Approaching Web services transactions

Comparing two different approaches

In business applications, transactional support is taken for granted. If business applications are now going to rely on Web services, it is expected that there would be transactional support in Web services as well. However, Web services introduce a different set of requirements on a transaction infrastructure -- transactions should be able to encompass systems that need not be in a trusted domain, that do not want their resources to be locked, and do not care if the transaction runs for a short time or stretches for days. There is a need for a different kind of transaction, which instead of relying on the commit and rollback features of traditional transactions uses compensations. Compensations are operations or tasks that participants perform to nullify or negate the results of previous tasks. This article analyzes two Web services transaction proposals that are currently being developed. One is from OASIS and another proposed by IBM, Microsoft, and BEA. This article compares these two specifications.

Manish Verma (mverma@secf.com), Principal Architect, Second Foundation Inc.

Manish Verma is a Principal Architect at Second Foundation Inc., a global software services and systems integration company. Manish has 10 years experience in all aspects of the software development life cycle and has designed integration strategies for client organizations running disparate systems. Manish's integration expertise is founded on his understanding of a host of technologies, including various legacy systems, .NET, Java and the latest middleware. Prior to Second Foundation, Manish worked as a Software Architect and Technical Lead at Quark Inc., Hewlett Packard, Endura Software and The Williams Company.



Parveen Deswal (pdeswal@secf.com), Technical Lead, Second Foundation Inc.

Parveen Deswal is a Technical Lead at Second Foundation Inc., a global software services and systems integration company. Parveen has 7 years of experience; he has been working in the J2EE space for the past 5 years with a primary focus on integration and server side infrastructure.



28 February 2003

What are transactions and why are they important?

Transactions refer to all discreet tasks that must be performed in unison to accomplish a goal. Transactions may involve tasks that are done by one or more participant. When more than one participant is involved, it must be ensured that all the participants do their tasks as promised. To ensure this, there is some kind of transaction manager that all the involved participants trust, that controls the actions taken by various participants and ensures that either all the participants do what they promise or none of the participants do anything.

Transactions are important because there are some tasks that make sense only if done in unison with other tasks. For example, in a bank transaction, when transferring money from one account to another it is very important to do the task of debiting one account at this same time as the task of crediting another account.

Transactions as described above would fall under the category of traditional transactions. With the advent of the Internet and Web services, the scenario that is emerging requires involvement of participants unknown to each other in distributed transactions. Let us take a closer look at the characteristics of "Traditional transactions" and "Transactions in a Web services context".

Traditional transactions

These types of transactions occur in tightly coupled systems. A transaction has the ACID properties:

  • Atomicity -- All participants must confirm or cancel.
  • Consistency -- A consistent result is obtained.
  • Isolation -- Effects are not visible until all participants confirm or cancel. Intermittent status of various participants is not visible to the external world.
  • Durability -- Effects of the transaction are stored.

Transactions are short lived. Resources are locked for the duration of the transaction. Participants have a high degree of trust on each other and are willing to cooperate under a transaction manager.

Transactions in a Web services context

These transactions have the following characteristics:

  • Transactions may be of a long duration, sometimes lasting hours, days, or more.
  • Participants may not allow their resources to be locked for long durations.
  • The communication infrastructure between participants may not be reliable.
  • Some of the ACID properties of traditional transactions are not mandatory.
  • A transaction may succeed even if only some of the participants choose to confirm and others cancel.
  • All participants may choose to have their own coordinator (Transaction Manager), because of lack of trust.
  • All activities are logged.
  • Transactions that have to be rolled back have the concept of compensation.

Options available for Web services to participate in transactions

We have well-defined and mature standards for managing traditional transactions. For transactions in a Web services context, there are several proposals at the time of writing. One proposal is from IBM, Microsoft, and BEA; the other one is from OASIS with SUN, Hewlett Packard, and others.


IBM, Microsoft, and BEA proposal

This consists of two separate specifications made publicly available on 9 August 2002:

  1. WS-Transaction
  2. WS-Coordination

WS-Transaction defines the sequence of messages that various participants will exchange when participating in transactions. Messages that applications exchange depend upon two things:

  1. Type of coordination protocol.
  2. Coordination protocol within the chosen coordination protocol type. The coordination protocol type and coordination protocols are defined in WS-Coordination.

For example, there are two coordination types -- Atomic and Business activity. Each of these has various coordination protocols. For example, Atomic has "Completion", "Two Phase Commit", etc. For "Two Phase Commit", there are various valid messages, as follows:

  • Sent by the participant in this protocol:
    • Prepared
    • ReadOnly
    • Aborted
    • Committed
  • Sent by the coordinator in this protocol:
    • Prepare
    • Rollback
    • Cancel

Digging deep into the transaction management based on this proposal, let us see how to create the required infrastructure to build transactions. WS-Coordination defines an extensible framework for coordinator creation and creation of coordination protocols. It also defines the structure of the CoordinationContext and requirements for propagating a context between cooperating services. The coordination context defined is generic, and can be leveraged by various coordination types, two of which we will look at as part of WS-Transaction.

