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:
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:
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.
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.
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.
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.
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.
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
Part I: SOA and Web Services Fundamentals
The Evolution of SOA
Web Services and Primitive SOA
Part II: SOA and WS-* Extensions
Web Services and Contemporary SOA (Part I: Activity Management and Composition)
Web Services and Contemporary SOA (Part II: Advanced Messaging, Metadata, and Security)
Part III: SOA and Service-Orientation
Principles of Service-Orientation
Part IV: Building SOA (Planning and Analysis)
SOA Delivery Strategies
Service-Oriented Analysis (Part I: Introduction)
Service-Oriented Analysis (Part II: Service Modeling)
Part V: Building SOA (Technology and Design)
Service-Oriented Design (Part I: Introduction)
Service-Oriented Design (Part II: SOA Composition Guidelines)
Service-Oriented Design (Part III: Service Design)
Service-Oriented Design (Part IV: Business Process Design)
Fundamental WS-* Extensions
Appendix A. Case Studies: Conclusion