Update 2004-11-15: "WS-Reliability Version 1.1 Approved as an OASIS Standard." The OASIS membership has voted to ratify the "WS-Reliability 1.1" specification as an OASIS Standard. The specification provides a method to guarantee message delivery over the Internet, enabling companies to conduct reliable business-to-business trading or collaboration using current Web services standards. WS-Reliability defines a SOAP-based protocol for exchanging SOAP messages with guaranteed delivery, no duplicates, and guaranteed message ordering.

[September 10, 2004] The OASIS Web Services Reliable Messaging Technical Committee has published a milestone version of its Web Services Reliable Messaging (WS-Reliability) specification, including a prose document and four supporting XML schemas.

WS-Reliability is a "SOAP-based specification that fulfills reliable messaging requirements critical to some applications of Web Services. It is needed because SOAP over HTTP is not sufficient when an application-level messaging protocol must also guarantee some level of reliability and security.

Reliable Messaging in this context refers to "act of processing the set of transport-agnostic SOAP Features defined by WS-Reliability, which results in a protocol supporting quality of service features such as guaranteed delivery, duplicate message elimination, and message ordering. Reliable messaging requires the definition and enforcement of contracts between (1) The Sending and Receiving message processors — contracts about the wire protocol, (2) The messaging service provider and the users of the messaging service — contracts about quality of service."

WS-Reliability supports message reliability by defining: (1) Guaranteed message delivery, or At-Least-Once delivery semantics; (2) Guaranteed message duplicate elimination, or At-Most-Once delivery semantics; (3) Guaranteed message delivery and duplicate elimination, or Exactly-Once delivery semantics; (4) Guaranteed message ordering for delivery within a group of messages.

The WS-Reliability specification "defines reliability in the context of current Web Services standards and has been designed for use in combination with complementary protocols. W3C SOAP 1.1 and 1.2 are the the base protocols for WS-Reliability, which defines reliable messaging protocol features expressed as extension header blocks embedded in the SOAP Header. The reliable messaging mechanism defined in the ebXML Message Service Specification 2.0 is implemented in a number of products and open source efforts, many of which have undergone interoperability testing; WS-Reliability borrows from this technology. WS-Reliability can be used with OASIS Web Services Security: SOAP Message Security 1.0 (WSS). The specification also defines how to use reliability in compliance with WS-I Basic Profile 1.1."

It is anticipated that the WS-Reliability version 1.1 specification voted by the TC as a Committee Draft level work product (August 24, 2004) will be balloted for approval as an OASIS Standard in October 2004.

Bibliographic Information

The latest public version of the WS-Reliability specification (Version "1.1" [CD 1.086] voted as 'CD' by the WSRM TC) is distributed as a ZIP archive containing a prose document in PDF format and four XML schema files.

• Web Services Reliable Messaging TC. WS-Reliability 1.1. Reference: Committee Draft. Version 1.086. August 24, 2004. 72 pages. Document identifier: 'oasis-wsrm-ws_reliability-1.1-spec-cd-1.086'. Principal editor: Kazunori Iwasa (Fujitsu Limited). Assisting editors: Jacques Durand (Fujitsu Software Corporation), Tom Rutt (Fujitsu Software Corporation), Mark Peel (Novell, Inc.), Sunil Kunisetty (Oracle Corporation), and Doug Bunting (Sun Microsystems). [revision 1]

  Acknowledgments. The following individuals were members of the committee during the development of this specification: David Ingham (Arjuna Technologies Limited), Joseph Chiusano (Booz Allen Hamilton), Peter Furniss (Choreology Ltd), Jeff Turpin (Cyclone Commerce), Pramila Mullan (France Telecom), Jacques Durand (Fujitsu), Kazunori Iwasa (Secretary, Fujitsu), Tom Rutt (Chair, Fujitsu), Jishnu Mukerji (Hewlett-Packard), Robert Freund (Hitachi), Eisaku Nishiyama (Hitachi), Nobuyuki Yamamoto (Hitachi), Ben Bloch (Individual), Mark Hansen (Individual), Paolo Romano (Individual), Dock Allen (Mitre Corporation), Junichi Tatemura (NEC Corporation), Alan Weissberger (NEC Corporation), Magdolna Gerendai (Nokia), Szabolcs Payrits (Nokia), Mark Peel (Novell), Sunil Kunisetty (Secretary, Oracle), Anish Karmarkar (Oracle), Jeff Mischkinsky (Oracle), Marc Goodner (Secretary, SAP), Pete Wenzel (SeeBeyond Technology Corporation), Doug Bunting (Secretary, Sun Microsystems), Tony Graham (Sun Microsystems), Chi-Yuen Ng (University of Hong Kong), Patrick Yee (University of Hong Kong), Prasad Yendluri (webMethods Inc.), Scott Werden (WRQ Inc).

• XML Schema for WS-Reliability Protocol Headers for SOAP 1.1 & SOAP 1.2 Protocols. Edited by Sunil Kunisetty, Scott Werden, and Doug Bunting. Version: 1.1. August 04, 2004. File: 'ws-reliability-1.1.xsd'. "In a case where the text of the specification is shown to be in conflict with schema statements, the Schema statement prevails."

• XML Schema for Features, Property, and Compositor Constructs. Edited by Sunil Kunisetty and Anish Karmarkar. Version: 1.1. June 07, 2004. File: 'fnp-1.1.xsd'. "In a case where the text of the specification is shown to be in conflict with schema statements, the Schema statement prevails."

