(fine) Getting started with JMS

The JMS-the Java Message Service-application interface is a Java platform-oriented messaging middleware (MOM) API for sending messages and communicating asynchronously between two applications, or distributed systems. The Java Messaging Service is a platform-independent API, with most MOM providers supporting JMS.

Catalog Definition Introduction History Architecture JMS Model delivery message way JMS Application Interface ConnectionFactory interface (connection factory) Connection interface (connection) destination interface (target) Messageconsumer Interface (message consumer) MessageProducer interface (messaging producer) message interface (messaging) session interface JMS Provider Implementation Marketing Science Journal of Book Information Content Introduction book catalogue other abbreviations network terms

definition

The JMS (Java Messaging Service) is a technical specification for message-oriented middleware (MOM) on the Java platform that facilitates message exchange for Java applications in messaging systems and simplifies the development of enterprise applications by providing a standard interface for generating, sending, and receiving messages. Translated to the Java messaging service.Brief IntroductionJMS is a vendor-independent API for accessing messaging systems. It is similar to JDBC (Java Database connectivity): Here, JDBC is an API that can be used to access many different relational databases, while JMS provides the same vendor-independent access method to access the messaging service. Many vendors currently support JMS, including IBM's MQSeries, Bea's Weblogic JMS service, and Progress's sonicmq, which are just a few examples. JMS enables you to send messages from a JMS client to another JMS client through a messaging service (sometimes called a message broker or router). A message is a type object in JMS that consists of two parts: the header and the message body. The header consists of routing information and metadata about the message. The message body carries the data or payload of the application. Based on the type of payload, you can divide messages into several types that carry: Simple text (textmessage), serializable objects (objectmessage), attribute collections (mapmessage), byte streams (bytesmessage), Raw value Stream (streammessage) and a message with no payload.HistoryThe Java Messaging Service is a standard developed within the Java Standardization Organization (JCP) (code-named JSR 914). June 25, 2001, the Java Messaging Service publishes the JMS 1.0.2b,2002 March 18 Java Messaging Service Release 1.1, which unifies the message domain.System ArchitectureJMS is made up of the following elements. A JMS provider connects to an implementation of the JMS interface for message-oriented middleware. 　　The provider can be a JMS implementation of the Java platform, or a message-oriented middleware adapter that is not a Java platform. 　　A JMS client produces or consumes a message based Java application or object. 　　JMS producers create and send messages to JMS customers. 　　A JMS customer that receives messages from a JMS consumer. A JMS message includes an object JMS queue of data that can be passed between JMS clients a region that accommodates messages that are sent for waiting to be read. Queues imply that these messages will be sent in order. 　　Once a message is read, the message is removed from the queue. A JMS topic a mechanism that supports sending messages to multiple subscribers.JMS ModelJava Messaging Application architecture supports two models: Point-to-Point or Queue model Publisher/Subscriber model in a point-to-point or queue model, a producer publishes a message to a particular queue, and a consumer reads the message from that queue. Here, the producer knows the consumer's queue and sends the message directly to the consumer's queue. 　　This pattern is summed up as follows: Only one consumer will get the message that the producer does not need to be running while the recipient is consuming the message, nor does the receiver need to be in the running state when the message is sent. Each successfully processed message is signed by the receiver to the Publisher/Subscriber model to support the release of a message to a particular message subject. 0 or more Subscribers may be interested in receiving messages from a specific message topic. In this model, publishers and Subscribers do not know each other. This pattern is like an anonymous bulletin board. This pattern is summarized as: multiple consumers can get a time dependency between the Publisher and the Subscriber. Publishers need to establish a subscription (subscription) so that customers can subscribe. Subscribers must remain active to receive messages unless the Subscriber establishes a persistent subscription. 　　In that case, messages that are published when the Subscriber is not connected will be republished when the Subscriber is reconnected. Using the Java language, JMS provides a way to isolate the transport layer that will be applied to provide data. The same set of Java classes can connect different JMS providers through the information about the provider in Jndi. This group of classes first uses a connection factory to connect to a queue or topic, and then sends or publishes a message. At the receiving end, the customer receives or subscribes to these messages.Delivery Message WayJMS now has two ways to deliver messages. Messages marked as Non_persistent are posted most of the time, and messages marked as persistent are posted using the mechanism of staging and forwarding. If a JMS service is offline, persistent messages are not lost but will not be delivered until the service is brought back online. So the default message delivery method is non-persistent. 　　Even if you use non-persistent messages, you may be able to reduce your internal and desired storage, and this is only used if you do not need to receive all the messages. Although the JMS specification does not require a JMS vendor to implement a priority route for messages, it needs to deliver expedited messages over normal-level messages. JMS defines a priority route level from 0 to 9, 0 is the lowest priority and 9 is the highest. More specifically, 0 to 4 is the change in the normal priority, and 5 to 9 is the rate of change in the accelerated priority level. For example: Topicpublisher.publish (Message, deliverymode.persistent, 8, 10000); Pub-sub or Queuesender.send (message,deliverymode.persistent, 8, 10000);//p2p This code fragment, there are two message models, the map delivery mode is persistent, priority is accelerated type, The life cycle is 10000 (measured in milliseconds). If the life cycle is set to zero, the message will never expire. 　　Setting a lifetime is useful when a message requires a time limit that otherwise invalidates it. JMS defines five different message body formats, and the message types that are invoked, allowing you to send and receive some level of compatibility with existing message formats in a number of different forms of data. · Streammessage--Data flow for Java raw values · mapmessage--a set of name-value pairs · textmessage--a String Object · objectmessage--a serialized Java object · bytesmessage--a data stream with no interpreted bytesJMS Application Interface connectionfactory Interface (connecting factory)A pipe object used by the user to create a connection to a JMS provider. JMS clients access the connection through a portable interface so that the code does not need to be modified when the implementation of the current layer changes. Administrators configure connection factories in the Jndi namespace so that JMS clients can find them. Depending on the type of message, the user will use the queue to connect to the factory or the subject to connect to the factory.Connection Interface (connection)A connection represents a communication link between an application and a message server. Once you have the connection factory, you can create a connection to the JMS provider. Depending on the type of connection, the connection allows the user to create sessions to send and receive queues and topics to the destination.destination Interface (target)The target is a Tube object that wraps the message target identifier, which refers to the location where the message was published and received, or the queue, or the subject. The JMS administrator creates these objects and then the user discovers them through Jndi. As with connection factories, administrators can create two types of goals, a point-to-point model queue, and a publisher/Subscriber model theme.Messageconsumer Interface (message consumer)An object created by the session to receive messages sent to the destination. Consumers can synchronize (blocking mode), or receive messages of queue and subject type asynchronously (non-blocking).MessageProducer Interface (message producer)An object created by a session to send a message to a destination. Users can create a sender of a target, or they can create a generic sender, specifying a target when sending a message.message Interface (Messages)Is the object that is transferred between the consumer and the producer, that is, from one application to another. 　　A message has three main parts: the message header (must): Contains the operation settings that are used to identify and find a route for the message. A set of message properties (optional): Contains additional attributes that support compatibility with other providers and users. 　　You can create custom fields and filters (message selectors). 　　A message body (optional): Allows the user to create five types of messages (text messages, mapping messages, byte messages, stream messages, and object messages). The messaging interface is flexible and provides many ways to customize the content of the message.session Interface (sessions)Represents a single-threaded context for sending and receiving messages. Because the session is single-threaded, the message is sequential, that is, the message is received in the order sent. The benefit of a session is that it supports transactions. If the user chooses transaction support, the session context saves a set of messages until the transaction is committed. The user can use a rollback operation to cancel these messages before committing the transaction. A session allows a user to create a message producer to send a message, creating a message consumer to receive the message.

