O'Reilly - Java Message Service

Java Message Service
Messaging clients in JMS are called JMS clients, and the messaging system - the MOM - is
called the JMS provider. A JMS application is a business system composed of many JMS
clients and, generally, one JMS provider.
In addition, a JMS client that produces a message is called a producer, while a JMS client
that receives a message is called a consumer. A JMS client can be both a producer and a
consumer. When we use the term consumer or producer, we mean a JMS client that
consumes messages or produces messages, respectively. We use this terminology
throughout the book.
1.2.1.1 Publish-and-subscribe
In pub/sub, one producer can send a message to many consumers through a virtual channel
called a topic. Consumers, which receive messages, can choose to subscribe to a topic.
Any messages addressed to a topic are delivered to all the topic's consumers. Every
consumer receives a copy of each message. The pub/sub messaging model is by and large
a push-based model, where messages are automatically broadcast to consumers without
them having to request or poll the topic for new messages.
In the pub/sub messaging model the producer sending the message is not dependent on the
consumers receiving the message. Optionally, JMS clients that use pub/sub can establish
durable subscriptions that allow consumers to disconnect and later reconnect and collect
messages that were published while they were disconnected. The pub/sub JMS messaging
model is discussed in greater detail in Chapter 2, and Chapter 4.
1.2.1.2 Point-to-point
The point-to-point messaging model allows JMS clients to send and receive messages both
synchronously and asynchronously via virtual channels known as queues. The p2p
messaging model has traditionally been a pull- or polling-based model, where messages
are requested from the queue instead of being pushed to the client automatically. In JMS,
however, an option exists that allows p2p clients to use a push model similar to pub/sub.
A given queue may have multiple receivers, but only one receiver may consume each
message. As shown in Figure 1.4, the JMS provider takes care of doling out the work,
insuring that each message is consumed once and only once by the next available receiver
in the group. The JMS specification does not dictate the rules for distributing messages
among multiple receivers, although some JMS vendors have chosen to implement this as a
load balancing capability. P2p also offers other features, such as a queue browser that
allows a client to view the contents of a queue prior to consuming its messages - this
browser concept is not available in the pub/sub model. The p2p messaging model is
covered in more detail in Chapter 5.
1.3 Application Scenarios
Until now, our discussion of enterprise messaging has been somewhat abstract. This
section attempts to give some real-world scenarios to provide you with a better idea of the
types of problems that enterprise messaging systems can solve.
11