基于面向消息中间件的SOA系统集成技术探索

基于MOM-面向消息中间件的SOA系统集成技术探索一、什么是MOM？MOM是Message-Oriented Middleware（面向消息的中间件）的缩写，MOM 的作用就是利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成，通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信，并支持多通讯协议、语言、应用程序、硬件和软件平台。

目前流行的MOM产品有IBM的WebSphere MQ和基于JMS标准的系列中间件等。

二、MOM特点MOM是一个基础架构，在基于MOM的通信环境中，通常是异步地发送和接受消息，它将应用抽象地划分为发送者和接收者，它们之间无需彼此了解，MOM最重要的作用就是将消息转发到它们的目的地。

下图就是MOM的简单模型图:从上图可以看出，为了支持消息传递的异步模型，MOM位于客户端和服务器之间，使用消息队列临时存储调用，并允许客户端和服务器分别在不同的时候运行，消息的目标端也不需要立即处理消息，并且客户端和服务器的程序之间不需要彼此知道对方的存在，它们之间不需要考虑它们之间的网络通讯复杂性。

MOM不同于普通的通讯系统的地方在于，通讯的接收和发送两端必须同时运行，并且消息必须即时处理。

三、MOM原理MOM要实现高效可靠的消息传递机制，必须实现以下三大功能：●实现消息的异步发送和接收，实现发布/订阅模式●实现消息的持久化，保证消息可靠性传输●优化网络传输，支持断点续传要实现以上三大功能，需要实现消息队列，消息队列为构造以同步或异步方式实现的分布式应用提供了松耦合的方式，队列是消息的安全存放的位置，队列存储消息直到它被应用程序处理，这样的工作机制，能够保证在各种网络环境下能够可靠的传递。

在消息队列的应用上，各个不同的MOM产品应用上有所不同，例如，JMS 标准的MOM和IBM Websphere MQ实现上就有所区别。

从上图，可以看出IBM WebSphere MQ的结构和JMS结构在队列的应用上略有不同，IBM WebSphere MQ在客户机上存在有传输队列，而JMS在客户机方面不存在任何队列，所以说JMS相对于MQ而言，只是规范了消息的存取，而没有规范消息数据的传输，因为JMS客户机并不拥有存放数据的队列，所以所有发送的操作都要由应用程序来控制，JMS服务器本身不代理传输，也不保证数据在远程队列间的传输可靠性。

IBM MQ通过通道与传输队列和远程队列来保证队列间的传输可靠性，IBM MQ支持客户端的断网续传，而客户端的应用程序不用做任何工作，但是，这种方式需要客户端本地安装MQ的客户端。

四、MOM通讯模式MOM主要存在3工作模式：点对点模式、发布/订阅模式以及消息队列模式，其中，点对点模式和发布/订阅模式统称为消息传递模式。

点对点模式（Point-to-Point）点对点模式用于消息生产者和消息消费者之间点到点的通信，是一种程序到程序的直接通信模式。

消息生产者将消息发送到由某个名字标识的特定消费者，点对点消息允许客户端通过队列这个虚拟通道来同步和异步发送、接收消息，传统上，点对点模型是一个基于拉取（Pull）或基于轮询（Polling）的消息传递模式，这种模型从队列中请求消息，而不是自动地将消息推送到客户端。

点对点消息传送模型的一个突出特点就是：发送到队列的消息被一个而且仅仅一个接收者所接收，即使可能有多个接收者在一个队列中侦听同一消息时，也是如此。

●发布订阅模式（Publish-and-Subscribe）在发布/订阅模型中，消息会被发布到一个名为主题（topic）的虚拟通道中。

消息生产者称为发布者（publisher），而消息消费者则称为订阅者（subscriber）。

与点对点模型不同，使用发布/订阅模型发布到一个主题的消息，能够由多个订阅者所接收。

有时候，也称这项技术为广播（broadcasting）消息。

每个订阅者都会接收到每条消息的一个副本。

总地来说，发布/订阅消息传送模型基本上是一个基于推送（push）的模型，其中消息自动地向消费者广播，它们无须请求或轮询主题来获得新消息。

如上图所示，在发布/订阅模式下，没有传统意义上的客户端和服务器，而是在网络中进行消息发布的应用程序和接收某个特定主题消息的应用程序，发布消息的客户端将消息传递给消息代理，有消息代理负责路由消息给相应的订阅消息的客户端，由消息代理实现消息的动态路由，发布者和订阅者在空间上是松耦合的，客户端和服务器不需要知道对方的地址和具体的数量，简化了配置，更容易重用。

这种模式也是目前应用最广泛的模式。

●消息队列模式消息队列模式是一种程序之间的无连接的通信模式，它允许程序通过消息队列进行通信，它将消息放入队列（通常基于内存和硬盘）直接或者按顺序传送，这种方式允许程序按照不同的速度独立运行，而不需要双方之间建立一条逻辑连接。

这种模式需要系统中包含有队列管理器，用于处理本地队列，保证消息传送到存在于本机或者网络中某个位置的目的地。

队列管理器与其他节点上的队列器合作控制网络路由机制。

支持不同Qos（服务质量），包括：●Qos 0至多一次消息会丢失或重复，但是只发送一次●Qos 1 至少一次确保消息到达，但消息重复可能会发生。

●Qos 2 只有一次确保消息到达一次消息队列可以是永久性或者非永久性的，永久性的消息存放在硬盘上，非永久性的消息存放在内存中，当队列管理器出现故障时，非永久性队列的消息会全部丢失，而永久性的消息会自动恢复。

