JMS is a standard API applied to asynchronous messaging, and as part of the Java platform, JMS allows for reliable, asynchronous data communication between different applications and different modules.
Some Concepts
JMS Provider
An implementation of the JMS interface for a Message oriented middleware (MOM). Providers is 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 The contains messages that has been sent and is waiting to be read. Note that, contrary to the name of the queue suggests, messages don ' t has to be delivered in the order sent. A JMS Queue Only guarantees this each message was processed only once.
JMS Topic
A distribution mechanism for publishing messages that is delivered to multiple subscribers.
in JMS, two message models, point-to-point (point-to-point), and publish-subscribe (Publish and subscribe) are supported, each corresponding to two message destinations in JMS (Messages Destination): Queues and topics.
In a point-to-point model, each message has a sender and a receiver, the message mediation (broker) receives a message from the sender, puts the message in the queue, and the recipient requests and receives a message from the queue, and the message is removed from the queue. Each message in a message queue can only be delivered to one recipient, but it does not mean that only one receiver can be used to fetch messages from the queue, and that, depending on the business needs, multiple recipients are able to request messages from the queue at the same time, sharing the processing pressure. However, it is important to note that the message received by a single recipient is based on the order of delivery, and because of the multi-threaded relationship of multiple receivers, there is no guarantee that the received message must be in the original order.
In Publish-subscribe mode, messages are sent to a topic, but unlike point-to-point mode, messages are no longer delivered to only one recipient, but all Subscribers to this topic receive the message.
JMS Message Type
in the JMS1.1 specification, five types of messages are defined, respectively:
1.StreamMessage: The message body is a Java stream, and both writes and reads are sequential
2.MapMessage: Message body contains key-value pair, key is String, value is base type, can be accessed via iterator
3.TextMessage: The message body is a String
4.ObjectMessage: The message body is a serializable Java object
5.BytesMessage: The message body is a byte array
The message body can be purged by message.clearbody (), but on the consumer side, the message body is read-only and the write operation for the message throws a Messagenotwritableexception exception
JMS message Header
All message headers are of the exact same field, used for the JMS Client and JMS Provider to differentiate them and to route messages1.JMSDestination
The destination (queue or topic) where the message was sent, jmsdestination can be set when the message is created, but its value is updated to the jmsdestination specified by the sender when the send is completed, that is, the field is ignored before it is sent, and when the message is consumed, The value of the field is the same as the value that was set when it was sentall of the following examples are based on ACTIVEMQ
Session session = Connection.createsession (false, Session.auto_acknowledge);
//creation of 2 destinations
Destination Destination = Session.createqueue ("JMS. DEMO ");
Destination Destination2 = Session.createqueue ("JMS. DEMO2 ");
//Create a producer
MessageProducer publisher = Session.createproducer (destination);
//Set Transfer Mode
Publisher.setdeliverymode (deliverymode.persistent);
//Create a message
TextMessage message = session.createtextmessage ("Test message");
//set the destination of the message to Destination2
Message.setjmsdestination (Destination2);
//Send Message
Publisher.send (message);
System.out.println (Message.getjmsdestination ());
Code, through Message.setjmsdestination (Destination2); Sets the value of the message header property of the Jmsdestination, and then we look at its output
Queue//JMS. DEMO
This example shows that although the destination of the message was set before it was sent, the destination of the message after it was sent has been reset by 2. Jmsdeliverymode
Indicates the transmission mode of the message in two ways: deliverymode.persistent: Ensure that the message is passed only once and the message is not lost after the JMS Provider service is stopped; Deliverymode.non_persistent: The message is transmitted at most once, and the message is JMS Provider is lost after it is stopped, and as with jmsdestination, it is ignored before sending.
Look at the following example
Session session = Connection.createsession (false, Session.auto_acknowledge);
//Create a destination
Destination Destination = Session.createqueue ("JMS. DEMO ");
//Create a producer
MessageProducer publisher = Session.createproducer (destination);
//Set Transfer Mode
Publisher.setdeliverymode (deliverymode.persistent);
//Send Persistent message
Publisher.send (Session.createtextmessage ("Persistent MESSAGE"));
//Set Transfer Mode
Publisher.setdeliverymode (deliverymode.non_persistent);
//Send Persistent message
Publisher.send (Session.createtextmessage ("Non_persistent MESSAGE"));
In the example, a persistent message and a non_persistent message are sent respectively, and when the Active MQ restarts, the consumer is started, and the message received is as follows
Persistent MESSAGE
This example shows that after the JMS Provider restart, the non_persistent message is lost, and the persistent message can be consumed by the consumer.3.JMSMessageID
The unique identifier of the message specified by the JMS Provider, as in the above field, which is set before sending and is ignored and reset by the JMS Provider when the send is complete
4.JMSReplyTo send side when sending a message, you can specify the property (for a jmsdestination), which indicates the response expected to be received by the client, and whether the response is determined by the consumer, as in the following example: Send side: Session session = Connection.createsession (false, Session.auto_acknowledge);
//Create a destination
Destination Destination = Session.createqueue ("JMS. DEMO ");
Destination Destination2 = Session.createqueue ("JMS. DEMO3 ");
//Create a producer
MessageProducer publisher = Session.createproducer (destination);
//Set Transfer Mode
Publisher.setdeliverymode (deliverymode.persistent);
//Create a message
TextMessage message = session.createtextmessage ("Test message");
Message.setjmsreplyto (Destination2);
//Send Message
Publisher.send (message);
Receiving end (can decide if a reply is required depending on the situation)
PublicvoidOnMessage (Message message) {
Try{
SYSTEM.OUT.PRINTLN ("Receive message:" + message);
if(Message.getjmsreplyto ()! =NULL) {
Session.createproducer (Message.getjmsreplyto ()). Send (Session.createtextmessage ("This was a reply to"
+ Message.getjmsreplyto ()));
}
}Catch(Exception e) {
E.printstacktrace ();
}
}
5.JMSRedelivered
When a consumer receives a message header with a jmsredelivered, it indicates that the message has been transmitted in the past but is not confirmed that the JMS Provider must be set, and when True informs the consumer that the message is retransmitted and that the consumer needs to handle the duplicate message on its own
6.JMSExpiration
The expiration time of the message, which is the current time plus the time of survival (in milliseconds), and when the survival time is set to 0 o'clock, the value of the field is set to 0, which means it never expires; the consumer does not receive an expired message in general, but JMS Provider does not guarantee this The following example shows how to set the expiration time of a message session session = Connection.createsession (false, Session.auto_acknowledge);
//Create a destination
Destination Destination = Session.createqueue ("JMS. DEMO ");
//Create a producer
MessageProducer publisher = Session.createproducer (destination);
//Set Transfer Mode
Publisher.setdeliverymode (deliverymode.persistent);
//Create a message
TextMessage message = session.createtextmessage ("Test message");
//Send Message
Publisher.settimetolive (5000);
Publisher.send (message);
7.JMSPriority
The priority of the message, 0 for the lowest priority, 9 for the highest priority, the general 0~4 for the normal priority, the 5~9 for the expedited priority JMS specification does not require the JMS Provider to be implemented in strict accordance with this priority, but as far as possible to achieve faster priority message transmission in front of the ordinary message and JMS Destination, the field is ignored before it is sent and reset when the send is complete
Message Properties
In addition to the message headers mentioned earlier, JMS messages provide support for property value pairs to extend the message header, which is used primarily for message selectors (messages selector see below)
1. Property name
property names must serve the naming rules of the message selector
2. Attribute values
Can be basic types and their object types, as well as Map, List, and String
In the following example, the message with the HASHMAP attribute session session = Connection.createsession (false, Session.auto_acknowledge);
//Create a destination
Destination Destination = Session.createqueue ("JMS. DEMO ");
//Create a producer
MessageProducer publisher = Session.createproducer (destination);
//Set Transfer Mode
Publisher.setdeliverymode (deliverymode.persistent);
//Create a message
TextMessage message = session.createtextmessage ("Test message");
//Send Message
Message.setobjectproperty ("MyProp",NewHashMap () {
{
This. put ("Key1", "value1");
This. put ("Key2", "value2");
}
});
Publisher.send (message);
3. Clear Properties
JMS cannot purge a single property, but all message properties can be cleared through the Message.clearproperties () method
JMS Implementation (Provider implementations)
To use JMS, you must have a corresponding implementation to manage the session and queue, starting with Java EE1.4, all Java EE application servers must contain a JMS implementation.Here are some JMS implementations:
Apache activemq Apache Qpid, using amqp BEA Weblogic (part of the Fusion Middlewar E suite) and Oracle AQ from oracle EMS from tibco FFMQ, GNU LGPL licensed JBoss Mes Saging and HornetQ from jboss Joram, from the OW2 consortium Open Message Queue from Sun Micros ystems OPENJMS, from the OPENJMS group RabbitMQ, using amqp Solace JMS from Solace systems SONICMQ from Progress software STORMMQ, using amqp swiftmq Ter vela Ultra Messaging from-West (acquired by Informatica) webmethods from software ag &N Bsp WebSphere application Server from IBM, which provides an inbuilt default messaging provider known as the Service Integrati On Bus (SIBus), or which can connect to WebSphere MQ as a JMS provider [5] WebSphere MQ (formerly MQSeries) F Rom IBM
Source: >
whether it is persistent or non-persistent messages, if the message does not have a corresponding consumer, then ACTIVEMQ will consider these messages useless and delete them directly.
Persistent Subscribers/non-persistent subscribers only affect whether messages (including persistent and non-persistent messages) can be received while offline, and whether the messages are persistent or not, persistent/non-persistent messages only affect the JMS provider after the outage. Whether the message is lost, and if it never goes down, there is no difference between persistent and non-persistent messages.
From for notes (Wiz)
JMS is a standard API that is applied to asynchronous messaging
