We have been introducing the notion of guaranteed messaging in bits and pieces throughout the book. Until now, we have assumed that you would take our word that guaranteed messaging ensures that messages are faithfully delivered once-and-only-once to their intended consumers.
This chapter examines why guaranteed messaging works, and provides a thorough discussion of the subject. We will examine the message acknowledgment protocols that are part of guaranteed messaging, and how to use client acknowledgments in applications. We will explore the design patterns of JMS that enable you to build guaranteed messaging into applications, and discuss failure scenarios, the rules that apply to recovery, and how to deal with recovery semantics in a JMS application.
Guaranteed messaging is more than just a mechanism for handling disconnected consumers. It is a crucial part of the messaging paradigm, and is the key to understanding the design of a distributed messaging system. There are three main parts to guaranteed messaging: message autonomy, store-and-forward, and the underlying message acknowledgment semantics.
Before we discuss the parts of guaranteed messaging, we need to review and define some new terms. A JMS client application uses the JMS API. Each JMS vendor provides an implementation of the JMS API on the client, which we call the client runtime . In addition to the client runtime, the JMS vendor also provides some kind of message "server" that implements the routing and delivery of messages. The client runtime and the message server are collectively referred to as the JMS provider. Regardless of the architecture used by a JMS provider, the logical parts of a JMS system are the same. The number of processes and their location on the network is unimportant for this discussion. (In Chapter 7, we'll see that some providers use a multicast architecture in which there is no central server.) The upcoming sections make use of diagrams that describe the logical pieces, and do not necessarily reflect the process architecture of any particular JMS provider.
A provider failure refers to any failure condition that is outside of the domain of the application code. It could mean a hardware failure that occurs while the provider is entrusted with the processing of a message, or an unexpected exception, or the abnormal end of a process due to a software defect, or network failures.
Messages are self-contained autonomous entities. This fact needs to be foremost in your mind when designing a distributed messaging application. A message may be sent and resent many times across multiple processes throughout its lifetime. Each JMS client along the way will consume the message, examine it, execute business logic, modify it, or create new messages in order to accomplish the task at hand.
In a sense, a JMS client has a contract with the rest of the system: when it receives a message, it does its part of the processing, and may deliver the message (or new message) to another topic or queue. When a JMS client sends a message, it has done its job. The messaging server guarantees that any other interested parties will receive the messages. This contract between the sender and the message server is much like the contract between a JDBC client and a database. Once the data is delivered, it is considered "safe" and out of the hands of the client.
When messages are marked persistent , it is the responsibility of the JMS provider to utilize a store-and-forward mechanism to fulfill its contract with the sender. The storage mechanism is used for persisting messages to disk (or some other reliable medium) in order to ensure that the message can be recovered in the event of a provider failure or a failure of the consuming client. The implementation of the storage mechanism is up to the JMS provider. The messages may be stored centrally (as is the case with centralized architectures), or locally, with each sending or receiving client (the solution used by decentralized architectures). Some vendors use a flat-file storage mechanism, while others use a database. Some use an intelligent combination of both. The forwarding mechanism is responsible for retrieving messages from storage, and subsequently routing and delivering them.
JMS specifies a number of acknowledgment modes. These acknowledgments are a key part of guaranteed messaging. A message acknowledgment is part of the protocol that is established between the client runtime portion of the JMS provider and the server. Servers acknowledge the receipt of messages from JMS producers and JMS consumers acknowledge the receipt of messages from servers. The acknowledgment protocol allows the JMS provider to monitor the progress of a message so that it knows whether the message was successfully produced and consumed. With this information, the JMS provider can manage the distribution of messages and guarantee their delivery.