Section 11.3. Architectural Concepts

11.3. Architectural Concepts

11.3.1. Definition of Transaction Architectural Terms

The previous section discussed some of the basic principles of transactions and their application in example scenarios. The next section places this discussion in a Web services context, and identifies those specifications that provide the overall architectural framework for supporting transactions in the world of Web services.

Coordination

WS-Coordination defines a generic framework that allows an application to identify related operations across Web services and to enable management of any required processing when the activity ends. WS-Coordination defines protocols and services that do the following:

• Provide a context to identify Web service operations as part of a particular activity

• Allow Web services to register interest in participating in the activity outcome

• Allow the selection of a coordination protocol to be performed between the coordination service and participating Web services at completion of the activity

WS-Coordination can support any arbitrary coordination protocol. Coordination requires that one party act as the coordinator who is responsible for tracking participants involved in an activity and to execute the specified coordination protocol at activity completion. In addition, you can use WS-Coordination in scenarios other than supporting transactions. For example, an activity might do the following:

• Exploit the identifier value that is contained in the context associated with the activity to perform simple correlation across all the participating services

• Use an activity completion notification to supply a more simplified completion processing, such as to perform resource reclamation

• Define additional completion protocols, for those situations in which WS-Atomic Transaction or WS-Business Activity does not meet the application needs, such as a three-phase commit protocol.

WS-Atomic Transaction and WS-Business Activity define two specific completion processing patterns to meet the common transaction processing requirements in the industry today.

Protocols for Atomic Transactions (WS-Atomic Transaction)

The protocols for atomic transactions typically handle activities that are short lived. Atomic transactions are provided through a two-phase commitment protocol. The transaction scope states that all work is either successfully completed in its entirety, or not at all. In other words, if an activity is successful, all changes resulting from operations performed during the activity are made permanent and visible. Alternatively, if the activity fails to complete successfully, none of the changes that the activity makes are made permanent and visible.

Protocols for Business Transactions (WS-BusinessActivity)

The protocols for business transactions handle long-lived activities. These differ from atomic transactions in that such activities can take much longer to complete. Also, to minimize latency of access by other potential users of the resources, the results of interim operations need to become visible to others before the overall activity has completed. In light of this, mechanisms for fault and compensation handling are introduced to reverse the effects of tasks previously completed within a business activity (such as compensation and reconciliation).

You can use the protocols in combination with each other. For example, short-running atomic transactions can be part of a long-running business activity. The actions of the embedded atomic transactions might be committed and made visible before the long-running business activity completes. Also, if a long-running business activity fails, you need to compensate for the effects of such atomic transactions. An example is multilevel transactions [Gray 1993].

11.3.2. Services and Protocols

This section covers more details about the architecture, services and protocols that are defined and implied by the WS-Coordination, WS-Atomic Transaction and WS-Business Activity Web Service specifications.

WS-Coordination Service

The WS-Coordination specification is focused on the notion of an activity. An activity is defined as a computation carried out as tasks on one or more Web services. An activity has a lifecycle; it is created, runs, and completes. This process can also be termed an activity scope. WS-Coordination specifies operations to demarcate the activity through the activation service, identify the activity by creating and passing a context along with a Web service operation, and record the Web services that are interested in completion processing through the registration service.

The following elements are associated with the coordination architecture:

• Activation service

• Context

• Registration service

• Coordination protocol

Figure 11-8 illustrates application operations, coordination contexts, and coordination operations among service requestor, service provider, coordination service, coordinator, and participant.

Figure 11-8. Web service transaction elements.

These elements work as follows:

1. Activation The WS-Coordination activation service creates a new activity and returns a context containing an identifier that uniquely distinguishes a particular work scope. Furthermore, activation defines the coordinator who is responsible for managing the coordination protocol processing and specifies the coordination protocols that are supported (WS-Coordination, CreateCoordinationContext).

2. Context The context that is returned at activation is passed along with the Web services operations and used to identify the operation as contained within the activity scope.