Coordinator consists of the following three services:

  1. Activation service -- The service has an operation that allows an application to create coordination content.
  2. Registration service -- This allows an application to register for coordination protocols.
  3. Coordination protocols -- Coordination protocols that are specific to coordination types*.

*Coordination types are defined as part of WS-Transaction, explained later in this article.

Coordinator is the principal object that gets created and is propagated for managing the transactions. The activation service of the coordinator can be used to get an instance of the coordinator; the registration service can be used to register the applications with the coordinator. When creating the coordinator, one of the supported protocol types is chosen by the instantiating application. Later when the coordination context is propagated to other applications, the other applications choose the coordination protocol supported by that coordination type to participate in the transaction.

To propagate activity to another Web service, the initiating client must send a CoordinatorContext. CoordinationContext is sent as part of the application message itself. It is generally in the SOAP header, but could be part of the SOAP body as well, if the SOAP body is empty.

Activation service

The activation service requires port types on both the coordinator and requestor sides. Port types referred to here are the same as the port types in WSDL. Port types identify operations under them.

When the requestor has to create a CoordinationContext, it calls the "CreateCoordinationContext" operation of the coordinator activation service, passing the coordination type, requesters own port type reference (for the coordinator to send back the response), port type reference of activation service and other information.

The coordinator in return calls the "CreateCoordinatorContextResponse" operation of the requestor, passing back the Requestor port type reference, CoordinationContext created in response to the earlier "CreateCoordinationContest" operation call, and other information. An important thing to remember, as part of the newly created CoordinationContext, is that the registration service port type reference of the coordinator is also returned.

Registration service

Like the activation service, this service also requires port type references on both the coordinator and requester sides. It allows coordinator and requester to send messages to each other.

For the requester to register itself to the coordinator, the requester uses the registration service port type reference returned by the coordinator in response to the creation of a context. The requester calls the "Register" operation of the coordinator registration service, passing the coordinator registration service port type reference, port type reference of itself (to allow the coordinator to send back the status information), URI of the coordination protocol selected for registration, port type reference that the participant wants the coordinator to use for the coordination protocol, and other information.

The coordinator in return calls the "RegisterResponse" operation on the requester by passing the requesters port type reference, the port reference that the coordinator wants the registered participant to use for the coordination protocol, and other information.

At this stage both coordinator and the requester have each other's port type reference and can exchange protocol messages.

A participant can register with the coordinator for multiple coordination protocols by calling the "Register" operation on the coordinator multiple times with different coordination protocol URI.

A typical message exchange between two Web services

We are assuming that the two Web services will create their own coordinators to interact with each other. Here is the sequence of message exchanges:

  1. Application 1 calls the "CreateCoordinationContext" operation on Coordinator A. The application passes the coordination type, say CT1, and its own port type reference to the operation.
  2. Coordinator A calls the "CreateCoordinationContextResponse" operation on Coordinator B, sending back the CoordinationContext CCA, that has the activity identifier A1, coordination type CT1 and port type reference for Coordinator A's registration service RSA.
  3. Application 1 sends the application message with the CoordinationContext CCA to Application 2.
  4. Application 2 wants to create its own coordinator instead of using the coordinator sent by Application 1. Application 2 calls the "CreateCoordinationContext" operation on Coordinator B with the CoordinationContext CCA that it received from Application 1. Coordinator B creates its own CoordinatorContext CCB. This new CoordinatorContext CCB has the same activity identifier and coordination type as CCA but the registration service RSB is different.
  5. Application 2 determines the coordination protocol supported by the CoordinationType CT1 and registers for a coordination protocol CP1 at Coordinator B, thereby exchanging port references. All messages on protocol CP1 can now be exchanged between these two.
  6. Registration of application 2 with Coordinator B triggers another registration. This registration happens between Coordinator B and Coordinator A. Coordinator B forwards registration onto Coordinator A's registration service RSA. Now all messages on protocol CP1 can be exchanged between the two coordinators and hence between the two applications, Application 1 and Application 2.

WS-Transaction is used for defining the coordination types that are used with the coordination framework, as mentioned earlier. WS-Transaction defines two coordination types:

  1. Atomic transactions
  2. Business activity

Each coordination type has a number of coordination protocols. Various participants may choose to register for one or more of the protocols. Based on the coordination protocol that a participant registers for, a well-defined number and type of message becomes available to the participant for exchanging with the coordinator.

The process of a set of messages becoming available to the participant on registering for a coordination protocol is analogous to the participant implementing an interface in a programming language. The interface may have a set of methods that need to be implemented.

Atomic transactions

Atomic transactions are used to coordinate activities that have following characteristics:

  • Short duration.
  • Participants trust each other.
  • Desired outcome requires all participants either confirm or cancel.

Atomic transactions are closest to traditional transactions.

Atomic transaction type coordination protocols

Coordination protocols that are part of the atomic transaction protocol type are listed below. A participant may choose to register for more than one coordination protocol at the same time for a given transaction. Registration of a participant with the coordinator using a particular coordination protocol will entail access to certain messages and their types.

