Contents

• Summary
• Bibliographic Information
• WS-TC TC: Call for Participation
• Principal References

A new OASIS technical committee has been chartered to define a set of protocols to coordinate the outcomes of distributed application actions. The OASIS Web Services Transaction (WS-TX) Technical Committee will continue work on technologies now represented by the Web Services Transactions Specifications published by Arjuna Technologies, BEA Systems, Hitachi, IBM, IONA Technologies, and Microsoft.

Three existing specifications will be submitted to the WS-TX Technical Committee as input to initial committee work: Web Services Coordination (WS-Coordination), Web Services Atomic Transaction (WS-AtomicTransaction), and Web Services Business Activity Framework (WS-BusinessActivity). Other contributions and changes to the input documents will be accepted for consideration, based on technical merit, insofar as they conform to the TC's published charter.

The so-called Web Services Transactions specifications "define mechanisms for transactional interoperability between Web services domains and provide a means to compose transactional qualities of service into Web services applications. These specifications describe an extensible coordination framework (WS-Coordination) and specific coordination types for: (1) short duration, ACID transactions (WS-AtomicTransaction) and (2) longer running business transactions (WS-BusinessActivity)."

Specifically, the OASIS TC proposes to "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 as submitted to the committee.

Members of the TC will "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 TC expects to produce three inter-related specifications: (1) a WS-Coordination version 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 version 1.1 specification specifying concrete protocols for distributed atomic transactions using the well-known two-phase commit abstract protocol; (3) a WS-BusinessActivity version 1.1 specification providing a protocol for long-running activities using a compensation protocol.

These protocols, according to general principles articulated in the TC Charter 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; not depend on the availability of reliable message delivery mechanisms outside of these specifications."

Initial public versions of Web Services Coordination (WS-Coordination) and Web Services Transaction (WS-Transaction) were released in August 2002 by BEA Systems, International Business Machines Corporation (IBM), and Microsoft Corporation. The two-part WS-Transaction specification was subsequently refactored: Part 1, published in September 2003, became WS-AtomicTransaction while Part 2 was re-released as WS-BusinessActivity in January 2004. The group of Web Services Transactions specifications were updated in August 2005; these "August 2005" versions are expected to be contributed to the new OASIS WS-TC Technical Committee.

The initial meeting of the WS-TX TC will be a face-to-face meeting held in Cupertino, California on November 16-17, 2005. The TC Convener is Paul Cotton (Microsoft); its proposed Co-Chairs are Ian Robinson (IBM) and Eric Newcomer (IONA).

Bibliographic Information

The August 2005 versions of the following specifications are expected to be contributed to the WS-TC Technical Committee:

• Web Services Coordination (WS-Coordination). Version 1.0. August 2005. 23 pages. With XML Schema (xsd) and WSDL. WS-Coordination namespace URI (RDDL): http://schemas.xmlsoap.org/ws/2004/10/wscoor. Copyright (c) 2002-2005 by Arjuna Technologies, Ltd., BEA Systems, Hitachi, Ltd., International Business Machines Corporation, IONA Technologies, Microsoft Corporation. ["August 2005" URIs: xsd, wsdl, PDF]

  Authors: Luis Felipe Cabrera (Microsoft), George Copeland (Microsoft), Max Feingold (Microsoft, Editor), Robert W Freund (Hitachi), Tom Freund (IBM), Jim Johnson (Microsoft), Sean Joyce (IONA), Chris Kaler (Microsoft), Johannes Klein (Microsoft), David Langworthy (Microsoft), Mark Little (Arjuna Technologies), Anthony Nadalin (IBM), Eric Newcomer (IONA), David Orchard (BEA Systems), Ian Robinson (IBM), John Shewchuk (Microsoft), and Tony Storey (IBM). Acknowledgments. The following individuals have provided invaluable input into the design of the WS-Coordination specification: Francisco Curbera (IBM), Sanjay Dalal (BEA Systems), Doug Davis (IBM), Don Ferguson (IBM), Kirill Garvylyuk (Microsoft), Dan House (IBM), Oisin Hurley (IONA), Frank Leymann (IBM), Thomas Mikalsen (IBM), Jagan Peri (Microsoft), Alex Somogyi (BEA Systems), Stefan Tai (IBM), Satish Thatte (Microsoft), Gary Tully (IONA), and Sanjiva Weerawarana (IBM).

  Abstract: "This specification (WS-Coordination) describes an extensible framework for providing protocols that coordinate the actions of distributed applications. Such coordination protocols are used to support a number of applications, including those that need to reach consistent agreement on the outcome of distributed activities. The framework defined in this specification enables an application service to create a context needed to propagate an activity to other services and to register for coordination protocols. The framework enables existing transaction processing, workflow, and other systems for coordination to hide their proprietary protocols and to operate in a heterogeneous environment. Additionally this specification describes a definition of the structure of context and the requirements for propagating context between cooperating services."

