1、 题 （中、英文） 目 基于 ActiveMQ 的消息中间件的设计与实现 Design and Implementation of Message Oriented Middleware Based on ActiveMQ 作 者 姓 名 汪然 臧明相 副教授 计算机技术 提交论文日期 二一三年三月 黄战武 高工 学校指导教师姓名职称工 程 领 域 企业指导教师姓名职称 论文 类型 代号 分类号 学号 密级 10701 TP311.5 公开 1077490442 U D C 编号 应用软件技术 西安电子科技大学 学位论文独创性声明 秉承学校严谨的学风和优良的科学道德，本人声明所呈交的论文是我个
2、人在导师指导下进行的研究工作及取得的研究成果。尽我所知，除了文中特别加以标注和致谢中所罗列的内容以外，论文中不包含其他人已经发表或撰写过的研究成果；也不包含为获得西安电子科技大学或其它教育机构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均已在论文中做了明确的说明并表示了谢意。 申请学位论文与资料若有不实之处，本人承担一切 法律 责任。 本人签名： 日 期 ： 西安电子科技大学 关于论文使用授权的说明 本人完全了解西安电子科技大学有关保留和使用学位论文的规定，即：研究生在校攻读学位期间论文工作的知识产权单位属西安电子科技大学。学校有权保留送交论文的复印件，允许查阅和借阅论
3、文；学校可以公布论文的全部或部分内容，可以允许采用影印、缩印或其它复制手段保存论文。同时本人保证，毕业后结合学位论文研究课题再撰写的文章一律署名单位为西安电子科技大学。 （保密的 论文在解密后遵守此规定） 本学位论文属于保密，在 年解密后适用本授权书。 本人签名： 导师签名： 日 期 ： 日 期 ： 摘要 近年来，随着计算机以及网络相关技术的飞速发展 ，越来越多的应用程序运行在分布式的环境中。 为了实现 分布式应用 之间的透明通信 ， 消息中间件 技术应运而生。消息 中间件屏蔽了底层分布式环境的复杂性和异构性，简化了分布式应用程 序的开发 难度 。 但是在实际的使用中发现 ， 现有 消息中间件
4、 存在着管理 落后、使用繁琐等问题。 本文 在 研究了现有的几种消息 模型 基础上 ，提出了一种改进的消息队列 模型 ，该模型 将消息队列与若干个消息服务器 通过映射 关联起来 ， 基于这种模型 的消息队列的管理 方式 ，细化 了 消息中间件的扩展粒度 ，简化 了 系统的管理难度 ；设计了消息缓存方案， 将消息暂存在本地，在网络畅通后将消息转发到消息服务器，极大 地 提高了消息中间件的可靠性； 设计了连接池，由连接池自动管理消息发送过程中连接的建立、使用、关闭等过程 ， 为应用程序提供 更加 简单易用的接口 。 测试 结 果表明， 本文设计和实现的 消息中间件的 消息吞吐量更高 ，使用更加方便
5、， 可靠性更高，解决了消息中间件 的 管理效率 低 下、使用繁琐等问题。 在后续的研究工作中，将进一步加深对消息中间件 底层 关键技术的研究，并在此基础上，实现功能插件化和底层无关化。 关键词： 消息中间件 ActiveMQ Java 消息服务 分布式 监控系统 Abstract In recent years, with the rapid development of computer and network related technologies， more and more applications run in a distributed environment. In order
6、 to achieve transparent communication among distributed applications, messaging middleware technology came into being. Messaging middleware technology shields the complexity and the heterogeneity of distributed environment and simplifies the development of distributed applications. However, in the u
7、se process, a series of problems, such as poor management and cumbersome to use, have been presented. An improved message queue model is proposed after studying several message models. The proposed message queue associates with message queue and several message servers by mapping. Based on this new
8、model, a new management idea that would refine the scalable granularity and simplify the difficulty of management is brought out. In order to improve the reliability of the message oriented middleware, a message caching solution is designed. The message caching solution allows messages to store in t
9、he local temporarily when network is not available. At last, this paper designs a connection pool that would control the connection procedure automatically, such as connection establishment, connection retention and connection close. The connection pool makes it possible for providing easier and mor
10、e convenient interface for applications. The test results show that the new message oriented middleware is more convenient and reliable, and solves the problems of low efficiency of management and complexity in use. In further research, the underlying technology of message oriented middleware would
11、be further studied. Based on that analysis, pluggable function and independent underlying details of message oriented middleware will be realized. Keywords： Message Oriented Middleware ActiveMQ Java Message Service Distributed System Monitoring System 目录 第一章 绪论 1 1.1 研究背景 1 1.2 研究现状 2 1.3 本文工作 3 1.4
12、 章节安排 3 第二章 消息中间件技术研究 . 5 2.1 中间件概述 . 5 2.1.1 中间件的基本概念 . 5 2.1.2 中间件的分类 . 6 2.1.3 消息中间件 . 6 2.2 JMS 概述 . 8 2.2.1 JMS 的体系结构 9 2.2.2 JMS 主要接口 11 2.2.3 JMS 收发消息 13 2.3 ActiveMQ 概述 14 2.4 本章小结 16 第三章 基于 ActiveMQ 的消息中间件总体设计 . 17 3.1 需求概述 17 3.2 需求分析 18 3.3 总体设计 20 3.3.1 发送消息流程设计 . 21 3.3.2 接收消息流程设计 . 21
13、3.4 本章小结 22 第四章 消息中间件服务器端设计与实现 23 4.1 配置管理 23 4.1.1 集群管理 . 24 4.1.2 消息队列管理 . 26 4.2 消息队列监控 . 28 4.3 本章小结 31 第五章 消息中间件客户端设计 . 33 5.1 客户端功 能概述 . 33 5.2 配置连接管理 . 34 5.3 消息发送 . 37 5.4 消息接收和消息过滤 . 41 5.5 本章小结 . 42 第六章 系统测试 . 45 6.1 环境的搭建 . 45 6.2 测试内容 . 45 6.2.1 性能测试 . 45 6.2.2 监控报警测试 . 46 6.2.3 消息缓存测试 .
14、 48 6.3 本章小结 . 48 第七章 结束语 49 7.1 总结 49 7.2 展望 50 致谢 51 参考文献 53 第一章 绪论 1 第一章 绪论 1.1 研究 背景 随着 互联网的发展，企业的 系统 架构和以往相比有了巨 大的变化。企业级的应用 系统 不再 局限 于 单机 系统和简单的客户 /服务器系统，而是 向 着三层 或 多层体系结构的分布式环境不断迈进 1。所谓三层结构，就是在原有的“两层结构”（客户端和服务器端） 间增 加 了一层 新的 组件，这层组件包括事务处理逻辑应用服务、数据库查询代理等 ，增加的这层组件就叫做“中间件” 。两层结构向三层结构转变后， 不但 减轻 了
15、客户端与 服务器端的负载， 还 解决 了跨平台、传输不可靠等问题 。中间件在 软件系统 三层结构中主要充当中间层， 以 保证 数据 的安全和传输 数据 的完整 ， 并 通过负载 均衡来调节系统的工作效率，从而弥补两层系统 构的不足。在分布式环境中，无论硬件平台还是软件平台都不可能做到统一 ， 大规模的应用软件通常要求在软硬件各不相同的分布式网络上 运 行。为了更好地开发和应用能够运行在这种异构平台上的软件，迫切需要一种基于标准的 ，并且 独立于计算机硬件 和 操作系统的开发 、 运行环境，中间件技术 随之 诞生了 2。 分布式应用系统借助消息中间件在不同的系统 之间共享资源，管理计算资源和网络
16、通信 3。消息中间件适用于任何需要网络通信的系统，负责建立网络通信的通道，提供公共的通信手段，并且独立于网络和操作 系统，进行消息或文 件发送。消息中间件为开发者提供了独立于 应用 环境的应用程序接口， 应用程序 使 用消息中间件提供的接口 ，便可利用其运行的特定操作系统和网络环境的功能，为应用执行通信功能，从而满足企业内部对应用系统伸缩性和扩展性的要求。 但是在使用过程中，发现现有消息中间件存在以下几个问题。 (1) 缺乏便捷的系统管理功能。 一个 系统的质量 ， 很大部分取决于开发后对系统的管理和维护 ，目前 许多消息中间件标准和产品已经 能够提供良好 的开发平台和通信支持 ， 但是却忽视
17、了系统管理功能，不能为系统管理员提供一个便捷的控制系统接口。 企业应用通 常需要根据业务的需求动态调整应用的部署，消息中间件作为广泛使用的平台型组件，就需要提供更加细的管理粒度 4。 (2) 使用 过程 繁琐。 消息中间件在通信过程中需要创建、保持和关闭连接，对于需要频繁使用消息中间件的应用，就需要不断重复这一过程，不仅增加了开发者的负担，还侵入了应用程序的业务代码。此外，开发者还需要 处理 消息中间件通信过程中可能产2 基于 ActiveMQ 的消息中间件的设计与实现 生的各种异常 ，同样增加了消息中间件的使用成本。 (3) 监控系统的适应性 不足。 企业通常使用自己的监控系统，以达到个性化
18、定制报警信息的目的，如何将消息中间件纳入到现有的监控系统中 ，也是 企 业用户 需要面临的问题之一。 为了解决消息中间件在使用、维护过程中存在的 上述 问题，本文研究了消息中间件技术，并在现有 技术 的基础上，设计实现了一种新的消息中间件，解决了上述问题。 1.2 研究 现状 消息中间件 起源于 对 分布式操作系统进程通信模型和分布式应用互操作技术的研究。 1980 年代，随着开放系统互连参考模型 OSI 的兴起，作为开放系统网络模式中底层的包交换通信范型 的一种自然扩充，分布式系统消息机制的研究和应用得到极大的发展， 统一处理消息发送、接收和管理的消息中间件的概念和平台也随即 出现。 198
19、0 年代后期， IBM 公司推出了消息中间件产品 MQSeries，成为消息中间件 技术 成熟的一个标志。 进入 1990 年代， 大规模的分布式 应用 广泛应用于互联网 公司 ，消息中间件技术得到极大的发展，并在世界范围内涌现出大量的消息中间件产品。为了 推动 消息中间件技术的 发展 ，由众多消息中间件厂商、用户和咨询机构组成了消息中间件协会（ Message oriented Middleware Association，简称 MOMA）， MOMA 是一个非盈利机构，旨在推动消息技术在跨平台、跨层次的分布计算中的广泛应用。国际对象管理组织（ Object Management Group
20、，简称 OMG）制定了公共对象服务标准（ Common Object Service Specification，简称 COSS），其中对消息服务进行了规范。 进入 21 世纪，消息中间件技术得到进一步的发展。在规范化方面，由于 J2EE技术的广泛应用， J2EE 的消息服务规范 JMS（ Java Message Service）得到消息中间件厂商的广泛采纳，并逐渐成为消息中间件的事实标准，与此同时， Web 服务技术的兴起，与 Web 服务相关的标准体系得到发展，在消息方面， W3C 组织定义了 Web 服务的可 靠消息传送规范（ Web Services Reliable Messagi
21、ng，简称WSRM） 5。 随着分布式系统间数据交换需求的 迅猛 增长 ，我国的消息中间件技术也有了蓬勃 的 发展。如东方科技公司出品的 TongLINK/Q6，不但 全面支持 JMS 规范标准 ，还具有 高效、可靠、实用等特点。 自 1993 年诞生以来，已成功运行在金融、电信、交通、政府等行业的数百个大、中型企业级应用系统中。 第一章 绪论 3 1.3 本文工作 本论文课题来源于 某 公司平台架构部的消息中间件产品，项目代号 Napoli。该项目 旨在 为分布式应用程序提供高效、 稳定的消息解耦中间件 ， 同时兼具集群管理， 异常 处理等功能 。 本文 主要的工作和创新点如下 ： 1. 设
22、计并实现了消息中间件 Napoli (1) 研究了消息中间件的相关 技术 在研究中间件技术的基础上，重点研究了消息中间件的技术规范与实现方法。通过分析现有消息中间件的不足 ，提出了 基于 ActiveMQ 的消息中间件的 设计 思路。 (2) 提出了逻辑消息队列的模型 通过 分析 现有消息 模型 ，提出了将现有消息队列重新组合生成逻辑消息队列的模型。 逻辑消息队列 由 多个消息服务器上的物理消息队列组成， 通过调整逻辑消息队列与物理消息队列的映射关系，能够灵活的扩展 每一个消息队列的性能，解决了传统消息中间件只能在系统级别扩展的 不足 。 (3) 设计并实现了 连接池 自动管理模块 传统的消息
23、中间件在使用时不仅需要频繁的创建、使用、关闭连接，还需要对使用过程中抛出的异常进行处理。本文设计实现了连接池，通过对连接池内资源的统一调度，减少了对应用程序代码的侵入，降低了应用程序的使用成本。 (4) 设计并实现了 异常 处理 模块 针对可能出现的系统故障和网络中断等极端情况，设计实现了消息缓存模块。使消息中间件在极端条件下也能正常工作，保证了应用程序自身业务的正常 执行 ，极大的提升了 Napoli 的 可靠性 。 2. 完 成了对 消息中间件 的测试 测试 了 消息中间件 的功能及异常处理能力，分析对比测试结果，指出了 Napoli消息中间件 的优势 ，并提出了后续 的改进 思想 。 1
24、.4 章节安排 本文共分为 七 章，各章的主要内容安排如下： 第一章 介绍了课题研究的背景、现状以及使用消息中间件进行通信的意义。 第二章 相关概念介绍。介绍了中间件 的概念 及分类，着重介绍了消息中间件的特点 、 JMS 规范 及 相关 API， 最后介绍了一款基于 JMS 标准实现的产品 ActiveMQ。 4 基于 ActiveMQ 的消息中间件的设计与实现 第三章 分析了现有消息中间件的不足，结合用户的需求，设计了基于ActiveMQ 的消息中间件的框架结构，并叙述了每个模块的具体功能。 第四章 详细叙述了消息中间件 服务器 端的实现方案。 第五章 详细叙述了消息中间件客户端 端的实现
25、方案。 第六章 测试基于 ActiveMQ 的消息中间件的性能 及功能 。 第七章 对本文做一个总结，分析了本文研究的“基于 ActiveMQ 的消息中间件的设计与实现”的优点和不足以及如何改进。 最后是 致谢和 参考文献。 第二章 消息中间件技术研究 5 第二章 消息中间件 技术研究 消息 中间件技术应用广泛，各种中间件层出不穷。 本章将对 消息中间件 技术相关理论进行研究 ，针对 Napoli 消息中间件 的特点，选 择 ActiveMQ 作为消息中间件的基础服务产品 ，并详细研究其关键技术。 2.1 中间件概述 2.1.1 中间件的基本概念 中间 件（ Middleware）是和操作系统
26、、数据库并列的三大基础软件。定义有很多种，其中被普遍接受的是 IDC（ Internet Data Center） 的定义：中间件是一 类独立 于 具体的应用软件的 软件或服务， 借助于这类软件， 分布式应用 程序 解决了不同的 平台 和应用环境 之间 的 共享资源 的 问题 。在结构上， 中间件位于客户端和操作系统之 间 ，管理计算机资源和网络通信 7，如图 2.1 所示 8。 应 用应 用操 作 系 统操 作 系 统应 用应 用中 间 件中 间 件网 络网 络图 2.1 中间件 的作用 分布式应用程序的开发需要面对不同的操作系统和异构网络环境下不同 的 网络 协议 带来的困难 ， 中间件
27、通过提供通用 的 API 屏蔽了这些问题， 使程序开发人员面对一个简单而统一的 开发环境 ，减少 了 软件开发 的复杂性， 使开发人员能够集中 注意力在 软件自身的业务逻辑 上 ， 避免了 为 软件 在不同 平台和运行环境上 移植而重复工作，从而大大减少了 应用程序的开发成本 。中间件 不但降低了 开发的6 基于 ActiveMQ 的消息中间件的设计与实现 难度 、 缩短了 开发周期， 还 减少了系统的维护、运行和管理的工作量， 降低 了计算机总体费用的投入 9。正是因为中间件对软件开发 有着 重要 的 作用 ，中间件已成为许多标准化工作的主要部分。 对于应用软件开发，中间件远比操作系统和网络
28、服务更为重要，中间件提供的程序接口定义了一个相对稳定的高层应用环境 。 升级 硬件资源或 系统软件 后 ，将中间件 同步 更新， 使中间 件适应底层的硬件或系统软件的变更， 并 维持 中间件对外 提供的服务接口 不变， 上层 应用软件 就可以 几乎 不做任何代码修改 依然可以正常运行 ， 从而 将对应用软件的开发维护转移到对中间件的维护上，减少了企业应用的开发和维护成本 10。 2.1.2 中间件的分类 中间件 种类繁多， 按照应用场景 的不同， 可以分为以下几类 11： 消息（ 通信处理）中间件 12 利用高效可靠的消息传递机制实现 不同平台之间 的 数据 通信， 通过与分布式应用系统之间的
29、集成通信 ，解耦分布式应用程序 ， 如 Tong LINK、 HornetQ、 金蝶软件的 Apusic 等 产品。 数据存取管理中间件 数据存取管理中间件 处理 应用程序与数据库之间的 连接以及读写数据库逻辑的功能 ，包括 管理 应用程序 与数据库的连接， 数据 缓冲、转换从数据库获得数据等步骤 。 交易中间件 13 交易中间件是专门针对 需要处理大量交易订单而设 计的 ， 电子商务 类 网站 需要 在分布式事务处理系统中要处理大量事务， 交易中间件负责正确的传递交易，管理交易的完整性，调动系统资源和应用程序均衡负载运行，保证分布式环境中各节点交易结果处理的一致性、可靠性和完整性。 2.1.
30、3 消息中间件 消息中间件（ Message Oriented Middleware）是指支持与保障分布式应用程序之间同步 /异步收发消息的中间件。消息是分布式应用之间进行数据交换的基本信息单位，分布式应用程序之间的通信接口由消息中间件提供。其中，异步方式指消息发送方在发送消息时不必知道接收方的状态，更无需等待接收方的回复，而接收方在收到消息时也不必知道发送方的目前状态，更无需进行同步的消息处理，它们之间的连接完全是松耦合的，通信是非阻塞的，这种异步通信方式是由消息第二章 消息中间件技术研究 7 中间件中的消息队列及其服务机制保障的。一般地，实时性要求较高的业务采用同步方式处理，实时性要求不高
31、的业务采用异步 方式进行处理。 消息中间件适用于需要可靠的数据传送的分布式环境。采用消息中间件 技术的系统 ，不同的对象之间通过传递消息来激活对方的事件，完成相应的操作。发送者将消息发送给消息服务器， 消息服务器将消息存放在一个先进先出的队列中，当接收者不在线或者网络中断时，消息将一直保存在消息服务器，直到接收者在线或者网络恢复后再将消息转发给接收者。不同平台、不同网络结构都能使用消息中间件通信，消息中间件通过屏蔽各种平台和网络协议的差异，使应用程序之间能够通过收发消息协调工作 。消息中间件能够在客户端和服务器之间提供同步或异步的 连接，同步连接将消息直接以点对点的方式传送 接收端 ，异步连接
32、发送的消息由服务器转发给接收端 14。 应 用 程 序 A应 用 程 序 A消 息 中 间 件 / 企 业 消 息 系 统消 息 中 间 件 / 企 业 消 息 系 统应 用 程 序 B应 用 程 序 B应 用 程 序 接 口应 用 程 序 接 口图 2.2 消息中间件 如 图 2.2 所示，应用程序 A 与应用程序 B 通过 消息中间件 提供 的 API 发送消息进行 异步 通信 ， 消息并没有由应用程序 A 直接发送给应用程序 B， 应用 程序 A将消息发送给消息中间件，由 消息中间件 负责 将消息 转发 给应用程 序 B， 正是这样的 方式 解耦了分布式应用程序，使 互相通信 的应用程序
33、不必同时在线 。 消息中间件 封装了 网络通信 逻辑，当 网络连接不可用 时 ， 消息 将 一直存储在 消息中间件服务器上 ，直到连接变得可用时， 消息 服务器 再将消息转发给应用程序 B15。 消息中间件具有以下一些基本特点： 1. 存储和转发 信息 消息中间件 使用消息服务器 暂存 应用程序发出的消息， 应用程序 可以 发 送 消息给 那些离线的应用程序 或不可达的应用程序， 并且能够在网络恢复可用或接收应用 能够 正常工作时及时 地 将消息转发给接收应用 程序 。 8 基于 ActiveMQ 的消息中间件的设计与实现 2. 防御通信 应用程序通信 过程 中 可能发生各种异常情况 ， 从而
34、引起应用程序自身的严重问题 ， 引入消息中间件后，由消息中间件管理消息的通信过程，将应用程序与消息通信隔绝，保护应用程序不被通信失 败干扰 16。 3. 并发执行 使用耦合性较高的通信方式如远程过程调用，当发送者需要与多个接收者时通信时，发送者需要依次等待每一个接收者确认接收后才能继续发送消息，这样的通信方式需要用复杂的同步 通信 编程技术实现，不但增加了编程复杂度，也影响应用程序自身的业务。 使用消息中间件，降低了通信过程的编程技术 要求 ，应用程序将消息交给消息中间后，即可继续处理自身的业务。 使用 消息中间件传递消息，应用程序可以与多个不同的接收方通信而不必等待接收响应 ，接收方可以异步
35、处理收到的消息而不必阻塞自身的业务处理流程 。 4. 无连接通信 面向连接 的通信并不总是实用 的 ， 面向连接意味着通信的双方都明确对方的存在，并且需要同时在线 ，当接收方处在离线状态时，发送方就不能建立与接收方的连接。利用消息中间件，发送方可以发送消息到目的地暂存消息，接收者在合适的时候从目的地获取消息，消息的发送者不必建立 与 接收者之间的连接，发送者甚至不需要知道具体的接收方，就可以完成通信过程。 5. 灵活的多种 通信 方式 在复杂的应用场合中， 通信 程序之间不仅可以是一对一的关系，还可以进行一对多 或 多对一方式，甚至是 不确定通信对象的数量 。利用消息中间件，应用程序 在不增加
36、使用复杂性的情况下， 可根 据自身需要选择 合适的 通信 方式， 采用消息队列或者主题达到一对一或一对多的 通信 。 6. 应用程序与网络复杂性相隔离 消息中间件 屏蔽了网络通讯的复杂性 ， 使分布式应用程序之间 不 必 直接 进行连接通信 。 应用 程序 通过将消息存放在目的地，然后由对应的应用程序将消息从目的地取出的方式，解耦了应用程序之间的数据通信 。 与消息存放和获取无关的全部操作， 比如消息队列 的 维护 、 应用 程序和 消息队列之间连接的维护 、网络 故障 的 异常处理和消息队列中消息的派发等都由 消息中间件 来处理 ，应用程序无需关注应用程序 复杂的网络环境 1718。 2.2
37、 JMS 概述 JMS 是 Java 平台上有关面向消息中间件的技术规范，它便于消息系统中的Java 应用程序 进行消息交换 ， 并且通过提供标准的产生、发送、接收消息的接口第二章 消息中间件技术研究 9 简化 企业 应用的开发 19。 JMS 提供 了一组与厂商无关的 API 来实现 消息收发服务 ，并鼓励 JMS 客户端程序使用这些接口来创建程序 20。 目前， JMS 得到了 许多厂商 的 支持 ， 推出了各种基于 JMS 的消息中间件产品， 包括 IBM 的 MQSeries21、 Apache 的 ActiveMQ和 Progress 的 SonicMQ 等 22。 统一的接口和规范
38、 使 应用程序 能够通过消息收发服务从一个 JMS 客户 端 向另一个 JMS 客户 端 发送消息。 2.2.1 JMS 的 体系结构 JMS 定义了 以下 几种 元素，所有遵从 JMS 规 范的产品必须实现这些 元素，按照 JMS 规定的通信模型通讯。由于语言、平台的不同，元素的内部实现各有不同，但是由于 JMS 规范了统一的接口和数据 模型 ，使跨平台的通信成为可能，大大增加 了消息中间件的使用范围。 (1) JMS 提供者 JMS 提供者 实现 JMS 规范的消息队列和通知等 接口 ，对外提供消息服务 。提供者 既 可以是 基于 Java 平台实现 JMS，也可以是 由 其他 平台 开发
39、 的 、 面向消息中间件的适配器。 (2) JMS 客户 生产或消费基于消息的 Java 的应用程序或对象。 (3) JMS 生产者 创建并发送消息的 JMS 客户。 (4) JMS 消费者 接收消息的 JMS 客户。 (5) JMS 消息 包括可以在 JMS 客户之间传递的数据的对象 。 由两部分组成：报头和消息主体。报头由 目的地 信息以及 与 该消息 有关的属性信息如优先级、消息类型等 构 成。消息主体则携带着应用程序 发送 的 有效 数据或有效负载 23。 此外， JMS 还定义了以下两种消息模型 ： (1) 队列模型 这种模型用来解决 生产 者和消费者之间点到点的通信。 在队列模型下
40、， 消息生产者 发送消息到 一个 由某个名字标识的 特定 虚拟通道 ，消费者 连接到该虚拟通道后获取其中的 消息。这里，生产者 和消费者 需要 预先 知道 虚拟通道的标识 ，消息 才 会被直接 发送到 该标识所对应的虚拟通 道 。 在 这种模式 下， 生产者 和消费者可以不必同时处在工作状态， 虚拟通道 会按照先进先出的顺序在消费者能够正常工作后将消息转发给消费者， 虚拟通道 转发的消息只能被一个消费者接收，消费10 基于 ActiveMQ 的消息中间件的设计与实现 者接收到消息并处理完之后向 通道 发送确认信息， JMS 提供者将 确认接收成功的消息从消息队列中删除 24， 队列模型 如图
41、2.3 所示。 消 息客 户 端 A客 户 端 A消 息 队 列消 息 队 列客 户 端 B客 户 端 B发 送发 送接 收接 收确 认确 认消 息图 2.3 队列模型 (2) 发布 /订阅 者 模型 发布 /订阅者模型支持向一个特定的消息主题发布消息 ， 一个 或多个订阅者可能对接收来自特定消息主题的消息感兴趣。在这种模型 下，发布者和订阅者彼此不知道对方 ， 这种模式好比是匿名公告板。这种模式被概括为：多个消费者可以获得消息 ； 在发布者和订阅者之间存在时间依赖性。发布者需要建立一个订阅（ subscription），以便客户能够购订阅 25。 发布者发送消息到一个主题 ， 消息会存储在消
42、 息服务器上，所有订阅该主题的在线订阅者都会收到消息的一个副本，离线的订阅者也会在上线后收到消息的副本，当所有的订阅者都收到消息的副本后，JMS 提供者 删除主题内的该消息 26， 发布 /订阅者模型 如图 2.4 所示 27。 消 息发 布发 布接 收接 收消 息主题主题传 送传 送接 收接 收传 送传 送客 户 端 A客 户 端 A客 户 端 C客 户 端 C客 户 端 B客 户 端 B图 2.4 发布 /订阅者 模型 一个 典型的 JMS 应用系统 由 四个部分组成，其结构如图 2.5 所示 。第二章 消息中间件技术研究 11 J M S 提 供 者J M S 提 供 者JbossMQJ
43、bossMQActiveMQActiveMQIBMWebSphereMQIBMWebSphereMQBEAWeblogicMQBEAWeblogicMQ客 户 程 序 J M S A P I客 户 程 序 J M S A P IJMS消息客 户 程 序 J M S A P I客 户 程 序 J M S A P IJMS消息客 户 程 序 J M S A P I客 户 程 序 J M S A P IJMS消息图 2.5 JMS 应用 系统的 组成 结构 (1) JMS 客户 端 ：使用 JMS API 发送 或 接收消息的 Java 程序。 (2) 消息：客户端之间交换的 、 由 消息中间件服务
44、器 转发的 信息 ，是客户端之间交换的 有效 数据的载体 。 (3) JMS 提供者： 实现了 JMS 规范 的消息中间件服务器， 用来存储、转发 JMS客户端发送的消息， 是 JMS 应用程序最主要的部分。 (4) 受管对象： 由系统管理员创建和配置的 JMS 对象 ， 受管对象和命名服务中的名称相互绑定在一起 28， JMS 客户端通过浏览 、 引用命名空间内的受管对象，来管理消息队列，收发消息等 。 JMS 中定义了两类受管对象： a) 连接工厂：用于创建 应用程序和消息服务器之间的通信链路 。 b) 目的地： 包装了消息目标标识符的被管对象 ， JMS 客户端 通过目的地标识来 指定
45、被发送的消息目标或接收 消息 的来源 29。 2.2.2 JMS 主要 接口 JMS API 是消息服务的核心部分，所有接口都 在 javax.jms 包中提供。 JMS的接口有通用接口，点对点模型接口和发布 /订阅 者 模型接口。 通用接口 在点对点模型和发布 /订阅模型中均可使用，点对点模型专用接口只能用在点对点模型中，发布订阅模型接口只能用在发布 /订阅模型中 ， JMS 定义的 API30如 表 2.1 所示。 12 基于 ActiveMQ 的消息中间件的设计与实现 表 2.1 JMS 公共接口、点对点接口和发布 /订阅接口 JMS 公共接口 PTP 专有接口 Pub/Sub 专有接口
46、 ConnectionFactory QueueConnectionFactory TopicConnectionFactory Connection QueueConnection TopicConnection Destination Queue Topic Session QueueSession TopicSession MessageProducer QueueSender TopicPublisher MessageConsumer QueueReceiver,QueueBrowser TopicSubscriber (1) ConnectionFactory 接口（连接工厂） 用
47、来 创建 从 JMS 客户端 到 JMS 提供者之间 连接的被管对象。 JMS 客户 端 通过可移植的接口访问连接，这样当下层的实现改变时，代码不需要进行修 改。 管理员在 JNDI 名字空间中配置连接工厂，这样， JMS 客户才能够查找到它们。根据消息类型的不同，用户 可以 使用队列连接工厂，或者主题连接工厂。 (2) Connection 接口（连接） 31 连接代表了应用程序和消息服务器之间的通信链路。在获得了连接工厂后，就可以创建一个与 JMS 提供者的连接。根据不同的连接类型，连接允许用户创建会话，以发送和接收队列和主题到目标。 (3) Destination 接口（目标） 32 目
48、标是一个包装了消息目标标识符的被管对象，消息目标是指消息发布和接收的地点，或者是队列，或者是主题。 JMS 管理员创建这些对象，用户通过 JNDI发现它们。和连接工厂一样，管理员可以创建两种类型的目标，点对点模型的队列，以及发布 /订阅者模型的主题。 (4) MessageConsumer 接口（消息消费者） 由会话创建的对象，用于接收发送到目标的消息。消费者可以同步地（阻塞模式），或异步（非阻塞）接收队列和主题类型的消息。 (5) MessageProducer 接口（消息生产者） 由会话创建的对象，用于发送消息到目标。用户可以创建某个目标的发送者，也可以创建一个通用的发送者，在发送消息时指
49、定目标。 (6) Message 接口（消息） 33 是在消费者和生产者之间传送的对象，也就是说从一个应用程序 传 送到另一个应用程序。一个消息有三个主要部分 34：消息头（必须）：包含用于识别和为消息寻找路由的操作设置。一组消息属性（可选）：包含额外的属性，支持其他提供者和用户的兼容 ， 可 以创建定制的字段和过滤器（消息选择器）。一个消息体（可第二章 消息中间件技术研究 13 选）： 用户 可以 创建五种类型的消息（文本消息，映射消息，字节消息，流消息和对象消息）。 (7) Session 接口（会话） 35 表示一个单线程的上下文，用于发送和接收消息。由于会话是单线程的，所以消息是连续的，就是说消息是按 照发送的顺序一个一个接收的。会话的好处是它支持事务。如果用户选择了事务支持，会话上下
