WebServices dot org

The OASIS WS-CAF Approach to Web Services Business Transactions

As Web services have evolved as a means to integrate processes and applications at an inter-enterprise level, traditional transaction semantics and protocols have proven to be inappropriate. Web services-based transactions, colloquially termed Business Transactions, differ from traditional transactions in that they execute over long periods, they require commitments to the transaction to be “negotiated” at runtime, and isolation levels have to be relaxed.

A solution to this problem has to work over HTTP and include existing transaction processing technologies of all types: database management systems, application servers, message queuing systems and packaged applications. The solution needs to support a range of requirements including lightweight applications in which the major goal is to let Web services know when they’re in the same application to complicated transactions that may take days or weeks to complete across wide ranging geographies, time zones, and enterprise boundaries. In this paper we’ll look at the OASIS WS-CAF standardization effort and show how it is attempting to address this important and difficult subject.

Introduction

Atomic transactions are a well-known technique for guaranteeing consistency in the presence of failures [1] . The ACID properties of atomic transactions (Atomicity, Consistency, Isolation, Durability) ensure that even in complex business applications consistency of state is preserved, despite concurrent accesses and failures. This is an extremely useful fault-tolerance technique, especially when multiple, possibly remote, resources are involved.

Previous transaction processing systems shared a great deal of commonality in terms of the crux of the problem that they address and the abstractions they use to address it. Specifically, transaction processing systems were developed for particular platforms and each system assumes that it is in sole control of the transaction domain and hence does not generally have to interoperate with other transaction processing systems (though interoperability with lower-level components like databases is generally well supported via interfaces like X/Open XA).

However, the structuring mechanisms available within traditional atomic transaction systems are sequential and concurrent composition of transactions. These mechanisms are sufficient if an application function can be represented as a single atomic transaction. Transactions are most suitably viewed as “short-lived” entities, performing stable state changes to the system; they are less well suited for structuring “long-lived” application functions (e.g., running for hours, days, …). Long-lived atomic transactions (as typically occur in business-to-business interactions) may reduce the concurrency in the system to an unacceptable level by holding on to resources (e.g., locks) for a long time; further, if such an atomic transaction rolls back, much valuable work already performed could be undone.

Web services present a different kind of problem: they are specifically about fostering systems interoperability. This presents some interesting problems from a transaction management point of view. What makes Web services so interesting is the fact that the architecture is deliberately not prescriptive about what happens behind service endpoints – Web services are ultimately only concerned with the transfer of structured data between parties, plus any meta-level information to safeguard such transfers (e.g. by encrypting or digitally signing messages) – yet it is behind service endpoints that we find traditional transaction processing architectures supporting business activities.

Thus we are presented with a paradox. The Web services platform provides a service-oriented, loosely coupled, and potentially asynchronous means of propagating information between parties, whilst in the background we have traditional transaction processing infrastructures whose behavior is neither or mutually interoperable. Furthermore, the fact that transactions in these systems are assumed to exhibit ACID properties potentially leads to problems when exposing resources to third parties, since it presents opportunities to those parties to tie up resources and prevent transactions from making progress. Thus if transactions were to be supported in the Web services architecture then it is clear that some re-addressing of the problem is required.

This is the arena where the OASIS Web Services Composite Application Framework [2] plays. It began life in August 2003 when ArjunaTechnologies, Fujitsu, IONA Technologies, Oracle and Sun Microsystems submitted their WS-CAF specifications to the standards body. This effort is entirely open, unlike efforts from some other Web Services vendors, and the results produced will be royalty free. In the following sections we’ll look at how WS-CAF is trying to address the important problem of business-to-business transactions.

An overview of WS-CAF

The WS-CAF suite includes three specifications that can be implemented incrementally to address the range of requirements needed to support a variety of simple to complex composite applications:

• Web Service Context (WS-Context), a lightweight framework for simple context management. WS-Context has now reached OASIS Committee Draft and has been the subject of several interoperability demonstrators [10] .

