Application and BTP Elements

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

Figure 14.5: Application and BTP elements overview

The application 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 application 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 application elements.

The application element pertains to the service consumer and service producer components the application programmer deploys—that is, application/business logic. The BTP elements are supplied by the BTP vendor. The separation of system components into BTP and application elements is a logical one. These elements may or may not coexist in a single address space.

With respect to a BTP transaction, application 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 application element.

BTP elements play either a superior or inferior role. The BTP element associated with the application 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.

Figure 14.6 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 application asks it to complete the transaction.

Figure 14.6: Application and BTP elements in an atom/cohesion

As Figure 14.6 also shows, inferior BTP elements are called participants. The participant is in charge of persisting the state change made by the associated application 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 Figure 14.4, 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 14.6, 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 overall 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 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.

Figure 14.7 shows a more detailed version of Figure 14.5. 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.

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

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

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

On receiving a PREPARE message, an inferior (in Figure 14.9, the participant) can reply with a PREPARED, CANCEL, or RESIGN message. In Figure 14.9, 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 14.10 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.

Figure 14.10: 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.

Differences between the BTP and Current Two-Phase Commit Protocols

As discussed in the "Isolation Levels and Locking" sidebar earlier, BTP does not require a participant waiting for a confirm message to hold locks for maintaining application state. A prepared participant can choose to apply application state changes to the database and make this interim "provisional effect" visible. In doing so, it has to hold a compensating transaction ready to be applied (the counter effect), in case of the need to cancel.

Because Web service transactions can span networks prone to communication failure or congestion, a participant and its superior may not be able to communicate readily. BTP recognizes this and accommodates possible communication failures. A participant can limit the promise made in sending PREPARED back to its superior. by retaining the right to autonomously confirm or cancel application state changes it controls. This autonomous decision is very much like the heuristic decision made by in-doubt resources in a normal two-phase commit protocol. The difference is that whereas other transaction models consider heuristic decisions rare occurrences, BTP anticipates such problems and allows participants to indicate how long they are willing to be in a prepared state.

What happens when a participant, having informed its superior that it is prepared to confirm, makes an autonomous decision to cancel, because it has not received the phase-two CONFIRM message within the allotted time? What if, after the autonomous decision is made to cancel, the superior sends out a CONFIRM message? In such cases, the superior will eventually recognize and log a contradiction, inform management/monitoring systems, and send a CONTRADICTION message to the participant. By sending a contradiction message, the superior acknowledges the contradiction and informs the inferior that it knows and has tried to cope with it.

The differences between BTP 2PC and current 2PC can be summed up as follows:

• In BTP, the application determines the confirm-set.

• BTP provides a means for applications to "tune" the two-phase protocol, by passing qualifiers to the coordinator. These qualifiers include standard BTP qualifiers, such as how long a participant is to wait before making an autonomous decision. Qualifiers can also be BTP vendor- or application-specific.

• BTP does not require two-phase locking. This can lead to contradictions if participants make autonomous decisions. Unlike other models, however, which treat heuristic decisions as rare occurrences, BTP anticipates such problems and tries to accommodate them.

Complex BTP Element Relationships

So far, we have examined the BTP elements, roles, and message in a rather simple scenario. A business transaction can span multiple organizations and multiple services, and BTP accommodates such complex scenarios by describing a tree structure for relationships between BTP elements. Figure 14.11 illustrates such a complex relationship. The BTP elements associated with services B and C are both superiors to other inferiors but are inferiors to the superior (composer A, also known as the decider). BTP element B is a composer of the transaction cohesion Tc1. As B is an inferior to A, B is called a sub-composer. Similarly, BTP element C coordinates the atom Ta1 and is a superior to F and G but an inferior to A, so C is a sub-coordinator.

Figure 14.11: BTP element tree

A sub-composer or sub-coordinator is not a participant; it controls other participants and reports to its superior. On receiving PREPARE and CONFIRM messages from its superior, the sub-composer or sub-coordinator asks its confirm-set to PREPARE and CONFIRM and reports the result to its superior. In this way, BTP supports the creation of relationship trees of arbitrary depth and width.

Sub-composers and sub-coordinators are interposed (as in injected or inserted) into the transaction. By default, BTP supports an interposed transaction model, not a nested transaction model.

