Java Message Service, 2nd Edition

Chapter 4. Point-to-Point Messaging

This chapter focuses on the point-to-point (p2p) messaging model. The point-to-point model is used when you need to send a message to only one message consumer. Even though multiple consumers may be listening on the queue for the same message, only one of those consumer threads will receive the message. This is different from the publish-and-subscribe model described in Chapter 5, where a message is broadcast to (and consumed by) multiple consumers.

In this chapter, we will describe the point-to-point model through the use of a typical messaging scenario involving a borrower and a mortgage lender. In our example, the QBorrower class will submit a loan application via JMS messaging to a QLender class. The QLender class will receive the loan request through a message queue, determine whether to accept or decline the loan based on certain business rules, and send the result (accept or decline) back to the QBorrower class through another message queue. However, before launching into the messaging example, we will first describe the main characteristics and use cases of the p2p messaging model.

Point-to-Point Overview

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 as follows:

• 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 to only one receiver. Multiple receivers may listen on 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 (unless message priority is used).

• 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.)

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.

As you will see in the next chapter, the pub/sub model is based on a push model, which means that consumers are delivered messages without having to request them. With the p2p messaging model, the p2p receiver 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 this chapter.

In the p2p 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 sent 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 also 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 no consumer is currently connected.

There are two types of point-to-point messaging: asynchronous fire-and-forget processing and asynchronous request/reply processing. With fire-and-forget processing, the message producer sends a message to a queue and does not expect to receive a response (at least not right away). This type of processing can be used to trigger an event or make a request to a receiver to execute a particular action that does not require a response (or in some cases, an immediate response). For instance, you may want to use asynchronous fire-and-forget processing to send a message to a logging system, make a request to kick off a report, or trigger an event on another process. Asynchronous fire-and-forget processing is illustrated in Figure 4-1.

Figure 4-1. p2p async fire-and-forget

With asynchronous request/reply processing, the message producer sends a message on one queue and then does a blocking wait on a reply queue waiting for the response from the receiver. The request/reply processing provides for a high degree of decoupling between the producer and consumer, allowing the message producer and consumer components to be heterogeneous languages or platforms. Asynchronous request/reply processing is illustrated in Figure 4-2.

Figure 4-2. p2p async request/reply

The specific p2p interfaces for connecting, creating, sending, and receiving are shown in Table 4-1.

Table 4-1. Interfaces for queues

General API	Point-to-point API
ConnectionFactory	QueueConnectionFactory
Destination	Queue
Connection	QueueConnection
Session	QueueSession
MessageConsumer	QueueSender
MessageProducer	QueueReceiver

When to Use Point-to-Point Messaging

The rationale behind the two models (point-to-point and publish-and-subscribe) 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.

In most cases, the decision about which model to use depends on the distinct characteristics 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 generally does not care how many subscribers there are or how many of them are actively listening on the topic. 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. In contrast, with point-to-point messaging, a particular message is likely to be intended for a one-on-one conversation with a specific application at the other end. In this scenario, every message matters.

Point-to-point is used 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 will process 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 take a snapshot of 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.

Another use case for point-to-point messaging is when you need synchronous communication between components, but those components are written in different programming languages or implemented in different technology platforms (e.g., J2EE and .NET). For example, you may have a stock trading client written as a Java Swing client that needs to communicate with a .NET/C# trading server to process the stock trade. In this scenario, point-to-point messaging can be used to provide the interoperability between these heterogeneous platforms.

As you will see later in this chapter, another good reason to use point-to-point messaging is to provide a higher degree of throughput to server-side components through the use of message-based load balancing, particularly for homogeneous components (i.e., Java to Java). Introducing p2p messaging allows you to add a degree of concurrent processing to your architecture without having to deal with threads or Java concurrency issues.