Hi JC Reddy,

I agree totally with your comments on Jbpm after having struggled with it for 3 months. I wish I had read your comments on it before starting to use Jbpm.

The model behind Jbpm does not look clean and logical. I thank to all their developers for making it available, but I don't think that it will be successful as Hibernate has been.
I certainly didn't mean to discredit all the good work done by the JBpm group. However, I do feel that the choice of model is not optimal, and may lead to incoherent implementation of more advanced features that will certainly be needed.
Hi JC,

Can I tempt you into reviewing jBPM 3.0 which will be in beta soon? I think it addresses so of your initial issues. It will support both jPDL and BPEL natively based on the same underlying computational model and maybe even bpss (ebBP) in the future.

I certainly look forward to checking out the 3.0 release. Thanks for all the good work.

Post a Comment


Comments on jBpm 

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.

This page is powered by Blogger. Isn't yours?