• Web Service Coordination Framework (WS-CF), which defines the behavior of a coordinator with which Web services can register for context augmentation and results propagation, and on top of which can be plugged various transaction protocols.

• Web Services Transaction Management (WS-TXM), comprising three distinct protocols for interoperability across multiple transaction managers and supporting multiple transaction models (two phase commit, long running actions or compensation, and business process flows).

The overall aim of the combination of the parts of WS-CAF is to provide a complete solution that supports various transaction processing models and architectures. Implementations of WS-CAF can start small and grow to include more functionality over time. WS-CAF specifications are designed to compliment Web services orchestration and choreography technologies such as WS-BPEL [3] and WSCI [4] and are compatible with other Web services specifications. The emphasis of WS-CAF is to define supporting services required by Web services used in combination, including other specifications.

The parts of WS-CAF comprise a stack, starting from WS-Context, adding WS-CF, and finally WS-TXM to deliver the complete features and functionality required by composite applications. An implementation of WS-CAF can start with WS-Context for simple context management, and later add WS-CF for its additional context management features and context message delivery guarantees, and finally add WS-TXM for managing a variety of recovery protocols.

In the following sections we shall examine each of these specifications in more detail and show how they support the development of composite Web Service applications.

WS-Context

WS-Context provides a mechanism for Web services to share persistent state, which is required to support conversational interactions, single sign-on, transaction coordination, and other features dependent upon system-level data items such as IDs, tokens etc. Context provides a way to correlate a set of messages into a larger unit of work by sharing common information such as a security token exchanged within a single sign on session.

Because distributed computing systems depend upon a variety of IDs, tokens, channels, and addresses, which are a part of every software infrastructure, and because Web services are independent of any particular execution environment, this type of system level information needs to be organized and managed in a persistent, shared context structure. Applications need a service to manage the lifecycle of the shared context, and to ensure the context structure is kept up to date and accessible.

WS-Context defines a context data structure that can be arbitrarily augmented. By default, all the context defines is a unique context identifier, the type of the context (e.g., transaction or security) and a timeout value (how long the context can remain valid). For example:

<env:Envelope xmlns:env=http://www.w3.org/2002/12/soap-envelope>
<env:Header>
<wsctx:context timeout="0">
<wsctx:context-identifier>

<"http://www.arjuna.com/ws-ctx/123:abc:456:def"

</wsctx:context-identifier>
<!-- Other protocols can extend context here -->
</wsctx:context>
</env:Header>
<env:Body>
<m:Message xmlns:m=http://example.org/MessageSchema

<m:…
</m:Message>
</env:Body>
</env:Envelope>

WS-CF

A coordinator is a software entity responsible for ensuring consensus is achieved between multiple parties. Coordinators exist in CORBA, .NET, J2EE, and other distributed computing environments to coordinate the classic two-phase commit transaction protocol across multiple data resources. However, coordination is a more fundamental requirement: it is used in security, replication, caching and other areas.

Therefore, the definition of a coordinator in WS-CAF is extended for use with Web services by using a plug in mechanism that supports multiple coordination protocols. Web services are designed to be multi-protocol and therefore to map to multiple underlying technologies. Instead of tying the coordinator to the two-phase commit protocol, which is the way current coordinators are defined, the WS-CF specification creates a general-purpose coordinator capable of driving a variety of context types and transaction protocols (such as those defined in WS-TXM and others).

Whatever coordination protocol is used and in whatever domain it is deployed, the same generic requirements are present:

• Instantiation (or activation) of a new coordinator for the specific coordination protocol, for a particular application instance;

• Registration of participants with the coordinator, such that they will receive that coordinator’s protocol messages during (some part of) the application’s lifetime;

• Propagation of contextual information between Web services that comprise the application;

• An entity to drive the coordination protocol through to completion.

The first two of these points are directly the concern of WS-CF, the third is obtained through the use of WS-Context, while the fourth is the responsibility of a third-party entity, usually the client application that controls the application as a whole.

