OASIS Web Services Transaction (WS-TX) TC

From the Call for Participation at: http://lists.oasis-open.org/archives/ws-tx/200510/msg00000.html

The Charter for this TC was modified on 13 April 2007; this change was announced at http://lists.oasis-open.org/archives/tc-announce/200704/msg00022.html

Additional non-normative information, not included in this Charter, may be found in the Call for Participation

a. Name of the TC

OASIS Web Services Transaction (WS-TX) Technical Committee

b. Statement of Purpose

The purpose of the Web Services Transaction (WS-TX) Technical Committee (TC) 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) [1] specification submitted to the TC as referenced in this charter.

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) [2] and Web Services Business Activity (WS-BusinessActivity v 1.0) [3] specifications submitted to the TC.

Collectively, these three specifications will be referred to as the WS-TX Specifications.

This document assumes the reader has a basic knowledge of coordination protocols and current practice as it relates to atomic transaction management and long running activities. A familiarity with the concepts and terms may also be obtained through books such as "Transaction Processing: Concepts & Technologies" by Gray & Reuter [4], and "Principles of Transaction Processing" by Bernstein and Newcomer [5].

c. Scope of Work

The TC will accept as input version 1.0 of the WS-Coordination [1], WS-AT [2] and WS-BA [3] specifications (the Input Documents) as published by Arjuna Technologies, BEA Systems, Hitachi, IBM, IONA Technologies and Microsoft. Other contributions and changes to the input documents will be accepted for consideration without any prejudice or restrictions and evaluated based on technical merit in so far as they conform to this charter.

The scope of the TC's work is to continue further refinement and finalization of the input documents to produce as output modular specifications that standardize the concepts, WSDL documents and XML schema renderings required to coordinate actions of distributed applications that conform to the specifications.

The WS-TX TC shall produce three inter-related specifications:

1. A WS-Coordination v 1.1 specification providing protocols for services that create a coordination context, which uniquely identifies an activity, and register participants in the activity.

2. A WS-AtomicTransaction v 1.1 specification specifying concrete protocols for distributed atomic transactions using the well-known two-phase commit abstract protocol.

3. A WS-BusinessActivity v 1.1 specification providing a protocol for long-running activities using a compensation protocol.

As general principles, these protocols should:

Focus on ease of interoperation.
Use simple but complete state machines, preferring simplicity and completeness to elaboration.
Specify concrete protocol message formats.
Use message formats that include extensibility points for implementations to add custom elements as required within the context of message semantics and schemas.
Support the extensibility of coordination types for use in control protocols outside the scope of this TC.
Include state machines that specify the events and messages (including fault messages) that may be received at each different state in the protocol.
Must not depend on the availability of reliable message delivery mechanisms outside of these specifications.

The specifications will uphold the basic principles of other Web services specifications of independence and composition and must be composable with the other specifications in the Web services architecture such as WS-Security [6], WS-Trust [7], WS-SecureConversation [8], WS-Addressing [9], SOAP 1.1 [10], SOAP 1.2 [11], bindings of SOAP 1.1/1.2 to HTTP, WS-Policy [12], WSDL 1.1 [13] and WSDL 2.0 [14]. The "Secure, Reliable, Transacted Web Services: Architecture & Composition" white paper [15] published in 2003 provides information on the Web services architecture. The TC will also take into consideration applicable work, such as the WS-I Basic Profile [16].

If any above specification is outside of a standardization process at the time this TC moves to ratify its deliverables, or is not far enough along in the standardization process, any normative references to it in the TC output will be expressed in an abstract manner, and the incarnation will be left at that time as an exercise in interoperability.

While enabling composition with other specifications is a goal of the TC, it is also a goal to leave the specifics of how that composition is achieved outside the scope of the WS-TX specifications.

Each of the protocol elements will use implementation and language neutral message formats defined in WSDL [13] and XML formats defined in XML Schema [17]. SOAP [10, 11] bindings will be specified for the message protocol elements.

The scope of these three specifications is detailed below.

The WS-Coordination specification consists of:

