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

Posted by Gavin Terrill on Aug 08, 2008 02:56 PM

Community

Architecture,

Java,

SOA

Topics

Business Process Management

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

1. Back to top

   What about Intalio?

   Aug 8, 2008 9:03 PM by Joshua Partogi

   Why is Intalio not included on the list?

   Reply

2. Back to top

   Putting things in perspective

   Aug 9, 2008 7:45 AM 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.
   
   regards,
   Tom Baeyens
   JBoss jBPM

   Reply

3. Back to top

   ProcessMaker OSS

   Aug 9, 2008 8:43 AM by Jorge Dollisen

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

   Reply

4. Back to top

   Re: What about Intalio?

   Aug 9, 2008 9:01 AM by John Mettraux

   Joshua, Jorge,
   
   you can read about the selection criteria at the beginning of the evaluation document.
   
   John (http://openwferu.rubyforge.org)

   Reply

5. Back to top

   How about YAWL

   Aug 9, 2008 11:44 PM by Hongchao Nie

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

   Reply

6. Back to top

   Re: How about YAWL

   Aug 10, 2008 3:23 AM by John Mettraux

   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

   Reply

7. Back to top

   Re: How about YAWL

   Aug 10, 2008 7:34 PM by Hongchao Nie

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

   Reply

8. Back to top

   Re: What about Intalio?

   Nov 5, 2008 8:36 AM 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.

   Reply

9. Back to top

   More about "embeddability and extensibility"

   Feb 5, 2009 6:21 AM by Pietro Polsinelli

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

   Reply

• Older >