<env:Envelope xmlns:env="http://www.w3.org/2002/12/soap-envelope">
<env:Header>
<n:Composite xmlns:n=”http://www.example.org/CompositeApplication”>
<n:Coordinator>
htt://www.webservicestransactions.org/example/CoordinatorURI

</Cooordinator>
</n:Composite>
</env:Header>
<env:Body> ...
</env:Envelope>

In the above example, the coordinator URI points to a Web service interface that defines the SOAP message pattern for interactions between the coordinator and the Web service execution. The coordinator then manages any user defined context and generates and propagates any context for use within the operations of the composite and includes each registered Web service in the recovery protocol.

WS-TXM

Given that the traditional ACID transaction model is not appropriate for Web services, let’s pose the question, “what type of model or protocol is appropriate?” The answer to that question is that that no one specific protocol is likely to be sufficient, given the wide range of situations that Web service transactions are likely to be deployed within.

Therefore WS-TXM provides models that are designed to accommodate multiple use-cases, from tightly-coupled intranet-based transactions (TX-ACID), through to Internet-scale long lived transactions (TX-LRA), to business-process oriented transactions(TX-BP).

It’s important to note that this set of protocols is not meant to be complete. The intention is that if other models are developed to better suit different use cases, then those models should be added to WS-TXM.

TX-ACID

This model is designed to support interoperability of existing transaction processing systems via Web Services, given such systems already form the backbone of enterprise class applications. Although ACID transactions may not be suitable for all Web Services, they are most definitely suitable for some, and particularly high-value interactions such as those involved in finance. As a result, the ACID transaction model defined in WS-TXM has been designed with interoperability in mind. In the ACID model, each activity is bound to the scope of a transaction, such that the end of an activity automatically triggers the termination (commit or rollback) of the associated transaction.

TX-LRA

The long running action model (LRA) is designed specifically for those business interactions that occur over a long duration. Within this model, an activity reflects business interactions: all work performed within the scope of an application is required to be compensatable. Therefore, an application’s work is either performed successfully or undone. How individual Web services perform their work and ensure it can be undone if compensation is required, are implementation choices and not exposed to the LRA model. The LRA model simply defines the triggers for compensation actions and the conditions under which those triggers are executed.

In the LRA model, each application is bound to the scope of a compensation interaction. For example, when a user reserves a seat on a flight, the airline reservation centre may take an optimistic approach and actually book the seat and debit the users account, relying on the fact that most of their customers who reserve seats later book them; the compensation action for this activity would obviously be to un-book the seat and credit the user’s account. Work performed within the scope of a nested LRA must remain compensatable until an enclosing service informs the individual service(s) that it is no longer required.

There is a caveat to this model though, where application services may not be compensatable (e.g. an application-level service that prints and mails cheques), or the ability to compensate may be transient. The LRA model allows applications to combine services that can be compensated with those that cannot be compensated Obviously by mixing the two service types the user may end up with a business activity that will ultimately not be undone by the LRA model, but which may require outside (application specific) compensation.

The LRA model defines a protocol actor called a Compensator that operates on behalf of a service to undo the work it performs within the scope of an LRA. How compensation is carried out will obviously be dependant upon the service; compensation work may be carried out by other LRAs which themselves have Compensators.

Let’s consider another example of a long running business transaction. The application is concerned with booking a taxi, reserving a table at a restaurant, reserving a seat at the theatre, and then booking a room at a hotel. If all of these operations were performed as a single transaction then resources acquired during booking the taxi (for example) would not be released until the top-level transaction has terminated. If subsequent activities do not require those resources, then they will be needlessly unavailable to other clients.