The definition of a coordination service as an aggregate of an activation service, a registration service, a CoordinationContext XML type, and a set of specific coordination service protocols.
The definition of protocols for communicating with an activation service, that service having two purposes:
- Creating a coordination context for a new activity.
- Creating a coordination context for an existing activity into which the coordination service has been interposed.
The definition of protocols for communicating with a registration service, that service having the purpose of allowing a web service to register to participate in a specific coordination protocol relating to a specific activity.
The notion of a coordination type as an independent service, not defined in the WS-Coordination specification, which provides a set of coordination protocols.
The notion of a coordination protocol as an independent message exchange pattern, not defined in the WS-Coordination specification, which is associated with a coordination type.
A binding-specific mechanism for propagating coordination context elements representing activities between applications, including a SOAP-binding that uses the SOAP header of a SOAP message.
The definition of protocols for communicating with a registration service that can be used by an application to register itself into the overall activity.
A coordination context usable within a SOAP header that identifies the activity type, the activity identifier, the activity expiration time, an appropriate pre-registration service, and protocol specific extensions. The context can be used by other coordination protocols, including, but not limited to, those produced by this TC.

The coordination specification MUST be able to compose with WS-Security [6], WS-Trust [7], and WS-SecureConversation [8] to realize the following security goals in a simple and interoperable way:

Ensure that only authorized principals (see [15]) can create or register with a coordination context
Verify that a coordination context is legitimate and has not suffered from tampering.
Allow composition with existing and federated security infrastructures
Limit the transaction participation to authorized participants and applications

The coordination specification must also provide a mechanism that restricts registration on an activity to those applications to whom the right to register was delegated from the root coordinator. This mechanism must associate a security token with each coordination context. The WS-Trust <IssuedTokens> element must be used to flow security tokens in SOAP message headers alongside coordination contexts.

The WS-AtomicTransaction specification consists of:

Definition of a coordination type suit able for coordination in a two-phase commit protocol.
Definition of a completion protocol which can be used by a service to signal the initiation of commitment processing and to receive notification of the success or failure of the subsequent two-phase commitment.
Durable and Volatile variants of a two-phase commit (2PC) protocol.
Policy assertions qualifying instances of protocol usage.

The volatile resource and the durable resource variations of the two-phase commit protocols MUST each:

Specify the presumed abort protocol.
Support a read-only optimization, both as a response to Prepare, and as an unsolicited notification.
Support unsolicited rollback notifications from a participant.

The volatile two-phase commit protocol must:

Provide for completion of volatile phase 1 for all volatile participants before the durable two-phase commit protocol begins.
Not preclude other participants from registering with either the volatile or durable two phase commit protocols until durable phase 1.

It is not required to provide guarantees of notification of the transaction outcome.

The durable two-phase commit protocol must:

Preclude any additional two-phase commit registration as soon as the protocol enters durable phase 1 for any participant.
Guarantee notification of the transaction outcome, through the use of well- known recovery mechanisms, including repeated requests for outcome from the participant and repeated unsolicited notifications from the superior.

An individual participant may want to register for both two-phase-commit protocols with the same transaction, so this capability must be provided.

The Atomic Transaction specification security model must build on the security model defined in WS-Coordination.

The Atomic Transaction specification must define policy assertions that prescribe the transactional processing of SOAP messages on a WSDL operation. The assertions must be usable in the policy framework defined by WS-Policy. The assertions must have Operation Policy Subject and must be able to be attached to a WSDL binding.

These assertions must indicate whether:

A requester MAY, MUST or SHOULD NOT include an atomic transaction coordination context flowed with the message.
The target service processes its message under an atomic transaction regardless of whether the requester supplies an atomic transaction coordination context.

The WS-BusinessActivity specification consists of:

Definition of two coordination types suitable for coordination in a business activity protocol:
- A coordination type for which the outcome is the same for all participants involved in the same activity.
- A coordination type for which the outcome may vary between participants involved in the same activity.
Definition of two types of coordination protocols for consensual agreement:
- A coordination protocol in which participants inform their coordinator as to when they are complete.
- A coordination protocol in which a coordinator informs its participants as to when they are complete.

Both types of coordination protocols should:

Define a common, pair-wise consensus protocol that allows for eventual consensus between the pair of participants.
Use the coordinator to determine if the activity specified by the coordination context is to be canceled, has exited, has successfully terminated, requires compensation or has faulted.
Guarantee protocol notifications, through the use of well-known mechanisms including repeated unsolicited notifications.

The Business Activity specification security model must build on the security model defined in WS-Coordination.

The Business Activity specification must define policy assertions that prescribe the business activity processing of SOAP messages on a WSDL operation. The assertions must be usable in the policy framework defined by WS-Policy. The assertions must have Operation Policy Subject and must be able to be attached to a WSDL binding.

These assertions must indicate whether:

The sender of an input message MAY, MUST or SHOULD NOT include an AtomicOutcome coordination context flowed with the message.
The sender of an input message MAY, MUST or SHOULD NOT include a MixedOutcome coordination context flowed with the message.

Out of Scope

