BPM for free - IT Directions

« Eclipse and the end of the Microsoft monopoly | Main | A simple way to evaluate open source »

March 23, 2006
BPM for free

This is the 3rd entry in a blog series on open source - this time I will introduce another major open source project of which every enterprise should be aware, and next time I will discuss a quick and simple way to evaluate open source projects in general.

This time it is the turn of JBoss jBPM. There are a number of open source workflow/BPM projects, ranging from simple BPEL engines to fully-fledged suites. However, the JBoss offering is particularly interesting, for 3 reasons:

JBoss is, these days, about as blue-chip as you can get in the open source world. Not only do they offer a complete range of middleware, but they have download rates that must be the envy of other products (typically hundreds of thousands per month) and are venture-capital backed. Implementing JBoss now is like buying IBM used to be.

jBPM supports BPEL, but is based on a more powerful programming model - what they call Graph Oriented Programming - with its own process definition language, jPdl. This language was designed from the ground up to support the workflow patterns developed by Prof. Wil van der Aalst and his group.

Why is this important? Because the workflow patterns attempt to represent all possible modes of behaviour in a "programmatic" business process - preset workflows in which human involvement is limited to key decision and data entry points. So if your process definition language can represent all the patterns, you know you can automate just about any such business behaviour using it. As far as I know, jBPM is the only workflow system that claims to support all the patterns.

jBPM is closely tied to the component architecture of the entire JBoss suite. In my recent blog series on BPM Futures, I discussed how process automation is effectively becoming a graphical interface to component tooling. This approach is very much in line with the architecture of jBPM. Web services, for example, can be employed as desired, but there is no need to move program control flow into a weak language such as BPEL unless it is necessary - you can do as much or as little as you want in Java, for instance.

TAKE AWAY

There is a lot of discussion about BPM at the moment - the debate around jBPM is typically lively - and a lot of this debate is still along the lines of: so what is BPM and why do we need it?

As I have commented before in this blog, despite the views presented by analysts and vendors, anyone working at the coalface in a range of companies will know that by far the bulk of enterprise process automation is still done using ERP packages and component technologies rather than using dedicated workflow/BPM tools.

I discussed in previous entries how new approaches may well change that, as "declarative" techniques enable the automated generation and application of certain types of executable process. In future entries, I will be looking in more detail at the implications of this for enterprise architecture. For now, however, anyone seeking an enterprise-strength process automation system would be well-advised to look at jBPM. Not only is it a powerful open source solution, but it fits naturally with emerging techniques and tools (coming with its own Eclipse plugin, for example).

In the next and concluding entry in this blog series on open source, I will discuss how to decide when you should not adopt an open source approach - without needing to spend a fortune on consultancy advice to find out!

Posted by keithhb in Business Process Management • Open Source |Digg This|Add to del.icio.us

Comments

jBPM is also very different than a BPEL engine or workflow system.
While in a typical BPEL engine, the engine is a separate process or thread, waiting in-coming messages for going further in some processes and dispatching messages to external systems for triggering some work out there. The BPEL engine is external to the application.
jBPM is different, it is a library that will be embedded in your application, there won't be a separate thread or process wich will invoke your services as needed. The application simply asks jBPM, I'm done, what's next? and then jBPM will call back the appropriate class of that same application.
Comparing jBPM with other BPM systems is not really accurate. I think jBPM is much more flexible but it does not come with the Web services plumbing stuff (which may or may not be be a drawback).

Posted by: Robin Mulkers at March 29, 2006 01:26 PM

Thanks for your comment, Robin.

Yes, jBPM is a Java library - but that doesn't mean you have to run it in the same thread. In fact, that would be a rather bizarre approach. What enterprise application of any kind runs in a single thread? JBoss jBPM in particular can be integrated with another JBoss product called SEAM, for instance, and via such methods you can separate the process engine as cleanly as you like from any external components or services that it makes use of.

With regard to the WS-* stack, as you know there is currently intense debate in the SOA community about the necessity of these techniques. However, jBPM can be used in conjunction with the WS-* stack if desired - there is a JBoss Web service platform, for instance, and any third party ESB or WSM product could be used alongside jBPM - just as with any BPM product.

Posted by: Keith Harrison-Broninski at March 29, 2006 07:57 PM