3. Registration The Web service that is receiving an operation with context might register for inclusion in the outcome processing that is associated with the activity completion. Further, the registration selects from the coordination protocols that are supported (WS-Coordination, Register).

4. Coordination Protocol A protocol service (such as WS-AtomicTransaction or WS-Business Activity) provides the logic to drive a specific completion-processing pattern.

The operations and messages for the services are defined using WSDL.

Context

Context is a container for sharing processing information between Web services. An XML type of Context is defined that specifies an identifier and an optional expiration element. The identifier is a uniform resource identifier (URI) that identifies related groups of messages. The CoordinationContext is a distinct context type that is defined to pass specific Coordination information to the participants who are involved in a transaction.

For an activity to span a distributed environment, the context information must be associated with application messages that are destined for a service. Implementations generally append context to the application message at the source to establish the execution environment at the target.

For each newly created transaction, the activation service returns a coordination context that contains the following:

1. Identifier A unique name to identify the CoordinationContext.

2. Expires An activity timeout value.

3. CoordinationType A defined set of coordination protocols that describe a specific completion-processing behavior.

4. Registration Servicea Address [WS-Addressing] of the registration service. The Web service registers interest and participation in a coordination protocol to determine the overall outcome of the activity.

5. Extensibility element Provides for optional product-specific extensions.

Activation Service

The activation service uses CreateCoordinationContext (see Figure 11-9, step 1) to do the following:

• Begin a new transaction

• Specify the coordination protocols that are available to the activity

Figure 11-9. Web service transaction flow.

The CreateCoordinationContextResponse returns a context that contains an identifier for the newly created transaction and the address of the registration service for the transaction (see Figure 11-9, step 2).

In addition, the activation service optionally allows the user to specify a relationship between activities. This relationship might be a superior-subordinate or parent-child nested relationship between the activities, as explained later in the Travel Agent scenario examples.

Registration Service

The registration service Register allows a Web service to register its interest in participation in the completion processing of the activity and to select the specific protocol to be used for this activity. Enrollment and selection allow the Web services involved in the activity to establish the traditional roles of coordinator and participant (see Figure 11-9, steps 4 and 5).

Transaction Protocols

The WS-Atomic Transaction and WS-Business Activity specifications define two completion-processing patterns (specifically transaction coordination protocols) that are common within the industry. These transaction coordination protocols provide the coordination service that the WS-Coordination framework defines (Figure 11-9, step 7).

Each supports the semantics of a particular kind of business-to-business (B2B) interaction:

• Atomic Transaction (AT) This maps to existing ACID transaction standards. Remember that Web services are meant to promote interoperability between software applications. Historically, enabling traditional transaction systems to communicate with one another was a goal that was rarely achieved. However, mergers, acquisitions, or consolidations continue to stress the need to readily combine applications across the new business. Because traditional transaction systems currently form the backbone of enterprise-level applications, any solution must continue to accommodate these needs in a Web services environment.

• Intra-Enterprise AT is useful for intradomain environments in which a customer needs to consolidate operations across various internal applications.

• Inter-Enterprise B2B activities might require interoperability with existing transaction systems. Although such environments usually lend themselves to utilizing the more flexible facilities provided by extended transactions, if needed, existing transaction processing systems can be tied together directly using the atomic transactional protocol.

• Business Activity (BA) accommodates the requirement for a more flexible style of activity outcome processing than those that have strict ACID semantics. BA is designed specifically for loosely coupled and lengthy interactions, in which holding onto resources until completion is impossible or impractical. In this model:

  • The requirements for the properties of both atomicity and isolation are significantly relaxed. Services are requested to perform work (such as reserve a seat on a flight) in a manner in which the result of the work can be directly exposed. (For example, the seat assignment can be posted.) However, they must do so with an assumption that the work can be undone later. (The reservation can be cancelled and the seat can be reallocated.)

  • In addition, some of the work might not be included in the overall outcome. (For example, a reservation system might choose among several airlines and select the lowest available fare or most convenient flight.)

