BPEL Compared To jPDL

Michael Neale of the drools team is giving a Talk on JBoss jBPM for the Canberra User Group. He mentioned my <sarcasm>*looooove*</sarcasm> for BPEL and asked me the pitch. In my reply, I explained that I don't think BPEL is bad, but that you have to know when to use it and when other alternatives are more appropriate. I think my reply would be interesting for more people, so I share it here.

BPEL is a process language designed to work on in a web services environment because it is based on WSDL. WSDL could potentially map to java beans as well, but it naturally maps to web services, while WSDL doesn't map naturally to java beans.

Deploying a BPEL process leads to publishing of a web service (a WSDL service to be exact), that is your interface to the process. Internally in a bpel process, the process variables are XML snippets (or xsd basic types). BPEL has some control flow constructs and a construct to invoke a WSDL service. So in essense, BPEL is in fact a language to script a new web service as a function of other web services.

BPEL has a receive construct, which means wait here until this message is received over the published service. This implies that the overall execution behaves as a wait state. Consequently, long running (spanning multiple server side transactions with long periods inbetween) processes can be expressed in BPEL.

Expressing long running processes (== support for wait states) is a requirement to model typical business processes in a language. Business processes like handling an insurance claim take a long time and involve several requests to/transactions on the server. So to support business processes, the runtime engine needs to behave as a kind of state machine. While BPEL has the wait state feature, which is one of the requirements for executing business processes, the assumption of an all-web-services-world makes it hard to integrate BPEL based business processes with every day software development in e.g. Java.

The thing that nobody seems to understand is that you can build state machines in Java as well. And typically much more simple then in web services technologies. That is where jPDL fits in. In jPDL the interface is a Java API and the process variables are POJO's. So this language embeds far better in a Java project.

Conclusion is not that BPEL is bad. The conclusion is that you need to select the process language that fits with the environment in which you are working and with the requirements you have. Use BPEL if you want to script new web services as a function of other web services in a mostly webservices environment. Use jPDL if you need statemachine capabilities in a Java environment. In both technologies it is possible to make the bridge to the other side, but that is of course requires some mappings and translations. So it is all a matter of selecting your process language based on the main development environment.