As mentioned above, JMS defines two types of destinations, topics and queues. Most JMS providers support both topics and queues, and an application can make use of both. Oracle ATG Web Commerce applications typically use topics, as they offer the most flexibility for expansion. However, a messaging application might use queues for certain purposes, such as load balancing.

The use of destinations provides much of the flexibility in JMS. If a new application needs to send messages to or receive messages from an existing application, it can publish or subscribe to the destinations used by that application. The new application does not need to be aware of the message producers and consumers in the original application, just the destinations. This means that message producers and consumers can be added to or removed from one application without affecting other applications, as long as the destinations remain the same.

Each destination is maintained by a single JMS provider, which typically maintains many destinations. The creation and management of destinations within a JMS provider is usually an administrative or configuration operation. If a message is sent to a destination, that destination’s JMS provider is responsible for receiving the message and passing it on to subscribers waiting for messages from that destination. Different providers might use different mechanisms to accomplish this. For example, Oracle ATG Web Commerce’s SQL JMS uses an SQL database to store and deliver messages, for applications that require the messaging system to be highly reliable. Other JMS providers might use file- or memory-based storage.

Message Persistence

Queue destinations typically are persistent. If a message is sent to a queue but no receiver is online, the message is kept in the queue, waiting for a receiver to connect and start reading from the queue. After a message is delivered to a single receiver, it is removed from the queue.

Topics, however, are non-persistent by default. If a message is sent to a topic, it is delivered to all subscribers to that topic that are currently online, and then removed. Any subscriber that is offline does not receive the message. If no subscribers are currently online, the message is simply removed from the topic without being delivered anywhere.

Some applications require the flexibility of a topic, but also the persistence offered by a queue. For example, suppose an application requires a message to be delivered to several subscribers, but it is not acceptable for a subscriber to miss any of the messages if it goes offline. Sending email to a mailing list demonstrates this paradigm (in a non-JMS environment), where a single message is distributed to many readers, and queued up for each reader to be delivered when the reader comes online.

JMS addresses this need through the use of durable subscriptions. A message consumer that has a durable subscription to a topic can go offline, then reconnect later and pick up any messages that were sent to the topic in its absence. Durable versus non-durable is a property of each individual subscriber, not of the topic as a whole. A topic can have a mix of subscribers, some durable and some non-durable.

Durable and non-durable subscribers are created through the JMS API. Creating a durable subscriber requires specifying a name that the topic uses to identify the subscriber. Each durable subscriber to a topic must have a name that is unique for that topic. If a subscriber disconnects, the JMS provider holds any subsequent messages under that name. If the subscriber then reconnects using the same durable subscription name, the messages held under that name are delivered to the subscriber.