• Web Services Atomic Transaction (WS-AtomicTransaction). Version 1.0. August 2005. 21 pages. Edited by Max Feingold (Microsoft). Copyright (c) 2001-2005 by Arjuna Technologies, Ltd., BEA Systems, Hitachi, Ltd., International Business Machines Corporation, IONA Technologies, and Microsoft Corporation, Inc. With XML Schema (xsd) and WSDL. ["August 2005" URIs: XML Schema (xsd), wsdl, PDF]

  Authors: Luis Felipe Cabrera (Microsoft), George Copeland (Microsoft), Max Feingold (Microsoft, Editor), Robert W. Freund (Hitachi), Tom Freund (IBM), Jim Johnson (Microsoft), Sean Joyce (IONA), Chris Kaler (Microsoft), Johannes Klein (Microsoft), David Langworthy (Microsoft), Mark Little (Arjuna Technologies), Anthony Nadalin (IBM), Eric Newcomer (IONA), David Orchard (BEA Systems), Ian Robinson (IBM), Tony Storey (IBM), and Satish Thatte (Microsoft). Acknowledgments. The following individuals have provided invaluable input into the design of the WS-AtomicTransaction specification: Francisco Curbera (IBM), Sanjay Dalal (BEA Systems), Doug Davis (IBM), Gert Drapers (Microsoft), Don Ferguson (IBM), Kirill Garvylyuk (Microsoft), Dan House (IBM), Oisin Hurley (IONA), Frank Leymann (IBM), Thomas Mikalsen (IBM), Jagan Peri (Microsoft), John Shewchuk (Microsoft), Alex Somogyi (BEA Systems), Stefan Tai (IBM), Gary Tully (IONA), and Sanjiva Weerawarana (IBM).

  Abstract: "This specification provides the definition of the atomic transaction coordination type that is to be used with the extensible coordination framework described in the WSCoordination specification. The specification defines three specific agreement coordination protocols for the atomic transaction coordination type: completion, volatile two-phase commit, and durable two-phase commit. Developers can use any or all of these protocols when building applications that require consistent agreement on the outcome of short-lived distributed activities that have the all-or-nothing property."

• Web Services Business Activity Framework (WS-BusinessActivity). Version 1.0. August 2005. 23 pages. Copyright (c) 2001-2005 by Arjuna Technologies, Ltd., BEA Systems Inc, Hitachi, Ltd., IBM Corporation, IONA Technologies, and Microsoft Corporation. With XML Schema (xsd) and WSDL. WS-BusinessActivity namespace URI (RDDL): http://schemas.xmlsoap.org/ws/2004/10/wsba. ["August 2005" URIs: xsd, wsdl, PDF]

  Authors: Luis Felipe Cabrera (Microsoft), George Copeland (Microsoft), Max Feingold (Microsoft), Robert W Freund (Hitachi), Tom Freund (IBM), Sean Joyce (IONA), Johannes Klein (Microsoft), David Langworthy (Microsoft), Mark Little (Arjuna Technologies), Frank Leymann (IBM), Eric Newcomer (IONA), David Orchard (BEA Systems), Ian Robinson (IBM), Tony Storey (IBM), Satish Thatte (Microsoft). Francisco Curbera (IBM), Gert Drapers (Microsoft), Doug Davis (IBM), Don Ferguson (IBM), Kirill Garvylyuk (Microsoft), Dan House (IBM), Oisin Hurley (IONA), Frank Leymann (IBM), Thomas Mikalsen (IBM), Jagan Peri (Microsoft), John Shewchuk (Microsoft), Stefan Tai (IBM), Gary Tully (IONA), and Sanjiva Weerawarana (IBM).

  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."