Figure 1 shows how part of the night-out may be mapped into LRAs. All of the individual activities are compensatable. For example, this means that if LRA1 fails or the user decides to not accept the booked taxi, the work will be undone automatically. Because LRA1 is nested within another LRA, once LRA1 completes successfully any compensation mechanisms for its work may be passed to LRA5: this is an implementation choice for the Compensator. In the event that LRA5 completes successfully, no work is required to be compensated, otherwise all work performed within the scope of LRA5 (LRA1 to LRA4) will be compensated.

Figure 1, LRA example.

TX-BP

In the business process transaction model (BP model) all parties involved in a business process reside within business domains, which may themselves use business processes to perform work. Business process transactions are responsible for managing interactions between these domains. A business process (business-to-business interaction) is split into business tasks and each task executes within a specific business domain. A business domain may itself be subdivided into other business domains (business processes) in a recursive manner.

Each domain may represent a different transaction model if such a federation of models is more appropriate to the activity. Each business task (which may be modeled as a scope) may provide implementation specific counter-effects in the event that the enclosing scope must cancel. In addition, periodically the controlling application may request that the entire business domains checkpoint their state such that they can either be consistently rolled back to that checkpoint by the application or restarted from the checkpoint in the event of a failure.

An individual task may require multiple services to work. Each task is assumed to be a compensatable unit of work. However, as with the LRA model described earlier, how compensation is provided is an implementation choice for the task.

For example, consider the purchasing of a home entertainment system example shown in Figure 2. The on-line shop interacts with its specific suppliers, each of which resides in its own business domain. The work necessary to obtain each component is modeled as a separate task, or Web service. In this example, the HiFi task is actually composed of two sub-tasks.

Figure 2, Business processes and tasks.

In this example, the user may interact synchronously with the shop to build up the entertainment system. Alternatively, the user may submit an order (possibly with a list of alternate requirements) to the shop which will eventually call back when it has been filled; likewise, the shop then submits orders to each supplier, requiring them to call back when each component is available (or is known to be unavailable).

How might WS-CAF be used?

During a business activity, a given process will often interact with many different partners in order to conduct work. Those interactions may be based on either synchronous or asynchronous transport mechanisms. However, the typical interaction pattern is based on asynchronous (one way) messages because this has the benefit of allowing loose coupling of application entities: the sender of a given message that requires a response need not be the same as the ultimate receiver of that response. This allows for great flexibility in choosing service deployments, particularly in environments that may be error prone or require dynamic changes to roles and responsibilities.

However, if interactions are structured as independent one-way messages, some means of tying a response to a request is obviously needed. Furthermore, in some situations it may be a requirement for multiple requests to be sent to a service but only one response is required. For example, consider an online computer ordering service that allows you to send an initial order but follow up with enhancement requests until the machine is finally dispatched. As such there are multiple outgoing requests (initial + N*refinements) and one incoming response (delivery).

Both of these requirements can be summarized as requiring messages to be contextualized: additional information is associated with a message to enable the infrastructure to “route” the message (physically or logically). An obvious way in which this matching could be done would be through the use of additional information associated with the messages (e.g., a message sequence number). However, this has the following disadvantages:

1. It requires support (and agreement) from all parties involved. For instance, do we use a string, a URI or an integer for this information?

2. It’s an ad hoc solution which is implemented each time an application has this kind of requirement. Although it will work for perhaps one or two interactions, it simply does not scale as the number of interactions and services increases.

WS-Context defines the notion of an abstract activity to which the context is bound: the lifetime of the activity is the lifetime of the context. So, we can (for example) use an activity to model a session: all interactions on a session-oriented service in the scope of an activity will be uniquely and unambiguously tied to that activity through the context. An activity may also model a business process instance, a conversation, and other concepts.

For example, a context might begin:

<ContextType>MyContext</ContextType>
<context-identifier>
www.webservicestransactions.org/example/xml2004

</context-identifier>

