MOM的架构 JMS消息模型

缺乏、安全感 2023-10-17 11:32 136阅读 0赞

本文转自：http://blog.csdn.net/michaelwubo/article/details/50877363 谢谢大神的辛苦之作！！

## MOM的架构 ##

#### 什么是MOM ####

MOM是消息中间件。基本思想，思想就是A和B两个应用程序不直接发送消息。企业消息系统，即面向消息的中间件（MOM），提供了以松散耦合的灵活方式集成应用程序的一种机制。它们提供了基于存储和转发的应用程序之间的异步数据发送，即应用程序彼此不直接通信，而是与作为中介的MOM 通信。MOM提供了有保证的消息发送，应用程序开发人员无需了解远程过程调用（PRC）和网络/通信协议的细节。

##### 之前之后的对比 #####

> 之前的做法：  
> A和B直接发送消息有很多效率问题，如A发送之后B没有及时接受，那么A就一直再在那里堵塞并发性不好，A必须等B接受完之后有返结果了A才可以结束。
> 
> 有了MOM之后的做法：  
> 而MOM就是为了解决这样的问题，不让A与B之间交互，在A和B之间加一个消息中间件，A把消息放到消息中间上，就可以走了，去做别的事情，B什么时候来消息中间件取消息A不用知道也不用管。这样就提高了效率提供并发性，等B去走后可以通过状态，通知，回调等方式通知A就可以。

##### 当时的现状 #####

市面上实现这种思想的技术有很多，ibm(MQServices)Microsoft(MSMQ)以及BEA的MessageMQ，activemq，Kafka等。处于百家争鸣阶段都是各自实现各自的，没有统一实现标准。

##### 制定规范 #####

sun公司为了解决2中的百家争鸣的现象指定一套规范，以后大家就按照这个规范来实现MOM消息中间件，既JMS（[Java ][Java]Message Service）规范横空出世。

#### JMS ####

我们先来看看下图，应用程序A将Message发送到服务器上，然后应用程序B从服务器中接收A发来的消息，通过这个图我们一起来分析一下JMS的好处  
![JMS流程图][JMS]

##### 什么是JMS #####

JMS是一系列的接口及相关语义的集合，通过这些接口和和其中的方法，JMS客户端如何去访问消息系统，完成创建、发送、接收和读取企业消息系统中消息。  
在JMS之前，每一家MOM厂商都用专有API为应用程序提供对其产品的访问，通常可用于许多种语言，其中包括[Java][Java 1]语言。JMS通过MOM为Java程序提供了一个发送和接收消息的标准的、便利的方法。用JMS编写的程序可以在任何实现JMS标准的MOM上运行。  
JMS可移植性的关键在于：JMS API是由Sun作为一组接口而提供的。提供了JMS功能的产品是通过提供一个实现这些接口的提供者来做到这一点的。开发人员可以通过定义一组消息和一组交换这些消息的应用程序，建立JMS应用程序，实现异步通讯。

##### JMS的目标 #####

JMS从提出以来，致力于完成如下几个目标：  
1.定义一组消息公用概念和实用工具。  
所有Java应用程序都可以使用JMS中定义的API去完成消息的创建、接收与发送，任何实现了JMS标准的MOM都可以作为消息的中介，完成消息的存储转发。  
2.最大化消息应用程序的可移植性。  
MOM提供了有保证的消息发送，应用程序开发人员无需了解远程过程调用（PRC）和网络/通信协议的细节，提供了程序的可移植性。  
3.最大化降低应用程序与应用系统之间的耦合度。  
由于MOM的存在，各个应用程序只关心和MOM之间如何进行消息的接收与发送，而无需关注MOM的另一边，其他程序是如何接收和发送的

##### 提供消息灵活性 #####

应用程序A与应用程序B通过使用MOM的应用程序编程接口（API）发送消息进行通信。MOM 将消息路由给应用程序B，这样消息就可以存在于MOM中，MOM 负责处理网络通信。如果网络连接不可用，MOM会存储消息，直到连接变得可用时，再将消息转发给应用程序B。  
灵活性的另一方面体现在，当应用程序A发送其消息时，应用程序B甚至可以不处于执行状态。MOM将保留这个消息，直到应用程序B开始执行并试着检索消息为止。这还防止了应用程序A因为等待应用程序B检索消息而出现阻塞。  
这种异步通信要求应用程序的设计与现在大多数应用程序不同，不过对于时间无关或并行处理，它可能是一个极其有用的方法。