In this way, if it is subsequently decided that the work done needs to be cancelled, BA can inform the service. How services do their work and provide compensation mechanisms is generally specific to the application and is not defined by the WS-BusinessActivity specification. It's an implementation decision for the service provider. Note that the BA model has a relationship with the specific industry requirements for workflow interoperability. (For more detail, see the WS-BPEL specification [BPEL4WS]).

The WS-Atomic Transaction and WS-Business Activity coordination types provide the following transaction coordination protocols:

• WS-AT:

  • Completion

  • VolatileTwoPhaseCommit

  • DurableTwoPhaseCommit

• WS-BA:

  • BusinessAgreementWithParticipantCompletion

  • BusinessAgreementWithCoordinatorCompletion

Although AT and BA protocols match the needs of the current customer transactional use cases, they might not cover all requirements, and additional completion protocols might be required. Such an approach (as illustrated in Figure 11-10) is adaptable and allows for additional specifications to be defined and added as needed. By defining a clear separation between coordination framework and completion protocol, WS-Coordination can support a spectrum of completion processing.

Figure 11-10. Web service coordination protocols.

One important aspect of a Web service environment that differentiates it from traditional transaction processing environments is that a synchronous request/response model is not required. WSDL allows binding to a variety of interaction styles.

The transaction protocol specifications WS-Atomic Transaction and WS-Business Activity leverage the framework provided by WS-Coordination in two ways:

• First, they allow a WS-Coordination context to be augmented with protocol-specific information to create a transaction context.

• Second, they augment the activation and registration services with additional protocol services and associated protocol message sets.

WS-Atomic Transaction

WS-Atomic Transaction (WS-AT) is a protocol that enforces uniform outcome across all its participants. Updates are invisible outside the transaction and resources are locked for the duration of the transaction. Environments that require classic ACID transaction semantics utilize WS-ATs.

Completion Protocol

The application uses the completion protocol to direct the transaction protocol to complete an activity. The application indicates whether the desired outcome is successful (issues a Commit for the transaction) or unsuccessful (issues a Rollback for the transaction). The transaction protocol then executes and returns the outcome to the application.

To recap, when an application begins an atomic transaction, the client application establishes a coordinator that supports the WS-AtomicTransaction protocol. The client uses the WS-Coordination Service and might send a CreateCoordinationContext message to the activation service specifying the coordination type and get back an appropriate WS-Transaction context. Alternatively, the client can manufacture the appropriate context for those cases in which the client has decided not to avail itself of an activation service. The transaction context has its CoordinationType element set to the WS-Transaction AT namespace. It also contains a reference to the atomic transaction coordinator endpoint (the WS-Coordination registration service), where potential participants can be enlisted.

The client application registers for the Completion protocol so that it can later direct the outcome of the transaction. It then proceeds to interact with Web services to accomplish its business-level work. With each invocation on a Web service, the context is propagated along with any messages. This ensures that the transaction explicitly scopes each invocation.

After all the necessary application-level work has been completed, the application finishes the transaction by instructing the coordinator either to commit (see Figure 11-11, where the application finishes and the transaction is successful, and Figure 11-12, where the application finishes and the transaction is unsuccessful) or roll back the transaction (see Figure 11-13, where the application instructs the transaction to terminate).

Figure 11-11. Completion protocolsuccessful transaction.

Figure 11-12. Completion protocoltransaction failure.

Figure 11-13. Completion protocolapplication failure.

Durable Two-Phase Commit Protocol

Transaction completion uses the Durable Two-Phase Commit (2PC) protocol to perform the classic atomic transaction processing, as described earlier. Here, a two-phase commitment protocol ensures that the work is completed atomically. Note that the WS-AT specification implies no ordering of Durable 2PC participant invocations. As illustrated in Figure 11-14, during Phase 1, the coordinator sends Prepare to the transaction participants. Each participant returns Prepared, thereby successfully completing Phase 1. During Phase 2, the coordinator indicates the successful outcome, sending Commit to all the participants. All the participants return Committed to acknowledge the outcome.

