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

Why is Intalio not included on the list?

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.



regards,

Tom Baeyens

JBoss jBPM

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

Joshua, Jorge,



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



John (openwferu.rubyforge.org)

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

Hongchao,



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.



John

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

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.

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

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: www.imixs.org