Completion
The participant uses the completion protocol to tell the coordinator to either try to commit or cancel the whole activity. The application that created the transaction generally registers for this protocol.

The participant can send "Commit" or "Rollback" messages. The coordinator can send "Committed" or "Aborted" messages.

The participant begins by sending either a "Commit" or "Rollback" request; this puts the protocol in either a "Completing" or "Aborting" state. The only outcome allowed in the aborting state is for the coordinator to send an "Aborted" message, where as in the completing state, the coordinator can send either "Committed" or "Aborted".

CompletionWithAck
This protocol is similar to the completion protocol, described above, the only difference being that the coordinator must remember the outcome until an acknowledgement notification "Notified" is received from the participant that registered for this protocol.

The participant can send "Commit", "Rollback" or "Notified" messages. The coordinator can send "Committed" or "Aborted" messages.

Other messages being exactly the same as in the completion protocol; a notified message is sent by the participant to the coordinator before the coordinator releases the transaction.

PhaseZero
The participant that wants the coordinator to notify it, just before a two-phase commit begins, registers for this protocol. Applications that would typically register for this kind of protocol are the ones that have some data in a cache, which must be flushed to some persistent storage like a database, before a two-phase commit starts.

The coordinator initiates the message exchange by sending a "PhaseZero" message. The participant responds with a "PhaseZeroCompleted" message.

In a transaction, all the participants that have registered for the PhaseZero protocol must respond with a "PhaseZeroCompleted" message before a two-phase commit can be initiated.

Two-Phase Commit (2PC)
Participants subscribe to this protocol when they want to reach common agreement on the outcome of an atomic transaction.

The coordinator can send "Prepare", "Rollback" or "Cancel" messages. The participant responds with "Prepared", "ReadOnly", "Aborted" or "Committed" messages.

This protocol also makes a "presumed abort" assumption to minimize work for normal commits. The coordinator initiates the message exchange by sending a "Prepare" message to participants. Participants can respond by sending any of the following messages: "Prepared", "Aborted" or "ReadOnly". A prepared message means that the participant is ready to commit. It also means that the participant has enough information stored with it to either commit or abort the work. An aborted message means the participant won't commit and won't participate further in the transaction. ReadOnly message indicates that the participant is prepared to commit, but won't participate further in the transaction.

Outcome Notification
Participants that are only interested in finding out when a transaction has completed and what the outcome was, register for this protocol.

The coordinator initiates the message exchange by sending any of the following messages: "Committed" or "Aborted". A participant responds by sending the message "Notified". The coordinator must remember the outcome of the transaction until the notified message is received from the participant. The participant may also send a "Replay" message to the coordinator indicating that the participant is recovering. The coordinator can then again send the status of the transaction to the participant.

Business activity

This is the second coordination type that is described in WS-Coordination. The business activity protocol type is used to coordinate activities that have the following characteristics:

  • Long lived.
  • Low trust level between participants.
  • All participants may not confirm or cancel.
  • All transactions are logged.
  • For rolling back the task performed by a participant, a compensating task is performed and both are logged as separate tasks performed in time.

Business activity type coordination protocols

Business activity supports two coordination protocols:

  1. BusinessAgreement
  2. BusinessAgreementWithComplete

A participant may choose to register for more than one coordination protocol at the same time for a given transaction. Registration of a participant with the coordinator using a particular coordination protocol will entail access to certain messages and their types.

BusinessAgreement protocol
In this protocol, the child application knows when it is done with the activities that it is supposed to do. After it is finished, it spontaneously sends the appropriate message to the parent.

The parent application can send the following messages: "Close", "Cancel", "Compensate" or "Forget". The participant can send "Completed", "Faulted", "Compensated", "Closed", "Canceled" or "Exited" messages.

If the child finishes a task and does not want to participate further in the business activity, it spontaneously sends an exited message to the parent. The child can also send a completed message to the parent, if it wishes to continue participating in the transaction. At a later stage the parent can choose to send a close or compensate message to the client. Close will indicate that the changes done by the child should be finalized where as compensate tells the child that the original changes done should be compensated by doing another task that negates its effect. The child may also send a faulted message, if it fails to do a certain task. The parent responds by sending a forget message. The parent can also instruct the child to cancel the transaction by sending a cancel message. The child responds by sending a canceled message.

BusinessAgreementWithComplete protocol
The BusinessAgreementWithComplete protocol is the same as the BusinessAgreement protocol except for the fact that the child application depends on the parent to tell it when it is done with its tasks. It expects the parent to send a complete message to which it replies with a completed message.

Message exchange as per the WS-C and WS-T, between two participating applications is as depicted in Figure 1.

Figure 1. Message exchange as per the WS-C and WS-T.
Message exchange as per the WS-C and WS-T

Business activity message precedence

The process of creating a CoordinatorContext and registration of participants with the coordinator happens exactly the same way as it happens in Atomic transactions. Of course in this case, the initiating application creates a CoordinationContext with coordination type as BusinessActivity instead of AtomicTransaction.

