[jbpm-dev] Proposal for jBPM5 first release

[Kris Verlaenen]

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