WS-TC TC: Call for Participation

Excerpts from the 'Call for Participation', including formal Charter and non-binding Additional Information:

Name of the TC

OASIS Web Services Transaction (WS-TX) Technical Committee

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].

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 and 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 suitable 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.

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, including a brief period to address any errata will mark the end of the TC's lifecycle.

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.

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.

Language

TC business will be conducted in English.

Additional Information: The following additional information relates to the launch of the TC, but will not be part of the TC's charter.

Related Work

Since the WS-TX specifications are part of the Web services architecture, and must work well with other specifications within that architecture, the following [Applicable Work; Other, Similar Work] work may be relevant to this WS-TX TC.

Applicable Work

• OASIS Web Services Security (WSS) TC. WS-TX will ensure that its specifications compose with the WSS TC specifications.
• W3C Web Services Addressing WG. WS-TX will utilize the WS-Addressing functions where appropriate and avoid creating overlapping functions.

The TC may decide to establish liaisons with other groups as needed. Responsibilities for such liaison will be defined by the TC at that time.

Other, Similar Work

• OASIS Web Services Business Process Execution Language (WSBPEL) TC. The WSBPEL TC focuses on an overall business process orchestration language. WS-TX will not discuss how an application operates internally, nor make any overall statement about a global orchestration, but will instead focus on individual, pair-wise message exchanges.

• OASIS Web Services Composite Application Framework (WS-CAF) TC. WS-CAF also offers a set of consensus protocols, some of which are complementary to WS-TX. The WS-TX TC will focus on solidifying a proven foundation for an extensible coordination framework, and updating two fundamental consensus protocols, all of which have been publicly validated and interoperated on in the Web Services Protocol Workshops [18]. It will provide explicit rules in the form of state tables and message schemas for both successful and faulting behavior. It will offer an explicit security model for authorizing participation. It will emphasize composition with other WS-* standards, such as WS-Addressing and WS- Security.

• OASIS Business Transactions (BTP) TC. The WS-TX TC will have a different focus with regard to specification scope, required functions, policy, and other Web Services composeability . WS-TX will focus solely on simple, pair-wise message exchange patterns that can be used to reach either atomic commitment, or looser application consensus. WS-TX will provide simpler interoperability by focusing exclusively on externally visible service behavior at the protocol level. It will not impose constraints on internal service implementations. It will emphasize clean composition with other WS-* standards, such as WS-Addressing and WS-Security. WS-TX will concentrate on interoperability specifying relatively few variations and providing simple state tables rather than extensive options with considerable application semantics.

Anticipated Contributions

The current WS-Coordination v 1.0 [1], WS-AtomicTransaction v 1.0 [2], and WS-BusinessActivity v 1.0 [3] specifications, as published August 2005 by Arjuna Technologies, BEA Systems, Hitachi, IBM, IONA Technologies and Microsoft are expected to be contributed to this TC.

Date and Time of First Meeting

The first meeting of the WS-TX TC will be a face to face meeting held in Cupertino, California on Wednesday November 16 and Thursday November 17, 2005, from 9:00 am to 5:30 local time. This meeting will be sponsored by Hitachi.

Ongoing Meeting Plans and Sponsors

It is anticipated the WS-TX Technical Committee will meet via teleconference every other week for 90 minutes at a time determined by the TC members during the TC's first meeting. It is anticipated that the WS-TX Technical Committee will meet in face to face every quarter at a time and location to be determined by the TC members. Actual pace of face to face and teleconference meetings will be determined by TC members.

One of the proposers, as listed below, will sponsor the teleconferences unless other TC members offer to donate their own facilities. If no other TC proposers offer to sponsor teleconference facilities, Microsoft or IBM will donate their facilities.

Proposers of the TC

