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