Should you bet on jBPM?

In a recent webinar from Active Endpoints called "Should you bet on jBPM?", Michael Rowley described the findings of his evaluation of jBPM. This includes what he believes jBPM is good at and what it is bad at, relation to standards, etc. It's always a good thing if competitors think they need to do a comparison, right? ;)

Unfortunately, he decided to evaluate jBPM v3. Fair enough, jBPM5 isn't out yet, so selecting jBPM3 probably made sense. But luckily, a lot of the "issues" he has with jBPM3 have already been improved significantly in jBPM5! For those that might have seen the presentation and are wondering what is still applicable for jBPM5, some highlights ...

Standards
jBPM5 is using existing standards wherever possible. BPMN2 is used for process definitions (both at the graphical level as well as the underlying XML). This means that concepts like exception handling, event signaling etc. are all offered using the concepts as defined in the specification (which were agreed upon as the best possible solution to represent these concepts by many experts in the working group). But it's not just BPMN2, but also WS-HT for human tasks (see below), JPA / JTA for persistence and transactions, etc., as we believe the use of these standards only brings benefits to our users.

Human tasks
Instead of having an embedded, proprietary human task solution, the new human task service is an independent service based on the WS-HumanTask specification, and allow more advanced features like escalation, reassignment, etc.

Low-level details
We try to hide low-level implementation details from the end user as much as possible. For example, there's no more concept of a "token" that the user needs to know. Also, we strongly encourage users to keep implementation details out of their process definitions. No more low-level Java integration code is needed inside your process (or handlers) to link to external services, this all can be handled as domain-specific extensions. The use of code inside a process should be limited to simply expressions / actions.

XML editing
While people are allowed to edit the underlying XML (used for storing process definitions) themselves, this is not are recommended approach and users should not be forced into doing that. There are property panels, but more importantly, there are user-friendly editors that pop up when double-clicking specific nodes (and yes, you can contribute your own!). For example, a screenshot of how you could specify the details when you need to send an email below.



Service Orchestration
It is true to say that jBPM is (currently) more focused on a Java environment. This doesn't mean you can't do web service invocations, but if all you're currently interested in is web service orchestration, you might find the default support for process interface generation, correlation and XML data handling a little bit limited. We'll be working on improving that after jBPM 5.0, but luckily JBoss has another project called RiftSaw which does exactly that: offer web service orchestration using WS-BPEL execution based on the Apache ODE engine. Both projects share a few components already and we're working on a combined long-term strategy, but definitely take a look there as well if you need pure service orchestration.

As you can see, lots of improvements and new features have already been added in jBPM5. Want to know more? There's a webinar next week where I will give a one-hour introduction to jBPM5! So register now!