O'Reilly - Java Message Service

Java Message Service
Chapter 6. Guaranteed Messaging, Transactions,
Acknowledgments, and Failures
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.
6.1 Guaranteed Messaging
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.
6.1.1 Message Autonomy
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.
84