March 1, 2021
Hot Topics:

A Transaction Model for Web Services

  • By McGovern, Tyagi, Stevens, and Mathew
  • Send Email »
  • More Articles »

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 Figure 1, airline C refuses to reserve seats on the requested flight, because it is fully booked. This refusal to participate in the transaction does not mean that the transaction should be rolled back, because the application logic is able to determine that two other airlines have reserved seats on their flights. Furthermore, because two airlines have reserved seats, the application 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 application 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 Figure 3, 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 application 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 application elements (i.e., business logic). In a cohesion, the initiating application element determines which subset of activities is to be included in the over-all transaction by providing that information to the superior. Application 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 application-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 application logic, and the application 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 transactionan 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.

Figure 4 shows a more detailed version of Figure 2. The application (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.

Click here for a larger image.

Figure 4 BTP and application elements

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 Figure 5 details the exchange of messages between the different elements.

Click here for a larger image.

Figure 5 BTP actors and messages overview

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 application 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 application 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. Figure 5 illustrated how a transaction is started. Figure 6 shows how such a transaction is terminated using the two-phase protocol.

Click here for a larger image.

Figure 6 A simple atom example illustrating the BTP two-phase protocol

On receiving a PREPARE message, an inferior (in Figure 6, the participant) can reply with a PREPARED, CANCEL, or RESIGN message. In Figure 6, 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 application-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 application element associated with the superior (this implies that business logic is involved).

Figure 7 illustrates how a composer with multiple participants confirms a cohesion with the two-phase protocol. The application 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,

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

Click here for a larger image.

Figure 7 Cohesion completion

How the confirm subset is passed to the decider is better understood by examining the CONFIRM_TRANSACTION message structure:

<btp:confirm-transaction id>  <btp:transaction-identifier> ... URI ...       </btp:transaction-identifier>  <btp:inferiors-list>    <btp:inferior-identifier> inferior URI</btp:inferior-identifier>    <btp:inferior-identifier> inferior URI</btp:inferior-identifier  </btp:inferiors-list>  <btp:report-hazard>true</btp:report-hazard>  <btp:qualifiers>qualifiers</btp:qualifiers>  <btp:target-additional-information>    info  </btp:target-additional-information>  <btp:reply-address> decider address</btp:reply-address></btp: confirm_transaction>

Note that inferiors-list contains only the confirm-set of inferiors. If this element is absent, all inferiors are part of the confirm-set. For an atom, because all participants are in the confirm set, this element must not be present.

The report-hazard element defines when the decider informs the application that the transaction is conformed (TRANSACTION_CONFIRMED message):

  • If report-hazard is true, the decider waits to hear from all inferiors, not just the confirm-set, before informing the terminator.
  • If report-hazard is false, the decider must wait for all elements (even elements that receive a CANCEL message) to reply before communicating the outcome of the transaction to the terminator.

report-hazard is useful when the application element wants to know if there was a hazard (problem) with any inferior.

If a coordinator or composer has only one inferior, it may decide to use a single-phase confirm operation and skip the two-phase protocol. Instead of a PREPARE + CONFIRM message exchange, it may send a CONFIRM_ONE_PHASE message to the inferior.

The two-phase protocol used in BTP ensures that either the entire transaction is canceled or that a consistent set of participants is confirmed.

Page 3 of 5

This article was originally published on August 20, 2003

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date