Figure 11-14. Successful two-phase commit.

As illustrated in Figure 11-15, during Phase 1, the coordinator sends Prepare to the transaction participants. However, one or more of the participants returns Aborted, thereby causing an unsuccessful completion of Phase 1. During Phase 2, the coordinator indicates the unsuccessful outcome, sending Rollback to all the remaining participants. The participants return Aborted to acknowledge the outcome.

Figure 11-15. Unsuccessful two-phase commit.

Volatile Two-Phase Commit Protocol

In addition to the Durable 2PC protocol, WS-AT provides the Volatile 2PC protocol. Accessing durable storage (whatever its implementation) is often a performance bottleneck, and operating on the cached contents of the durable storage (such as an entire database table) for the length of the transaction can often significantly improve performance. However, you need to force that data back to the original persistent store prior to the transaction committing.

When an atomic transaction is finishing, the coordinator executes the Volatile 2PC protocol if any participants are registered for it. The coordinator informs all Volatile 2PC participants that the transaction is about to complete by sending them a Prepare before any of the Durable 2PC participants. That way, the participants can perform any outstanding work and respond with a Prepared, ReadOnly, or an error message indicating Aborted. Any failures at this stage cause the transaction to roll back.

Volatile 2PC participants and other Durable 2PC participants are informed of the outcome decision at Phase 2 via the Commit or Rollback. As illustrated in Figure 11-16, during Phase 1, the coordinator sends Prepare to the volatile transaction participants. After the volatile participants return Prepared, the coordinator sends Prepare to the durable participants. During Phase 2, the coordinator indicates the successful outcome, sending Commit to both the volatile and durable participants.

Figure 11-16. Two-phase commitvolatile/durable order.

WS-Business Activity

Most B2B applications require transactional support to guarantee consistent outcome and correct execution. Also, such applications often involve long-running computations across loosely coupled systems and components that do not share data, location, or administration. In most cases, the use of atomic transactions within such architectures is inappropriate. For example, an online bookshop might reserve books for an individual for a specific period of time. However, if the individual does not purchase the books within that period, the store puts the books back on the shelf for others to buy. Furthermore, because it is not possible for anyone to have an infinite supply of stock, some online shops might appear to users to reserve items for them but, in fact, might allow others to pre-empt that reservation. (For example, the shop might concurrently reserve the same book for multiple users.) A user might subsequently find that the item is no longer available, or he might have to reorder the item especially for him.

A BA is designed specifically for these kinds of lengthy interactions, in which exclusively locking resources over extended periods of time is impossible or impractical. In this model, services are requested to do work, and when those services can compensate for work done, they inform the BA such that if the BA later decides to cancel the work, it can instruct the service to execute its compensation behavior.

Although a BA doesn't maintain the full ACID transaction semantics, it can maintain overall consistency through compensation. However, the task of writing correct compensating actions (and thus overall system consistency) is delegated to the developers of the services. Such compensations might use backward error recovery, but they more generally employ forward recovery or a combination of both backward and forward recovery. WS-Business Activity defines a protocol for Web services-based applications to enable existing business processing and workflow systems to interoperate across implementation and business boundaries.

An application might be partitioned into scopes. A scope is a specific collection of Web service operations. Such scopes can be nested to arbitrary levels, forming parent and child relationships. A parent can select which children to include in the overall outcome protocol, thereby making nonatomic outcomes possible. The WS-Business Activity protocol defines a consensus group that allows the relaxation of atomicity based on business-level decisions. In a similar manner to nested transactions, if a child experiences an error, a parent might catch it. If this happens, the parent might be able to compensate and continue processing.

Scopes and the parent-child relationship that nesting provides are important for many reasons, including the following:

• Fault-isolation A scope failing (perhaps because a service it was using fails) does not necessarily mean the enclosing scope will fail, thus undoing all the work performed so far.

