Open source workflow engines compared: jBPM, OpenWFE and Enhydra Shark
- Share
-
- |
Read later
My Reading List
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
Putting things in perspective
by
Tom Baeyens
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
ProcessMaker OSS
by
Jorge Dollisen
Re: What about Intalio?
by
John Mettraux
you can read about the selection criteria at the beginning of the evaluation document.
John (openwferu.rubyforge.org)
How about YAWL
by
Nie Hongchao
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.
John
Re: How about YAWL
by
Nie Hongchao
Thank you for replying
I'll just start reading it carefully
Re: What about Intalio?
by
Jason Woodruff
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
Take a look at the Imixs Workflow Project
by
Ralph Soika
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
Educational Content
Clojure in the Field
Stuart Halloway May 23, 2013
Tuning the Size of Your Thread Pool
Kirk Pepperdine May 23, 2013
Hello stranger!
You need to Register an InfoQ account 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