Section 10.2. Reliable Messaging Scenarios

10.2. Reliable Messaging Scenarios

Considering the issues highlighted by the previous elaborated fallacies, various strategies are available for designing a more robust and reliable system.

10.2.1. Store and Forward

In many scenarios in highly distributed systems, the best you can hope to achieve is to get information closer to its intended destination. This allows for more efficient use of the network resources and decouples the initial sender and intended recipient such that they do not need to be running concurrently. In other words, the sending system does not need to be running when the receiving node receives and processes the information, and the receiving node does not need to be running when the sending node transmits the information in the first place.

E-mail is at its essence a store-and-forward system. When you send an e-mail, it typically is transmitted first to your Internet service provider (ISP), where it is stored on disk. Then the ISP's sendmail server transmits the message to a server that is closer yet to the intended recipient (for example, the sendmail server at the intended recipient's ISP). Eventually, the intended recipient logs into her ISP and retrieves all new e-mail messages that have arrived. If any of the distributed components along the e-mail's message path is unavailable, the node at which the message is currently located attempts to retransmit the message later until such time as the message transmission, or hop, is successful.

10.2.2. Batch Window

This scenario is a derivative of the store-and-forward scenario discussed in the previous section. Consider two trading partners who want to exchange purchase orders reliably. One uses a batch system to process orders, and the other uses an online system that processes them in near real time. Clearly, there's an impedance mismatch between the two partners' systems. The partner with the batch order processing system might be in no position to rip and replace its existing batch system for any number of valid reasons, both business and technical.

An effective strategy for dealing with this impedance mismatch is to interpose a store-and-forward architecture between the two systems. You can employ this architecture at either partner or at both. The impedance mismatch is mitigated by virtue of the fact that the messages transmitted as individual messages can be collected into a batch for processing. The converse is also true. Neither side needs to be concerned with the fact that its counterpart has a different processing design.

10.2.3. Failure Recovery

Another scenario is that of failure recovery. Consider two trading partners that have been exchanging order information over time. One suffers a catastrophic failure of its order management system and has to recover from the previous evening's backup. That partner has lost all the orders that it has received since the backup from which it recovered was performed, and it must find some way of resynchronizing its system with that of its trading partner. Similarly, the partner whose system did not fail has an interest in having its trading partner fulfill all the orders that it has sent. Although the two partners could manually reconcile their systems, a manual reconciliation does not scale to scenarios that involve several trading partners. Had the partners been using a protocol that reliably exchanged messages that leveraged a persistent store and a capability to redeliver messages that had previously been acknowledged, they might be able to recover from such a failure in an automated manner, saving time and money in the process.

10.2.4. Long-Running Transactions

People often use atomic transactions with two or or three-phase commit strategies when designing distributed systems to ensure that the distributed components of the system have a consistent view of their shared state.

However, in many scenarios, use of a transaction processing monitor is not practical. You would never consider locking resources for extended periods necessary for completion of something as long running as a purchase order life cycle. Further, because of security considerations, you would never think twice about letting an external party place locks on your system's resources; that party could easily mount a denial-of-service (DoS) attack that could cripple your systems.

Using a reliable messaging protocol, paired with a protocol such as WS-Business Activity, to manage the compensation of application-level faults, you can overcome these concerns while enabling a more reliable interaction. The reliable messaging protocol ensures the dependable delivery of the messages, and the application-level compensation ensures that the long-running transaction either completes successfully or suitably compensates any failure.