Understanding of MQ, JMS and ActiveMQ relationships

 

MQ, JMS and ActiveMQ

A standard or a protocol of ms. It is usually used for message passing in enterprise-level applications. There are mainly topic messages (1-to-many), queue messages (1-to-1).

activemq is an implementation of jms, from apache.
In addition, there are other implementations of jboss...
 
 

Introduction to MQ:

MQ stands for Message Queue, and Message Queue (MQ) is an application-to-application communication method. Applications communicate by writing and retrieving application-specific data (messages) in and out of the queue without requiring dedicated connections to link them. Messaging refers to the communication between programs by sending data in messages, rather than by calling each other directly, which is typically used for techniques such as remote procedure calls. Queuing refers to applications communicating through queues. The use of queues removes the requirement that the receiving and sending applications execute simultaneously. One of the more mature MQ products is IBMWEBSPHERE MQ.

MQ features:

A typical representative of MQ's consumer-producer model, one end continuously writes messages to the message queue, while the other end can read or subscribe to the messages in the queue. MQ is similar to JMS, but the difference is that JMS is a standard and API definition of SUN  Java message middleware service, while MQ is a specific implementation and product that follows the AMQP protocol.

scenes to be used:

In the project, some time-consuming operations that do not need immediate return are extracted and processed asynchronously, and this asynchronous processing method greatly saves the server's request response time, thereby improving the system throughput.

Introduction to JMS:

JMS is the Java Message Service ( Java  Message Service) API, which is an API for message-oriented middleware (MOM) in the Java platform. It is used to send messages between two applications or in a distributed system for asynchronous communication. . Java Message Service is a platform-independent API, and most MOM providers support JMS.

definition:

JMS ( java  Messaging Service) is a technical specification for message-oriented middleware (MOM) on the Java platform. It facilitates the exchange of messages between Java applications in the message system and simplifies enterprises by providing standard interfaces for generating, sending and receiving messages. Application development, translated into Java message service.

Introduction:

JMS is a vendor-independent API for accessing messaging system messages. It is similar to JDBC (Java DatabaseConnectivity): here, JDBC is an API that can be used to access many different relational databases , while JMS provides the same vendor-independent access methods to access messaging services. Many vendors currently support JMS, including IBM's MQSeries, BEA's Weblogic JMS service, and Progress's SonicMQ, just to name a few. JMS enables you to send messages from one JMS client to another 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 routing information and metadata about the message. The message body carries the application's data or payload. According to the type of payload, the message can be divided into several types, which carry: simple text (TextMessage), serializable object (ObjectMessage), property collection (MapMessage), byte stream (BytesMessage), raw A stream of values ​​(StreamMessage), and a message without payload (Message).

The relationship between JMS and MQ:

JMS is a technical specification for providing message services, which formulates all data structures and interaction processes in the entire process of providing message services. MQ is a message queue service, the final implementation of message-oriented middleware (MOM), and a real service provider; the implementation of MQ can be based on JMS or other specifications or standards.

Open source MQ that supports JMS:

Currently the most selected is ActiveMQ .

ActiveMQ is the most popular and powerful open source message bus produced by Apache. ActiveMQ is a JMS Provider implementation that fully supports the JMS1.1 and J2EE 1.4 specifications. Although the JMS specification has been published for a long time, JMS still plays a special role in today's J2EE applications.

main feature:

1. Write clients in multiple languages ​​and protocols. Languages: Java, C, C++, C#, Ruby, Perl,  PythonPHP . Application Protocol: OpenWire, Stomp REST, WSNotification, XMPP, AMQP

2. Fully supports JMS1.1 and J2EE 1.4 specifications (persistence, XA messages, transactions)

3. For the support of spring , ActiveMQ can be easily embedded into the system using Spring, and also supports the features of Spring 2.0

4. Passed the test of common J2EE servers (such as Geronimo, JBoss 4, GlassFish, WebLogic) , in which ActiveMQ can be automatically deployed to any compatible J2EE 1.4 commercial server through the configuration of JCA 1.5 resource adaptors

5. Support multiple transmission protocols: in-VM, TCP, SSL, NIO, UDP, JGroups, JXTA

6. Support high-speed message persistence through JDBC and journal

7. The design ensures high-performance clustering, client-server, point-to-point

8. Ajax support

9. Support integration with Axis

10. It is easy to call the embedded JMS provider for testing

11. ActiveMQ is very fast; generally 10 times faster than jbossMQ.

