消息中间件论文（精选7篇）
消息中间件论文 篇1
面向消息的中间件可在分布式环境下扩展进程间的通信,保证数据传送的持久、快速和安全。它的应用不仅满足了跨平台系统集成的需要,同时也减少了系统的开发周期,使得孤立信息应用之间的交互成为可能。TongLINK/Q消息中间件作为众多中间件中的一种,在近些年得到了广泛应用和认可。
1 TongLINK/Q概述
TongLINK/Q是面向分布式应用的消息传送中间件,它为网络环境下各个节点之间构建虚拟的端到端通道,并以节点为基本运行单位实现数据的收发、端对端消息的传输控制以及网络运行状况的监控。
1.1 节点
节点是TongLINK/Q网络结构中的一个基本运行单位,TongLINK/Q通过节点来唯一的区分网络中的每个通信实体。每个节点只有一个IP地址和一个全局唯一的节点名,并具有自已专用运行环境及配置。根据每个节点在网络中的相对位置,节点分为三种类型,即本地节点、上级节点和下级节点。TongLINK/Q网络通讯平台为处于这个平台上的节点之间建立了一个虚拟的数据通道, 称之为TongLINK/Q节点之间的连接。连接的建立均由本地节点向上级节点发起。一个节点可以同时拥有多个上级节点和多个下级节点,通过多上级节点和多下级节点混合使用,可以构造灵活的网络结构。
1.2 消息
在分布式应用中,不同的应用进程之间传递、交换的信息统称为消息。TongLINK/Q系统提供数据报消息(BUF_MSG)、文件 (FILE_MSG)消息、事件消息(EVENT_MSG)三种类型。消息的实时传输指消息必须在规定的时间内必须传递到目标节点。TongLINK/Q在规定时间内提供可靠的传输机制,保证消息传递的实时性和可靠性。消息可靠传输指消息的传递在时间上无特殊的要求,在网络连通的情况下必须保证消息可靠的传递到目标节点。TongLINK/Q在消息提交后,在遇到可恢复的故障(包括机器故障或网络故障)情况下能够保证消息的可靠传输。传递的消息可以是数据包或文件。
1.3 队列
队列是存储消息的数据结构,分为持久和非持久两种,持久队列在磁盘上有相应的映像,持久队列中存储的消息都为持久消息;非持久队列只存在于内存中,非持久队列中的消息都为非持久消息。每个队列都属于一个队列控制单元(QCU),由QCU负责维护。
TongLINK/Q系统提供的队列类型包括:发送队列,接收队列,事件队列。发往目的地的消息要经由发送队列,由核心从发送队列中取消息进行发送;核心收到消息后,将根据发送方的设置放到相应的接收队列中;事件队列属于一个特殊的接收队列,用于存放TongLINK/Q系统产生的事件。
1.4 队列控制单元
队列控制单元,简称QCU。它是一个节点内相对独立运行单元,由数据缓冲区(发送/接收缓冲区)、队列组成,功能主要是对一组队列以及队列内的消息进行监控和管理。包括:队列创建、恢复及消息在数据缓冲区和队列之间的转移等。一个节点可拥有多个QCU,每个QCU在运行上相互独立。一个QCU可对应多个发送进程和接收进程。
2 TongLINK/Q应用案例
TongLINK/Q的传输模式包括路由转发、点对点、和发布订阅。相同的网络结构,不同的应用可以选择不同的传输模式。
2.1 案例一
在全国推广的金融机构理财与资金信托数据报送系统中,各地方性金融机构一点接入人民银行网络进行数据报送的工作。数据采集与报送采用直连接口报送方式,统一通过TongLINK/Q同人民银行总行系统进行报文交换,人民银行省级分支行构建的网间互联平台前置负责TongLINK/Q报文的转发。下图为地方性金融机构、人民银行省级分支行、人民银行总行三者之间TongLINK/Q互连结构图。
网间互联平台前置的TongLINK/Q配置中,其上级节点为人民银行总行的理财与资金信托数据报送系统,节点名称为:SERV-ER_NODE_LCBS,其中LCBS假定为总行节点代码。每个下级节点对应一个金融机构,节点名称为:CLIENT_NODE_XXXX,其中XXXX为节点代码,由人民银行总行统一分配。省级分支行节点在这个互连结构中作为路由(Router)节点在金融机构与人民银行总行之间建立通信通道,仅负责数据的转发,因此没有建立相应的队列,技术实现比较简单。
网络结构中的上下级关系只是节点之间的逻辑关系,下级节点和上级节点之间在建立连接时,是由下级节点主动向上级节点发出连接请求,上级节点决定是否接受此连接请求。省级分支行的节点信息通过TongUser文件进行配置,简单示例如下:
2.1案例二
全国推广的跨境人民币信息管理系统复用案例一中的网络结构,地方性金融机构同样遵循一点接入的模式,通过TongLINK/Q同人民银行总行系统进行报文交换,但省级分支行节点不仅仅作为路由节点,而是需要建立点对点连接来完成TongLINK/Q报文的转发。假定某地方性商业银行的节点代码为10001,该省级人民银行网间互联平台标识为1001,下图为该地方性商业银行、人民银行省级分支行、人民银行总行三者之间TongLINK/Q互连结构图。
人民银行省级分支行网间互联平台前置作为外联机构与总行跨境人民币信息管理系统之间的通信枢纽,接收地方性商业银行的批量报文转发到人民银行总行,或接收人民银行总行的批量报文转发到地方性商业银行。按照命名规范,在人民银行省级分支行网间互联平台前置建立队列控制单元TLQ_RCPMIS_1001_01,建立接收连接Conn100001.1001.B1、远程队列PBC.EXT.BATCH.IN、发送队列PBC.RCPMIS.BATCH.TRAN、发送连接Conn1001.RCPMIS.B1将接收自地方性商业银行的批量报文转发到人民银行总行,建立接收连接ConnRCPMIS.1001.B1、远程队列PBC.100001.BATCH.OUT、发送队列PBC.100001.BATCH.TRAN、发送连接Conn1001.100001.B1将接收自人民银行总行的批量交易报文转发到地方性商业银行。
人民银行省级分支行网间互联平台前置对应总行一个上级节点,下级节点则可能包含多个地方性商业银行。同时,地方性商业银行的加入又是一个循序渐进的过程,并不是一次性的工作。所以在TongLINK/Q前置平台的配置中采用文件和脚本配置相结合的方式,在系统配置文件tlsys.conf中对系统参数进行统一配置,在本例中对应的队列控制单元的配置文件tlqcu_TLQ_RCPMIS_0200_01.conf中对队列、连接等对象进行相应的配置,同时通过以下脚本示例实现商业银行节点的动态增加。
#新增商业银行节点脚本示例
#新增连接
Addchl -qcu TLQ_RCPMIS_1001_01 -cn Conn1001. "商业银行节点代码".B1 -sq PBC."商业银行节点代码".BATCH.TRAN -h "商业银行前置平台IP地址" -p "商业银行前置平台对外服务端口" -mn 20000 -maxms 4194304 -sp 100000
#新增远程队列、发送队列
Addrq -qcu TLQ_RCPMIS_1001_01 -rq PBC. "商业银行节点代码".BATCH.OUT -sq PBC. "商业银行节点代码".BATCH.TRAN - dq PBC. "商业银行节点代码".BATCH.OUT
3 结束语
TongLINK/Q作为能够跨平台运行和交互的消息中间件,为业务应用之间搭建了稳定可靠的沟通桥梁。应用系统可以借助它构造灵活的网络结构,轻松地交换和处理消息,而无需考虑消息传递的具体细节,能够大大降低开发难度,缩短开发周期,节约开发成本。TongLINK/Q的产品易用性和技术优势使其广泛应用于各大、中型企业,并在实际使用中得到了充分的肯定。
摘要：消息中间件利用高效可靠的消息传递机制进行平台无关的数据交流,并基于数据通信来进行分布式系统的集成。TongTech的TongLINK/Q是依据DTP模型,结合实际应用系统的需求而设计开发的中间件产品,可以满足端到端的通信服务和分布式应用的管理需求,同时提供了节点、消息、队列等各种对象。在金融机构理财与资金信托数据报送系统和跨境人民币信息管理系统中,通过应用TongLINK/Q构建了两级消息传递的架构,实现了金融机构与人民银行之间交易报文的双向交互。
关键词：消息中间件,TongLINK/Q,节点,消息,队列
消息中间件在银行业务中的应用 篇2
IBM WebSphere MQ是一个优秀的用于应用系统间联系的软件, 它的原理简单且易理解, 就是消息传递。应用系统就像一群有机生物一样, 它们之间可以各自活动, 也可以相互交流。通过消息传递, 将它们有效地联系起来, 每一个应用系统都可以对外提供自身的功能, 也可以要求其他应用系统作为它的下一处理环节, 消息是应用系统之间请求、应答和中间结果的载体。
一、Web Sphere MQ简介
IBM WebSphere MQ本质上是一种消息中间件, 用于保证异构应用之间的消息传递。应用程序通过MQ接口进行互连通信, 可以不必关心网络上的通信细节, 从而将更多的注意力集中于应用本身。MQ在所有的平台上有统一的操作界面, 这使得应用程序可以很方便地移植到各种操作系统中。
通过WebSphere MQ可以屏蔽不同的通信协议之间的差别, 可以最大限度地简化网络编程的复杂性。通过MQ的配置, 通信双方的程序可以以松耦合的方式独自运行, 并不关心对方所在的位置和状态, 通过消息驱动或消息触发的方式来相互联系。它支持多种平台, 对消息支持交易式的提交和回滚。
WebSphere MQ中间件的主要功能:
(一) 负责客户机和服务器问的联接和通讯提供客户机与应用层的高效率通讯机制;提供应用层不同服务之间的互操作机制;提供应用层与数据库之间的联接和控制机制。
(二) 提供一个多层结构的应用开发和运行平台;提供一个应用开发框架, 支持模块化的应用开发;提供交易管理机制, 保证分布式交易处理结果的一致性;提供应用的负载均衡和高可用性;提供应用的安全机制;提供应用的管理功能等。
二、系统设计
(一) 业务流程
以非税收入收缴管理系统为例, 按照财政相关规定, 实行“单位开票, 银行代收, 财政统管”的管理方式, 在统一工作流程、统一数据库、统一操作平台的基础上, 通过财政外围信息交换平台, 实现非税管理信息的网上传输、核对等工作。
收入收缴的总体业务流程可概括为:财政设置执收单位、收入项目、票据等重要控制信息;执收单位下载这些控制信息, 并根据要求为缴款人开具《非税收入一般缴款书》, 由缴款人持缴款书到代理银行网点缴款, 资金直接进入指定账户;缴款信息由银行网点录入, 然后通过银行端的MQ服务将信息上传给财政, 财政接收并且审核收款信息, 然后进行处理, 生成报表;执收单位通过网络查询和核对收入信息。非税收入收缴总体业务流程如图1所示。
(二) 两点间通讯
IBM WebSphere MQ的基本功能是用来连接异构平台之间的应用, 通过MQ的互连, 使两个应用系统实现互连通信, 如图2所示。所以, 对于已有的应用系统, 如果没有通信接口则通常需要进行改造, 嵌入MQI调用使消息进得来、出得去。
在MQ管理控制平台上, 要先创建队列管理器, 再创建队列与通道。非税收入收缴管理系统银行端MQ配置如下:
MQ的通信方式是异步非实时的, 也就是说应用系统A调用发送消息的API, 如果返回正常表示发送消息已经被MQ接受, 但并不表示消息已经传达应用系统B。首先, 在传输的路途中如果发生各种异常情况, 应用系统B有可能收不到该消息。其次, 由于网络或其他的原因, 应用系统B有可能不能马上收到该消息。在这种情况下, 应用系统A无法知道消息是否已经成功地到达应用系统B。所以, 在需要有反馈的应用系统中, 通常会设计反向应答机制, 在非税收入收缴管理系统中设计了反向应答机制。
应用系统A发出请求消息, 然后等待对该请求消息的应答反馈, 即请求消息。通常情况下, 请求消息和应答消息应该放在不同的队列中, 以免混淆。每一条MQ消息的头结构 (MQMD) 中包含了Msg Id和CrorrelId两个域, 分别用于标识消息本身和相关消息。对于应答消息, 它有不同于请求消息的Msg Id, 但它的CrorrelId应该等于请求消息的Msg Id, 表示针对该请求消息的应答。在应用系统A等待应答消息的时候, 可以用请求消息的Msg Id作为匹配条件来明确地等待针对该请求消息的应答。
应用系统B在收到请求消息后, 根据消息内容做出相应的动作, 同时在构建应答消息的时候, 应该将请求消息的Msg Id填入应答消息的CrorrelId域中。
参考文献
[1]陈宇翔.精通IBM WebSphere MQ[J].安徽科学技术出版社, 2005.
[2]王多裴.基于中间件的银行业务系统研究与设计[J].计算机应用与软件, 2008.
[3]贾郭军.交易的桥梁—谈面向银行应用的交易中间件体系结构[J].中国计算机用户, 2004.
消息中间件论文 篇3
在分布式应用中, CORBA、DCOM、RMI等RPC中间件技术已广泛应用于各个领域。但是面对规模和复杂度都越来越高的分布式系统, 这些技术也显示出其局限性:①同步通信:客户端发出调用后, 必须等待服务对象完成处理并返回结果后才能继续执行;②客户端和服务对象的生命周期紧密耦合:客户端进程和服务对象进程都必须正常运行, 如果由于服务对象崩溃或者网络故障导致客户的请求不可达, 客户端会接收到异常;③点对点通信:客户端的一次调用只发送给某个单独的目标对象。
面向消息的中间件 (Message Oriented Middleware, MOM) 较好地解决了以上问题。发送者将消息发送给消息服务器, 消息服务器将消息存放在若干队列中, 在合适的时候再将消息转发给接收者。这种模式下, 发送和接收是异步的, 发送者无需等待;二者的生命周期未必相同:发送消息的时候接收者不一定运行, 接收消息的时候发送者也不一定运行;一对多通信:对于一个消息可以有多个接收者。在此背景下, 本文设计了基于JMX框架的JMS服务器 (下文称为JMX-oriented Message Bus Server, 简称为XMB服务器) 系统。XMB是一个遵从JMS1.1规范的基于JMX管理框架的消息中间件实现。该中间件从逻辑上分为两大部分:一部分是客户端编程接口;另一部分则实现一个基于JMS规范的消息中间件服务器。
1JMS规范解析
Java消息服务 (Java Message Service, JMS) 是J2EE (Java 2 Enterprise Edition) 套件的一部分, 它提供了标准API, Java开发人员可以使用这些API来访问企业消息系统的共同特性。Java消息服务定义了Java中访问消息中间件的接口。JMS只是接口, 并没有给予实现, 实现JMS接口的消息中间件称为JMS实现 (JMS Provider) 。JMS支持发布/订阅和点对点模型, 并允许创建由任意Java对象组成的消息类型。
1.1JMS体系结构
一个完整的JMS应用程序是由以下部分组成的:JMS实现 (JMS provider) , 它是一个实现了JMS接口并提供管理和控制能力的消息通信系统;JMS客户端是使用Java编程语言编写的创建和消费消息的程序或组件;消息是在JMS客户之间用于交流信息的对象;受管对象 (Administered object) 是由管理员为客户使用而创建的预先设置JMS对象 (preconfigured JMS object) 。主要有两个受管对象:目的域 (destination) 和连接工厂 (connection factory) 。
图1展示了上述对象的交互情况。管理员利用管理工具绑定目的域和连接工厂到JNDI (Java Naming and Directory Interface) 命名空间。然后, JMS客户就能够查找该命名空间内的受管对象, 而后通过JMS实现建立一个到这些对象的逻辑连接。
1.2消息通信模式
JMS规范定义了两种消息通信模式:点对点 (Point-to-Point, PTP) 通信模式和发布者/订阅者 (Pub/Sub) 通信模式。
PTP (Point-to-Point) 模型是基于队列的, 发送方发消息到队列 (Queue) , 接收方从队列接收消息, 队列的存在使得消息的异步传输成为可能。和邮件系统中的邮箱一样, 队列可以包含各种消息, JMS Provider提供工具管理队列的创建、删除。JMS PTP模型定义了客户端如何向队列发送消息, 从队列接收消息, 浏览队列中的消息。
JMS Pub/Sub模型定义了如何向一个内容节点发布和订阅消息, 这些节点被称作主题 (topic) 。主题可以被认为是消息的传输中介, 发布者 (publisher) 发布消息到主题, 订阅者 (subscribe) 从主题订阅消息。主题使得消息订阅者和消息发布者保持互相独立, 不需要接触即可保证消息的传送。
2JMS关键技术
2.1XMB的体系结构
如图2所示, 整个XMB系统主要由4个部分组成:JMS实现、JNDI实现、XMB管理框架和XMB API。
其中, JMS实现模块是保证消息传输的关键模块, 是整个系统的核心之一, 也是本文主要描述和设计的系统模块。该模块由JMS接口实现和对象传输层组成。JMS接口实现主要是用来和外部系统交互, 对象传输层主要负责服务器端和客户端交互所必需的通讯工作。这里的XMB API就是前面JMS接口实现策略中提到的, 为JMS接口实现提供访问系统中更基础功能的系统内部自己定义的一层外观 (Faade) 。
JNDI实现并不属于JMS规范的内容, 而是作为J2EE规范的一部分, 为其它的J2EE模块提供命名和目录服务, 提供发现和定位功能的一个技术规范。在XMB系统中, JNDI扮演了一个很重要的角色, 它提供了一个接口让用户在不知道资源所在位置的情形下, 取得该资源服务。另外, 服务器还要对客户端所需的通讯对象进行管理, 对于如何管理JMS规范没有统一的规定, 但是JMX作为SUN推出的分布式环境组件对象管理的标准, 很适合解决服务器端受管对象的管理。因此, XMB管理框架采用JMX技术为基础, 为JMS模块提供扩展管理架构, 用于对服务器端受管对象的管理。
2.2消息队列设计
消息队列是一个消息中间件的核心部件, 它的设计是左右一个JMS服务器效能的关键。
从应用的层面上讲, 消息队列是消息的安全存放地, 队列需要存储消息直到消息被应用程序处理为止。消息队列通常是以下述方式进行工作的:①程序A形成对消息队列系统的调用, 此调用告知消息队列系统, 消息准备好了投向程序B;②消息队列系统发送此消息到程序B驻留处的系统, 并将它放到程序B的队列中;③适当时间后, 程序B从它的队列中读此消息, 并处理此信息。
消息队列必须要能够在各种网络条件下保证消息的可靠传递, 必须要克服网络线路质量差或不稳定的现状。在传输过程中, 如果通信线路出现故障或远端的主机发生故障, 本地的应用程序都不会受到影响, 可以继续发送数据, 而无需等待网络故障恢复或远端主机正常后再重新运行。
一般在消息中间件中不会只有一种类型的队列。消息中间件的队列分为很多种类型, 其中包括:本地队列、远程队列、模板队列、动态队列、别名队列等。
本地队列又分为普通本地队列和传输队列, 普通本地队列是应用程序通过API对其进行读写操作的队列;传输队列可以理解为存储——转发队列, 比如:系统将某个消息交给JMS系统发送到远程主机, 而此时网络发生故障, JMS系统将把消息放在传输队列中暂存, 当网络恢复时, 再发往远端目的地。
远程队列是目的队列在本地的定义, 它类似一个地址指针, 指向远程主机上的某个目的队列, 它仅仅是个定义, 并不真正占用磁盘存储空间。
模板队列和动态队列不是必须的, 但是很多商业消息中间件产品都实现了它们。它们的一个典型用途是用作系统的可扩展性考虑。基于以上考虑, 可以在XMB系统中创建一个模板队列, 当今后需要新增队列时, 每打开一个模板队列, JMS系统便会自动生成一个动态队列, 还可以指定该动态队列为临时队列或者是永久队列, 若为临时队列可在关闭它的同时将它删除, 相反, 若为永久队列, 可以将它永久保留, 以后继续用。
借用观察者模式的框架, 可以得到如图3所示的消息队列体系结构。
从图3中可以看到:首先, 系统定义了一个抽象类IMessagingQueue, 它相当于观察者模式中的Subject接口, 负责消息队列的基类型, 这样的实现是为了便于系统在今后加入其它类型的消息队列时不至于进行整个框架的改变。IMessagingQueue定义了所有消息队列的公共属性和方法。ClientList是一个双向链表, 它维持了一个注册到该消息队列的客户队列, attach ( ) 和detach ( ) 用于客户注册或取消注册的方法。当服务器收到新的消息后会调用notify ( ) 方法, 在notify ( ) 方法中会调用客户的getMessage ( ) 方法将消息的一个复本push到客户端。
然后, 系统定义一个IMessagingClient接口, 用于表示连接到某个消息队列的客户。该接口只有一个方法, 就是getMessage ( ) , 并且该方法是一个push方法, 客户是被动的。此外, 客户有一个重要的属性——onlineState, 消息队列要凭该属性的值判断客户的在线状态, 以决定是发送消息还是缓存消息。最后, 还必须明确消息队列是在JMS系统启动时由JMS系统的相关部件创建的。
2.3管理框架设计
关于整个服务器对象的管理在JMS规范中并未做具体的规定, 但是该部分对于整个系统来说却是很重要的。消息服务器管理框架的实现不仅会影响JMS实现各部分的性能和效率, 而且对于消息的监控以及整个系统的可操作性来说也同样重要。该部分主要负责管理系统中已经建立的JMS受控对象, 即Queue和Topic的创建、管理和销毁, 以及这些对象中的持久消息和持久订阅对象等。
为了更好的完成服务器对象的管理, 本系统采用了Sun公司的另一个重要的Java技术——JMX, 它主要用于分布式系统中的对象管理。JMX实现是在系统启动时自启动的, 和它交互的边界主要是OTL层。
在整个系统中, XMBServerAgent可以看作是管理框架的大脑, 和注册到其中的各种MBean共同组成了整个JMX管理框架。
图4是整个管理框架的实现, 系统首先定义了4种MBean, 然后完成了它们各自的实现类。这些MBean都会到XMBServerAgent中的MBeanServer去注册, 同时它们也在被销毁的时候撤销注册。然后, 系统管理员就可以通过表示HTML控制台的MBean-HtmlAdaptorServer来界面化操作这些服务器。这些不同的服务器的操作已经定义在了各自的MBean接口中, 而这些MBean接口又可以嵌套使用。
3结束语
本文针对分布式应用通信中存在的问题, 讨论了消息中间件设计的关键技术和系统框架, 并借鉴如JBoss messaging, OpenJMS等优秀的开源消息中间件的设计思想, 设计了基于JMX框架的JMS服务器——XMB。整个XMB由两部分组成:客户端JAR文件和XMB服务器。客户端JAR文件用于客户加入ClassPath中进行JMS客户端开发。XMB服务器用于创建、部署和管理消息目的域, 并提供基于消息通讯的低层系统支持。
摘要：消息中间件为应用系统之间提供了可靠、高效、跨平台的消息传递服务, 有利于应用之间的数据交换。但消息中间件在具体实现上有很大的差异, 不同的厂商采用各自的开发标准和接口, 因而不同系统之间兼容性不好, 这样不利于降低企业的成本, 同时也加重了应用开发者和系统维护的负担。基于以上目的设计了一个遵从JMS规范的基于JMX技术的消息中间件。首先介绍了与消息中间件相关的概念和模型;其次, 对Sun公司提出的JMS API接口规范进行分析, 解决了JMS实现的关键问题, 并且将JMX技术引入到消息中间件的管理中, 提出了JMS消息中间件的设计和实现思路。
关键词：消息中间件,JMS,JMS实现,JMX,XMB
参考文献
[1]ERIC NEWCOMER, GREG LOMOW.Understanding SOA withweb services中文版[M].徐涵, 译.2006.
[2]KIM HAASE.JavaTMmessage service API tutorial[M].Sun Micr-osystems, Inc, 2002.
[3]DAVID REILLY.Java网络编程与分布式计算[M].沈风, 译.北京:机械工业出版社, 2003.
[4]What is middleware[EB/OL].http://www.middleware.org/whatis.html.
[5]Message oriented middleware vendor lists[EB/OL].http://www.middleware.org/mom/vendors.html.
消息中间件论文 篇4
关键词：消息中间件,消息传递模式,消息队列模式,点到点,发布/订阅,智能消息中间件
0 引言
中间件是在企业本身业务需求的快速增长及Internet/Intranet的广泛应用,应用系统由过去的Client/Serve两层体系结构逐步发展成三层或多层体系结构的过程中应运而生的。而又随着中间件技术的不断进步和发展,中间件作为与操作系统、数据库同等重要的基础系统软件在越来越多的领域得到应用。在此过程中,中间件又发展为几种不同的形式,如:数据访问中间件、远程过程调用(RPC)中间件、消息中间件、交易管理中间件、对象中间件种、应用服务器中间件等。而其中消息中间件(Message Oriented Middleware, MOM)是出现最早,也是最基础的中间件。面向消息中间件主要有消息传递和消息队列两种模式,而这两种模式都支持点到点通信和发布/订阅通信两种方式。本文总结了两种模式及两种通信方式的优缺点,根据目前企业消息数据的多样性的特点,提出了一种基于Pub/Sub模式的智能消息中间件的设计方案,它可以根据消息的不同类型结合具体情况自动选择最合适的传递方法组合使其既能够满足高速、大数据量消息数据的传输,又支持可靠持久消息传递,还使消息的传递模式和传递方法对应用程序透明,极大地增强了消息中间件的智能性、灵活性和易用性。
1 消息中间件的两种实现模式
1.1 消息传递模式
在此模式中,消息由一个发送者发送给接收者,消息的发送端和接收端并没有缓存机制,在发送端当消息到来后即刻发送(当然在连接有效的情况下),而在接收端当收到消息后则立即提交给上层应用程序处理。
由此可见,消息传递模式的优点是速度快、实时性好,但因为此种模式并没有提供缓存机制所以在消息持久性方面有天生的缺陷,比如在连接出现问题时,就需要消息发送端重新发送消息,而不能通过恢复来重传消息。
1.2 消息队列模式
消息队列可以为程序提供异步的通信方式。消息发送端的程序以一个队列作为中转与接收端的程序相互通信,如果把消息传递比喻成打电话,那么消息队列就像是电子邮件一样,不管你是不是在线邮件都会发送到你的邮箱里。
消息队列的优点十分突出:稳定性好、灵活、可靠,在客户端系统崩溃的情况下也不会造成数据丢失。同样缺点也比较突出:实时性差、吞吐率低。
2 消息中间件的两种通信方式
以下提到的两种通信方式都可采用上面所提到的实现模式,只以消息队列模式来进行介绍。
2.1 点对点通信方式(Peer-to-Peer,PTP)
在PTP通信模式中(如图1所示)[1],每个客户端对应一个消息队列,发送客户端(生产者)发送消息到消息队列中,接收端(消费者)从消息队列读取消息。其中消息在队列以FIFO或优先级方式存储[2]。
PTP的通信模式的最大优点是实现简单,而其缺点是数据提供者和订阅者的耦合度太高、扩展性较差,使得系统通信灵活性受到较大限制,每当接收方发生变化时,发送方的应用程序都必须作相应变更,难以支持多方参与者的交互。
2.2 发布/订阅通信方式(Publish/Subscribe,Pub/Sub)
在Pub/Sub通信模式中(如图2所示)[1],发布者通过发布代理把消息主题发布到消息代理服务器,由消息代理服务器向订阅代理发布所订阅消息;订阅者通过订阅代理向消息代理服务器“订阅”感兴趣的消息主题。由于发布/订阅方式更加智能有效,实际上已成为异步消息中间件的事实标准[3]。
Pub/Sub通信模式的主要优点是通过消息代理服务器实现了发送方和接收方之间的松耦合,但其明显的缺点是中央的消息代理服务器负责处理消息的转发和管理,在大数据量交互时,其性能瓶颈和单点失效的局限性越发明显,严重影响了系统的可用性[4]。
3 基于Pub/Sub模式的智能消息中间件设计
根据上面介绍的情况,可知消息中间件的通信方法有四种组合方式,而每一种方式都有各自的优缺点,因此本文提出一种基于Pub/Sub模式的智能消息中间件通信模型,它通过在代理服务器端收到发送客户端的发布主题消息后,根据主题的类型以及该主题的订阅情况来选择使用消息中间件的哪一种组合方式,以满足不同消息在实时性,可靠性,高速性等性能方面的不同要求,这样就大大提高了消息传递的灵活性。另一方面,此种设计可以大大简化应用程序的编写,使得在编写应用程序时不须关心消息传递的细节,只要通过简单的接口发送和接收消息即可,而不需要考虑要采用何种方法进行通信[5]。
3.1 系统架构设计
此种通信模式的系统架构设计如图3所示。
(1) 代理服务器端
发布、订阅及判定中心为本系统的核心模块,其功能主要分为两类:①发布、订阅功能:主要提供发布/订阅管理功能、连接管理等功能。为客户端提供发布/取消发布、订阅/取消订阅、上线/下线等接口。通过发布/订阅接口在代理服务器中可以形成一个完整的主题、发布方、订阅方的对应关系图,为以后消息的传递提供路由信息。②传送模式判定功能:服务器端从软总线接收到发送端传来的消息后,通过判断消息的类型及该消息的订阅情况来决定使用哪一种消息模式。
此外服务器端还包括消息路由适配器、队列管理器和分发管理器。队列管理器是基于Pub/Sub的消息队列模式的具体实现,提供消息生命周期控制,支持优先级队列,可以使用数据库或文件支持消息的持久存储。分发管理器是基于Pub/Sub的消息传递模式的具体实现,使用同步传输方式支持大数据量快速传输,并提供丢失消息重传机制最大程度保证消息的完整性。路由适配器将由队列管理器和分发管理器分发下来为消息发送到需要该消息的订阅代理客户端。
(2) 发布代理客户端
负责向代理服务器端发布消息主题并接受服务器端的答复,根据答复信息来选择使用哪一种消息模式,即是将消息发送给服务器还是直接与订阅客户端进行交互,以及是采用消息队列还是采用点对点的方式。选择一种通信模式后向软总路线发送消息,并根据需要对消息进行封装、压缩和加密处理。
(3) 订阅代理客户端
负责向代理服务器订阅、退订消息,同样也有个消息队列。它接收来自软总线的消息,并根据需要对消息进行解包、解压缩和解密处理。
发布、订阅代理客户端并不是固定的,可能在这一次的消息交互中此客户端是发布端,而下一次此端又成为了订阅客户端。但是在此系统中这两种客户端的结构基本相同,所以在实际应用中可以满足一个客户端既为发布端,又为订阅端的要求。
3.2 系统工作流程
本系统总体框架是基于发布/订阅模式的,图4所示的是该系统下发布/订阅通信方式的工作流程。
其中发送消息与分发消息的方式既支持消息传递模式,又支持消息队列模式。其中发布客户端收到代理服务器的答复消息后,根据答复消息判断是采用发布/订阅通信方式,于是将消息发送给代理服务器,之后由代理服务器根据该消息的类型来选择是直接转发还是将该消息放入消息队列,但不管采用何种方式,都由代理服务器负责消息向订阅客户端的发送。
该系统在点对点通信方式下的工作流程与图4所示的工作流程相似,其主要差别在于,代理服务器只负责通过向发布客户端发送答复消息的方式来告诉发布客户端选择是采用消息传递方式还是消息队列方式直接与订阅客户端进行通信。
3.3 消息的格式
由于企业应用中消息所要包含的内容是多种多样,不可能对每种消息类型都考虑到,所以采用XML技术,其可以自己定义消息的格式,并且XML在网络上传输也相当方便,它既适用于异构应用之间的数据通信也适用于异构数据库之间的数据集成。由此可见,使用XML技术来定义消息可以尽可能满足各个企业对数据通信的要求。消息中除了包含所要传输的数据之外,还应该包含消息对高速性,及时性,可靠性,持久性等方面的要求,还可以包含该消息的优先级。
3.4 该系统的设计难点
此系统的设计难点就在于发布/订阅及判定中心的设计,其中发布/订阅的实现可以通过建立订阅者主题树的方式来实现[6],该技术现在已经比较成熟。重点就在于对消息传递方式的判定上,要对此做出准确判定必须综合很多方面的信息,其中涉及到该消息的订阅情况,消息本身的性质要求,还有消息发送者对消息的要求及系统当前本身的状况等等。所以就需要设计出一个比较完善且能够实现准确判定的方法,这也是今后要研究的主要方向。
4 结束语
简单介绍了基于Pub/Sub模式的智能消息中间件的系统设计与工作流程及其中涉及到的关键技术,以期望通过这种技术使得用消息中间件传递消息可以实现智能性,即根据消息的不同来选择最适合的通信方式,以满足不同消息对实时性,高速性,可靠性等方面的不同要求。
参考文献
[1]Eugster P T,Pascal A Felber,Rachid Guerraoui,et al.The Many Facesof Publish/Subscribe[J].ACM Computing Surveys,2003,35(2):114-131.
[2]RAO B R.Making the Most of Middleware[J].Data CommunicationsInternational 24.1995,9,12:89-96.
[3]胡雅庆.面向消息中间件的设计与实现[J].计算机与现代化,2001(3):41-45.
[4]BERNSTEIN,PHILIP A.Middleware:A Model for Distributed Services[J].Communications of the ACM.1996,2,39(2):86-97.
[5]李辉,李绪志.基于消息分类的复合模式消息中间件研究[J].微计算机信息,2007,23(12):195.
消息中间件论文 篇5
关键词：ICE中间件,分布式系统,模拟训练系统
0 引言
模拟训练系统被称为“没有硝烟战场的训练”[1], 目前已成为部队军事训练的重要手段之一。随着信息化水平的不断进步, 我军模拟训练系统建设要求也在不断的提高。组网训练、异地训练等规模越来越大的分布式模拟训练系统, 迫切需要一种高服务质量、自适应能力强的信息中间件来实现大规模多种类信息的交互功能。
中间件位于操作系统和应用软件之间[2], 是对上层应用开发提供统一的方式, 以确保用户程序在不同的操作系统环境下无需改动只做简单编译操作即可使用, 为应用开发、部署和管理提供方便[3]。
本文在研究ICE的基础上提出了一种适应模拟训练系统要求的, 具有与硬件平台、操作系统、网络和开发语言无关等特点的消息中间件系统。
1 ICE技术特点
1.1 ICE简介
ICE是ZeroC公司提供的一种开放源码、高性能、面向对象、跨操作系统、跨语言的中间件产品, 广泛应用于实际的分布式应用开发。
ICE可以使用不同的编程语言 (C++、Java、C#、Python) 编写客户端、服务端软件, 可以运行在不同的操作系统 (Windows、Liunx) 和机器架构上, 并支持TCP、UDP、SSL多种网络协议进行通信[5]。
ICE提供了一种Slice (Specification Language for ICE) 接口描述语言[6], 该语言允许开发人员使用C++、NET、Java、Python和php等编程语言定义客户-服务器之间的合约。ICE客户端-服务器架构如图一所示。
(1) ICE核心。为远地通信提供了客户端和服务端运行时支持, 是作为客户和服务器可与之链接的库提供的。
(2) 代理。代理代码是根据Slice定义生成的, 为客户提供一个向下调用接口, 并提供整编和解编代码。
(3) 对象适配器。专用于服务端的ICE API的一部分, 主要负责将客户端的请求映射到编程语言的特定方法上, 并与一个或多个传输端点关联在一起。
(4) 骨架。骨架代码也是根据Slice定义生成, 提供向上调用的接口, 具有整编和解编代码, 允许ICE runtime把控制线程交给所编写的应用程序。
1.2 ICE开发流程
ICE通用开发流程如下[7]:
(1) 使用Slice语言编写客户端-服务器之间程序通讯时使用到的数据结构和接口定义。
(2) 使用Slice2XXX命令编译程序生成服务平台具体的框架代码, 包括服务端骨架类代码和客户端代理类代码。
(3) 服务端继承骨架类代码实现服务端软件功能, 实现客户端代码来获取服务器提供对象的代理。
(4) 编辑相关配置文件设定服务器网络地址、端口号、对象标示等属性。
(5) 配置ICE开发库, 编译客户端和服务端程序代码。
1.3 ICE的优势
与传统分布式中间件相比, ICE中间件具有以下优势[8,9]:
(1) 支持多种不同语言之间的通信程序设计。目前支持的语言有:C++、NET、Java、Python和php等语言。通过ICE的标准Slice语言规定的接口, 再结合Slice2XXX (XXX=cpp, java, php等) 命令的执行, Java开发人员可以很方便的和C++开发人员或者python开发人员, 通过一组定好的接口进行通讯程序的开发, 从而实现功能。
(2) 支持不同的操作系统程序设计。开发不同操作系统下的标准socket的通信应用, 若采用ICE框架进行开发, 开发人员不需要关注平台相关的socket开发方法, 只要按照标准的C++语法写符合逻辑的代码, 然后在链接时链接上ICE在该平台的库文件就行。
(3) 支持多种底层传输协议。使用标准的socket实现时, 当所采用的TCP协议想改为UDP协议时, 需要修改大量的代码, 而使用ICE框架的话, 只需要修改配置即可。ICE目前支持TCP、UPD协议以及SSL协议。
(4) 提供多种服务。已经实现了对象持久服务、事件服务、软件更新服务、调度服务等服务, 方便用户集成, 提高开发和部署效率。
(5) 提供多种调用模式。ICE在调用模式上有几种选择方案, 并且每种方案针对不同的网络协议的特性作了相应的选择, 实现了同步异步调用, 支持单向、双向、批量分派模型, 提高了应用的伸缩性和扩展性, 同时降低了接口设计和实现的耦合度。
2 系统设计
2.1 设计目标
为了满足模拟训练系统信息交互的实际需求, 其设计目标如下:
(1) 支持异构平台分布式对象间的消息传递, 提供信息接入、管理、分发等能力。
(2) 提供“推送、拉取”机制相结合的信息共享能力。
(3) 满足模拟训练系统收集、传递和按需分发、多级分发信息的需求。
(4) 为模拟训练系统提供简单、易用的API接口, 应用程序不必关心具体的消息转发过程。
2.2 功能组成
为了满足上述目标, 基于ICE的消息中间件系统的功能组成如图二所示。
(1) 系统管理。为管理员提供服务运行管理、参数配置、服务状态、日志查看等功能。
(2) 目录服务。为管理员提供类别维护、信息维护、目录索引等功能。
(3) 订阅管理。为管理员提供人机交互界面, 实现用户订阅、取消订阅和查询可订阅信息的功能。
(4) 信息流监视。为管理员提供当前系统输入、输出信息流监视功能。
(5) 发布订阅。提供主题创建、主题删除、软件注册、发布信息、订阅主题、取消订阅主题、软件注销等功能。
(6) 信息发送。提供软件注册、发送数据、接收数据、软件注销等功能。
2.3 体系结构
为了实现以上功能要求, 基于ICE的消息中间件系统的体系结构如图三所示。
在模拟训练系统运行环境中, 部署一个中心服务器, 在客户机节点上部署一个信息代理。其中, 中心服务器提供系统管理、目录管理、订阅管理以及信息流监视等功能。
客户机应用程序通过API与信息代理进行通信, 信息代理在每个节点上以后台服务的方式运行, 接收应用程序的数据信息, 通过注册、查询等操作与中心服务器进行交互获得信息转发所需的接收端地址, 在信息代理之间进行直接通信。
2.4 应用方式
应用程序使用该系统的步骤如下:
(1) 调用信息代理提供的API进行初始化操作, 与信息代理建立连接以便进行数据收发、发布订阅等操作。
(2) 调用信息代理提供的API通知信息代理所要发送或接收的数据类型, 由信息代理调用中心服务器所提供的注册方法进行消息注册, 在中心服务器上生成消息类型, 发送者和接收者、发布者和订阅者之间的对应关系, 建立消息转发关系表。
(3) 调用信息代理提供API进行数据收发、发布订阅等操作。
3 结束语
本文通过对ICE中间件技术的分析, 详细介绍了ICE中间件的基本原理、开发流程以及优势, 在此基础上提出并实现了一种模拟训练系统消息中间件。经过在项目中的试用, 证明该ICE中间件具有信息传输质量高、适应能力强等优点, 能较好的解决模拟训练系统的信息传输瓶颈。
参考文献
[1]胡晓峰.美军训练模拟[M].北京:国防大学出版社, 2001.
[2]蒋雄伟, 马范援.中间件与分布式计算[J].计算机应用, 2002, 22 (04) :6-8.
[3]周元春, 李淼.中间件技术[J].计算机工程与应用, 2002, 38 (15) :80-85.
[4]Michi Henning, Mark Spruiell, 著.马维达, 译.ICE分布式程序设计[M].Zero C, Inc, 2004.
[5]陈增孝, 裘雪红.面向对象的ICE中间件系统设计[J].电子元器件应用, 2008, 10 (08) :16-18, 21.
[6]张俊军, 章旋.ICE中间件技术及其应用研究[J].计算机与现代化, 2012, (05) :53.
[7]童琨.分布式应用程序开发框架的研究[J].字技术与应用, 2010, 4 (04) :85-86.
消息中间件论文 篇6
关键词：消息中间件,多维QoS,QoS管理
目前,分布式系统广泛应用于各行各业之中,发挥着重要作用。然而,分布式系统也存在着诸多问题:一方面,分布式系统中存在着多种硬件设备,而这些硬件设备上又运行着不同的操作系统和应用软件,实现这些异构系统间可靠、便捷地交互一直是一个难题;另一方面,分布式系统的广泛应用使得系统规模迅速扩大,导致网络带宽等资源严重不足,难以满足分布式环境下的用户需求。
为了解决上述第一个问题,使分布式环境下的应用能够在一个统一的平台上进行交互,学者们提出了中间件的概念。中间件是一种位于系统软件和应用软件之间的分布式软件,为分布式系统中不同组件之间的交互提供了支持[1]。当前,中间件已广泛应用于分布式系统中,为分布式环境下的通信和互操作提供着便利[2]。
为了解决上述第二个问题,缓解日益增长的用户需求与严重短缺的网络、系统资源间的矛盾,CCITT提出了服务质量(Quality o Service,QoS)的概念,希望通过对应用的QoS进行管理来解决这一问题。
鉴于上述两点,以中间件为平台对分布式应用的QoS进行管理,可以有效地解决分布式系统中存在的问题。然而目前的中间件产品大多只关注应用在功能方面的需求,对以QoS为代表的非功能性需求只提供“尽力而为”的服务,难以满足分布式环境下的用户需求[3]。
该文首先对消息中间和QoS的相关知识进行了介绍,然后针对目前分布式交互中存在的问题,设计了一种基于消息中间件(Message-Oriented Middleware,MOM)的多维QoS管理模型,对分布式交互的QoS进行管理,介绍了该模型的体系结构,详细介绍了其核心模块的设计与实现,最后对全文进行了总结。
1 消息中间件和QoS
1.1 消息中间件
消息中间件是一种用于消息传输的中间件,提供了与平台无关的可靠的数据传输机制,增加了C/S(Client/Server)模式的灵活性,实现了系统的松耦合[4]。目前进行消息中间件开发的厂商主要有IBM、BEA、Tibco、东方通科技等公司,产品主要有MQSeries、Mes-sageQ、Rendezvous、TongLink/Q等。
1.2 QoS
QoS的定义最初由CCITT给出:QoS是一个综合指标,用于衡量使用一个服务的满意程度,描述关于一个服务的某些性能特点[5]。学术界普遍认为QoS有狭义和广义之分:狭义QoS指网络传输中的一些技术指标;广义QoS指端到端QoS,涉及网络层、系统层、中间件层、应用层,包括资源调配与利用、各层之间的协商等。
2 基于MOM的多维QoS管理模型设计
针对目前分布式交互中存在的问题,本文提出了一种基于MOM的多维QoS管理模型,以MOM为平台,采用多维QoS描述QoS需求,对分布式交互的QoS进行管理,能有效地满足分布式交互的QoS需求。
如图1所示,基于MOM的多维QoS管理模型分为三层:
1)用户层:描述用户的QoS需求,考虑到用户的实际情况,用户接口仅提供几个QoS等级供用户选择,然后由QoS映射模块将用户层的QoS等级映射成相应的应用层QoS参数。
2)应用层:描述应用的QoS需求,其中,应用接口描述那些由用户层映射来的QoS参数,而应用配置模块则用于获得应用在运行时决定的QoS参数。然后,QoS映射模块将这两部分QoS参数映射为MOM层的QoS参数。
3)MOM层:MOM层屏蔽了底层环境的复杂性,将系统层和网络层的QoS管理集中到MOM层,根据用户的QoS需求和当前资源情况对QoS进行综合管理,包括资源管理、QoS评估、QoS协商、QoS降级、QoS预测等模块。
3 核心模块的设计与实现
在对基于MOM的多维QoS管理模型的体系结构进行深入研究的基础上,设计了该模型的核心模块,并用Java语言实现了这些模块。基于MOM的多维QoS管理模型的核心模块主要包括QoS规约模块、QoS映射模块和QoS执行模块。
3.1 Qo S规约模块
QoS规约模块的主要功能是对模型中各层的QoS参数进行定义,可细分为三个子模块:用户层QoS规约、应用层QoS规约、MOM层QoS规约。
用户层是基于MOM的多维QoS管理模型的最上层,直接面向最终用户,针对用户往往难以准确描述应用QoS需求的实际情况,用户层QoS规约仅提供一个用户易于理解的QoS等级供用户选择。QoS等级分为以下三个级别:尽力而为、QoS协商、QoS保证。
应用层QoS规约对应用层的QoS参数进行定义,与具体应用领域相关,不同应用的QoS各不相同,本文所研究的基于MOM的多维QoS管理模型主要针对分布式交互领域,其应用层的QoS参数主要有周期、容量、可靠性、优先级。
MOM层对系统层和网络层的QoS进行统一管理,其QoS参数较为复杂,为了准确地描述MOM层的QoS参数,将MOM层的QoS看作由时间维、空间维、可靠维、策略维构成的一个四维QoS空间。时间维QoS描述与时间相关的QoS参数,包括开始时间、相对截止时间、绝对截止时间、传输周期、期望周期、最大周期,其中,相对截止时间为应用请求的传输截止时间,绝对截止时间为交互过程的截止时间。空间维QoS描述与空间相关的QoS参数,包括最大消息长度、处理空间容量。可靠维QoS描述与可靠性相关的QoS参数,可细分为消息可靠维和传输可靠维:消息可靠维描述消息本身的可靠性,包括持久性、持久存储空间容量;传输可靠维描述消息在传输过程中的可靠性,包括重发次数、发送方地址、接收方地址。策略维QoS描述与QoS管理策略相关的参数,包括QoS效益。
3.2 Qo S映射模块
QoS映射模块完成模型不同层间的QoS参数转换,它分为用户层到应用层的QoS映射和应用层到MOM层的QoS映射两部分。
用户层到应用层的QoS映射将用户层的QoS等级映射成应用层的QoS参数,映射规则在QoS契约中进行定义。QoS契约描述用户的具体QoS需求,由用户和系统通过协商确定,是用户和系统之间的一个约定,说明了对某种服务级别的确保程度。通过QoS契约,可以很方便地完成不同层QoS参数之间的转换。
应用层到MOM层的QoS映射将应用层的QoS参数映射为MOM层所能理解的QoS参数,它分为两部分:
1)静态映射
静态映射根据事先由用户和系统通过协商所确定的QoS契约,将应用层的QoS参数映射为MOM层的QoS参数,这一过程与用户层到应用层的QoS映射类似,在此不做详述。
2)动态映射
通过静态映射只能得到MOM层的大部分QoS参数,还有一些QoS参数是应用在运行时决定的,如开始时间、相对截止时间、绝对截止时间、QoS效益等,这部分QoS参数通过动态映射获得。其中,开始时间、相对截止时间、绝对截止时间等QoS参数都可通过底层提供的API获得,下面重点介绍QoS效益的计算方法。
系统每完成一个应用请求,都可以看作应用获得了一定的QoS效益,QoS效益的大小反映了系统对应用的QoS保障程度。QoS效益与应用的优先级和应用请求的完成时间有关。我们用请求完成周期的质量评估函数F(t)来表示应用请求的完成时间,用expcyc表示期望周期,maxcyc表示最大周期,pri表示优先级,qosval表示QoS效益,则:
1)当t<=expcyc时,F(t)=1。
2)当expcyc
3)当t>=maxcyc时,F(t)=0。
将完成时间与优先级相乘,即可得到应用的QoS效益,即:
3.3 Qo S执行模块
QoS执行模块的主要功能是根据用户的QoS需求和当前资源情况,对相关活动进行监控,并在外界环境发生变化时进行适应性调整,使整体的QoS达到最优。QoS执行模块主要包括以下几个部分:
1)资源管理:对当前资源情况进行监测,协助系统对资源进行分配和回收。
2)QoS评估:根据当前资源情况对用户的QoS需求进行评估,判断当前资源是否能满足QoS需求,并根据判断结果执行相应操作。
3)QoS协商:在当前资源无法满足用户的QoS需求时,与用户进行QoS协商,降低QoS需求。
4)QoS降级:对QoS协商所得到的新的QoS需求进行判断,若当前资源能满足QoS需求,则协助系统分配资源;若当前资源不能满足QoS需求,则对QoS需求进行调整,并执行相应操作。
5)QoS预测:根据先前应用的执行情况,对用户的QoS需求能否得到满足进行预测,为QoS管理提供决策参考。
4 结束语
本文首先对消息中间件和QoS的相关概念进行了介绍,然后针对分布式交互中存在的问题,设计了一种基于MOM的多维QoS管理模型,对QoS规约、QoS映射、QoS执行这三个模型的核心模块进行了详细介绍,细致分析了这些模块的组成以及功能。基于MOM的多维QoS管理模型通过对分布式交互的QoS进行管理,能有效地保证了分布式交互的QoS,为满足分布式环境下的端到端QoS需求奠定了基础。
参考文献
[1]Geihs K.Middleware Challenges Ahead[J].IEEE Computer,2001,34(6):24-31.
[2]Vinoski S.Where is Middleware[J].IEEE Internet Computing,2002,6(2):83-85.
[3]胡剑军,官荷卿,魏峻,等.一种基于性能模型的中间件自配置框架[J].软件学报,2007,18(9):2117-2129.
[4]Maheshwari P,Tang H,Liang R.Enhancing Web Services with Message-Oriented Middleware[C].Proc.of IEEE International Confer-ence on Web Services,San Diego,California,2004.
消息中间件论文 篇7
分布对象的异步消息传递机制是构造大型分布应用必不可少的机制之一,但是在目前的典型分布式应用支撑平台中,没有很好地解决消息的异步机制问题,缺乏对消息异步传递、服务质量控制和时间无关的存储转发机制的支持。目前,在分布式对象中间件平台中,支持异步机制的研究主要有两个方面,第一种异步机制是通过中间件代理服务解耦对象请求端与接收端,以实现异步、松耦合和多对多通信。这种方式适合构造基于事件的中间件应用,不能够支持消息接收端向消息发送端返回应答。第二种异步机制是基于方法级支持请求发送端与接收端之间的异步通信,它可以直接支持消息接收端向发送端返回应答。这种基于方法级的异步机制有两种基本的模型:异步回调模型和异步轮询模型。这两种异步模型能够解耦消息发送端和接收端,消息发送端发送请求之后不需要阻塞等待应答结果。但回调和轮询异步模型存在以下缺点:
(1) 要求消息发送端和接收端都必须处于活动状态,具有时间紧耦合的缺点。
(2) 消息的服务质量支持不足,对消息的可靠性传递不能保证。
(3) 无法支持消息应答双方是不同对象的请求,具有空间紧耦合的缺点。
针对上述方法级异步消息模型存在的问题,我们设计了一种支持时间解耦的分布对象异步消息模型TIAIM(Time Independent Asynchronous Invoke Model )。该模型引入了消息转换层MCL(Message Conversion Layer)来完成消息的提取、包装和变换,以实现原始的请求消息转化为一个可存储转发的消息。该模型设计了一种软件路由代理SRA(Software Route Agent)来存储和转发消息,以支持消息异步传递和时间无关激活,同时很好地支持消息服务质量的控制。本文主要针对TIAIM中消息转换机制进行研究。
1 基于软件路由代理支持时间解耦的TIAIM
时间解耦异步消息模型TIAIM属于方法级的异步机制,它基于回调和轮询异步模型进行扩展。TIAIM可形式化地定义为:
定义1 TIAIM=<DE,O,MCL,SRA>,其中,分布式对象O=<Oc,Orh ,Op ,Osrh ,Os> Oc表示客户请求对象,Os表示服务对象,Orh为Reply Handler对象,它是异步回调模型中引入的接收应答对象,Op 为异步轮询模型引入的查询(Poll)对象,Osrh是针对TIAIM中的异步轮询模型引入的由系统维护的应答接收对象。MCL为消息转换层,负责原始请求消息的转换。SRA为软件路由代理,它基于DE分布环境,对MCL转换后的消息进行存储转发。
基于时间解耦的分布对象中间件异步通信模型如图1所示。
2 TIAIM消息转换层MCL
2.1 TIAIM消息转换层MCL体系结构
TIAIM的消息转换层MCL的结构如图2所示。
MPA:提取原始GIOP Request消息,请求消息包括GIOP主版本号、次版本号、服务上下文、应答标志、对象Key、操作名及IN/OUT类型参数。
PI: MCL提供给Client选择使用的一组有关路由策略接口,实现了路由策略设置与具体实现的无关性。
QSI: MCL提供的QoS接口,以控制消息的服务质量。QSI设置的服务质量信息将作为请求消息的一部分随消息进行传递,并影响SRA对消息的处理。
RE:根据RE作用的不同,RE可以分为三种:转换规则、路由规则及其它应用层规则。转换规则的作用是将GIOP Request消息转换为可以存储转发的消息。路由规则作用是选择开始的路由器。
MAA:在MT的控制下,将转换后的请求消息、路由信息、服务质量信息、应答目的地信息包装为一个可以存储转发的消息Request Info,通过DE发送出去。
2.2 MCL消息提取适配机制
GIOP(General Inter-ORB Protocol)是OMG在CORBA规范中定义的一个ORB间的通信协议。GIOP请求消息由GIOP固定消息头、请求消息头和请求消息体组成。
为了包装和重构一个请求消息,以便SRAT能够激活一个GIOP Request,MPA需要提取以下信息:GIOP_version、flags、response_expected、reserved、Object_key、operation、Service_context。MPA提取信息的处理算法如下:GIOP_version、flags、response_expected、reserved、Object_key、operation、Service_context。
2.3 MCL策略接口PI及算法
PI为MCL向上提供一组与路由有关的策略接口,供Client选择使用,实现路由策略设置与具体实现分离。在异步消息模型中,由于SRA之间互连构成了一定的拓扑结构图,消息要从一个Client传递到一个Server,可能要经过SRA的多次存储转发,而SRA传递消息的效率取决于寻径算法,算法的优劣会给系统的正确性、可扩展性、可靠性带来很大的影响,因此寻径算法设计是异步消息模型研究中的一个重要问题。
SRA之间可以采取静态或动态路由的策略。静态路由策略,在生成服务方对象引用时,在对象引用中嵌入路由信息。动态路由策略,每个SRA都动态地更新路由信息。我们结合TCP/IP协议的IP寻径技术与IRP寻径方法的优点,设计了链路-状态寻径(L-S)算法。利用该算法,消息传递的路径不依赖于Server提供的路径构件,而是通过SRA之间周期性地交换路径信息,来更新SRA维护的路由拓扑图的信息表为消息的传递提供路径。
链路-状态寻径算法是一种动态路由算法,能够适应大规模分布式对象环境的变化,保证消息的正确寻径,具有较大的应用前景。由于篇幅的原因,不对该算法进行详细描述。
2.4 MCL服务质量接口及算法
MCL提供了QSI,对消息的服务质量进行控制,实现了策略和机制的分离。服务质量信息是客户对Client及SRA处理消息的一种要求。客户方通过QSI设置自己的服务质量策略,该策略不仅控制客户方的行为,并随着RequestInfo传递来影响SRA的行为。
排序策略对消息的服务质量有较大的影响。排序策略不同,消息被服务的先后顺序不同。在分布对象异步消息模型中,消息的发送不必等待前面异步消息应答的返回,并且它们的传递路径可能不同,因此消息的发送极有可能出现“先发后服务”、“后发先服务”的情况。在这种情况下,客户方得到的应答结果可能是错误的。所以,排序策略及其核心算法是一个值得研究的问题。我们从Client-Server的全局的角度出发,设计了一种基于优先级的消息排序算法能够解决上述问题。
基于优先级的消息排序算法根据消息的优先级和同一客户方发出消息的依赖关系,控制消息被目标对象服务的顺序,有效地解决了服务顺序不合理的问题。
2.5 MCL消息装配适配机制
MAA的任务可以分为两个阶段:第一阶段:首先把Request Body中的信息与字节顺序装配为MessageBody结构,然后把MPA提取的信息与MessageBody装配为一个RequestMessage结构。
第二阶段:将RequestMessage及服务质量信息Qos、路由信息 RouteInfo、应答目的地 Target装配为一个可以存储转发的消息RequestInfo。
2.6 基于异步轮询的MCL处理算法设计
针对异步回调和异步轮询应答处理方法的不同,MCL的处理算法不同。在基于异步回调的TIAIM模型中,MCL需要对ReplyHandler对象的引用进行注册,并把提取出的请求消息包装为可以存储转发的消息。在基于异步轮询的TIAIM模型中,MCL不需要进行以上操作,但是要创建Poller对象并将它返回给Client。下面给出基于异步轮询的TIAIM模型中MCL的处理算法。
MCL处理算法:
由该算法可以看出,路由策略是影响MCL的主要因素。当使用TIAIM时,MCL激活MT,MT通过MPA提取原始请求消息,然后由MAA将消息进行装配为可以存储转发的消息,算法执行完毕时返回一个poller对象。算法的复杂度为O(n)。
3 TIAIM实现与测试
基于我们开发的CORBA企业级异构集成中间件平台,对TIAIM进行实验性实现与测试。引入TIAIM模型之后,应用系统发生了改变,主要表现在:
(1)客户方利用MCL将消息转换后,需要启动SRAs,服务方需要启动SRAT,中间节点可选择若干SRAM。(2)将SRAs对象引用配置到请求发送方。(3)配置SRA之间的路由关系,客户方代码只需设置适当的存储转发策略,服务器方不需要改变。引入TIAIM前后的性能如图所示。
引入TIAIM的企业级异构集成中间件平台实现了常规CORBA系统无法实现的功能,例如:消息的存储转发、断开的Client/Server应用、时间无关的激活和移动应用。在系统的性能方面,引入SRA后请求执行路径变长,对系统的性能产生影响。我们选择引入SRA前后的同一测试程序,在线程容量为75时的性能测试。H1表示引入SRA之后的测试结果,H1测试时要保证测试实体之间的连接,否则无法比较延迟。H2表示引入SRA前的测试结果。分析该图可以看出,在保证连接的情况下,引入SRA后的延迟大于引入SRA前的延迟。测试结果符合实际情况,因为引入SRA后请求执行的路径变长,在消息存储转发过程中,要进行对象创建和激活、请求排队以及包装应答结果等,对于要求时间无关的异步激活应用,是可以接受的。
4 结束语
实现分布对象中间件异步通信的时间解耦问题,是当前大型分布式应用软件的需求。通过在分布对象中间件异步通信模型中,引入消息转换机制和软件路由代理机制可以较好地解决上述时间解耦问题。本文重点论述了在分布对象客户请求端的消息转换机制。TIAIM在我们开发的基于CORBA标准的企业异构集成中间件中进行了实验,结果表明分布对象异步调用模型对于时间无关性有了很大的改进。
摘要：针对目前分布对象中间件消息通信机制中不支持时间解耦和服务质量控制的问题,提出一种能够支持消息异步传递和时间解耦的异步通信模型,通过在客户端引入消息转换层来完成异步消息的提取、包装和转换,将原始的请求转换为一种可路由的消息,然后设计一种软件路由代理来实现异步消息的传递与转发。重点论述了分布对象中间件异步通信消息的转换机制。
关键词：分布对象中间件,异步通信模型,时间解耦,消息转换机制
参考文献
[1]Vinoski Steve.New features for CORBA3.0.Communications of theACM,1998,41(10):44-52.
[2]Tai S,Rouvellou I.Srrategies for integrating messaging and distributedobject transactions.In:Proceedings of IFIP/ACM International Con-ference on Distributed Systems Platforms and Open Distributed Pro-cessing,New York,USA,2000:308-330.
[3]朱其亮,郑斌.CORBA原理及应用.北京:北京邮电大学出版社,2001.
[4]Object Management Group.CORBA Messaging Specification.http://www.omg.org,1998.
[5]Aahlad Y,Martin B,Marathe M,et al.Asynchronous notification a-mong distributed objects.Toronto:Proceedings of the 2nd Conferenceon Object-Oriented Technologies,1996,6.