• Abbie Barbir, Nortel, abbieb@nortel.com
• Rebecca Bergersen, IONA Technologies, Rebecca.bergersen@iona.com
• Allen Brookes, Rogue Wave, abrookes@roguewave.com
• Anto Budiardjo, Individual Member, antob@clasma.com
• Dave Chappell, Sonic Software, chappell@sonicsoftware.com
• David Connelly, Open Applications Group, Inc., dconnelly@openapplications.org
• Paul Cotton, Microsoft Corporation, pcotton@microsoft.com
• Glen Daniels, Sonic Software, gdaniels@sonicsoftware.com
• Jean-Jacques Dubray, SAP, jean-jacques.dubray@sap.com
• Petr Dvorak, Systinet, petr.dvorak@systinet.com
• Dan Foody, Actional Corporation, dan.foody@actional.com
• Robert Freund, Hitachi, Ltd., bob.freund@hitachisoftware.com
• Tom Freund, IBM, tjfreund@us.ibm.com
• Peter Furniss, Choreology peter.furniss@choreology.com
• Alastair Green, Choreology, alastair.green@choreology.com
• Paul Knight, Nortel, paul.knight@nortel.com
• Chris Kurt, Microsoft Corporation, ckurt@microsoft.com
• Mark Little, Arjuna Technologies, mark.little@arjuna.com
• Denis Lussier, individual, denis@enterprisedb.com
• Jeff Mischkinsky, Oracle, jeff.mischkinsky@oracle.com
• Andrew Nash, Reactivity, anash@reactivity.com
• Eric Newcomer, IONA Technologies, eric.newcomer@iona.com
• Duane Nickull, Adobe Systems, dnickull@adobe.com
• David Orchard, BEA, dorchard@bea.com
• Sanjay Patil, SAP, sanjay.patil@sap.com
• Alain Regnier, Ricoh, alain@ussj.ricoh.com
• Ian Robinson, IBM, ian_robinson@uk.ibm.com
• Tom Rutt, Fujitsu Software Corporation, trutt@us.fujitsu.com
• Shivajee Samdarshi, TIBCO, shivajee@tibco.com
• Hitoshi Sekine, Ricoh, hitoshi@ussj.ricoh.com
• Keith Swenson, Fujitsu Software Corporation, kswenson@us.fujitsu.com
• Claus von Riegen, SAP, claus.von.riegen@sap.com
• Prasad Yendluri, webMethods, prasad.yendluri@webmethods.com

TC Convener

The TC Convener will be Paul Cotton (pcotton@microsoft.com) from Microsoft.

Proposed Co-Chairs

• Ian Robinson (ian_robinson@uk.ibm.com) from IBM
• Eric Newcomer (Eric.Newcomer@iona.com) from IONA

These co-chairs will jointly chair the WS-Coordination specification development, followed by the independent WS-AtomicTransaction and WS-BusinessActivity sub-tracks.

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/

[10] SOAP 1.1
http://www.w3.org/TR/2000/NOTE-SOAP-20000508/

[11] SOAP 1.2
http://www.w3.org/TR/2003/REC-soap12-part1-20030624/

[12] WS-Policy
http://schemas.xmlsoap.org/ws/2004/09/policy

[13] WSDL 1.1
http://www.w3.org/TR/2001/NOTE-wsdl-20010315

[14] WSDL 2.0
http://www.w3.org/TR/wsdl20/

[15] Secure, Reliable, Transacted Web Services: Architecture and Composition
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/wsoverview.asp
http://www-128.ibm.com/developerworks/webservices/library/ws-securtrans/index.html

[16] WS-I Basic Profile
http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicprofile

[17] XML Schema
http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/
http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/

[18] Web Services Protocol Workshops Process Overview
http://msdn.microsoft.com/webservices/community/workshops/default.aspx
http://www-128.ibm.com/developerworks/offers/WS-Specworkshops/

Principal References

• Call for Participation: OASIS Web Services Transaction Technical Committee
• Announcement 2005-10-12: "OASIS Members Form Committee to Advance Web Services Transaction (WS-TX) Standards. Actional, Adobe, BEA Systems, Cast Iron Systems, DataPower, Fujitsu, Hitachi, IBM, IONA, Microsoft, Oracle, Reactivity, Ricoh, SAP, SOA Software, Sonic Software, Systinet, TIBCO, webMethods, and Others Collaborate on Extensible Framework for Developing Coordination Protocols."
• Earlier news stories:
  • "WS-BusinessActivity Specification Completes the Web Services Transaction Framework." News story 2004-02-03.
  • "Updated Specifications for the Web Services Transaction Framework." News story 2003-09-16.
  • "Web Services Specifications for Business Transactions and Process Automation." News story 2002-08-12. With announcement.
