This chapter focuses on the point-to-point (p2p) messaging domain. Many of the concepts of p2p messaging are similar to those we learned in Chapter 4. To avoid redundancy, this chapter highlights the areas where the two models are the same, and focuses on the areas where the two models differ.
In the p2p model, the producer is called a sender and the consumer is called a receiver . The most important characteristics of the point-to-point model are:
Messages are exchanged through a virtual channel called a queue. A queue is a destination to which producers send messages, and a source from which receivers consume messages.
Each message is delivered only to one receiver. Multiple receivers may connect to a queue, but each message in the queue may only be consumed by one of the queue's receivers.
Messages are ordered. A queue delivers messages to consumers in the order they were placed in the queue by the message server. As messages are consumed they are removed from the head of the queue.
There is no coupling of the producers to the consumers. Receivers and senders can be added dynamically at runtime, allowing the system to grow or shrink in complexity over time. (This is a characteristic of messaging systems in general.)
In this chapter, we introduce new versions of our
Wholesaler and Retailer
classes, called QWholesaler and
QRetailer. QWholesaler still
uses pub/sub to broadcast price quotes, while
QRetailer uses a p2p queue to respond with
"buy" orders instead of publishing to a temporary topic.
The rest of the chapter focuses on the unique capabilities offered by
p2p: examining a queue using the QueueBrowser
interface, and load balancing among multiple recipients of a queue.
Like publish/subscribe messaging,
point-to-point messaging is based on the concept of sending a message
to a named destination. The actual network location of the
destination is transparent to the sender, because the p2p client
works with a Queue identifier obtained from a JNDI
namespace, the same way that a pub/sub client uses a
Topic identifier.
The pub/sub model is based on a push model, which means that
consumers are delivered messages without having to request them.
Messages are exchanged through a virtual channel called a topic. From
the viewpoint of the receiver, a p2p queue can either push or pull
messages, depending on whether it uses the asynchronous
onMessage( ) callback, or a synchronous
receive( ) method. Both of these methods are
explained in more detail later.
In the p2p model, as in the pub/sub model, there is no direct coupling of the producers to the consumers. The destination queue provides a virtual channel that decouples consumers from producers. In the pub/sub model, multiple consumers that subscribe to the same topic each receive their own copy of every message addressed to that topic. In the p2p model, multiple consumers can use the same queue, but each message delivered to the queue can only be received by one of the queue's consumers. How messages delivered to a queue are distributed to the queue's consumers depends on the policies of the JMS provider. Some JMS providers use load-balancing techniques to distribute messages evenly among consumers, while others will use more arbitrary policies.
Messages intended for a p2p queue can be either persistent or nonpersistent. Persistent messages survive JMS provider failures, while nonpersistent messages do not. Messages may have a priority and an expiration time. One important difference between point-to-point and publish/subscribe messaging is that p2p messages are always delivered, regardless of the current connection status of the receiver. Once a message is delivered to a queue, it stays there even if there is no consumer currently connected. More details on failure scenarios can be found in Chapter 6.
The interfaces for connecting, creating, sending and receiving are similar to the interfaces for topics, as shown in Table 5.1.
First, let's talk about why two distinct models exist. The rationale behind the two models lies in the origin of the JMS specification. JMS started out as a way of providing a common API for accessing existing messaging systems. At the time of its conception, some messaging vendors had a p2p model, and some had a pub/sub model. Hence JMS needed to provide an API for both models to gain wide industry support. The JMS 1.0.2 specification does not require a JMS provider to support both models, although most JMS vendors do.
Almost anything that can be done with the pub/sub model can be done with point-to-point, and vice versa. An analogy can be drawn to developers' programming language preferences. In theory, any application that can be written with Pascal can also be written with C. Anything that can be written in C++ can also be written in Java. In some cases it comes down to a matter of preference, or which model you are already familiar with.
In most cases, the decision about which model to use depends on the
distinct merits of each model. With pub/sub, any number of
subscribers can be listening on a topic, all receiving copies of the
same message. The publisher may not care if everybody is listening,
or even if nobody is listening. For example, consider a publisher
that broadcasts stock quotes. If any particular subscriber is not
currently connected and misses out on a great quote, the publisher is
not concerned. Likewise, our Wholesaler class
didn't care whether there were any subscribers when it sent
price quotes: if a Retailer missed a great price,
that wasn't the Wholesaler's problem.
In contrast, a point-to-point session is likely to be intended for a
one-on-one conversation with a specific application at the other end.
In this scenario, every message really matters.
The range and variety of the data that the messages represent can be
a factor as well. Using pub/sub, messages are dispatched to the
consumers based on filtering that is provided through the use of
specific topics. Even when messaging is being used to establish a
one-on-one conversation with another known application, it can be
advantageous to use pub/sub with multiple topics to segregate
different kinds of messages. Each kind of message can be dealt with
separately through its own unique consumer and onMessage(
) handler.
Point-to-point is more convenient when you want one receiver to
process any given message once-and-only-once. This is perhaps the
most critical difference between the two models: point-to-point
guarantees that only one consumer processes a given message. This is
extremely important when messages need to be processed separately but
in tandem, balancing the load of message processing across many JMS
clients. Another advantage is that the
point-to-point model provides a
QueueBrowser that allows the JMS client to peek
ahead on the queue to see messages waiting to be consumed. Pub/sub
does not include a browsing feature. We'll talk more about the
QueueBrowser later in this chapter.