Queue and Topic are two messaging models supported by JMS:
1. Point-to-point (PTP) Queue messaging model:
With this messaging model, one application (i.e., the message producer) can send a message to another application (i.e., the message consumer). In this delivery model, the message destination type is a queue (i.e., the Destination interface implementation class instance is created by the Session interface implementation class instance by calling its createQueue method and passing in the queue name). The message is first delivered to a specific queue on the message server side, and from there, the message is delivered to a consumer who is listening to this queue. The same queue can associate multiple message producers and message consumers, but a message can only be delivered to one message consumer. If multiple message consumers are listening to messages on the queue, the JMS message server determines which message consumer receives the next message based on the "first-come, first-come" principle. If no message consumer is listening to the queue, the message remains in the queue until the message consumer connects to the queue. This messaging model is a lazy or polling model in the traditional sense. In this model, messages are not automatically pushed to the message consumer, but are requested from the queue by the message consumer.
2. Publish/subscribe (pub/sub) topic messaging model:
With this messaging model, applications are able to send a single message to multiple message consumers. In this delivery model, the message destination type is the topic (i.e., the Destination interface implementation class instance is created by the Session interface implementation class instance by calling its createTopic method and passing in the topic name). The message is first published to a specific topic in the message server by the message producer, who then delivers the message to all consumers who have subscribed to the topic. Topic goals also support long-term subscriptions. A long-term subscription means that the consumer is enrolled in the topic goal, but the consumer can be inactive when the message reaches the destination. The message will be received when the consumer is active again. If none of the consumers are enrolled in a topic destination, the topic retains messages only for inactive consumers who have signed up for a long-term subscription. Unlike the PTP messaging model, the pub/sub messaging model allows multiple topic subscribers to receive the same message. JMS holds the message until all topic subscribers receive it. The pub/sub messaging model is basically a push model. In this model, messages are automatically broadcast, and message consumers don't need to actively request or poll topics to get new messages.
The specific differences are as follows:
type
| Topic
| Queue | Overview
| Publish Subscribe messaging Publish subscription messages
| Point-to-Point Point-to-Point
| There is no state
| topic data is stateless by default.
| Queue data is saved as a file on the MQ server by default, for example, Active MQ is usually stored under $AMQ_HOME\data\kr-store\data. It can also be configured as a DB store.
| Integrity guarantee
| There is no guarantee that every piece of data published by the publisher will be accepted by the subscriber.
| Queue guarantees that every piece of data can be received by the receiver.
| whether the message will be lost
| Generally speaking, when a publisher publishes a message to a topic, only the sub that is listening to the topic address can receive the message. If there is no sub listening, the topic is lost.
| The Sender sends a message to the target Queue, and the receiver can receive messages on this Queue asynchronously. Messages on the Queue will not be lost if there is no receiver to pick them up for the time being.
| Message release reception policy
| One-to-many message publishing and receiving policy, multiple subs listening to the same topic address can receive messages sent by the publisher. The sub receives the notification to the mq server
| One-to-one message publishing and receiving policies, messages sent by a sender can only be received by one receiver. After the receiver receives, the MQ server notifies the MQ server that it has been received, and the MQ server deletes or takes other actions on the messages in the queue.
|
|
Posted on 7/14/2017 9:59:30 AM
|
|
|
|
Landlord