[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
>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-sec
>urity-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/
>
>====
>
>
>---------------------------------------------------------------------
>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
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]