基于面向消息中间件的SOA系统集成技术探索.docx
《基于面向消息中间件的SOA系统集成技术探索.docx》由会员分享，可在线阅读，更多相关《基于面向消息中间件的SOA系统集成技术探索.docx（13页珍藏版）》请在冰点文库上搜索。
基于面向消息中间件的SOA系统集成技术探索
基于MOM-面向消息中间件的SOA系统集成技术探索
一、什么是MOM？
MOM是Message-OrientedMiddleware（面向消息的中间件）的缩写，MOM的作用就是利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成，通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信，并支持多通讯协议、语言、应用程序、硬件和软件平台。
目前流行的MOM产品有IBM的WebSphereMQ和基于JMS标准的系列中间件等。
二、MOM特点
MOM是一个基础架构，在基于MOM的通信环境中，通常是异步地发送和接受消息，它将应用抽象地划分为发送者和接收者，它们之间无需彼此了解，MOM最重要的作用就是将消息转发到它们的目的地。
下图就是MOM的简单模型图:
从上图可以看出，为了支持消息传递的异步模型，MOM位于客户端和服务器之间，使用消息队列临时存储调用，并允许客户端和服务器分别在不同的时候运行，消息的目标端也不需要立即处理消息，并且客户端和服务器的程序之间不需要彼此知道对方的存在，它们之间不需要考虑它们之间的网络通讯复杂性。
MOM不同于普通的通讯系统的地方在于，通讯的接收和发送两端必须同时运行，并且消息必须即时处理。
三、MOM原理
MOM要实现高效可靠的消息传递机制，必须实现以下三大功能：
●实现消息的异步发送和接收，实现发布/订阅模式
●实现消息的持久化，保证消息可靠性传输
●优化网络传输，支持断点续传
要实现以上三大功能，需要实现消息队列，消息队列为构造以同步或异步方式实现的分布式应用提供了松耦合的方式，队列是消息的安全存放的位置，队列存储消息直到它被应用程序处理，这样的工作机制，能够保证在各种网络环境下能够可靠的传递。
在消息队列的应用上，各个不同的MOM产品应用上有所不同，例如，JMS标准的MOM和IBMWebsphereMQ实现上就有所区别。
从上图，可以看出IBMWebSphereMQ的结构和JMS结构在队列的应用上略有不同，IBMWebSphereMQ在客户机上存在有传输队列，而JMS在客户机方面不存在任何队列，所以说JMS相对于MQ而言，只是规范了消息的存取，而没有规范消息数据的传输，因为JMS客户机并不拥有存放数据的队列，所以所有发送的操作都要由应用程序来控制，JMS服务器本身不代理传输，也不保证数据在远程队列间的传输可靠性。
IBMMQ通过通道与传输队列和远程队列来保证队列间的传输可靠性，IBMMQ支持客户端的断网续传，而客户端的应用程序不用做任何工作，但是，这种方式需要客户端本地安装MQ的客户端。
四、MOM通讯模式
MOM主要存在3工作模式：
点对点模式、发布/订阅模式以及消息队列模式，其中，点对点模式和发布/订阅模式统称为消息传递模式。
●点对点模式（Point-to-Point）
点对点模式用于消息生产者和消息消费者之间点到点的通信，是一种程序到程序的直接通信模式。
消息生产者将消息发送到由某个名字标识的特定消费者，点对点消息允许客户端通过队列这个虚拟通道来同步和异步发送、接收消息，传统上，点对点模型是一个基于拉取（Pull）或基于轮询（Polling）的消息传递模式，这种模型从队列中请求消息，而不是自动地将消息推送到客户端。
点对点消息传送模型的一个突出特点就是：
发送到队列的消息被一个而且仅仅一个接收者所接收，即使可能有多个接收者在一个队列中侦听同一消息时，也是如此。
●发布订阅模式（Publish-and-Subscribe）
在发布/订阅模型中，消息会被发布到一个名为主题（topic）的虚拟通道中。
消息生产者称为发布者（publisher），而消息消费者则称为订阅者（subscriber）。
与点对点模型不同，使用发布/订阅模型发布到一个主题的消息，能够由多个订阅者所接收。
有时候，也称这项技术为广播（broadcasting）消息。
每个订阅者都会接收到每条消息的一个副本。
总地来说，发布/订阅消息传送模型基本上是一个基于推送（push）的模型，其中消息自动地向消费者广播，它们无须请求或轮询主题来获得新消息。
如上图所示，在发布/订阅模式下，没有传统意义上的客户端和服务器，而是在网络中进行消息发布的应用程序和接收某个特定主题消息的应用程序，发布消息的客户端将消息传递给消息代理，有消息代理负责路由消息给相应的订阅消息的客户端，由消息代理实现消息的动态路由，发布者和订阅者在空间上是松耦合的，客户端和服务器不需要知道对方的地址和具体的数量，简化了配置，更容易重用。
这种模式也是目前应用最广泛的模式。
●消息队列模式
消息队列模式是一种程序之间的无连接的通信模式，它允许程序通过消息队列进行通信，它将消息放入队列（通常基于内存和硬盘）直接或者按顺序传送，这种方式允许程序按照不同的速度独立运行，而不需要双方之间建立一条逻辑连接。
这种模式需要系统中包含有队列管理器，用于处理本地队列，保证消息传送到存在于本机或者网络中某个位置的目的地。
队列管理器与其他节点上的队列器合作控制网络路由机制。
支持不同Qos（服务质量），包括：
●Qos0至多一次
消息会丢失或重复，但是只发送一次
●Qos1至少一次
确保消息到达，但消息重复可能会发生。
●Qos2只有一次
确保消息到达一次
消息队列可以是永久性或者非永久性的，永久性的消息存放在硬盘上，非永久性的消息存放在内存中，当队列管理器出现故障时，非永久性队列的消息会全部丢失，而永久性的消息会自动恢复。
消息队列支持触发，当请求消息和应答消息到达本地队列，但是应用程序未处于活动状态时，自动启动这个应用程序。
这种方式只有在工作需要完成时，处于活动状态，从而避免不必要的资源浪费。
目前，IBMMQ主要采用就是这种消息队列模式。
五、MOM消息传递模式比较
●点对点模型
在点对点模式下，每个消息都被发送到特定的队列，接收者从队列中获取消息，队列保留着消息，直到它们被消费或者超时。
Ø每个消息只有一个消费者（Consumer）（即一旦被消费，消息就不再在消息队列中）
Ø发送者和接收者之间在时间上没有依赖性，也就是说当发送者发送了消息之后，不管接收者有没有正在运行，它不会影响到消息被发送到队列。
Ø接收者在成功接收消息之后需向队列应答成功
这种模式保证发送的每条消息都被消费者成功接收。
●发布/订阅模型
在发布/订阅模型中，客户端将消息发送到主题。
多个发布者将消息发送到Topic，系统将这些消息传递给多个订阅者。
Ø每个消息可以有多个消费者
Ø发布者和订阅者之间有时间上的依赖性。
针对某个主题（Topic）的订阅者，它必须创建一个订阅之后，才能消费发布者的消息，而且，为了消费消息，订阅者必须保持运行的状态。
当然，为了缓和这种严格的时间相关性，有些MOM系统，例如利用了JMS的MOM系统,允许订阅者创建一个可持久化的订阅。
这样，即使订阅者没有被激活（运行），它也能接收到发布者的消息。
在JMS中，持久化订阅者可以定义为durable（持久化的），持久化的订阅者注册一个带有JMS保持的唯一标识的持久化订阅，带有相同标识的后续订阅者会再续前一个订阅者的订阅状态，如果持久化订阅没有活动的订阅者，JMS会保持订阅消息，知道消息被订阅接收或者过期。
如果希望发送的消息可以不被做任何处理、或者被一个消费者处理、或者可以被多个消费者处理的话，那么可以采用发布/订阅模型。
六、系统业务集成的目标
信息系统业务集成的目标是构建一个开放、松散耦合的系统集成环境，就目前公司开发的各个产品而言，存在多平台、多开发语言的特点，比如ZLHIS基于VB6+Windows平台、ZLBH基于.net+Windows平台、移动临床基于Java+Android和ObjectC+IOS两种平台、社区一部分产品基于B/S架构运行于浏览器，而且在具体实施时还面临第三方厂商业务集成的需要。
由于各系统采用的技术路线不统一，进行业务集成是，需要开发新的接口或者采用其他集成方法，最终导致业务集成成本提高，增加了现有系统的复杂程度，而且随着各个应用系统上的业务交叉点越来越广，传统的数据集成已经不能满足现实的需求，需要一种支持业务流程编排重组的业务流程集成方式才能解决。
SOA是一种软件系统架构和软件设计模式，而WebService是就目前而言最适合实现SOA架构的核心技术，WebService基于XML、SOAP、WSDL和UDDI协议形成了实现SOA的一系列技术的集合。
企业服务总线（EnterpriseServiceBus，ESB）为SOA系统的实现提供了一个核心架构，是一种分布式的集成框架，ESB相当于一个WebService的组装平台，它支持各个异构系统间通过Webservice实现面向服务的交互，ESB智能的在企业系统间路由数据流，配合和转换各个系统需要的数据信息，为SOA提供一种连通性基础架构，用以连接SOA中的各个服务。
这种模式有助于减少应用接口的数据量和复杂性。
七、MOM在ESB中的应用
ESB概念的四个支柱-MOM、WebService、数据变换和路由智能，其中MOM是ESB实现消息和事件驱动的核心技术，对于ESB而言，可靠的传输是ESB的基础，比如IBMMessageBroker就是建立于IBMMQ基础之上的（这里从名字也可以看得出来），OracleServiceBus是基于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的功能。
目前，常见的厂商ESB产品有IBMWebSphereESB、IBMWebSphereMessageBroker和OracleServiceBus,其中IBMWebSphereESB是一种基于平台（基于WebSphereApplicationServer）的ESB，IBMWebSphereMessageBorker是一种跨平台的ESB，应用于对性能要求相对较高，多种复杂协议存在的集成环境中。
OracleServiceBus是标准的J2EE实现的ESB产品。
IBM的ESB中的MOM是主要采用的是IBMWebSphereMQ，当然也可以支持JMS。
OracleServiceBus中的MOM主要采用的是JMS技术。
八、IBMMQ和JMS比较
●IBMMQ
IBMMQ是一种基于消息队列模式的消息传输技术，负责两个异构系统之间传递消息，使用简单，而且具有很高的性能和可靠性，IBM号称：
一旦发出保证到达。
更为重要的是它对各个平台支持都非常好，几乎所有想得到的硬件和操作系统平台以及编程语言，MQ都有专门的API支持。
MQ的功能只限于消息队列传输，如果需要实现MQ的消息路由和消息转换必须要使用IBMMesssageBroker。
MQ的消息队列模式需要依赖于队列管理器，队列管理器可以位于相同或不同的计算机上，它们可以彼此通信，并在不同的队列管理器的队列之间传递消息，队列管理器为消息提供了可靠的传递。
●JMS-JavaMessageService
JMS应用程序接口是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。
Java消息服务是一个与具体平台无关的API，绝大多数MOM提供商都对JMS提供支持。
JMS支持点对点和发布/订阅模式，但是不支持队列传输模式，而且不支持客户机上的消息队列，所以JMS并不能保证对远程队列的传输可靠性。
●比较
从上面几点来看，MQ的设计不论在性能和可靠性上都比JMS的MOM要好，MQ支持更多的通信协议，而JMS只支持TCP/IP,另外，MQ在各种平台和开发语言的支持上，明显优于JMS，JMS只支持JAVA的开发环境，而且只支持J2EE规范，不支持J2SE规范。
但是，如果只是仅仅采用IBMMQ进行数据传输，代价并不大，但是要利用MQ实现消息路由和数据转换，就必须要采用IBMMessageBroker，这样的代价就不小了。
另外对于IBMMQ的本地队列在移动设备上是不是存在还存在疑问，如果在移动设备上不存在本地队列传输，MQ在移动设备上的传输可靠性的优点就不能够表现了。
对于目前的应用而言，这两大ESB产品除了MOM的功能值得商榷研究以外，其他三大支柱功能的差别只是在性能以及特殊应用场景上的差别，但从目前来看OracleServiceBus的JMS在应用上完全不能满足现在的需要，最为致命的一点就是JMS不支持提供目前的VB、.NET和IOS开发平台的API。
要使用JMS，首先要解决JMS客户端的问题，毕竟JMS在J2EE平台上应用的还是比较广泛的，例如，IOS设备以及非Java的软件应用JMS的需求还是比较多的，比如.NET应用JMS，现在有专门的公司开发出JMSAdapterFor.NET,帮助.NET程序来连接JMS，另外一种方案是通过MQ封装JMS消息，利用MQ对JMS进行中转，然后其他客户端比如iOS通过MQ接收消息。
而最新的方式是通过MQTT通讯协议来实现跨平台的应用。
九、MQTT-面向于未来的通讯技术
IBMWebSphereMQTelemetryTransport（简称MQTT）是一种基于TCP/IP的轻量级发布/订阅消息传输协议，用于连接大量的远程传感器和控制设备，而有可能成为物联网的重要组成部分。
在必须允许低带宽和不可靠的通信并且占用较少内存的设备上，专业化的应用程序就使用MQTT协议。
用户可以编写自己的客户机以使用已发布的协议。
MQTT产品作为WebSphereMQ产品的扩展，使用了MQTTV3.1版本的协议。
它提供了一些小型客户机库，可以将这些客户机库嵌入到运行于不同设备平台上的智能设备中。
使用客户机构建的应用程序使用MQTelemetryTransport（MQTT）和WebSphereMQTelemetry服务并借助WebSphereMQ来可靠地发布和预订消息。
一个高级MQTT客户机（即设备的WebSphereMQTelemetry守护程序）可以运行于多种平台上。
它可以充当一个网络集中器，能够将更多的MQTT客户机连接至单个队列管理器。
对于在网络发生短暂中断期间无法缓存消息的小型设备，它还可以为这些小型设备提供存储转发功能。
该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和致动器（比如通过Twitter让房屋联网）的通信协议
归根结底，MQTT协议是为大量计算能力有限，且工作在低带宽、不可靠的网络的远程传感器和控制设备通讯而设计的协议，它具有以下主要的几项特性：
1、非常小的通信开销（最小的消息大小为2字节）；
2、支持各种流行编程语言（包括C，Java，Ruby，Python等等）且易于使用的客户端；
3、支持发布/预定模型，简化应用程序的开发；
4、提供三种不同消息传递等级，让消息能按需到达目的地，适应在不稳定工作的网络传输需求
MQTT是一个开发式的通信协议，它是WebSphereMQ7.0.1.3版本以上的插件，它可以直接和WebSphereMQ进行通信，但是MQTT所使用的服务器不仅仅只限于IBMWebSphereMQ，目前还有很多开源的MQTT服务器，同时，因为是开发式的通信协议，MQTT的客户端在很多平台上存在，比如FaceBook最近发布了新版的iOS应用，使用了MQTT更新通知、消息和书签等等。
除了IOS，MQTT还支持JAVA、C#、C、C++、Delphi、Erlang、ActionScript、Object-C、Python等多种开发平台以及操作系统。
MQTT的服务器平台除了WebSphereMQ还有很多，比如：
Mosquitto、ApacheActiveMQ等等，下表是各个服务器之间的比较
Server
QoS0
QoS1
QoS2
auth
bridge
$SYS
SSL
dynamictopics
Mosquitto
✔
✔
✔
✔
✔
✔
✔
✔
RSMB
✔
✔
✔
✔
✔
✔
✘
✔
WebSphereMQ
✔
✔
✔
✔
✔
✔
✔
✔
ApacheApollo
✔
✔
✔
✔
✘
✘
✔
✔
ApacheActiveMQ
✔
✔
✔
?
?
?
?
?
webMethodsNirvanaMessaging
✔
✔
✔
§
✘
✘
✔
✘
RabbitMQ
✔
✔
✘
✔
✘
✘
✔
✔
MQTT.js
✔
✔
✔
§
✘
✘
✘
✔
moquette
✔
✔
✘
?
?
?
?
?
Key:
✔supported✘notsupported?
unknown§seelimitations
其中值得一提的是ApacheActiveMQ，ActiveMQ是Apache出品，最流行的，能力强劲的开源消息总线。
ActiveMQ是一个完全支持JMS1.1和J2EE1.4规范的JMSProvider实现，并且ActiveMQ可以和WebLogic进行集成，将WebLogic中的消息通过MQTT方式进行发送，从而被MQTT客户端所接收并使用。
JMS+MQTTServer+MQTTClient的通讯模式，不仅能够实现多平台多语言的JMS消息的利用而且能够实现push推送模式，同时MQTT的自身的消息发布质量设置能够保证消息的本身传递的可靠性。
经过JMS+MQTTServer+MQTT改造的应用ESB的出院流程如下：
一十、总结
MOM是ESB实现消息和事件驱动的核心技术，相对于B/S架构的应用系统，目前的C/S架构的系统集成对消息在目前多平台、多语言的产品上的使用以及消息即时推送的机制提出了更高的要求,因此对于系统业务的集成改造，在对ESB产品的选择上，更应慎重对待内置的MOM产品上的选择，因此在实践探索中更需要保持“大胆猜测，小心求证“的态度。
升级会员 