[jbpm-dev] Proposal for jBPM5 first release

[Maciej Swiderski]

Hi,

first of all, that's really great that jBPM 5 is on its way to be started.
This is really important to know because we can prepare some long term
planning.
There was number of different threads about jBPM5 features and I have to
admit that they cover almost everything that is required for first release,
to make it interesting for any customer. I hope you could come up with a
long term road map as well to illustrate to the customer that it is going to
be enhanced and will live quite some time (that I am sure of but sometime
without hard facts it is not so easy to convince business people).
In one of the threads there was discussion about web editor for process
definitions and I have to say that from what I noticed so far, for business
experts this is really important. Eclipse based tools are not of any
interest for them, they are far to complex (as they used to say). Web based
editors - this is what they want, especially with some repository
capabilities and (what would be perfect) with collaboration capabilities
where business experts can share and exchange ideas (and processes). What is
really important as well about web process editor is to have "two way
support", meaning that process developed in web editor can be consumed by
eclipse based tool and the other way around without lost of information.
This was something that was missing in current web editor (signavio) and
eclipse plugin for jBPM 4.x.
Another thing that could be quite useful is to have some kind of mechanism
that will support compensation. What would be good to have is to provide
compensation manager on process instance level that could invoke some stuff
in case of rollback (unexpected errors on process execution). Process
execution is within transaction boundaries but unfortunately not everything
is (or can be done) in transactional manner. This does not have to be very
sophisticated it is just to give some kind of listeners that could be used
by process developers to take some actions on rollback, even if that will be
just to send an email to administration personnel.

Ok, I think that's all. As mentioned before, most of the items were already
addressed by others. Thanks for that, and hope the dialog will go on.

Last but not least, I would like to take the chance to offer my help in
development (and any other tasks you find me useful). So whenever you have
complete plan and some issues to do, just let me know I will be on it ;)

Cheers and looking forward to see more information and ideas.
Maciej

2010/5/26 Kris Verlaenen <kverlaen at redhat.com>

> Ed,
>
> Thanks a lot for your feedback, comments inlined.
>
> Staub, Edward wrote:
> > 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.
> >
> It all depends on what you are trying to do.  jBPM3 used to combine
> current runtime state and history logs.  As of jBPM4, these are now
> stored separately, as does Drools Flow.  You're right when you're saying
> that Drools Flow uses a binary storage mechanism by default (though
> persistence is fully pluggable), where the internal state of the process
> instances is stored using a binary format.  There were various reasons
> for this (performance, migration, pluggability, shielding of execution
> engine, etc.).  There is however also a separate history log that
> contains history information, but also is real-time, so it contains info
> like the current active nodes, etc.  I would be very interested in the
> use cases you envision for "open persistence" though.
>
> > 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.
> >
> I don't think there's a real difference here.  You are correct in saying
> that a work item is a more limited than an Activity, as it's only
> purpose is getting results back (from an external system) based on some
> input.  But that's what the work item node was written for specifically
> (and is very useful for defining domain-specific extension imho).  You
> should probably compare a jBPM4 Activity with a NodeInstance in Drools
> Flow, which is the internal representation of a node executing.  There
> you would have access to the entire internal engine.  So you could plug
> in your own node implementation.  So why the difference you might ask?
> I think not a lot of developers are experts in that they feel familiar
> with plugging in their custom nodes.  But defining domain-specific nodes
> using the work item node (actually by just creating a configuration
> file) is a lot less complex.  But again, I'd love to hear about the use
> case you had in mind where you would need to define your own Activity.
>
> > 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.
> >
> The disadvantage of using Java classes for describing decisions like
> that is that you tend to end up with a lot of lower-level decision
> code.  And you should be especially careful if you are trying to access
> external state, as you should in that case handle the transaction
> management yourself.  In Drools Flow, this would probably be modeled
> using 2 separate nodes, one where you prepare the decision (and a result
> set the value of the decision variable) and then the actual decision
> node.  Since we're moving towards BPMN2, we should probably be looking
> at whether we would need to extend the BPMN2 spec for specific use cases
> in this area.
>
> > 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"?
> >
> The vision is that you should be able to combine processes and rules
> seamlessly.  The simplest case would be the use of a decision service
> where a decision is made based on some rules (and data).  This is the
> case jPBM also supported.  Currently, Drools Flow also supports use
> cases like rules for starting processes, rules for leaving wait states,
> assignment rules, rules reasoning on process events, processes driving
> rules, etc.  But we believe in going much further, offering constructs
> where rules could override process logic for exceptional situations, or
> a process might be nothing more than a set of process fragments, where
> the user or rules could decide which fragment to execute when.  I'm not
> saying everyone will need these features, but if you're looking for more
> flexible or adaptive processes, you'll be interested in this more
> advanced integration.   To be honest, I think this will become the
> default in the future, especially if you see the current interest in
> topics like adaptive case management etc., as you shouldn't see
> processes and rules (and event processing for that matter) as completely
> separate technologies but rather different ways of modeling your
> business logic which you can easily combine.
>
> > 5.) A roadmap for web services.  JBPM has historically done nothing in
> this area.  Is this still the plan?
> >
> Short-term, jBPM will focus on a more Java-oriented audience.  Invoking
> web services or integration with an ESB is definitely a target (you
> could even see them as a domain-specific node), but probably won't make
> the first release out-of-the-box.  If you're interested in pure web
> service orchestration, you could take a look at the RiftSaw project
> using BPEL.  While this uses a separate execution engine, we'll be
> sharing other components like management consoles, human task service,
> etc.  But we're already doing the exercise, where we are trying to
> define what it is exactly that is currently missing (WS discovery, sync
> and async integration, XML handling, etc.) and what we need to improve
> it.  We're more than happy to assist anyone who might be interested in
> this as well.
>
> Kris
>
> _______________________________________________
> jbpm-dev mailing list
> jbpm-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbpm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbpm-dev/attachments/20100530/b77f5408/attachment.html