Fuse Message Broker

Exploring JMS

Version 5.5

Febuary 2012
Trademark Disclaimer
Third Party Acknowledgements

Updated: 27 Mar 2014

Table of Contents

1. Introduction
2. Concepts in JMS Messaging
Overview
Messaging Models
Connections
Creating Sessions on the Connection
Creating Producers and Consumers in a Session
Message Producers
Message Consumers
Creating Messages
Creating a Destination (Topic or Queue)
Publish and Subscribe Messaging: Broadcast the Message
Point-to-point Messaging: Each Message Has One Consumer
3. Setting Up the Guided Tour
4. Publish and Subscribe Messaging Samples
Chat Application
DurableChat Application
HierarchicalChat Application
MessageMonitor Application
SelectorChat Application
TransactedChat Application
5. Point-to-Point Messaging Samples
Talk Application
The QueueMonitor Application
SelectorTalk Application
TransactedTalk Application
6. Request and Reply Samples
Request and Reply (Pub/Sub)
Request and Reply (PTP)
7. Queue Test Loop Sample
8. Changing Parameters and Modifying Source Code
Revising Parameters in the Build File
Analyzing and Modifying the Java Source Files
Index

List of Figures

2.1. JMS Sequence Diagram
2.2. JMS Session on a Connection
2.3. Producer and consumer sessions on a connection
2.4. Concept of Publish and Subscribe Messaging Topics
2.5. Publishing Messages to Topics for Subscribers
2.6. Sending Messages to Queues for Receivers
2.7. Features of Point-to-point messaging

The book is broken into three sections:

  1. Concepts in JMS Messaging describes the basic concepts used when developing JMS applications.

  2. Setting Up the Guided Tour through Queue Test Loop Sample are samples that demonstrate the basic JMS concepts.

  3. Changing Parameters and Modifying Source Code describes different ways you can modify the samples to further explore JMS.

The samples demonstrate the basic JMS features, as follows:

  • publish and subscribe messaging—Messages are published to a destination and multiple consumers can subscribe to receive the messages.

  • point-to-point messaging—Messages are published to a destination and a single consumer can receive the message.

  • request and reply—The initiator of the transaction expects a reply to its message.

  • test loop—This sample shows how quickly messages can be sent and received in a test loop.

A message producer packages and encrypts the message body, sets the service level and protection for the outbound message, and then sends the message to its destination. If the delivery mode is PERSISTENT, the message will be placed in the broker’s log or message store before starting delivery.

Message producers can set a time to live for each message. The calculated expiration time keeps a message in the queue until it expires. Expired messages are discarded.

Request/Reply

An application can use a request/reply mechanism to send a message and then wait for a response. The client application creates a temporary destination to receive the reply.

Quality of Service

Quality of Service refers to message delivery configuration that a producer specifies. Generally, Quality of Service affects the availability, reliability, scalability, and performance of message delivery. Loose Quality of Service uses a minimum number of features to maximize performance. A tighter Quality of Service uses multiple features, such as fault tolerant client connections, acknowledgements, and duplication elimination to maximize reliability, availability and transactional integrity.

For example, a loose Quality of Service might be used by a stock ticker application that wants to publish messages to a large number of subscribers to be consumed immediately. Since there are no security concerns and the information is time-sensitive, performance is at a premium. In contrast, a tight Quality of Service might be used for an online stock purchasing system, in which the company hosting the system wants to ensure transactional integrity, confidentiality, and reliability for all stock purchase transactions.

Quality of Service is supported by the following session options and message producer parameters:

In the Publish and Subscribe (Pub/Sub) messaging model, one client application can send a message to many other client applications. In the Pub/Sub model, a message producer is a publisher and a consumer is a subscriber .


This illustration shows three subscribers who have each received message A and are about to receive message B, and then message C:

  • Client application 1, a synchronous subscriber, waits for a message, for a specified time or forever, and then blocks to receive again after processing a message.

  • Client application 2, a durable subscriber specified an interest in receiving messages from the broker on the selected topic, even when disconnected. Messages are saved for durable subscribers, although a saved message can expire while waiting for the durable subscriber to reconnect.

  • Client application 3, an asynchronous subscriber has set up a message listener. When a message arrives, the onMessage method in the client is called. Although it is not shown in the illustration, this subscriber has a message selector. The subscriber provided a string in SQL syntax as a parameter when the subscription was created. If the selection criteria are not met, the subscriber does not take delivery of that message.

The following illustration shows the distribution of message delivery. The shapes on the publisher lines indicate messages published to specific topics over time. The crossovers within the broker represent the subscriptions that could have wildcard patterns so a single subscription delivers messages from many topics. The shapes on the subscriber lines indicate that everyone subscribed to a topic receives the same message at the same time. The exception is the durable subscription that, when not active, can receive its messages later, provided the messages do not expire.


The Point-to-point (PTP) messaging model ensures that a message is delivered only once to a single consumer. The following illustration shows three message producers sending messages to three different queues. Queues are defined with a maximum size and a threshold that indicates at what point to persist messages on the queue in the data store. If messages are taken off the queue at the same rate they are placed on the queue, then no messages are persisted.


In the diagram, Producer 2 sends a message to QueueB, which has three registered listeners. Because only one receiver will receive this message, the broker decides to let Consumer B1 receive the message. The other consumers do not receive that message.

