Reliable Messaging

A typical business process is composed of several diverse web services. These services are provided by several coordinating partners. During the execution of the business process, several documents are exchanged between the partners. The means of exchange used for these documents must be reliable. This section discusses the standards for achieving reliable messaging between the partners.

In any communication, delivering a message reliably is of utmost importance to ensure the proper integrity of the system. Delivery of messages is subject to several error conditions arising due to:

• Network failures
• Component failures
• System failures

Under such unforeseen conditions, messages should still be reliably delivered. XML-based messages are usually exchanged between partners over HTTP. HTTP is a stateless protocol and is not reliable. While using HTTP, a message in split into several small packets during delivery. Such packets are numbered. The order in which these packets are received may not agree with the dispatch order. Packets may be lost during transit. HTTP does not provide for positive acknowledgement of a message delivery. Thus, it becomes important for us to define a standard for reliable messaging while exchanging messages in a business process.

Reliable messaging specifications were designed to address these issues associated with HTTP. These specifications define a new protocol that is responsible for:

• Identifying each message
• Tracking its delivery
• Guaranteeing delivery of the message from the source to the ultimate destination, in the correct order of dispatch

Messaging Model

The messaging model used for reliable message delivery is illustrated in the following diagram:

This model defines four components:

• Initial sender
• Source
• Destination
• Ultimate receiver

The initial sender sends a message to the source for delivery to the ultimate receiver. The source dispatches the message to the destination. After receiving the message, the destination acknowledges the message. If the source does not receive the acknowledgment, the source resends the message. The source will send the message multiple times until an acknowledgement is received. Finally, the destination delivers the message to the ultimate receiver.

For this model to work properly, the source must have an endpoint reference to the destination. The source must know the policies associated with the destination and must be capable of formulating messages that comply with these policies. Also, if a secured message exchange is desired, both source and destination must support associated security protocols.

The source assigns a sequence number to each message. The number starts with 1 and increments by exactly 1 for each subsequent reliable message. The destination acknowledges the message along with the sequence number of the received message.

Example

The RM protocol uses the sequence element for tracking messages and managing their delivery. The following example shows how the messages are sequenced:

<wsrm:Sequence>
  <wsu:Identifier>
    http://mysite.com/test
  </wsu:Identifier>
  <wsrm:MessageNumber>
    12
  </wsrm:MessageNumber>
  <wsrm:LastMessage/>
</wsrm:Sequence>

Each message contains a MessageNumber. If the current message is the last message in a sequence, the LastMessage element is included in the sequence.

The receiving endpoint acknowledges the message receipt using the following XML code:

<wsrm:SequenceAcknowledgment>
  <wsu:Identifier>
    http://mysite.com/test
  </wsu:Identifier>
  <wsrm:AcknowledgmentRange Upper=”12” Lower=”1”/>
</wsrm:SequenceAcknowledgment>

The range of received messages is specified in the acknowledgement. For example, the above acknowledgment indicates that the messages in the range 1 through 12 are received. If the messages are not received in order, the acknowledgement specifies the sub-ranges of received messages, as shown in the following code:

<wsrm:SequenceAcknowledgment>
  <wsu:Identifier>
    http://mysite.com/test
  </wsu:Identifier>
  <wsrm:AcknowledgmentRange Upper=”2” Lower=”1”/>
  <wsrm:AcknowledgmentRange Upper=”8” Lower=”5”/>
  <wsrm:AcknowledgmentRange Upper=”12” Lower=”10”/>
</wsrm:SequenceAcknowledgment>

The above acknowledgement indicates that the messages in the ranges 1-2, 5-8, and 10-12 are received, and that the messages 3, 4, and 9 are not yet received.

Requesting Acknowledgement

A message sender may request an acknowledgement from the destination at any time. It does so by sending a message containing the AckRequested element. The use of this element is as follows:

<wsrm:AckRequested ...>
  <wsu:Identifier> uri </wsu:Identifier>
  ...
</wsrm:AckRequested>

The destination must respond to the above message with the SequenceAcknowledgment message.

Delivery Assurances

The two endpoints that implement the Reliable Messaging protocol assure message delivery from the initial sender to the ultimate receiver. The following four delivery assurances are supported:

• AtMostOnce: No duplicate messages are permitted. Some may not be delivered.
• AtLeastOnce: May result in duplicate messages at the receiver end.
• ExactlyOnce: Every message is delivered without duplication.
• InOrder: Messages are delivered in the order received.

Delivery assurance is specified using the following syntax:

<wsrm:DeliveryAssurance Value=”wsrm:AtMostOnce”/>

Other Assertions

The RM specification defines a few XML elements to specify other types of assertions. These assertions include:

• Inactivity timeout:

     <wsrm:InactivityTimeout Milliseconds=”100” />

• Base re-transmission interval:

     <wsrm:BaseRetransmissionInterval Milliseconds=”100”/>

• Acknowledgment interval:

   <wsrm:AcknowledgementInterval Milliseconds=”100”/>

• Sequence lifetime specified using the Expires element of WS-Security:

     <wsu:Expires> time </wsu:Expires>

Faults

Faults, if any, during the transmission are indicated using the SequenceFault element.

The following example illustrates the SequenceTerminated fault.

<wsrm:SequenceFault>
  <wsu:Identifier> uri </wsu:Identifier>
  <wsrm:FaultCode>
    wsrm:SequenceTerminated
  </wsrm:FaultCode>
</wsrm:SequenceFault>

The SequenceTerminated fault indicates that the current sequence was terminated either by the source or the destination due to unrecoverable conditions.

The other pre-defined fault codes are:

• wsrm:UnknownSequence
• wsrm:InvalidAcknowledgement
• wsrm:MessageNumberRollover
• wsrm:LastMessageNumberExceeded
• wsrm:SequenceRefused