New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Open source workflow engines compared: jBPM, OpenWFE and Enhydra Shark
Posted by Gavin Terrill on Aug 08, 2008
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
- This article is part of a featured topic series on SOA
- See more SOA content at: http://www.infoq.com/soa
- Other recent content items in this topic
What about Intalio?
by
Joshua Partogi
Posted
Re: What about Intalio?
by
John Mettraux
Posted
Re: What about Intalio?
by
Jason Woodruff
Posted
Putting things in perspective
by
Tom Baeyens
Posted
ProcessMaker OSS
by
Jorge Dollisen
Posted
How about YAWL
by
Nie Hongchao
Posted
Re: How about YAWL
by
John Mettraux
Posted
Re: How about YAWL
by
Nie Hongchao
Posted
More about "embeddability and extensibility"
by
Pietro Polsinelli
Posted
Take a look at the Imixs Workflow Project
by
Ralph Soika
Posted
-
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
10 comments
Watch Thread Reply