Each message producer sends new messages to a queue, a destination on the broker. The broker, unless advised that there is a request for priority treatment, places new messages at the back of the queue. Consumer A takes the frontmost message off Queue A.

On Queue B, multiple consumers are listening to the queue, but only one consumer receives the message, Consumer B1. The QueueBrowser is browsing the queue without taking messages off the queue.

Queues are useful for load-balancing when many diverse systems share processing operations because additional receivers can be used to keep queue processing current. For example, applications for trading activities, credit card charges, online shopping carts, auctions, reservations, and ticketing often use queues.

Characteristics of the Point-to-point messaging model include:

  • The first message received by the broker is the first message delivered. This “First In, First Out” (FIFO) technique makes the second through nth messages endure until that first message is consumed. (Note that mixed priority settings on messages affect FIFO.)

  • Even when no clients specify an interest in receiving messages from a queue, messages wait for a consumer until the message expires.

  • When a message’s delivery mode is set to PERSISTENT, the message is stored so that even a broker shutdown will not put the message at risk.

  • There is only one message consumer for a given message. Many consumers can listen or receive on a queue, but only one takes delivery of a specific message.

  • When the message is acknowledged as delivered by the consumer, it is removed from the queue permanently. No one else sees it and no one else receives it.

The following illustration shows other features in Fuse Message Broker Point-to-point messaging.


The messages in this illustration are being received from the queue by three consumers:

  • Client Application 1,with a prefetch count of 2, took messages A and B off the queue. Message B is held in the prefetch buffer while message A is processed. When message B enters processing, the threshold trigger causes the consumer to draw off two more messages. The broker keeps track of unacknowledged messages and, if acknowledgement is not received before the session closes, the unacknowledged messages are reinstated in the queue.

  • Client Application 2, consuming with a message selector, reviews qualified messages on the queue to filter the messages that it wants to process. In this example, the consumer selected and acknowledged messages C and D. Assuming message F does not meet its criteria, this consumer perceives a momentarily empty queue.

  • Client Application 3, a synchronous consumer, receives a message, acknowledges its receipt, processes the message, and then waits to receive another message. The queue state indicates that message E was the frontmost message because messages A and B, while still in the queue, are awaiting acknowledgement from another consumer.

  • Client Application 4, a message producer, has sent message G to the queue and is in the process of sending message H.

The sample applications in the next chapter provide exercises that let you observe JMS messaging behaviors in both JMS messaging models.

Loosely coupled applications require special techniques when it is important for the publisher to certify that a message was delivered in either messaging domain:

  • Publish and Subscribe — While the publisher can send long-lived messages to durable receivers and get acknowledgement from the broker, neither of these techniques confirms that a message was actually delivered or how many, if any, subscribers received the message.

  • Point-to-point — While a sender can see if a message was removed from a queue, implying that it was delivered, there is no indication where it went.

A message producer can request a reply when a message is sent. A common way to do this is to set up a temporary destination and header information that the consumer can use to create a reply to the sender of the original message.

In both request and reply samples, the replier's task is a simple data processing exercise: standardize the case of the text sent/receive text and send back the same text as either all uppercase characters or all lowercase characters—then publish the modified message to the temporary destination that was set up for the reply.

While request-and-reply provides proof of delivery, it is a blocking transaction—the requestor waits until the reply arrives. While this situation might be appropriate for a system that, for example, issues lottery tickets, it might be preferable in other situations to have a formally established return destination that echoes the original message and a correlation identifier—a designated identifier that certifies that each reply is referred to its original requestor.

The sample applications use JMS sample classes TopicRequestor and QueueRequestor. You should create the Request/Reply helper classes that are appropriate for your application.

These request and reply samples show that request/reply mechanisms are very similar across messaging models, and that, while there might be zero or many subscriber replies, there will be, at most, one PTP reply.

The JMS samples are compiled and run using the Apache Ant build tool, where the Ant build file, build.xml, defines the rules for building the samples in a platform-independent manner. We now explore some ways of modifying and customizing the samples, as follows:

At this point in exploring JMS, the broker used by the samples is always on the computer where the sample applications run. While you might use a local or an embedded broker, JMS messaging is designed so that the sample applications can run on a computer that has the appropriate libraries, yet can connect to a broker on a different system to produce and consume messages. The standalone broker system would typically be in a location where it can be monitored and provided resources that ensure optimal availability to any applications that use it.

The sample applications provide a -b parameter to specify the protocol, host, and port of the preferred broker. As the default broker configuration specifies the TCP protocol on localhost, listening on port 61616, you can use another installation of the Java, Fuse Message Broker, Ant, and the Exploring JMS files (as described in the previous chapter) on another computer to experience distributed connection. On one host set up and start the broker. On the other host (the remote host), do the same.

Stop the broker on the remote host, then modify the build.xml file on the remote host to add the connection parameter and specify the host name where the broker is running. For example:

<target name="chat1">
  <java classname="Chat" ... >
    ...
    <arg value="-u"/>
    <arg value="Fred"/>
    <arg value="-b"/>
    <arg value="tcp://remoteHostName:61616"/>
  </java>
</target>

Save the build file and then run chat1 in a sample window on each of the computers. When you enter messages in either Chatter_1 window, the subscribers both get the message from the same broker.