Programming constructs in BPEL

Part 3: BPELJ and Compensation

The first thing to note in this script is the two attributes for the whole process at the start. These are used to define the default expression language (which in this case is Java) and the default package (bpelj:package="com.regdev.example") that should be used with any emebedded Java code within the script. That is, all Java code should be considered to be part of the com.regdev.example package.

Next, note that the <partnerLinks> section includes a partner link to a "lookup" resource. This is actually a Java class, such as an EJB, that will be used elsewhere within the script.

In the variables section, a new variable message is defined as a type defined by a class TextMessage within a package com:.regdev.

Later in the script, a Java snippet can be seen. A Java snippet contains valid Java expressions or statement blocks. These blocks are embedded in a BPEL process definition and have access to certain variables defined within the execution space of the script (in a similar manner to the way in which JSPs can contain embedded Java code that can access certain variables within a JSP).

Finally, an invoke section illustrates how a method is invoked on a Java class. In this case the method checkRegistration on the class indicates by the partner link referenced by BookLookup (i.e. com.regdev.BookLookup). The method checkRegistration takes two parameters a (book) title and an isbn.

BPELJ - is this the right answer?

In an earlier column, I indicated that BPEL represented Programming in the Large, whereas programming languages such as Java represent Programming in the small. I am left wondering whether there's a fundamental dichotomy between the two approaches. Is it really appropriate to define business functions in Java within a BPEL definition? Does this promote the flexibility claimed for BPM and the use of BPEL?

If we look at the implementation of BPELJ, I'm again left wondering about the success of the final result. The intention, as mentioned earlier, was to use the strengths of both to provide something that is more than the sum of its parts. However, we end up with a syntax that is less than "clean", in my opinion, as a programming language (notably, a criticism I've also been levelling at JSPs for years). Embedding Java within BPEL Java snippets might work well if there was a development tool hiding the details, but in its raw form it's hamstrung by embedding it in an XML-based pseudo-programming language.


The idea behind compensation is that in any long running business process, situations may occur in which it's necessary for the whole business process to be terminated tidily. However, within such business processes, the systems being integrated tend to be asynchronous in nature. They may represent both new and legacy applications, may or may not have the ability to rollback any side affects of any services executed etc.

In such situations, when a business process must be terminated, it may be necessary to communicate with one or more systems that have previously completed their activities, in order to tell them to undo what they've done. The goal of compensation is to support the reversal of the effects of previous activities that have been carried out as part of the process now being terminated.

Compensation overview

Having read the introduction, perhaps you are thinking, so what exactly is compensation? I find it useful to think of compensation being used in the following scenario for a holiday booking business process:

To book a holiday we might create a business process that defined three specific steps:

  1. Booking a hotel
  2. Booking a hire car
  3. Booking a flight

In such a scenario compensation behaviour might be defined for each of these steps such that if the hotel and the hire car are booked but a flight cannot be found then the hire car and the hotel booking can be undone - this undoing process is compensation.

In practice, compensation has two parts a compensation handler and a compensate activity. A compensation handler is associated with a "scope". A scope is a container and context for other activities (you might considered it to be analogous to a {}block in Java). For example, the "Booking a Hotel" step above could be a scope. Indeed, the above example could be considered to have three scopes, one for each booking. Thus, each scope would have its own compensation process defined for it. The compensation process is referred to as the "compensation handler" and defines how the compensation is implemented (i.e. how the undo behaviour should be performed).

The compensation handler can also be invoked indirectly by a compensate activity. When this happens the compensation handler is invoked on an inner scope activity that has already successfully completed, and it can be invoked only from within a fault handler or another compensation handler.

Sponsored: Driving business with continuous operational intelligence