The following is a non-exhaustive list. It is provided only for the sake of clarity. If some function, mechanism or feature is not mentioned here, and it is not mentioned as in-scope in the Scope of Work section either, then it will be deemed to be out of scope.

The TC will not define a mapping of the functions and elements described in the specifications to any programming language, particular messaging middleware or specific network transports.

Except for the elements directly related to the functions in the scope of the specifications, the TC will not prescribe the format of messages that are transferred according to the specifications.

The elements and/or mechanisms the TC defines must be independent of issues and considerations that do not affect an interoperable transaction coordination protocol. Specifically, the TC should not define mechanisms for binding the specifications to specific transports. However, the specifications should include elements and/or mechanisms that allow binding to transports commonly used in Web services implementations.

The TC will not attempt to define concepts or renderings for functions that are separable from consensus protocols, including but not limited to:

Security (Encryption, Integrity and Authentication)
Addressing
Policy languages and frameworks
Routing
General-purpose reliable message delivery

Where required, these functions are achieved by composition with other Web services specifications.

The TC will not attempt to define functionality duplicating that of a specification normatively referenced in the input WS-Coordination, WS-AtomicTransaction, or WS-BusinessActivity specifications. If the referenced specification is outside of a standardization process at the time this TC moves to ratify its deliverables, or is not far along enough in the standardization process, any normative references to it in the TC output will be expressed in an abstract manner, and the incarnation will be left at that time as an exercise in interoperability.

The TC will not specify changes to specifications external to the WS-TX input specifications.

For clarity, the out of scope features include, but are not limited to, the following:

Alternatives to two phase commit atomic commitment protocols
Heuristic outcome handling, including mixed outcome detection, in the atomic commitment protocols
Any pattern or optimization that leads to delegation of ownership of the outcome decision or re-orders the 2PC commit tree
The last-participant optimization
Any extension or protocol optimization beyond those already listed
Business process workflow or lifecycle specifications
Additional coordination types
Additional control protocols
Additional policy assertions
Additional protocols for activity management
Message formats or mechanisms other than SOAP messages defined in terms of XML InfoSets

Out of scope items for WS-TX may be appropriate for consideration by another TC, such as WS-CAF, in the context of the potential definition of one or more coordination types that extend WS-TX.

d. Deliverables

The TC has the following set of deliverables.

A WS-Coordination v 1.1 Protocol specification. Committee specifications are scheduled for completion within six months of the first TC meeting.
A WS-AtomicTransaction v 1.1 specification. Committee specifications are scheduled for completion within one year of the first TC meeting.
A WS-BusinessActivity v 1.1 specification. Committee specifications are scheduled for completion within one year of the first TC meeting.

These specifications will reflect refinements, corrections or material technological improvements with respect to the input documents and in accordance with this charter.

The WS-TX TC will first work on refining a WS-Coordination Committee Draft. Once this coordination framework Committee Draft has been completed, the TC will then work to refine the WS-AtomicTransaction and WS-BusinessActivity coordination type specifications.

Ratification of the above specifications as OASIS standards. Following this, ratification of updated specifications as revised OASIS standards to address any errata to fix errors and to replace policy references to the WS-Policy W3C Recommendation as soon as that Recommendation is available will mark the end of the TCs lifecycle.

e. IPR Mode

This TC will operate under the "RF (Royalty Free) on RAND Terms" IPR mode as defined in the OASIS Intellectual Property Rights (IPR) Policy, effective 15 April 2005.

f. Anticipated Audience

The anticipated audience for this work includes:

Vendors offering web services products;
Other specification authors that need distributed transactions for Web services;
Software architects and programmers, who design, write or integrate applications for Web services; and
End users implementing Web services-based solutions that require an interoperable, composable distributed transaction solution.

g. Language

TC business will be conducted in English.

References

[1] WS-Coordination
http://schemas.xmlsoap.org/ws/2004/10/wscoor

[2] WS-AtomicTransaction
http://schemas.xmlsoap.org/ws/2004/10/wsat

[3] WS-BusinessActivity
http://schemas.xmlsoap.org/ws/2004/10/wsba

[4] "Transaction Processing: Concepts & Technologies", Jim Gray and Andreas
Reuter Morgan Kaufmann, 1993.

[5] "Principles of Transaction Processing," Philip A. Bernstein and Eric
Newcomer, Morgan Kaufmann, 1997.

[6] WS-Security
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

[7] WS-Trust
http://schemas.xmlsoap.org/ws/2005/02/trust

[8] WS-SecureConversation
http://schemas.xmlsoap.org.ws/2005/02/sc

[9] WS-Addressing
http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/