JMS supports two types of messaging models: point-to-point and publish-and-subscribe. These messaging models are sometimes referred to as messaging domains. Point-to-point messaging and publish-and-subscribe messaging are frequently shortened to p2p and pub/sub, respectively. This book uses both the long and short forms throughout.
In the simplest sense, publish-and-subscribe is intended for a one-to-many broadcast of messages, while point-to-point is intended for one-to-one delivery of messages (see Figure 1-4).
From a JMS perspective, messaging clients are called JMS clients, and the messaging system 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 message producer, while a JMS client that receives a message is called a message consumer. A JMS client can be both a message producer and a message 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.
The point-to-point messaging model allows JMS clients to send and receive messages both synchronously and asynchronously via virtual channels known as queues. In the point-to-point model, message producers are called senders and message consumers are called receivers. The point-to-point messaging model has traditionally been a pull-based or polling-based model, where messages are requested from the queue instead of being pushed to the client automatically. One of the distinguishing characteristics of point-to-point messaging is that messages sent to a queue are received by one and only one receiver, even though there may be many receivers listening on a queue for the same message.
Point-to-point messaging supports asynchronous “fire and forget” messaging as well as synchronous request/reply messaging. Point-to-point messaging tends to be more coupled than the publish-and-subscribe model in that the sender generally knows how the message is going to be used and who is going to receive it. For example, a sender may send a stock trade order to a queue and wait for a response containing the trade confirmation number. In this case, the message sender knows that the message receiver is going to process the trade order. Another example would be an asynchronous request to generate a long-running report. The sender makes the request for the report, and when the report is ready, a notification message is sent to the sender. In this case, the sender knows the message receiver is going to pick up the message and create the report.
The point-to-point model supports load balancing, which allows multiple receivers to listen on the same queue, therefore distributing the load. As shown in Figure 1-4, the JMS provider takes care of managing the queue, ensuring 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. Point-to-point 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 publish-and-subscribe model. The point-to-point messaging model is covered in more detail in Chapter 4.
In the publish-and-subscribe model, messages are published to a virtual channel called a topic. Message producers are called publishers, whereas message consumers are called subscribers. Unlike the point-to-point model, messages published to a topic using the publish-and-subscribe model can be received by multiple subscribers. This technique is sometimes referred to as broadcasting a message. Every subscriber receives a copy of each message. The publish-and-subscribe 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.
The pub/sub model tends to be more decoupled than the p2p model in that the message publisher is generally unaware of how many subscribers there are or what those subscribers do with the message. For example, suppose a message is published to a topic every time an exception occurs in a Java application. The responsibility of the publisher is to simply broadcast that an exception occurred. The publisher does not know or generally care how that message will be used. For example, there may be subscribers that send an email to the development or support staff based on the exception, subscribers that accumulate counts of the various types of exceptions for reporting purposes, or even subscribers that use the information to page an on-call support person based on the exception type.
There are many different types of subscribers within the pub/sub messaging model. Nondurable subscribers are temporary subscriptions that receive messages only when they are actively listening on the topic. Durable subscribers, on the other hand, will receive a copy of every message published, even if they are “offline” when the message is published. There is also the notion of dynamic durable subscribers and administered durable subscribers. The publish-and-subscribe messaging model is discussed in greater detail in Chapters 2 and 5.
Get Java Message Service, 2nd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
