New Transaction Specifications

In this section, we discuss three important proposed standards that implement new transaction models: Business Transaction Protocol (BTP) from OASIS, WS-Transaction from IBM and Microsoft, and Activity Service from OMG. Their purpose is to coordinate Web services into apps that provide reliable outcomes. Of the three, BTP is the most mature and sophisticated. We examine it first and in the most detail.

Business Transaction Protocol (BTP)

In May 2002, the OASIS Business Transaction Technical Committee (BTTC) published a specification, BTP 1.0, for coordinating transactions between apps controlled by multiple autonomous parties. BTP 1.0 is the work of several companies (BEA, IBM, Sun, HP, Choreology, ORACLE, and others) that addresses the challenges posed by business transactions to traditional transaction models. Examining BTP messages and interactions in detail is beyond the scope of this tutorial. Our intention is to describe the concepts and motivations behind BTP. The full BTP specification can be found at www.oasis-open.org/committees/business-transactions. BTP recognizes that in a business transaction, no single party controls all resources needed. In such an environment, parties manage their own resources but coordinate in a defined manner to accomplish the work scoped by a transaction. Individual service providers either agree to join a transaction or not. If they agree, they are required to provide a mechanism to confirm or cancel their commitments to the transaction. They may, however, autonomously decide when to unlock resources they hold and/or whether to use compensating transactions to roll back transient states that were persisted. The BTP specification did not arise out of the need created by Web services architecture but was formed to address the needs of interorganizational transactions and of workflow systems. However, the authors realized early on the limitations of similar coordination protocols tied to communication protocols. BTP defines an abstract message set and a binding to communication protocols. Its ability to coordinate transactions across multiple autonomous services and its use of XML messages makes it particularly suited for adoption in Web service architectures. BTP is designed such that the protocol may be bound to any carrier protocol, and BTP implementations bound to the same carrier protocols should be interoperable. The current specification describes a SOAP 1.1/HTTP binding. Transaction and security aspects of an app system are often related, but the BTP specification consciously does not address how a BTP transaction will integrate with a security system, because Web services security standards are still evolving (independently of the transaction specifications).

app and BTP Elements

BTP is a protocol-a set of well-defined messages exchanged between the app systems involved in a business transaction. Each system that participates in a business transaction can be thought of as having two elements-an app element and a BTP element ( ScreenShot).

The app elements exchange messages to accomplish the business function. When Flute Bank's bill payment service sends a message to the check writing service with details of the payee's name, address, and payment amount, the app elements of the two services are exchanging a message. The BTP elements of the two services also exchange messages that help compose, control, and coordinate a reliable outcome for the message sent between the app elements. The app element pertains to the service consumer and service producer components the app programmer deploys-that is, app/business logic. The BTP elements are supplied by the BTP vendor. The separation of system components into BTP and app elements is a logical one. These elements may or may not coexist in a single address space. With respect to a BTP transaction, app elements play the role of initiator (the Web service that starts the transaction) and terminator (the Web service that decides to commit or end the transaction). The initiator and terminator of a transaction are usually played by the same app element.

BTP elements play either a superior or inferior role. The BTP element associated with the app element that starts a business transaction is usually assigned the superior role. The superior informs the inferior when to prepare to terminate the transaction and waits for the inferior to report back on the result of its request. The following sections detail roles played by BTP elements and the nature and content of BTP messages.

Types of BTP Transactions

Table 14.2 summarized the transactional properties business transactions must satisfy. In all types of business transactions, the isolation property is relaxed. Some business transactions require the entire transaction to be treated as an atomic operation, while another class of business transactions requires that the atomic property also be relaxed. BTP accommodates both types of transaction needs. BTP Atomic Business Transactions, or atoms, are like traditional transactions, with a relaxed isolation property.

In traditional transactions, a transaction manger will cancel (roll back) a transaction if any resource manager participating in the transaction cannot commit or cannot prepare. In BTP, this is not always the case; the set of participants that must confirm before a transaction can be committed is called a confirm-set. The confirm-set may be the set of all participants or a subset of participants.

