JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle GlassFish Server Message Queue 4.5 Technical Overview
search filter icon
search icon

Document Information


1.  Messaging Systems: An Introduction

2.  Client Programming Model

Messaging Domains

Point-To-Point Messaging

Publish/Subscribe Messaging

Domain-Specific and Unified APIs

Programming Objects

Connection Factories and Connections



Message Header

Message Properties

Message Body

Producing a Message

Consuming a Message

Synchronous and Asynchronous Consumers

Using Selectors to Filter Messages

Using Durable Subscribers

The Request-Reply Pattern

Reliable Message Delivery



Local Transactions

Distributed Transactions

Persistent Storage

A Message's Journey Through the System

Message Production

Message Handling and Routing

Message Consumption

Message End-of-Life

Design and Performance

Working with SOAP Messages

Java and C Clients

3.  The Message Queue Broker

4.  Broker Clusters

5.  Message Queue and Java EE

A.  Message Queue Implementation of Optional JMS Functionality

B.  Message Queue Features



Messaging Domains

Messaging middleware allows components and applications to communicate by producing and consuming messages. The JMS API defines two patterns or messaging domains that govern this communication: point-to-point messaging and publish/subscribe messaging. The JMS API is organized to support these patterns. The basic JMS objects: connections, sessions, producers, consumers, destinations, and messages are used to specify messaging behavior in both domains.

Point-To-Point Messaging

In the point-to-point domain, message producers are called senders and consumers are called receivers. They exchange messages by means of a destination called a queue: senders produce messages to a queue; receivers consume messages from a queue. What distinguishes point-to-point messaging is that a message can be consumed by only one consumer.

Figure 2-1 shows the simplest messaging operation in the point-to-point domain. MyQueueSender sends Msg1 to the queue destination MyQueue1. Then, MyQueueReceiver obtains the message from MyQueue1.

Figure 2-1 Simple Point-to-Point Messaging

image:Message travels from sender to receiver via a queue destination. Figure described in text.

Figure 2-2 shows a more complex picture of point-to-point messaging to illustrate the possibilities offered by this domain. Two senders, MyQSender1 and MyQSender2, use the same connection to send messages to MyQueue1. MyQSender3 uses an additional connection to send messages to MyQueue1. On the receiving side, MyQReceiver1 consumes messages from MyQueue1, and MyQReceiver2 and MyQReceiver3, share a connection in order to consume messages from MyQueue1.

Note - Support for multiple-consumer queues is a Message Queue feature (the JMS specification defines messaging behavior in the case of only one consumer accessing a queue). When multiple consumers access a queue, the load-balancing among them takes into account each consumer’s capacity and message processing rate.

Figure 2-2 Complex Point-to-Point Messaging

image:Two senders use one connection to send messages to one receiver. Two consumers getting messages from same queue. Figure explained in text.

This more complex picture exemplifies a number of additional points about point-to-point messaging.

The point-to-point domain offers a number of advantages:

Publish/Subscribe Messaging

In the publish/subscribe domain, message producers are called publishers and message consumers are called subscribers. They exchange messages by means of a destination called a topic: publishers produce messages to a topic; subscribers subscribe to a topic and consume messages from a topic.

Figure 2-3 shows a simple messaging operation in the publish/subscribe domain. MyTopicPublisher publishes Msg1 to the destination MyTopic. Then, MyTopicSubscriber1 and MyTopicSubscriber2 each receive a copy of Msg1 from MyTopic.

Figure 2-3 Simple Publish/Subscribe Messaging

image:Figure shows one publisher sending the same message to two subscribers via a topic destination. Figure described in text.

While the publish/subscribe model does not require that there be more than one subscriber, two subscribers are shown in the figure to emphasize the fact that this domain allows you to broadcast messages. All subscribers to a topic get a copy of any message published to that topic.

Subscribers can be durable or non-durable. If a durable subscriber becomes inactive, the broker retains messages for it until the subscriber becomes active and consumes the messages. If a non-durable subscriber becomes inactive, the broker does not retain messages for it.

Figure 2-4 shows a more complex picture of publish/subscribe messaging to illustrate the possibilities offered by this domain. Several producers publish messages to the Topic1 destination. Several subscribers consume messages from the Topic1 destination. Unless, a subscriber is using a selector to filter messages, each subscriber gets all the messages published to the topic to which it is subscribed. In Figure 2-4, MyTSubscriber2 has filtered out Msg2.

Figure 2-4 Complex Publish/Subscribe Messaging

image:Figure shows three publishers sending messages to three subscribers via one topic destination. Figure described in text.

This more complex picture exemplifies a number of additional points about publish/subscribe messaging.

The main advantage of the publish/subscribe model is that it allows messages to be broadcast to multiple subscribers.

Domain-Specific and Unified APIs

The JMS API defines interfaces and classes that you can use to implement either of the point-to-point or the publish/subscribe domains. These are the domain-specific API’s shown in columns 2 and 3 of Table 2-1. The JMS API defines an additional unified domain, which allows you to program a generic messaging client. The behavior of such a client is determined by the type of the destination to which it produces messages and from which it consumes messages. If the destination is a queue, messaging will behave according to the point-to-point pattern; if the destination is a topic, messaging will behave according to the publish/subscribe pattern.

Table 2-1 JMS Programming Domains and Objects

Base Type(Unified Domain)
Point-to-Point Domain
Publish/Subscribe Domain
Destination (Queue or Topic)

The unified domain was introduced with JMS version 1.1. The domain-specific API also provides a clean programming interface that prevents certain types of programming errors: for example, creating a durable subscriber for a queue destination. However, the domain-specific APIs have the disadvantage that you cannot combine point-to-point and publish/subscribe operations in the same transaction or in the same session. If you need to do that, you should choose the unified domain API. See The Request-Reply Pattern for an example of combining the two domains.