The child application that gets the CoordinationContext from the parent application registers for the BusinessAgreement protocol. Thereafter the protocol enters the active state and starts exchanging messages as identified above.

In the active state, messages can be initiated by either party, thus there is chance that conflicting messages are sent by different parties at the same time. To resolve conflicting competing messages, the following precedence level is used:

  • Child application sends "Completed" message, parent application sends "Cancel". Completed message takes precedence over cancel.
  • Child sends "Faulted" message, parent sends "Cancel". Faulted message takes precedence and cancel is ignored.
  • Child sends "Exited" message, parent sends "Cancel". Exited message takes precedence and cancel is ignored.

Difference between atomic transactions and business activity

Resources consumed in business activity are more than those consumed in atomic transactions. Business transactions may themselves have a number of atomic transactions.

During a business activity, the states of various participants are persisted as business activity proceeds, as opposed to no intermittent state information persistence in atomic transactions.

Since intermittent state of various participants is persisted and is made visible to the outside world even before completion of the business activity, it may have a significant impact on the associated systems that see that intermittent state. In atomic transactions this is never the issue.

The key issue that business activity has to deal with is the long time that it takes for requests to be processed, ranging anywhere from a few seconds to more than a few days.

All requests are acknowledged, to detect any problems early. Atomic transaction type does not mandate acknowledgement of each request.

Response is always defined as a separate operation, because in business activity, the participant that gets the request may take a considerable amount of time to respond.

The business activity protocol also provides flexibility in creation and maintenance of a transaction involving various participants.

Business activity can be partitioned in scopes. A scope can be defined as a collection of operations that need to be executed to finish a task. The operations executed may be on different participants who participate to finish the task. A hierarchy of scopes can be created to finish a business activity. Nesting of scopes allows several things:

  • The parent can select what result it propagates further to its controlling application or its parent based on the results that its child tasks return in a scope.
  • The parent can catch the exception thrown by its child scope, apply an exception handler and continue doing processing.

A participant after registering in the business activity is allowed to leave the activity at any point in time during the transaction. This is opposite to how an atomic transaction handles its participants. Any participant once registered in an atomic transaction coordination type must confirm with the other participants, but if it chooses to cancel, forces other participants also to cancel the task.

In business activity, all participants can send out spontaneous messages without waiting for explicit requests. This allows immediate action to be initiated to take care of failures, etc. whereas in atomic transactions, messages are exchanged based on explicit requests.


OASIS proposal

The specification from OASIS is called Business Transaction Protocol (BTP). It was publicly available on 3 June 2002.

Business transaction protocol like the WS-Coordination and WS-Transaction allows various participants controlled by different organizations to collaborate together to accomplish some activity. The type of activity has the characteristics as described earlier in this article.

BTP allows two types of transactions:

  1. Atomic business transaction or atom.
  2. Cohesive business transaction or cohesion.

Atomic business transaction, as the name suggests implies that all the work is either confirmed or canceled. A cohesive business transaction allows the application to control work that is to be confirmed and work that can be canceled.

BTP defines:

  • Roles played by various participants.
  • Messages passed between participants.
  • Obligations and commitments of the participants.

Conceptual model

In each BTP participant there are two parts:

  1. Application element.
  2. BTP element.

Application element causes the associated business functions to be executed. BTP elements assist the application in getting the work done in a consistent and clean manner.

BTP requires that the BTP participants are able to support the following states to allow them to roll-forward or rollback, if required:

  • Provisional effect.
  • Final effect.
  • Counter effect.

Provisional effect is to record the change that is intended. On confirmation of go ahead, the final effect makes the provisional effect permanent. On cancellation, the counter effect makes the provisional effect void.

Support of the above mentioned states allows the BTP protocol to coordinate state changes using two phase exchange. First to get the participants to have provisional effect and then later depending on the response of other participants and the business logic, either of the other two effects can be employed.

Roles and their relations in different types of BTP transactions

Superior
Superior is a coordinator that has one or more coordinators under it behaving as inferiors. A superior could be an inferior with respect to its own superior. A superior can have multiple inferiors.

Inferior
Inferior is a coordinator that is linked to a single superior. An inferior may be a superior in another relation.

Decider
Topmost superior linked to the top most application element is called decider.

Initiator
The topmost application element at the root of the transaction tree that initiates the transaction plays the role of Initiator.

Terminator
The topmost application element at the root of the transaction tree that instructs a decider to commit or cancel plays the role of terminator.

The depth of the superior inferior tree could be arbitrarily long. Based on two criteria, one, whether the superior is inferior as well, and two, how does it treat its inferiors, atomically or cohesively, a superior may further be classified into the following sub categories.

Atom coordinator
When an application initiates a business transaction enforcing all inferiors to either confirm or cancel together, it creates a superior of the type atom coordinator.

Cohesion composer
When an application initiates a business transaction, postponing the choice of a subset of inferiors to confirm or cancel for later, it creates a superior of the type cohesion composer.