消息队列支持触发，当请求消息和应答消息到达本地队列，但是应用程序未处于活动状态时，自动启动这个应用程序。

这种方式只有在工作需要完成时，处于活动状态，从而避免不必要的资源浪费。

目前，IBM MQ主要采用就是这种消息队列模式。

五、MOM消息传递模式比较●点对点模型在点对点模式下，每个消息都被发送到特定的队列，接收者从队列中获取消息，队列保留着消息，直到它们被消费或者超时。

每个消息只有一个消费者(Consumer)（即一旦被消费，消息就不再在消息队列中）发送者和接收者之间在时间上没有依赖性，也就是说当发送者发送了消息之后，不管接收者有没有正在运行，它不会影响到消息被发送到队列。

接收者在成功接收消息之后需向队列应答成功这种模式保证发送的每条消息都被消费者成功接收。

●发布/订阅模型在发布/订阅模型中，客户端将消息发送到主题。

多个发布者将消息发送到Topic，系统将这些消息传递给多个订阅者。

每个消息可以有多个消费者发布者和订阅者之间有时间上的依赖性。

针对某个主题(Topic)的订阅者，它必须创建一个订阅之后，才能消费发布者的消息，而且，为了消费消息，订阅者必须保持运行的状态。

当然，为了缓和这种严格的时间相关性，有些MOM系统，例如利用了JMS 的MOM系统,允许订阅者创建一个可持久化的订阅。

这样，即使订阅者没有被激活（运行），它也能接收到发布者的消息。

在JMS中，持久化订阅者可以定义为durable（持久化的），持久化的订阅者注册一个带有JMS保持的唯一标识的持久化订阅，带有相同标识的后续订阅者会再续前一个订阅者的订阅状态，如果持久化订阅没有活动的订阅者，JMS会保持订阅消息，知道消息被订阅接收或者过期。

如果希望发送的消息可以不被做任何处理、或者被一个消费者处理、或者可以被多个消费者处理的话，那么可以采用发布/订阅模型。

六、系统业务集成的目标信息系统业务集成的目标是构建一个开放、松散耦合的系统集成环境，就目前公司开发的各个产品而言，存在多平台、多开发语言的特点，比如ZLHIS基于VB6+Windows平台、ZLBH基于.net +Windows平台、移动临床基于Java+Android 和Object C+IOS两种平台、社区一部分产品基于B/S架构运行于浏览器，而且在具体实施时还面临第三方厂商业务集成的需要。

由于各系统采用的技术路线不统一，进行业务集成是，需要开发新的接口或者采用其他集成方法，最终导致业务集成成本提高，增加了现有系统的复杂程度，而且随着各个应用系统上的业务交叉点越来越广，传统的数据集成已经不能满足现实的需求，需要一种支持业务流程编排重组的业务流程集成方式才能解决。

SOA是一种软件系统架构和软件设计模式，而WebService是就目前而言最适合实现SOA架构的核心技术，WebService基于XML、SOAP、WSDL和UDDI协议形成了实现SOA的一系列技术的集合。

企业服务总线（Enterprise Service Bus，ESB）为SOA系统的实现提供了一个核心架构，是一种分布式的集成框架，ESB 相当于一个WebService的组装平台，它支持各个异构系统间通过Webservice实现面向服务的交互，ESB智能的在企业系统间路由数据流，配合和转换各个系统需要的数据信息，为SOA提供一种连通性基础架构，用以连接SOA中的各个服务。

这种模式有助于减少应用接口的数据量和复杂性。

七、MOM在ESB中的应用ESB概念的四个支柱-MOM、WebService、数据变换和路由智能，其中MOM 是ESB实现消息和事件驱动的核心技术，对于ESB而言，可靠的传输是ESB的基础，比如IBM Message Broker就是建立于IBM MQ基础之上的（这里从名字也可以看得出来），Oracle Service Bus是基于JMS基础之上的。

例如，上图中可靠、异步、安全的消息传递机制就是依赖于JMS方式。

这里再举一个例子：上图简单示意了，出院程序如何通过ESB调用重庆医保的Webservice接口和ZLHIS出院结算接口，完成出院结算消息提醒，并通知到ZLHIS和ZLBH客户端以及IOS/android设备客户端。

1、出院程序首先调用ESB上公布的出院WebService，传入病人住院号；2、ESB通过传入的病人住院号调用数据库存储过程，通过病人住院号查询到病人的医保号和身份证号信息以及住院费用信息；3、ESB通过服务编排传入医保号和住院费用信息，调用重庆医保接口获得病人该次住院的医保结算报销费用；4、将出院报销费用和总费用传给zlhis出院结算WebService，检查该病人住院预缴金额是否充足，并将欠费金额组织成格式消息发送到消息代理上，消息代理转发消息至指定病区的护士工作站和移动护士工作站。

5、护士通过订阅消息获得病人出院信息，并作相应处理。

在这里，ESB通过服务组织调用不同的WebService或内置业务逻辑进行消息路由后，获得最终结果消息发送到消息代理，由消息代理将消息可靠的、异步的传输到工作站程序上。

因为目前ZLHIS运行环境的复杂性，消息的传递必须具备以下几个条件1、消息的通知必须是异步的，因为类似于移动设备可能因为移动网络原因和省电的原因，不可能一直保持连接；2、消息的通知必须能够通过推送的方式送达；3、消息接收的客户端要是能够跨平台的；如果要达到以上几点要求，ESB的消息传递就必须使用MOM，而目前厂商的ESB产品内置了MOM的功能。