Figure 1: Egg-and-spoon race block diagram
Keywords: Web Services, SOAP, Reliability
Biography
Tony Graham is a current member of the W3C XML Protocol Working Group and the OASIS Web Services Reliable Messaging TC and a past member of the W3C XSL Working Group. He is also the principal author of the xmlroff XSL formatter and the author of "Unicode: A Primer" and numerous articles and conference presentations on XML, XSL, XSLT, and Unicode.
How is Web Services over an unreliable network like an egg-and-spoon relay race? How does adding reliability alter the dynamics of the race? These and other important questions (details of the reliability standardization underway) are answered.
1. How is an Egg-and-Spoon Race Like a Web Service?
1.1 Egg-and-Spoon Race
1.2 Computer Network
1.3 Web Service
2. Scope for Adding Reliability
2.1 Egg-and-Spoon Race
2.2 Computer Network
2.3 Web Service
3. Standards and Specifications for Reliable Web Services
3.1 WS-Reliability 1.1
3.2 WS-ReliableMessaging
4. What Makes a Reliable Web Service Reliable?
4.1 Basic Web Service
4.2 Enter the RMP
4.3 Reliable Operations
4.3.1 Guaranteeing Message Delivery
4.3.1.1 Identifying Messages
4.3.2 Guaranteeing Duplicate Elimination
4.3.3 Guaranteeing Message Delivery and Duplicate Elimination
4.3.4 Guaranteeing Message Order
4.4 Stop The Protocol, I Want To Get Off
5. Conclusion
Appendix 1. WS-Reliability 1.1 and WS-ReliableMessaging Legal
Notices
Appendix 1.1 WS-Reliability 1.1 Notices
Appendix 1.2 WS-ReliableMessaging Copyright Notice
Bibliography
When they are reduced to their essentials, an egg-and-spoon race, a computer network, and a Web Service are all very similar.
To a first approximation, the rules of an egg-and-spoon race are:
Figure 1: Egg-and-spoon race block diagram
To make it a relay race, just add multiple stages.
To a first approximation, the rules of operation of a computer network are:
Figure 2: Network block diagram
To a first approximation, the rules of operation of a Web Service are:
Adding intermediaries requires relaying the SOAP message through the intermediary nodes.
Figure 3: Web Service block diagram
There are several ways to add reliability to an egg-and-spoon race, including:
However, using any mechanism to keep the egg on the spoon changes the dynamics of the race too much: it's no longer an egg-and-spoon race and instead is just an exercise in running fast while holding a spoon.
Similarly, while there are ways to make networks – including the networks underlying Web Services – more reliable, they're not the networks that we have today. Making an inherently reliable network similarly changes the dynamics of networking but it is also a lot more difficult – and a lot more expensive – than putting your hand on the egg when you run.
For Web Services to be inherently reliable is twice as difficult. If you wanted to rip out and replace existing networks with reliable networks and also rip out and replace existing Web Services infrastructure, then you could do it. But if you set out to do that, you're more likely to end up with egg on your face than egg on your spoon.
So for Web Services in particular, the answer isn't to replace the existing infrastructure. It is, instead, to put a reliability layer above the SOAP transport so that the reliable Web Service for the most part looks to the application a lot like the existing, unreliable Web Service but just happens to get its messages through to the other endpoint; all messages, in the right order, and with no duplicates.
At the time of this writing, there is one standard and one specification in development for making reliable Web Services: the WS-Reliability standard being developed at OASIS and the WS-ReliableMessaging specification owned by BEA Systems, IBM, Microsoft, and Tibco. The following table shows some of their details as of the time of this writing.
| Name | WS-Reliability 1.1 | Web Services Reliable Messaging Protocol (WS-ReliableMessaging) |
| Copyright holder | OASIS Open | BEA Systems, IBM, Microsoft, Tibco |
| Current version | CD 1.086 | Unnumbered |
| Date | 24 August 2004 | March 2004 |
| Supported SOAP versions | SOAP 1.1, SOAP 1.2 | SOAP 1.1, SOAP 1.2 |
Table 1: Comparison of Reliable Web Services Standards and Specifications
At the time of this writing, Committee Draft 1.086 (CD 1.086) is about to be submitted to the OASIS membership for a vote on whether or not to make the CD into an OASIS Standard. The voting will close on 31 October, which is shortly before XML 2004.
WS-ReliableMessaging has been made public “for review and evaluation only”. There has been no publicly visible advancement of the standard since the current version was made public in March 2004.
This section builds up a description of a reliable Web Service. Talking about capabilities rather than implementations avoids trying to both introduce and disambiguate the standard and the specification all at the same time. It also avoids complex explanations when an element or attribute has a dual role in multiple aspects of ensuring reliability.
Where there are differences in terminology, this section uses terms from WS-Reliability [WS-R] unless otherwise noted.
Figure 4 shows the anatomy of a basic Web Service without any added reliability. It shows a Producer passing a payload to a SOAP node. That payload is encapsulated in a SOAP envelope and sent to the SOAP Node that extracts the payload and passes it to the Consumer.
For the purposes of discussing reliability of Web Services, it doesn't much matter what is the producer or the consumer or even what is the payload in the SOAP envelope: all that really matters is whether or not the correct payload or payloads are delivered to the consumer the requisite number of times and in the requisite order. In this basic scenario, there is no guarantee that payloads will be delivered to the consumer, let alone any guarantee of their ordering.
Adding reliability requires something more than generic SOAP nodes, it requires SOAP nodes on either end that additionally understand the additional reliability protocol in use. In WS-Reliability terms, these are a sending and receiving Reliable Messaging Processor (RMP), and in WS-ReliableMessaging terms, these are RM Source and RM Destination endpoints.
Figure 5 shows the abstract operations as defined by WS-Reliability. The producer submits payloads to the Sending RMP, which transmits them to the Receiving RMP. The Receiving RMP delivers payloads to the consumer. The Receiving RMP additionally transmits acknowledgments and fault indications back to the Sending RMP as part of the reliability protocol. The consumer may submit responses back to the Receiving RMP as a response to a previously received payload. The responses may be transmitted back to the Sending RMP and made available to the producer. The Sending RMP additionally notifies the producer when a payload fails to be delivered.
Both the standard and the specification define four reliability features or basic delivery assurances:
| WS-Reliability 1.1 reliability feature | WS-ReliableMessaging delivery assurance | Description |
| Guaranteed message delivery (At-Least-Once) | AtLeastOnce | A payload will be delivered at least once or an error will be notified |
| Guaranteed message duplicate elimination (At-Most-Once) | AtMostOnce | A payload will be delivered exactly once or an error will be notified |
| Guaranteed message delivery and duplicate elimination (Exactly-Once) | ExactlyOnce | A payload will be delivered one and only once or an error will be notified |
| Guaranteed message ordering | InOrder | Payloads, within a group of related payloads, are delivered to the consumer in the order in which they are submitted or an error will be notified |
Table 2: Comparison of reliable operations
Before looking at guaranteeing message delivery, look at what happens if a message fails to be delivered and there's no reliability mechanism for recovering from the failure. Figure 6 shows a failure when sending a SOAP envelope from the Sending RMP to the Receiving RMP. In the absence of any reliability mechanism, there's potentially no way for the Sending RMP – and almost certainly no way for the producer – to know whether a message is delivered or whether delivery failed.
The first part of guaranteeing message delivery, therefore, is providing an indication when a message is received by the Receiving RMP. Figure 7 shows an acknowledgment being sent from the Receiving RMP to the Sending RMP following the Receiving RMP receiving the message.
The second part of guaranteeing message delivery, therefore, is resending a message for which no acknowledgment has been received. Both the WS-Reliabiity and WS-ReliableMessaging protocols support acknowledgments for received messages, and both the standard and the specification support the Sending RMP (RM Source) resending an unacknowledged message.
The description so far has been adequate if only one producer submits payloads one at a time to only one Sending RMP that transmits reliable messages to only one Receiving RMP and that Receiving RMP delivers payloads to only one consumer. Reality tends to be a bit more complex than that.
In the real world, a Sending RMP may be sending reliable messages to more than one Receiving RMP and, consequently, be receiving acknowledgments from more than one Receiving RMP. The Sending RMP may also be maintaining several “conversations” comprising groups of related messages with a single Receiving RMP. Furthermore, a Receiving RMP may simultaneously be receiving messages from multiple Sending RMP.
It should be no surprise, therefore, that every reliable message (from either protocol) carries a unique identifier. The identifier is used to correlate messages and acknowledgments.
WS-Reliability supports identifying both single messages and messages within a sequence of individual messages. All messages have a group ID; when the message is not part of a group, the group ID identifies the message, and when the message is part of a group, an additional, optional sequence number identifies the messages within its sequence.
WS-ReliableMessaging requires both a sequence identifier and a message number for every message.
In both protocols, the only requirement for the group ID or sequence identifier is that it be a URI, although WS-Reliability does recommend that implementations use the Message-ID schema defined in [RFC2392].
Acknowledgments solve the problem of guaranteeing message delivery, but guaranteeing delivery is only one aspect of reliability. Imagine you were using a Web Service, a reliable Web Service even, when instructing your bank to pay your electricity bill. Yes, you want assurance that your instructions are delivered so the lights don't go out at your house. What you don't want is for the instructions to go through twice because your account would then be debited twice. That's just one example of where guaranteeing duplicate elimination is important.
Figure 8 shows a sequence of messages being sent without acknowledgments. Message 2 is lost, but message 3 is sent twice (for some reason). Without duplicate elimination, both copies of message 3 are delivered to the consumer.
Figure 9 shows the same sequence of messages between the Sending RMP and Receiving RMP but with duplicate elimination occurring in the Receiving RMP. Only one copy of each message is being delivered to the consumer.
Both guaranteed message delivery and guaranteed duplicate elimination have their separate uses. When used in combination, they provide “Exactly-Once” delivery, where each message is delivered once and only once.
Imagine you are using a Web Service, a reliable Web Service even, when instructing your bank to pay your electricity bill. You want “At-Least-Once” delivery so you can be sure that the lights don't go out at your house. You also want “At-Most-Once” delivery since your account would be debited twice if the message goes through twice.
Figure 10 shows a message being received correctly but being re-sent because the message's acknowledgment was not received by the Sending RMP. With duplicate elimination in the Receiving RMP, only one copy of the message is delivered to the consumer, and with message acknowledgments from the Receiving RMP to the Sending RMP, the Sending RMP stops retransmissions once (and only when) the message is acknowledged.
The remaining common reliability feature is guaranteed message ordering (or “InOrder” messages). To continue the bank account scenario, if you need to transfer money from your savings account into your current account before you can pay your electricity bill, then you need message ordering to be sure that your messages reach the bank in the correct order.
Figure 11 shows a sequence of messages where the second message is received by the Receiving RMP before the first message. With message ordering in the Receiving RMP, the messages' payloads are delivered to the consumer in the correct 1–2 sequence.
Both the standard and the specification define mechanisms for voluntarily and involuntarily terminating a message group.
The Sending RMP can voluntarily terminate the protocol by indicating that a message is the last message in its group, as shown in Figure 12.
A group can also terminate because the group has:
This paper began by noting the essential similarities between an egg-and-spoon race, a computer network, and a Web Service. It then discussed ways of adding reliability to each of those without fundamentally changing their dynamics. The method, for Web Services, is to layer reliability on top of existing Web Services infrastructure, and the remainder of the paper discussed the features of the WS-Reliability standard being developed at OASIS and the WS-ReliableMessaging specification that is owned by BEA, IBM, Microsoft, and Tibco.
Based on the essential similarity of an egg-and-spoon race to a Web Service, it should be possible to create a reliability protocol for egg-and-spoon relay races that will deliver more eggs to the finish line – especially where egg order is significant – than an unreliable protocol under the same conditions.
The legal notices from the current versions of WS-Reliability 1.1 and WS-ReliableMessaging are reproduced here so you can compare their terms and conditions.
OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.
OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.
Copyright © OASIS Open 2003-2004. All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself does not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on an “AS IS” basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
(c) 2002-2004 BEA Systems Inc., International Business Machines Corporation, Microsoft Corporation, Inc, and TIBCO Software Inc. All rights reserved.
BEA Systems, IBM, Microsoft, and TIBCO Software (collectively, the "Authors") hereby grant you permission to copy and display the WS-ReliableMessaging Specification (the Specification), in any medium without fee or royalty, provided that you include the following on ALL copies of the Specification, or portions thereof, that you make:
EXCEPT FOR THE COPYRIGHT LICENSE GRANTED ABOVE, THE AUTHORS DO NOT GRANT, EITHER EXPRESSLY OR IMPLIEDLY, A LICENSE TO ANY INTELLECTUAL PROPERTY, INCLUDING PATENTS, THEY OWN OR CONTROL.
THE SPECIFICATION IS PROVIDED "AS IS," AND THE AUTHORS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE SPECIFICATION ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.
THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THE SPECIFICATION.
The Specification may change before final release and you are cautioned against relying on the content of this Specification.
The name and trademarks of the Authors may NOT be used in any manner, including advertising or publicity pertaining to the Specification or its contents without specific, written prior permission. Title to copyright in the Specification will at all times remain with the Authors.
No other rights are granted by implication, estoppel or otherwise.
XHTML rendition made possible by SchemaSoft's Document Interpreter™ technology.