BTP Cohesive Business Transactions, or cohesions, are transactions where both isolation and atomicity properties are relaxed. Atoms Atoms are business transactions where all participants have to agree before a transaction can be committed that is, all participants in an atom are guaranteed to see the same ending to the transaction. If any participant cannot confirm, the entire transaction is canceled. Because BTP transactions do not require strict isolation, it is up to each participating service to determine how to implement transaction isolation. ScreenShot depicts a Web service consumer invoking two business methods on two different services, within the scope of a transaction. If the overall transaction is an atom, the BTP element (superior) at the service consumer end is called an atom coordinator or simply a coordinator. The BTP element plays the coordinator role and coordinates a BTP atomic transaction. It does this by exchanging BTP messages with the BTP elements associated with the two service producers when the app asks it to complete the transaction.

app and BTP elements in an atom/cohesion

As ScreenShot also shows, inferior BTP elements are called participants. The participant is in charge of persisting the state change made by the associated app element (service producer), which it does by following instructions (via BTP messages) from the superior (coordinator). If either participant informs the superior that it cannot confirm the transaction, the transaction is rolled back-that is, the confirm-set in this example is "participant a" and "participant b."

An atom is a BTP transaction whose confirm-set is the set of all inferiors-that is, in an atom, any inferior has power to veto the transaction.

Cohesions Cohesions are transactions where not all involved parties must agree to commit their changes before a transaction is committed. Only some subset of the parties may need to agree. The subset of parties that need to agree before a transaction can be completed is determined using business logic and is called the confirm-set. In the example illustrated by ScreenShot, airline C refuses to reserve seats on the requested flight, because it is fully tutorialed. This refusal to participate in the transaction does not mean that the transaction should be rolled back, because the app logic is able to determine that two other airlines have reserved seats on their flights. Furthermore, because two airlines have reserved seats, the app element must instruct the BTP superior to cancel the more expensive reservation. The BTP superior that composes the transaction based on instructions from the initiating app element is called a cohesion composer. The confirm-set in the example is the BTP elements associated with the Web services of Airline A, the rental car agency, and the hotel. Referring to ScreenShot, in a cohesion scenario, the BTP element (superior) at the service consumer end is called a cohesion composer or simply a composer. The BTP element associated with the service producer is called a participant. In a cohesion scenario, the business logic in app element (initiating element) can determine whether the transaction can be completed-that is, whether "participant a" only need confirm, "participant b" only need confirm, or both must confirm. If only one participant must confirm but both eventually confirm, the composer will ask the unwanted participant to cancel.

In BTP, the actions of transaction coordinator or composer can be influenced by app elements (i.e., business logic). In a cohesion, the initiating app element determines which subset of activities is to be included in the overall transaction by providing that information to the superior. app elements can also influence the control and coordination of the transaction by providing the superior with additional context information (via qualifiers; see next section), such as transaction time limits and other app-specific values.

A cohesion is a transaction whose confirm-set is a subset of all inferiors participating in the transaction-that is, only inferiors in the confirm-set have the power to veto the transaction. This subset is determined by app logic, and the app element passes the confirm-set to the composer before asking the composer to complete the transaction.

BTP Transactions and Locking

For both atoms and cohesions, the isolation level for cohesions is left up to each service. Isolation can be achieved by:

Making changes but applying locks, as in traditional transactions
Deferring changes until a transaction commits (perhaps by writing a log of changes that will be applied later)
Making changes and making the interim results visible to others

If the third option is chosen, the effect of making interim changes visible is called the provisional effect. If a service makes visible provisional changes and the transaction is ultimately rolled back, new transactions (compensations) may have to be generated to undo the changes made (This is known as the counter effect).

BTP Actors, Roles, and Messages

As mentioned earlier, the BTP element associated with the initiator plays the superior role. The initiator is also usually the terminator of the initiated transaction. Depending on the type of business transaction, superiors are either coordinators or composers of the business transaction-an atom is coordinated by an atom coordinator (coordinator), and a cohesion is composed by a cohesive composer (composer). All other BTP elements are inferiors to this superior. In the simplest case, with only one superior and one inferior (i.e., only two parties are involved in the business transaction), the inferior is called a participant.

ScreenShot shows a more detailed version of ScreenShot. The app (initiator) first asks a BTP element called the factory to create the coordinator/composer. The factory creates the superior and returns the transaction context. The initiator then invokes the business method on the service consumer and passes the context to the service.

How the context is passed depends on the protocol binding. It is, for example, stuffed as a header block in a SOAP message. At the other end, the invoked service asks a BTP element called enroller to enroll in the transaction, passing the received context. The enroller creates the inferior (participant) and enrolls in the transaction with the superior. Finally, the service provides the response to the business method and passes along the context reply. The message sequence diagram in ScreenShot details the exchange of messages between the different elements.

