Re: [jbpm-dev] Proposal for jBPM5 first release
by Staub, Edward
Kris,
Unless you've been getting a lot of private communication, the paucity of feedback here must be troubling.
I've been involved with workflow since around 1990, and it has always been plagued with too many competing products and specifications. Just within the organization, JBoss suffers from this greatly, with three products competing for mindshare. (I know, each has a sweet spot, but nevertheless, they share less than they should.) If JBPM can span the needs of the various constituencies better, I think it would be a big win.
In looking at JBPM and Drools-Flow, there are a few requirement candidates that I'm surprised there hasn't been any discussion of. I don't mean to promote these - but I do think that it may make sense to explicitly rule them in or out - especially "out", so that people will react if it's painful not to have a particular feature. It may well be that none of them are important to anyone who's a real stakeholder here. I'm NOT a stakeholder, except in the sense that my company may at some point decide to use JBPM.
Apologies in advance for any misinformation here - it's unintentional!
Are these needed?
=================
1.) Open persistence - by which I mean, a database schema where the process and "thread" states, definitions, etc., are modeled in the database - not in a big blob. JBPM has this, Drools-Flow doesn't.
2.) Isolated or collaborative custom nodes. In Drools-Flow, the WorkItem is (deliberately, I think) isolated from the engine. It can get parameters, and return values - that's it. In JBPM, the Activity has more-or-less full access to the engine.
3.) Custom Decision Handlers. In JBPM, decision nodes can be customized just as much as Activity/WorkItem nodes. In Drools-Flow, the only inputs to a decision are the KnowledgeBase variables.
4.) Use of rules for decisions. They both have this in some form. The JBPM support is a subset of Drools-Flow. Is it sufficient to satisfy Drools-Flow users? If not, what's "missing"?
5.) A roadmap for web services. JBPM has historically done nothing in this area. Is this still the plan?
=================
I hope this is helpful.
Good luck,
-Ed Staub
14 years, 5 months
Features and jBPM 5
by Brad Davis
Here are features that I have seen a need for in jBPM while using it at our various Red Hat clients. These comments are based on the currently supported 3.2 branch.
1) The ability to create Typed Actions which can be plugged into the Eclipse UI [similar to Drools Flow]
2) Truly plug-able Identity Management backing to JAAS.
3) Email Notification should instead be a general notification framework.
a. Oracle BPEL supports this functionality - See: http://download.oracle.com/docs/cd/E11036_01/integrate.1013/b28981/notif.htm
b. Notifications should be sent to secondary service via JMS to ensure that no notifications are sent until the Transaction completes successfully.
c. Out of the Box Email Notification Support for HTML Email and multiple SMTP servers [similar to what was created for jBPM 4]
4) Reporting; this has been suggested in jBPM 5 blogs.
a. Contact me for specifics; we can questionnaire our clients.
5) Service layer to more easily create custom UI for processes.
6) More Complex Form Generation for Tasks via XForms?!
7) Better Audit Logging configuration OOTB.
a. Ability to offload this from the main database to a secondary store [like warehouse].
8) OOTB use of JBoss Cache.
9) Cluster-ready timer executions.
10) Keep Decision Handler plug-ability.
a. Provide OOTB Drools support.
b. Reuse existing BRMS tooling and provide jBPM Eclipse integration with BRMS?! for Drools Decisions via Wizard.
11) Bring Maven Support in-house from the current Codehaus offering [http://mojo.codehaus.org/jboss-packaging-maven-plugin/par-mojo.html]
12) Support Process Upgrades OOTB.
a. If a new Process Definition is added because the previous one is flawed, give users the ability to bring existing processes to the current version from the jBPM console.
>From my experience, no one in the field has asked me for support to edit workflows in the browser. If I were scheduling features, I would put this last. It increases the development effort for the product with little payoff. Our true competitors should be seen as Microsoft Biztalk and Oracle ESB/BPEL, not Activiti. There are so many more features we could spend our time on than in-browser workflow manipulation.
Additionally, I fundamentally believe that all our SOA initiative should start and end in workflow. The integration in SOA-P currently for jBPM and back is not ideal. To create a Service, it should be as simple as configuring an input type and output type in jBPM, configure if the process should be request/response or async, and registering within the jBPM workflow the appropriate ESB gateways. So, my suggestion is to pull the gateway concept into jBPM directly. This has worked well for both Oracle BPEL and Biztalk.
14 years, 5 months
Re: [jbpm-dev] Features and jBPM 5
by Mauricio Salatino
I agree about the JMS Job Executor,
I don't agree with the true parallel execution, I think it's just a
conceptual change, and if you really need parallel executions, you can
implement a Work Item that do that for you.
Including multi threaded execution at business process level seems to be
very technical for a high level view of a business situation/use case.
Cheers
On Fri, May 28, 2010 at 10:20 AM, Bernd Rücker <bernd.ruecker(a)camunda.com>wrote:
> Hi Eric.
>
> Quick remark on JMS: We made the experience in big clustered environments,
> that the JobExecutor (okay, we pimped it :-)) scales even better than JMS.
> Because Jboss Messaging, clustering and huge amounts of messages aren't
> best friends (okay, maybe that gets better with HornetQ)...
>
> Agreed on a lot of issues from Brad.
>
> Cheers
> Bernd
>
> -----Ursprüngliche Nachricht-----
> Von: jbpm-dev-bounces(a)lists.jboss.org
> [mailto:jbpm-dev-bounces@lists.jboss.org] Im Auftrag von Eric D. Schabell
> Gesendet: Freitag, 28. Mai 2010 12:02
> An: Brad Davis
> Cc: jbpm-dev(a)lists.jboss.org
> Betreff: Re: [jbpm-dev] Features and jBPM 5
>
> Brad,
>
> I am so glad you did this, make the list I was putting together based
> on my experiences obsolete (almost).
>
> One thing I know that several customers have asked about in regards to
> current projects running on our supported versions of jBPM is to have
> real parallel execution. So when they use a fork / join they want it
> to truly use separate threads, which is not happening now. I believe
> the current versions are running single thread with sub-flows and
> forks just executing serially.
>
> Also would be nice to drop the existing and simple JobExecutor queuing
> mechanism and REQUIRE a real JMS queue. I see lots of customers trying
> to scale out the default implementation and I see no reason to provide
> a simple queue solution or maintain it if it is not usable in real
> enterprise solutions.
>
> For the rest I have been very busy with travel around my region, my
> next post will be to comment on the rest of the roadmap.
>
> Kind regards, erics
>
>
>
> On Thu, May 27, 2010 at 4:33 PM, Brad Davis <brad.davis(a)amentra.com>
> wrote:
> > Here are features that I have seen a need for in jBPM while using it at
> our
> > various Red Hat clients. These comments are based on the currently
> > supported 3.2 branch.
> >
> >
> >
> > 1) The ability to create Typed Actions which can be plugged into
> the
> > Eclipse UI [similar to Drools Flow]
> >
> > 2) Truly plug-able Identity Management backing to JAAS.
> >
> > 3) Email Notification should instead be a general notification
> > framework.
> >
> > a. Oracle BPEL supports this functionality – See:
> >
> http://download.oracle.com/docs/cd/E11036_01/integrate.1013/b28981/notif.h
> tm<http://download.oracle.com/docs/cd/E11036_01/integrate.1013/b28981/notif....>
> >
> > b. Notifications should be sent to secondary service via JMS to
> ensure
> > that no notifications are sent until the Transaction completes
> successfully.
> >
> > c. Out of the Box Email Notification Support for HTML Email and
> > multiple SMTP servers [similar to what was created for jBPM 4]
> >
> > 4) Reporting; this has been suggested in jBPM 5 blogs.
> >
> > a. Contact me for specifics; we can questionnaire our clients.
> >
> > 5) Service layer to more easily create custom UI for processes.
> >
> > 6) More Complex Form Generation for Tasks via XForms?!
> >
> > 7) Better Audit Logging configuration OOTB.
> >
> > a. Ability to offload this from the main database to a secondary
> store
> > [like warehouse].
> >
> > 8) OOTB use of JBoss Cache.
> >
> > 9) Cluster-ready timer executions.
> >
> > 10) Keep Decision Handler plug-ability.
> >
> > a. Provide OOTB Drools support.
> >
> > b. Reuse existing BRMS tooling and provide jBPM Eclipse integration
> > with BRMS?! for Drools Decisions via Wizard.
> >
> > 11) Bring Maven Support in-house from the current Codehaus offering
> > [http://mojo.codehaus.org/jboss-packaging-maven-plugin/par-mojo.html]
> >
> > 12) Support Process Upgrades OOTB.
> >
> > a. If a new Process Definition is added because the previous one
> is
> > flawed, give users the ability to bring existing processes to the
> current
> > version from the jBPM console.
> >
> >
> >
> > From my experience, no one in the field has asked me for support to edit
> > workflows in the browser. If I were scheduling features, I would put
> this
> > last. It increases the development effort for the product with little
> > payoff. Our true competitors should be seen as Microsoft Biztalk and
> Oracle
> > ESB/BPEL, not Activiti. There are so many more features we could spend
> our
> > time on than in-browser workflow manipulation.
> >
> >
> >
> > Additionally, I fundamentally believe that all our SOA initiative should
> > start and end in workflow. The integration in SOA-P currently for jBPM
> and
> > back is not ideal. To create a Service, it should be as simple as
> > configuring an input type and output type in jBPM, configure if the
> process
> > should be request/response or async, and registering within the jBPM
> > workflow the appropriate ESB gateways. So, my suggestion is to pull the
> > gateway concept into jBPM directly. This has worked well for both
> Oracle
> > BPEL and Biztalk.
> >
> > _______________________________________________
> > jbpm-dev mailing list
> > jbpm-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jbpm-dev
> >
> >
>
> _______________________________________________
> jbpm-dev mailing list
> jbpm-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbpm-dev
> _______________________________________________
> jbpm-dev mailing list
> jbpm-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbpm-dev
>
--
- CTO @ http://www.plugtree.com
- MyJourney @ http://salaboy.wordpress.com
- Co-Founder @ http://www.jbug.com.ar
- Salatino "Salaboy" Mauricio -
14 years, 6 months
Re: [jbpm-dev] Proposal for jBPM5 first release
by Michele Mauro
Since Edward called "to get a rise out of other folks", I think I'll rise my
hand too :-)
To put my words in perspective, I have a lot at stake in jBPM: I'm the
senior architect at a consultancy/software house that has one big product in
production (4y/man in the making) based on jBPM 3, another implementation
ongoing, and several pilot projects with jBPM4 and Drools Flow.
Regarding the very interesting points raisen by Edward, I'll add my
respectful opinion:
> 1.) Open persistence
While I agree with Edward on the value of an open relational schema for
reporting and similar tools, I think the choosen path is more valuable. If
you have needs for an open schema, you'll almost always better served if you
design it yourself. With some interceptors in the right places (jBPM4 seems
to have the right hooks to plug them in) you can keep your report schema
aligned with the engine's data, without disturbing it too much. Even jBPM3's
very open and flexible schema is not good enough with some kind of processes
(I have some 150+ nodes, 200+ variables, very long financial processes to
manage), so you'll end up with something custom anyway. If you design it
flexible enough, however, you could come up with an interesting extension.
> 2.) Isolated or collaborative custom nodes.
There already is an interesting practice coming out of Drools Flow about
Domain Specific Processes, so Edward's needs will be served by that tooling,
probabily.
> 3.) Custom Decision Handlers.
Due to point 4, there should be little need for these. If you have a
decision to make, is far better to have it documented with a rule instead
than in code. I can tolerate MVEL-based decision evaluators, if they don't
get too big. If you have to check with external data and services, you
better bring that data in the process first (and deal with what happens if
you can't get it) and decide on it afterwards.
> 4.) Use of rules for decisions.
Drools wins in this field, hands down. With Guvnor and the BRMS
infrastructure, you can have documented, readable and managed (versioned &
avalaible in a repository) decision rules/conditions in a language far more
flexible and expressive than Java code. Anything you ask for (connection,
services) should not be included in the decision conditions or can be
brought in with little integration effort.
> 5.) A roadmap for web services.
Web services are a separate integration issue. And if what you need is
orchestrating webservices, you are better served with BPEL.
The focus on BPMN2 is really the top priority for jBPM5: we have real
competition on that. Combining BPMN2 and rules may be the best
differentiator between jBPM5 and other offerings.
Just my opinion. Edward's concerns are just as valid, of course. I've just
represented another point of view.
Michele
--
Michele Mauro
Senior Architect
Visionest S.r.l. - The Business Innovator www.visionest.com
Via G.B. Ricci 6/A
35131 Padova - Italy
E-mail: michele.mauro(a)visionest.com
Mobile: +39 349 2222319
Phone: +39 049 8210229
Fax: +39 049 8774924
14 years, 6 months
Re: [jbpm-dev] Proposal for jBPM5 first release
by Walter Egger
Hi Kris,
our company has been using jBPM3.x for a while. Some months ago i have
been evaluating jBPM 4.x and drools flow to choose a framework for our new
application. while i liked a lot of features in drools flow, i have some
concerns regarding the persistence solution (process is in a stateful
knowledge session and serialized in a single blob field in the database).
here are some comments to the proposed jBPM5 architecture:
- support of BPMN2.0 integration is highly appreciated
- integration of an ioc container would be nice (e. g. spring ioc)
- osgi support
- possibility to run a process without drools, persistence should not
depend on persisting a stateful knowledge session
- possibility to use transient data in a process, data that is not
automatically persisted (we have long running processes, where data is
also changed outside of the process scope - we have to insert some facts
into the session per request)
- possibility to change the definition of a running process instance
(changes on the fly when you are executing a process, persisting such a
"dynamic" process would mean, to also persist the process definition for
each instance. we could define a "standard" workflow, with the possibility
to allow the user/application to add some steps to the running process)
kind regards,
Walter
14 years, 6 months
Simulation
by marco sabatini
I want to know wot to simulate process defined with jbpm modeler? Exsist
some tool?
The simulation is very important for my domain model!
Thx in advance!
--
-------------------------------------------
Linkedin Account: http://it.linkedin.com/in/sabatinimarco
mobile: +39 3313852736
skype: marco.sabatini1
"Laudamus veteres, sed nostri utemur annis"
-------------------------------------------
14 years, 6 months
jbpm 5 feedback
by Wim Geeraerts
This is the feedback we have at this point:
CORE PROCESS ENGINE
The time line will be very important for us: which BPMN2 nodes will be
implemented first?
It would be great if we have a number of core nodes in a first phase
and the ability to customize these (both by configuring the core nodes
and by adding custom nodes)
Customization of nodes is key to us, f.e. we want to be able to
define our own task created within a task node with custom attributes
and with links to our domain data
process instance migration is something we don't want to happen
always. In some situations we want our old process instances to use
old process definitions. Furthermore process instance migration must
be extensible since some of the constraints are application specific.
Jbpm 5 can only provide a good default implementation.
HUMAN TASK
good that is is based on a standard
Will this be offered as a POJO instead of a webservice?
Will this be customizable? (as described above, we want our own
flavour of tasks to be created)
Will the task data pattern be implemented? Having scoped variables is
important for us.
We need group assignment / escalation / assignment rules - again this
should be customizable
Human task console / from editor is something which has less priority
according to us. If the core is there these tools can be created on
top of that afterwards.
PROCESS REPOSITORY
Versioning of processes is a must. Also think about how attached
business logic or rules will be versioned. What is the link between
process version and business rule version? . Furthermore if old
process instances refer to business logic using class names (as in
jbpm3 f.e.), they will no longer work if the business code is
refactored (i.e. the class names are changed). So we need a better
way to link the business logic / business rules from within the
process description and version these.
Dynamically updating processes - how whill this behave if process
instances are active at that time? This is a nice feature but with a
lower priority.
Scenario testing before deployment - Does this mean we can test the
application using the new process definitions before they are
deployed? Nice feature but again lower priorty according to us.
BPM CONSOLE / WEB-BASED PROCESSING TOOL
It would be beneficial to have the same functionality available via
EJB. I.e. it would be nice if the web tools would just be a WS layer
on top of a set of EJBs (which we could use to create our own
integrated tools).
SIMULATION
Something we would use in a later stadium to allow service engineers
to adapt processes to optimize usage of resources f.e. But for us
this has a lower priority.
BAM/BI
It would be nice if the data that is used to create the BIRT reports
on is available, so that we can integrate our own BI solution (Oracle
BI f.e.) on top of this.
We will use this not only to show statistics but also to do trend
analysis and report changes in trends, f.e. some data normal for one
site is abnormal for another site
So again here according to us it is more important to focus on the
core (make sure the data is there) and a customizable way to consume
the data (with BIRT as default implementation)
INTEGRATION
authentication / authorization: it must be possible to provide our own
module here.
JOPR => is there also an integration with RHQ?
Kind Regards,
Olivier Debels, Wim Geeraerts, Roel Adriaensens ( Agfa HealthCare)
14 years, 6 months
jbpm5 RFQ
by Zeljko Kovacevic
Hello all,
I'm working now for 2.5 years in a telco project that is heavily based on jBPM 3.2.3.
Since the very first steps we really enjoyed jBPM and introduced a couple of modifications and so I take the chance to give some feedback.
What we love is the lean&mean approach of jBPM. Introducing new developers to the framework is of course not a matter of hours. But compared to i.e BPEL - which imo is a nightmare - it has a flat learning curve, is extendable and by usage of Java-ActionHandlers: Unit-testable.
Basically this application is a order management system that besides its core task performs account/product suspensions, feature provisioning , inventory management, etc.
So we have a wide mix of synchronous/asynchronous processes, Webservice and queue communication which additionally have different performance goals.
The PVM-targets are pointing to the right direction - at least for our needs.
We share the need for a integration layer, however modularity and extensibility should be primarily focused on the core task which is process.
>From a technical perspective our needs led to some changes in jBPM.
1. saving Java objects as variables
The standard mechanism supports saving of business java objects. However, jBPM serializes objects and saves it in chunks. Honestly this feels like a relict from long ago (Oracle 7) where one needed to avoid clobs for performance reasons. We've introduced another converter and Hibernate mapping to store JSON'ed objects in a clob column (on a per-process rather than per-token basis).
2. async node execution
A async-marked node will cause JBPM's MessageServiceImpl to create a JMS job-message which in turn is consumed by a MDB/MDP in order to continue execution. Though this is a simple mechanism it has drawbacks.
One needs local/sticky queues to remain on the same physical machine. This is to benefit from an already warm cache. Sure one could use a distributed cache. But from our experience there is nothing faster than to stick on the local machine.
Moreover, using plain JMS for async nodes leads to an equal distribution of processes being started and the ones being continued. I'd prefer already started processes being executed with higher priority. Therefore we are internally using a thread-pool that gives a higher priority to running processes.
3. transaction management
Currently there is no means to separate framework and business transactions. Therefore we have a strict all-or-nothing situation. In case of exceptions one can either commit the transaction in order to have a consistent process-state (and inconsistent business data) or the other (business data consistent but process-state lost because of rollback). All we came up with was to rollback the transaction and reconstructing necessary process-data given the java objects we still were able to access. Additionally jBPM logging is done in a separate transaction. Separating framework and business transactions by means of async actions is not really an option, because every async action runs in a separate transaction.
4. mixing persistent/not persisted processes
Nearly all business processes in this application are modeled as jBPM processes (for documentation purposes). Some parts could have easily been replaced by plain java code. As an example think of "classic" orchestrated services bundled in a subprocess. In order to gain performance those sub-processes are not being persisted. Out of the box mixing persistent and not-persistent processes is not possible (think variable copying, subprocesses,...).
Besides that we've targeted following points:
5. integration layer (not necessarily ESB)
We strongly encourage the introduction of an integration layer.
Having to talk to dozens other systems with not necessarily the same release cycles (unexpected API changes) urges for an integration layer. Another example: using WebServices with different security constraints depending on the context of the process.
>From our point of view the IL is a mere means to decouple sender and receiver *within* the application server (giving the possibility to transform, enhance, ..., ) and supports modular design. Maybe (means: not really) things are different if processes were spread around multiple systems.
I think there will always be cases that prevent a clean migration path from let's say jBPM3 to jBPM5. Imagine millions of order processes hanging around in the db and waiting to be *properly* migrated...
In the end companies will accept such additional investments if the benefits pay of.
We are already now able to combine all fancy JBoss products to create a "workflow suite". I'm afraid that by spreading the goals and introducing new/newest technologies (OSGI/BPMN2/other langs/JPA/Drools/...) the focus will be lost.
At least our company invests a whole lot of money in describing enterprise-processes, coding and optimizing that processes. I would be glad to see that these tasks were supported best of jBPM.
jBPM should provide consistent means to tackle modeling, management and superior execution of processes before taking off for the Clouds.
cheers,
Zeljko
14 years, 6 months
Release 5
by marco sabatini
When release 5 will be on line? It's very interesting for us and we,d want
to know the period of release.
Thanks a lot,
regards.
--
-------------------------------------------
Linkedin Account: http://it.linkedin.com/in/sabatinimarco
mobile: +39 3313852736
skype: marco.sabatini1
"Laudamus veteres, sed nostri utemur annis"
-------------------------------------------
14 years, 6 months
