Comments on jBpm
Blog: Business Process Management
There is a lot of buzz about jBpm since it joined Jboss. It is an exciting news for the workflow/bpm community, especially for those, like myself, who wished they didn't need to build their own workflow engines in the past. It appears that there is a lot of mometum with 30+ developers (as listed on www.sourceforge.net) and some 6500+ messages posted on forums.
I downloaded jBpm2.0 source and spent about 4 hrs browsing the code and understanding the model. My first feelings are mixed.
I was surprised to find that the underlying computational model behind jBpm isn't Petri Nets. Considering that the design of the core engine is influenced by the workflow patterns work (www.workflowpatterns.com) conducted by Wil van der Aalst and his group, I'd have expected, naturally, that Petri Nets would have been a natural choice. jBpm adapts more of state-machine approach with special constructs for forks and joins. All those workflow patterns that jBpm attempts to support are naturally supported by a Petri Net model.
The chosen model itself seems unfit to support all intended workflow patterns, unless one writes custom fork handlers, action handlers, and such, in effect leaving modeling constructs in the developer's hands. I would have liked the model to support all the intended patterns and much more. This model might be better than some others, but far from being complete.
I understand jBpm is still in the initial stages, but I don't see how BPEL can be translated into jpdl in the future, as promised, even after several iterations on jpdl. jpdl and its underlying model simply don't have some basic constructs (e.g., messages, message correlations, and compensation scopes/spheres, etc). Introducing them at a later stage isn't going to be a trivial exercise, at least in a meaningful way. In the absence of a sufficiently capable model, one can always allow custom Java programming to achieve anything one needs to achieve, but that isn't very valuable.
I downloaded jBpm2.0 source and spent about 4 hrs browsing the code and understanding the model. My first feelings are mixed.
I was surprised to find that the underlying computational model behind jBpm isn't Petri Nets. Considering that the design of the core engine is influenced by the workflow patterns work (www.workflowpatterns.com) conducted by Wil van der Aalst and his group, I'd have expected, naturally, that Petri Nets would have been a natural choice. jBpm adapts more of state-machine approach with special constructs for forks and joins. All those workflow patterns that jBpm attempts to support are naturally supported by a Petri Net model.
The chosen model itself seems unfit to support all intended workflow patterns, unless one writes custom fork handlers, action handlers, and such, in effect leaving modeling constructs in the developer's hands. I would have liked the model to support all the intended patterns and much more. This model might be better than some others, but far from being complete.
I understand jBpm is still in the initial stages, but I don't see how BPEL can be translated into jpdl in the future, as promised, even after several iterations on jpdl. jpdl and its underlying model simply don't have some basic constructs (e.g., messages, message correlations, and compensation scopes/spheres, etc). Introducing them at a later stage isn't going to be a trivial exercise, at least in a meaningful way. In the absence of a sufficiently capable model, one can always allow custom Java programming to achieve anything one needs to achieve, but that isn't very valuable.