Message Reliability for Web Services

While WS-Addressing helps to solve the challenges of consistently describing and accessing Web service endpoints, the general issues of getting messages reliably between message endpoints are being addressed in another specification. A Web service needs to be able to determine when messaging has become unreliable so that it can adjust accordingly , which might involve resending certain messages or delaying the processing of messages until other messages arrive . To that end, IBM, BEA Systems, and Microsoft have again teamed up to draft WS-ReliableMessaging, a specification that attempts to guarantee the reliability of SOAP messaging by defining message acknowledgments, message ordering, and reliability policies. Now let s look at how these message reliability features work.

Message Ordering

When a Web services “based interaction comprises a series of SOAP messages, it s conceivable that because of transmission on unreliable networks these messages might not be received in the order in which they were sent. When messages in a series are lost or delayed, the interaction can become unreliable. This can cause problems that require advanced application logic for handling cases when the message sender assumes that as a result of an earlier message the Web service is in a certain state, but when messages are received out of order, this might not be the case.

To track the order of Web service requests , WS-ReliableMessaging introduces the Sequence SOAP header element. When a client communicates with a Web service implementing WS-ReliableMessaging, the Sequence element is used to number the messages in a sequence, set a time-out period for a sequence, and to declare the end of a sequence. The Sequence element implements the following child elements:

• Identifier A unique identifier for the sequence, which leverages the Identifier element defined in the Web Service Security Addendum specification and which is qualified against the http://schemas.xmlsoap.org/ws/2002/07/utility namespace.

• MessageNumber A value that defines the sequence number for the message, wherein numbers are assigned as consecutive unsigned integers starting at 1 and increasing by 1 throughout the lifetime of the conversation.

• LastMessage Declares that a message is the last in the sequence.

• Expires Declares a time in the future when the sequence expires, whether or not the LastMessage element has been used.

The following is an example of a message containing the Sequence header; this message is the third in a sequence, which is defined by the GUID in the Identifier element:

 <soap:Envelope xmlns:wsrm="http://schemas.xmlsoap.org/ws/2003/03/rm" 
 xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility" 
 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> 
 <soap:Header> 
   
 <wsrm:Sequence> 
 <wsu:Identifier> 
 uuid:56b8f19a-40be-ca6c-b6a0-89eaf22c7df3 
 </wsu:Identifier> 
 <wsrm:MessageNumber>3</wsrm:MessageNumber> 
 </wsrm:Sequence> 
   
 </soap:Header> 
 <soap:Body> 
 <GetDocument xmlns="http://example.com/documentservice"> 
   
 </GetDocument> 
 </soap:Body> 
 </soap:Envelope> 

Message Receipt Acknowledgments

Since the Web service architecture enables asynchronous messaging, there is no requirement that a response message be returned for any given request message, as there would be in two-way messaging. However, from the standpoint of message reliability, such an acknowledgment in essence closes the loop on the request process. In asynchronous messaging and without receipt acknowledgments, the requesting party has no way of knowing whether the request message was received. In this case, if there was unreliability on the network, it will likely be manifested later in the interaction as failures that result from having both parties in a different application state. For example, an application might send a one-way request to open a shopping cart session, with items to be added in later requests. If this request was not received, subsequent requests to add items to the cart will fail since the Web service never received the first request to create the cart session.

One solution might be simply to return a response message that a new cart session was created, essentially making it a two-way messaging scenario. While this dedicated acknowledgment message solves this reliability issue, it is inefficient to generate such a response message, particularly in situations in which both parties are regularly exchanging messages. In such cases, it would be more efficient to piggyback the acknowledgment in the header of an otherwise unrelated message. WS-ReliableMessaging proposes the use of a SequenceAcknowledgment header element that is used to return a receipt acknowledgment for one or more messages in a given sequence, either in an arbitrary response message or in a response created exclusively to return the acknowledgment. A SequenceAcknowledgment element supports the following child elements:

• Identifier A unique identifier for the sequence, which leverages the Identifier element defined in the Web Service Security Addendum specification and is qualified against the http://schemas.xmlsoap.org/ws/2002/07/utility namespace.

• AcknowledgmentRange Defines a range of one or more sequence numbers that identifies messages that have been received, where the range is defined by the integer values of the Upper and Lower attributes.

An acknowledgment for a single message in a sequence will have the same sequence number for both Upper and Lower attributes. If the range of messages in the sequence being acknowledged is not contiguous, more than one AcknowledgmentRange element can be used. The following example shows the inclusion of a SequenceAcknowledgment element in an acknowledgment response message:

 <soap:Envelope xmlns:wsrm="http://schemas.xmlsoap.org/ws/2003/03/rm" 
 xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility" 
 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> 
 <soap:Header> 
   
 <wsrm:SequenceAcknowledgment> 
 <wsu:Identifier> 
 uuid:56b8f19a-40be-ca6c-b6a0-89eaf22c7df3 
 </wsu:Identifier> 
 <wsrm:AcknowledgmentRange Upper="2" Lower="1"/> 
 <wsrm:AcknowledgmentRange Upper="4" Lower="4"/> 
 </wsrm:SequenceAcknowledgment> 
   
 </soap:Header> 
 <soap:Body /> 
 </soap:Envelope> 

This acknowledgment indicates that message number 3 in the sequence was not received and that the requester should resend this message.

A Web service can wait for a negotiated amount of time before returning an acknowledgment, which gives it time to attach it to another outgoing message. However, once this limit has been reached, the service must generate a response message solely to return the acknowledgment, as in the preceding example. Of course, at any point the AckRequested header element can be sent with any message to the Web service to explicitly request that an acknowledgment for the sequence be returned. This element supports the following child element:

• Identifier A unique identifier for the sequence, which leverages the Identifier element defined in the Web Service Security Addendum specification and which is qualified against the http://schemas.xmlsoap.org/ws/2002/07/utility namespace.

The following message includes a request for a series acknowledgment:

 <soap:Envelope xmlns:wsrm="http://schemas.xmlsoap.org/ws/2003/03/rm" 
 xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility" 
 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> 
 <soap:Header> 
   
 <wsrm:AckRequested> 
 <wsu:Identifier> 
 uuid:56b8f19a-40be-ca6c-b6a0-89eaf22c7df3 
 </wsu:Identifier> 
 </wsrm:AckRequested> 
   
 </soap:Header> 
 <soap:Body> 
   
 </soap:Body> 
 </soap:Envelope> 

Reliable Messaging Policies

In addition to the functionalities just discussed that use reliability headers, WS- ReliableMessaging also defines a set of policy assertions that can be published by a Web service to declare which reliable messaging functionalities are required when accessing the endpoint. These policy assertions include the following general categories:

• Specification version The version of WS-ReliableMessaging supported by the endpoint.

• Delivery assurance The number of times a message can be delivered and whether message sequences must be delivered in order.

• Sequence expiration The lifetime of a messaging sequence.

• Inactivity time-out The time-out period after which a sequence is considered terminated .

• Retransmission interval The time that an application should wait for an acknowledgment before resending the message.

• Acknowledgment interval The time that a Web service should wait for a response message to be sent back to the requester before generating a stand-alone acknowledgment message.

I will discuss using policies for reliable messaging along with security and the other types of policy assertions in Chapter 6.