| A common misconception regarding publish-and-subscribe versus point-to-point messaging queuing is that pub/sub is for lightweight, unreliable messaging and point-to-point queuing is more heavyweight and reliable. That may have been true a decade ago, when there were really only two messaging vendors: one that supported lightweight pub/sub and one that supported heavyweight, reliable point-to-point queues. Since then, however, many new messaging vendors have come onto the market supporting both messaging models, each with its own full range of QoS options. In addition, these reliable messaging techniques can be utilized across some potentially sophisticated deployment topologies. 5.4.1 Reliable Publish-and-Subscribe A pub/sub message can be delivered just as reliably as a point-to-point message can. A message delivered on a point-to-point queue can be delivered with little additional overhead if it is not marked as being persistent. A reliable pub/sub message is delivered using a combination of persistent messages and durable subscriptions (a common term in JMS parlance). When an application registers its interest in receiving messages on a particular topic, it can specify that the subscription is durable. A durable subscription will survive the failure of the subscribing client. This means that if the intended receiver of a message becomes unavailable for any reason, the message server will continue to store messages on behalf of the receiver until the receiver becomes available again. When the receiver reestablishes its subscription with the messaging system, the stored messages will be delivered. Figure 5-12. Reliable publish-and-subscribe involves message acknowledgments, message persistence, and durable subscriptions Figure 5-11 shows the steps involved with delivering a pub/sub message using persistent messaging and a durable subscription. The subscriber subscribes and indicates that the subscription is durable. The subscriber disconnects from the message server, either through a graceful shutdown or through some kind of a failure. The publisher sends the message using a publish( ) method. The publish( ) method will block and wait until it receives an acknowledgment from the message server. The message server writes the message out to a reliable, persistent storage device. The message is held reliably on disk. An acknowledgment is sent back to the sender indicating that the message is now safe in the hands of the message server. The publish( ) method returns. The subscriber reconnects and reestablishes the subscription. The message is retrieved from the persistent store. The message is delivered to the subscriber. The subscriber acknowledges to the message server that it has successfully received the message. The message server removes the message from the persistent store.
5.4.2 Reliable Point-to-Point Queues For point-to-point queues, messages are marked by the producer as either persistent or nonpersistent. If they are persistent, they are written to disk and subject to the same acknowledgment rules, failure conditions, and recovery as persistent messages in the publish/subscribe model. From the receiver's perspective, the rules are somewhat simpler than with durable subscriptions because the receiver has no role in the durability aspect. With point-to-point queues, because only one consumer can receive a particular instance of a message, it's in the queue as either a persistent message or a nonpersistent message. A persistent message stays in the queue and on disk until it is delivered to a consumer or it expires. A nonpersistent message also stays in the queue until it is delivered or expired, but it is not guaranteed to survive a failure and recovery of the messaging server. The receipt of the message is also subject to the same acknowledgment rules and recovery from failure conditions as with the pub/sub model once a persistent message is delivered to the consuming application and an acknowledgment is sent back to the message server, the message can be removed from persistent storage. If something fails during that process, the message will be redelivered during recovery. 5.4.3 Store-and-Forward Across Multiple Message Servers In an ESB MOM core, the concept of store-and-forward should be capable of being repeated across multiple message servers that are chained together. In this scenario, each message server uses store-and-forward and message acknowledgments to get the message to the next server in the chain (Figure 5-12). Figure 5-13. Reliable delivery across multiple message servers using store-and-forward and message acknowledgments Each server-to-server handoff maintains the minimum reliability and QoS that were specified by the sender. This is all done in a fashion that is transparent to both the sender and the receiver. The chain of message servers may not always form a straight line. Depending on the implementation, sophisticated and dynamic routing may be possible that directs each message to remote locations across a different path of servers based on routing information that is associated with the destination (Figure 5-13). Figure 5-14. Dynamic routing of reliable messages across secure links As illustrated in Figure 5-13, these links can be secure, authenticated, and capable of traversing safely through firewall boundaries using mutually authenticated channels with digital certificates on both sides of the communication link, ensuring that only the most secure link can be established through the corporate firewalls. |