AMQP Protocol Introduction
AMQP, Advanced message Queuing Protocol, is an open standard for application-layer protocols designed for message-oriented middleware.
The main features of AMQP are message-oriented, queue, routing (including point-to-point and publish/subscribe), reliability, and security.
AMQP enforces the behavior of both the message provider and the client, allowing for true interoperability between different vendors.
JMS is an attempt to standardize the early messaging middleware, which is only standardized at the API level and is far from creating interoperability capabilities.
Unlike JMS, AMQP is a wire-level protocol that describes the format of the data transmitted over the network, in bytes as a stream. Therefore, any tool that adheres to this data format can interoperate with other compatible tools by creating and interpreting messages.
Version of the AMQP specification:
0-8 was released in June 2006
0-9 published on December 2006
0-9-1 released in November 2008
0-10 released in the second half of 2009
1.0 Draft (document or draft)
The AMQP implementations are:
1) openamq
AMQP's Open source implementation, written in C, runs on Linux, AIX, Solaris, Windows, OpenVMS.
2) Apache Qpid
Apache's Open source project supports C + +, Ruby, Java, JMS, Python, and. NET.
3) Redhat Enterprise MRG
The latest version of AMQP 0-10 is implemented, providing a rich set of features, such as full management, federation, active-active clusters, web consoles, and many enterprise-class features that support C + +, Ruby, Java, JMS, Python, and. NET.
4) RabbitMQ
An independent open source implementation, the server side is written in Erlang language, supporting a variety of clients, such as: Python, Ruby,. NET, Java, JMS, C, PHP, ActionScript, XMPP, stomp, etc., support Ajax. RABBITMQ released in Ubuntu, FreeBSD platform.
5) AMQP Infrastructure
Linux, including broker, administrative tools, agents, and clients.
6) ØMQ
A high-performance messaging platform that can be used as an AMQP-compliant broker node in a distributed messaging network that is bound to multiple languages, including Python, C, C + +, Lisp, Ruby, and more.
7) Zyre
is a broker that implements the RESTMS protocol and the AMQP protocol, providing restful HTTP access to the network AMQP capability. Introduction to the JMS protocol
JMS (Java Messaging Service) is a technical specification for message-oriented middleware on the Java platform that facilitates the message exchange of Java applications in the messaging system and simplifies the development of enterprise applications by providing a standard interface for generating, sending, and receiving messages.
JMS itself only defines a series of interface specifications, which is a vendor-agnostic API for accessing messaging systems. It is similar to JDBC (Java Database Connectivity): Here, JDBC is the 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 SonicMQ, which are just a few examples. JMS enables you to send messages from one JMS client to another JML 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: a header and a message body. The header consists of the routing information and the metadata about the message. The message body carries the data or payload of the application. Depending on the type of payload, messages can be divided into several types, each carrying: simple text (textmessage), serializable object (objectmessage), attribute collection (mapmessage), Byte Stream (bytesmessage), The original value stream (Streammessage), as well as a message with no payload.
Stomp Protocol Introduction
The stomp,streaming text orientated message Protocol is a streaming text-oriented messaging protocol, a simple text protocol designed for MOM (message oriented middleware, messaging-oriented middleware).
It provides an interoperable connection format that allows the stomp client to interact with any stomp message broker (broker), similar to Openwire (a binary protocol).
Because of its simple design, it is easy to develop the client, so it is widely used in many languages and various platforms. One of the most popular stomp message agents is Apache ActiveMQ.
The STOMP protocol works on the TCP protocol and uses the following commands:
* Send Sent
* SUBSCRIBE Subscription
* Unsubscribe Unsubscribe
* BEGIN
* Commit Commit
* Abort Cancel
* ACK Confirmation
* DISCONNECT Disconnect Message Middleware Overview
Message Queuing technology is a technique for exchanging information among distributed applications. Message Queuing can reside in memory or on disk, and queues store messages until they are read by the application. With Message Queuing, applications can execute independently-they do not need to know each other's location, or wait for the receiving program to receive this message before proceeding.
In distributed computing environments, in order to integrate distributed applications, developers need to provide effective means of communication for distributed applications in heterogeneous network environments. In order to manage the information that needs to be shared, it is important to provide the public information exchange mechanism for the application.
The methods of designing distributed applications are: Remote Procedure call (PRC)-One of the basic standard components of Distributed computing Environment (DCE); object transaction Monitoring (OTM)-The combination of object-oriented industry standard and transaction processing (TP) monitoring technology based on CORBA; Message Queuing (MessageQueue )-loosely coupled method for constructing distributed applications.
(a) Distributed computing environment/Remote Procedure Call (DCE/RPC)
RPC is the component of DCE and is an application-integrated software standard released by the Open Software Foundation (OSF). RPC mimics a program that uses a function reference to refer to another program's traditional programming method, which is the form of a procedure call, and once invoked, the program's control turns to the called program.
When RPC is implemented, the called procedure can reside in another system, either locally or in a remote place, and is executed. When the called program finishes processing the input data, the result is placed in the return variable of the procedure call back to the calling program. After the RPC is complete, program control returns to the calling program immediately. So RPC mimics the call/return structure of the subroutine, which provides only the synchronous data exchange between the client (the calling program) and the server (called procedure).
(b) Object Transaction monitoring (OTM)
The combination of object-oriented industry standard and transaction processing (TP) monitoring technology based on CORBA defines: Architecture using object-oriented techniques and methods, public client/server programming interface, and guidelines for transferring and translating data between multiple platforms , developing the language of Distributed Application Interface (IDL), and providing a wide and consistent pattern for client/server application of structural distribution.
(c) Message Queuing (Messages queue)
The messaging team is listed as a loosely coupled method for constructing distributed applications that are implemented synchronously or asynchronously. Message Queuing API calls are embedded in new or existing applications that provide information exchange by sending messages to memory or disk-based queues or reading them out. Message Queuing can be used in an app to perform a variety of functions, such as requiring services, exchanging information, or asynchronous processing.
Middleware is a kind of independent system software or service program, and distributed Application system uses this software to share resources among different technologies, manage computing resources and network communication. It is a key software in the computer system, it can realize the interconnection and interoperability of the application, and can ensure the safe, reliable and efficient operation of the system. The middleware is located between the user application and the operating system and the network software, it provides the common communication means for the application, and is independent of the network and the operating system. Middleware provides developers with an application interface for all environments, and when an application embeds its function calls, it can take advantage of the capabilities of the specific operating system and network environment it runs to perform communication functions for the application.
If there is no message middleware to complete the exchange of information, application developers in order to transfer data, it is necessary to learn how to use the network and operating system software functions, write the appropriate application to send and receive information, and exchange information there is no standard method, each application must be specific programming and multi-platform, Communication of one or more applications in different environments. For example, in order to achieve communication between different host systems on the network, it will require knowledge of how information is exchanged on the network (such as socket programming with TCP/IP), and in order to achieve communication between different processes within the same host, knowledge of the operating system's Message Queuing or named pipes (Pipes) will be required.
There are many kinds of middleware, such as transaction management middleware, Web application Server middleware for Java application, and message transfer middleware (MOM). It simplifies the transmission of data between applications, shields the underlying heterogeneous operating systems and network platforms, provides consistent communication standards and application development, and ensures reliable, cross-platform information transfer and data exchange in a distributed computing network environment. It is based on the storage-forwarding mechanism of message queue, and provides the unique asynchronous transmission mechanism, which can realize application integration and data exchange based on message transmission and asynchronous transaction processing.
Publish-Subscribe message mode
First, subscribe to the magazine
Many of us have booked a magazine, and the process is simple. Just tell the Post office the name of the magazine, the address of the delivery, and pay the money. Publishing houses are regularly handed over to the post office, and the Post Office will deliver the magazine to consumers based on a list of subscriptions. So that we can see every issue of a wonderful magazine.
Think carefully about the process of ordering a magazine, we will find a few features: 1, consumers do not need to book a magazine directly, 2, the publishing house only need to give the magazine to the post Office; 3. The Post Office will serve the magazine to consumers. The Post office has played a very important relay role in the entire process, and the Post Office has completed the delivery of the magazine in the case of publishers and consumers who do not need to know each other.
Second, publish-subscribe message mode
Just talked about subscribing to the magazine, below we will talk about the traditional call pattern evolution to the publish-subscribe message pattern.
Some websites send an activation email after a successful registered user, and the user clicks the activation link after receiving the message before they can use the site. The general practice is to invoke the logic that sends the message in the registered user's business logic. In this way, the user business relies on the mail business. If you later change to SMS activation, the registered user business logic must be modified to invoke the logic to send the SMS. If you want to add points to the user after registration, add a logic. After many changes, we found that a very simple registered user business has become more complex and more difficult to maintain. It is believed that many developers will experience similar pain.
Even if the user's business implementation is interface dependent on other business, it will not be able to avoid the impact of business change. What to do. Decoupling. The process of registering a successful registration in the business logic of the registered user is stripped out.
Then look back at "subscription magazine", if there is no post office, the publishing house must own the magazine to all consumers. This situation is the same as the current registered user business. We found the problem and the role of the post office was missing between the user business and the other business.
We abstracted the Post office as a place to manage the message, called the message manager. The registered user sends a message to the message manager after success, and the message manager forwards the message to the business that needs to be processed. Now, the user's business depends only on the message manager, and it will no longer be bothered by the other processing after the successful registration of the user.
The transformation of registered users is to learn from the "subscription magazine" such a primitive model. We further abstract that the user business is the "producer" of the message, which publishes the message to the message manager. The Mail service is the "consumer" of the message, which processes the messages it receives. The Post Office can subscribe to many kinds of magazines, which are distinguished by a number; The message manager can also manage a variety of messages, each of which has a "subject" to differentiate, and consumers are subscribed through the topic.
The Publish-Subscribe message pattern is already in front of us, making it possible to create more flexible, loosely coupled systems.
MQ related concepts
1. Messages (message)
The message is the smallest concept in MQ, which is essentially a piece of data that can be understood by one or more applications and is the carrier of information passed between applications.
2. Queuing (queue)
2.1 Local queues
Local queues are categorized by functionality to initialize queues, transmission queues, destination queues, and dead-letter queues.
Initialize the queue as a message-triggering feature.
The transport queue is simply staging the message to be passed, and, if the condition permits, the message is routed through the pipeline to the other queue managers.
The destination queue is the destination of the message and can hold the message for a long time.
If the message cannot be delivered to the destination queue and can no longer be routed, it is automatically placed in the dead-letter queue for saving.
2.2 Alias Queue & remote Queue
is just a queue definition that specifies the queue for the remote Queue Manager. With a remote queue, the program does not need to know the location of the destination queue.
2.3 Model queues
Model queues define a set of properties for a local queue, and once you open the model queue, the queue manager dynamically creates a local queue based on those attributes.
3. Queue Manager
A queue manager is a mechanism that provides a message service to an application, and if the queue manager is likened to a database, the queue is one of the tables.
4. Channels (channel)
A channel is a one-way point-to-point communication connection between two managers, and a pair of channels can be established if two-way communication is required.
5. Listener (listner) features of MQ products
Reliability transmission
This feature can be said to be the base of the message middleware, for the application, as long as the data submitted to the message middleware successfully, the problem of reliable transmission of data by the message middleware is responsible.
No repeat transfer
The non-repetition propagation is the function that the breakpoint continues to transmit, especially suitable for the network unstable environment, saves the network resources.
Asynchronous transport
Asynchronous transmission means that both parties to the message do not have to be online at the same time and have offline capability and security.
Message-driven
The message receiver is actively notified when the message is received.
Support Transactions
An application can combine some data updates into a single unit of work, which is usually logically related and, in order to ensure data integrity, all updates must succeed or fail at the same time.
comparison of commonly used MQ products
|
ActiveMQ |
Joram |
HornetQ |
Openmq |
Mulemq |
SonicMQ |
RabbitMQ |
ZeroMQ |
| Attention level |
High |
In |
In |
In |
Low |
Low |
High |
In |
| Maturity level |
Mature |
More mature |
More mature |
More mature |
New Product No success case |
Mature |
Mature |
Not mature |
| Affiliated Communities/Companies |
Apache |
OW2 |
Jboss |
Sun |
Mule |
Progress |
|
|
| Community activity Level |
High |
In |
In |
Low |
High |
Low |
High |
Low |
| Document |
Many |
Many |
In |
In |
Less |
Less |
Many |
In |
| Characteristics |
Fully functional, used by a large number of open source projects |
|
Performance is greatly improved by invoking the operating system's AIO directly on the Linux platform |
|
Very good performance, seamless integration with MULEESB |
Commercial MQ with superior performance |
Very good performance due to the concurrency of the Erlang language |
Low latency, high performance, up to 430,000 messages per second |
| Authorization method |
Open source |
Open source |
Open source |
Open source |
Business |
Business |
Open source |
Open source |
| Development language |
Java |
Java |
Java |
Java |
Java |
Java |
Erlang |
C |
| Supported protocols |
Openwire, STOMP, REST, XMPP, AMQP |
Jms |
Jms |
Jms |
Jms |
Jms |
Amqp |
TCP, UDP |
| Client Support languages |
Java, C, C + +, Python, PHP, Perl,. NET, etc. |
Java |
Java |
Java |
Java |
Java, C, C + +,. Net |
Java, C, C + +, Python, PHP, Perl, etc. |
Python, Java, PHP,. NET, etc. |
| Persistence of |
Memory, file, database |
Memory, File |
Memory, File |
Memory, File |
Memory, File |
Memory, file, database |
Memory, File |
Save on message send side |
| Transaction |
Support |
Support |
Support |
Support |
Support |
Support |
Not supported |
Not supported |
| Cluster |
Support |
Support |
Support |
Support |
Support |
Support |
Support |
Not supported |
| Load Balancing |
Support |
Support |
Support |
Support |
Support |
Support |
Support |
Not supported |
| Management interface |
So so
|
So so |
No |
So so |
So so |
Good |
No |
No |
| Deployment method |
Standalone, embedded |
Standalone, embedded |
Standalone, embedded |
Standalone, embedded |
Independent |
Independent |
Independent |
Independent |
| Evaluation |
Mature and stable, open source preferred |
dependent containers, not for cross-language calls |
Not a long time to launch, no use cases, not suitable for cross-language calls |
dependent containers, not for cross-language calls |
Not a long time to launch, no success story, currently only support Java |
Mature and Stable |
When the number of queue is greater than 50, the service can not be sustained stably under high concurrency. |
transactions, clusters are not supported, and messages cannot be persisted on the server side |
MQ applicable Scenarios Introduction
MQ Message Queuing is generated by the concept of should be shipped, which transmits the message reliably to the consumer's base product in an asynchronous way, with the queue and the publish subscription as the message transmission mechanism.
It is widely used in the cross-platform, cross-system distributed systems, providing them with efficient and reliable asynchronous transmission mechanism. Message Channel
Use MQ to connect clients and services that collaborate with each other so that they can exchange messages.
If the client and the server need secure and reliable interaction, an MQ queue can be used as a secure channel and the client and the server can communicate with each other safely and efficiently.
