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?

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.

InfoQ: Bull has now joined with JBoss to support the PVM concept - are you working with any other partners?

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.

InfoQ: What have been some of the major challenges you have had to overcome so far?

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:

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.

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.

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.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.