• See also:
  • Web Services Transaction Framework
  • Web Services Coordination (WS-Coordination)
  • Web Services Atomic Transaction (WS-AtomicTransaction)
  • Web Services Business Activity Framework (WS-BusinessActivity)
• General:
  • Web Services Transactions (WS-TX). Arjuna Technologies.
  • Web Services Standards. From BEA Web Services Dev Center
  • Web Services Transactions Specifications. From IBM.
  • IONA and Web Services Transactions Specifications: announcement August 2005.
  • Transaction Specification Index Page. From Microsoft. See also Web Services Specifications Index Page.
• Papers on Web Services Transactions Specifications [IBM, BEA Systems, Microsoft, Arjuna, Hitachi, IONA]:

  • [September 23, 2005] "Power Players Propose Web Services Transaction Standards." By Charles Abrams (Research Director, Gartner) and Daniel Sholler (Research VP, Gartner). September 23, 2005. Gartner Research. Reference: ID Number G00131190. "On 16 September 2005, BEA Systems, Hitachi, IBM, Microsoft and others submitted a charter to the Organization of the Advancement of Structured Information Standards (OASIS) to establish a Web Services Transaction (WS-TX) Technical Committee to refine, and enable industry collaboration on, three transaction specifications: WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity. The specifications... provide a mechanism for managing complex multistep transactions in a distributed system... Significantly, two key vendors in WS standards efforts — IBM and Microsoft — (along with other leading players) are helping to create an OASIS committee that will ratify Web services transaction standards. Transactions are one of the remaining key pieces in the Web services standards puzzle. WS-TX will create a standards-based mechanism for managing the outcome of complex multistep operations in a distributed system. The standards will enable Simple Object Access Protocol (SOAP) and its extensions to act as an internetworking protocol for message-based and loosely coupled systems. This will allow organizations to extend the messaging paradigm throughout the enterprise and to business partners and customers. The transaction framework will also support existing transaction-processing workflows and enable other coordination systems to interoperate in heterogeneous environments while continuing to use proprietary protocols. Transactions (along with reliability and security) are the foundation of most modern systems, and enterprises expect their infrastructure to provide these functions. The WS-TX standards will allow SOAP to fulfill its promise of becoming an application- and implementation-neutral mechanism for achieving consistent application outcomes across message interactions. The WS-TX standards will be a key enabler for SOAP, because they will encompass a discrete set of functionality demanded by users. In turn, this will trigger higher adoption rates for SOAP and for implementations based on Web services standards... IT organizations and vendors should monitor the development of WS-TX standards, which Gartner expects won't be ratified until well into 2006. [Companies should] start planning to use the WS-TX standards to address the challenges faced when building loosely coupled environments. Once the WS-TX standards enable SOAP and its extensions to act as an internetworking protocol for message-based systems, consider using the messaging paradigm in the development of distributed systems, especially those that are enterprisewide or span corporate boundaries..." [PDF, cache]

  • "Secure, Reliable, Transacted Web Services: Architecture and Composition." By Donald Ferguson (IBM Fellow and Chairman IBM Software Group Architecture Board, IBM Corporation), Tony Storey (IBM Fellow, IBM Corporation), Brad Lovering (Distinguished Engineer, Microsoft Corporation), and John Shewchuk , Web Services Architect (Microsoft Corporation). October 28, 2003. "This paper provides a succinct overview for the set of Web service specifications that addresses the needs of security, reliability, and transactability. For the details of the specifications it provides references to the actual documents.The main purpose of this paper is to briefly define the value these specifications provide to our customers. It also describes how these specifications complement each other to compose robust environments for distributed applications..." Also available from Microsoft.

  • "Coordinating Web Services Activities with WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity." Microsoft White Paper. January 28, 2004. Learn "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.

  • "Web Services Transactions: A Practitioner's Approach." By Manish Verma (Center Head and VP Delivery, Second Foundation). From IBM developerWorks. September 30, 2005. "Transactions are an important building block in all serious business applications. A transaction is a unit of work that involves one or more resources and is either completed in its entirety or is not done at all. Participating resources are locked for the duration of the transaction. Depending on the readiness of all the participating resources, the changes made to the resources are either committed or rolled back, and the lock is released... The author shows you how Web services transactions are different from normal transactions, and demonstrates how to create Web services that can participate in transactions."

  • "Tour Web Services Atomic Transaction Operations. Beginner's guide to classic transactions, data recovery, and mapping to WS-AtomicTransactions." By Thomas Freund (Senior Technical Staff Member, IBM) and Daniel House (Senior Technical Staff Member, IBM). September 02, 2004. From IBM developerWorks. "Explore how transactions work in one common and classic form to preserve data integrity, and apply that classical transaction description to the operations of the new Web Services Atomic Transactions (WS-AT) and related Web Services Coordination (WS-C) specifications. Mapping classical to Web services transactions helps you discover that Web Services Atomic Transactions embodies age-old common industry best practices for one kind of transaction."

  • "A Comparison of Web Services Transaction Protocols. A Comparative Analysis of WS-C/WS-Tx and OASIS BTP." By Mark Little (Arjuna Technologies Ltd) and Thomas Freund (IBM).

