jBPM at JavaOne2005
"Graph Oriented Programming" is NOT going to become the foundation for BPM - that I am certain. If jBpm wants to make that a criterion for success, it is set up for a disappointing failure. There is a simple reason - jBpm GOP may be a model for programming, but it isn't a model for BPM, at least not a good one.

jBpm doesn't really need the hype. If it is any good, it will be accepted based on its own merits. It is a open source, free software, after all.
Thank you for the insight. In addition to your and Tom Baeyens reviews, are there other customer reviews out their that would help me make a jPbpm 3.0 application decision?

I am not aware of any decent-sized projects using jBPM, and haven't read any case studies. I haven't been following jBPM effort for a while now. Perhaps you can find relevant information on the JBOSS jBPM site and related user forums.

I can tell you Tom is right and you are wrong. Will post the exact reasons in my own blog at: http://duckdown.blogspot.com/ shortly...

Have you posted your reasons yet? I'd be interested in reading them and see if I am missing something.

Post a Comment


Comments on jBpm 3.0 

Since I commented on jBpm 2.0 model earlier in this blog, I have been asked to review jBpm 3.0 beta. This is not really a review per se, but my quick observations after spending a couple of hours on jBpm-3.0-beta4 and jBpm-bpel-1.0-alpha1.

jBpm 3.0 is essentially has the same underlying model as its predecessor, and that isn't surprising. From the architectural view point, it has more of a pluggable architecture (i.e., we can plug in our own modules that take up certain workflow responsibilities, for example, task handling), which can be a good thing. There is also a new graphical designer, which I didn't check out. There are a few implementation enhancements related to persistence and such, as well as many improvements related to deployment and documentation. However, I didn't see any notable changes or improvements from the modeling perspective.

The BPEL component, which is in alpha1 stage, is in very early stages of development. A full-blown implementation of the BPEL standard is not trivial, and I don't expect to see this component being ready atleast until the end of 2005. Some BPEL constructs have been added including messages and message correlations, but I don't know how complete they are. The current model still remains void of some non-trivial constructs such as scopes, compensations, and fault handlers. Some diligent analysis is required on my part before I can conclude whether or not jBpm can support all control flow constructs that BPEL specifies.

Overall, nothing in jBpm 3.0 made me change my earlier opinion that jBpm model is ad hoc and suboptimal, but Tom Baeyens has a different opinion (I hope that he is right and I am wrong). That said, I won't hesitate to use jBpm where ever I can, if I find it sufficient to fit the needs of the situation at hand.

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