BTP messages must be bound to a protocol such as SOAP. Because we have not yet described the BTP binding to SOAP, the following section shows only abstract forms of BTP messages. All BTP messages have an associated schema. The CONTEXT message shown below is an example of a BTP message.

<btp:context id>
<btp:superior-address> address</btp:superior-address>
<btp:superior-identifier> URI </btp:superior-identifier>
<btp:superior-type>atom</btp:superior-type>
<btp:qualifiers> qualifiers </btp:qualifiers>
<btp:reply-address> address </btp:reply-address>
</btp:context>

The superior-address element contains the address to which ENROLL and other messages from an inferior are to be sent. Every BTP address element (superior-address, reply-address, etc.) has the following XML format:

<btp:superior-address>
 <btp:binding-name> </btp:binding-name>
 <btp:binding-address></btp:binding-address>
 <btp:additional-information>information ... </btp:additional-
 information>
</btp:superior-address>

superior-identifier contains a unique identifier (URI) for the superior. superior-type indicates whether the context is for a transaction that is an atom or a cohesion. The qualifiers element provides a means for app elements to have some control over transaction management. Qualifiers are data structures whose contents can influence how the transaction coordinator/composer controls the transaction. BTP defines a few standard qualifiers (such as transaction time limit), but BTP vendors can define more such parameters.

The reply-address element contains the address to which a CONTEXT_REPLY message is to be sent (this is required only if the BTP message is not sent over a request-response transport).

BTP Two-Phase Protocol

Once the initiating app decides to terminate the transaction, it asks the BTP superior to confirm the transaction. The BTP elements then follow a two-phase protocol to complete the transaction. This is quite similar to the two-phase protocol used in the flat transaction model, but there are some key differences, discussed later in this section. ScreenShot illustrated how a transaction is started. ScreenShot shows how such a transaction is terminated using the two-phase protocol.

On receiving a PREPARE message, an inferior (in ScreenShot, the participant) can reply with a PREPARED, CANCEL, or RESIGN message. In ScreenShot, because only one inferior exists, the participant must reply with a PREPARED message if the transaction is to be confirmed and progress to phase 2 (CONFIRM). An example of the BTP message for PREPARE is shown below:

<btp:prepare id>
 <btp:inferior-identifier> URI </btp:inferior-identifier>
 <btp:qualifiers>qualifiers</btp:qualifiers>
 <btp:target-additional-information>
 additional address information
 </btp:target-additional-information>
 <btp:sender-address>address</btp:sender-address>
</btp:prepare>

As explained previously, the qualifiers element contains a set of standard or app-specific qualifiers. The timeout for inferiors is one of the qualifiers that should be sent for a PREPARE message. target-address points to the address of the inferior that was ENROLLed. The PREPARE message will be sent to that address. The sender-address points to address of the superior. The effect on the outcome of a final transaction of having multiple inferiors depends on whether the transaction is a cohesion or is an atom. The set of inferiors that must eventually return CONFIRMED to a CONFIRM message for the transaction to be committed is called a confirm-set. For an atomic transaction, the set consist of all of a superior's inferiors. For a cohesion, the confirm-set is a subset of all its inferiors. The subset is decided by the app element associated with the superior (this implies that business logic is involved). ScreenShot illustrates how a composer with multiple participants confirms a cohesion with the two-phase protocol. The app element (the initiator and the terminator of the transaction) decides that only participants 1 and 2 should confirm-that the confirm-set consists of participants 1 and 2. To accomplish this,

The terminator sends a CONFIRM_TRANSACTION with the IDs of the participants in the confirm-set.
The decider (composer) sends PREPARE messages to participants 1 and 2 and a CANCEL message to participant 3.
As soon as PREPARED messages return from participants in the confirm-set, the decider sends out CONFIRM (phase 2) messages.
When the confirm-set replies with CONFIRMED messages, the transaction is confirmed.

Business Transaction Protocol (BTP)

app and BTP Elements

Types of BTP Transactions

BTP Transactions and Locking

BTP Actors, Roles, and Messages

BTP Two-Phase Protocol

Differences between the BTP and Current Two-Phase Commit Protocols

Complex BTP Element Relationships

BTP and SOAP Binding

WS-Transaction

Activity Service