Tom Baeyens on the Process Virtual Machine

With the latest alpha release of the jBPM Process Virtual Machine, JBoss moves closer to realizing the vision of a process execution engine that supports multiple definition languages. The release also marks an increase in interest in jBPM, which has recently provided an updated website. InfoQ spoke with project lead Tom Baeyens about the project, and how the PVM changes the BPM landscape.

InfoQ: Can you give InfoQ readers some background on the history and purpose of the PVM concept?

Tom: The Process Virtual Machine is the finalization of the core concepts that we have been exploring in jBPM.

jBPM started with a single process language called jPDL, but soon after becoming part of JBoss, users were asking if we could also support BPEL. That's when I realized that a lot of the jPDL implementation overlaps with BPEL. Since then, we have worked on extracting the common parts from the process language specific parts.

jBPM 3 already has all the concepts worked out and it runs multiple process languages like jPDL and BPEL natively. But the downside is that it's still one big codebase, not really modular. As the BPM and workflow landscape is completely fragmented, the need for multiple process languages becomes more and more obvious. So we needed a more modular approach.

That is where the Process Virtual Machine comes in. It's a library for building and executing graphs. Native implementations of process languages can be build on top of the Process Virtual Machine. Furthermore, it runs inside of any Java environment, be it standard Java, enterprise Java, SEAM or Spring.

InfoQ:  Why is this important?

Tom: On the one hand, the landscape of Business Process Management (BPM) and workflow is completely fragmented. There are many different types of process languages that all have a specific set target use cases and target environment. It's like with Domain Specific Languages (DSL); there will not be one language to rule them all. Currently all these languages come with their own monolithic engine, which is not practical and they are hard to integrate into an application.

The Process Virtual Machine provides a simple unified structure to run all of these process languages on one core technology.

On the other hand, the Java landscape is fragmented as well. In contrast to the traditional process engine that must run in isolation on a separate server, the Process Virtual Machine can run integrated inside of your application, whatever Java environment. This significantly lowers the threshold for projects to adopt process technology since the process persistence can be transparently integrated with the application persistence.

InfoQ: Will application developers work with the Process Virtual Machine itself?

Tom: Most application developers will not work with the Process Virtual Machine itself, but rather with one of the process languages that are build on it like jPDL, BPEL or XPDL.

But it will be important for application developers to know the basic concepts of the Process Virtual Machine. Just like developers know about the basic concepts of tables, columns, primary keys and SQL queries to work with relational databases, they will know the Process Virtual Machine concepts like a process definition, an execution execution and asynchronous continuations. Tom: Indeed Bull collaborates with us on the Process Virtual Machine. They are contributing to some base functionalities in the Process Virtual Machine and driving the BPEL and XPDL activity implementations. There are other companies in the pipeline, but regrettably we can't talk about those yet. But we see clear signs that the Process Virtual Machine will be a consolidating force in the BPM landscape for Java. Tom: The confusion that currently exists around analysis, implementation and service orchestration. We see three clear separate use cases for applications of the Process Virtual Machine. Let's discuss them and highlight which process languages are most applicable for each of the use cases:

1. Analysis to implementation: This is the main use case targeted by pure-play BPM Suites today. Starting from an analysis diagram and turn that into executable software. Many traditional vendors try to hide the crucial distinction between analysis process diagrams and executable processes with a lot of magic.
   
   The clue is that the diagram serves as an important instrument in the communication between non technical people who are responsible for requirements and technical people who are responsible for the automation. But in general, no technology will be able to produce production-ready software from only input of non technical people.
   
   To make that collaboration work between analysts and developers, the executable process language must be flexible enough to fit right onto the analysis diagram. Feature like customizable activity implementations and event listeners are crucial to make sure that the analyst still recognizes the diagram after it's been made executable. jPDL excels in that purpose. It also provides a clean integration with Java technologies and a compact, readable XML grammar that developers like. XPDL also supports this use case. XPDL's grammar is more verbose and less readable, but it is more portable as slowly but steady, more vendors are adopting this standard.
   
   
2. Asynchronous Java architectures: To work with asynchronous architectures, Java doesn't really provide attractive solutions. In fact, it's a big mess.
   
   On the one hand, there is the enterprise platform with JMS for asynchronous messages and EJB Timers. Those are very low level constructs and you need a lot of deployment descriptor mess in place to support a long running process. And even then, the overview of how things are connected is completely lost. With jPDL, the overview is clearly visible and hot redeployment is easy as pie. Just reconfigure transitions in a diagram graphically and redeploy instead of messing with enterprise deployment descriptors for a couple of hours.
   
   On the other hand, there is the standard Java platform where there is absolutely no support for asynchronous architectures. jPDL integrates very closely with standard Java and it leverages the job executor from the Process Virtual Machine to deliver asynchronous continuations and timers.
   
   So now, because of the basic Process Virtual Machine infrastructure, one single jPDL process can capture the asynchronous orchestration of people, Java code and other goodies and make that logic portable between standard and enterprise Java environments.
   
   
3. Service orchestration: BPEL is the well accepted and supported standard for service orchestration. It operates on the level of the Enterprise Service Bus (ESB) and hence it is an integration technology. A BPEL process can (oversimplified) be thought of as a scripting language on web services level. WSDL services can be scripted into coarser grained services with BPEL.
   

InfoQ: Where can readers find out more about the PVM?

Tom: First of all, there will be a jBPM Community Day in Dublin on June the 6th. This is an excellent opportunity to connect with the core jBPM developers, partners, clients and other people that are just looking to hear more about it. It's a free event and it's just a Friday afternoon. For more information, check the jBPM Community Day wiki page or send an email to dublin@jbpm.org.

Secondly, for the impatient, there is the PVM manual that explains already step by step how to build activities and start playing with it.

Last, there is also the InfoQ article "Process Component Models: The Next Generation In Workflow ?" which was published recently and gives a more background about this topic.