Coordinating Web Services Activities with WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity
Luis Felipe Cabrera
January 28, 2004
Summary: Understand how the new WS-Coordination specification relates to the WS-AtomicTransaction and WS-BusinessActivity specifications. These specifications collectively provide the necessary mechanisms to create activities, join in activities, and reach common agreement on the outcome of joint operations across distributed systems. (22 printed pages)
3.2 Creating An Activity
3.4 Importing An Activity
3.5 Protocol Instance Termination
4.1 Two-Phase Commit (2PC)
4.2 The Coordination Protocols
4.3 What Has Changed Over Time
5.1 The Coordination Protocols
5.2 How Business Activities Differ From Atomic Transactions
The Web Service architecture provides a set of modular protocol building blocks that can be composed in varying ways to create protocols specific to particular applications. The protocols present in WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity are mechanisms to create activities, join into them, and reach common agreement on the outcome of joint operations. These specifications provide a basis on which to build interoperable, distributed applications that desire to coordinate joint work.
The operations of Web service activities that are common to explicit coordination are defined in the WS-Coordination specification. The WS-AtomicTransaction and WS-BusinessActivity specifications each define a type of agreement coordination that addresses the needs of complementary classes of activities. Both of them leverage WS-Coordination and jointly provide agreement coordination infrastructure for tightly and loosely coupled activities, whether short- or long-lived. In particular, activities that require the traditional atomic, consistent, isolated, and durable (ACID) properties of transactions are natural users of WS-AtomicTransaction. Those activities that require tentative operations that are visible to third parties before the final outcome of an activity are natural users of WS-BusinessActivity.
As Web services may belong to different enterprises, there is need to support arm's-length relationships. Each pair-wise relationship between services should be defined to include everything needed for the two parties to interoperate and reach an agreed outcome, but nothing else. These specifications achieve this goal by assuming:
- Asynchronous operation among participants
- Explicit registration in activities with pre-defined behaviors
- All communication between participants is based on a collection of mandatory messages and mandatory message exchange patterns for coordination operations
- Composition with other WS-* specifications so that additional functionality, such as reliable messaging and end-to-end secure message exchanges, can be achieved
The coordination specifications describe on-the-wire protocols, including XML schema, WSDL, state transition diagrams, and state tables. This paper supplements these specifications with our perspective on why these mechanisms are what they are, what to use them for, and when it is appropriate to use them.
To complement the agreement coordination behaviors prescribed by the protocols in WS-AtomicTransaction and WS-BusinessActivity, they compose with other WS-* specifications such as WS-Addressing, WS-Policy, WS-Security, WS-SecureConversation, and WS-ReliableMessaging. For example, in situations where WS-Policy is used to express necessary pre-conditions for successful operation, the source must have knowledge of the destination's policies, and the source must be capable of formulating messages that adhere to these policies. When a secure exchange of messages is required, then the source and destination must have a security context. Agreement coordination is independent of these other aspects of distributed applications that may be needed for a given situation.
Figure 1 illustrates the relationship between different kinds of activities and their use of the coordination specifications. For example, Activity 2 illustrates the use of atomic transactions. Activity 3, in this case, makes use of both atomic transactions and business activity. The figure also illustrates that WS-AtomicTransaction and WS-BusinessActivity build on WS-Coordination.
We introduce a collection of definitions used in this paper. We note that to fully understand the specific coordination protocols, readers should be familiar with the coordination specifications: WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity.
- Protocol: The rules of interaction between two Web services, including message formats and sequencing rules. For example, a purchase protocol would define message formats for purchase order, quote, etc., the meaning of these messages, and the constraint that a quote message should follow a purchase order message. Note that a communication protocol such as TCP/IP also satisfies this definition. Thus, protocols may be defined for different levels of a communication stack and they may nest. For example, an application protocol may use a communication protocol.
- Protocol instance: A particular usage of a protocol. For example, a purchase protocol instance would involve a single purchase.
- Activity: A set of actions spanning multiple Web services that work jointly toward a common goal. For example, making a trip reservation across hotel, airline, cruise, and auto rental reservation services.
- Activity coordination: Managing the creation of an activity, the propagation of an activity, and the agreement on the intermediate steps and outcome of an activity. This enables all the involved services to agree even when exceptions happen.
- Coordination protocol: A protocol that enables coordination. For example, the WS-AtomicTransaction two-phase commit protocol or the WS-BusinessActivity BusinessAgreementWithCoordinatorCompletion protocol.
- Coordination type: A family of coordination protocols that address a particular kind of coordination. For example, WS-AtomicTransaction defines a coordination type that is most useful for handling system-generated exceptions, such as an incomplete write operation or a process terminating abnormally. This type includes three coordination protocols.
- Coordination context: An XML element used in a message as an invitation to participate in an activity. The information includes that needed to register to participate in the activity.
- EndpointReference: Defined in the WS-Addressing specification. It contains the information needed to address a Web service end point, including the service address and optionally additional opaque information that can be used by the target service to identify a particular resource within it.
- Activation service: Defined as part of the WS-Coordination specification, it is a Web service where coordination contexts can be created.
- Registration service: Defined as part of the WS-Coordination specification, it is a Web service where other Web services can register to participate in an activity. A registration begins a coordination protocol instance by exchanging coordination and participant service EndpointReferences.
- Coordinator service: Defined as part of the WS-Coordination specification, it is a Web service that is an endpoint for a coordination protocol instance and plays the coordinator role. The semantics of the coordinator and participant roles are defined as part of the specific coordination protocol.
- Participant service: Defined as part of the WS-Coordination specification, is a Web service that is an endpoint for a coordination protocol instance and plays the participant role. The semantics of the coordinator and participant roles are defined as part of the specific coordination protocol.
- Atomic transaction: An activity that is coordinated using WS-AtomicTransaction coordination protocols. These protocols provide an all-or-nothing coordination mechanism that is useful in situations including short-lived activities within a domain of trust, and for handling system-generated exceptions that arise from hardware and software failures.
- Business activity: An activity that is coordinated using WS-BusinessActivity coordination protocols. These protocols provide a coordinated outcome useful in situations that include activities that transcend one domain of trust, those that require tentative operations whose intermediate results may be visible to third parties, and for handling application-generated exceptions.
The procedure to establish coordination between the set of participants of an activity has two stages. In the first stage, the activity is configured; one may think of this as the participants being wired together. The second stage is that in which the participants exchange messages over the wires according to the protocols that have been established. The protocols in this section represent those needed to do the initial wiring—a small set of primitive operations to establish a specific coordination protocol among participants. In particular, the WS-Coordination specification defines the following:
- A format for a CoordinationContext, which contains the information needed to request to participate in an activity.
- A protocol to create a CoordinationContext for an activity.
- How to pass a CoordinationContext in application messages as a way for one service to invite another service to participate in the activity.
- A protocol to register to participate in the activity.
These basic mechanisms can be used by any collection of Web services that desire to establish a coordinated activity.
Additional coordination types can extend WS-Coordination. WS-AtomicTransaction and WS-BusinessActivity are the first two examples of coordination types. A coordination type is identified by a URI (called the coordination type) and defines one or more coordination protocols. Each coordination protocol is identified by a URI (called the coordination protocol identifier) and defines the formats and behavior of the protocol. A coordination protocol is defined between two services. However, additional constraints can be placed on how multiple parties in the same activity may interact (see the WS-AtomicTransaction section).
The CoordinationContext also includes an "Expires" field. Each coordination type defines the exact usage of this field. As we shall see later, the meaning may be different for each type.
In Figure 2 below, we illustrate the types of service involved in coordination. The illustrated logical services can be hosted in fewer actual services in different ways. For atomic transactions, the Activation, Registration and Coordinator/Participant services on either side are typically hosted in a single transaction manager. For business activities, the application service is typically also included.
These services do not have to be combined in the same way on each side in order to interoperate. Moreover, the specifications do not mandate which services need to be in which processes. When desired, an activity may include multiple coordination services that would interact using these protocols to provide the overall coordination. The so-called one-pipe and two-pipe coordination models are supported by this infrastructure. This flexibility enables a service-oriented deployment to evolve over time in autonomous manners.
We now describe the elements of this specification in turn.
A CoordinationContext includes the following information:
- An activity identifier
- The type of the coordination (e.g., atomic transaction)
- The EndpointReference to the Registration service
- An optional expiration time for the activity
- Extensibility elements to allow other information to be communicated
An example of a CoordinationContext for atomic transactions is:
<wscoor:CoordinationContext> <wsu:Expires>2012-04-22T00:00:00.0000000-07:00</wsu:Expires> <wsu:Identifier> uuid:0f05758b-1f0d-4248-a911-90f7bd18ae52 </wsu:Identifier> <wscoor:CoordinationType> http://schemas.xmlsoap.org/ws/2003/09/wsat </wscoor:CoordinationType> <wscoor:RegistrationService> <wsa:Address> http://Business456.com/MyCoordinationService/RegistrationCoordinator </wsa:Address> <wsa:ReferenceProperties> <mstx:ex xmlns:mstx=http://schemas.microsoft.com/wsat/extensibility mstx:transactionId="uuid:cfb01dc0-5073-405a-a3aea6038ecc476e"/> </wsa:ReferenceProperties> </wscoor:RegistrationService> </wscoor:CoordinationContext>
Like all EndpointReferences, the ReferenceProperties are opaque to all but the service that created them. The service using them blindly copies these into headers in messages directed to this EndpointReference. This example uses an internal transaction identifier that it maps onto the CoordinationContext identifier.
To create a CoordinationContext, the WS-Coordination specification defines an Activation protocol with the following two messages:
- The CreateCoordinationContext message targets an ActivationService, and provides an optional CurrentContext parameter that is a CoordinationContext for an existing activity. This parameter causes the activity to be imported instead of created. Import is described later.
- CreateCoordinationContextResponse message returns the newly created CoordinationContext.
Although the above messages have a request-response pattern, each message is a separate operation to support asynchronous usage. An activation protocol instance consists of a CreateCoordinationContext message followed by a CreateCoordinationContextResponse message.
It is consistent with this specification that a given service creates an activity context by completely private means. All that is needed is for the service to possess all the necessary information. This context could then be sent to participants.
Figure 2 also illustrates the sequence of messages in a simple scenario:
- Sending a CreateCoordinationContext message to the Activation service creates an activity. The optional CurrentContext parameter is absent, so a new activity is created and the returned CoordinationContext has a new activity identifier and Registration service A.
- The CoordinationContext is propagated from application services A to B as a SOAP header in an application message. This acts as an invitation to application service B to participate in the activity using one of the coordination protocols for that coordination type. The service that receives this invitation can either register to participate or not.
- Service B registers using the Registration service A from the propagated context.
- The coordination protocol instance can then begin between the participants.
Registration is the explicit operation done to become a participant in an activity. To register to participate, the WS-Coordination specification defines a Registration protocol with the following two messages:
- The Register message targets the Registration service it got from the CoordinationContext, and provides the name of the protocol it wants to register for and the Participant service's EndpointReference.
- The RegisterResponse message provides the Coordinator service's EndpointReference.
A registration protocol instance consists of a Register message followed by a RegisterResponse message.
The Participant service and Coordinator service that are exchanged in this registration protocol are the two endpoints used for the coordination protocol instance. Each of these services includes in its EndpointReference ReferenceProperties whatever "cookies"—namely private data opaque to all other services—it needs to get back as headers in the coordination protocol messages, so that it knows what coordination protocol instance the message belongs to. An example Register message containing a Participant service EndpointReference is:
<wscoor:Register> <wscoor:Protocol> http://schemas.xmlsoap.org/ws/2003/09/wsat#Durable2PC </wscoor:Protocol> <wscoor:ParticipantProtocolService> <wsa:Address>http://Schedule456/DurableParticipant</wsa:Address> <wsa:ReferenceProperties> <mstx:ex xmlns:mstx="http://schemas.microsoft.com/wsat/extensibility" mstx:transactionId="uuid:30cce6ae-c828-4e13-bbc2-957beaf1e942" mstx:enlistmentId="73ff2d16-177e-4bc1-8748-7abc0dde3f3b" mstx:ordinal="317"/> </wsa:ReferenceProperties> </wscoor:ParticipantProtocolService> </wscoor:Register>
An example of a RegisterResponse message containing a Coordination service EndpointReference is:
<wscoor:RegisterResponse> <wscoor:CoordinatorProtocolService> <wsa:Address>http://Business456/DurableCoordinator</wsa:Address> <wsa:ReferenceProperties> <mstx:ex xmlns:mstx="http://schemas.microsoft.com/wsat/extensibility" mstx:transactionId="uuid:aa89673c-355c-400b-8ab9-3d4cda0e3c71" mstx:enlistmentId="185f3eca-c7c6-48f5-99bf-f5375d4446a5" mstx:ordinal="961"/> </wsa:ReferenceProperties> </wscoor:CoordinatorProtocolService> </wscoor:RegisterResponse>
These ReferenceProperties include internal identifiers for the transaction and the particular registration, as well as an index for internal performance.
Once the RegisterResponse message has been sent, the coordinator service is ready to handle the newly created coordination protocol instance. Once the RegisterResponse message has been received, the Participant service is ready to handle the newly created coordination protocol instance.
The Activation protocol can be used for importing an activity to a different set of coordination services. Importing an activity has several motivations. For example, it allows an application to use an intermediary set of coordination services that it prefers to deal with directly due to performance, trust domain, or control reasons. In a federated environment of autonomous services, this is especially necessary given the arbitrary trust relationships that may exist between them. Sometimes this procedure is also called interposition.
In Figure 4, after the import of the activity or the interposition of the trusted coordinator service B, Application B can deal with its own coordination services, which in turn deals with A's coordination services. Figure 3 illustrates importing:
- Create the activity and receive a CoordinationContext.
- Propagate A's CoordinationContext to B in an application message.
- B has a choice of whether to deal directly with A's coordination services, as in Figure 2, or use another set of coordination services as its representative. It decides to import the activity to B's coordination services by sending its Activation service the CreateCoordinationContext message with the context from A as the optional CurrentContext parameter. The returned CoordinationContext has the same activity identifier, but has B's Registration service.
- Register B with its own Registration service obtained from its CoordinationContext identifier.
- B's coordination services delegate the registration to A's Registration service, which it obtained from the CurrentContext parameter during import. This creates a new coordination protocol instance between A and B.
- The coordination protocol instance can then begin between the participants A and B.
Application A does not "see" the differences between Figures 2 and 3.
Figure 4 illustrates the effect that import has when B further propagates the activity to C, forming a coordination hierarchy:
- Create the activity and receive a CoordinationContext.
- Propagate A's CoordinationContext to B in an application message.
- Import the activity to B's coordination services by sending its Activation service the CreateCoordinationContext message with the context from A as the optional CurrentContext parameter. The returned CoordinationContext has the same activity identifier, but has B's Registration service.
- Register with the coordination service B. This makes B's coordination service register with A's coordination service, creating a new coordination protocol instance between both coordination services.
- The coordination protocol instance between A's coordination service and B's coordination service can begin.
- Propagate B's CoordinationContext to C in an application message.
- Import the activity to C's coordination services by sending its Activation service the CreateCoordinationContext message with the context from B as the optional CurrentContext parameter. The returned CoordinationContext has the same activity identifier, but has C's Registration service.
- C registers with the coordination service C. This makes C's coordination service register with B's coordination service, creating a new coordination protocol instance between the B and C coordination services.
- The coordination protocol instance between B and C can begin.
The approach depicted in Figure 4 allows B to supply intermediary coordination handling and to hide B's use of A from C. The resulting two coordination protocol instances form a hierarchy. In this example, B's coordination services play both the participant role in the coordination protocol instance with A, and coordinator role in the coordination protocol instance with C.
The WS-Coordination specification does not define a protocol for terminating a coordination protocol instance. Termination is specific to a coordination protocol, and thus is part of that protocol definition. For example, the coordination protocols for WS-AtomicTransaction and WS-BusinessActivity have different requirements for the participants on how to terminate.
The protocols defined in this section capture the agreement coordination properties used in existing environments in which processing is based on the well-understood atomic transactions. They enable preservation of existing software investments when adopting a Web service environment. In particular, they provide a means to achieve interoperability within an organizational structure. They also provide simple agreement coordination protocols for closely coupled systems that desire all-or-nothing outcomes.
Atomic transactions greatly simplify application programming by shielding the application from system-generated exceptions, especially when they do not recur on retry. For example, an intermittent hardware failure may cause a disk access error that may not manifest itself on retry. Other examples are when the process crashes the application it is executing in, a database that has a deadlock, or a network that fails to ship a message. Without atomic transactions in cases like these, the application would have to determine exactly where it was when it stopped, and then determine how to get back to a consistent state. The recognition of this pattern and the realization that this part of the application logic could be automated with transaction management and resource managers was the beginning of the world of atomic transactions. Later, the realization was made that multiple resource managers could cooperate using a two-phase commit (2PC) protocol. (1)
The atomic transaction 2PC protocol coordinates registered services to reach a commit or abort decision, and informs all services of the final result. The decision is the same for all the services in the transaction. Making this group decision uses two phases:
- Prepare phase: All participants are asked to get ready to either commit or abort, and then vote on the overall outcome. The vote is propagated up to the root coordinator to make the overall group decision.
- Commit phase: If all participants vote to commit, the decision will be to commit. Otherwise, it will be to abort.
Although a coordination protocol defines a two-party interaction, the above 2PC protocol is an example of how it can also constrain the interaction between multiple services.
With atomic transactions, there is a strong division of function between an application and coordination. The application determines which services are included in the transaction, and when to either commit or abort. After this, coordination takes over deciding the outcome without application involvement.
An atomic transaction provides a simple programming model abstraction by making the following assumptions:
- Updates are hidden (isolated) until they are committed. For even the weakest database isolation levels, write locks are held on updated data until the end of the transaction, so that updates are hidden from view by other transactions until commit. When a transaction spans multiple systems using 2PC, all of these systems hold write locks until commit, so the systems must trust each other to be responsive.
- There is a single all-or-nothing decision for all participants. Any one of the systems can abort the entire atomic transaction, so these systems must trust each other to have cooperative intentions.
- The 2PC protocol also requires that services in the Prepare phase waiting for the final outcome to be communicated by the coordinator do not drop unilaterally their participation in the activity. This is quite a stringent constraint, as the Prepare phase may be of long duration, so these systems must trust each other to be responsive.
An atomic transaction should not span systems that cannot establish these forms of mutual trust.
The 2PC protocol further requires that the Expires time in the CoordinationContext be interpreted as follows: if the expiration time is reached before the end of the Prepare Phase of the 2PC, then the transaction has to abort. Once the Prepare Phase of 2PC has completed, the Expires time has no influence in the outcome of the transaction. In effect, it is ignored from then on.
The three coordination protocols for atomic transactions specified in WS-AtomicTransaction are the following:
- Completion: An application uses this protocol to tell the coordinator to either try to commit or abort an atomic transaction. Upon receiving a Commit or Rollback message, the coordinator begins with Volatile2PC prepare phase and then proceeds through Durable2PC. The final result is signaled to the Completion protocol participant. This protocol does not guarantee that the message with the final outcome be delivered to the participant.
- Volatile2PC: Participants managing volatile resources, such as a cache, should use this 2PC protocol. Upon receiving a Completion protocol Commit message, the root coordinator begins the prepare phase of all participants registered for the Volatile2PC protocol. All participants registered for this protocol must respond before a Prepare message is sent to a participant registered for the Durable2PC protocol. Additional participants may register with the coordinator until the coordinator issues a Prepare to any durable participant. This protocol does not guarantee that the message with the final outcome be delivered to the participant.
- Durable2PC: Participants managing durable resources such as a database, a transactional file system or a durable queue service should use this 2PC protocol. Upon completing the prepare phase for Volatile2PC participants, the root coordinator begins the prepare phase for Durable2PC participants. All participants registered for this protocol must respond Prepared or ReadOnly before a Commit notification is issued to a participant registered for either protocol. This protocol guarantees that the message with the final outcome will be delivered to each of the participants.
While the traditional 2PC protocol is well understood and has not changed in decades, the environment for processing transactional activities has evolved. It is now commonplace in computing centers to have multiple tiers of services. For example, in typical Web applications, front-end presentation servers farm out work to the middle-tier application-logic servers. In turn, these middle-tier servers cache appropriate application state and access the back-end databases where the state being managed by the applications ultimately resides. Supporting this requires additional coordination infrastructure. For example, to enable flushing their updated cached state to the back-end servers, the middle-tier participants need to be notified before 2PC begins. In the WS-AtomicTransaction specification, this is achieved by the Volatile2PC protocol, where the prepare phase is always executed prior to executing the Durable2PC protocol.
A second extension comes from the need to initiate a 2PC coordination protocol from outside one of the coordinators involved in the agreement. It has become commonplace for applications that do not share the same coordinator as databases to be the ones that know when 2PC should begin. In the WS-AtomicTransaction specification, this is achieved by the Completion protocol.
Figure 5 illustrates the sequencing of the messages at commit for the scenario of a successful commit. There are three participants, one for each of the above protocols:
- When all of the work has completed, the Completion participant (i.e., the application) initiates the commit process by deciding to try to commit and by sending a Commit message to the Coordinator. The Coordinator initiates the prepare phase on the Volatile2PC participant by sending a Prepare message. Each Volatile2PC participant signals that it has successfully finished preparing by sending a Prepared message.
- The Coordinator initiates the prepare phase on the Volatile2PC participant by sending a Prepare message. Each Volatile2PC participant signals that it has successfully finished preparing by sending a Prepared message.
- When all Prepared messages have been received from Volatile2PC participants, the root Coordinator initiates the prepare phase on the Durable2PC participant by sending a Prepare message. Each Durable2PC participant signals that it has successfully finished preparing by sending a Prepared message.
- When all Prepared messages have been received from Durable2PC participants, the root Coordinator decides to commit, sends the Committed message to the Completion participant, and sends the Commit message to both the Volatile2PC and Durable2PC participants. There are no ordering constraints among the 4a, 4b and 4c messages.
A business activity service is expected to use multiple atomic transactions to move the application from one consistent state to another. This leverages atomic transactions to handle system-generated exceptions, so that business activity coordination need handle only application-generated exceptions.
The WS-BusinessActivity coordination protocols provide a standard way for application code to drive toward an overall agreement while preserving their autonomy, even when application-generated exceptions occur. This agreement can involve a single pair of services or multiple pairs of services.
Each business activity should handle a single coordination agreement. When an application involves multiple different agreements, then multiple business activities should be used.
As an example of an activity involving a single pair of services, a buyer service sends a purchase order to a seller service. The seller either provides a quote that is good for some duration of time, or declines. The buyer decides whether to buy or cancel.
As an example of an activity involving multiple pairs of services, a buyer service sends a purchase order to multiple seller services. Some sellers will provide a quote that is good for some duration of time, while others will decline. The buyer service picks one of the quotes according to its standard selection criteria and tells the other sellers to cancel.
In both of the above cases, the WS-BusinessActivity coordination protocols add a standard structure to the application, but allow arbitrary application logic to handle the coordination.
WS-BusinessActivity defines two coordination protocols that differ only in the knowledge of when a unit of work has been completed.
- BusinessAgreementWithParticipantCompletion: The participant knows when the coordinator will ask no more work of it.
- BusinessAgreementWithCoordinatorCompletion: The coordinator has to tell the participant that no more work will be asked of it.
These protocols are considered to be of "broadest coverage". An application should use as much of these protocols' flexibility as needed. Some two-party interactions may avoid using some of the legal paths through the state diagrams presented in WS-BusinessActivity.
Like an atomic transaction, a business activity deals with coordinating agreement among participants performing multiple distributed actions. However, business activities have distinctly different operational characteristics, which are described in the following points:
- Type of exceptions: A business activity is aimed at handling application-generated exceptions that require application logic to resolve to continue progress toward a desirable goal. For example, knowing whether a participant has completed its work (and therefore requires a fee to compensate) may affect the decision of the coordinator. An atomic transaction is aimed at handling system-generated exceptions that are contained within the computer system. Atomic transactions provide a way to easily return to a consistent state, so that the exception can be handled by retrying the transaction or by manual intervention. Thus, when an application error can be treated as an atomic transaction rollback, atomic transactions provide a simple and robust mechanism for programming applications.
- Duration: A business activity typically occurs over many minutes, or over days, weeks, or months. An atomic transaction typically happens almost instantaneously.
- Isolation: A business activity does not hold locks throughout its agreement phases, so it has weaker isolation characteristics than atomic transactions. Resource availability problems occur when locks are held for user input or a real-world event such as the arrival of a shipment. Thus, in business activities, intermediate steps become visible, sometimes outside of the computer system. Even though the actions are tentative, they become part of real-world history. This increases resource availability by releasing locks between steps, but makes applications more complex by requiring them to program compensating actions.
- Durability: Because a business activity is aimed at handling application-generated exceptions in order to keep moving forward toward a desirable goal, its state is typically saved between steps. Because a business activity is used as a solution for activities of long duration, durability is needed to avoid holding physical resources other than disk space (e.g., threads, connections, memory).
- Agreement scope: A business activity is aimed at handling application exceptions, so its coordination involves application logic. For example, when a business activity coordinator receives a Faulted message from one of its participants, its action is determined by application logic. This makes each pair-wise interaction independent in a business activity, so there is not necessarily a global decision.
- Combined services: A business activity involves business logic in its coordination, so that coordination typically requires access to application state. This close relationship makes it more convenient to combine the application and coordination into a single service, so that the application state required for coordination is available. Separating these services requires additional application-specific protocols between the two services.
- Diverse operational characteristics: The business activity protocols enable services to have different operational behaviors. For example, services need not be simultaneously up, or the latency of message delivery among participants may be substantially different over time, yet agreement can still be reached.
- Fewer constraints in coordinator behavior: The business activity protocols do not mandate any behavior on the coordinators. For example, a coordinator may use the all-or-nothing logic among its participants to determine the outcome of an activity. Or, it could use an "only one winner" behavior among its participants.
- Expires time: The Expires time in the CoordinationContext is interpreted differently in a business activity. The Expires time represents a time after which participants can unilaterally leave the activity. This interpretation assumes that the expiration time was reached because some large failure happened. Thus, it is appropriate for participants to finish up their participation in the activity in the most appropriate manner.
Figure 6 illustrates a Buyer service that asks for quotes from three Seller services and picks the best deal:
- The Buyer service sends each Seller a PurchaseOrder message with a CoordinationContext header. These messages can all be sent at the same time.
- All three Sellers register for the BusinessAgreementWithParticipantCompletion protocol.
- From this point on, each of the 3 Sellers have different flows:
- Seller A cannot make a quote. It notifies the Buyer using the coordination protocol Fault message with message's ExceptionIdentifier parameter to indicate this.
- Sellers B and C can make a quote. They each notify the Buyer using the coordination protocol Completed message with price information included in the message using the extensibility elements of the protocol messages.
- After looking at the quotes from Sellers B and C, the Buyer chooses B.
- It notifies B with the coordination protocol Close message.
- It notifies C with the coordination protocol Compensate message. This compensation may require the Buyer to pay a handling fee.
WS-Coordination provides uniformity for the creation, propagation, and joining of a distributed activity. WS-AtomicTransaction and WS-BusinessActivity extend this with agreement coordination protocols. Together they provide coordination mechanisms to handle exceptions from a wide variety of sources, ranging from hardware to software to the real world. In conjunction with other Web services standards, we expect them to be useful for applications where the scope spans from an organization within an enterprise, across different organizations in an enterprise, across enterprises, and across different vendor platforms.
We are grateful to Omri Gazitt, Johannes Klein, Rodney Limprecht, Matt Powell, Rebecca Dias and Brad Lovering for providing us with valuable feedback in the creation of this white paper.