[jbpm-dev] Proposal for jBPM5 first release

[Kris Verlaenen]

Walter Egger wrote:
> 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:
Feel free to raise those concerns.  A process instance is indeed stored 
as one row (in its most simple form) in the database, consisting of id, 
some metadata (like processId and state) and a binary object 
representing its current state in Drools Flow.

> - 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
Part of merging both jBPM and Drools Flow, is that Drools Flow will be 
modularized more.  They will be using the same core sometimes.  Note 
however that, when you're only using processes and not rules, the 
session state will basically be empty, as the process instance state is 
stored separately from the rest of the session state.

> - 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)
I like this.  Could you explain how you see this happening?  While it 
would be trivial to not persist data (for example by annotating it), 
does that mean the value will always be null afterwards?  Or how will 
this data be repopulated when reloading the state?  Might be possible to 
support this use case using pluggable variable persistence, where you 
don't actually store the variable value but customize how the variable 
values should be stored (or in this case not be stored).

> - 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)
There's nothing that would prevent you from dynamically adding new 
process definitions.  You can also migrate a process instance from one 
process definition to another (assuming the states can be mapped).  
You'd obviously need some tooling to support the case you are describing.

What we're also doing however, to allow you add dynamically add new 
tasks in the context of an executing process instance, without actually 
requiring the need to change the definition it is linked to.  This could 
also be useful to create more dynamic processes.

Kris