Reliable messaging

The benefits of a loosely coupled messaging framework come at the cost of a loss of control over the actual communications process. After a Web service transmits a message, it has no immediate way of knowing:

• whether the message successfully arrived at its intended destination
• whether the message failed to arrive and therefore requires a retransmission
• whether a series of messages arrived in the sequence they were intended to

Reliable messaging addresses these concerns by establishing a measure of quality assurance that can be applied to other activity management frameworks (Figure 7.7).

Figure 7.7. Reliable messaging provides a guaranteed notification of delivery success or failure.

WS-ReliableMessaging provides a framework capable of guaranteeing:

• that service providers will be notified of the success or failure of message transmissions
• that messages sent with specific sequence-related rules will arrive as intended (or generate a failure condition)

Although the extensions introduced by reliable messaging govern aspects of service activities, the WS-ReliableMessaging specification is different from the activity management specifications we discussed in Chapter 6. Reliable messaging does not employ a coordinator service to keep track of the state of an activity; instead, all reliability rules are implemented as SOAP headers within the messages themselves.

Note

Chapter 17 provides an introduction to the WS-ReliableMessaging language in the WS-ReliableMessaging language basics section.

In Plain English

In the last chapter's Choreography section we explained how our car wash had formed an alliance with the car wash located on the other side of the highway. Part of our arrangement was to share part-time workers during peak hours.

One of the workers that joined our team is named George. Though good at his job, George has a bad memory. When we request that workers from the other side walk over to help us out, we always are warned when one of those workers is George.

The walk from the other gas station is about one kilometer. Sometimes George forgets the way and gets lost. We therefore put a system in place where we agree to call the other company to tell them how many workers have arrived. If it's not equal to the number of workers they actually sent, it's usually because George has gone missing again.

Our system of calling the other company to acknowledge the receipt of the workers and to report any missing workers builds an element of reliability into our resource sharing arrangement.

 

7.2.1. RM Source, RM Destination, Application Source, and Application Destination

WS-ReliableMessaging makes a distinction between the parts of a solution that are responsible for initiating a message transmission and those that actually perform the transmission. It further assigns specific descriptions to the terms "send," "transmit," "receive," and "deliver," as they relate differently to these solution parts. These differentiations are necessary to abstract the reliable messaging framework from the overall SOA.

An application source is the service or application logic that sends the message to the RM source, the physical processor or node that performs the actual wire transmission. Similarly, the RM destination represents the target processor or node that receives the message and subsequently delivers it to the application destination (Figure 7.8).

Figure 7.8. An application source, RM source, RM destination, and application destination.

 

7.2.2. Sequences

A sequence establishes the order in which messages should be delivered. Each message that is part of a sequence is labeled with a message number that identifies the position of the message within the sequence. The final message in a sequence is further tagged with a last message identifier.

7.2.3. Acknowledgements

A core part of the reliable messaging framework is a notification system used to communicate conditions from the RM destination to the RM source. Upon receipt of the message containing the last message identifier, the RM destination issues a sequence acknowledgement (Figure 7.9). The acknowledgement message indicates to the RM source which messages were received. It is up to the RM source to determine if the messages received are equal to the original messages transmitted. The RM source may retransmit any of the missing messages, depending on the delivery assurance used (see following section).

Figure 7.9. A sequence acknowledgement sent by the RM destination after the successful delivery of a sequence of messages.

An RM source does not need to wait until the RM destination receives the last message before receiving an acknowledgement. RM sources can request that additional acknowledgements be transmitted at any time by issuing request acknowledgements to RM destinations (Figure 7.10). Additionally, RM destinations have the option of transmitting negative acknowledgements that immediately indicate to the RM source that a failure condition has occurred (Figure 7.11).

Figure 7.10. A request acknowledgement sent by the RM source to the RM destination, indicating that the RM source would like to receive an acknowledgement message before the sequence completes.

Figure 7.11. A negative acknowledgement sent by the RM destination to the RM source, indicating a failed delivery prior to the completion of the sequence.

 

