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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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

Subject: Re: [ebxml-msg] FW: [members] OASIS TC Call for Participation: OASISWeb Services Reliable Exchange (WS-RX) TC

It would be interesting to discuss what would be required in ebms to 
enable pluggability of rm processors. 

Dale Moberg wrote:

>If we are meeting today, could we add the following item to our agenda
>and try to figure out what convergence involves for the reliability
>functionality in 3.0?
>Dale Moberg
>-----Original Message-----
>From: James Bryce Clark [mailto:jamie.clark@oasis-open.org] 
>Sent: Tuesday, May 03, 2005 8:01 PM
>To: members@lists.oasis-open.org; tc-announce@lists.oasis-open.org
>Subject: [members] 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
>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
>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
>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
>     (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
>"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
>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
>the TC's public home page at [4]. Archives of the TC's mail list and
>comment lists, as with all OASIS TCs, will be visible at [5].
>     Further information generally related to the topic may be found on
>Cover Pages at http://xml.coverpages.org/reliableMessaging.html.
>     Please feel free to forward this announcement to any other
>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:
>     OASIS Web Services Reliable Exchange Technical Committee (WS-RX)
>     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
>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
>the TC.
>     The TC will accept as input the February 2005 Version 1.0 of the
>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
>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
>of the input documents to produce as output modular specifications that 
>standardize the concepts, WSDL documents and XML schema renderings
>to provide reliability assurances to message exchanges between two
>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
>behalf of the Application Destination. Message Transfer is the function
>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
>failures. There can be multiple, concurrent and independent reliable 
>exchanges between two parties. Reliability assurances make statements
>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
>The specifications will render these concepts as a specific set of 
>restrictions over SOAP messages including XML schemas and WSDL
>     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
>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
>messages are not transferred.
>     --  Exactly Once:  Messages are transferred at least one time and
>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
>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
>     The specifications developed by the WS-RX TC will define elements
>relationships among elements that enable the implementation of the 
>following functions which support the reliability assurances in the
>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
>is the condition resulting from catastrophic failure in which a
>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
>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
>Framework [9] and binding of that policy to a WSDL port.
>     --  A binding of the reliable messaging protocol elements to SOAP
>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
>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
>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
>Web services architecture.
>     If an above specification is outside of a standardization process
>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
>TC output will be expressed in an abstract manner, and the incarnation
>be left at that time as an exercise in interoperability.
>     While composition with other specifications is a goal of the TC, it
>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
>only for the sake of clarity. If some function, mechanism or feature is
>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
>issues and considerations that do not affect an interoperable reliable 
>messaging protocol.
>    Specifically: the TC is not concerned with binding the
>to specific underlying transports.
>     The TC and the specifications that it produces do not address 
>considerations, such as durability related to Sources' and/or
>ability to satisfy reliability assurances.
>     Except for the elements directly related to the functions in the
>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
>    The TC will not attempt to define concepts or renderings for
>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
>Web services specifications.
>     The TC will not attempt to define functionality duplicating that of
>any normatively referenced specification in the input
>or WS-RM Policy specifications. If the referenced specification is
>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 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
>technological improvements with respect to the input documents and in 
>accordance with this charter.
>     Ratification of the above specifications as OASIS Standards,
>a brief period to address any errata, will mark the end of the TC's
>     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"
>mode as defined in the OASIS Intellectual Property Rights (IPR) Policy, 
>effective 15 April 2005.
>     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
>an interoperable, composable reliable messaging solution.
>     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
>services.   However, the WSRM TC has a fundamentally different view with
>regard to scope of the specification, required functions, policy, and
>services architecture
>     --  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
>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.
>proposers of this TC seek involvement from the authors of WS-Reliability
>particular, and the contribution of their expertise and experience, and 
>intend to work in harmony with them in the creation of the product of
>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
>     The TC may decide to establish liaisons with other groups as
>Responsibilities for such liaison will be defined by the TC at that
>     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
>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
>TC's first meeting.  It is anticipated that the WS-RX Technical
>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.
>     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,
>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, 
>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
>     Paul Cotton, Microsoft Corporation, pcotton@microsoft.com
>Proposed TC Chairs
>     Paul Fremantle, IBM, pzf@uk.ibm.com
>     Sanjay Patil, SAP, sanjay.patil@sap.com
>[1] WS-ReliableMessaging
>[2] WS-RM Policy
>[3] WS-Security
>[4] WS-Trust
>[5] WS-SecureConversation
>[6] WS-Addressing
>[7] SOAP 1.1
>[8] SOAP 1.2
>[9] WS-Policy
>[10] WSDL 1.1
>[11] WSDL 2.0
>[12] WS-I Basic Profile
>[13] Secure, Reliable, Transacted Web Services: Architecture &
>[14] XML Schema
>To unsubscribe, e-mail: members-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: members-help@lists.oasis-open.org
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in OASIS

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