JMS flowchart

JMS provider implementations to use the Java Messaging Service, you must have a JMS provider that manages sessions and queues. 　　Now there are both open source providers and proprietary providers. Open source providers include: Hornetq Joram Coridan, a Mantaray exclusive provider of the OPENJMS group, developed by the Apache ActiveMQ JBoss community includes: be A's BEA WebLogic Server JMS TIBCO software EMS gigaspaces Technologies gigaspaces softwired 2006 IBUs Iona IES's Iona JMS Seebeyond Iqmanager (acquired by Sun Microsystems in August 2005) webmethods jms+-My-channels Nirvana SONICMQ SWIFTMQ swiftmq IBM's WebSphere MQ------------------------------------------------------------------------- ------------------------------------------------------------------------------

The basic concept of MQ:

1) Queue Manager

The queue Manager is the topmost concept in the MQ system, and it provides a queue based messaging service for us.

2) message

In MQ, we define the data that the application sends to MQ as a message, and we can define the content of the message and understand the message in a broad sense, such as the user's various types of data files, the processing requests that an application makes to other applications, and so on. The message consists of two parts:

The message descriptor (the messages discription or the message Header) that describes the characteristics of the message, such as the priority of the message, the lifecycle, the information ID, and so on;

The body of the message, the User data section. In MQ, messages are classified into two types, non-persistent (non-persistent) messages and persistent (persistent) messages, and non-persistent messages are stored in memory and are designed to improve performance and are not recoverable when the system drops power or the MQ Queue Manager restarts. When the user's reliability requirements for the message are not high, while focusing on the performance of the system, you can use this type of message, such as: When the stock information is released, because the stock information is constantly updated, we may be published every few seconds, new messages will continue to overwrite the old message. Permanent messages are stored on the hard disk, and record the data log, it has high reliability, in the network and system failure, etc. can ensure that the message is not lost, not heavy.