Sub coordinator
This kind of superior is created when the application element that creates it is not the top-level application element, i.e. this superior is inferior in another relation. Also, the superior created in this relation instructs its inferiors to either confirm or cancel together based on the instructions received from above.

Sub composer
This kind of superior is created when the application element that creates this is not the top-level application element, i.e. this superior is inferior in another relation. Also, the superior created in this relation defers the decision to select a subset of inferiors to confirm and others to cancel for later, based on the instructions received from above.

Participant
An inferior that directly handles application effects is called a participant. A superior that also handles application effects is not considered a participant.

Confirm set

A set of inferiors that will eventually confirm in the case of cohesion is called a confirm set. In the case of atom transactions, all the inferiors make the confirm set. All inferiors that are part of the confirm set hold a veto to cancel the whole transaction.

Business Transaction lifecycle

Business Transaction creation

Step 1 -- A business transaction is started by an application that plays the role of an Initiator. As a result, a coordinator or a composer is created. Messages that are available to participants are as follows.

Initiator sends the following messages:

  • Begin
  • Begin and Context

"Begin" message is sent if there is no preexisting context that is to be propagated. "Begin and Context" is used to propagate a preexisting context. Begin message identifies whether a coordinator or a composer is desired. These messages are sent to the factory, factory of coordinator or composers, that responds with the following message:

  • Begun and Context

Begun message provides the Initiator, which may act as terminator as well, with addressing and identification information needed for it to access a new coordinator or composer as decider.

Context message identifies the coordinator or composer as a superior. It contains addressing and identification of the relevant state information. The context also identifies whether this superior will behave atomically with respect to its inferiors.

Functionality of Begin and Begun messages may also be implemented using proprietary mechanisms.

Step 2 -- Propagation of business transaction.

Propagation of business transaction from one participant to another is the way various parties enlist in a transaction. Transmitting the context propagates a business transaction; context is commonly associated with or related to the application messages that the participants exchange.

Application element, Initiator or any other application element that is already enrolled in the transaction can send a request along with the context to another application element. The receiving application creates an enroller which in-turn creates an inferior of type sub coordinator or sub composer based on a request from above. Enroller sends the "Enroll" message to the superior attached to the sending application, which after enrolling the inferior attached to the enroller sends an "Enrolled" message back to the Enroller. Finally, the receiving application sends back a response and the Context_Reply message.

Step 3 -- Exchange of messages.

BTP messages are exchanged between two kinds of relationships:

  1. Outcome relations like Superior: Inferior and Enroller: Superior.
  2. Control relations like Initiator: Factory and Terminator: Decider.

Message exchange between control relations can be achieved using non-standard mechanisms. We will shortly describe message exchange between two applications (see also Figure 2), one acting as the initiator and terminator, the other as the enroller. Decider/superior is shown as coordinator, but with only one inferior there would be no difference between cohesion and composer. The sequence of messages is as follows:

  1. Application acting as Initiator and terminator sends a "Begin" message to the Factory that creates a coordinator which acts as superior and decider, and sends back a "Begun and Context" to the Initiator.
  2. Initiator sends a "Request and Context" to another application to enroll it in the transaction.
  3. The receiving application creates an "Enroller" which creates an inferior.
  4. The Enroller send an "Enroll" message to the superior, which in turn sends back an "Enrolled" message to the Enroller.
  5. The receiving application responds with the response and a Context_Reply message. The Context_Reply message tells the initiator that no more inferiors would be enrolled.
  6. At some time, the initiator and terminator instructs the decider to confirm the transaction by sending a "Confirm_Transaction" message to the decider.
  7. The decider sends a "Prepare" message to the inferior.
  8. Inferior sends a "Prepared" message to the decider.
  9. Decider then sends a "Confirm" message to the inferior.
  10. Inferior responds by sending a "Confirmed" message to the decider.
  11. Decider sends a "Transaction_Confirmed" message to Initiator and terminator.
Figure 2. Message exchange between the client and two participating applications.
Message exchange between the client and two participating applications

Optimizations and variations

There are various mechanisms that help optimizations and variations on the message exchange described above.

Spontaneous prepared
Inferiors must be prepared before a superior can order them to confirm or cancel. Sometimes it is possible for the application element controlling the inferior to infer that the work that inferior was supposed to do has been completed. Instead of waiting for the superior to send a "Prepare" message, it causes the inferior to be prepared and send a "Prepared" message to the superior. This saves the superior explicitly sending a prepare message.

One shot
In the normal exchange of messages between two participating applications, the following pairs of messages are exchanged:

  • Application request and response.
  • Enroll and Enrolled.
  • Prepare and Prepared.
  • Confirm and Confirmed.

A total of four messages are sent in either direction.

In one shot optimization:

  • Initiator sends an application request with context.
  • Response, Enroll and Prepared messages from receiving application are sent together to the initiator.
  • Initiator sends confirm or cancel.
  • The receiving application sends confirmed or cancelled messages.

A total of two messages are sent in either direction.

