[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: OASIS TC Call for Participation: OASIS Web Services Reliable Exchange (WS-RX) TC
Here is the Call for Participation for this TC, cross-posted from its official location at http://lists.oasis-open.org/archives/tc-announce/200505/msg00004.html. JBC >Date: Tue, 03 May 2005 20:01:19 -0700 >To: members@lists.oasis-open.org, tc-announce@lists.oasis-open.org >From: James Bryce Clark <jamie.clark@oasis-open.org> >Subject: OASIS TC Call for Participation: OASIS Web Services Reliable >Exchange (WS-RX) TC > > A new OASIS technical committee is being formed. The OASIS Web > Services Reliable Exchange (WS-RX) 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, all of 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 may be found on > the Cover Pages at http://xml.coverpages.org/reliableMessaging.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://oasis-open.org/committees/process.shtml >[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-rx >[5] http://lists.oasis-open.org/archives/ > >==== >1. TC Charter: > >Name > > OASIS Web Services Reliable Exchange Technical Committee (WS-RX) > >Purpose > > The purpose of the OASIS Web Services Reliable Exchange (WS-RX) > Technical Committee (TC) is to define a protocol for reliable message > exchanges between two Web services, through continued development of the > Web Services Reliable Messaging specification [1] submitted to the TC as > referenced in this charter and to define a mechanism by which Web > services express support for reliable messaging as well as other related > useful parameters. This mechanism will be based upon the Web Services > Reliable Messaging Policy Assertion ("WS-RM Policy") specification [2] > submitted to the TC. > >Scope > > The TC will accept as input the February 2005 Version 1.0 of the WS- >ReliableMessaging [1] and WS-RM Policy [2] specifications (the Input >Documents) from BEA Systems, IBM, Microsoft, and TIBCO Software. 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. OASIS members >with extensive experience and knowledge in these areas are particularly >invited to participate. > > The scope of the TC's work is to continue development and refinement > of the input documents to produce as output modular specifications that > standardize the concepts, WSDL documents and XML schema renderings > required to provide reliability assurances to message exchanges between > two parties that conform to the specifications. > > Reliable messaging systems can generally be described using a four > agent model. In this model there is an Application Source, a Reliable > Messaging Source that acts on behalf of the Application Source, an > Application Destination and a Reliable Messaging Destination that acts on > behalf of the Application Destination. Message Transfer is the function > of moving messages from a Reliable Message Source to a Reliable Messaging > Destination. This TC will provide protocols for the reliable message > transfers that occur between Reliable Messaging Sources and Reliable > Messaging Destinations. The TC will not develop additional mechanisms by > which a Reliable Messaging Source captures messages from an Application > Source or mechanisms by which a Reliable Messaging Destination delivers > messages to an Application Destination. > > A reliable message transfer is one in which certain reliability > assurances exist between two parties even in the presence of a variety of > failures. There can be multiple, concurrent and independent reliable > exchanges between two parties. Reliability assurances make statements > about the type of reliability provided to a message exchange. > > The specifications will define a set of basic concepts required for > the correct functioning of message exchanges with reliability assurances. > The specifications will render these concepts as a specific set of > restrictions over SOAP messages including XML schemas and WSDL documents. > > The specific reliability assurances in the scope of the TC are: > -- At Least Once: Messages are transferred at least one time or an > error is raised on at least one of the endpoints. It is possible that > some messages are transferred more than once. > -- At Most Once: Messages are transferred at most one time or an > error is raised on at least one of the endpoints. It is possible that > some messages are not transferred. > -- Exactly Once: Messages are transferred at least one time and at > most one time or an error is raised on at least one of the endpoints. > -- Ordered: Messages are transferred in the order in which they are > sent. > > These reliability assurances can be combined and certain combinations > are of particular interest due to their widespread application: Exactly > Once and Ordered (also referred to as Exactly Once Ordered). > > The specifications developed by the WS-RX TC will define mechanisms > that support and allow the implementation and expression of reliability > assurances, at most once, at least once, exactly once, ordered, and will > not define mechanisms for applications to manifest reliability assurances. > > The specifications developed by the WS-RX TC will define elements and > relationships among elements that enable the implementation of the > following functions which support the reliability assurances in the scope > of the TC: > -- Reliable establishment and teardown of one or more independent > shared contexts between two parties within which reliability assurances > apply to one-way or two-way messaging. > -- A mechanism which two parties can use to perform one-way or > two-way reliable messaging within a reliable context. > -- Ensures timely destination amnesia detection. Destination amnesia > is the condition resulting from catastrophic failure in which a > Destination loses the shared context required by reliability assurances. > -- At Most Once reliability assurances even in the case of > Destination amnesia. > -- Efficient message retransmission and acknowledgment. > -- Duplicate message detection. > -- Detection of out-of-order messages and discovery of the correct > order of messages. > -- Unique identification of messages within a reliable context > -- Acknowledgement of all messages within a reliable context > -- RM protocol violation detection and the raising and transmission > of related fault information. > -- Efficient preservation of the integrity of reliable contexts by > composition with WS-Security or other SOAP security mechanisms. > -- Expression of support for the specifications using the WS-Policy > Framework [9] and binding of that policy to a WSDL port. > -- A binding of the reliable messaging protocol elements to SOAP 1.1 > and SOAP 1.2. > > 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 [3], WS-Trust [4], > WS-SecureConversation [5], WS-Addressing [6], SOAP 1.1 [7], SOAP 1.2 [8], > bindings of SOAP 1.1/1.2 to HTTP, WS-Policy [9], WSDL 1.1 [10] and WSDL > 2.0 [11]. The TC will also take into consideration applicable work, such > as the WS-I Basic Profile [12]. The "Secure, Reliable, Transacted Web > Services: Architecture & Composition" white paper [13] published in 2003 > provides information on the Web services architecture. > > If an 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 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 RM specifications. > > Each of the protocol elements will use implementation and language > neutral XML formats defined in XML Schema [14]. > > 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 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, to any > particular messaging >middleware, nor to specific network transports. > > The elements and/or mechanisms the TC defines must be independent of > issues and considerations that do not affect an interoperable reliable > messaging protocol. > > Specifically: the TC is not concerned with binding the specifications > to specific underlying transports. > > The TC and the specifications that it produces do not address > considerations, such as durability related to Sources' and/or > Destinations' ability to satisfy reliability assurances. > > 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 reliably according to the specifications. > > The TC will make no assumptions about the location of Application > Sources relative to RM Sources and Application Destinations relative to > RM Destinations. > > The TC will not attempt to define concepts or renderings for functions > that are of wider applicability including but not limited to: > -- Security (Encryption, Integrity and Authentication) > -- Addressing > -- Policy languages and frameworks > -- Routing > -- Transactions and Compensation > > Where required these functions are achieved by composition with other > Web services specifications. > > The TC will not attempt to define functionality duplicating that of > any normatively referenced specification in the input > WS-ReliableMessaging or WS-RM Policy 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. > >Deliverables > > The TC has the following set of deliverables. > -- A revised Web Services Reliable Messaging Protocol > specification. Committee Specifications are scheduled for completion > within one year of the first TC meeting. > -- A revised Web Services Reliable Messaging Policy Assertion > 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. > > 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. > > The TC may choose to vary the number of the specification documents > and their titles. > >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. > >Audience > > The anticipated audience for this work includes: > -- Vendors offering Web services products; > -- Other specification authors that need reliable message delivery > 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 reliable messaging solution. > >Language > > TC business will be conducted in English. > >2. Non-normative information regarding the TC: > >Similar or applicable work > > The following work may be relevant to this WS-RX TC: > > Similar Work: > -- OASIS Web Services Reliable Messaging TC. The WSRM TC has a > similar goal to that of WS-RX; to specify reliable message delivery for > Web services. However, the WSRM TC has a fundamentally different view > with regard to scope of the specification, required functions, policy, > and Web services architecture >composability. > -- OASIS ebMS TC. The ebMS TC has as part of its scope a similar > goal to that of WS-RX. However, it has a fundamentally different view > with regard to scope, QoS, required functions and Web services composability. > > The proposers of this TC recognize there are different reliability > approaches in the industry and believe that the defined Scope of Work of > this TC addresses many functional use cases of these parallel efforts. > The proposers of this TC seek involvement from the authors of > WS-Reliability in particular, and the contribution of their expertise and > experience, and intend to work in harmony with them in the creation of > the product of this technical committee. > > Applicable Work: > -- OASIS Web Services Security TC. WS-RX will ensure that its > specifications compose with the WSS TC specifications. > -- W3C Web Services Addressing WG. WS-RX 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. > > Anticipated contributions: > -- The current WS-Reliable Messaging [1] and WS-RM Policy [2] > specifications, as published February 2005 by BEA, IBM, Microsoft, and > TIBCO Software are expected to be contributed to this TC. > >First meeting > > The first meeting of the WS-RX TC will be a face to face meeting held > in Palo Alto, California, USA on Thursday, June 23 from 9:00 am to 5:30 > local time and Friday June 24 from 9am to 12pm local time. This meeting > will be sponsored by SAP. > >On-going meeting schedule > > It is anticipated the WS-RX Technical Committee will meet via > teleconference every week at a time determined by the TC members during > the TC's first meeting. It is anticipated that the WS-RX 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 will donate their facilities. > >Proposers > > The following eligible individuals are in support of this proposal: > >Atsushi Atarashi, NEC, atarashi@sv.nec-labs.com >Anto Budiardjo, Individual Member, antob@clasma.com >Abbie Barbir, Nortel, abbieb@nortel.com >Doug Bunting, Sun Microsystems, doug.bunting@sun.com >Lloyd Burch, Novell, lburch@novell.com >Serge Cayron, ACORD, scayron@acord.org >Steve Carter, Novell, srcarter@novell.com >David Chappell, Sonic Software, dchappell@sonicsoftware.com >Alan Clark, Novell, aclark@novell.com >Lloyd Chumbley, ACORD, lchumbley@acord.org >David Connelly, OAGI, dconnelly@openapplications.org >Toby Considine, The University of North Carolina at Chapel Hill, >toby.considine@fac.unc.edu >Paul Cotton, Microsoft Corporation, pcotton@microsoft.com >Glen Daniels, Sonic Software, gdaniels@sonicsoftware.com >Chris Ferris, IBM, chrisfer@us.ibm.com >Dan Foody, Actional, dan.foody@actional.com >Paul Fremantle, IBM, pzf@uk.ibm.com >Robert Freund, Hitachi, Ltd., bob.freund@hitachisoftware.com >Peter Furniss, Choreology, peter.furniss@choreology.com >Alastair Green, Choreology, alastair.green@choreology.com >Anish Karmarkar, Oracle, Anish.Karmarkar@oracle.com >Chris Kurt, Microsoft Corporation, ckurt@microsoft.com >Dan Leshchiner, TIBCO, dleshc@tibco.com >Mark Little, Arjuna, mark.little@arjuna.com >Matt Mackenzie, Adobe, mattm@adobe.com >Matt Mihic, Blue Titan, mmihic@bluetitan.com >Jeff Mischkinsky, Oracle, jeff.mischkinsky@oracle.com >Nilo Mitra, Ericsson, nilo.mitra@ericsson.com >Tim Moses, Entrust, tim.moses@entrust.com >Eric Newcomer, IONA, eric.newcomer@iona.com >David Orchard, BEA Systems, dorchard@bea.com >Sanjay Patil, SAP, sanjay.patil@sap.com >Jim Purves, United Kingdom e-Government Unit, >jim.purves@cabinet-office.x.gsi.gov.uk >Andrew Nash, Reactivity, anash@reactivity.com >Shivajee Samdarshi, TIBCO, shivajee@tibco.com >Jiri Tejkl, Systinet, jiri.tejkl@systinet.com >Claus von Riegen, SAP, claus.von.riegen@sap.com >Pete Wenzel, SeeBeyond, pete@seebeyond.com >Steve Winkler, SAP, steve.winkler@sap.com >Prasad Yendluri, webMethods, prasad.yendluri@webmethods.com >Matsuki Yoshino, Hitachi, Ltd., yoshinom@itg.hitachi.co.jp > >Convener > > Paul Cotton, Microsoft Corporation, pcotton@microsoft.com > >Proposed TC Chairs > > Paul Fremantle, IBM, pzf@uk.ibm.com > Sanjay Patil, SAP, sanjay.patil@sap.com > >References > >[1] WS-ReliableMessaging >http://schemas.xmlsoap.org/ws/2005/02/rm > >[2] WS-RM Policy >http://schemas.xmlsoap.org/ws/2005/02/rm/policy > >[3] WS-Security >http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf > >[4] WS-Trust >http://schemas.xmlsoap.org/ws/2005/02/trust > >[5] WS-SecureConversation >http://schemas.xmlsoap.org.ws/2005/02/sc > >[6] WS-Addressing >http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/ > >[7] SOAP 1.1 >http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ > >[8] SOAP 1.2 >http://www.w3.org/TR/soap12-part1/ >http://www.w3.org/TR/soap12-part2/ > >[9] WS-Policy >http://schemas.xmlsoap.org/ws/2004/09/policy > >[10] WSDL 1.1 >http://www.w3.org/TR/2001/NOTE-wsdl-20010315 > >[11] WSDL 2.0 >http://www.w3.org/TR/wsdl20-extensions >http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803 > >[12] WS-I Basic Profile >http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicprofile > >[13] Secure, Reliable, Transacted Web Services: Architecture & Composition >http://msdn.microsoft.com/webservices/understanding/advancedwebservices/default.aspx?pull=/library/en-us/dnwebsrv/html/wsoverview.asp > > >http://www-128.ibm.com/developerworks/webservices/library/ws- >securtrans/index.html > >[14] XML Schema >http://www.w3.org/TR/xmlschema-1/ >http://www.w3.org/TR/xmlschema-2/ > >====
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]