消息中间件综述


—73— 消息中间件综述 徐 晶,许 炜 (华中科技大学电子与信息工程系,武汉 430074) 摘 要:从基本定义、主要特点、核心技术以及主要产品等诸多方面对消息中间件进行了全面的综述,并着重介绍了目前消息中间件产品 所采用的主流模式——消息队列模式中的体系结构、消息、队列以及队列管理器和触发机制等细节。 关键词:消息中间件(MOM);消息队列;订阅/发布;触发机制;容错 Summarization of Message-oriented Middleware XU Jing, XU Wei (Department of Electronics and Information, Huazhong University of Science and Technology, Wuhan 430074) 【Abstract】The basic definition, the important characteristic, the technique kernel and the common-used product of the MOM is presented. Also, the main modes now applied in MOM product——the structure of the message-queuing mode, the message, the queue, the queue manager and the trigger principle are discussed. 【Key words】Message-oriented middleware(MOM); Message-queuing; Subscribe/Publish; Trigger; Fault tolerance 计 算 机 工 程 Computer Engineering 第 31 卷 第 16 期 Vol.31 № 16 2005 年 8 月 August 2005 ·软件技术与数据库· 文章编号:1000—3428(2005)16—0073—04 文献标识码:A 中图分类号:TP31 1 消息中间件概述 1.1 消息中间件的定义 目前对消息中间件(MOM)的定义还未形成统一的行业 标准,我国也正加快对消息中间件技术的标准化研究工作。 一般认为,消息中间件是一种由消息传送机制或消息队列模 式组成的中间件技术,利用高效可靠的消息传递机制进行平 台无关的数据交流,并基于数据通信来进行分布式系统的集 成。与其它中间件技术不同(例如 ORB 和 RPC),一般来说, 消息中间件并不要求系统具备一个可靠的底部传输层,而是 通过以消息的形式收发应用程序数据来连接运行于不同系统 上的应用程序。信息可以同步传送,也支持异步传送。在异 步方式下,应用程序并不需要消息即时即刻传送到对方,只 是由 MOM 确保把信息以消息的方式传送到适当的目的地, 并且只传一次[3] 。 1.2 消息中间件主要特点 消息中间件属于中间件的一种,拥有中间件的主要特点, 但是自身的工作机制又具有特殊性,主要特点包括以下 6 个 方面:(1)异步传送;(2)防御通信;(3)并发执行;(4)日志通信;(5) 多种通信方式;(6)应用程序与网络复杂性相隔离。 1.3 消息中间件的发展 0 500 1000 1500 2000 1997 2002 对象 交易管理 消息代理 远程调用 数据访问 终端/图形 图 1 消息中间件发展趋势预测 国际数据公司(IDC)曾经预测(见图 1),1997~2002 年,增长率最高的中间件将集中在消息中间件。这一预测已 经成为现实,消息传输中间件已成为目前中间件领域中应用 最广、销售量最大的一类中间件产品,广泛地应用在金融、 邮电、交通、政府等数据传输频繁、交易量大的行业,国内 诸多行业信息系统建设中规划的“公共传输平台”都以消息 中间件的功能做为设计参考。今后几年,消息中间件将继续 保持稳步增长的势头。 2 MOM 的核心技术 2.1 通信模式 消息中间件是一种最“混乱”的中间件,主要有 3 种工 作模式:点对点模式,发布/订阅模式以及消息队列模式。通 常将点对点模式和发布/订阅模式统称为消息传递模式。 2.1.1 消息队列模式 消息队列模式是一种程序之间的非直接的通信模式,它 允许程序通过消息队列进行通信。消息队列模式通常意味着 无连接模式,并不强制要求对方程序一定可用。如图 2 所示。 消息放入队列(通常基于内存或者硬盘)直接或者按顺序传 送。这种方式允许程序按照不同的速度独立运行,而不需要 在双方之间建立一条逻辑连接。 主机A 主机B 应用A 应用D 应用C 应用B 队列1 队列4 队列2队列3 队列管理器 图 2 消息队列模式 尽管目前的消息队列产品在实现上存在差异,但是都具 有下列功能: 作者简介:徐 晶(1979—),男,博士生,主研方向为计算网络;许 炜,博士生 定稿日期:2004-05-22 E-mail:xujingking@sina.com —74— (1)通常都开发了相应的 API,方便应用程序开发员使用 以进行消息交换。 (2)系统中包含有一种固有组件——队列管理器。它处理 本地队列,并保证消息传送到存在与本机或者网络中某个位 置的目的地。消息队列管理器还包含其他一些功能,包括消 息确认的不同级别,优先级以及负载均衡等。 (3)队列管理器与其它节点上的队列器合作控制网络路 由机制。 (4)支持不同的“服务质量”。主要列表如下: 1)可靠的消息传送——在数据交换过程中不丢失网络数据包。 2)保证的消息传送——消息被直接(网络可用,不存在潜伏期) 或间接(网络不可用,存在一定的潜伏期)传送至目的节点。在间 接方式下,在某个特定的时间周期内,消息将被保证传送。 3)确定的、非复制的消息传送——消息如果被传送出去,将仅 仅传送一次。 (5)消息队列可以是永久性的或者非永久性的。当队列管 理器出现故障时,非永久性队列中的消息将全部丢失,而对 于永久性的队列中的消息会随着消息管理器的重起而恢复。 (6)支持触发,当请求消息和应答消息到达本地队列,但 是应用程序并未处于活动状态时启动一个应用程序。这种方 式允许应用程序只有在有工作需要完成的时候处于活动状 态,从而避免了不必要的资源浪费。 (7)某些产品采用了事务消息的概念。事务用来表示在队 列管理器的控制下,多中队列之间的入列和出列操作。它允 许把一个跨越多种网络节点(并且通常更新多种数据库)的 同步事务分割成许多较小的事务,然后采用异步方式处理, 通过异步消息机制来驱动。值得指出的是,目前一些消息队 列模式产品仅仅只能对事务包括的分布式队列进行调整。 (8)大多数支持多路复用技术。这一特点可以减少通信成 本以及网络贷款需求。 综上所述,采用消息队列模式的中间件对企业分布式应 用系统的开发具有非常的吸引力。它向开发者展现了一个丰 富而又灵活,同时非常简单的通信模式。消息队列模式适用 于事件驱动的应用开发,当一个应用程序发生了某一事件(通 常为表现为一个消息),会导致其他应用程序某种行为的发 生,这真实反映了一个企业或者跨越多个不同企业的复杂的 商务处理过程。 2.1.2 点对点模式 点对点模式是一种程序到程序的直接通信模式。应用请 求通过消息的形式直接从一个程序发送至另一个程序。双方 的程序采用面向连接的形式相互通信,程序之间必须维持一 条逻辑链路连接,所以点对点模式并不适合松耦合、时间独 立应用程序采用。需要强调的是,这种直接的链路连接通常 支持大多数的通信协议。 点对点模式的特点: (1)传送器可以提供阻塞或者非阻塞的行为,通常与一些类型服 务保证相关联。 (2)参与消息传送的应用程序组件在交换过程中处于活动状态, 共享一个逻辑通信会话。 (3)应用程序组件通常注册一个全局名字空间,以实现位置的独 立以及灵活的路由。 2.1.3 订阅/发布模式 订阅/发布模式从现实的贸易应用演化而来。虽然这个模 式目前来说仅仅被少数的产品所采用,但是这种技术已经到 达了一定程序的成熟。它在由信息生产者事件驱动的商务系 统的开发方面有很大的潜力。 发布者 订阅者A 订阅者B 订阅者C 消息总线 图 3 订阅/发布模式 如图 3 所示,在订阅/发布模式中,没有传统意义上的客 户端和服务器,而是网络中进行信息发布的应用程序和接收 某个特定主题信息的应用程序。发布消息的应用程序只需要 简单地将消息以主题方式发送出去,由消息代理来负责将消 息传递给所有订购该主题的订阅消息的应用程序。发布/订阅 模式由于更加智能有效,事实上已成为消息中间件的非正式 标准。其特点为: (1)通过消息代理进行通信 发布消息的客户端将消息传递给消息代理,由消息代理 负责路由消息给相应的订阅消息的客户端。由于消息代理可 以实现消息的动态路由功能,因此该方式能够提供较好的容 错性能。 (2)多维空间上松耦合 发布/订阅模式最大的优点是发布者和订阅者在多维空 间上是松耦合的。这种模式下,客户端和服务器不需要知道 对方的地址和具体的数量,简化了应用的配置,并且使组件 更易重用。具体体现在: 1)空间非耦合:发布者和订阅者不必相互知道; 2)时间非耦合:发布者和订阅者不必同时在线; 3)数据流非耦合:发布/订阅是异步模式。 消息中间件为企业提供数据传递已经有很多年了,但是 消息中间件始终没有一个统一的标准,各个产商各自采用不 同的通信模式,导致消息中间件产品的实现和接口各异,使 企业在选择产品时很难做出选择。随着 SUN 公司发布 Java 消息服务(Java Message Service)规范后,这种情况发生了变 化。尽管 JMS 还比较简单,但消息中间件支持 JMS 具有支 持不同厂家产品互操作的明显好处。国内各个开发消息中间 件产品的厂商,大都对 JMS 提供支持[5]。 2.2 安全 除了网络传输过程中的安全性问题外,系统崩溃后的消 息恢复问题也是一个重要的考虑因素。消息中间件具有消息 容错的特殊能力,用以解决在某个元素出现错误的环境中保 证服务不会中断。当错误发生时,系统有能力决定是在不丢 失数据的情况下继续系统的运作还是关闭系统重新启动,以 恢复所有正在进行的进程。容错通常包含一定程度的冗余度。 当消息传送失败后,系统能够恢复到最近“提交”。一旦消息 恢复后,处理可以重新开始,异常中断的事务也可再次提交。 容错常以服务形式提供。 2.3 基于消息队列模式 MOM 2.3.1 体系结构 基于消息队列模式的 MOM 主要由 5 个部分组成,接口 处理模块、消息队列、队列管理、消息通道代理和安全管理, 如图 4 所示。其中接口处理模块负责处理来自应用的服务请 求,根据应用请求的类型(数据或控制)分别进行不同的处 理,该模块具有名字服务、安全管理机状态查询等功能,负 责数据流的分割和组合,分组的加密/解密以及数据和消息之 —75— 间的转换。队列管理器是 MOM 的核心,负责创建和删除队 列,控制队列的行为和调整优先级。消息通道代理(MCA) 利用网络提供通信机制,负责将消息投递给响应的消息队列, 监测网络通道故障并完成故障恢复工作。安全管理则负责对 数据进行加密/解密操作,向用户提供安全的消息服务。 2.3.2 消息 在消息中间件中,不同的应用程序进程之间传递交换的 信息统称为消息,它是数据交换的基本单位。消息是由一些 位和字节组成的字符串,这些位和字节在具体的一个或多个 应用程序中具有特殊的含义。程序把它视为一个字段的序列, 其中每一字段都自己的数据类型和含义。 应 用 数据分割 数据组合 数据加密 数据封装 数据解密 消息解包 服 务 请 求 模 块 日 志 管 理 运 行 监 控 接 口 处 理 函 数 消息 MCA 至网络 应答包 数据包 应答包 数据流 请求 响应 写队列 发送队列 读队列 接收队列 发送模块 接收模块应答模块 读队列 包封装 写队列 包分析 服 务 处 理 模 块 数据包 控制包 响应 消息通道代理 队 列 管 理 器 图 4 基于队列模式 MOM 的体系结构 消息通常由两部分组成。除了应用数据之外,消息中还 包含了一些控制信息(常成为消息描述子),来指定消息的属 性,或者被消息队列服务用来决定消息的处理方式。其中一 些信息必须由应用本身来指定(例如,消息的目的地址)。应 用数据由发送方应用程序提供并给予定义,在形式上没有任 何的数据类型限制。消息中可以不包含任何应用数据,这种 类型的消息同样非常重要,通常用于标识某种特殊事件的发 生。控制信息由消息中间件定义,具体内容应当由发送方应 用程序来指定,它们描述了消息的各种不同的属性。所有的 控制信息均包含在一个被称为消息描述子的数据结构中。 消息中间件中的消息类型一般分为 4 种:数据报,请求, 应答以及报告。应用程序可以使用前 3 种类型的消息进行相 互的信息传送。第 4 种类型,报告,用于应用程序和队列管 理器报告事件信息。 每一个消息都拥有一个优先级属性,标识与其它消息的 相对重要性,可以使用其静态优先级,也可以动态地进行设 定。消息的优先级大小受到了队列管理器的限制,它可以指 定所能处理的消息的最大优先级,处于 0 到最大优先级的消 息才能获得处理,超出范围的消息将被丢弃。 2.3.3 队列以及队列管理器 队列是一种用以存储消息的数据结构。作为一般的操作, 消息可以被应用程序或一个队列管理器所放置或获得。队列 的存在不依赖于使用它们的应用程序。一个队列可以存在于 主存储区(如果它只是暂时性的),磁盘上或类似的辅助存 储区(如果它必须保存以防恢复),或者同时存在于两个地 方(当前它正在被使用,而且为了恢复而保存)。 当消息放入队列之前,队列必须建立。每个队列都属于 一个队列管理器,队列管理器将它接收到的消息放入正确的 队列中,一个队列管理器可以拥有除此之外的多个队列,但 是每个队列在拥有该队列的队列管理器中必须拥有一个独一 无二的名字。队列可以存在于本地系统中(这时它们被称为 本地队列),或者其它的队列管理器中(这时它们被称为远 程队列)。使用一个队列之前,必须打开该队列,指定想要 进行的操作。例如:浏览消息、接收消息、向队列中放置消 息、查询队列属性、设置队列属性等。 为应用程序提供队列服务并且管理所属队列的队列管理 器。它保证:(1)对象属性随所接收到的细节而改变。(2)在某 些适当的情况下产生一些特殊事件(例如:执行事件或者触 发)。(3)消息根据应用程序的请求放入正确的队列中。如果 没有,应用程序将被通告,并将给出一个准确的原因码。 应用程序所连接的队列管理器是该应用程序的本地队列 管理器。对于应用程序而言,属于其本地队列管理器的队列 都是本地队列。远程队列是属于其他队列管理器的队列。远 程队列管理器指除本地队列管理器以外的所有队列管理器。 一个远程队列管理器既可存在于一台网络中的远程机器上也 可以作为本地队列管理器存在于同一台机器上。一台机器上 可支持多个队列管理器。 2.3.4 触发机制 消息中间件系统中的应用程序采用持续运行机制时,可 以立即读取任何到达的消息, 但这样做只有当消息流动量大 且稳定时才适用。多数情况下, 应用程序在消息到达之前不 是活动的, 这时就需要设置消息队列的触发机制来激活处于 休眠状态的应用程序。触发机制的工作过程(如图 5 所示): (1)一条消息到达被触发的应用队列。 (2)队列管理器参考环境信息决定这条消息的到达是否 构成一次触发事件(是否满足触发条件)。 (3)队列管理器创建一条触发消息, 并将触发消息发送到 启动队列。 (4)触发监控器从启动队列中读出触发消息。 (5)触发监控器发出一条激活与触发队列相关联的应用 程序的命令。 (6)被启动应用程序从触发队列中取走消息并执行相应 操作。 消息队列 启动队列 应用程序 触发监测 应用程序 图 5 触发机制原理 如果给一个队列加触发器,那么队列必须与一个进程定 义对象建立关联。这个对象包含了处理消息的应用程序的信 —76— 息。当队列管理器产生触发消息时,队列管理器将相关的处 理的信息置入触发消息里面,这样触发监控程序能够获得这 些信息。每个队列能够指定不同的处理方法,也可以多个队 列使用一种处理方法。触发事件包括以下类型:1)队列变得 不为空:这种触发事件用来表明队列第一条消息,处理消息 知道队列为空;2)每次消息达到队列:处理一条消息;3) 一定数量得消息到达队列:处理多条消息。消息的数目可以 定义。 产生触发消息的条件:1)消息到达队列;2)消息权限 大于等于触发最低权限;3)处理程序名属性不为空;4)初 始队列已经被定义,并且没有被禁用;5)触发类型不为空类 型。 当条件被满足时,引起触发的消息将被放入工作单元中, 触发消息直到工作单元完成时,也就是工作单元被提交或者 停止时,才能被触发控制程序所获得。即使在工作单元停止 的情况下,也必须能够获得触发消息。这条规则表明,当触 发条件不满足时,有时触发消息也是可以获得的。此时,被 触发的应用程序必须进行相应的处理。如果一个可以产生触 发消息的消息在被获得之前就已经过期了,仍然会发送一个 伪触发消息。被触发的应用程序在启动后需要延迟一段时间 以后才能获得消息,这使得在其他相关消息提交前,产生触 发的消息能够达到同步点。如果消息来自远程的队列管理者, 那么这个时间还受到需要提交的消息数、连接速度以及消息 大小等因素的影响。 触发消息是依照触发的属性产生的。如果触发消息在产 生后还没有发布,改变触发属性对这条触发消息没有任何影 响。即使关掉触发开关,已经产生了的触发消息还是将发布。 如果触发消息产生了,但是不能发送到启动队列,那么 触发消息将发送到死信队列。如果发送仍然失败,那么这条 触发消息将被删除,并且没有任何提示。发送触发消息失败 对其他消息发送到消息队列没有影响。发送一个触发消息到 死信队列可能会引起该队列产生一个新的触发消息。如果这 条消息还是不能发送到启动队列,那么它将被删除。某些情 况下,在一个启动队列中可能出现重复的触发消息。 3 主要的 MOM 产品 目前开发消息传输中间件的厂商主要包括 IBM、Tibco、 东方通科技、中科国际等公司,产品主要有 MQSeries、 Rendezvous、TongLink/Q、A2E-MQ 等,所有产品均各具优 势。 4 结论 消息中间件集运行系统、管理工具集和开发系统 3 者于 一身,既为上层应用系统提供了可靠、高效的数据通信服务, 又为网络系统提供了实时管理和监控的工具,同时还为编程 人员提供了简单、易用、功能强大的应用开发接口。 随着 Internet 的普及和分布式应用新技术的不断涌现, 消息中间件技术将会以越来越快的速度发展,然而鉴于目前 消息中间件标准的研究现状——国内外研究性组织没有明确 提出任何标准,各厂商按照各自的技术优势设计实现软件产 品,导致市场上消息中间件产品的兼容性上出现了很大的问 题,为了更好地促进消息中间件技术的发展,统一市场上的 产品,制定相应的行业标准成了迫在眉睫的任务。如何进一 步完善 MOM 的基本功能,并将各种新标准融合在一起,使 其在分布式应用中发挥出更大的作用将是下一步的研究 目标。 参考文献 1 Bernstein P. Middleware: A Model for Distributed System Services. Communications of the ACM, 1996,39(2): 86-98 2 Verissimo P, Rodrigues L. Distributed Systems for System Architects. Kluwer Academic Press, 2001 3 Korhonen M. Message Oriented Middleware. Helsinki University of Technology, ttp://www.tml.hut.fi/Opinnot/Tik-110.551/1997/mqs.htm, 1997-08 4 Lingel K. Security Requirements for Message-oriented Middleware. http://www.eaijournal.com/PDF/MomSecure.pdf, 2001-06 5 Sun Microsystems. JMS Tutorial. http://java.sun.com/products/jms/ tutorial/ , 2002 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (上接第 72 页) 自占有的内存区域不同。通常 AA 只能在分配给它的内存区 域上进行操作,但当几个 AA 需要共享一些信息时,可以在 内存池中创建一个特殊的内存区域,将该区域添加到这些 AA 可使用的内存区域列表中。当某个 AA 不再需要使用共享区 域时,可从列表中将其删除。当所有相关联的 AA 均删除了 这个共享区域后,系统从内存池中删除该区域。 流事件分别在主动包的输入通道处理,AA、EE 定制处 理,输出通道处理的过程中触发。AA、EE 可以实现自己的 流事件回调函数定制主动包的处理过程。 (4)安全策略接口的实现。资源管理层中的安全管理模 块负责策略文件的编译、策略数据的存储和策略计算以获得 访问实体的权限。每一个安全策略都是与系统内的某个实体 或服务相关联的,安全策略配置模块就是以实体、服务 ID 和 策略文件的绑定向安全管理模块注册、注销和查询安全策略。 (5)主动结点的管理。主要是对 NodeOS、EE、AA 的资 源策略、安全策略、资源统计和状态的管理,可以分别通过 它们的资源上下文来管理。其中,NodeOS-EE API 层的资源 使用统计模块则提供了多种粒度的资源统计接口,这是通过 资源上下文资源使用统计表的上溯分类累加过程来实现的。 3 结束语 本文首先从各种类型的 EE、AA 以及管理应用对 NodeOS 的需求出发,提出了一套不依赖于特定 NodeOS 的方便、灵 活和通用的 API,然后基于我们提出的 NodeOS 体系结构讨 论了接口实现的关键机制。该套接口具有通用、支持多个 EE 以及便于第三方 EE 开发的特点。 参考文献 1 Calvert K L. Architectural Framework for Active Networks (Version 1.0). RFC Draft[R], 1999 2 DARPA AN Node OS Working Group. NodeOS Interface Specification[R]. 2001 3 Tullmann P. Janos: A Java-oriented OS for Active Network Nodes[J]. IEEE Journal on Selected Areas in Communications, 2001, 19 (3): 501-510
还剩3页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 10 金币 [ 分享pdf获得金币 ] 0 人已下载

下载pdf

pdf贡献者

Azureflame

贡献于2017-02-20

下载需要 10 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf