The Business Transactions Protocol, Page 2
Therefore, structuring certain activities from long-running transactions can reduce the amount of concurrency within an application or require work to be performed again. For example, there are certain classes of application where it is known that resources acquired within a transaction can be released "early", rather than having to wait until the transaction terminates; in the event of the transaction rolling back certain compensation activities may be necessary to restore the system to a consistent state. Such compensations will typically be application specific.
The Business Transaction Protocol
Business-to-business (B2B) interactions may be complex, involving many parties, spanning many different organisations, and potentially lasting for hours or days, e.g., the process of ordering and delivering parts for a computer which may involve different suppliers, and may only be considered to have completed once the parts are delivered to their final destination. Unfortunately, for a number of reasons B2B participants simply cannot afford to lock their resources exclusively on behalf of an individual indefinitely, thus ruling out the use of atomic transactions. Therefore, the BTP effort has attempted to provide a solution to this by defining a new transactional model specifically for web services. It is important to realise that the term "transaction" in this sense does not mean atomic transaction, though ACID semantics can be obtained if required.
Consensus of Opinion
In general a business transaction requires the capability for certain participants to be structured into a consensus group, such that all of the members have the same result. Importantly, different participants within the same business transaction may belong to different consensus groups. The business logic then controls how each group completes. In this way, a business transaction may cause a subset of the groups it naturally creates to perform the work it asks, while asking the other groups to undo the work.
For example, consider the situation shown in Figure 2, where a user is booking a holiday, has provisionally reserved a flight ticket and taxi to the airport and is now looking for travel insurance. The first consensus group holds Flights and Taxi, since neither of these can occur independently. The user may then decide to visit multiple insurance sites (called A and B, in this example), and as he goes may reserve the quotes he likes. So, for example, A may quote $50, which is just within budget, but the user may want to try B just in case he can find a cheaper price, and without losing the initial quote. If the quote from B is less than that from A, the user may cancel A, while confirming both the flights and the insurance from B. Each insurance site may therefore occur within its own consensus group. This is not something that is possible when using ACID transactions.
Figure 2: Flight-booking.
The BTP consortium began by examining the experiences gained by using transactions in closely coupled environments such as CORBA and comparing and contrasting with the loosely coupled world of Web Services. They concluded that:
- Transaction information must be communicated in XML documents. How these documents are propagated is left up to the application, e.g., email or HTTP. All that BTP mandates is the format of the transaction payload, leaving it to users to define how to get it from end-point to end-point.
- Consensus between participants is extremely useful. Unfortunately, atomic transaction systems typically tie the two-phase commit protocol, which is intended purely for consensus with the requirement to retain locks and persistence for resources.
- Typically applications possess an initial (preparatory) phase, where resources are acquired on behalf of a specific user or business transaction and then either a cancellation or confirmation stage, which may come at an arbitrary time after the initial phase. Although this two phase approach may appear similar to that possessed by atomic transactions there is are important differences: (i) the cancellation stage does not imply backward compensation, as it does in atomic transactions: a participant may use forward compensation, (ii) the reservation stage does not guarantee that resources acquired will be available for confirmation later, and there may be an explicit or implicit time "confirm-by" period indicated when making the reservation.
- Multiple participants may find themselves in their preparatory phases and only a subset of these may eventually be confirmed, while the others are cancelled. For example, a user may contact multiple bookshops, reserving the same book at each before deciding which shop to finally purchase from (e.g., the one which offers the best price and delivery guarantees). With these points in mind, we shall now present an overview of BTP and show how it copes with the world of Web Services.
Page 2 of 4