Resignation
If an application infers that the inferior it controls will do same thing in case of a Cancel-effect, if cancelled and Final-effect, if confirmed, it may ask the inferior to Resign itself spontaneously or as a response to a prepare message.

One phase confirmation
If the coordinator, composer has only one inferior in the confirm-set, it may delegate the decision to confirm-or-cancel to that inferior. Thus only one message "Confirm-one-phase" is sent instead of the two messages "Prepare" and "Confirm".

Autonomous decisions
In BTP even after an inferior has sent a "Prepared" message to its superior, it retains the right to take an autonomous decision that may be contradictory to the decision taken by the superior. BTP allows participants to specify for how long they are willing to remain in a prepared state and thereafter they are free to take an autonomous decision.

If the autonomous decision taken by a participant is in agreement with the final outcome of the transaction, everything works fine. If not, the superior records the decision of the client and sends a "Contradiction" message to the inferior. Receipt of a "Contradiction" message by the inferior tells the inferior that the superior knows about the autonomous decision taken by it and it has taken necessary action.

Autonomous decision-taking capability is critical to a number of applications agreeing to participate in BTP transactions. Autonomous decision-taking capability allows participants to come out of transactions as and when they want.


Key differences between the two approaches

In this section, we summarize the differences between the two approaches, using a set of tables.

Table 1. How business transactions are created.

BTPWS-Coordination & WS-Transaction
Business Transactions in BTP are called Cohesions.Business Transactions in WS-C and WS-T are called Business Activity.
1) Initiating application, called the Initiator, creates a Coordinator (Superior, Decider) using Factory.1) Initiating application creates a CoordinationContext of Type Business Activity as defined in WS-Coordination. Initiating application gets back CoordinationContext.
2) A new Context is created and returned to the Initiator.2) CoordinationContext is exchanged between Web services so that various Web services can participate in a transaction.
3) Initiator sends a request along with the Context to another application.3) The receiving application may or may not create its own CoordinatorContext. If a new CoordinatorContext is created, it becomes subordinate to the passed CoordinatorContext.
4) The receiving application creates an Enroller which creates a participant (Inferior).4) Receiving application can participate in a transaction by registering with CoordinationContext for a particular coordination protocol supported by the business activity coordination type.
5) Enroller then enrolls the Inferior with the Superior associated with the initiating application.5) If a new CoordinationContext was created, registration of the receiving application with the new CoordinationContext triggers registration of the new Coordinator with the CoordinatorContext what was passed to it.
6) More request messages can be exchanged between the applications.6) More request messages can be exchanged between the applications.
7) When the work has to be committed or canceled, the Initiating application playing the role of Terminator instructs the Decider to commit.7) When the work is to be committed or canceled, the application that has signed up for a particular coordination protocol, in this case either "Completion" or "CompletionWithAck", gives instructions to the coordinator attached to it to either commit or cancel.
8) Decider in-turn instructs its Inferiors to prepare and then confirm or cancel as directed.8) The coordinator, based on what coordination protocols other applications have signed up, initiates message exchange with them to prepare them and ultimately either instruct to cancel or confirm them.
9) Decider may choose to only instruct a partial set of Inferiors to confirm and may ask the rest to cancel.9) Business activity allows creation of business scopes, which allows a parent scope to choose which child tasks are included in the final outcome.
Business Scope is a business task that needs to be accomplished. For accomplishing the business task as identified in the scope, various Web services may collaborate, some of which may be asked to cancel and some may be asked to confirm. The decision to confirm or cancel different Web services is with the parent scope of the child scope.

Table 2. Traditional transaction handling.

BTPWS-Coordination & WS-Transaction
Traditional transactions are called Atoms in BTP.

Traditional transactions are initiated and handled exactly the same way as cohesions expect for the fact that once participants have registered for transactions, they cannot back out, and all of them must either confirm together or cancel together.

Traditional transaction are called Atomic Transactions or AT.

These also behave similar to business activity except for the fact that all the participants must confirm or cancel together with non of them allowed to back out.

Table 3. Security mechanisms.

BTPWS-Coordination & WS-Transaction
The available specification version at the time of writing has deferred discussion on this topic. Assumes that all actors are within a trusted domain. The following security related recommendations are made:
  • WS-Security is used to ensure messages are digitally signed and encrypted while in transit or while stored at their source or destination.
  • Ensure that any part of the message that can be independently used, like headers not specifically attached to any message, be digitally signed preventing their misuse.
  • Another potential security issue could be misuse of a replay message. To safeguard against that, a timestamp should be included with each message.

Table 4. Recovery and failure handling mechanisms.

BTPWS-Coordination & WS-Transaction
Recovery handling mechanisms in BTP are much more comprehensive and described in detail.

BTP talks about two types of failures:

  1. Communication failure.
  2. Network node failure.

Communication failure is communicated either by lower layers or may be inferred by expiry of timeout. Recovery from this requires that the participants are again able to exchange messages to continue with their transaction.

Network node failure has the added complexity that the state of the participant may also be lost. To guard against this, BTP requires that some state information be persisted despite network node failure. Exactly what information is to be persisted is the prerogative of the application.

