[rules-users] Rule Flow vs jBPM

[Mark Proctor]

A better question should be why doesn't jbpm leverage rules :)

jBPM does many things we don't do, it's transactional and persistable, 
it has a number of services configured for nodes (tasks etc) and is 
generally better aimed at long lived orchestration and choreography and 
of course it is aimed at various workflow/bpm standards support.

Firstly the GUI side was donated and already partially integrated, it 
was a few days work to get that fully integrated or weeks of work (maybe 
more) to refactor much of jBPM designer to allow us to integrate and 
then ofcourse the further work to better supported our "tooled" 
environment. Our GUI side offers a far more integrated approach for 
rules, where as jBPM has more pojo focused, still leaving the author to 
implement interfaces and then specify the class as a callback within the 
configuration on that node - so it's far more low level.

Secondly if we where to leverage jBPM to do the state management of the 
executions we would end up with two engines running which would need to 
be bridged, contexts would have to be mapped and the tooling is not 
aimed at ruleflow but more orchestration of services - over all there is 
an impedenance mismatch which would actually make this more complex, the 
implementation slower and generally it would take longer to do. RuleFlow 
is a natural extension of the approached use by agenda groups and its 
hooked tightly into the engine to get the best performance.

Mark
Ming Fang wrote:
> The Rule Flow implementation looks similar to jBPM's Graph Oriented 
> Programming framework. 
> http://docs.jboss.com/jbpm/v3/userguide/graphorientedprogramming.html
> Was there any reason why it was not leverage?
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>