• XML Schema for ServiceRefType. Edited by Sunil Kunisetty and Anish Karmarkar. Version: 1.1. June 07, 2004. File: 'reference-1.1.xsd'. "In a case where the text of the specification is shown to be in conflict with schema statements, the Schema statement prevails."

• XML Schema for WSRM Features And Properties. Edited by Sunil Kunisetty and Anish Karmarkar. Version: 1.1. August 03, 2004. File: 'wsrmfp-1.1.xsd'. "In a case where the text of the specification is shown to be in conflict with schema statements, the Schema statement prevails."

WS-Reliability Sample Software from Fujitsu, Hitachi, and NEC

"A highly reliable message delivery infrastructure is necessary in e-business where important information, such as purchase orders and billing, is exchanged. The delivery of an incorrect purchase order or the non-delivery of an order cancellation could cause serious problems for a company. In order to avoid such problems in e-business executed using Web services, it is necessary to provide a highly reliable messaging infrastructure for Web services. To encourage the swift and wide-ranging implementation of such an infrastructure, its technology should be both open and royalty-free..."

Publication of WS-Reliability sample software [WS-Reliability sample software 'RM4GS alpha version']: "In addition to standardizing the specification, Fujitsu has developed WS-Reliability-compatible sample software jointly with Hitachi, Ltd., and NEC Corporation in order to help the spread of the highly reliable messaging infrastructure. This sample software demonstrates the fact that WS-Reliability is a high quality specification that is ready for implementation. The sample software was developed as part of the "Business Grid Computing Project" hosted by the Japanese Ministry of Economy, Trade and Industry. The WS-Reliability sample software "RM4GS alpha version" is available for download free of charge..." [from Fujitsu XML Solutions, WS-Reliability Activities]

About the OASIS Web Services Reliable Messaging TC

The OASIS Web Services Reliable Messaging Technical Committee (WSRM TC) was chartered in February 2003 to "create a generic and open model for ensuring reliable message delivery for Web services. This TC defines reliable message delivery as the ability to guarantee message delivery to software applications — Web services or Web service client applications — with a chosen level of quality of service (QoS). For this TC effort, QoS will be defined as the ability to determine the following aspects of message delivery: Message persistence; Message acknowledgement and resending; Elimination of duplicate messages; Ordered delivery of messages; Delivery status awareness for sender and receiver applications. The TC will specify rules for combining these features and their parameters...

Essential elements of web services are SOAP and WSDL. The specification to be created will provide WSDL definitions for reliable messaging and the message formats will be specified as SOAP headers and/or body content. The resulting specification must be programming language-neutral and platform-neutral. Lastly, the TC will address the dependencies between the capacity of the messaging nodes (persistence, message processing) and the level of QoS that can be provided...

In no event shall this [WSRM] Technical Committee finalize or approve any technical specification if it believes that the use, distribution, or implementation of such specification would necessarily require the unauthorized infringement of any third party rights known to the Technical Committee, and such third party has not agreed to provide necessary license rights on perpetual, royalty-free, non-discriminatory terms..."

The WSRM TC Chair is Mr. Tom Rutt (Fujitsu). Secretaries [2004-09] include Doug Bunting (Sun Microsystems), Jacques Durand (Fujitsu), Kazunori Iwasa (Fujitsu), and Mark Peel (Novell).

Related Technology: WS-ReliableMessaging

A Web Services Reliable Messaging Protocol (WS-ReliableMessaging) specification from BEA, IBM, Microsoft, and TIBCO Software covers some of the same territory as WS-Reliability. From the version of March 2004 version of WS-ReliableMessaging:

It is often a requirement for two Web services that wish to communicate to do so reliably in the presence of software component, system, or network failures. The primary goal of this specification is to create a modular mechanism for reliable message delivery. It defines a messaging protocol to identify, track, and manage the reliable delivery of messages between exactly two parties, a source and a destination. It also defines a SOAP binding that is required for interoperability. Additional bindings may be defined.

This mechanism is extensible allowing additional functionality, such as security, to be tightly integrated. This specification integrates with and complements the WS-Security, WS-Policy, and other Web services specifications. Combined, these allow for a broad range of reliable, secure messaging options...

WS-ReliableMessaging provides an interoperable protocol that a Reliable Messaging (RM) Source and Reliable Messaging (RM) Destination use to provide application source and destinations a guarantee that a message that is sent will be delivered. The guarantee is specified as a delivery assurance. The protocol supports the endpoints in providing these delivery assurances. It is the responsibility of the RM Source and RM Destination to fulfill the delivery assurances, or raise an error. The protocol defined here allows endpoints to meet this guarantee for the [defined] delivery assurances...

Persistence considerations related to an endpoint's ability to satisfy the delivery assurances defined below are the responsibility of the implementation and do not affect the wire protocol. As such, they are out of scope of this specification.

There are four basic delivery assurances that endpoints can provide:

• AtMostOnce Messages will be delivered at most once without duplication or an error will be raised on at least one endpoint. It is possible that some messages in a sequence may not be delivered.
• AtLeastOnce Every message sent will be delivered or an error will be raised on at least one endpoint. Some messages may be delivered more than once.
• ExactlyOnce Every message sent will be delivered without duplication or an error will be raised on at least one endpoint. This delivery assurance is the logical "and" of the two prior delivery assurances.
• InOrder Messages will be delivered in the order that they were sent. This delivery assurance may be combined with any of the above delivery assurances. It requires that the sequence observed by the ultimate receiver be non-decreasing. It says nothing about duplications or omissions.