OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tc-announce message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: OASIS TC Call for Participation: OASIS Web Services Transaction Technical Committee




      A new OASIS technical committee is being formed. The OASIS Web 
Services Transaction Technical Committee has been proposed by the members 
of OASIS listed below.  The proposal (below) meets the requirements of the 
OASIS TC Process [1].  The TC name, statement of purpose, scope, list of 
deliverables, audience, and language specified in the proposal will 
constitute the TC's official charter. Submissions of technology for 
consideration by the TC, and the beginning of technical discussions, may 
occur no sooner than the TC's first meeting.

      This TC will operate under our 2005 IPR Policy.[2]  The eligibility 
requirements for becoming a participant in the TC at the first meeting (see 
details below) are that:
      (a) you must be an employee of an OASIS member organization or an 
individual member of OASIS;
      (b) the OASIS member must sign the OASIS membership agreement (see [3]);
      (c) you must notify the TC chair of your intent to participate at 
least 15 days prior to the first meeting, which members may do by using the 
"Join this TC" button on the TC's public page at [4]; and
      (d) you must attend the first meeting of the TC, at the time and date 
fixed below.
Of course, it also will be possible to join the TC at a later time. 
Standards always are improved by broad participation.

      Non-OASIS members who wish to participate may contact us about 
joining OASIS [3].  Our rules and structure are designed to promote 
inclusiveness. We look forward to assisting parties interested in joining 
the community of implementers, technologists, academics and end-users 
working on OASIS standardization projects.  All also are welcome to take 
advantage of the public resources maintained for each TC: a mail list 
archive, document repository and public comments facility, which will be 
available via the TC's public home page at [4].  Archives of the TC's mail 
list and public comment lists, as with all OASIS TCs, will be visible at [5].

      Further information generally related to the topic area addressed by 
this TC may be found on the Cover Pages at "Messaging and Transaction 
Coordination":  http://xml.coverpages.org/coordination.html

      Please feel free to forward this announcement to any other 
appropriate lists.  OASIS is an open standards organization; we encourage 
your feedback.  JBC

~ James Bryce Clark
~ Director, Standards Development, OASIS
~ jamie.clark@oasis-open.org

[1] http://www.oasis-open.org/committees/process.php
[2] http://www.oasis-open.org/who/intellectualproperty.php
[3] See http://www.oasis-open.org/join/
[4] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-tx
[5] http://lists.oasis-open.org/archives/

====
WEB SERVICES TRANSACTION TC

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

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

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

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

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

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

d. On-Going Meeting Plans & 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.

e. Proposers of the TC

is Kurt, Microsoft Corporation, ckurt@microsoft.com
MarAbbie 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@openapplicaitons.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
Chrk 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

f. TC Convener

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

g. 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 & Composition
http://msdn.microsoft.com/webservices/understanding/advancedwebservices/default.asp
x?pull=/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/

END



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]