In addition, there is the concept of logical and physical messages in MQ. With logical and physical messages, we can segment large messages, or we can classify several of our own complete messages into one group for processing.

3) Queue

Queues are safe repositories of messages, and queues store messages until they are processed by the application.

Message Queuing works in the following ways:

(a) program a forms a call to the Message Queuing system, which informs the Message Queuing system that the message is ready for program B;

b The Message Queuing system sends this message to the system where program B resides and places it in the queue of program B;

c After the appropriate time, program B reads the message from its queue and processes this information.

Due to the introduction of advanced program design ideas and internal working mechanism, MQ can guarantee the reliable transmission of the message under various network conditions, can overcome the poor or unstable status of the network line quality, in the transmission process, if the communication line fails or the remote host fails, the local application will not be affected, You can continue to send data without waiting for network failure recovery or remote host to run again.

In MQ, queues are divided into a number of types, including local queues, remote queues, template queues, dynamic queues, alias queues, and so on.

The local queue is divided into normal local queues and transport queues, which are queues that the application reads and writes through the API; transport queues can be understood as storage-forwarding queues, such as: We send a message to the MQ system to the remote host, where the network fails, MQ will put the message in the transport queue and, when the network resumes, send it to the remote destination.

A remote queue is a local definition of the destination queue, which resembles an address pointer that points to a destination queue on a remote host that is simply a definition and does not really occupy disk storage space.

Template queues and dynamic queues are a feature of MQ, a typical use of which is to be used as a system scalability consideration. We can create a template queue, when new queues are needed in the future, MQ automatically generates a dynamic queue each time a template queue is opened, and we can specify that the dynamic queue is either a temporary queue or a permanent queue, and if it is a temporary queue we can delete it while closing it, instead, if it is a permanent queue, We can keep it forever, for my own use.

4) Channel

A channel is a conduit for sending messages between queue managers in an MQ system, a logical concept built on a physical network connection, and the essence of MQ products.

in MQ, there are three main classes of channel types, namely, message channels, MQI channels, and cluster channels. The message channel is used to transmit messages between MQ servers and servers, and it should be emphasized that the channel is one-way, it has sent (sender), received (receive), requester (requestor), server (s), and so on, different types, For use by users in different situations. The MQI channel is used to communicate and transmit messages between MQ client and MQ server, and its transport is bidirectional, unlike the message channel. The cluster (Cluster) channel is used for communication between queue managers within the same MQ cluster.