Tuesday, 29 March 2011

JMS Queue - Difference between a Queue and a Topic.

This is a typical interview question: What is the difference between a Queue and a Topic ( or Queue Vs Topic).

Before you go for the comparisons you need to learn the basics such as what is a JMS Queue what was the purpose of this technology and so on...

I would like to point you to this wiki page:

Topic: Java Message Service


After you have reviewed the above page you might have understood what is the difference already. But for those who are time short... read on.

First Elements of an JMS Queue:

JMS provider
    An implementation of the JMS interface for a Message Oriented Middleware (MOM). Providers are implemented as either a Java JMS implementation or an adapter to a non-Java MOM.

JMS client    An application or process that produces and/or receives messages.

JMS producer/publisher    A JMS client that creates and sends messages.

JMS consumer/subscriber
    A JMS client that receives messages.

JMS message
    An object that contains the data being transferred between JMS clients.

JMS queue
    A staging area that contains messages that have been sent and are waiting to be read. Note that, contrary to what the name queue suggests, messages have to be delivered in the order sent A JMS queue only guarantees that each message is processed only once.

JMS topic    A distribution mechanism for publishing messages that are delivered to multiple subscribers. 

Source: Java Message Service

The comparison: Queue VS Topic

Queue:

  • Point-to-point model
  • Only one consumer gets the message
  • Messages have to be delivered in the order sent
  • A JMS queue only guarantees that each message is processed only once.
  • The Queue knows who the consumer or the JMS client is. The destination is known.
  • The JMS client (the consumer) does not have to be  active or connected to the queue all the time to receive or read the message.
  • Every message successfully processed is acknowledged by the consumer.


Descriptive example: A JMS queue is a channel through which users "pull" messages they want to receive using the p2p model, instead of automatically receiving messages on a particular topic. The producer submits messages to the queue, and recipients can browse the queue and decide which messages they wish to receive. In the p2p model, users can see the contents of the messages held in the queue before deciding whether or not to accept their delivery.



 
Topic:

  • Publish/subscribe model
  • Multiple clients subscribe to the message
  • There is no guarantee messages have to be delivered in the order sent
  • There is no guarantees that each message is processed only once. -- As this can be sensed from the model 
  • The Topic, have multiple subscribers and there is a chance that the topic does not know all the subscribers. The destination is unknown.
  • The subscriber / JMS client needs to the active when the messages are produced by the producer, unless the subscription was a durable subscription.
  • No, Every message successfully processed is not acknowledged by the consumer/subscriber.
Descriptive Example: A JMS topic is the channel through which users subscribe to receive specific messages from a producer in the publish-and-subscribe model of JMS messaging. The model can be compared to subscribing to a newspaper; for example, if John Doe subscribed to "The New York Times," he would receive the paper every day from the newspaper producer. Similarly, if John Doe used JMS messaging to subscribe to a particular topic, he would receive all sent messages from a producer regarding that topic.

21 comments:

  1. It is missing the key "Don't" in the "Note that, contrary to what the name queue suggests, messages have to be delivered in the order sent". They do not have to be delivered in the order they were sent. This is stated incorrectly twice.

    ReplyDelete
  2. Can we use as below:
    1) JMS queue Eg:Customer want to know the all the previous trasactions,that time we will put data into the particular QUEUE,then one customer only will consume the confidential data from that QUEUE

    2) JMS topic Eg: Multiple Customers want to know all the services details,then we can distribute the data to multiple customers by using TOPIC

    ReplyDelete
    Replies
    1. Thanks for the info provided with the examples

      Delete
  3. Sound OK to me with what I understand from your description.

    ReplyDelete
  4. Can multiple JMS queues subscribe to a JMS topic to get messages?

    ReplyDelete
  5. Very well explained pretty useful for beginners, thanx a lot.

    ReplyDelete
  6. Great! It is useful and very long durable(2011 - ?) Topic to consume it :-)

    ReplyDelete
  7. This comment has been removed by the author.

    ReplyDelete
  8. Great article, but to pick up on a small but important point: the Queue doesn't know who the consumer is and the destination is NOT known.

    The message Producer knows what Topic it sends a message to or what Queue it publishes a message to but it doesn't know who the consumer will be. There may not even be a consumer.

    The message Consumer has to know what Topic it will subscribe to or what Queue it will listen to. But it doesn't know anything about the Producer.

    Queues and Topics know nothing they just carry messages.

    You have to choose the right pattern for each use case. For example, Publish/Subscribe tends to be overused because people think it is massively scalable. And it is, sort of. But it all depends on the use case.

    Pub/Sub will allow massive number of subscribers (think Twitter, footy scores etc).

    Message Queues are the pattern to use for messages that must be delivered and processed (think banks, ATMs) and they can scale to the moon by instantiating more listeners, which can be a triviality.

    ReplyDelete
  9. Nice content. Well explained. Thnx

    ReplyDelete