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
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
