Message middleware and JMS standards

Initial knowledge of message middleware

The definition of message middleware on Wikipedia is "message-oriented middleware (MOM) was software infrastructure focused on sending and receiving messages be Tween distrubuted Systems ". The explanation is that the message middleware is the basic software that completes the message sending and passing in the distributed System . Read a picture to understand message middleware more intuitively:

There are two benefits of seeing message middleware:

1. Asynchronous

2. Decoupling

Application A and application B are dealing with the message middleware, the two applications are not directly linked, so that the understanding of decoupling, the purpose is to send and receive messages to each other do not know each other's existence, and not affected by the other side, so the delivery of the message to the receiver is actually used in an asynchronous way.

The application decoupling of message middleware through example

Take Apple's App Store as an example, the App Store has a feature: A security option is to send a text message to the user's mobile phone after the user has successfully credited it. The most intuitive, we will do this:

Then, we need to pass the user's payment information (user name, time, IP and other data) to the security system, the security system will be based on the security policy of the relevant judgment and processing, so the structure into:

So it looks okay, so what if we add some more systems to be called? Like what:

This makes the payment system very complex, with each additional system that needs to be called after the payment is successful, the payment system needs to be modified to make the relevant call. An elegant implementation is to turn the service invocation of this payment success into an extensible configuration that can even be applied dynamically, but this can only reduce the cost of development and deployment at the time of the change, without reducing complexity. Payment systems are forced to rely on very many systems.

Service decoupling by introducing message middleware

Consider, from a payment point of view, that these systems must be dependent on the payment system? The answer is no, the payment system only need to verify the legality of user account, payment account, payment password, so the payment system depends on the system user account, payment account, payment password system, and in the system is not the payment system must rely on the system. Instead, these systems must be dependent on the payment system, as they all care about the success of the payment.

In such a scenario, we need to decouple the above structure through the message middleware, and the service invocation in the above structure will be replaced by a fixed-format message delivery. The payment system is responsible for sending messages to the message middleware, while other systems subscribe to the message middleware and do their job:

In this way, through the message middleware, the payment system does not need to be concerned about how many systems need to know the success of the payment, and do not care how to notify them, just to the success of the landing into a message sent to the message middleware, so that the need to understand the payment success of the system itself to the message The inter-item subscription is OK, and the systems are not affected by each other.

JMS Overview

JMS is the abbreviation for the Java Message service, Java messaging, which is a specification for messages in Java EE, and Hornetq, ACTIVEMQ, and so on, are implementations of this specification. If it is an enterprise or some small system, it is an economical choice to use JMS directly, and there are some scenarios in large-scale systems that are not suitable for using JMS.

In the large-scale Internet, we use the message middleware to decouple the application and the asynchronous Operation , which is the most basic feature of the message middleware two, and it is exactly what we need. On this basis, we focus on the sequence of message assurance , extensibility , reliability , business operations and message delivery consistency , as well as multi-cluster subscribers and other aspects of the problem . Of course, these are the things that we want to think about, and JMS has already figured out what JMS can do for developers:

1. Define a set of message common concepts and utilities

All Java applications can use the APIs defined in JMS to create, receive, and send messages, and any mom that implements the JMS standard can be used as a mediator for messages and to store and forward messages.

2. Maximizing portability of messaging applications

MOM provides guaranteed message delivery, and application developers do not need to know the details of remote procedure calls (PRC) and network/communication protocols to provide program portability

3. Minimizing the coupling between applications and applications

Because of the presence of MOM, individual applications only care about how messages are received and sent between mom and not the other side of mom, how other programs receive and send

JMS Two message models

1, point-to-point model

The point-to-point model (Pointer-to-pointer) resembles this:

This model summarizes several points:

(1) A message middleware is associated with multiple queue producers and consumers

(2) A message can only be consumed by a consumer

(3) Multiple consumers are listening to messages on the queue, then the middleware will be based on the first-come first-served basis to determine which consumer receives the next message, if no consumer is listening to the queue, then the message will remain in the middleware until the consumer connects to the middle

(4) After receiving the message, the consumer must confirm that the message has been received, or the middleware Jiang believes that the message has not been received, then the message can still be received by other consumers. The program can be automatically confirmed without the need for manual intervention

(5) There are no restrictions on the operation of producers and consumers

(6) in this model, the message is not automatically pushed to the consumer, but the consumer middleware in the request to obtain

2. Publish/Subscribe Model

The Publish/subscribe (PUBLISH-SUBSCRIBE) model looks like this:

In this model, it is summarized in the form of points:

(1) There is an important concept of topic, which can be considered a subject

(2) Producers publish messages, consumers subscribe to messages of interest, producers connect messages to a specific topic (subject), and middleware will deliver messages to consumers based on the topic of consumer registrations

(3) Publish/Subscribe mode allows multiple consumers to receive the same message as long as these consumers register the same topic

(4) Consumers must first run, subscribe to the theme, and then wait for the producers to run, so point-to-point model is different

(5) In this model, messages are broadcast automatically, and consumers do not need to obtain new messages through unsolicited requests or rotation-themed methods.

JMS is the provided feature

JMS provides a lot of elements for the issuer to see the more important:

Feature	Role
Destination	Represents the target definition of the channel to which the message is going, and is used to define the channel that the message is going to take from the sending side, not the receiver. Destination belongs to the Management class object
ConnectionFactory	As the name implies, used to create the connection object, ConnectionFactory belongs to the Management class object
Connection	Connect interface, responsible for important work when creating session
Session	Session interface, which is a very important object, the message sender, the message receiver, and the message object itself, are created through this session object
Messageconsumer	The consumer of the message, which is the object that subscribes to the message and processes the message
MessageProducer	The producer of the message, which is the object used to send the message
Xxxmessage	Refers to the various types of message objects, including Bytemesage, ObjectMessage, Streammessage, and textmessage 5 kinds of

In the JMS message model, depending on the point-to-point pattern and the Publish/subscribe pattern, these features are expanded to their content:

JMS Standard	Point-to-point mode	Publish/Subscribe Mode
ConnectionFactory	Queueconnectionfactory	Topicconnectionfactory
Connection	Queueconnection	Topicconnection
Destination	Queue	Topic
Session	Queuesession	Topicsession
MessageProducer	Queuesender	Topicpublisher
Messageconsumer	QueueReceiver	TopicSubscriber

JMS is a standard, specific or dependent implementation, the current common JMS implementation has ACTIVEMQ, ZeroMQ, RABBITMQ, and so on, Kafka is a similar JMS implementation, the next article will focus on the Kafka, as for why, or the same as the previous writing article reasons , because the work, hehe.

Message middleware and JMS standards