The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors
NEWS
Cover Stories
Articles & Papers
Press Releases
CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG
TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps
EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
Created: May 04, 2005.
News: Cover StoriesPrevious News ItemNext News Item

Call for Participation in the OASIS Web Services Reliable Exchange (WS-RX) TC.

Contents

Update 2007-05-15: WS-ReliableMessaging Version 1.1 was submitted for ballot as an OASIS Standard in May 2007. Four years in development, WS-RM has three parts. The core "WS-ReliableMessaging V1.1" document defines a protocol for reliable message exchange even in the presence of network/system failures. The protocol allows Web service nodes to implement a variety of delivery assurances, including 'At Most Once', 'At Least Once', 'Exactly Once', and 'In Order' delivery of messages. "WS-ReliableMessaging Policy 1.1" defines an XML policy language that enables Web services to advertise their support for the WS-ReliableMessaging specification; it is is designed for use with the WS-Policy Framework. "WS-MakeConnection" defines a protocol for two-way communication when only a transport specific back-channel is available. See "WS-ReliableMessaging Version 1.1 Submitted for Ballot as an OASIS Standard."

[May 04, 2005] On May 03, 2005, OASIS issued a Call for Participation in a new Technical Committee chartered to define a protocol for reliable message exchanges between two Web services, through continued development of the Web Services Reliable Messaging (WS-RM) specification.

The OASIS Web Services Reliable Exchange (WS-RX) Technical Committee will operate in the 'RF on RAND Terms' IPR mode as defined in the new OASIS IPR Policy. Some forty-one (41) individuals identified as TC Proposers have already agreed to support the work of the new TC, representing at least twenty-eight (28) corporate institutions: ACORD, Actional, Adobe, Arjuna, BEA Systems, Blue Titan, Choreology, Entrust, Ericsson, Hitachi, IBM, IONA, Microsoft, NEC, Nortel, Novell, OAGi, Oracle, Reactivity, SAP, SeeBeyond, Sonic Software, Sun Microsystems, Systinet, TIBCO, United Kingdom e-Government Unit, The University of North Carolina at Chapel Hill, and webMethods.

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

Reliable messaging systems, according to the WS-RX Charter, "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."

Given this model, the new OASIS Technical Committee "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."

The specifications to be developed in the TC "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 scope for design by the TC are: (1) At Least Once, where messages are transferred at least one time or an error is raised on at least one of the endpoints, [given it] is possible that some messages are transferred more than once; (2) At Most Once, where messages are transferred at most one time or an error is raised on at least one of the endpoints; (3) Exactly Once, where messages are transferred at least one time and at most one time or an error is raised on at least one of the endpoints; (4) Ordered, guaranteeing that messages are transferred in the order in which they are sent."

The WS-RX TC will continue development of the (BEA Systems, IBM, Microsoft, and TIBCO Software) Web Services Reliable Messaging specification (WS-ReliableMessaging) submitted to the TC. The defined mechanism by which Web services express support for reliable messaging and related useful parameters "will be based upon the Web Services Reliable Messaging Policy Assertion (WS-RM Policy) specification," also to be submitted to the TC. The WS-RX work will be designed to compose with the WSS TC specifications and will utilize the WS-Addressing functions where appropriate, and avoiding the creation of overlapping functions.

Many approaches have been taken to reliable message transfer. The WS-RX TC Call for Participation includes a discussion of related work which recognizes the OASIS Web Services Reliable Messaging TC and OASIS ebMS TC. The WSRM TC, although it has a goal similar to that of WS-RX, "has a fundamentally different view with regard to scope of the specification, required functions, policy, and Web services architecture composability." The OASIS ebMS TC is said to have a fundamentally different view with regard to scope, QoS, required functions, and Web services composability."

The proposers of the OASIS Web Services Reliable Exchange (WS-RX) Technical Committee "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.

The first meeting of the WS-RX will be held as a F2F meeting June 23-24, 2005 in Palo Alto, California, hosted by SAP. The WS-RX TC Convener is Paul Cotton (Microsoft Corporation); the proposed TC Chairs are Paul Fremantle (IBM) and Sanjay Patil (SAP).

From the WS-RX TC Charter and Call for Participation

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.

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.

Technical Committe 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
  • End users implementing Web services-based solutions that require an interoperable, composable reliable messaging solution

Language

TC business will be conducted in English.

Additional Information

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.

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

TC Proposers

The following eligible individuals are in support of this proposal:

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

RF on RAND Terms IPR Mode

The WS-RX TC will operate under the 'RF on RAND Terms IPR Mode' as described in the 2005-04-15 OASIS IPR Policy:

10.2.2 RF on RAND Terms: "With TCs operating under the RF on RAND Terms IPR Mode, license terms that are fair, reasonable, and non-discriminatory beyond those specifically mentioned in Section 10.2.1 may also be included, and such additional RAND terms are left to the Licensees and Obligated Parties involved."

10.2.1 Common terms (excerpted from the full text): "... except where a Licensee has a separate, signed agreement under which the Essential Claims are licensed to such Licensee on more favorable terms and conditions than set forth in this section (in which case such separate signed agreement shall supersede this Limited Patent License), each Obligated Party in such TC hereby covenants that, upon request and subject to Section 11, it will grant to any OASIS Party or third party: a nonexclusive, worldwide, non-sublicensable, perpetual patent license (or an equivalent non-assertion covenant) under its Essential Claims covered by its Contribution Obligations or Participation Obligations without payment of royalties or fees, and subject to the applicable Section 10.2.2 or 10.2.3, to make, have made, use, market, import, offer to sell, and sell, and to otherwise distribute Licensed Products directly or indirectly that implement such specification. Such license need not extend to features of a Licensed Product that are not required to comply with the Normative Portions of such specification. For the sake of clarity, the rights set forth above include the right to directly or indirectly authorize a third party to make unmodified copies of the Licensee's Licensed Products and to license (optionally under the third party's license) the Licensee's Licensed Products, within the scope of, and subject to the terms of, the Obligated Party's license.

At the election of the Obligated Party, such license may include a term requiring the Licensee to grant a reciprocal license to its Essential Claims (if any) covering the same OASIS Committee Specification or OASIS Standard. Such term may require the Licensee to grant licenses to all implementers of such specification. The Obligated Party may also include a term providing that such license may be suspended with respect to the Licensee if that Licensee first sues the Obligated Party for infringement by the Obligated Party of any of the Licensee's Essential Claims covering the same OASIS Committee Specification or OASIS Standard..."

Note: BEA Systems, IBM, Microsoft and TIBCO Software may have patents or patent applications ['their respective essential patent claims that they deem necessary to implement'] relevant to the technology being submitted to the WS-RX Technical Committee, viz., the Web Services Reliable Messaging Protocol (WS-ReliableMessaging) specification and the Web Services Reliable Messaging Policy Assertion (WS-RM Policy) specification. The Copyright Notices for these specifications read (in part) "BEA Systems, IBM, Microsoft and TIBCO Software (collectively, the 'Authors') each agree to grant you a license, under royalty-free and otherwise reasonable, nondiscriminatory terms and conditions, to their respective essential patent claims that they deem necessary to implement the Specification."

Principal References
Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

Primeton

XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Bottom Globe Image

Document URI: http://xml.coverpages.org/ni2005-05-04-a.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org