• Modularity Work is logically partitioned into scopes such that the tasks that span business boundaries are accommodated using well-formulated concepts exhibited by existing workflow systems. If a scope is already associated with the invocation of a service, within which a new scope is begun, the new scope is nested within it. If the service is invoked without a parent scope, the service's scope is simply top level.

When a child completes, it signals to the parent that the work it has done can be compensated later if required. The parent performs compensation if it needs to reverse the effects of the work that the child performed.

Unlike the atomic transaction protocol, in which participants inform the coordinator of their state only when specifically requested to do so, a child can specify its outcome to the parent without solicitation. This feature is helpful when an operation fails because the application's exception handler can use the notification to modify the goals and drive processing forward without having to wait until the end of the transaction. A well-designed application using the WS-Business Activity protocol should be proactive, if it is to perform well.

Underpinning all of this are three fundamental assumptions:

• All state transitions are reliably recorded, including application state and coordination metadata (the record of sent and received messages).

• All request messages are acknowledged so that problems are detected as early as possible. This avoids executing unnecessary tasks and allows earlier and less costly problem detection.

• As with atomic transactions, a response is defined as a separate operation and not as the output of the request. Message input-output implementations typically have timeouts that are too short for some business activity responses. If the response is not received after a timeout, it is resent. This is repeated until a response is received. The request receiver discards all but one of the identical requests it receives.

As with atomic transactions, the business activity model has multiple protocols: Business Agreement with Participant Completion and Business Agreement with Coordinator Completion

Business Agreement with Participant Completion

Under the Business Agreement protocol with Participant Completion, a child activity is initially created in the Active state. After a child task finishes, it must be able to compensate for the work that was performed. The child task sends a Completed message to the parent and waits to receive the final outcome of the BA from the parent. This outcome will either be a Close message, meaning that the BA has completed successfully, or a Compensate message, requesting the child task to reverse the effects of its work.

As illustrated in Figure 11-17, after all the participants return Completed, the coordinator indicates a successful outcome, sending Close to the participants. Then the participants return Closed to acknowledge the outcome.

Figure 11-17. Successful business agreement with participant completion.

As illustrated in Figure 11-18, after all the participants return Completed, the coordinator indicates the unsuccessful outcome, sending Compensate to the participants. Then the participants return Compensated to acknowledge the outcome and undo the work for the transaction.

Figure 11-18. Unsuccessful business agreement with participant completion.

A child task might finish the work it was created to do and decide it no longer needs to participate in the activity. In this case, the child task can unilaterally send an Exit message to the parent that is equivalent to the participant resigning from the business transaction. (As illustrated in Figure 11-19, a participant ends involvement in the transaction by sending an Exit to the coordinator, and the coordinator acknowledges the action by returning Exited. After all the other participants return Completed, the coordinator indicates a successful outcome, sending Close to all the remaining participants. The participants then return Closed to acknowledge the outcome.)

Figure 11-19. Business agreement with participant completionparticipant exit.

Business Agreement with Coordinator Completion

The Business Agreement with Coordinator Completion protocol is identical to the Business Agreement with Participant Completion protocol except that the child cannot unilaterally decide to end its participation in the business activity. The child task relies on the parent to send a Complete message when it has received all requests to perform work. The child then acts as it does in the Business Agreement with Participant Completions protocol (see Figure 11-20).

Figure 11-20. Successful business agreement with coordinator completion.

General Considerations

The scenario infers several fundamental requirements on a Web service implementation:

• The usage throughout the distributed environment of a "universally" understood Activation Service definition (that is, a context that includes both an identifier and a coordinator address).

• The ability to establish and reference a coordinator (an endpoint address that is understood throughout the network).

• (Optional) For efficiency through the reduction of network flows, the ability to construct a subordinate node that uses the Activation Service definition to control the outcome of some part of distributed activity.

• (Optional) The ability to optimize flows by including protocol messages on the regular application message flow.

• A defined relationship for context and endpoint association (that is, an agreed mechanism for exchanging context and establishing an execution environment for the target Web service).