Contents
- Reliable Messaging Requirements
- ebXML Message Service Specification (ebMS)
- HTTPLR
- WS-Reliability from the OASIS WSRM TC
- WS-ReliableMessaging from the OASIS WS-RX TC
- Reliable Asynchronous Messaging Profile (WS-RAMP)
- Reliable HTTP (HTTPR)
- Web Service Acknowledgement Protocol (WS-Acknowledgement)
- Web Services Reliability Specification (WS-Reliability)
- Web Services Reliable Messaging Protocol (WS-ReliableMessaging)
- W3C Web Services Architecture Working Group
- WS-I Reliable Secure Profile
- General: Articles, Papers, News
Reliable Messaging Requirements
The paper of Prasad Yendluri "Web Services Reliable Messaging", emphasizing that reliable messaging is not unique to web services, summarizes the 'Requirements for Reliable Messaging' as follows:
"In the most basic level, reliable messaging refers to the ability of a sender to deliver a message once and only once to its intended receiver. However the key requirements of reliable messaging can be captured more formally as follows:
- Support carrying message traffic reliably in support of business processes whose lifetimes commonly exceed the up times of the components on which these processes are realized
- Support quality-of-service assertions such as:
- Each message sent be received exactly once (once and only once), at most once, at least once, and so on
- Messages be received in the same order in which they were sent
- Failure to deliver a message be made known to both the sender and receiver
- Accommodate mobility of a reliable business process to different channels or physical machines
- Support message transfer via intermediaries
- Leverage the SOAP extensibility mechanism to achieve reliable messaging
- Enable reliable messaging bindings to a variety of underlying reliable and unreliable transport protocols together with the Message Routing Protocol
- Compose with other protocols to support security and other message delivery services
ebXML Message Service Specification (ebMS)
The ebXML Message Service (ebMS) specification "defines the message enveloping and header document schema used to transfer ebXML messages over a communications protocol such as HTTP or SMTP and the behavior of software sending and receiving ebXML messages. The ebMS is defined as a set of layered extensions to the base Simple Object Access Protocol and SOAP Messages with Attachments specifications."
ebMS Version 2.0 does not provide a complete solution to the broad set of industry requirements for reliable messaging. However, convergence with WS-Reliability and related specifications is likely. It is expected that the work of the OASIS Web Services Reliable Messaging TC will be incorporated into ebMS Version 3.0; see the Fujitsu Statement on WS-Reliability and ebMS and the similar statement from Sun Microsystems.
According to the text of the ebMS Version 2.0 rev C 2 draft, ebMS also "provides security and reliability features necessary to support international electronic business; these security and reliability features are not provided in the SOAP or SOAP with Attachments specifications." Section 6 of the ebMS 2.0 specification describes the Reliable Messaging Module:
"Reliability requirements defined in the ebREQ [ebXML Requirements Specification] relate to delivery of ebXML messages over the communications channels. The ebMS provides mechanisms to satisfy the ebREQ requirements. The reliable messaging elements of the ebMS supply reliability to the communications layer; they are not intended as business-level acknowledgments to the applications supported by the ebMS. This is an important distinction. Business processes often anticipate responses to messages they generate. The responses may take the form of a simple acknowledgment of message receipt by the application receiving the message or a companion message reflecting action on the original message. Those messages are outside of the MSH scope. The acknowledgment defined in this specification does not indicate the payload of the ebXML message was syntactically correct. It does not acknowledge the accuracy of the payload information. It does not indicate business acceptance of the information or agreement with the content of the payload. The ebMS is designed to provide the sender with the confidence the receiving MSH has received the message securely and intact.
Reliable Messaging Module: Reliable Messaging defines an interoperable protocol such that two Message Service Handlers (MSH) can reliably exchange messages, using acknowledgment, retry and duplicate detection and elimination mechanisms, resulting in the To Party receiving the message Once-And-Only-Once. The protocol is flexible, allowing for both store-and-forward and end-to-end reliable messaging.
Reliability is achieved by a Receiving MSH responding to a message with an Acknowledgment Message. An Acknowledgment Message is any ebXML message containing an Acknowledgment element. Failure to receive an Acknowledgment Message by a Sending MSH MAY trigger successive retries until such time as an Acknowledgment Message is received or the predetermined number of retries has been exceeded at which time the From Party MUST be notified of the probable delivery failure. Whenever an identical message may be received more than once, some method of duplicate detection and elimination is indicated, usually through the mechanism of a persistent store.
Methods of Implementing Reliable Messaging: Support for Reliable Messaging is implemented in one of the following ways: (1) using the ebXML Reliable Messaging protocol; (2) using ebXML SOAP structures together with commercial software products that are designed to provide; (3) reliable delivery of messages using alternative protocols; (4) user application support for some features, especially duplicate elimination, or (5) some mixture of the above options on a per-feature basis...
The underlying architecture of the MSH assumes messages are exchanged between two ebMS-compliant MSH nodes. This pair of MSH nodes provides a hop-to-hop model extended as required to support a multi-hop environment. The multi-hop environment allows the next destination of the message to be an intermediary MSH other than the 'receiving MSH' identified by the original sending MSH. The ebMS architecture assumes the sender of the message MAY be unaware of the specific path used to deliver a message. However, it MUST be assumed the original sender has knowledge of the final recipient of the message and the first of one or more intermediary hops.
The MSH supports the concept of 'quality of service.' The degree of service quality is controlled by an agreement existing between the parties directly involved in the message exchange. In practice, multiple agreements may be required between the two parties. The agreements might be tailored to the particular needs of the business exchanges. For instance, business partners may have a contract defining the message exchanges related to buying products from a domestic facility and another defining the message exchanges for buying from an overseas facility. Alternatively, the partners might agree to follow the agreements developed by their trade association. Multiple agreements may also exist between the various parties handling the message from the original sender to the final recipient.
References:
- ebXML Message Service Specification. Version 2.0 rev C 2. From the OASIS ebXML Messaging Services Technical Committee. 21-February-2002. 71 pages.
- OASIS ebXML Messaging Services TC website
- TC discussion list archives for 'ebxml-msg'
HTTPLR
HTTPLR is documented in a draft from Bill de hÓra (Propylon) in preparation for submission as an IETF Internet Draft. HTTPLR revision 01 is "an application protocol for reliable transmission of messages using HTTP. The protocol provides a measure of reliability within the client server model of HTTP without recourse to a peer to peer model, where both communicators are HTTP servers... The document describes an application protocol for guaranteed once and only once transmission of messages using HTTP, something that HTTP alone does not guarantee. It describes a means for both downloading and uploading of messages. It is not concerned with endpoint availability, robustness of components, or details of persistent storage. It is not concerned with message order. A characteristic of distributed systems is that senders and receivers of messages can't know with certainty what went wrong in the event of failure, and without catering for agreement, they might not know if anything did go wrong with a transmission. Our primary concern for failure is dealing with partial failure. Partial failure is where one component in the system fails while the others continue to function. The HTTP client-server model has three failing parts, the Client, the Network, and the Server. For example, if the Network fails mid-transmission, a request might be arrive to the Server but not a response to the Client. Or if the Server's firewall rules are mis-configured, Client requests might be rejected out of hand. The techniques described here provides a measure of reliability within the client server model of HTTP. Reliable variants of HTTP or protocols layered upon HTTP often require a peer to peer model, where both communicators are HTTP servers. The first published description of a reliable protocol using a HTTP client and server is attributed to Paul Prescod [in 'Reliable Delivery in HTTP']. That document 'Reliable delivery in HTTP', along with the author's experiences implementing messaging systems with HTTP and anecdotal descriptions of ad-hoc applications created to handle reliability for HTTP were the basis for this protocol..."
References:
- HTTPLR. By Bill de hÓra (Propylon Ltd., Dublin, Ireland), WWW. Reference: draft-httplr-01.txt. February 2005. [cache]
- " HTTPLR draft-01 published. Some background. Some futures." Blog entry. March 14, 2005.
- "Reliable Delivery in HTTP." By Paul Prescod. Revised October 08, 2002 or later.
WS-Reliability from the OASIS WSRM Technical Committee
"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. Specification: WS-Reliability v1.1.
"OASIS WSRM TC Releases Web Services Reliable Messaging (WS-Reliability) Version 1.1." News story 2004-09-10. The OASIS Web Services Reliable Messaging TC has published a milestone version of its "WS-Reliability" specification, including a prose document and four supporting XML schemas. WS-Reliability defines a SOAP-based protocol for exchanging SOAP messages with guaranteed delivery, no duplicates, and guaranteed message ordering. WS-Reliability is defined as SOAP header extensions and is independent of the underlying protocol. A binding to HTTP is provided. On August 24, 2004 members of the OASIS Web Services Reliable Messaging TC voted: (1) to approve WSRM Spec Draft Version 1.086 as a Committee Draft, and (2) to submit this Committee Draft to OASIS administration for an OASIS member vote.
"Reliable Messaging: Recent Versions of WS-Reliability and WS-ReliableMessaging." News story 2004-03-11. Summary: The WS-Reliability version 0.992 of March 10, 2004 includes a prose specification is accompanied by two XML Schemas. It addresses a recognized problem, viz., that "SOAP 1.2 over HTTP is not sufficient when an application-level messaging protocol must also address reliability and security. The specification is intended as an initial proposal for defining reliability in the context of current Web Services standards. It borrows from previous work in messaging and transport protocols, e.g., SOAP and the OASIS ebXML Message Service Specification Version 2.0. The 0.992 WS-Reliability working draft is being balloted for approval as an OASIS Technical Committee Draft. Royalty-free software which implements Web Services Reliability has been made available by Fujitsu, Hitachi, and NEC.
[February 13, 2003] "OASIS Members Form Technical Committee for Web Services Reliable Messaging." OASIS has announced a new Web Services Reliable Messaging TC, formed with the goal of creating a generic and open model for ensuring reliable message delivery for Web services. "Reliable message delivery" in this context means the ability to guarantee message delivery to software applications, whether Web services or Web service client applications, with a chosen level of quality of service (QoS). The TC will address the following aspects of message delivery: "message persistence, message acknowledgement and resending, elimination of duplicate messages, ordered delivery of messages, and delivery status awareness for sender and receiver applications. 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. The TC hopes to establish: (1) a standard and interoperable way of achieving a known, acceptable, and defined level of reliability at the SOAP messaging level, and (2) a common vocabulary for describing reliable message exchange patterns. Key deliverables include a reliability requirements document (use cases for WS-RM in EAI, B2B, and wireless scenarios) and a WS-Reliability specification, including description of WS-Reliability bindings to transport protocol(s)." Technical specifications approved by the TC will be issued under royalty-free terms. [Full Story]
Announcement 2003-02-13: "CFP: OASIS Web Services Reliable Messaging Technical Committee"
"Fujitsu, Hitachi, NEC and Oracle Showcase Reliable Web Services. OASIS Members Demonstrate Successful Interoperability of Reliable Messaging for Web Services at Technical Committee Meeting." Announcement 2003-09-04. Fujitsu Limited, Hitachi, Ltd., NEC Corp. and Oracle Corp. today announced that they have successfully demonstrated interoperability between four independent implementations of reliable Web services based on the Web Services-Reliability (WS-Reliability) specification, which the companies jointly submitted to the Organization for the Advancement of Structured Information Standards (OASIS) in January. The WS-Reliability specification defines an open reliable messaging infrastructure that enables companies to conduct reliable business-to-business trading or collaboration using Web services. This demonstration is the first deliverable of an ongoing Proof-of-Concept activity for the Web Services-Reliability specification. The OASIS Web Services Reliable Messaging (WS-RM) Technical Committee members plan to update their implementations to accommodate the upcoming release of the next version of the specification, already under development by the committee. The demonstration highlights two functions of the WS-Reliability specification. The first one is 'Guaranteed Delivery' in which the sender will automatically resend the same message if no positive acknowledgement was received, and the other is 'Duplicate Elimination' in which the receiving application eliminates duplicates of the same message. These two functions greatly improve the reliability and efficiency of business applications, by preventing message loss and duplication. This will allow, for example, buyers to ensure that Purchase Order messages are successfully delivered to their suppliers, and prevent suppliers from receiving duplicate orders due to network routing problems. In addition to guaranteed delivery and duplicate elimination, the OASIS WS-Reliability specification also addresses message delivery management, including message persistence, ordered delivery, and delivery status notifications for sending and receiving applications..."
OASIS WSRM [aka 'WS-RM'] TC References:
- OASIS Web Services Reliable Messaging TC (WS-RM TC) website
- TC Charter. Note: Some confusion resulted from the use of the acronym 'WS-RM' in the official OASIS TC name, specified in the original charter ["The name of this Technical Committee is the Web Services Reliable Messaging (WS-RM) Technical Committee (TC)"] and the use of this acronym 'WS-RM' in reference to the WS-* (WS-ReliableMessaging) specification, on which, see Web Services Reliable Messaging Protocol (WS-ReliableMessaging)
- WS-Reliability FAQ document
- Archives for TC discussion list. Use the subscription manager.
- Archives for public list 'wsrm-comment'. Send messages to wsrm-comment@lists.oasis-open.org.
- TC document register
- WS-Reliability v1.1. OASIS Standard. November 15, 2004.
- Errata for OASIS Standard WS-Reliability 1.1
- Working List of Potential Enhancements for Future Versions of WS-Reliability Specification. Edited by Tom Rutt. April 28, 2005. Note: this document may be versioned; see the TC's document register for a possible update.
- "OASIS Members Advance Reliable Message Delivery for Web Services. WS-Reliability Specification Submitted to OASIS." Announcement 2003-02-26.
WS-ReliableMessaging from the OASIS WS-RX TC
The OASIS Web Services Reliable Exchange (WS-RX) Technical Committee (TC) was chartered in May 2005 to define a protocol for reliable message exchanges between two Web services, through continued development of the Web Services Reliable Messaging specification originally published by BEA, IBM, Microsoft, and TIBCO Software.
On June 21, 2007, OASIS announced that its members had approved Web Services Reliable Messaging (WS-ReliableMessaging) Version 1.1 as an OASIS Standard. See the specification listing.
[Update 2007-05] "WS-ReliableMessaging Version 1.1 Submitted for Ballot as an OASIS Standard." OASIS announced that members of the Web Services Reliable Exchange (WS-RX) Technical Committee approved WS-ReliableMessaging Version 1.1 as a Committee Specification and submitted it for consideration as an OASIS Standard. The specification has gone through two Public Review periods, and was balloted May 16-31, 2007. WS-ReliableMessaging Version 1.1 is now a three-part specification, each with a prose document, separate XML namespace, and XML schema: Core Web Services ReliableMessaging 1.1, Web Services ReliableMessaging Policy 1.1, and Web Services MakeConnection 1.0. "The core WS-ReliableMessaging 1.1 document defines a protocol for reliable message exchange between two Web services, even in the presence of network or system failures. For example, the protocol can ensure the resending of messages that have been lost, and can ensure that duplicate messages are not delivered. 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. The protocol fundamentally defines a one-way reliable channel (known as a Sequence), but also includes mechanisms to optimize the creation of two-way reliable exchanges. The protocol is designed to compose with other relevant standards such as WS-Security and WS-SecureConversation. The protocol allows developers to add reliable delivery of messages to their applications on a variety of platforms, including Java and .NET. The WS-ReliableMessaging Policy 1.1 document defines an XML policy language that enables Web services to advertise their support for the WS-ReliableMessaging specification. The specification is designed for use with the WS-Policy Framework. The language aids the interoperability of nodes that support WS-ReliableMessaging by publishing their support and requirements for aspects of reliable messaging. For example, an endpoint may use this specification to indicate that it requires that the reliable message protocol to be secured using transport level security. WS-ReliableMessaging Policy is designed to be used with other policy languages, such as WS-Security Policy, in the scope of the WS-Policy Framework. The WS-MakeConnection 1.0 document defines a protocol that can be used to allow two-way communications when only a transport specific back-channel (such as the HTTP response mechanism) is available. For example, this allows a client to establish a two-way reliable message exchange even in the presence of firewalls and network address translation, that otherwise would prevent the server from initiating connections to the client."
[Update 2006-09] On August 24, 2006, OASIS announced that its Web Services Reliable Exchange (WS-RX) TC had approved the following specification set as a Committee Draft and voted to submit the package for public review: (1) Web Services Reliable Messaging (WS-ReliableMessaging) v1.1, (2) Web Services ReliableMessaging Policy Assertion (WS-RM Policy) v1.1. WS-ReliableMessaging describes a protocol that allows messages to be transferred reliably between nodes implementing this protocol in the presence of software component, system, or network failures. The protocol is described in the specification in a transport-independent manner, allowing it to be implemented using different network technologies. To support interoperable Web services, a SOAP binding is defined. The WS-RM Policy specification describes a domain-specific policy assertion for WS-ReliableMessaging (WSRM) that that can be specified within a policy alternative as defined in WS-Policy Framework. The public review began on 24 August 2006 and ends 21 October 2006. Members of the TC encourage feedback from potential users, developers and others.
On April 19, 2005, BEA Systems Inc., IBM Corp., Microsoft Corp., and TIBCO Software Inc. announced a proposed OASIS technical committee and TC Charter to enable further review and industry collaboration on the Web Services ReliableMessaging (WS-RM) specification, including both protocol and policy assertions. See details in the news story "OASIS TC to Finalize WS-ReliableMessaging and WS-RM Policy Assertion Specifications."
A Call for Participation in the new OASIS Web Services Reliable Exchange (WS-RX) Technical Committee was issued on May 03, 2005. The TC operates in the "RF on RAND Terms" IPR mode as defined in the OASIS IPR Policy dated April 15, 2005. The WS-RX TC Charter was supported by some forty-one (41) individuals, identified as 'Proposers' of the TC, including the companies 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.
From the WS-RX TC Charter and Call for participation:
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 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
WS-ReliableMessaging Version 1.1 (OASIS Standard):
Web Services Reliable Messaging (WS-ReliableMessaging) Version 1.1. OASIS Standard. 14-June-2007. Namespace URI. See also the PDF and DOC, with XML Schema and WSDL.
Web Services Reliable Messaging Policy Assertion (WS-RM Policy) Version 1.1. OASIS Standard. 14-June-2007. Namespace URI. See also the PDF and DOC, with XML Schema.
Web Services Make Connection (WS-MakeConnection). Version 1.0. OASIS Standard. 14-June-2007. Namespace URI. See also PDF and DOC, with XML Schema WSDL.
TC References:
- Public Review of WS-Reliable Messaging and WS-Reliable Messaging Policy Assertion v1.1. Announcement August 24, 2006.
- "Call for Participation in the OASIS Web Services Reliable Exchange (WS-RX) TC." News story 2005-05-04.
- Announcement 2005-05-03: Call for Participation: OASIS Web Services Reliable Exchange (WS-RX) Technical Committee.
- "OASIS TC to Finalize WS-ReliableMessaging and WS-RM Policy Assertion Specifications." News story 2005-04-19.
- OASIS press release 2005-05-10: "Members Agree to Advance Reliable Messaging Specification Within OASIS."
- WS-RX TC web site
- WS-RX TC Charter
- OASIS Library document archive
- Kavi document repository
- TC Issues list archive
- TC discussion list archive
- TC comment list archive
- Archive for 'ws-reliablemessaging-dev' list. Subscribe via email; post to ws-reliablemessaging-dev@lists.oasis-open.org
- WS-RX TC Press
Reliable Asynchronous Messaging Profile (WS-RAMP)
"The Reliable Asynchronous Messaging Profile (RAMP) 1.0 is a profile, in the fashion of the WS-I profiles, that enables, among other things, basic B2B integration scenarios using Web services technologies.
The effective use of standards continues to be a proven method of addressing business challenges in a consistent manner. Aggregating standards usage through Profiles provides a method of guidance for the consistency in their application. WS-I has limited the scope of their profiles to adopted industry standards. However, businesses need to solve challenges which can only be addressed through emerging standards. The RAMP Profile represents the first successful effort to combine emerging Web services standards with vertical industry standards, semantics, and expertise to develop a prescriptive roadmap to implement systems common to all players in an industry. This fills an extremely important marketplace void in providing a method to implement a collection of standards that address areas including reliable messaging, security, and ecommerce, versus simply making the standards available..." [spec overview]
According to a 2005-08-26 paper by Christopher Ferris: "The Reliable Asynchronous Messaging Profile (RAMP) 1.0 is a profile, in the fashion of the WS-I profiles, that enables, among other things, basic B2B integration scenarios using Web services technologies. This profile is the second public draft of what was formerly labeled the IBM Basic B2B Profile. The motivation for renaming the profile was based on feedback from analysts, our customers, and partners stating that the profile had relevance beyond business-to-business scenarios and that the name should be changed to reflect this fact...
The RAMP 1.0 profile, published on August 4, 2005, represents the second public draft of what had previously been labeled the RAMP profile. We fully expect that as we continue to work with our clients to develop usage patterns for the profile, as we receive feedback from the
Ultimately, we hope that the RAMP 1.0 profile and the usage patterns which are developed to supplement it are taken up by WS-I, revised as needed, and published in Final form by WS-I. We are eager to see others working on the adoption of Web services use this work as the basis for their own (we are eager to see the Open Applications Group (OAGi), the Automotive Industry Action Group (AIAG), and other industry sector organizations referencing the profile and usage scenarios in their work the same way organizations such as HR-XML have begun referencing the WS-I Basic Profile). Finally we hope this effort will contribute to Web services becoming a useful integration technology, and to that end, we encourage all parties to contribute to this work, and adopt it, and use it in your products and solutions..."
References:
- Reliable Asynchronous Messaging Profile (WS-RAMP). Version 1.0. Working Draft: 2005-08-25. By Chris Ferris (Editor IBM), and Tim Fowler (Ford Motor Company). Latest version URL. [source PDF]
- "Introducing the RAMP Profile. The profile formerly known as the IBM Basic B2B Profile." By Christopher Ferris (Senior Technical Staff Member, IBM). IBM developerWorks. August 26, 2005.
- Reliable Asynchronous Messaging Profile 1.0. Reference page with overview.
- Reliable Asynchronous Message Profile (RAMP) Toolkit. IBM alphaWorks.
Reliable HTTP (HTTPR)
In June 2001, a research team from IBM published a Reliable HTTP (HTTPR) specification for a new protocol supporting reliable delivery of HTTP packets between the server and client. HTTPR is an extension of HTTP that supports reliable message exchange.
[April 01, 2002] "HTTPR Specification." Edited by Francis Parr. April 01, 2002. [Version 1.1: 2001-12-03.] 44 pages (PDF). Contributing authors: Andrew Banks (IBM Software Group), Jim Challenger (IBM Software Group), Paul Clarke (IBM Software Group), Doug Davis, Richard P King, Karen Witting, Andrew Donoho, Time Holloway, John Ibbotson, and Stephen Todd. "HTTPR is a protocol for the reliable transport of messages from one application program to another over the Internet, even in the presence of failures either of the network or the agents on either end. It is layered on top of HTTP. Specifically, HTTPR defines how metadata and application messages are encapsulated within the payload of HTTP requests and responses. HTTPR also provides protocol rules which make it possible to ensure that each message is delivered to its destination application exactly once or is reliably reported as undelivered." [PDF, cache]
Commentary on HTTPR:
- IBM hosts a public discussion forum on HTTPR.
- Comments on HTTPR were posted to the W3C Web Services discussion forum 'www-ws' during July 2001. See the posting of John D. Beatty, Richard P. King, and others contributing to this thread.
[April 2002] "A Primer for HTTPR." By Stephen Todd (IBM Research, Hursley), Francis Parr (IBM MQSeries, Hawthorne), and Michael H. Conner (IBM Internet Software, Austin). From IBM developerWorks, Web services. April 2002. Originally published July 2001. ['Reliable HTTP (HTTPR) is a new protocol that offers the reliable delivery of HTTP packets between the server and client. This solves a number of issues that are evident in current HTTP and opens the way to reliable messaging between Web services.'] "The delivery of messages using a reliable transport mechanism is a fundamental component for middleware in e-business systems, and a needed technology in enterprise computing. However, in the wider context of the Internet, synchronous transport protocols such as HTTP do not currently provide those facilities. Reliable HTTP (HTTPR) addresses these deficiencies by proposing rules that make it possible to ensure that all messages are delivered to their destination in their exact form and only once. In cases where the message delivery fails, the protocol will reliably report the message as undeliverable. Messaging agents can use HTTPR together with persistent storage capability to provide reliable messaging for applications. The specification of HTTPR does not include the design of a messaging agent, nor does it say what storage mechanisms should be used by a messaging agent; it does specify the state information needs to be in to be stored safely and when to store it so that a messaging agent can provide reliable delivery using HTTPR. HTTP version 1.1 serves as the base upon which HTTPR builds its reliability. As such, all of the facilities of HTTP/1.1 (SSL, keep-alive, communication through proxies and firewalls, and so on) are available. IBM is making the HTTPR specification specification available to the public to stimulate public discussion on reliable message delivery on the Internet... Reliable message support is not a new technology. Messaging middleware products such as the IBM MQSeries, Oracle Message Broker, and Microsoft Message Queuing have supported it for years and are widely deployed in enterprise computing environments. However, reliable messaging is currently supported via product specific protocols. This article proposes how reliable messaging can be brought to communication over an open, standardized, and product neutral protocol..." [PDF, cache]
[February 14, 2003] "Business Process Integration with IBM CrossWorlds. Part 3: Automatically Externalize Web Services with WebSphere Business Connection." By Rob Cutlip (Software and Solutions Architect, IBM). From IBM developerWorks, IBM developer solutions. January 2003. ['In this third and final installment in the series, Rob Cutlip describes how to enable Web services for the IBM CrossWorlds environment by using WebSphere Business Connection offerings, which allow business-to-business process integration and data sharing among trading partners. This article extends the Web services architecture described in Part 2 of the series, which in turn built upon the IBM CrossWorlds Business process integration infrastructure presented in Part 1. WebSphere Business Connection offerings provide scalable, B2B gateway function, and they exploit cutting-edge technologies, including WSIF, AXIS, and HTTPR; they support "reliable messaging" over the Internet, which is the delivery of messages in their exact form to a destination, once and only once. Messaging agents, persistent storage, and HTTPR are provided to support reliable messaging.'] "WebSphere Business Connection offerings let an organization execute complex business process flows and connect to trading partners using a variety of standard protocols, including RosettaNet, EDI, EDI-INT (AS1/AS2), and ebXML, as well as Web services. Companies can start with the simple, low-cost Web services connection capabilities provided by the entry level Business Connection Express, and scale to support additional partners and more complex business processes using the WebSphere Business Connection standard and enterprise editions. Beyond the Web services gateway functions provided by all of the WebSphere Business Connection offerings, there are many mission-critical functions, including trading partner management and "large file transfer" document exchange with guaranteed delivery using HTTPR. HTTPR is an extension of HTTP that supports reliable message exchange. The WebSphere Business Connection offerings are part of a larger set of business process integration offerings that comprise the WebSphere Business Integration (WBI) family..."
FAQ for IBM Web Services Toolkit: "Reliable HTTP (HTTPR) is a protocol that offers the reliable delivery of HTTP packets between the server and client. This solves a number of reliability issues in current HTTP and opens the way to reliable messaging between Web services. The HTTPR demo and the SOAP over MQ Series demo that was shipped in previous versions of the WSTK are now available in an IBM MQ Series SupportPac MA0R. The MQ Series SupportPac MA0R also exposes a compatible JMS messaging interface for applications to interact with this choice of reliable internet transport mechanisms. HTTPR is a protocol for the reliable transport of messages from one application program to another over the Internet, even in the presence of failures either of the network or the agents on either end..."
[November 2001] "The Web Services Insider. Part 10: Digging Into the Issues. Reliability and Transactions." By James Snell (Software Engineer, IBM Software Group). From IBM developerWorks, Web services. November 2001. ['The Web services architecture is, at its core, a way for applications to integrate with one another through the intelligent interchange of messages. For the enterprise, this means the exchange of critical business information such as purchase orders, contracts, and requests for quotes (RFQs). Because of the critical nature of this information, businesses must be assured of the reliability of the underlying messaging architecture. In this installment of the Web services insider, James Snell continues his discussion of issues affecting the use of Web services in the enterprise by focusing on reliable messaging and transactions.'] "The simple definition of 'reliable messaging' is making sure that both the sender and recipient of a message both know whether or not a message was actually sent and received, and furthermore making sure that the message was sent once and only once to the intended recipient. Straightforward? Yes. Easy to implement? No. Reliable messaging is a problem that has plagued Internet application development since its inception. The Internet is, by its very nature, unreliable. Servers that are up and running one moment may be down the next. The protocols used to connect senders and receivers were not designed to support reliable messaging constructs, such as message identifiers and acknowledgements. Recipients of messages must be able to acknowledge the fact that they actually did in fact receive the message. Senders of messages must be able to cache those messages in the event that an acknowledgement is not received and the message needs to be sent again. The fundamental technology that drives the Internet of today does not support such mechanisms. And therefore, developers are forced to implement new protocols, new technologies that address these needs... HTTPR augments HTTP in that it adds the necessary elements to remove, or at least reduce the level of doubt that arises when a failure of any sort occurs in the request/response process... Layering reliable messaging on top of HTTP allows companies with existing investments in Web server technology to take advantage of reliable messaging capabilities, while still leveraging their existing investments. As an extension to HTTP, HTTPR is also capable of making use of HTTP's facilities for security, sessions, proxies, and firewall support, etc... To begin experimenting with reliable messaging in Web services, I recommend that you download the latest version of the Web Services ToolKit (version 2.4) from IBM's alphaWorks site. Included in the samples is a demonstration of the HTTPR protocol..." Also in PDF format.
Press:
- [August 14, 2001] "IBM Ups HTTP Ante." By Mark Jones. InfoWorld. August 14, 2001. "IBM is aiming to send its new Internet transfer protocol HTTPR (Reliable HTTP) standard to the Internet Engineering Task Force (IETF) for certification, an IBM executive revealed today..."
- [August 02, 2001] "Reliable HTTP Messaging Spec from IBM." By Edd Dumbill. From XMLhack.com. August 02, 2001.
- [July 26, 2001] "IBM Unveils Reliable HTTP." By Carolyn Duffy Marsan. Network World Fusion. July 26, 2001.
Web Service Acknowledgement Protocol (WS-Acknowledgement)
In February 2003, BEA Systems released a version 0.9 specification for WS-Acknowledgement, "designed to support Reliable message exchange between services by providing for at-least-once and exactly-once SOAP message transfer guarantees."
From the Introduction:
"The WS-Acknowledgement protocol is designed to enable WS-Acknowledgement senders to request explicit acknowledgement from WS-Acknowledgement receivers that a WS-Acknowledgement Request MessageWS-Acknowledgement Request Message has been received. An Acknowledgement message only acknowledges the receipt of the WS-Acknowledgement Request MessageWS-Acknowledgement Request Message. No guarantee is made that the WS-Acknowledgement Request MessageWS-Acknowledgement Request Message has been or will ever be processed.
If the WS-Acknowledgement sender does not receive an acknowledgement within the pre-arranged retry interval then the WS-Acknowledgement sender will repeat the WS-Acknowledgement Request Message. The WS-Acknowledgement sender will continue to repeat the WS-Acknowledgement Request Message until the WS-Acknowledgement sender has retried the pre-arranged maximum number of times or until it receives an acknowledgement message.
As part of the configuration of a reliable messaging exchange between two parties it is possible to ask for duplicate elimination. In that case the WS-Acknowledgement receiver is required to keep a persistent record of what Message IDs have been received for a pre-arranged period of time. If the WS-Acknowledgement receiver should receive a message whose Message ID matches that of one already in the persistent store then the WS-Acknowledgement receiver will repeat the previous transmitted Acknowledgement message. It will then discard the repeated message..."
References:
- WS-Acknowledgement version 0.91. February 26 2003. [cache]
- "BEA Releases Web Services Specifications Supporting Asynchrony, Reliable Messaging, Metadata." News story 2003-03-17.
Web Services Reliability Specification (WS-Reliability)
See now OASIS Web Services Reliable Messaging Technical Committee (WSRM). WS-Reliability v1.1 was approved as an OASIS Standard. See the OASIS TC Administration announcement of November 15, 2004 and the OASIS press release.
[January 09, 2003] Web Services Vendors Publish Royalty-Free WS-Reliability Specification. Six leading vendors have contributed to the working draft of a Web Services Reliability (WS-Reliability) specification designed to support reliable Web services messaging. WS-Reliability is a "specification for open, reliable Web services messaging including guaranteed delivery, duplicate message elimination and message ordering, enabling reliable communication between Web services. The reliability features are based on extensions to the Simple Object Access Protocol (SOAP), rather than being tied to the underlying transport protocol. The specification will allow a variety of systems to interoperate reliably in a platform- and vendor-neutral manner. Following collaboration on the specification draft, the companies plan to submit WS-Reliability to a standards body on a royalty-free basis. Reliable message delivery means the ability to ensure delivery of a message with the desired level of quality of service. Some examples of this quality of service level for message delivery are: (1) Message sent at least once -- guaranteed delivery; (2) Message sent at most once -- guaranteed duplicate elimination; (3) Message sent exactly once -- guaranteed delivery and duplicate elimination." The specification has been produced by Fujitsu Limited, Hitachi, Ltd., NEC Corporation, Oracle Corporation, Sonic Software Corporation, and Sun Microsystems, Inc. [Full Story.
[January 09, 2003] "Web Services Reliability (WS-Reliability)." From Fujitsu Limited, Hitachi, Ltd., NEC Corporation, Oracle Corporation, Sonic Software Corporation, and Sun Microsystems, Inc. Version 1.0. January 8, 2003. 45 pages. "Web Services Reliability (WS-Reliability) is a SOAP-based protocol for exchanging SOAP messages with guaranteed delivery, no duplicate s, and guaranteed message ordering. WS-Reliability is defined as SOAP header extensions, and is independent of the underlying protocol. This specification contains a binding to HTTP. This model enables a sender (i.e., a SOAP node with reliable messaging functions for sending) to send a message to a receiver (i.e., a SOAP node with reliable messaging functions for receiving) that can accept an incoming connection. Functions to accommodate a receiver that cannot accept an incoming connection (e.g., because of a firewall) are intended for further study, and are not included in this version of the specification... The purpose of WS-Reliability is to address reliable messaging requirements, which become critical, for example, when using Web Services in B2B applications. SOAP over HTTP is not sufficient when an application-level messaging protocol must also address reliability and security. While security is getting traction in the development of Web Services standards, reliability is not. This specification is intended as an initial proposal for defining reliability in the context of current Web Services standards. The specification borrows from previous work in messaging and transport protocols, e.g. SOAP, and the ebXML Message Service [ebXML Message Service Specification Version 2.0]. It proposes appropriate modifications to apply this work to Web Services... The goal of this specification is to define: (1) A mechanism to guarantee message delivery and its e xpression in SOAP messages; (2) A mechanism to eliminate duplicate messages and its expression in SOAP messages; (3) A mechanism to guarantee received message order (within a context) and its expression in SOAP messages..." [source]
[January 09, 2003] WS-Reliability XML Schema
[February 15, 2003] "SOAP Extension Soup." By Roger Jennings. In XML & Web Services Magazine (January 31, 2003). ['The race to establish new WS-Whatever standards and intellectual property issues threaten Web services interoperability.'] "Too many cooks spoil the broth is the aphorism that best describes the current state of proposed Web service extension 'standards.' Rival vendor groups compete for trade press coverage and Web service developer mind share. IBM, Microsoft, and their allies hold the high ground with thirteen (13) published specifications, while Sun, Oracle, and their contingents wage a guerilla battle with two proposed SOAP-related specs. W3C working groups and OASIS technical committees contend for the preeminent Web service standards body role. The Web Services Interoperability (WS-I) Organization intends to resolve conflicting standards implementations. Unresolved intellectual property (IP) issues pose the threat of multiple standards for related extensions and interoperability breakdown. This article examines current Web service extension proliferation issues from a .NET developer's standpoint... Latecomers to the Web services standards table hope to overcome the IBM-Microsoft SOAP extensions hegemony by publishing specs to fulfill real or imagined Web services needs. As an example, Fujitsu, Hitachi, NEC, Oracle, Sonic Software, and Sun released what appears to me to be a very early and incomplete working draft of their proposed Web Services Reliability (WS-Reliability) standard on January 9, 2003. WS-Reliability -- based on OASIS's ebXML Message Service (ebXMS) standard -- doesn't deal with Quality of Service (QoS) issues, so a more accurate title would be 'WS-Reliable Messaging.' WS-Reliability defines SOAP header extensions for guaranteed delivery, duplicate elimination, and message ordering in a non-routed (endpoint-to-endpoint) environment... Clemens Vasters and Werner Vogels have analyzed the many deficiencies and ambiguities of the WS-Reliability proposal. Gartner's January 13, 2003 note on WS-Reliability deals primarily with the politics of current Web services extension proposals. IBM's Bob Sutor damned WS-Reliability with faint praise in a statement to InternetNews.com: 'We hope that the WS-Reliability spec represents an attempt to further converge ebXML into the increasingly dominant industry web services effort.' My conclusion is that WS-Reliability's authors, especially Sun and Oracle, opted for press coverage of a premature 'standard' to combat the December 19, 2002 barrage from Microsoft and IBM. Perhaps, as Werner Vogels suggests, IBM and Microsoft can get together and integrate reliable messaging features within a variation on the current WS-Routing theme. Microsoft's disdain for ebXML and IBM's for WS-Routing are likely to be the primary impediments to a joint WS-Routing/Reliability proposal. In the meantime, WS-Routing remains a .NET-only technology. Microsoft's initial WS-Routing/WS-Referral implementation in the Web Services Enhancement (WSE) 1.0 update to the Web Services Development Kit (WSDK) might deliver the incentive for a cooperative standards effort..."
[January 14, 2003] "New Specification Just a Start for Reliable Web Services Messaging." By David Smith, Roy Schulte, and Massimo Pezzini (Gartner Research). Gartner FirstTake. January 14, 2003. 2 pages (PDF). ['The Web Services Reliability specification aims to make message delivery reliable in Web services. The incomplete specification as yet lacks support from heavyweights IBM and Microsoft.'] "... The WS-Reliability specification is the first publicized break in the area of message interoperability. Its sponsors named it to sound like the emerging "WS" family (such as WS-Security and WS-Transactions, proposed earlier by Microsoft and IBM); however, WS-Reliability is not integrated with these standards. Instead, WS-Reliability stems from work completed by the Organization for the Advancement of Structured Information Standards (OASIS) to develop ebXML, a standard which has obtained some traction and vendor support. WS-Reliability marks the beginning of the potential reuse of pieces of ebXML in Web services. The specification aims to expand ebXML standards to increase the reliability of Web services and spur their wider use. The success of WS-Reliability will depend in part on the reaction of IBM and Microsoft, which have not participated in this effort thus far. Both are crucial to the success of any Web services specification. Gartner believes that IBM and Microsoft also are working on their own Web services messaging specification. The six vendors in this consortium have moved faster than IBM and Microsoft to publicize their work, perhaps hoping to offset some of the standards-dictating power that IBM and Microsoft have enjoyed with other Web services specifications. Vendors and enterprises that have already adopted ebXML will find it natural to endorse WS-Reliability -- thus hindering widespread acceptance of any hypothetical alternative proposal from IBM and Microsoft... As Gartner forecast [2001], Web services standards have begun fragmenting (see 'Does Web Services Need a ".Org" to Succeed?'). The new specification remains incomplete, even with respect to messaging: It describes reliable asynchronous delivery but does not address many other issues such as publish-and-subscribe. WS-Reliability fires only a first small shot in the impending battle for messaging standards..." [PDF source format; cache/mirror removed]
[January 14, 2003] "Reliable SOAP for Web Services Messaging Has Finally Arrived! Leading IT Vendors Join Forces to Create Web Services Reliability Specification." By Dave Chappell. In Web Services Journal (January 14, 2003). "... WS-Reliability is a standalone specification for reliable SOAP that can provide the missing link to bridge the gap between organizations and help make Web services a truly enterprise-capable technology for standards-based systems integration. As one of the WS-Reliability specification authors, I thought I would drop a quick note and give a description of it, and my viewpoint on where it is headed. WS-Reliability is a specification for an open, reliable SOAP-based asynchronous messaging protocol, which enables reliable communication between Web services. WS-Reliability includes well-known characteristics of reliable messaging such as guaranteed delivery, duplicate message elimination, and message ordering. Delivery options such as at-least-once, at-most-once, and exactly-once are available. Message expiration and delivery retries are also possible. I use the term SOAP-based reliability to mean that the reliability capabilities are defined in the SOAP envelope. The spec defines a set of SOAP envelope headers that govern the behavior of the senders and the receivers. This means that even while an HTTP binding is provided, WS-Reliability is a level above, or independent of, the underlying protocol... The guaranteed delivery is accomplished using concepts such as message persistence, acknowledgement of receipt, and error reporting via SOAP Fault handling... It is the responsibility of the receiving Reliable Messaging Processor (RMP) to detect duplicates and only deliver one message to the receiving application, discarding the rest. Now, you may notice I didn't say keep the first and discard all subsequent messages. We left it open for now because who is to say whether the first message is to be kept, or the last one. That's an example of an application specific requirement and something that perhaps could be configurable in an implementation specific RMP.Message Ordering Message ordering is accomplished using a <MessageOrder> element, which contains both a <GroupId> and a <SequenceNumber> element. The receiving RMP is responsible detecting out of sequence messages, and either waiting for them to arrive, or generating a Fault back to the sender... Both the sending and receiving RMPs are required to persist the messages under certain conditions. The sending RMP is required to persist a message until it receives an acknowledgement message, the time span as indicated by the <TimeToLive> element has expired, or a configurable number of retry attempts have failed. The receiving RMP is required to persist a message until a receipt has been delivered back to the sender, and all ordering and duplicate elimination requirements have been satisfied. The intent of WS-Reliability is to provide a simple yet robust specification for reliable messaging that can work well within existing parts of the Web services stack, and be capable of fitting in with other complementary efforts as they progress. We realize that the specification is in its early stages and we still have a great deal of work ahead of us, and look forward to the input from the other companies as they come on board with the effort... WS-Reliability should become a natural fit into any environment that supports JMS, HTTP, SOAP, and Web services..."
[January 13, 2003] "Web Services Reliability Specification Published by Leading IT Vendors." By Dave Chappell (Sonic Software). From The O'Reilly Network (January 13, 2003). "Finally we will have an open standards-based platform-neutral way of doing reliable messaging for Web services. WS-Reliability offers an asynchronous reliable messaging protocol at the SOAP envelope level. This is a very exciting project to be working on. At the moment it is a spec that was initially developed by a group of six companies (Oracle, Sun, Fujitsu, Sonic, Hitachi, NEC). We plan to take it to a standards body very soon and form a working group or technical committee. I can't say which standards body until it actually happens, but we are going through that process right now. We are looking forward to participation from other vendors when that step becomes official. We are already getting contacted by numerous companies who are interested in joining in. Keep your eyes open for upcoming events. WS-Reliability includes well known characteristics of reliable messaging such as guaranteed delivery, duplicate message elimination, and message ordering. Delivery options such as at-least-once, at-most-once, and exactly-once are available. Things like message expiration and delivery retries are also possible. WS-Reliability is a SOAP-based asynchronous reliable messaging protocol. This means that the spec defines a set of SOAP envelope headers that govern the behavior of the senders and the receivers. While an HTTP binding is provided, WS-Reliability is a level above, or independent of, the underlying protocol..."
[January 10, 2003] "WS-Reliability: Adoption May Be Low, but Impact Will Be Great." By Uttam Narsu. From Giga Information Group, Inc. January 10, 2003. 2 pages. Cited at CW360.com. ['Giga Information Group analyst Uttam Narsu looks behind the specification and discusses whether it is viable -- given that neither Microsoft nor IBM have given their support.'] The WS-Reliability working draft specification by Fujitsu, Hitachi, NEC, Oracle, Sonic Software and Sun Microsystems "is best viewed as a table-setter for a final specification yet to come. The reliability of Web Services messaging has been one of the issues preventing more rapid adoption of Web Services... WS-Reliability hopes to settle this issue by providing a decidedly minimalist (and royalty-free) specification that uses Simple Object Access Protocol (SOAP) 1.1's extensibility mechanism to address guaranteed delivery, elimination of duplicates and ordered message delivery. There is no question that WS-Reliability solves a real problem. One strong point in the design is that the specification is at the SOAP protocol level (rather than at the HTTP level like IBM's HTTPR spec), which allows reliability to be guaranteed no matter what the SOAP messages are ultimately being transmitted over. The ordered message delivery uses the concept of a group ID, which could then be used by a higher level spec to more easily create conversations/choreography. Minimalism is good but WS-Reliability might be too minimalist, for example, it's easy to imagine that reliability could be rolled into choreography/conversations, especially if doing so helps manage messaging to quality of service objectives. That's exactly the approach taken by ebXML's ebMS messaging service (from which WS-Reliability heavily borrows), which provides reliability. While anyone can create a spec, getting traction is another issue... The likely effect of the WS-Reliability spec will be to exert strong pressure on whatever final spec gets adopted by a standards body and users to ensure that it will be royalty free... Using the spec will require implementation support [so] a better choice would be to send SOAP over a reliable transport where possible; some vendors who provide support for this are IBM, Sonic, TIBCO and Microsoft..." [cache]
[January 09, 2003] "Sun, Oracle, Fujitsu to Push Web Services Reliability Specification." By Paul Krill. In InfoWorld (January 09, 2003). "Setting the stage for another potential battle over Web services standardization, Sun Microsystems, Fujitsu, and Oracle on Tuesday plan to announce a specification for Web services reliability without participation from rivals IBM and Microsoft. The Web Services Reliability (WS-Reliability) specification is intended to help accelerate adoption of Web services by promoting linking of applications via standard interfaces. WS-Reliability features extensions of SOAP that are intended to provide for guaranteed Web services delivery, eliminate message duplication, and provide for message ordering. 'We believe that this specification removes one of the two major adoption barriers that exist today for Web services, those barriers being a lack of security and the lack of a reliable messaging model,' said Ed Julson, group marketing manager for Java and Web services at Sun, in Santa Clara, Calif. WS-Reliability provides for quality of service for Web services at the application level rather than at the transport level, said Tom Rutt, a Fujitsu consulting engineer based in Asbury Park, N.J. An analyst applauded WS-Reliability but added it may compete with an alternate proposal by IBM, dubbed HTTPR. IBM and Microsoft have not been invited to participate in WS-Reliability development thus far, but will be able to do so when the proposal is submitted to a standards body shortly, according to Julson and Rutt... WS-Reliability will be submitted to a standards body on a royalty-free basis, Rutt said. He and Julson would not say which one but did say it would be one that has been involved in Web services standards development. That would make the World Wide Web Consortium (W3C) and OASIS (Organization for the Advancement of Structured Information Standards) the likely candidates. IBM, Microsoft, and BEA Systems have not been invited to participate in WS-Reliability thus far because of what Julson and Rutt termed differences of philosophies on royalty-free specifications and commitment to open standards. They cited the current IBM-Microsoft-BEA proposal for choreographing interactions between Web services, dubbed Business Process Execution Language for Web Services (BPEL4WS), which has yet to be submitted to a standards body. IBM and BEA have committed to a royalty-free stance on BPEL4WS, however. The BPEL4WS proposal was announced in August 2002, shortly after the unveiling of Sun's own choreography proposal, Web Services Choreography Interface (WSCI), which has been submitted to the W3C... Other participants in the WS-Reliability effort include Hitachi, NEC, and Sonic Software." See details in the 2003-01-09 news item "Web Services Vendors Publish Royalty-Free WS-Reliability Specification."
[January 09, 2003] "Oracle and Sun Lead WS-Reliability Charge, Exclude IBM." By [CBR Staff]. In CBR (January 09, 2003). "Vendors led by Oracle Corp and Sun Microsystems Inc are today expected to announce a draft web services specification for reliable messaging, without input from messaging heavyweight IBM. Oracle and Sun will announce WS-Reliability for guaranteed delivery of messages, ordering of messages, and for the elimination of duplicated messages. WS-Reliability uses a set of extensions written in Simple Object Access Protocol (SOAP). Joining Oracle and Sun are Fujitsu Ltd, Hitachi Ltd, NEC Corp and Sonic Software Corp... Ed Julson, Sun group marketing manager for industry initiatives and standards, said IBM would be invited to join if it supports RF. 'The philosophy of the six companies [involved] leans towards open specifications and IP that is submitted on an RF basis. Both are positions that... IBM has not embraced,' Julson said. IBM was unavailable for comment. An Oracle spokesperson said IBM is welcome to participate in WS-Reliability development, once the specification is submitted to a standards body. Oracle, Sun and others are in talks to decide which standards body WS-Reliability should be submitted to. Jeff Mischkinsky, director of web services standards, said the companies had focussed on reliable messaging with WS-Reliability because this was an area that has been largely overlooked in much of the current web services standards work. 'Security and reliability are the two biggest barriers [to web services use] right now. There's on-going work on security standards, but not on reliability,' Mischkinsky said..." See "Web Services Vendors Publish Royalty-Free WS-Reliability Specification."
Web Services Reliable Messaging Protocol (WS-ReliableMessaging)
Note: In the February 2005 release of WS-RM, the protocol and policy assertion portions were separated, where refactoring yielded a separate Web Services Reliable Messaging Policy Assertion (WS-RM Policy) accompanying Web Services Reliable Messaging Protocol (WS-ReliableMessaging).
References:
- Web Services Reliable Messaging Protocol (WS-ReliableMessaging). February 2005. source PDF
- WS-ReliableMessaging XML Schema. February 2005.
- WS-ReliableMessaging WSDL file. February 2005.
- "Reliable Messaging: Recent Versions of WS-Reliability and WS-ReliableMessaging." News story 2004-03-11.
- "Web Services Reliable Messaging Protocol (WS-ReliableMessaging)."
- WS-ReliableMessaging XML Schema 2003.
- "Reliable Message Delivery in a Web Services World: A Proposed Architecture and Roadmap." A Joint White Paper from IBM Corporation and Microsoft Corporation. Version 1.0. March 13, 2003.
- Web Services Reliable Messaging reference page. From IBM.
- WS-ReliableMessaging Specification Index Page
W3C Web Services Architecture Working Group
As of 2003-02, the W3C Web Services Architecture Working Group was discussing how best to address "reliability" in the web services context. A posting from Mike Champion on "Proposed text on reliability in the web services architecture" generated over a hundred followup messages, available in the mail archive. An earlier posting of December 13, 2002 to 'www-ws-arch' by Roger Cutler summarized a number of threads on Reliable Messaging; similarly from August 2002.
Excerpts from the draft of "Proposed text on reliability in the web services architecture," by Mike Champion, Co-Chair of the W3C Web Services Architecture Working Group:
"I have an action item to update the WSA draft with text 'harvested' from the lengthy threads last month on reliablility in the WSA and what we should say and do about it..."
"The issue of how one ensures that Web services operate reliably in environments (such as the Internet) that do not offer 'industrial strength' quality of service is a mulitfaceted and contentious one. Indeed, it's a densely interconnected clusters of issues: One might address it in the messaging infrastructure to put retry and timeout logic that makes repeated attempts to move SOAP messages from the ultimate origin to their final destination, reporting the status back to the sender; 'Asynchrony' is part of the picture because without a reliable substrate, senders and receivers may communicate 'out of band' to ensure that messages were received; and it's tangled up with Choreography and Transactions because Web service invocations can fail for all sorts of reasons besides messages not being delivered and some sort of recovery protocol may need to be scripted. Finally, there is a school of thought that argues that reliable messaging is not an important feature of the messaging infrastructure if the application-level protocol is well-designed."
"Reliable Messaging Layer: First, what can be done to assure that SOAP messages have been received (possibly after traversing multiple intermediaries) once and only once? [Note: it is important to pay very close attention to the wording of assertions about reliable messaging: there is no way to 'assure' that a message will be recieved, and it appears to be beyond the state of the art in computer science to reliably determine that a message was NOT received, so it is misleading to say that a reliable messaging layer lets the sender determine 'whether' a message was recieved!]. Of course, one possibility is to use proprietary messaging software at the transport layer; examples would include products such as IBM WebSphere MQ and MQ Everywhere, and Microsoft MSMQ, and those from a number of vendors that implement the Java Messaging Service API.
"Another approach, on which this discussion will focus, is taken by the ebXML Messaging Service specification and a number of vendor-specific technologies: use SOAP header extensions to define a protocol that defines ways of handling retries, error notification, removal of duplicates, and notification of errors.
"It is worth noting that the problem of reliable messaging is very successfully addressed on the Internet itself in the TCP protocol, which sits on top of IP to ensure that message components are delivered once and only once in the correct order... But in the case of reliable messaging, it seems that you should be able to use, for example, SOAP over HTTPR on one hop, and SOAP over JMS on the next hop, and still be able to support reliable messaging end-to-end. (The message goes reliably from A to C iff it goes reliably from A to B and from B to C -- for example, B waits until it gets the transport-level ack from C before sending its transport-level ack to A).
"In fact, I think this was the rationale when IBM designed HTTPR, so that you could go from Internet to intranet (and vice versa), using SOAP over HTTPR on the Internet, and then switching to SOAP over MQSeries (or other MOM) once inside the intranet.
"Reliability and Business Transaction Processing: One can consider the reliability of web service interactions from within a richer taxonomy of reliable messaging features. For example, David Burdett proposes a 6-level taxonomy from 'acknowledgement only' through 'reliable messaging' (as in ebXML) through 'reliable processing' where messaging is linked with business level transaction processing and recovery features.
"Peter Furniss elaborates on this basic idea by proposing that reliable web service interactions at the business level are best assured using a 'two-phase commit' approach: what you as a sender really want to know is if the receiver has committed to performing the work requested by the web service. If not, various rollback/remediation operations need to be performed, whether the lack of commitment is due to mechanical reasons or business reasons. He further argues that 'the "simple" ack approach actually requires some extra messages to avoid one or both sides having to remember the request (or some identification on it) indefinitely or have a complicated set of timeout rules as to when they can forget things. (and that's before we worry about surviving crashes)'..."
[over 100 followup messages...]
A requirement identified in the Web Services Architecture Requirements Working Draft is [AR017.2] that "the WSA must support reliable messaging." One of the features of the Extended Web Services Architecture is the reliable message -- implementation of Reliable Messaging; one message exchange pattern (MEP) is a series of requests between two nodes with an acknowledgement SOAP Module.
In the Web Services Glossary Working Draft of 14-November-2002, "Reliable messaging" is defined as "The ability: (1) of a sender of a message to be able to determine whether a given message has been received by its intended receiver and to take compensating action in the event a given message has been determined not to have been received. (2) of the intended receiver of the message to be assured that it receives and processes a given message once and only once; (3) of both sender and receiver of a message to carry out (1) and (2) with a high probability of success in the face of inevitable, yet often unpredictable, network, system, and software failures."
Several of the usage scenarios and use cases documented in the Web Services Architecture Usage Scenarios Working Draft deal with message acknowledgement and related QoS. For example (reqs), "A Sender shall be able to determine from a receiver message whether a message has been reliably delivered, as specified by the receiver; a sender and receiver shall be able to engage in message exchange patterns that exhibit best-effort, at least once, at most once, ordered qualities of service..."
WS-I Reliable Secure Profile
"The WS-I Reliable Secure Profile Working Group is developing an interoperability profile dealing with secure, reliable messaging capabilities for Web services. The Working Group is developing and selecting a set of usage scenarios and their component message exchange patterns to guide the profiling work."
As of 2007-06, work was underway within WS-I's Reliable Secure Profile Working Group, chaired by Bob Freund (Hitachi). According to the revised WG Charter of 2006-04-21, the Reliable Secure Profile Working Group (RSPWG) will develop the Reliable Secure Profile 1.0 (RSP) to provide interoperability guidance for the following specifications: OASIS WS-ReliableMessaging 1.1, OASIS WS-SecureConversation 1.3, and any normatively referenced specifications, such as IETF RFCs. Prior to commencing profile development, the Working Group will develop requirements and scenarios documents which clearly define interoperability issues that motivate profile guidance. The Working Group shall make every effort to provide for composition with Basic Profile 1.1, Attachments Profile 1.0, Simple SOAP Binding Profile 1.0, and the Basic Security Profiles 1.0 and 1.1. The Working Group shall also coordinate closely with the development of Basic Profile 1.2 and 2.0 and enable similar levels of composition with those profiles." The WS-I Reliable Secure Profile Working Group Usage Scenarios document (Working Group Draft as of 2007-04-05) defines interoperability scenarios that comprise the set of scenarios to be profiled in the RSP 1.0 profile.
From a 2007-06-22 blog by Chris Ferris: "Work was started last year in WS-I to incorporate these [WSRM, WSRMP, WSMC] standards into a new profile, the WS-I Reliable Secure Profile 1.0 (RSP 1.0). Work on that profile is based on the IBM RAMP profile that I began and lead back in 2005, to build industry support for development of a new WS-I profile that would enable many important B2B use cases that required secure, reliable and asynchronous delivery of messages between business partners. Now that all of the specifications upon which the RSP profile is based have been adopted as standards by their respective development organizations, the RSP 1.0 profile development and interoperability testing will become the next key area of focus, as we work through the composition and interoperability aspects of the relevant standards. As for product adoption of the new standards, IBM has shipped the WebSphere Application Server 6.1 Feature Pack for Web services which includes support for the WS-RM standards as well as the other standards related to the WS-I RSP1.0 profile. Other vendors have also begun shipping support for these stanards in their latest product offerings. Certainly, I believe that this will open up a new wave of Web services adoption between business partners now that the key quality of service protocols like WS-RM, WS-Secure Conversation, and WS-Addressing have all been formally adopted as OASIS Standard or W3C Recommendations..."
References:
Reliable Secure Profile Working Group Charter. 'Web Services Reliable Secure Profile. Creation Date: 2006-02-10 Revision Date: 2006-04-21. "RSP 1.0 must list or denote the different options for binding to the underlying open standard protocol the various kinds of messages and their patterns of exchange, described in the specifications directly referenced by this charter, e.g., how the back-channel of a 2-way protocol may be used. It will clarify how these options are signaled, e.g., use of anonymous replyTo in WS-Addressing and use of anonymous AcksTo in WSRM. RSP 1.0 may further narrow these binding options allowed by these specifications as appropriate... The RSP 1.0 will be based upon the following specifications: (1) OASIS WS-ReliableMessaging 1.1; (2) OASIS WS-SecureConversation 1.3 [For clarity, this profile will not provide guidance for the policy adjuncts (e.g., WS-ReliableMessaging Policy Assertion) to these specifications]. The RSP 1.0, when practical, will compose with the following specifications: [i] WS-I Basic Profile 1.2; [ii] WS-I Basic Profile 2.0; [iii] WS-I Basic Security Profile 1.0; [iv] WS-I Basic Security Profile 1.1. If current guidance in these profiles prohibits such composition, the working groups should identify these requirements and determine whether additional errata or revisions are required..." [source PDF]
WS-I RSP WG Usage Scenarios. Edited by Jacques Durand (Fujitsu) and Marc Goodner (Microsoft). Working Group Draft. Version: 1.0. November 06, 2006. 28 pages. Send feedback to wsi_rsp_comment@lists.ws-i.org. "The RSP WG has decided to approach defining requirements for the RSP profile in terms of realistic and detailed use cases, called usage scenarios. This document describes these usage scenarios. These scenarios will serve as detailed input for the profiling work, providing evidence of potential interoperability issues and/or need for best practice guidelines."
"WS-I to Develop Reliable Messaging Profile." From the 2006-05-01 announcement "Web Services Interoperability Organization Initiates Work on Three New Profiles: Basic Profile 1.2, Basic Profile 2.0 and Reliable Secure Profile 1.0." Excerpt: "The newly chartered Reliable Secure Profile Working Group will begin developing scenarios, requirements and profile guidance in parallel with the related standardization efforts within the OASIS WS-Reliable Exchange Technical Committee. The working group's primary deliverable is the WS-I Reliable Secure Profile (RSP) 1.0 which will provide guidance to architects and developers concerning reliable messaging with security. RSP 1.0 will be based upon the following specifications: (1) OASIS WS-ReliableMessaging 1.1; (2) OASIS WS-SecureConversation 1.3. The scenarios and requirements work will consider interoperability issues identified across a wide range of Web services applications (e.g., mobile, devices, intermediaries, enterprise applications, etc.). A Chair for the Reliable Secure Profile Working Group will be named shortly. The Basic Profile 1.2 and 2.0, and the Reliable Secure Profile 1.0, when practical, will cleanly compose with other WS-I profiles delivered to date..."
General: Articles, Papers, News
[November 07, 2007] Reliable Messaging in the Real World." By Paul Fremantle [WWW] (WSO2). Presented at the Open Standards Forum in the session "Quality of Service: Messaging." 19 slides. The OASIS WS-RX Technical Committee recently published WS-ReliableMessaging 1.1 as an OASIS Standard. In this session, the co-chair, Paul Fremantle, will outline the standard, how it can be used, as well as talk about real-life implementation and interoperability challenges. Excerpts: There's a strong requirement for reliability, strongest demand, after Security. The requirement is not just for SOAP services; customers are usually looking for a Secure Reliable Channel. Binary data (MTOM) is a key capability. The aims of WS-ReliableMessaging 1.1: Allow interoperable systems to exchange messages with assured delivery (in particular Exactly-Once In Order), Or both sides are alerted to failure. Composable with other standards: WS-Addressing, WS-Security, WS-SecureConversation, SSL/TLS, WS-Policy. Supports one-way and two-way exchanges. Optionally, supports two-way exchanges with NAT, firewalls, Internet configuration... Real-world interoperability examples: (1) PRESTO: French government sponsored interop, uses WSRM 1.0 + WS-Security + MTOM; (2) Danish Government OIO SOI: WSRM 1.0, Replay model, HTTP and SMTP, WS-Security, .NET 3.0 and Apache Axis2/Sandesha2. A WS-I Reliable Secure Profile (WS-I RSP) being created: OASIS WS-ReliableMessaging 1.1, OASIS WS-SecureConversation 1.3, WS-Addressing, MTOM (efficient binary), Other Base profile aspects (SOAP, WSDL). The OASIS Technical Committee is still open to produce minor updates and errata, address conformance with WS-Policy 1.5; likely to produce a [version] 1.1.1/1.2.
[November 07, 2007] Paul Fremantle on the State of WS-*. InfoQ Interview with Paul Fremantle. By Stefan Tilkov, InfoQ. Posted 2007-11-07. In this interview, Paul Fremantle, WSO2 co-founder co-chair of the OASIS committee that standardized WS-Reliable Messaging, talks to Stefan Tilkov about the state and relative importance of web services standards, the role of open source software for SOA, his views on the eternal REST debate, and WSO2's business model. Fremantle: "Fundamentally [RM is] a very simple approach protocol that enables you to deliver SOAP messages exactly once, and in order. Obviously it has some other capabilities but that's the primary use people want. It adds a JMS-like capability to SOAP, which allows you to basically enable reliable messaging, retries, resends and dropping duplicates, all the kind of things that you would expect from a product like MQSeries, in a completely standard open format... And what is really interesting about RM is not that it's a hard thing to do, to reliably deliver messages is actually pretty simple. What is interesting about RM is that it is the only standard that has the backing of every single vendor in this space, ranging from Sun to Microsoft, to IBM, to TIBCO, to BEA, Sonic, Progress. I think that is very interesting because it opens up the possibility that there might really be an open, widely adopted standard for doing reliable messaging, which is something that the world hasn't really had today, there's JMS but that's just an API, underneath it all those wire protocols are completely different... What I think people are interested in are obviously SOAP as a core messaging protocol, Reliable Messaging to make sure messages get there, Security to make sure they are secure, and this thing called MTOM which is basically how you transmit binary data and still maintain efficiency, security and so forth and fit that into the SOAP messaging format. And Windows Communication Foundation (WCF, Indigo) is shipping now with these things in it. For example the Apache Axis2 project has these, the Sun JAX-RI has these, and this has become a standard set that I think a number of people are quite interested in. For example I am working on a French government initiative called Presto where they are mandating all government departments communicate with this set of standards. We are doing a very broad-ranging project in Denmark, where basically the Danish government is specifying that small business are going to use this set of standards plus a set of standard XML schemas to do things like purchase orders and invoices securely and reliably. I think these standards are getting to the point now where they work - OK, they look a little bit ugly and heavy to some people, but fundamentally, boring can be good. And in this case I think boring is good, and that the other thing we are seeing is that people are coaelescing and there's a fantastic innoQ chart with a hundred million web services standards on it, but very few of those hundreds are going to be used extensively and I think the ones I just mentioned are probably going to become the core set of web services standards..."
[June 22, 2007] "OASIS Approves WS-RM as an OASIS Standard." By Chris Ferris. Blog. Friday June 22, 2007. As to the announcement of WS-RM as an OASIS Standard: "This is wonderful (if not long awaited) news from my perspective as it culminates a project that I have been working on for the past 4 1/2 years, since its inception. Work was started last year in WS-I to incorporate these standards into a new profile, the WS-I Reliable Secure Profile 1.0 (RSP 1.0). Work on that profile is based on the IBM RAMP profile that I began and lead back in 2005, to build industry support for development of a new WS-I profile that would enable many important B2B use cases that required secure, reliable and asynchronous delivery of messages between business partners. Now that all of the specifications upon which the RSP profile is based have been adopted as standards by their respective development organizations, the RSP 1.0 profile development and interoperability testing will become the next key area of focus, as we work through the composition and interoperability aspects of the relevant standards. As for product adoption of the new standards, IBM has shipped the WebSphere Application Server 6.1 Feature Pack for Web services which includes support for the WS-RM standards as well as the other standards related to the WS-I RSP1.0 profile. Other vendors have also begun shipping support for these stanards in their latest product offerings. Certainly, I believe that this will open up a new wave of Web services adoption between business partners now that the key quality of service protocols like WS-RM, WS-Secure Conversation, and WS-Addressing have all been formally adopted as OASIS Standard or W3C Recommendations..."
[June 21, 2007] "Members Approve WS-ReliableMessaging as OASIS Standard. New Standard Assures Secure Message Exchange Using Web Services." — OASIS announced that its members have approved Web Services Reliable Messaging (WS-ReliableMessaging) version 1.1 as an OASIS Standard, a status that signifies the highest level of ratification. WS-ReliableMessaging allows messages to be transferred reliably despite failures in software components, systems, or networks. It enables a broad range of reliability features, including ordered delivery, duplicate elimination, and guaranteed receipt. Paul Fremantle of WSO2, co-chair of the OASIS Web Services Reliable Exchange (WS-RX) Technical Committee: "Reliable messaging is one of the features customers demand most as they move to electronic business. The problem is that messages can be lost, repeated, or reordered, and host systems can fail. WS-ReliableMessaging addresses all these risks by providing a modular mechanism that identifies, tracks, and manages the reliable transfer of messages between a source and a destination." Sanjay Patil of SAP, co-chair of the OASIS WS-RX Technical Committee: "WS-ReliableMessaging delivers a key element in the openness of an enterprise service-oriented architecture (SOA) and provides a critical building block that can be used in conjunction with other specifications and application-specific protocols to reliably handle a wide variety of SOA requirements and scenarios." The extensible nature of WS-ReliableMessaging allows additional functionality, such as security, to be tightly integrated. It incorporates a SOAP binding for interoperability and allows additional bindings to be defined. The protocol can be implemented with a variety of robustness characteristics ranging from in-memory persistence scoped to a single process lifetime, to replicated durable storage that is recoverable in the most extreme circumstances... The WS-ReliableMessaging OASIS Standard was developed by representatives of Adobe, BEA Systems, Fujitsu, Hitachi, IBM, Intel, IONA, Microsoft, NEC, Nortel, Novell, Oracle, Progress Software, Red Hat, SAP, Sun Microsystems, TIBCO, webMethods, and others. The WS-ReliableMessaging OASIS Standard and the archives of the OASIS WS-RX Technical Committee work are publicly accessible. OASIS hosts the ws-reliablemessaging-dev mailing list for exchanging information on implementing the standard...
[June 19, 2007] "WSRM 1.1 is an OASIS Standard." By Paul Fremantle. Blog. June 19, 2007. "... I can confirm that WSRM 1.1 is really, finally, truly, honestly an OASIS standard... Let me take this moment to recap what WSRM is and offers: (1) An interoperable wire protocol for Reliable Messaging based on SOAP and WS-Addressing; (2) Support for Exactly-Once, At-Least-Once, At-Most-Once and Ordered delivery; (3) The ability to offer two-way reliable messaging even through firewalls, NAT, etc. — so you can sit in Starbucks and have your RM Agent reliably deliver and collect your purchase orders for the day over the Starbucks Wifi; (4) We've tested and shown interoperability between IBM, Microsoft and Apache/WSO2, and we will do more testing in the coming months; (5) Composability with SSL and WS-Security to ensure that the RM channel itself isn't a target for attacks; (6) Support for binary messages through composability with MTOM; (7) Support from a wide variety of software companies and organizations, including IBM, Microsoft, BEA, Tibco, JBoss/Redhat, Apache, WSO2 (of course!), Hitachi, Fujitsu, NEC, Nokia, Ericsson, and plenty of others. As co-chair of the working group I want to offer my special thanks to Sanjay Patil, my co-chair, without whom I think I would have gone mad! While the whole TC worked very hard, I think its fair to say that there were a few people who really made this happen. Without denigrating the efforts of the rest of TC, I'd like to call attention to the work done by Doug Davis from IBM, Gilbert Pilz from BEA, Tom Rutt from Fujitsu, and Marc Goodner from Microsoft..."
[June 07, 2007] "WS-Reliable Messaging and Session Support (Part 3)." By Bhakti Mehta. Blog. "This is the third part of tri series blogs where in Part 1 we showed one way of supporting sessions with WS Reliable Messaging. Mike showed in his blog 'WS Reliable Messaging and Session Support Part 2' what the problems are with this approach and we now conclude with a third part where we have tried to fix some of these problems. Sessions are unique IDs used to identify a client. They would help maintain state for each client. In this sample you will see how sessions can be supported with WS Reliable Messaging (WS RM). WS RM is one of the enterprise features in Project Tango which is Sun's Java Web Services interoperability project with Microsoft's Windows Communication Foundation (WCF)... JAX-