7.2.4. Delivery assurances

The nature of a sequence is determined by a set of reliability rules known as delivery assurances. Delivery assurances are predefined message delivery patterns that establish a set of reliability policies.

The following delivery assurances are supported:

The AtMostOnce delivery assurance promises the delivery of one or zero messages. If more than one of the same message is delivered, an error condition occurs (Figure 7.12).

Figure 7.12. The AtMostOnce delivery assurance.

The AtLeastOnce delivery assurance allows a message to be delivered once or several times. The delivery of zero messages creates an error condition (Figure 7.13).

Figure 7.13. The AtLeastOnce delivery assurance.

The ExactlyOnce delivery assurance guarantees that a message only will be delivered once. An error is raised if zero or duplicate messages are delivered (Figure 7.14).

Figure 7.14. The ExactlyOnce delivery assurance.

The InOrder delivery assurance is used to ensure that messages are delivered in a specific sequence (Figure 7.15). The delivery of messages out of sequence triggers an error. Note that this delivery assurance can be combined with any of the previously described assurances.

Figure 7.15. The InOrder delivery assurance.

 

7.2.5. Reliable messaging and addressing

WS-Addressing is closely tied to the WS-ReliableMessaging framework. In fact, it's interesting to note that the rules around the use of the WS-Addressing message id header were altered specifically to accommodate the WS-ReliableMessaging specification. Originally, message id values always had to be unique, regardless of the circumstance. However, the delivery assurances supported by WS-ReliableMessaging required the ability for services to retransmit identical messages in response to communication errors. The subsequent release of WS-Addressing, therefore, allowed retransmissions to use the same message ID.

7.2.6. Reliable messaging and SOA

Reliable messaging brings to service-oriented solutions a tangible quality of service (Figure 7.16). It introduces a flexible system that guarantees the delivery of message sequences supported by comprehensive fault reporting. This elevates the robustness of SOAP messaging implementations and eliminates the reliability concerns most often associated with any messaging frameworks.

Figure 7.16. Reliable messaging relating to other parts of SOA.

By increasing the delivery quality of SOAP messages, reliable messaging increases the quality of cross-application communication channels as well. The limitations of a messaging framework no longer inhibit the potential of establishing enterprise-level integration.

Case Study

To accommodate their existing accounting practices, RailCo sometimes prefers to issue bulk, month-end invoice submissions. TLS has other vendors that require this option and therefore accepts these forms of bulk submissionsbut under the condition that they must be transmitted as part of the same sequence. This gives TLS the ability to issue an acknowledgement that communicates which of the invoice messages were successfully received.

RailCo complies with this requirement and enhances its existing Invoice Submission Service to package invoices in SOAP messages that support reliable messaging extensions (Figure 7.17).

Figure 7.17. After transmitting a series of invoice messages, the last message within the sequence triggers the issuance of an acknowledgement message by TLS.

 

The first submitted batch consists of 15 invoices. Much to RailCo's dismay, upon transmitting the last message in the sequence, TLS issues an acknowledgement message indicating that only 11 of the 15 invoice messages were actually received. In preparation for subsequent bulk submissions, RailCo extends its Invoice Submission Service to issue an acknowledgement request message after every second invoice message sent as part of a sequence. This allows RailCo to better monitor and respond to failed delivery attempts.

Note

The passive Load Balancing Service displayed in Figure 7.17 does not verify or process reliability conditions. Messages are simply passed through to the destination Accounts Payable Service.

SUMMARY OF KEY POINTS

• WS-ReliableMessaging establishes a framework that guarantees the delivery of a SOAP message or the reporting of a failure condition.
• The key parts of this framework are a notification system based on the delivery of acknowledgement messages and a series of delivery assurances that provide policies comprised of reliability rules.
• WS-ReliableMessaging is closely associated with the WS-Addressing and WS-Policy specifications.
• Reliable messaging significantly increases SOA's quality of service level and broadens its interoperability potential.