Recovery from network node failure could involves recreating an accessible communication endpoint that has access to the persistent information for the incomplete transactions. This may be achieved in one of the following ways:

  • Recreating the original actor using the same address or a different address.
  • Creating a distinct recovery entity, which can access the persistent data but has a different address.

BTP mentions two types of recovery messages:

  1. Messages that are sent when the participants are in completion phase. In this phase, any last message that was sent can be resent again. The trigger to resend the last message is an exception from the lower layer, timeout expiry, reestablishment of communications, etc.
  2. Recovery messages that are sent when the participants are in the active state. In this state there is no appropriate last message that can be determined and sent. BTP proposes that peers can interrogate each others state by sending INFERIOR_STATE or SUPERIOR_STATE messages. The receiving application could respond by sending either the opposite message or the lost message.

BTP also proposes that a redirection address may be used to direct the messages sent by the requesting application to some alternative addresses after the participant at the original address has gone down. This could be implemented as follows:

  • Messages exchanged between participants can have a set of addresses, which are alternatives, one of which is chosen as a target address for future messages. If the sender finds that an address is not working, an alternate address could be used.
  • A redirect message can be used to inform the participant that the address previously given is no longer valid and a new replacement address is specified. This message can be sent spontaneously or when a request is received.

BTP also specifies what messages should be exchanged between a Superior and a Inferior if the Inferior chooses to contradict the confirm or cancel decision of the Superior.

Various mechanisms are available for recovery and failure handling.

Business activity can be partitioned in a hierarchy of scopes. A parent scope coordinates a child's scope.

Hierarchical business scope allows the parent scope to catch the exception thrown by the child, apply an exception handler and continue processing even if something went wrong.

When a child completes work, it is associated with a compensation that the parent may call, in case the parent wants the task done by the child to be negated.

Duplicate message handling capability should be built into the application. Messages should include a timestamp to assist applications sort duplicate messages.

All state transitions are reliably recorded, e.g on stable storage or redundant systems including application state and coordination metadata.

All request messages are acknowledged. This allows early detection of a problem.

Response is defined as a separate operation instead of the output of a request. This allows requests to be processed over a long period of time, if required.

Table 5. How applications determine which participants to confirm and which ones to cancel.

BTPWS-Coordination & WS-Transaction
Topmost application element that plays the role of Terminator may be aware of various Inferiors and what application work they are performing.

This is not required in the case of an atomic coordinator, since all the Inferiors have equal weight and any one of them can trigger the whole transaction to be cancelled.

In the case of a cohesion composer, this knowledge is a must. This allows the cohesion composer to choose which Inferiors become part of the confirm set.

Business activity is partitioned into scopes. These scopes are hierarchical in nature.

A nested scope allows a parent to actively select which child tasks are included in the overall outcome processing.

Table 6. How compensations are handled.

BTPWS-Coordination & WS-Transaction
A BTP enabled service must in some form support the following state changes:
  • Provisional effect -- The state of the application that is intended after a participant finishes the tasks.
  • Final effect -- Allows the final intended effect of the participants tasks to be realized.
  • Counter effect -- This is for negating the task done by the provisional effect.

Two-phase outcome enables a BTP enabled service to handle compensations. The first phase makes the participants apply the provisional effect; the second phase involves either applying the final effect or the counter effect.

There are several ways in which compensations are handled.

Business activity can be partitioned in scopes. A nested scope allows a parent to catch exceptions thrown by its child. The parent can apply an exception handler and as part of handling an exception, it may call a compensating operation.

When a child completes its work, it is associated with a compensation that the parent may call.

Table 7. How a participant's time limit for participating in transactions is specified.

BTPWS-Coordination & WS-Transaction
Transaction time limits are specified in three different ways:
  1. Superior can indicate the time limit for which it thinks the transaction will remain in an active state. This gives an indication to the Inferior of when it should initiate an action to cancel if the active phase continues for too long. Inferior is not bound to initiate a cancellation action on the expiry of timeout; it takes a cancellation decision at its own discretion, which could even be before the expiry of timeout. Inferior is expected to send a prepared message within the specified time limit. Superior sends this time limit on a Context message.
  2. Inferior can specify the limit of time for which it is ready to hold onto its promise when sending a prepared message. Superiors should ensure that the decisions for the Business Transactions are made before expiry of timeouts. Inferior also sends what it intends to do (e.g. cancel or confirm) if the time limit it sends with the prepared message expires.
  3. There is another time limit that a Superior specifies. This time limit allows a Superior to tell Inferiors that they should be prepared to hold on to their promises after a prepared message is sent for a minimum period of time. If an Inferior cannot or does not want to send a prepared message with at least that much, the timeout should cancel. This minimum timeout period could be present on Context, Enroll or Prepare messages sent by a Superior to an Inferior. In case the minimum timeout is on all three messages, the priority order in which they should be considered is Prepare then Enroll and then Context.
