Today Bonita, Orchestra and jBPM join forces: The Process Virtual Machine !
What is being announced?
This announcement is in fact the result of a collaboration between the leading open source communities, and it will take BPM, workflow, and orchestration to the next level. Red Hat (with JBoss jBPM) and Bull/OW2 (with Bonita and Orchestra) have years of experience with very diverse process languages and engines. The following process languages are currently in the works on top of this single model: jPDL, XPDL, BPEL, pageflow, and threadflow.
Those communities will work together on some common modules, starting by a generic process engine called the Process Virtual Machine, as well as services and process languages extensions.
Does it mean that Bonita, Orchestra and jBPM projects will merge?
No it doesn’t. Bonita, Orchestra and jBPM will share some common modules and extensions that it will leverage on their next version (v4) in different ways.
The main piece of this collaboration is the generic process engine. This process engine is based on the conceptual model called Process Virtual Machine.
The Process Virtual Machine does not define a process language. Instead it acknowledges some process language might be better suited for a certain situation then another and hence, there will be multiple process languages coexisting. The Process Virtual Machine will define a common model that can be shared between all the graph based execution languages.
Bonita and Orchestra version will be based on this generic engine and will add support for XPDL and BPEL standards natively on top. Bonita and Orchestra will also provide a configurable packaging procedure based on the PVM pluggable and embeddable technology together with a revolutionary workflow/BPM graphical tooling based on the eXo WebOS technology.
What was the over all reason for this collaboration?
So we met in Geneva for a full day to explain each other the internals of our workflow/BPM/orchestration engines and look for parts to collaborate.
It turned out that our architectures didn't allow for cherry picking, but we both planned a next version and we had very similar ideas for it. So, rather than reinventing the wheel on each side we decided to join forces and share developments.
Thanks to that we could spent our time on innovation rather than duplicating code and features!
The collaboration turns out to be better than we expected. We are both teams concerned on the same set of issues of traditional workflow and BPM solutions:
- Sole focus on the business analyst.
- Process engines are monolithic systems
- One single, fixed process language
- One single environment
- No easy binding with programming logic
- Lack of mindshare
The challenge was to define a conceptual model for process as flexible possible to be able to build on top embeddable, pluggable and extensible workflow and BPM solutions: The Process Virtual Machine
What are the Process Virtual Machine basics?
The main concept is to have a generic runtime engine implementation, with a component model for implementing process constructs. Very similar to Microsoft Workflow Foundation. Then we could build the process languages on top as a set of process construct implementations.
That concept is what we called The Process Virtual Machine : The full article can be found
here and
the onjava article is a shorter version of it.
We can already implement 4 languages BPEL, jPDL, XPDL and SEAM Pageflow on top of this single core engine. Those languages extensions will be leveraged afterwards by Jboss and Bull in three projects: Jbpm, Bonita and Orchestra.
Where will be hosted the results of this collaboration?
A large part of our engines will be a shared codebase hosted partly at JBoss and partly at OW2.
As agreed between both sides, the Process Virtual Machine kernel and services will be hosted at Jboss repository (under the Jbpm project). Both XPDL and BPEL extensions will be in the OW2 consortium repository (under Bonita and Orchestra projects svn respectively)
What sorts of workflow specifications did you agree upon?
We agreed on the Process Virtual Machine, the set of concepts. That is the base layer for building process languages. We are jointly developing that base layer. Also in the process language implementations we are collaborating, though each of us has got our own expertise that we leverage.
The second step will be the Process Virtual Machine standardization. Indeed there is no Java JSR on workflow or BPM and, as Java is the native language for the Process Virtual Machine, this is a natural move. The main objective is to create mindshare on workflow and BPM in the Java World.
How this will change the Workflow and BPM landscape?
In the short to mid term, we'll see a consolidation phase in workflow and BPM technology. There are various flavours of workflow, BPM and orchestration. Also there are different environment. E.g. an ESB is a very different environment from a POJO lightweight Java web application.
So we recognize that there is a need for different process languages. Most engines (all except for MS's workflow foundation) are build around 1 single process language. That is why their applicability is limited to only a niche. With the Process Virtual Machine technology, we put all of those on the same page.
We think that we are definitely equipped to compete in the long term. Cause we can add whatever process language is hyped next more easily. With this multi-language approach, we're able to cover a much broader market with one single technology.
What are the short term goals?
Developers will add the basic concepts explained in the Process Virtual Machine to their repertoire. That way, they'll know better when to use workflow, and what kind of responsibilities it can better then the do-it-yourself style.
This framework also allows for companies to develop their own dialects of process languages. We see very often that e.g. for approvals in a document management system or for e.g. describing experiments with samples in a laboratory, people want to develop a customized version for describing their processes. A dialect that is easier to use by their analysts.
What are the mid term goals?
As one of the objectives of the Process Virtual Machine is to create mindshare for developers as well as inside the workflow and BPM market as a whole, we are really open to other big names in this industry to join.
Most of the well known BPM/Workflow vendors have monolithic solutions based on one language. These solutions must be extended often in order to fit new particular uses cases (i.e adding an extension to the BPEL language in order to support human interaction). This end up with complex implementations, difficult to maintain, and even not adapted in some cases.
We see some of those companies to be interested on the Process Virtual Machine concepts/technology in a near future and this is what "communication" and "awareness" around the Process Virtual Machine is important.
