Read an Excerpt
Chapter 5: Publish/Subscribe MessagingPublish/Subscribe (Pub/Sub) messaging in JMS is based on the concept of topics. The destination in the Pub/Sub domain model is the topic and message producers publish messages to a specified topic. Message consumers subscribe for messages from the topic and receive the messages from the topic when they become available.
Every topic can have multiple publishers (message producers) or subscribers (message consumers) and every message published is received by all the subscribers. Therefore, unlike the Point-to-Point (PTP) messaging model, multiple subscribers will receive the same message that was published to that topic. These messages can either be persistent or non-persistent. If they are non-persistent, they are not stored in a persistent storage (like a database). This means, they may be lost if the messaging server were to crash. However, persistent messages are not even considered sent before they are stored in the persistent store. The JMS specification dictates that the messaging system guarantees to deliver a persistent message at least once.
What we'll learn in this chapter:
- We'll start off with a discussion on topics, including a look at Quality of Service in JMS applications.
- Then we'll move on to see how to set up our software environment to start coding Pub/Sub applications.
- After configuring our JMS server, we'll move on to developing a retail stock brokerage application, which provides ample opportunities for us to explore Pub/Sub messaging and transactions.
- While we develop our stock brokerage example, we will also learn about the key JMS Pub/Sub features.
TopicsMessaging server administrators explicitly create topics so that publishers and subscribers can exchange messages. The message producers in this domain model are called publishers and message consumers are referred to as subscribers. Publishers send messages to the topics for subscribers to consume.
The publisher declares the Quality of Service (QoS) while sending the message by setting the delivery mode, the time-to-live, and the message priority. The publisher also specifies whether a reply is requested from the subscriber. The messaging server records these items in its internal buffers, acknowledges receipt of the message to the publisher, and sends off the message to all the registered subscribers of the topic.
Quality of Service (QoS)JMS supports two types of message delivery:
- Reliable message delivery
- Guaranteed message delivery Each of these offers a different level of Quality of Service
With this type of delivery mode (DeliveryMode.NON_PERSISTENT), the messaging server will deliver a message to its subscribing client as long as there are no application or network failures. Delivery would fail if some disruption were to occur. This is referred to as "At-Most-Once-Delivery". The default QoS level in JMS is reliable delivery.
Delivery of NON_PERSISTENT messages is attempted only once. If the client does not receive the message for any reason (either the server's internal buffer overflowed, or the client crashed, etc.), these NON_PERSISTENT messages are lost as shown in the figure below...
However, in the next scenario, assume that we have a message sent with NON_PERSISTENT delivery mode and a durable subscriber/receiver. In this situation, the scenario is as follows and is also represented diagrammatically in the figure below:
- The message producer sends or publishes a message to the destination.
- An acknowledgement for the message is sent back to the producer.
- The messaging server realizes that there are durable subscribers that have not received the message and stores the message in its internal store.
- A provider failure occurs – either the server's internal buffer overflowed, or the client crashed, etc.
- Since the delivery mode for the message was NON_PERSISTENT, even though there are durable consumers, the message is lost.
With this type of delivery mode (DeliveryMode.PERSISTENT), the messaging server will deliver a message even if there are application or network failures. The messaging server will store the message in its persistent store and then forward the message to its subscribing clients. After the client processes the message, it sends an acknowledgement to the messaging server and verifies the receipt of the message as shown below...