Topics

Messaging 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. The client application configures the type of message delivery when it publishes the message to its destination by specifying the delivery mode as a parameter.

Reliable Messaging

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:

click to expand

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.

click to expand

Guaranteed Messaging

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:

click to expand

The messaging server will redeliver a message to each client that has not acknowledged receipt of the message. This is referred to as "Once-and-Only-Once-Delivery" since the messaging system ensures that all subscribers get the message just once.

However, if the server cannot deliver the message at all (in other words, the address is bad, the recipient is never awake, the recipent keeps erroring out whenever it tries to receive a message) the message is kept in the persistent store until the time-to-live value is exceeded. As soon as the time-to-live time is reached, the messaging server declares the guaranteed message undeliverable by discarding or deleting the message from the its persistent store.

Guaranteed Delivery for Message Producers

Producer clients can specify guaranteed delivery by sending messages to a topic or queue and specifying PERSISTENT delivery of messages. The code to produce PERSISTENT messages is reproduced below:

       publisher.publish (bytesMessage,                          DeliveryMode.PERSISTENT,                          Message.DEFAULT_PRIORITY, 0); 

The following scenario describes a situation where the message is sent out with a delivery mode of PERSISTENT, and a provider failure occurs. The consumers may be either durable or non-durable:

  • The message producer sends or publishes a PERSISTENT message to the destination

  • Since the message is sent with delivery mode PERSISTENT, it is saved in the persistent store of the messaging provider

  • An acknowledgement is then sent back to the message producer

  • At this time, something goes wrong and the server crashes

The figure below also represents this scenario diagrammatically:

click to expand

Since the message is declared PERSISTENT, as soon as the messaging server recovers, the delivery is re-attempted. The scenarios are described below:

  • The messaging server recovers from the failure

  • It recovers the message that was stored in the persistent store to try to deliver it to all consumers

  • It sends out the message to all consumers

  • The consumers respond with an acknowledgement to indicate successful receipt of the message

  • The messaging server removes the message from its persistent store

The figure below also represents this scenario diagrammatically:

click to expand

Guaranteed Delivery for Message Consumers

Consuming clients can specify guaranteed delivery by subscribing to a topic or receiving from a queue with a durable subscription. The code to subscribe durably to a destination is detailed below:

       subscriber = session.createDurableSubscriber(topic,                                                    "AccountsDepartment"); 

The following scenario describes a situation where a PERSISTENT message is sent out and a failure happens at a durable subscriber end:

  • The message producer creates and publishes or sends a PERSISTENT message to the destination.

  • At the destination, the message is stored in the persistent store.

  • An acknowledgement for the message is then sent back to the producer.

  • The server then tries to send the message to all its subscribers.

  • While acknowledging the message the client durable subscriber crashes.

The scenario is also represented diagrammatically in the figure below:

click to expand

In this scenario, since the message was sent out with a delivery mode of PERSISTENT, the message is safely stored away in the persistent store and is not lost. Therefore, whenever the client comes up, and asks for messages to the destination, the PERSISTENT messages intended for that client can be recovered from the persistent store and sent back to it with the redeliveryCount set to True.

The following scenario describes how the message is redelivered to the durable subscriber in spite of the client failure:

  • The durable messaging client recovers and asks delivery of messages.

  • The messaging server retrieves the message from the persistent store.

  • It redelivers the message with the redeliveryCount set to True.

  • The subscriber then acknowledges receipt of the message.

The scenario is also represented diagrammatically in the figure below:

click to expand

Therefore, if you want to ensure absolutely guaranteed delivery of your messages under all circumstances, your applications should always publish persistent messages with a time-to-live of forever (value of 0), and all your subscriptions should be durable.

Pub/Sub Semantics

The figure below shows message publishers publishing messages by sending them to topics and all the message subscribers who had registered to the topic for messages receiving them as soon as the publisher makes them available at the topic:

click to expand

The figure above describes how Pub/Sub semantics work:

  • Publishers publish messages to specific topics.

  • The messaging server keeps track of all the messages, and all its current active and durable subscribers, and also provides a secure environment for the messaging system by handling authorization and authentication.

  • As soon as messages are published on the topic, they are distributed to all its subscribers. Durable subscribers, who were not connected at the time of message delivery, can retrieve the messages if they come up within a specified time.

After the messages have been delivered, the messaging server checks to see if there are any durable subscribers (subscribers who specifically expressed a durable interest in the topic) subscribed to this topic. If, after the initial delivery, any of the durable subscribers did not acknowledge receipt of the message, the message is retained in the messaging server for the period of the expiration time, in the hope that the durable subscribers, if any, will connect to the messaging server and accept delivery of the message.

Every message has an expiration time that specifies the maximum amount of time that the Message object can live from the time of its publication in the topic. A message can also be set to live forever, but as soon as all current subscribers and all durable subscribers have received the message, it will be discarded or deleted.

All subscribers are supposed to have a message event listener that takes delivery of the message from the topic and delivers it to the messaging client application for further processing. Subscribers can also filter the messages that they receive by qualifying their subscriptions with a message selector as was discussed in 4.

Message selectors evaluate a message's headers and properties (not their bodies) with the provided filter expression strings. The expression strings are typically modeled after a SQL-92-based SELECT statement. If there is a match, the message is delivered to the subscriber, if not, the subscriber does not get the message.



Professional JMS
Professional JMS
ISBN: 1861004931
EAN: 2147483647
Year: 2000
Pages: 154

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net