优点:是一个快速的开源消息组件(框架),支持集群,同等网络,自动检测,TCP,SSL,广播,持久化,XA,和J2EE1.4容器无缝结合,并且支持轻量级容器和大多数跨语言客户端上的Java虚拟机。消息异步接受,减少软件多系统集成的耦合度。消息可靠接收,确保消息在中间件可靠保存,多个消息也可以组成原子事务。

缺点:ActiveMQ默认的配置性能偏低,需要优化配置,但是配置文件复杂,ActiveMQ本身不提供管理工具;示例代码少;主页上的文档看上去比较全面,但是缺乏一种有效的组织方式,文档只有片段,用户很难由浅入深进行了解,二、文档整体的专业性太强。在研究阶段可以通过查maillist、看Javadoc、分析源代码来了解。

ActiveMQ应用场景:

1、 不同语言应用集成

ActiveMQ 中间件用Java语言编写,因此自然提供Java客户端 API。但是ActiveMQ 也为C/C++、.NET、Perl、phppython、Ruby 和一些其它语言提供客户端。在你考虑如何集成不同平台不同语言编写应用的时候,ActiveMQ 拥有巨大优势。在这样的例子中,多种客户端API通过ActiveMQ 发送和接受消息成为可能,无论使用的是什么语言。此外,ActiveMQ 还提供交叉语言功能,该功能整合这种功能,无需使用远程过程调用(RPC)确实是个优势,因为消息协助应用解耦。

2、 作为RPC的替代

使用RPC同步调用的应用十分普遍。假设大多数客户端服务器应用使用RPC,包括ATM、大多数WEB应用、信用卡系统、销售点系统等等。尽管很多系统很成功,但是转换使用异步消息可以带来很多好处,而且也不会放弃响应保证。使用同步请求的系统在规模上有较大的限制,因为请求会被阻塞,从而导致整个系统变慢。如果使用异步消息替代,可以很容易增加额外的消息接收者,使得消息能被并发消耗,从而加快请求处理。当然,你的系统应用间应该是解耦的。

3、 应用之间解耦

正如之前讨论的,紧耦合架构可以导致很多问题,尤其是如果他们是分布的。松耦合架构,在另一方面,证实了更少的依赖性,能够更好地处理不可预见的改变。不仅可以在系统中改变组件而不影响整个系统,而且组件交互也相当的简单。相比使用同步的系统(调用者必须等待被调用者返回信息),异步系统(调用方发送消息后就不管,即fire-and-forget)能够给我们带来事件驱动架构(event-driven architecture EDA)。

4、 作为事件驱动架构的主干

解耦,异步架构的系统允许通过代理器自己配置更多的客户端,内存等(即vertical scalability)来扩大系统,而不是增加更多的代理器(即horizontal scalability)。考虑如亚马逊这样繁忙的电子商务系统。当用户购买物品,事实上系统需要很多步骤去处理,包括下单,创建发票,付款,执行订单,运输等。但是用户下单后,会立即返回“谢谢你下单”的界面。不只是没有延迟,而且用户还会受到一封邮件表明订单已经收到。在亚马逊下单的例子就是一个多步处理的例子。每一步都由单独的服务去处理。当用户下单是,有一个同步的体积表单动作,但整个处理流程并不通过浏览器同步处理。相反地,订单马上被接受和反馈。而剩下的步骤就通过异步处理。如果在处理过程中出错,用户会通过邮件收到通知。这样的异步处理能提供高负载和高可用性。

5、 提高系统扩展性

Many systems that use event-driven design are for high scalability, such as e-commerce, government, manufacturing, online gaming, etc. Separating business processing steps to individual applications through asynchronous messages opens up many possibilities. Consider designing an app to accomplish a specific task. This is service-oriented architecture (SOA). Each service performs one function and only one function. Applications are composed through services that use asynchronous messaging and eventual consistency. Such a design can introduce a complex event processing concept (complex event processing CEP). Using CEP, interactions between components can be recorded and tracked. In an asynchronous messaging system, it is easy to add a layer of processing between components.

other open source JMS vendors;

jbossmq(jboss 4)

jboss messaging (jboss 5)

joram-4.3.21 2006-09-22

openjms-0.7.7-alpha-3.zipDecember 26,2005

mantamq

ubermq

SomnifugiJMS 2005-7-27

Most of the open source JMSProviders have stopped developing, and the remaining few have found their owners and are linked to some kind of J2EE server, such as jbossmq and jboss, joram and jonas (objectweb organization), ActiveMQ and Geronimo (ASF APACHE foundation organization) ), and between these three, from the bottom layer of the network, only ActiveMQ uses NIO. From this point of view, ActiveMQ will have certain advantages in performance.

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326256218&siteId=291194637