##### JMS两种消息模型 #####

![这里写图片描述][20160313132654750]  
从图中可以看出，ClientA和ClientB是消息生产者，通过两种不同的目的地分别向ClientC、ClientD、ClientE和ClientF发送消息。  
在ClientA、C、D之间的消息是点对点模型，使用这种模型，客户端发送消息到队列目的地（Queue），从这个队列里面只有一个消息接收者可以收到那个消息，其他访问同一目的地的接收者不会接收到该消息。如ClientC接收Queue中的Msg1消息，ClientD接收Queue中的Msg2消息。  
在ClientB、E、F之间的消息是发布／订阅模型。使用这种广播模型，一个客户端发送消息给主题目的地（Topic），任何数量的消费订阅者可以从这个主题目的地来接收它们。如：ClientE和ClientF都接收这个Msg3这条消息。

###### 点到点（P2P） ######

点对点传递模型：生产者发送消息到一个特定的队列（Queue）中，而消费者从一个消息队列中得到消息，如下图所示

![这里写图片描述][20160313133003431]  
点对点模型的特点：

Ø 每条消息有一个消费者

每条只有一个消费者，如果一条消息被消息者接收，那么其他的消费者就不能得到这条消息了。

Ø 发送和接受消息与时间没有关系

也就是说，生产者在发送消息后，消费者可以在任意的时刻接收，但有两个前提：
    
            1、消息未过期
    
            2、消息没有被其他的用户接收
    
      消费者也可以先运行，当生产者一运行，将消息发送到队列中，消费者即可从队列中获得消息，这叫“守株待兔“。

Ø 消费者必须确认对消息的接收

收到消息后消费者必须确认消息已被接收，否则JMS服务提供者会认为该消息没有被接收，那么这条消息仍然可以被其他人接收。程序可以自动进行确认，不需要人工干预。

Ø 非持久的消息最多只发送一次

非持久的消息最多只发送一次，表示消息有可能未被发送，造成未被发送的原因可能有：
    
            1、 JMS服务提供者出现宕机等情况，造成非持久信息的丢失
    
            2、 队列中的消息过期，未被接收

Ø 持久的消息严格发送一次

我们可以将比较重要的消息设置为持久化的消息，持久化后的消息不会因为JMS服务提供者的故障或者其他原因造成消息丢失。

###### 发布/订阅(Pub/Sub) ######

发布/订阅模型：发布/订阅传递消息类型与主题（Topic）有关。生产者发布消息，而消费者订阅感兴趣的消息，生产者将消息和一个特定的主题（Topic）连在一起，消息传递系统（MOM）根据消费者注册的兴趣，将消息传递给消费者。这种类型非常类似出版报纸、杂志的形式，如下图所示：![这里写图片描述][20160313133337138]  
发布/订阅模型的特点：

Ø 每个消息都可以有多个（0，1，……）订阅者

每条消息可以有多个消费者，如果报纸和杂志一样，谁订阅了谁都可以获得。

Ø 订阅者只能消费他们订阅之后出版的消息

这就要求订阅者必须先订阅，生产者再发布。即订阅者必须先运行，再等待生产者的运行，这和点对点类型有所差异。

Ø 订阅者必须保持为活动状态才能使用这些消息

即订阅者必须保持活动状态等待发布者发布的消息，如果订阅者在发布者发布消息之后才运行，则不能获得先前发布者发布的消息。

[Java]: http://lib.csdn.net/base/java
[JMS]: https://img-blog.csdn.net/20160313131343550
[Java 1]: http://lib.csdn.net/base/javase
[20160313132654750]: https://img-blog.csdn.net/20160313132654750
[20160313133003431]: https://img-blog.csdn.net/20160313133003431
[20160313133337138]: https://img-blog.csdn.net/20160313133337138