Open source workflow engines compared: jBPM, OpenWFE and Enhydra Shark

| by Gavin Terrill Follow 1 Followers on Aug 08, 2008. Estimated reading time: 1 minute |

Petia Wohed has announced the latest version of Patterns-based Evaluation of Open Source BPM Systems. Building on an existing report that compared closed source BPM vendors Staffware, WebSphere MQ and Oracle BPEL PM, the new revision includes jBPM, OpenWFE and Enhydra Shark. The report uses the patterns described in the Workflow Patterns home page as an evaluation framework, encompassing functionality across three main areas: Control-Flow, Data, and Resources.

The report summarizes:

Overall one can conclude that the open source systems are geared more towards developers than business analysts. If one is proficient with Java, jBPM may be a good choice, although if not, choosing jBPM is less advisable. Similarly, whilst OpenWFE has a powerful language for workflow specification in terms of its support for the workflow patterns, we postulate that it will be difficult to understand by non-programmers. Finally, Endydra Shark’s minimalistic support for the workflow patterns may require complicated work-arounds for capturing nontrivial business scenarios.

The report concludes with the some interesting reflections from the authors on how the open source BPM solutions are changing the market:

On the surface, open source BPM solutions seem to offer the end user the answer to their BPM prayers - an innovative, rapidly evolving and cost-effective source of potential solutions to the wide range of BPM-related issues that they are currently facing. However despite the promising outlook offered by the open source BPM community, there are some salient considerations for potential end-users of these offerings

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

What about Intalio? by Joshua Partogi

Why is Intalio not included on the list?

Putting things in perspective by Tom Baeyens

While workflow patterns definitely can give an indication of the control flow capabilities of the process language, the control flow capabilities is just one aspect. Resource patterns and data patterns are two other aspects.

But the two most important aspects are often neglected: embeddability and extensibility.

Workflow and BPM engines are known as monolithic engines. There is typically an API offered to developers to connect to the engine. In some cases, this is desirable, but in most use cases, the business processes and workflows are part of a larger application. In that case, it is crucial that the deployment of the process engine can be embedded straight into the client application. If you look at it, at the core, BPM engines are state machines. That is not rocket science. So there is no reason why BPM engines cannot be deployed straight into the application. This can greatly simplify testability and maneability. This is where we focussed. We have made sure that jBPM is usable both as a standalone server and as a library embedded into an application.

Extensibility means that process constructs should be made pluggable. BPM and workflow languages are usually not general purpose languages. They have a specific target environment and specific use cases in mind. When you go beyond those typical use cases for a specific language, it becomes a lot more difficult to use. That also explains why there is no concensus yet around one process language. They are all too much focussed on a specific environment (like e.g. ESB for BPEL or Java for jPDL) and a specific function.

The Process Virtual Machine is the technology that we've developed and that will serve as the basis for our next generation BPM offerings. It's a base framework in which process constructs can be coded as components. Building a process language is just a matter of implementing the node types. In this way and in collaboration with Bull, we have build already 3 very diverse languages on top of this technology : jPDL, BPEL and XPDL.

Furthermore, the Process Virtual Machine supports all kinds of execution modes:

1) Process executions can just be created and executed by invoking methods on Java objects in memory. E.g. pageflow in SEAM. In this case the Process Virtual Machine does not have any dependencies outside the JVM.

2) You can store processes, executions and history information in a relational database. This is the typical BPM and workflow use case.

3) New will be an execution mode where the process state will be stored as one column in the users domain object. Imagine an Order class. With the PVM, you can deploy the process as a Java resource on the classpath and manage the state of the execution in a memberfield of the Order class. A special hibernate type can store this memberfield as a string column directly into the Order class.

The Process Virtual Machine also runs in any application environments like standard Java (simple web app or spring), enterprise Java, SEAM, OSGi and so on. And it can bind straight into any transaction technology in that environment.

Each process language that is implemented on the Process Virtual Machine inherits all those capabilities.

How many times have I heard "we decided to write our own small workflow engine because we only have limited use for it"... This is only because till today BPM technologies have been hard to use. It required a difficult set up to get going with it. It's because of practical issues that have been preventing ubiquitous adoption of BPM technology. With the Process Virtual Machine and the 3 languages that we're building on top, that is history.


Tom Baeyens

JBoss jBPM

ProcessMaker OSS by Jorge Dollisen

There is also another opensource BPM and workflow software. ProcessMaker OSS ( . You may also want to include it in your review in the future

Re: What about Intalio? by John Mettraux

Joshua, Jorge,

you can read about the selection criteria at the beginning of the evaluation document.

John (

How about YAWL by Nie Hongchao

the language that supports most workflow patterns, at least most control-flow patterns?

Re: How about YAWL by John Mettraux


if you read the document, you'll notice it comes from the same research group that provides us with YAWL.

They played it fair and did not include their own project in the evaluation.


Re: How about YAWL by Nie Hongchao

Dear John
Thank you for replying
I'll just start reading it carefully

Re: What about Intalio? by Jason Woodruff

The Apache ODE project (essentially Intalio) is listed, but doesn't meet the download criteria.
The Intalio product (the community edition certainly would meet download metrics), that uses Ode and Tempo isn't OSS (even though it won a recent OSS award - how confusing is that?). The commercial version is 'open-code' though.
Hope that helps.

More about "embeddability and extensibility" by Pietro Polsinelli

About Mr. Baeyens remarks on embeddability and extensibility, which his wonderful tool JBPM fully supports, in our Teamwork ( you can "embed" your JBPM workflows in a project management context. It was quite easy to do with JBPM.

Take a look at the Imixs Workflow Project by Ralph Soika

The Imixs Workflow Project focus on a different kind of usage. The Imixs JEE Workflow provides Java EE components (EJBs and JPA) to be used in any Java Enterprise project.
These components fit into the component model of Java EE and provide useful functions from a BPM framework.

The Imixs Workflow is not BPM Suite but it enables developers to implement BPM solutions in a much faster way.
See the open source project site:

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

10 Discuss