JMS Basics

Before you can jump to developing you first JMS application, you should first review the basics, or some might say the architecture. This chapter provides a high level architecture of a JMS system.

A Message Flow

The main purpose of the JMS API is to allow a message producer to create a message, send it to a JMS destination, and have a message consumer process the message. Figure 3.1 shows the basic message flow.

Frame1

It turns out that there are 2 different messaging models that a messaging provider can implement to deliver messages. The first is called the Point-to-Point Model and the second is called the Pub-Sub model. JMS providers must implement at least one of the two models. Most providers implement both models.

Since JMS provider do not need to implement both models, the JMS API has a different interface for each model. Tables 3.1 and 3.2 show you the interface class names uses in each model and their description.

Table 3.1 JMS classes used in the Point-to-Point model.

javax.jms Class Name

Description

QueueConnectionFactory

A configuration object that contains the information needed to establish a connection to the JMS server.

QueueConnection

Used to represent a connection to the JMS server. Multiple threads can share a single connection object.

QueueSession

A session object’s main purpose is to control the JMS transactions. Only one thread may use a session object.

Queue

Represents a queue on the JMS server.

TemporaryQueue

Same as a ‘queue’ but it’s lifespan is constrained by the lifespan of the client.

QueueReceiver

This is the message consumer used in the point-to-point model.

QueueSender

This is the message producer used in the point-to-point model.

QueueBrowser

This object is used to get a listing of messages waiting to be consumed on a queue. Browsing a message does not consume it.

Table 3.2 The JMS classes used in the Pub-Sub model.

javax.jms Class Name

Description

TopicConnectionFactory

A configuration object that contains the information needed to establish a connection to the JMS server.

TopicConnection

Used to represent a connection to the JMS server. Multiple threads can share a single connection object.

TopicSession

A session object’s main purpose is to control the JMS transactions. Only one thread may use a session object.

Topic

Represents a topic on the JMS server.

TemporaryQueue

Same as a ‘topic’ but it’s lifespan is constrained by the lifespan of the client.

TopicSubscriber

This is the message consumer used in the pub-sub model.

TopicPublisher

This is the message producer used in the pub-sub model.

Point-to-Point Model

The Point-to-Point model calls the destination objects ‘queues’. Queues are like mail boxes that can hold messages that message producers send to them. A consumer that is disconnected from the server can rest assured that it will not loose messages while it is disconnected. The messages will just sit in the queue until the consumer reconnects to the server.

Another important distinction about the Point-to-Point model is that if multiple consumers are receiving messages off a single queue, the results are JMS provider dependent. Most providers allow multiple consumers on a queue but all of them ensure that a single message will only be delivered to one consumer. Figure 2 shows a possible scenario of how messages might be delivered to two different consumers receiving messages from a single queue.

Frame2

Pub-Sub Model

The second type of model, the Pub-Sub model, calls the destination objects ‘topics’. The biggest difference between a topic and a queue is that while a message in queue will only be delivered to one consumer, a message sent to a topic will be delivered to all the consumers that have a subscription to the topic. In essence a topic ‘broadcasts’ a message to all of the active consumers.

The second biggest difference is that a topic will not hold messages like a queue. It is like a television broadcast. Many television viewers can tune into the same channel and catch the same show, but if you come home late, you will have missed the show. The same is true for topics. A consumer will miss messages that are sent to the topic while the consumer is shut down. Figure 3 show a possible scenario of how messages could be delivered to a set of consumers from a topic.

Frame3

A Consumer that needs to receive messages from a topic, but cannot loose messages due to down time, should establish a durable subscription. A durable subscription provides the message storage advantages of a queue while still receiving messages from a topic. Durable subscriptions are covered in more detail in chapter 3.6.7.