- Addressing
- Reliable Messaging
- Correlation
- Policies
- Metadata Exchange
- Security
- Notification and Eventing
This chapter is from the book
This chapter is from the book
This chapter is from the book
7.2 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.
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).
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.13 The AtLeastOnce delivery assurance.
)
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.
)
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.
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.