OASIS BTP

As mentioned earlier, a typical business activity spans several independent organizations. Implementing a transaction that requires ACID properties to be satisfied may not be possible in such cases, as a single transaction could last for hours or even days together. It may not be possible to hold locks on the participants’ resources for such a long duration. OASIS has defined a protocol called BTP (Business Transaction Protocol) that allows the coordination of business transactions spanning multiple participants. The transaction ensures consistency irrespective of the disparate applications running on different technologies deployed at different organizations. As it is not possible for a single controller to hold the resources belonging to different organizations, each participating organization is responsible for making a commitment required by a business transaction. The requester assumes that the party who has committed a portion of a business process will honor its commitment whenever asked to do so and accordingly proceeds with the outer business transaction. The requester or consumer may commit or cancel the request at a later time. The provider honors the earlier commitment, or it cancels all the operations by undoing whatever was done earlier as a part of the commitment, if it receives a request for canceling the transaction. This is depicted in the following figure:

In the above diagram, the consumer requests a service from a provider(s) by sending a service request message. The consumer may request the provider(s) to participate in a transaction. The provider(s) send a response to the consumer agreeing to participate in the specified transaction. Each participating provider agrees to participate in a transaction in the manner specified by the consumer.

At a later time in the business process, the consumer sends either a confirmation or the cancellation to the participating providers. In the case of a confirmation, the providers would commit their respective commitments to complete the transaction and acknowledge to the consumer. In the case of cancellations, the provider may run a compensating transaction to reverse the internal changes made.

BTP defines a protocol for achieving a business transaction that involves disparate applications.

The BTP Stack

The BTP stack is shown in the following figure:

At the bottom of the stack we have transaction management. This consists of typical TP (transaction processing) monitors consisting of one of several popular technologies. This may be an IBM Mainframe running CICS, CORBA transaction services, or Java EE transaction services, and so on. These services essentially provide ACID transactions and typically run at a single location.

Above this layer, we have commitment management. This consists of web services that use XML-based protocols. We have already studied the different transactional commitment specifications used by web services. The commitment management layer is responsible for providing support for atomic and non-atomic transactions. Non-atomic transactions are those that may require a compensating transaction to be run in case of a rollback. Web Services transactions and business activity protocols are implemented at this layer.

At the top, we have a layer for business process management. At this layer, the business processes defined using BPEL are executed.

The BTP Model

BTP defines a model for transactions that typically involve multiple participants over the Internet. The protocol:

• Addresses how to handle errors and communication failures over a channel
• Coordinates between multiple applications and provides a way to define the business activity workflow
• Supports loosely-coupled systems and both synchronous and asynchronous calls
• Provides for long-running transactions with support for running compensating transactions in case of failures

The model defines two types of transactions:

• Atomic
• Cohesive

Atomic Transactions

An atomic transaction requires one coordinator with zero or more sub-coordinators. Each coordinator is responsible for managing one or more participants within the transaction. The outcome of the transaction is atomic, that is either all participants confirm or all cancel. You must already have a fair idea about atomic transactions from the Web Services Transactions section in this chapter.

Cohesive Transactions

In a cohesive transaction there can be multiple sub-transactions. Some of the participants may confirm while others may cancel. The cohesive coordinator ensures output consistency by sending appropriate requests to the participants based on its agreement and interaction with the originator. Thus it has more complex functionality than an atomic coordinator.

Having seen the coordination and transaction specifications, we will now look at the specifications that allow reliable messaging. Reliable messaging is required for guaranteeing coordination between multiple parties in a distributed transaction.