ACTIVEMQ two modes of PTP and Pub/sub

1.PTP Models

The PTP (point-to-point) model is queue-based, and for the PTP message model its message is intended to be a message queue (queue), and the message producer always sends the message to the message queue each time it is sent. Message consumers always read messages from the message queue. Advanced Queue messages are first read by the message consumer.

The sender sends a message to the queue, the receiver receives the message from the queue, and the presence of the queue makes it possible to transmit the message asynchronously. As with mailboxes in the messaging system, queues can contain various messages, and JMS Provider provides tools to manage the creation and deletion of queues. The JMS PTP model defines how the client sends messages to the queue, receives messages from the queue, and browses the messages in the queue. The code in the first section is the PTP model.

The following table is the main concept and method of the PTP model object:

Name	Describe
Queue	Managed by the JMS Provider, the queue is identified by the queue name, and the client can get a queue object with the queue name through the Jndi interface.
Temporaryqueue	Created by Queueconnection, and can only be used by the queueconnection that created it. Temporary queues.
Queueconnectionfactory	The client creates the Queueconnection object with Queueconnectionfactory.
Queueconnection	A connection to the JMS PTP provider, the client can use Queueconnection to create queuesession to send and receive messages.
Queuesession	Provides some methods for creating Queuereceiver,queuesender,queuebrowser and Temporaryqueue. If the queuesession is closed, some messages have been received but have not yet been signed ( acknowledged), these messages are also received again when the recipient connects to the same queue the next time.
QueueReceiver	The client uses QueueReceiver to receive messages in the queue, and if the user sets the message selection criteria in QueueReceiver, the non-qualifying messages remain in the queue and are not received.
Queuesender	Client sends message to queue with Queuesender
Queuebrowser	The client can queuebrowser the messages in the queue, but will not take the messages.
Queuerequestor	JMS provides the Queuerequestor class to simplify the process of sending and receiving messages. The Queuerequestor constructor has two parameters: Queuesession and Queue,queuerequestor complete the final send and receive message request by creating a temporary queue.
Reliability (Reliability)	The queue can persist messages for a long time until the recipient receives the message. The recipient does not need to be able to maintain an active connection state because of fear that the message will be lost, which fully embodies the advantages of asynchronous transfer mode.

2.pub/sub Model

The JMS pub/sub model defines how messages are published and subscribed to a content node, which is called a topic (topic).
The subject can be thought of as a transport intermediary for the message, and the publisher (publisher) publishes the message to the subject, and the Subscriber (subscribe) subscribes to the message from the topic. The topic keeps the message subscribers and the message publishers separate from each other and guarantees the delivery of the message without contact.
The following describes the key concepts and objects in the JMS pub/sub model:

Subscribe (subscription)	Message subscriptions are divided into non-durable subscriptions (non-durable subscription) and persistent subscriptions (durable subscrip-tion), and non-durable subscriptions are only available when the client is active, that is, and the JMS Provider Stay connected to receive messages sent to a topic, and when the client is offline, messages sent to the topic during this time period will be lost and never received. When a persistent subscription is made, the client registers a ID with the JMS identity that is recognized by the customer, and when the client is offline, the JMS Provider All messages sent to the topic are saved for this ID, and when the customer connects to the JMS provider again, all messages that are sent to the topic when they are offline are obtained based on their ID.
Topic	The topic is managed by the JMS Provider, which is identified by the topic name and the client can get a Subject object with the topic name through the Jndi interface. JMS does not give a definition of the organization and hierarchy of the topic, which is defined by the JMS Provider itself.
Temporarytopic	The temporary theme is created by Topicconnection and can only be used by the topicconnection that created it. Temporary themes cannot provide persistent subscription functionality.
Topicconnectionfactory	The client creates the Topicconnection object with Topicconnectionfactory.
Topicconnection	Topicconnection is a connection to the JMS pub/sub provider, and the client can create topicsession with topicconnection to publish and subscribe to the message.
Topicsession	Topicsession provides some ways to create topicpublisher,topicsubscriber,temporarytopic. It also provides a durable subscription to the Unsubscribe method to cancel the message.
Topicpublisher	The client publishes the message to the subject with Topicpublisher.
TopicSubscriber	The client uses TopicSubscriber to receive messages that are published to the topic. You can set the message filtering feature in TopicSubscriber so that messages that do not meet the requirements are not received.
Durable TopicSubscriber	If a client needs a persistent subscription message, you can use durable topicsubscriber,topsession to provide a method Createdurablesubscriber create a durable TopicSubscriber object.
Recovery and re-Dispatch (Recovery and Redelivery)	An unsigned message cannot be recovered or re-dispatched under a non-persistent subscription state. Only persistent subscriptions can recover or resend a message that is not signed.
Topicrequestor	JMS provides the Topicrequestor class to simplify the process of sending and receiving messages. The Topicrequestor constructor has two parameters: Topicsession and topic. Topicrequestor completes the final publish and receive message requests by creating a temporary theme.
Reliability (Reliability)	When all messages must be received, the persistent subscription pattern is used. The non-persistent subscription mode is used when the lost message can be tolerated.

In summary, the API interface of both has been written out in detail, as a Java qualified developers, even if not back to these, but also need to understand the thorough remember. You can then look at the comparison between the two ways: the two types of message transmission in the 3.JMS specification topic and queue, The comparison of the two is shown in the following table:

	Topic	Queue
Profile	Pub-sub (Publish/subscribe)	PTP (Point-to-point)
There is no status	Topic data is stateless by default.	The queue data is saved to the actual media, such as to the database.
Integrity Assurance	There is no guarantee that every piece of data published by publisher will be accepted by subscriber.	The queue guarantees that each piece of data can be received by receiver.
Whether the message will be lost	In general, when Publisher publishes a message to a topic, only the sub that is listening to the topic address can receive the message, and if no sub is listening, the topic is lost.	Sender sends a message to the target Queue,receiver can receive messages on this queue asynchronously. Messages on the queue will not be lost if receiver is not available for the time being.
Message Publishing Receive Policy	A one-to-many message publishing receive policy that listens to multiple sub-topic addresses to receive messages from Publisher. The sub receives the notification server.	One message to the receiving policy, a sender sends a message, only one receiver receives. Receiver receives, notifies the server that it has received, and the server takes a delete or other action on the message in the queue.

Article go to: http://www.cnblogs.com/chenying99/archive/2013/07/01/3164637.html