The activity might require user authentication. For example, as we mentioned, the interactions between Bob and Pen require some kind of authentication information. To facilitate single sign-on throughout the composite application, the context might be extended to include user information and provided as an input to the first Web service in a WS-BPEL defined flow. The first Web service in the flow would check the username and password (the asterisks are used to indicate opaque data in the example below) and generate an authentication token. Such an authentication token would be placed back into the context data structure, augmenting the original structure. This token (rather than the username and password) is used for subsequent checks of whether the user is authorized to access other Web services in the flow.

The augmented context might contain the following:

<extended-context>
<user-name>John Doe</user-name>
<password>********</password>
<AuthToken>********</AuthToken>
</extended-context>

As illustrated, the context is a living data structure; the results of a security sign on (or other operations pertinent to the contents of the context) would typically be added for propagation to the next Web service in the flow. For example, a single sign-on system bridging multiple security domains could add another token to the context.

Specifications such as the Business Process Execution Language (BPEL) and the WebServices Choreography Interface (WSCI) focus on tying multiple Web services together to create multi-step applications, such as filling a purchase order or resolving an insurance claim. Therefore these applications have the requirement to share context across the steps and to coordinate those steps.

While specifications such as BPEL and WSCI provide the mechanism for extending the WSDL layer to identify a series or sequence of execution for multiple Web services, WS-CAF defines the complementary system layer necessary to ensure that the multiple Web services achieve the desired results of the application, and that the cooperation of multiple Web services from whatever source (local or remote) produces predictable behavior despite system failure and leaves the system in a known state.

Conclusions

An important consideration with respect to Web services specifications is the issue of intellectual property rights and copyright ownership. The WS-Interoperability organization [7] for example has debated to what extent their profiles can or should reference private specifications. The WS-I Basic Profile references SOAP 1.1, WSDL 1.1, and UDDI V2, all of which were produced by private consortia but have since been submitted to a standards body.

Some specifications under private copyright ownership require royalty fees to be paid to the copyright owners for the right to implement and sell software based upon them. Web services vendors who are not copyright holders on a given specification may be concerned about implementing a specification that their competitors control, especially when they are not allowed to participate in its definition or evolution. When a specification is not under the control of a single vendor of group of vendors, it’s said to be “open,” meaning that anyone can participate in its definition and evolution.

With respect to other Web services specifications, both private and open, the WS-Context specification is unique. No other specification exists that defines a generic context management mechanism for Web services.

The OASIS WS-Coordination Framework specification shares a common derivation with the private WS-Coordination specification – both are based on the Object Management Group’s (OMG) extended transaction specification called Additional Structuring Mechanisms for the OTS [8] . This specification was developed as an extension of the Object Transaction Specification (OTS) [9] , which defines how coordination works for both the CORBA and J2EE worlds.

As with most aspects of standardization, the value in WS-CAF is derived from the potential for its features and functions to be provided by Web services vendors, therefore helping application developers solve composite application problems more easily. Once adopted and implemented, the functionality contained within WS-CAF will not only be available as part of the platform but also it will be available in a standard way across platforms.

References

[1]Java Transaction Processing: Design and Implementation, Mark Little, Jon Maron and Greg Pavlik, Prentice Hall, July 2004

[2]OASIS Web Services Composite Application Framework Technical Committee, http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-caf

[3]OASIS Web Services Business Process Execution Language Technical Committee, http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel

[4]The Web Services Choreography Interface, August 2002, W3C Note, http://www.w3.org/TR/2002/NOTE-wsci-20020808/

[5]W3C Architecture Committee, see http://www.w3.org/2002/ws/arch/

[6] http://www-306.ibm.com/software/solutions/webservices/pdf/SecureReliableTransactedWSAction.pdf

[7]See http://www.ws-i.org/Documents.aspx for background on WS-I and information on WS-I working group charters, including the recently-formed requirements working group.

[8] http://www.omg.org/technology/documents/formal/add_struct.htm

[9] http://www.omg.org/technology/documents/formal/transaction_service.htm

[10] OASIS WS-Context Interoperability Demonstrator, http://www.oasis-open.org/news/oasis_news_11_19_04.php