Programming constructs in BPEL
Part 3: BPELJ and Compensation
What compensation is not
So having indicated that compensation is essentially like an undo facility for BPEL, let us now consider what it is not. It is not an exception handling or fault handling mechanism. It is also not an exception handling mechanism (this is worth saying, as a scope looks a bit like a try block within Java - at least conceptually). A suitable analogy might be that if you are using an editor and undo some operations; this is because you have decided to take a different course of action - not because the editor has generated an error.
Indeed, you'll find that BPEL also includes the ability to catch and handle errors at different levels of activity nesting. A fault handler can be defined on any scope and either bound to a particular kind of fault (defined by the fault's qualified name - a bit like an exception, or its message type) or to any faults not caught by a more specific handler. A handler simply contains an activity that will run in case an error occurs. For example, it might contain a reply activity that notifies a partner that an error has occurred.
This makes it clear that Compensation is not error handling - it is what should happen when I want to roll back some activities within the overall business process. I use the term roll-back here - but also do not want to imply that this is some form of distributed transaction rollback - instead, you have to decide what happens to undo any effects of what has gone before. There is nothing automatic in this, there is no DBMS handling the rollback.
In the overview of compensation, I introduced the idea of a holiday booking BPEL script that allowed hotel, hire car and flight bookings to be made. The following BPEL extracts illustrate how these scopes might be defined with compensation being provided to facilitate undoing some element of the booking process if one element fails. For example, the following scope defines a sequence for booking a hotel room and a compensation handler that can be invoked if required:
<scope name="BookHotel"> <!-- define a compensation handler --> <compensationHandler> <!-- call cancel ticked --> <invoke name="Invoke_CancelBooking" partnerLink="HotelBookingService" portType="hotel:hotelBooking" operation="cancelRoom"/> </compensationHandler> <sequence name="Sequence_1"> <invoke name="Invoke_BookRoom" partnerLink="HotelBookingService" portType="hotel:hotelBooking" operation="reserveRoom"/> </sequence> </scope>
The compensation handler in the above cancels a hotel room that has previously been booked by the service called by this step in the BPEL script.
The following scope defines what happens when we try to book seats on a flight to go along with the hotel room bookings. In this case, a sequence is defined to book the seats, but associated with it is a fault handler that is invoked when no seats are available for the selected dates.
<scope name="BookFLight"> <faultHandlers> <catch faultName="flight:NoSeatsAvailfault" <throw name="cancelBooking" faultName="client:cancelBooking"/> </catch> </faultHandlers> <sequence name="Sequence_2" <invoke name="Invoke_BookFLight" partnerLink="airline" portType="ReservationSystem" operation="bookSeats"/> </sequence> </scope>
In the above code, a catch block is defined to catch the specific fault and throws itself a cancelBooking fault to the parent scope. That will trigger the compensation we have defined earlier.
The last part is to define a catch block on the parent scope, that triggers in case of a cancelBooking fault and fires the compensation defined on the BookHotel scope.
<faultHandlers> <!-- catch the rollback fault and call --> <catch faultName="client:cancelBooking"> <compensate name="CompensateBoookings" scope="BookHotel"/> </catch> </faultHandlers>
Sponsored: Today’s most dangerous security threats