JavaData & JavaA Transaction Model for Web Services

A Transaction Model for Web Services content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

This material is from the book Java Web Services Architecture, written by James McGovern, Sameer Tyagi, Michael Stevens, and Sunil Mathew, published by Morgan Kaufmann Publishers.

© Copyright Morgan Kaufmann Publishers. All rights reserved.

In our last article, we have examined the properties, transactions, and specifications for transaction managers in the current Java/J2EE environment. Most, if not all, of today’s Java transaction managers implement the flat transaction model, in compliance with JTA and/or JTS. Also, most transactions today are executed within the scope of one enterprise, within one trust domain, and with all resources under the control of one transaction manager. A business transaction may be defined as a consistent state change in the business relationship among two or more parties, with each party maintaining an independent application system (or Web service) that maintains the state of each application. Business transactions form a good number of transaction types in Web services.

While the flat transaction model is well suited for traditional business computing environments, a Web services environment can create new, interesting challenges for flat transactions:

  • Loose coupling among services. A Web service application is a loose coupling of constituent Web services and is often constructed by combining Web services from multiple organizations. In this scenario, each service may implement a standalone business process and therefore demarcate transaction boundaries within the service. Because transactions are started and committed within each service, it is not possible to use a simple flat transaction model within the combined application.

    For example, in Flute Bank’s bill payment service, Flute works with an external check writing service to mail payment checks on behalf of its customers. That is, when a Flute customer transacts with Flute’s bill payment service, the service has to accomplish two separate functions as a part of one atomic transaction: it has to debit the customer’s checking account, and it has to transact with the external check-writing service and send details of the payee (payee address, payment amount, etc.) If the external check-writing service demarcates its own transaction, a flat transaction model may be inadequate to guarantee atomicity to the Flute consumer’s action. (The consumer’s interaction is internally implemented as two distinct transactions).

    It should be said that a nested transaction model will accommodate this situation, but it is not the only model that can do so. A flat transaction model that supports interposition also can accommodate this situation; we look at interposition in the later sections that explain the Business Transaction Protocol (BTP).

  • Long-running transactions. Many business transactions are long-running—some may run for hours or days. As transaction isolation is achieved by holding locks on resources, long-running transactions may reduce transaction concurrency to unacceptable levels. Moreover, in a business transaction, the actions of one party affect how long another’s resources are locked, opening the door for denial-of-service attacks. It is clear that the isolation property (which controls locking) must be relaxed in such transactions.

    Because a business transaction can take a long time to complete, businesses often impose a time limit on certain types of transactions. For example, an airline may hold a tentative reservation for a travel agency for two days. When the time limit is reached, the airline may decide to either cancel or confirm the reservation automatically. The time period for timeout and the result (confirm or cancel) should be a business agreement between the two parties. The transaction protocol should anticipate such events and allow for negotiation between the participants.

  • Optional subtransactions. In some business transactions, a subset of activities may be optional. An example of a fictitious travel agency will better illustrate such a situation.

    Assume that the travel service will search with multiple airline services to find flights, based on a consumer’s request. Further assume that the airlines all take a pessimistic approach to their commitment: when the travel agent service requests seats on a particular flight, if enough seats are available, the airlines lock the seats for the travel agent and marks the seats unavailable to other requests. Figure 1 depicts the participants in this example.

    In such a scenario, a transaction initiated by a consumer request will result in the agency requesting seats from one or more airline systems (in the example airlines A, B, and C), a rental car agency, and a hotel. Some airline systems may decline to participate in the transaction (perhaps because no seats are available, as is the case with airline C), and more than one may lock seats for the request (airlines A and B both have seats and confirm them).

    Airline C’s failure to commit seats cannot be considered a failure of the reservation transaction as a whole, because the application can determine the atomic subset of participants, based on business logic. As a result, the atomic property of the transaction need not be satisfied. Moreover, should multiple airlines lock seats (Airlines A and B), a compensating transaction that releases previously booked seats will have to be generated for Airline B, so that only one airline eventually reserves the required seats. This, in effect, conceptually relaxes the durability property of the reservation transaction initiated by the travel service. For this solution to work, application logic has to be written to select the subset of activities that must be considered atomic and also to generate compensation transactions.

    Figure 1 Atomicity relaxed, travel agency example

  • Transaction context propagation. A Web service application that combines Web services from different organizations will have transactions that span the services. The constituent services may be implemented using different technologies on different platforms (e.g., UNIX, Windows) and may store state in heterogeneous databases. When a transaction spans these disparate services, the transaction context must be passed from service to service. In a JTS environment, JTS specifies how a compliant transaction manager propagates the context from one transaction manager to another over IIOP. A Web service transaction manager must accommodate XML-based transaction contexts propagated over Web service protocols.

