Web Services Security and More, Part 2: The Global XML Web Services Architecture (GXA), Page 3
Reliable Message Delivery: WS-ReliableMessaging
In a message exchange scenario, it is of the utmost importance that the parties involved in the exchange can ensure that their messages are delivered in a reliable manner, including the assurance that "lost" messages can be retransmitted and properly received. These capabilities (and more) are addressed by the WS-ReliableMessaging specification, released in March 2003 by Microsoft, IBM, BEA, and TIBCO.
Reliable Messaging Model
The WS-ReliableMessaging reliable messaging model provides a guarantee that messages sent by an initial sender will be delivered to the ultimate receiver, even in the presence of software component, system, or network failures. As with all GXA specifications, WS-ReliableMessaging integrates with and complements other GXA specifications such as WS-Security and the various policy-related specifications, as well as other Web services specifications. The following figure depicts a simple reliable message exchange involving four entities:
- Initial Sender: The endpoint that sends a message;
- Source: The endpoint that actually transmits the message;
- Destination: The endpoint that receives the message;
- Ultimate Receiver: The endpoint to which a message is finally delivered;
In the above figure, the Initial Sender sends a message for reliable delivery by submitting it to the Source (this is the point at which the reliable guarantee begins). The Source accepts the message and transmits it one or more times to the Destination. The Destination then delivers the message to the Ultimate Receiver (this is the point at which the reliable guarantee ends).
Endpoints that implement the WS-ReliableMessaging protocol provide delivery assurances that act as a policy regarding the number of times a message can be sent, whether duplicate messages are allowed, and whether message order is to be preserved. There are four delivery assurances defined by WS-ReliableMessaging:
- Messages will be delivered at most once (and possibly not at all) and without duplication;
- Every message sent will be delivered at least once (and possibly more than once);
- Every message sent will be delivered exactly once (i.e. without duplication);
- Messages will be delivered in the order in which they were sent;
The "InOrder" delivery assurance can be combined with any of the other three assurances.
An Example: Reliable Message Exchange with Retransmission
The following figure demonstrates how WS-ReliableMessaging handles messages in a case where messages are lost in transit and need to be retransmitted:
In the above figure, the Source sends three messages—numbers 1, 2, and 3. Because message #3 is the last message in the sequence, it includes a "LastMessage" token (this is the third level from the top of the figure). However, message #2 becomes lost in transit—therefore, the Destination acknowledges receipt of only messages #1 and #3 (this is the fourth level). The Source then retransmits message #2, and requests an acknowledgement (this is the fifth level). Finally, upon receiving message #2, the Destination acknowledges receipt of all three messages.
The concepts presented here will be discussed in further detail below.
WS-ReliableMessaging uses an entity called a sequence to track and manage reliable message delivery. A sequence contains information such as a unique identifier, message number (which represents the particular message within the sequence that it is carrying), and a date/time at which the sequence will expire. The following is an example of a sequence:
<wsrm:Sequence> <wsu:Identifier>http://sequenceid.com</wsu:Identifier> <wsrm:MessageNumber>3</wsrm:MessageNumber> <wsrm:LastMessage/> </wsrm:Sequence>
The preceding example depicts the third and last message of the sequence whose identifier is "http://sequenceid.com" (note the <wsrm:LastMessage> element). So, in the example presented in Figure 2, messages #1, #2, and #3 (respectively) would look as follows:
<wsrm:Sequence> <wsu:Identifier>http://fabrikam123.com/abc</wsu:Identifier> <wsrm:MessageNumber>1</wsrm:MessageNumber> </wsrm:Sequence> <wsrm:Sequence> <wsu:Identifier>http://fabrikam123.com/abc</wsu:Identifier> <wsrm:MessageNumber>2</wsrm:MessageNumber> </wsrm:Sequence> <wsrm:Sequence> <wsu:Identifier>http://fabrikam123.com/abc</wsu:Identifier> <wsrm:MessageNumber>3</wsrm:MessageNumber> <wsrm:LastMessage/> </wsrm:Sequence>
In WS-ReliableMessaging, acknowledgements may be transmitted individually (i.e. as individual messages) or included as part of return messages. The timing of acknowledgements can be controlled through policy. An acknowledgement can be sent by a Destination for a single message, or a group of messages within a sequence—the latter approach can be beneficial for bandwidth purposes. Acknowledgement of a group of messages is done by specifying an acknowledgement range that gives the upper and lower (inclusive) message numbers for which an acknowledgement is being provided within a particular sequence.
The following is an example of an acknowledgement:
<wsrm:SequenceAcknowledgment> <wsu:Identifier>http://sequenceid.com</wsu:Identifier> <wsrm:AcknowledgmentRange Upper="5" Lower="1"/> </wsrm:SequenceAcknowledgment>
In the above example, messages #1 to #5 (inclusive) of the sequence whose identifier is "http://sequenceid.com" are acknowledged. If one message were lost in transmission (for example, message #3), the acknowledgement would look as follows:
<wsrm:SequenceAcknowledgment> <wsu:Identifier>http://sequenceid.com</wsu:Identifier> <wsrm:AcknowledgmentRange Upper="2" Lower="1"/> <wsrm:AcknowledgmentRange Upper="5" Lower="4"/> </wsrm:SequenceAcknowledgment>
Page 3 of 5