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  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  submitted to the TC.
The TC will accept as input the February 2005 Version 1.0 of the WS-ReliableMessaging  and WS-RM Policy  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  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 , WS-Trust , WS-SecureConversation , WS-Addressing , SOAP 1.1 , SOAP 1.2 , bindings of SOAP 1.1/1.2 to HTTP, WS-Policy , WSDL 1.1  and WSDL 2.0 . The TC will also take into consideration applicable work, such as the WS-I Basic Profile . The "Secure, Reliable, Transacted Web Services: Architecture & Composition" white paper  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 this TC.
Each of the protocol elements will use implementation and language neutral XML formats defined in XML Schema .
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)
Policy languages and frameworks
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.
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. Following this, ratification of updated specifications as revised OASIS standards to address any errata to fix errors and to replace policy references to the WS-Policy W3C Recommendation as soon as that Recommendation is available will mark the end of the TC's lifecycle.
The TC may choose to vary the number of the specification documents and their titles.
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.
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.