Let's perform the following steps of instructions to construct the book order process. First of all, let's create a new asynchronous BPEL 2.0 process named Book_Order_Process. We illustrated the process to create an asynchronous BPEL in Chapter 5, Interaction Patterns in BPEL. Perform the following steps:
- Drag-and-drop a
<scope>activity from the BPEL constructs palette in between the receiveInput and callbackClient activities. Name the<scope>activityregisterBookOrder. - Drag-and-drop an
<empty>activity to this<scope>activity, and name itdummyRegisterBookOrder. This is used to model the tasks related to book order registration, such as creating an entry in the order management system. - Now we will add a compensation handler to this
<scope>activity. Click on the Add Compensation Handler icon on the scope, and it will create<compensationHandler>within the<scope>activity:
- Now the
<scope>activity looks as follows. Make sure to click on the + mark if you do not see the menu on the left:
- Let's add the compensation logic into
<compensationHandler>. For demonstration purposes, we will add a<wait>activity with a 30-seconds break, so the user can monitor the status of the process before compensation starts. Drag-and-drop a<wait>activity inside the compensation handler and configure it to have a 30-seconds interval, as follows.
- Drag-and-drop an
<empty>activity after the previously added<wait>activity. Again, this<empty>activity is for demonstration purposes, so it represents the compensation logic to be executed. After this step, we finished addingregisterBookOrder, the<scope>activity that models the book order registration. The scope looks as follows:
- Likewise, we need to add an adjacent
<scope>activity to model the credit card transaction. Repeat the steps from 1 to 5 to create a<scope>activity namedinitiateCreditCardTransaction. The outcome is as follows:
In the previous section, we created two scopes named registerBookOrder and initiateCreditCardTransaction, which model the book order registration process with <compensationHandler>. For demonstration purposes, we didn't add actual implementation specific activities; rather, we added <empty> activities and the <wait> activities in each <compensationHandler>, so the user can monitor the state of the BPEL process.
When it comes to a BPEL process, it consists of a set of activities. We can generally categorize these activities into a set of units of works. The units of work can either be one activity or a set of activities. These units can also be called transactions, which are either executed or compensated as a whole due to an unexpected behavior.
Let's understand this by looking at a simple example. In the sample BPEL process in this chapter, we can consider the two scopes, registerBookOrder and initiateCreditCardTransaction, as a single transaction. This is because if the credit card transaction (the scope named initiateCreditCardTransaction) fails, we need to roll back the book order registration (the scope named registerBookOrder) as well.
In enterprise systems, such transactions are handled with the ACID distributed transaction model. ACID stands for atomicity, consistency, isolation, and durability. This model defines a transaction model that uses data locking and isolation. Such a model works perfectly well in trusted domains within enterprise. Also, it expects the transactions to be relatively short.
However, when it comes to business processes, they are typically long-running processes, sometimes several hours and sometimes several months. Also, they interact with loosely coupled partner web services. In such situations, the ACID distributed transaction model cannot be applied efficiently because locking certain data for such a long time will affect the performance of the system.
In business processes, compensation is used instead of ACID transactions to reverse the effect of unfinished processes. Compensation requires the user to specify reversing activities that can be invoked if it is necessary to undo the effect of an activity. WS-BPEL 2.0 supports specifying compensations for a specific <scope> activity or an <invoke> activity.
Compensation enables a BPEL developer to undo already completed <scope> and <invoke> activities by means of invoking activities that model the opposite behavior. For example, in order to compensate the credit card transaction, one is required to deposit the same amount back to the credit card.
If we compare <faultHandlers> and<compensationHandler>, we see that they both address a somewhat similar issue. Both define an activity to be triggered to handle an exceptional situation. However, what <faultHandlers> does is act upon error messages or other exceptions returned by partner web services and exceptions thrown from the BPEL process and runtime. The thrown fault is caught by <faultHandlers> and is acted upon accordingly. So, <faultHandlers> tries to recover from an activity that did not finish normally. However, a <compensationHandler> tries to reverse an activity or a set of activities that was successfully finished as part of a business process that is being abandoned.