WS-Coordination provides a mechanism to specify an optional expiration date and time for the CoordinationContext that is created and exchanged between various participants. The specification does not say what should happen if the transaction lingers on after the expiration date and time.

The specification further says that each message exchanged between various participants should have a timestamp as defined in WS-Security.

A timestamp is defined as part of the Web Service Security Addendum released publicly on 18 August 2002.

A timestamp captures three important things associated with the message:
  1. Creation time -- This is creation time of the message. This can occur once in the timestamp element. Time is specified in UTC and the data type used to specify time could also be mentioned, if it is different from the default which is xsd:dateTime.
  2. Expiration time -- This is the time after which a message is considered expired. Receivers of the message after its expiration time are recommended to ignore the message and optionally can inform the requestor by sending a message expiration notification.
  3. Received -- There can be multiple received elements under a timestamp element. All the intermediaries that receive the message can add this element to the timestamp. Intermediaries are not obliged to write this element. If they do, they must specify the receipt timestamp and may specify the processing delay at their end.

Table 8. How independent decisions taken by various participants are handled.

BTPWS-Coordination & WS-Transaction
In case of Atom, it is not possible for the participants to take an independent decision.

In the case of Cohesion, it is possible that some Inferior, as part of the confirm set, may take an independent decision to either confirm or cancel after sending a prepared message to its Superior.

If the independent decision taken by an Inferior is in line with the decision of the Superior, the decision taken by the Superior is relayed to the Inferior. If there is a contradiction, the Superior sends a contradiction message to the Inferior. This indicates to the Inferior that the Superior is aware of the contradictory decision taken by it.

What a Superior does on becoming aware of a contradiction is application specific.

Participants in an atomic transaction cannot take an independent decision. All the participants take a decision together.

In the case of business activity, after a child scope has taken an independent decision to confirm or cancel, the parent scope can instruct the child scope to compensate if the parent's decision is in conflict with the child's independent decision.

Table 9. Critical state information of participants that is persisted during a transaction.

BTPWS-Coordination & WS-Transaction
BTP lists in detail the information that should be persisted. It also explains how the persisted information be used for initiating any recovery, if required.

In the case of Cohesion, it is possible that some Inferior, as part of the confirm set, may take an independent decision to either confirm or cancel after sending a prepared message to its Superior.

The information that need to be persisted includes:
  • Inferior persists:
    • Its own decision to be prepared.
    • Superior's address and identity information for Inferior to reestablish communication with the Superior.
    • Its own autonomous decision.
  • Superior persists:
    • Its own decision to confirm.
    • Inferior's addressing and identification information that the Superior can use to reestablish communication with the Inferior.
The specification mentions that all state transitions should reliably be recorded on some stable storage or some redundant system. The transitions that get stored should include the application state and the coordination metadata.

The specification does not go into detail about what information should be persisted and how can that be used, in case recovery is to be initiated.

Table 10. How dynamic addition and removal of participants from an ongoing transaction is handled.

BTPWS-Coordination & WS-Transaction
In BTP, when an application element gets a Context, the application element can choose to enroll as many Inferiors as it wishes.

For the Superior to know when the receiving application is done with the enrolment of Inferiors, it requires the receiving application to reply to the Context message with Context_Reply. This way the Superior ensures that no more Inferiors would be registered, when it is in the middle of confirming or canceling a transaction.

BTP also allows Inferiors to resign. Inferiors can resign before they send a prepared message to their Superiors, but not after that.

The business activity protocol allows a task within a business activity to leave. Providing the ability for tasks to exit business activity allows business programs to delegate processing to other scopes.

Table 11. What underlying wire protocol is supported for transmission of messages.

BTPWS-Coordination & WS-Transaction
SOAP
SOAP + Attachment
SOAP
HTTP

The current state of acceptance and development

There are some implementations already available for the OASIS specification from Hewlett Packard, Choreology, and objectweb.org. objectweb.org also provides an open source implementation.

Collaxa is one company that claims to have a WS-Transaction implementation available. IBM provides demos of WS-Transaction and WS-Coordination, but no publicly available product yet.


Conclusions

For Web services to be taken seriously by IT department heads in user companies, they have to have industrial strength transaction support that most people take for granted in traditional systems like databases. Web services have caught the interest of all and sundry who are associated in some way with the technology world. For this interest not to wane, it is imperative that key issues left unaddressed, such as transaction handling and security, are handled in a consistent manner. We have explored two competing standards for enabling transaction support in Web services. These two standards need to be merged to avoid any confusion and delay in their adoption by the user community and without jeopardizing the Web services promise of platform and technology independent integration between disparate systems.

Broadly speaking, both specifications have divided the transaction issue into two categories: Atomic transactions (like database transactions), and Business transactions, which are at the center of the problem. Both specifications define mechanisms for enrolling/registering participants in a transaction and various messages and message structures that should be exchanged between them.

There are products on the market that plan to provide implementations of both specifications. But we urgently need to merge the two proposals.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services
ArticleID=87015
ArticleTitle=Approaching Web services transactions
publish-date=02282003