This section has illustrated the need for a new model for transactions and transaction management. In the new model, a transaction is viewed as a series of business activities with the context of the transaction made available to each activity. The execution of activities is coordinated, but individual activities may decide to commit the effects of the transaction and make the effects visible before the larger transaction is completed. However, the flat transaction model is adequate for a large number of Web service applications—those that feature short transactions and those in which individual services persist data into a central database or databases within the same enterprise. The new model therefore has to support both the properties of ACID transactions and the relaxed ACID properties demanded by loosely coupled, long-running business transactions.

Strictly speaking, adoption of this new model is not dictated primarily by Web service architectures but by the fundamental long-running nature of business transactions. Web service architecture has simply accentuated the need for it.

Table 1 summarizes the differences between traditional transaction models and the new model.

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 applications that provide reliable outcomes. Of the three, BTP is the most mature and sophisticated. We examine it first and in the most detail.

Table 1 Properties of Traditional and Business Transaction Models
Property   Traditional transactions   Business transactions
Atomicity Required; all or nothing. Depends; sometimes desirable, sometimes may be applicable only to a subset of functions.
Consistency Required. Required; temporary inconsistencies rectified.
Isolation Required; state change is not visible until transaction completes. Relaxed; each service controls degree of visibility.
Durability Required; effects persist. Required, but based on atomicity property; some parts may be volatile.
Context propagation Relaxed; may not be required. Required.

Business Transaction Protocol (BTP)

In May 2002, the OASIS Business Transaction Technical Committee (BTTC) published a specification, BTP 1.0, for coordinating transactions between applications 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 book. Our intention is to describe the concepts and motivations behind BTP. The full BTP specification can be found at

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 application 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).

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 2).

Figure 2 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 deploysthat 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 1 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 3 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 3 Application and BTP elements in an atom/cohesion

As Figure 3 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 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.

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.

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.

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.

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.

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.

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.

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=""  xmlns_xsd=""  xmlns_xsi=""  xmlns_enc=""  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>        </btp:binding-address>      </btp:superior-address>      <btp:superior-identifier>      </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=""    <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.

Figure 10 BTP SOAP message shown pictorially

<?xml version="1.0" encoding="UTF-8"?><soap-env:Envelope xmlns:soap-env=      ""      encodingStyle=""><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=      ""      encodingStyle=""><soap-env:Body>  <btp:cancel xmlns_btp="urn:oasis:names:tc:BTP:xml">  <btp:inferior-identifier>                                 -74c4a3c4:8dd-6ce8fec8:1  </btp:inferior-identifier>  <btp:superior-identifier>                             -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, supports both cohesive and atomic transactions. HP-WST includes an HP-WST coordinator component, Java libraries for transaction participants, and libraries for Java clients.


WS-Transaction (WS-TX) and the related WS-Coordination specifications are relatively new (released in August 2002). They describe mechanisms to coordinate the executions of individual Web services into reliable applications. The two specifications, created jointly by Microsoft, IBM, and BEA, rely on or are built on existing Web services specifications of WSDL, SOAP, and WS-Security.

The execution of a Web service application is seen as a series of activities, each of which may be executed in a different Web service. WS-Coordination describes a general mechanism to create, register, and coordinate those activities across multiple Web services. When a participant Web service creates and registers the activity, it also identifies the coordination protocol—that is, the way collaboration occurs between activities. The specification does not describe protocols for coordination,. which can be achieved in many ways. Some coordination protocols may be transactional; some may not.

WS-Coordination provides a generalized framework that allows Web services to specify the coordination protocol. WS-Transaction describes protocols for two common transactional coordination patterns that may be used with the WS-Coordination framework: the atomic transaction coordination pattern and the business activity transaction pattern. Figure 11 shows the relationship between WS-Coordination and WS-Transaction.

Figure 11 Relationship between WS-Coordination and WS-Transaction

Before describing the WS-Transaction coordination protocols, a brief explanation of the coordination framework described in WS-Coordination is necessary. The latter describes a standard coordination framework, consisting of an activation service, which helps create a new activity; a registration service, to register an activity’s participants; and a coordination service, to process an activity’s completion.

An application contacts the activation service to create an activity, which is identified by a coordination context. The context is a container (defined by an XML schema) with elements for an ID, a context expiration time, the coordination type (the coordination protocols to be used), and other extensible elements. Web services that participate in the same activity receive application messages with the context attached. Web services then use the context to identify the registration service and register as participants to the original activity. The coordination service controls the completion of the activity, based on the selected coordination protocol.

A WS-TX atomic transaction coordination pattern preserves the ACID properties of transactions. The application requests that a new activity be created by the activity service. The activity service creates a coordination context that has the coordinationType element set to the URI The coordination context allows for coordination-protocol-specific elements to be added to the context, using the extensibility mechanism (e.g., a context for an atomic transaction may also carry the isolation level value).

