What to look for when BPEL 2.0 becomes available for public review

The BPEL 2.0 specification is approaching it public review period. Will it live up to expectations? I’ve encountered people with some very different expectations of the 2.0 specification. Some expect it to have expanded greatly in scope compared to BPEL 1.1. For example, more than once I’ve heard that “BPEL 2.0 addresses human workflow”. People with these expectations may at first find themselves disappointed with the new specification. It has stayed true to the spirit of BPEL 1.1; you’ll be hard pressed to find new features in to BPEL 2.0.
However, don’t be put off by the fact that the table of contents remains almost unchanged. BPEL 2.0 represents a significant improvement and is perhaps a perfect example of what a standards body such as Oasis can do for a specification. Rather than taking off in a new direction, the working group have conducted a root and branch review of the specification. In every area, clarifications and corrections have been made, providing a much more concrete and precise specification.

Here are some of the things that are worthy of special note:

Extensibility
Specifications must specify extension mechanisms to facilitate use cases which are beyond the original scope. This is easier said than done: rules for the location and semantics of extensibility items must be specified. Significant improvements have been made to ensure that the extensibility mechanisms work in practice. The most obvious is the syntax for including expressions. This has changed to allow languages such as XQuery to be used in addition to XPath. An extensionActivity has also been introduced to allow vendors to introduce new activities to the language in a way which won’t break other vendors’ tools.

Data Manipulation
Data manipulation in BPEL 1.1 was deliberately limited – business process modelling is not the appropriate place to perform complex data manipulation. However, in some situations these limitations proved to have been a step too far. After some debate on how to rectify this situation, the ability to perform XSL Transformations was added to BPEL and as mentioned above, the extensibility mechanism has been enhanced to ensure that XQuery can also be used. The decision not to reinvent the wheel was a wise one.

Relationship to other specifications
One of the problems with the BPEL 1.1 was that its relationship to other specifications was not defined precisely. For example, a lack of details in relation to XPath meant that the $ syntax in XPath could not be used to reference variables. XML Schema and WSDL are used to define date types and interfaces, but BPEL was left without an import statement by which to reference such files. These issues have been resolved, ensuring that BPEL builds appropriately on the other Web service specifications.

New activities
Ok, so there are a few new activities, generally aimed at completing features in BPEL 1.1
rethrow – rethrows a fault which has been caught.
terminationHandler – executed on a scope after forced termination.
forEach and repeatUntil – provide alternative looping constructs to while
validate – used to validate the contents of variables against their schemas
compensateScope – used to compensate a named scope.
Some existing activities have been renamed – switch becomes if, terminate become exit.

Existing Activities
In every activity you will find small changes, some of which will change the style of BPEL you write. For example, receive, reply and invoke can now copy variables directly into message parts, instead of requiring you to use a variable defined using message declaration in the WSDL. In BPEL 1.1 all variables were usually declared using message types requiring that values be copied from one message to another. This practice may go away in BPEL 2.0 resulting in more concise scripts.

Summary
BPEL 2.0 provides immediate benefits to vendors implementing BPEL engines. The many improvements in the specifications represent the experience gained from implementing BPEL engines. Users may find it an easier language to develop, but the real benefits may come later as the extensibility mechanisms allow BPEL to be integrated closely with other languages and environments.

ESB Deathmatch

The ESB Roundup at InfoQ is proving to be an interesting discussion. This is an effort to get the various ESB vendors to better define the product category. It was originally conceived as an ESB "Deathmatch", let's hope no one gets hurt.

SOAP verses REST at ApacheCon

I recently attended ApacheCon Europe which was in Dublin, so it was just down the road from us at Cape Clear. One of the sessions that I found particularly interesting was Slicing and dicing REST with Apache Cocoon. Cocoon is a framework for XML over HTTP with some really nice features. It was no surprise that the presentation started with a comparison of SOAP with REST. Of course, the technical differences have been well rehearsed at this stage, with both sides often declaring victory. There are many similarities between two, which has lead to much debate over which to use in different circumstances. However, it occurs to me that all the best examples of REST involve a human as the end user, either through a browser or a mobile device. That’s because “reliable enough” is perfectible acceptable once there’s a human in the loop, especially given the other advantages of REST. However, for application to application communication, guarantees of delivery and traceability are required. With REST you get the QOS provided by HTTP, SOAP builds on it to provide a higher QOS. If you’re ever tempted to put a retry loop into your REST client just in case the HTTP connection is refused, then you need to face up to the need for SOAP (with WS-RM of course). On the other hand, don’t go building a light weight SOAP stack for use in devices; it’s just too close to the end user.