Programming constructs in BPEL

Part 3: BPELJ and Compensation

Compensation - what does it really mean?

So, where does this leave us with Compensation - it is not exception handling and it is not fault handling. However, it is closely related to both concepts, as the above example illustrates. It is an explicit way of representing how we recover from a problem or failure situation; but it is not automated state rollback; nor is it error recovery.

It should also be noted that compensation is not ACID compliant. ACID (or Atomicity, Consistency, Isolation, Durability) is a set of properties that guarantee that a single logical operation is processed reliably to completion or not at all. The term itself is most often used in the contact of database systems. So what do I mean when I say Compensation is not ACID compliant? Well, I mean that compensation does not guarantee any of the core concepts of ACID. Indeed, you can do anything you want within a compensation handler and that "anything" might intentionally not undo the effect of running the associated service.

As an example, consider how you might compensate in a business process for an activity that cannot be easily undone. For example, in a telecommunications environment part of the business process might have been to send an engineer out to install some new hardware. Undoing this may not be cost effective or indeed useful. Thus, the newly installed device may be left where it is.

As another example, if a payment has been made to a third party as part of the business process, you cannot just undo that payment - rather some alternative course of action may be required, such as requesting a credit note or a refund etc.

Of course, compensation was never intended to be based around ACID concepts - as that is not what compensation is about - however, it means that compensation could be very dangerous from a software engineering point of view. Remember, compensation itself does not guarantee anything about the state of the system before or after the compensation activities have executed, it does not guarantee consistency of the resulting data etc.

As an example of the complexities facing a developer working with compensation, consider the how difficult it to test all possible failure modes and paths through the compensation handlers in a large complex system, in order to ensure the resulting overall system state is coherent? I suspect this could be a very difficult task. Taking this further, how difficult is it to actually implement the compensation correctly in the first place? The above example made it look conveniently simple, but in reality it could be much more complex.

My biggest worry is that compensation may provide a nice warm feeling to system designers: that they can use compensation to solve all their problems. Then, not enough thought might go into the actual compensation process, the testing of these processes and their interactions.


In this final column on BPEL, we've looked at two of the more controversial (in my opinion) areas of BPEL and attempted to consider what they can do and why they may or may not be the right answer to the problem they are trying to address. How they develop in future version of BPEL will, I think, reflect the industry's experience with using them. Currently, both compensation and BPELJ have ardent supporters and vociferous detractors – personally, I'm sceptical of both. ®

Online References

BPELJ White Paper:

IBM BPELJ: BPEL for Java technology:


Sponsored: 10 ways wire data helps conquer IT complexity