The Web service that created the transaction also registers with the registration service the coordination or completion pattern service for the completion protocol. The coordination service controls the completion of the activity, based on the registered completion protocol.

The BTP and WS-Transaction/WS-Coordination specifications provide for similar transactional needs. One important difference between them is that although BTP provides bindings for SOAP 1.1, it is independent of current de facto Web service standards, although WS-Transaction is built on or relies on SOAP, WSDL, and WS-Security.

Activity Service

Activity Service framework is a submission to OMG in response to OMG’s call for additional structuring mechanisms for Object Transaction Service (OTS). OTS, you will recall, is the specification for the CORBA transaction manager. The Activity Service specification submission, like the BTP specification, addresses the transactional needs of complex, long-running transactions. The submission can be found at

This specification, unlike BTP, is directly tied to and based on the OMG Object Request Broker (ORB) and OTS specifications. The lack of support for XML-based messages and Activity Service’s tie to OTS may mean that Web services implemented in compliance to it may not transact transparently with services written on, say, the .NET platform. However, because most current Java transaction managers implement JTS (which is a Java mapping of OTS), Activity Service is likely to have a high impact on how Java transaction managers are implemented.

JSRs for Web Service Transaction Support

As described earlier, JTA- and JTS-based transaction managers are limited, in that they are meant to manage and coordinate distributed, ACID transactions. A new specification is needed to address the complex distributed transactions prevalent in Web service and workflow applications.

JSR-95, J2EE Activity Service for Extended Transactions, proposes a low-level API for J2EE containers and transaction managers. JSR-95 borrows from the OMG Activity Service submission and leverages concepts defined by JTA and EJB specifications.

JSR-156, XML Transactions for Java (JAXTX), also proposes support for extended transaction support in J2EE systems. Unlike JSR95, JSR-156 proposes a closer relationship to the BTP specification, using XML messaging for transaction management and coordination. This proposed Java API also has a loftier long-term goal: to isolate application programmers and application servers from the underlying transaction manager implementation (BTP, WS-Transaction, and Activity Service).

The acronym “JAXTX,” in an attempt at consistency with other JAX* APIs, is, in our opinion, misleading. The other JAX* APIs (e.g., JAXM) are meant to be used primarily by application programmers. The J2EE specifications have tried to minimize programmatic transaction demarcation, making the UserTransaction interface the only JTA interface exposed to the application.

We recognize that coordinated, non-atomic transactions (e.g., cohesive BTP transactions and business transactions in the WS-Transaction specification) will require application logic to generate compensation transactions. We also recognize that in determining the subset of activities treated as atomic, the interface exposed to application programmers must be expanded beyond the current JTA UserTransaction interface. But the vast majority of transaction coordination messages are meant to be exchanged by components below the application layer. Therefore, we feel that “JAXTX” is misleading.


J2EE servers are required only to implement the flat transaction model. This model is sufficient in situations where the transactional resources are centralized and under the control of one party. The ACID properties of such transactions can be maintained without compromise. This transactional model is adequate for Web service applications with short-running transactions and those in which transactions do not span organizational boundaries.

The flat transaction mode is inadequate to address the transactional needs of some business transactions in Web services, which frequently involve the assembly of disparate services. These disparate services may have been written with their own, autonomous transaction boundaries and may control their own resources. Web services for business-to-business integration can also be long-running, causing inefficiency as a result of the locking mechanism used for achieving isolation in traditional transaction models.

Relaxing the isolation property of transactions and allowing subtransactions to make visible state-change effects before the larger transaction completes solves the problem of inefficient resource locking in long-running transactions. Allowing a transaction to complete even if only a subset of subtransactions completes (i.e., relaxing the atomic property) allows a business transaction to be composed based on application needs.

The BTP, WS-TX, and Activity Service specifications address the needs of coordinating long-running business transactions that span autonomous, loosely coupled services while accommodating the needs of short-running, centralized transactions. BTP specifies the working of atomic and cohesive transactions, and WS-TX describes the atomic and business activity patterns for coordination. The Activity Service submission to OMG also provides a specification for business transactions but does not reference XML-based messages specifically. (Because Activity Service is based on OMG OTS, it does provide IDL specifications.)

Two JSRs, JSR-95 and JSR-156 propose an extended transaction model for the J2EE platform. As of now, no implementations of BTP or Activity Service transaction managers work seamlessly with J2EE servers. It will be some time before the relevant JSRs are fleshed out and we see servers with embedded, standards-based transaction support for extended transaction models. Until then, our current JTA- and JTS-based flat transaction managers will have to suffice.

Source of this material

This is material from Chapter 14: Transaction Management from the book Java Web Services Architecture (ISBN: 1-55860-900-8) written by James McGovern, Sameer Tyagi, Michael Stevens, and Sunil Mathew, published by Morgan Kaufmann Publishers.

To access the full Table of Contents for the book

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories