February 28, 2021
Hot Topics:

A Transaction Model for Web Services

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

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 8 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.

Click here for a larger image.

Figure 8 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 9 shows the different roles played by BTP elements and the relationships between them.

Click here for a larger image.

Figure 9 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 BTPCONTEXT 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 10). This BEGIN message starts a cohesion.

Click here for a larger image.

Figure 10 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.

Page 4 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