• Web Services Transaction Workshops:
  • Web Services Protocol Workshops Process Overview. See also information from IBM.
  • WS-TX-Workshops. Yahoo!Groups discussion list. Discussion from the workshops on the Web Services Transaction family of specifications.
  • WS-Transactions Interop Workshop. January 18-19, 2005. "On January 18-19, 2005, a 2-day Interop Workshop was held for the WS-Coordination, WS-AtomicTransaction and WS-BusinessActivity specifications at IBM's facilities in Raleigh, NC where 13 people from 5 companies brought implementations for multi-vendor interop testing. As with previous Web Service-related interoperability events, this workshop focused on giving developers implementing the specification a chance to test their code with other companies' implementations.."
  • WS-Transaction Feedback Workshop. March 10, 2004. "On March 10, 2004, a Specification Feedback Workshop was held for the WS-Coordination, WS-AtomicTransaction and WS-BusinessActivity specifications at Microsoft's campus in Redmond, WA. There were 36 attendees from 16 companies at this Workshop. The authors of this spec, BEA, IBM and Microsoft, discussed various aspects of the spec, including an introduction and detailed drill-down into the specs, implementation experiences, and possible future approaches to interop testing."
• Messaging and Transaction Coordination:
  • Business Process Execution Language for Web Services (WS-BPEL/BPEL4WS)
  • WS-BPEL Extension for People (BPEL4People)
  • Business Transaction Protocol (BTP)
  • OASIS Asynchronous Service Access Protocol TC
  • OASIS Web Services Composite Application Framework (WS-CAF) Technical Committee
  • OASIS Web Services Transaction (WS-TX) Technical Committee
  • W3C Web Services Choreography Working Group
  • Web Service Choreography Interface (WSCI)
  • Web Service Composite Applications Framework (WS-CAF)
    • Web Service Context (WS-CTX)
    • Web Service Coordination Framework (WS-CF)
    • Web Services Transaction Management (WS-TXM)
  • Web Services Choreography Description Language (WS-CDL)
  • Web Services Conversation Language (WSCL)
  • Web Services Transaction Framework
    • Web Services Coordination (WS-Coordination)
    • Web Services Atomic Transaction (WS-AtomicTransaction)
    • Web Services Business Activity Framework (WS-BusinessActivity)
  • WS Choreography
  • Related Work (not further abstracted or referenced):
    • Business Process Management Initiative Specifications (BPML, BPMN, BPQL)
    • Business Process Specification Schema (BPSS), including:
      • ebXML.org [ebBPSS] and Business Process Specification Schema v1.01
      • UN/CEFACT Business Process Specification Schema Project and UN/CEFACT's ebXML BPSS V1.09 Review Draft [source]
    • OMG Business Process Definition
    • Workflow Standard XML Process Definition Language (XPDL)
    • Web Services Flow Language (WSFL)
    • XLANG