For updated content from Camunda, check out the Camunda Blog.

Abstracting the Process Engine


Wow, what unexpected moves in the area of jBPM recently! Starting with Tom and Joram leaving the jBPM core team (see Die Zukunft von jBPM) to develop a new engine (see Alive and kicking). And yesterday – after being quite for a pretty long time – JBoss gives their answer for the future of jBPM and a vision for jBPM 5 (see Announcing jBPM 5). But what does that mean for projects using jBPM already or plan to start using it? Hence a pretty common question from customers approaching us is: Which engine and which version should we use?

And that is a tough question. Even with some more insights of the projects I find it hard to answer. Let’s have a quick look at the situation:

  • jBPM 3.x is supported by Red Hat and successfully used in a lot of projects, hence it is pretty stable. We have a lot of experience in that area and know every bit and byte of it. But it is not really developed further.
  • jBPM 4.x is not yet finished and some bugs or missing feature might catch you in the project. Operating it in a larger scale is not yet proven (as far as I know). And no Support from Red Hat is available.
  • Drools Flow is in some intermediate state as well. No support is offered by Red Hat for it.
  • jBPM 5 is till now just a wiki page. The concrete Roadmap is not yet defined.
  • The new engine from Tom and Joram is not yet released and it is not yet sure when it will be stable and usable in production exactly.
  • And there are even some other engines like Bonita or the like.

Technically I think the differences of the engines are obviously existent, but not that huge. As written in my last blog: Finally it is “just” a state machine 😉 For the decision which engine to use I think you should have a look at other arguments, for example:

  • Is there professional support available?
  • Will there be maintenance for the engine?
  • Does the open source project have a vital community?
  • Is it proven in bigger real live projects?
  • Is there a vision of the project?

So for example one of our customers starts a new project at the moment. For him the decision for the engine is pretty hard. First thing we now decided is to create a good abstraction of the engine before plugging it into the project. This is something I have done or seen pretty often already, actually I would say in most of the projects. I am not sure why we just needed the engine confusion to get the obvious idea:

We want to create a Process Engine Abstraction Layer to make the Process Engine pluggable. That’s a bit like slf4j or JDBC for Process Engines. And it will be Open Source, independent of a concrete engine and available for everybody!

Abstracting the Process Engine

Abstracting the Process Engine

This idea was in the JBoss PVM already, with the difference that it was pretty much part of the jBPM project. What we want to do is to define the API on our own. Then we can provide a binding to jBPM 4 as well as to the new engine, jBPM 5, or whatever. Ah, and another customer has another problem: He uses jBPM 3, and even if he is pretty happy with it, he needs to switch to BPMN 2.0 later on at least for political reasons. So there we want to provide a binding to jBPM 3 to allow an easy migration path from jBPM 3 to another engine in 2 steps: First change the code to use the abstract API and if that runs without problems you could switch to another engine smoothly. Even you could implement to run both engine in parallel to avoid runtime process instance migration. Or to put it in easy words: Already running process instances finish in the old engine, new process instances are started in the new engine. And that will be handled transparently behind the scenes 🙂

And how to migrate the process models you may ask? Bloody good question! Our approach is to use a mapping to a business model in BPMN. This model is independent of the engine and could even be mapped in another format later on. Sounds unrealistic? Maybe in a generic way, but currently we already used it successfully in a pilot project, so it looks promising!

I will provide a draft of that Abstraction Layer / API as soon as possible, but I want to discuss that internally in camunda and with a couple of customers before going public. But don’t hesitate to contact me if you are interested in such a layer: What I can say is that it (surprise, surprise) will not miles away from the jBPM 4 API. But I currently have a look at other API’s and engines as well, e.g. jBPM 3, Apache ODE, an upcoming BPMN 2.0 Engine and custom build abstractions from various projects.

So in a prefect future you can answer the question “Which engine do you use in your project?” with “it doesn’t matter” 😉 So stay tuned, it will get a really interesting summer!


P.S: Today I wrote in English, since I think these thoughts are interesting in an international context. Sorry for our German speaking fans 😉

Already read?

Scientific performance benchmark of open source BPMN engines

Why BPMN is not enough

Decision Model and Notation (DMN) – the new Business Rules Standard. An introduction by example.

New Whitepaper: The Zero-Code BPM Myth

15 Responses

Leave a reply