To summarize, if an inferior is a superior to other nodes, it may be a sub-composer or a sub-coordinator. A sub-coordinator treats its inferior's actions as atomic, while a sub-composer treats only a subset of its inferiors as atomic. A participant is a BTP inferior element that has no children; it is responsible for applying application state changes to a persistent store. Figure 14.12 shows the different roles played by BTP elements and the relationships between them.

Figure 14.12: Roles played by superiors and inferiors

BTP and SOAP Binding

BTP defines an abstract message set and a protocol that are independent of underlying communication protocols over which the messages are to be transmitted. For BTP to be viable for Web services, BTP messages must be transmitted over the de facto messaging standard for Web services: SOAP. BTP specifications define a binding for SOAP (and SOAP with Attachments).

As discussed above, most BTP messages are exchanged between BTP elements and are not mixed with any application-element business messages (e.g., PREPARE, CONFIRM). All such BTP messages are sent within the SOAP body under the btp:messages element. A few BTP messages are sent along with application messages.

One example of this type of message is CONTEXT. The BTP CONTEXT is propagated from a BTP superior to a BTP inferior when the initiating application element invokes a business method on a service. The BTP CONTEXT message, therefore, must be sent along with the application business message. For such messages, the BTP message is sent in the SOAP header under a single btp:messages element, and the application message is sent within the SOAP body. All BTP messages are sent without any encoding (application messages may be encoded).

The following example of a SOAP message starts a BTP atomic transaction in Flute Bank's bill payment service. The business method invoked is getLastPayment. As a new transaction is started, the BTP CONTEXT message is passed, along with the application message. The CONTEXT message is passed as a part of the SOAP header. The header is not encoded, but the body, which carries the application message, is RPC/encoded.

<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"
    env:encodingStyle="">

    <env:Header>

        <btp:messages
            xmlns:btp="urn:oasis:names:tc:BTP:1.0:core">
            <btp:context>
                <btp:superior-address>
                    <btp:binding>soap-http-1</btp:binding>
                    <btp:binding-address>
                        http://www.flute.com/btpengine
                    </btp:binding-address>
                </btp:superior-address>

                <btp:superior-identifier>
                    http://www.flute.com/btp01
                </btp:superior-identifier>
                <btp:qualifiers>
                    <btpq:transaction-timelimit>
        xmlns:btpq="urn:oasis:names:tc:BTP:1.0:qualifiers">
                    <btpq:timelimit>500</btpq:timelimit>
                    </btpq:transaction-timelimit>
                </btp:qualifiers>
            </btp:context>
        </btp:messages>
    </env:Header>

    <env:Body>
        <ans1:getLastPayment
            xmlns:ans1="http://com.flute.webservice/billPay/wsdl/billPay">
            env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

            <String_1 xsi:type="xsd:string">horizon_wireless </String_1>
        </ans1:getLastPayment>
    </env:Body>

</env:Envelope>

Although application architects and developers rarely concern themselves with messages exchanged between BTP elements, let us look at more examples, to help visualize the transaction coordination. The listing below shows the BEGIN BTP message over SOAP from the initiating application element to the associated BTP factory (Figure 14.13). This BEGIN message starts a cohesion.

Figure 14.13: BTP SOAP message shown pictorially

<?xml version="1.0" encoding="UTF-8"?>
<soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/"
               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<soap-env:Body>
     <btp:begin transaction-type="cohesion"
                                  xmlns:btp="urn:oasis:names:tc:BTP:xml"/>
 </soap-env:Body>
</soap-env:Envelope>

The following listing shows a SOAP message with a CANCEL request from a transaction coordinator to a participant.

<?xml version="1.0" encoding="UTF-8"?>
<soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/"
        encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<soap-env:Body>
    <btp:cancel xmlns:btp="urn:oasis:names:tc:BTP:xml">
    <btp:inferior-identifier>
    http://www.flute.com/btp01/Fluteparticipant/-74c4a3c4:8dd-6ce8fec8:1
    </btp:inferior-identifier>
    <btp:superior-identifier>
    http://www.flute.com/btp01/TransactionManager/-77e2b3e4:8aa-3ce8fec8:9
    </btp:superior-identifier>
    </btp:cancel>
</soap-env:Body>
</soap-env:Envelope

HP Web Services Transactions (HP-WST)

HP's Web Services Transactions (WST) is the first implementation of a transaction manager based on the BTP specifications. The implementation, available at www.hpmiddleware.com, supports both cohesive and atomic transactions. HP-WST includes an HP-WST coordinator component, Java libraries for transaction participants, and libraries for Java clients.