Update 2005-10: On October 01, 2005 OASIS announced a Call for Participation in a new Web Services Transaction (WS-TX) Technical Committee. According to the Charter, the purpose of the WS-TX Technical Committee is "to define a set of protocols to coordinate the outcomes of distributed application actions. The TC will specify an extensible framework for developing coordination protocols through continued refinement of the Web Services Coordination (WS-Coordination v 1.0) specification; in addition, the TC will continue refinement of protocols for two coordination types that use the WS-Coordination framework: atomic transaction (AT) and business activity (BA), based on the Web Services Atomic Transaction (WS-AtomicTransaction v 1.0) and Web Services Business Activity (WS-BusinessActivity v 1.0) specifications submitted to the TC. Collectively, these three specifications will be referred to as the WS-TX Specifications..."

[February 03, 2004] BEA, IBM, and Microsoft have published a third WS-* specification in the Web Services Transaction Framework. The new Web Services Business Activity Framework (WS-BusinessActivity) specification is designed to work in concert with two documents released earlier: Web Services Coordination (WS-Coordination) and Web Services Atomic Transaction (WS-AtomicTransaction). The three 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."

In particular, WS-BusinessActivity "provides the definition of the business activity coordination type that is to be used with the extensible coordination framework described in the WS-Coordination specification. The WS-BusinessActivity specification defines two specific agreement coordination protocols for the business activity coordination type: BusinessAgreementWithParticipantCompletion, and BusinessAgreementWithCoordinatorCompletion. Developers can use any or all of these protocols when building applications that require consistent agreement on the outcome of long-running distributed activities." WS-BusinessActivity addresses the coordination of activities that apply business logic to handle business exceptions: actions are applied immediately and are permanent; compensating actions may be invoked in the event of an error. The Business Activity specification defines protocols that enable existing business process and work flow systems to wrap their proprietary mechanisms and interoperate across trust boundaries and different vendor implementations."

According to IBM, the WS-Policy and WS-PolicyAssertions documents may affect how business activities operate; business activities as defined in WS-BusinessActivity may also utilize the secure messaging features of WS-Security.

Bibliographic Information

• Web Services Business Activity Framework (WS-BusinessActivity). Edited by David Langworthy (Microsoft). By By Luis Felipe Cabrera (Microsoft), George Copeland (Microsoft), William Cox (BEA Systems), Tom Freund (IBM), Johannes Klein (Microsoft), David Langworthy (Microsoft, Editor), Ian Robinson (IBM), Tony Storey (IBM), Satish Thatte (Microsoft). Copyright (c) 2001-2004 BEA Systems Inc, IBM Corporation, Microsoft Corporation. 21 pages.

  Abstract: "This specification provides the definition of the business activity coordination type that is to be used with the extensible coordination framework described in the WS-Coordination specification. The specification defines two specific agreement coordination protocols for the business activity coordination type: BusinessAgreementWithParticipantCompletion, and BusinessAgreementWithCoordinatorCompletion. Developers can use any or all of these protocols when building applications that require consistent agreement on the outcome of long-running distributed activities."

• Coordinating Web Services Activities with WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity. By Luis Felipe Cabrera, George Copeland, Jim Johnson, and David Langworthy. With contributions from Omri Gazitt, Johannes Klein, Rodney Limprecht, Matt Powell, Rebecca Dias, and Brad Lovering. White Paper. Microsoft Corporation. January 28, 2004. 22 pages.

  Written to help one understand how the new WS-BusinessActivity Framework specification relates to the WS-AtomicTransaction and WS-Coordination 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.

WS-BusinessActivity Framework Introduction

"The current set of Web service specifications (WSDL, SOAP) defines protocols for Web service interoperability. Web services increasingly tie together a number of participants forming large distributed applications. The resulting activities may have complex structure and relationships.

The WS-Coordination specification defines an extensible framework for defining coordination types. A coordination type can have multiple coordination protocols, each intended to coordinate a different role that a Web service plays in the activity.

To establish the necessary relationships between participants, messages exchanged between participants carry a CoordinationContext. The CoordinationContext includes a Registration service Endpoint Reference of a Coordination service. Participants use that Registration service to register for one or more of the protocols supported by that activity.

This [WS-BusinessActivity] specification provides the definition of a business activity coordination type used to coordinate activities that apply business logic to handle business exceptions. Actions are applied immediately and are permanent. Compensating actions may be invoked in the event of an error. The Business Activity specification defines protocols that enable existing business process and work flow systems to wrap their proprietary mechanisms and interoperate across trust boundaries and different vendor implementations.

Business Activities have the following characteristics:

• A business activity may consume many resources over a long duration.
• There may be a significant number of atomic transactions involved.
• Individual tasks within a business activity can be seen prior to the completion of the business activity, their results may have an impact outside of the computer system.
• Responding to a request may take a very long time. Human approval, assembly, manufacturing, or delivery may have to take place before a response can be sent.
• In the case where a business exception requires an Activity to be logically undone, abort is typically not sufficient. Exception handling mechanisms may require business logic, for example in the form of a compensation task, to reverse the effects of a completed business task.
• Participants in a business activity may be in different domains of trust where all trust relationships are established explicitly.

These characteristics lead to a design point, with the following assumptions:

• All state transitions are reliably recorded, including application state and coordination metadata.
• All notifications are acknowledged in the protocol to ensure a consistent view of state between the coordinator and participant.
• Each notification is defined as an individual message. Transport level request/response retry and time out are not sufficient mechanisms to achieve end-to-end agreement coordination for long-running activities.

This specification leverages WS-Coordination by extending it to support business activities. It does this by adding constraints to the protocols defined in WS-Coordination and by defining its own Coordination protocols..." [adapted from the WS-BusinessActivity 'Introduction']

"WS-BusinessActivity defines two coordination protocols that differ only in the knowledge of when a unit of work has been completed: (1) BusinessAgreementWithParticipantCompletion: The participant knows when the coordinator will ask no more work of it. (2) 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..." [from the White Paper]

About the Web Services Transaction Framework

"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: (1) Asynchronous operation among participants; (2) Explicit registration in activities with pre-defined behaviors; (3) All communication between participants is based on a collection of mandatory messages and mandatory message exchange patterns for coordination operations; (4) 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..." [adapted from the Microsoft White Paper 'Introduction']

WS-BusinessActivity in the Composable Architecture

"By using the SOAP and WSDL extensibility model, SOAP-based and WSDL-based specifications are designed to work together to define a rich Web services environment. As such, WS-BusinessActivity by itself does not define all features required for a complete solution. WS-BusinessActivity is a building block used with other specifications of web services (e.g., WS-Coordination, WS-Security) and application-specific protocols that are able to accommodate a wide variety of coordination protocols related to the coordination actions of distributed applications..." [from the WS-BusinessActivity spec]