JAVA基于JMX框架的JMS服务器的设计和实现

1、分类号 TP31 密级 公开 UDC 编号 硕士研究生学位论 文 题题 目目 基于基于 JMXJMX 框架的框架的 JMSJMS 服务器服务器 的设计和实现的设计和实现 学院（所、中心） 软件学院 专 业 名 称 软件工程 研究生姓名 陈冬 学号 导 师 姓名 周华 职称 研究员 2007 年 4 月 声 明 本人声明所呈交的论文是我个人在导师指导下进行的研究工作及取得的研究 成果。尽我所知，除了文中特别加以标注和致谢的地方外，论文中不包含其他人 已经发表或撰写过的研究成果，也不包含为获得云南大学或其他教育机构的学位 或证明而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均已在论 文中

2、作了明确的说明并表示了谢意。 研究生签名： 日 期： 论文使用和授权说明 本人完全了解云南大学有关保留、使用学位论文的规定，即：学校有权保留 并向国家有关部门或机构送交学位论文和论文电子版；允许论文被查阅或借阅； 学校可以公布论文的全部或部分内容，可以采用影印、缩印或其他复制手段保 存论文；授权学校将学位论文的全部或部分内容编入有关数据库进行检索。 （保密的论文在解密后应遵循此规定） 研究生签名： 导师签名： 日 期： 摘摘 要要 随着世界经济的全球化进程，电子商务的蓬勃发展以及网络应用的日益普及， 对于分布式应用和计算的要求越来越高。如何高效，安全，准确地进行分布式系 统间的通信已经成为了目

3、前网络应用和分布式计算所迫切需要解决的关键问题之 一。 消息中间件为应用系统之间提供了可靠，高效，跨平台的消息传递服务，有 利于应用之间的数据交换，是解决如上问题有效方案。虽然消息中间件实现的目 标和功能大同小异，但是在具体的实现上有很大的差异，不同的厂商基于各自的 开发标准和接口，因而不同系统之间兼容性不好，这样不利于降低企业的成本， 同时也加重了应用开发者和系统维护的负担。因此，作为消息中间件的一个规范 接口标准，JMS 规范已经被各大厂商所接受。 论文正是基于以上目的设计了一个遵从 JMS1.1 规范的基于 JMX 技术的消息 中间件。论文首先对中间件技术及其分类做了综述，介绍了与消息中

4、间件相关的 一些概念和模型。其次，对 Sun 公司提出的 JMS API 接口规范进行分析，解决了 JMS 实现的关键问题，并且将 JMX 技术引入到消息中间件的管理中，提出了 JMS 消息中间件的设计和实现的思路。论文给出了系统整体构架的分析和设计， 对其中的关键技术进行了深入分析，提出了相应的解决方案，并实现了系统的各 个主要功能模块。最后，论文指出了存在的问题和下一步的改进工作。 关键词 消息中间件; JMS 规范; JMX 分布式管理框架. ABSTRACT Along with the economy globalities and the progress of e-commerc

5、e application, these applications become the challenge of todays web and distributed systems. How to provide the efficacious, reliable and safe communication service of distributed systems is the key of these applications. Message oriented middleware(MOM) which is widely applied can provide reliable

6、 and efficacious message deliver service and avail data exchange among applications. Although the goal and function of most message oriented middleware is very common, the implements of MOM varies with the different MOM provider and each provider has its own development standard and interface. There

7、fore, the compatibility among providers is very weak, which will confine the choice of enterprise and increase the overload of developer. Obviously, it is very significative to pursuit a open and universal MOM service interface, JMS API specification, which is accepted by most companies, caters for

8、the demand. This thesis summerises the technology and category of middleware firstly, and introduce some general concept and message model on message oriented middleware. Then, JMS API specification of Sun Microsystem Incorpration is analyzed. In the rest part, the thesis takes JMX technology into t

9、he design of the JMS and discusses the design and implementation of JMS message oriented middleware and. This thesis discusses the system architecture and the design of imported parts. And some key technologies, such as thread pool and work queue, thread synchronization, is illustrated in detail. Fi

10、nally, the existing problem and future step are pointed out. KEYWORDS Message-oriented middleware(MOM); JMS API specification; Java Management Extensions(JMX). 目目 录录 摘 要.I ABSTRACT .II 目 录.III 第一章 引言.1 1.1 研究目的及问题概述 .1 1.2 研究范围及创新 .1 1.3 论文结构 .2 第二章 分布式应用的挑战.3 2.1 网络应用模式的发展 .3 2.2 分布式网络通讯面临的挑战 .4 第三

11、章 消息中间件和 JMS 规范概述.5 3.1 中间件的概述 .5 3.1.1 中间件的发展.5 3.1.2 中间件的作用和特点.6 3.1.3 主要中间件的分类.6 3.2 消息中间件的概述 .9 3.2.1 消息中间件的由来.9 3.2.2 消息中间件的定义.10 3.2.3 消息中间件的关键技术.10 3.2.4 SUN 对消息中间件的贡献 JMS.11 3.3 JMS 简介.11 3.3.1 JMS 概述.11 3.3.2 JMS 的目标.11 3.3.3 JMS 的体系结构.12 3.3.4 JMS 的基本概念.12 3.3.5 JMS 的 API.15 3.3.6 利用 JMS 进

12、行客户端开发的主要步骤.16 3.4 小结 .18 第四章 JMS 关键技术研究.19 4.1 消息队列的设计 .19 4.1.1 消息队列的工作方式.19 4.1.2 消息队列的实现原理.20 4.2 JMS 接口的封装和实现.24 4.2.1 JMS 接口的实现策略.24 4.2.2 为 Connection 对象建立对象池.25 4.3 XML 技术在 XMB 中的应用 .31 4.3.1 XML 技术概述.31 4.3.2 利用 XML 实现消息的持久化存储.32 4.3.3 利用 XML 实现 JMS 服务器的启动配置.35 4.4 JMX 技术在 XMB 中的应用.36 4.4.1

13、 JMX 技术概述.36 4.4.2 利用 JMX 实现 JMS 服务器的管理.38 4.5 小结 .41 第五章 XMB 的设计.42 5.1 设计思想和系统目标 .42 5.1.1 系统构思.42 5.1.2 系统所需的 java 技术 .42 5.2 系统的基本处理流程 .43 5.3 系统架构 .44 5.3.1 XMB 的体系结构.44 5.3.2 JMS 实现模块详解.45 5.4 接口实现部件的设计 .46 5.4.1 模块上下文环境.46 5.4.2 模块的内部交互.47 5.4.3 模块的内部结构.49 5.5 对象传输层的设计 .52 5.5.1 模块上下文环境.52 5.

14、5.2 模块的内部交互.53 5.5.3 模块的内部结构.55 5.6 系统中的 XML 处理部件的设计 .56 5.6.1 系统的启动配置.57 5.6.3 持久化 JMS 受管对象.59 5.7 管理框架的设计 .59 5.7.1 管理框架的上下文.59 5.7.2 管理框架的内部交互.60 5.7.3 管理框架的内部结构.62 5.8 小结 .65 第六章 总结与展望.66 6.1 总结 .66 6.2 进一步工作 .66 参考文献.68 致 谢.70 第一章第一章 引言引言 1.1 研究目的及问题概述 回顾互联网的发展轨迹，我们可以看到互联网的面貌正在迅速发生变化，互 联网所能传递、共

15、享的各种信息呈现出不同的形态，使得互联网能够提供越来越 丰富的应用。可以看到，从通信方式、娱乐方式到商业模式，互联网应用在多个 领域实现着对传统模式的颠覆。 随着互联网的发展，网络应用经历了从简单到复杂，从集中到分布的演变。 大型分布式应用程序的构建和维护却成了一个复杂的事情，尤其是不同应用程序 之间的通信问题。伴随着网络环境的日益复杂，网络中的通信问题也日趋严重。 主要表现在两个方面1：首先，在大型的分布式网络应用中，不同的应用运行在 不同的进程中，分布在不同的计算机上，甚至是跨系统，跨平台的，如何将这些 应用有效的集成，使不同的应用之间能保持良好的通信，使其发挥分布式应用的 真正的巨大优势

16、已经成为衡量一个分布式应用是否可靠，是否稳定的重要标准。 其次，大多数传统的通信技术要求发送和接收方必须遵循两个条件：1)双方通讯 是同步的；2)双方必须同时知道相互程序之间的调用接口。然而，在分布式环境 中，应用并不总是同时运行的；而且网络并不总是可用和可靠的；数据的流量具 有突发性，并可能造成网络的拥塞，这样一来分布式应用之间的异步通信问题就 变得非常突出了。 这些问题的提出对大型分布式应用程序提出了挑战，如何解决这些问题，使 分布式应用程序能高效，稳定和安全的运行，降低开发的成本并提高应用的投资 回报率，成为了开发人员急需解决的问题。 1.2 研究范围及创新 消息中间件无疑是解决分布式应

17、用程序之间通信的核心技术之一。消息中间 件可利用高效，可靠的消息传输机制进行平台无关的数据传输，并基于消息的通 信进行分布式系统的集成3。它适用于任何需要进行网络通信的系统，负责建立 网络通信的通道，进行数据或文件发送。消息中间件可以跨平台操作，为不同操 作系统上的应用软件集成提供方便，从而满足企业对系统伸缩性和可扩展性的要 求。 在此背景下，本论文设计了基于 JMX 框架的 JMS 服务器 (下文称为 JMX- oriented Message Bus Server，简称为 XMB 服务器)系统。XMB 是一个遵从 JMS1.1 规范的基于 JMX 管理框架的消息中间件实现。该中间件从逻辑上

18、分为两 大部分：一部分是客户端编程接口；另一部分则实现一个基于 JMS 规范的消息中 间件服务器6。 本论文首先对中间件技术及其分类做了综述，介绍了与消息中间件相关的一 些概念和模型，然后讨论了设计一个 JMS 实现的关键技术并给出了相应的解决方 案，最后论文从 XMB 系统的体系结构入手，分别设计了 XMB 系统中的各个关 键模块和重要部件。XMB 符合 JMS1.1 规范的相应要求，支持两种消息通讯模式， 支持消息的异步通讯，支持消息的持久化和消息消费者的持久化。同时，本论文 通过 JMX 技术的引入填补了 JMS 规范在服务器管理方面的空白。由于 JMX 技术 可以跨越一系列异构操作系统

19、平台、系统体系结构和网络传输协议，灵活的开发 无缝集成的系统、网络和服务管理应用15。系统通过 JMX 技术的引入大大简化 JMS 服务器的管理工作，并为整个 XMB 系统提供了极具伸缩性和可扩展性的体 系结构。 1.3 论文结构 本论文组织结构如下： 第一章介绍了本论文的研究目的，研究范围以及论文的创新点； 第二章简单介绍了网络应用模式的发展以及分布式应用面临的问题； 第三章介绍了消息中间件技术的发展和特点，并重点介绍了 JMS 技术规范以 及相关的概念和特点； 第四章讨论了设计一个 JMS 实现可能遇到的关键技术问题，并给出了相应的 一些解决方案； 第五章从 XMB 系统的架构入手，分别讨

20、论了该系统各个关键模块和主要部 件的设计； 第六章对论文进行了总结并对后续研究提出了展望。 第二章第二章 分布式应用的挑战分布式应用的挑战 2.12.1 网络应用模式的发展网络应用模式的发展 回顾互联网的发展轨迹，我们可以看到互联网的面貌正在迅速发生变化，互 联网所能传递、共享的各种信息呈现出不同的形态，使得互联网能够提供越来越 丰富的应用。可以看到，从通信方式、娱乐方式到商业模式，互联网应用在多个 领域实现着对传统模式的颠覆。例如在商业领域，互联网可以支持更加个性化、 定制化的服务，赋予了客户更多的自由度和选择空间。可以说，互联网应用的丰 富不仅体现在数量的增多，而且针对不同领域提供的服务的

21、满足度正在不断提高， 由此带动了互联网本身的社会和经济价值不断提升，并且对传统的社会和经济形 态形成了强有力的冲击。 但是不管互联网的内容和形式发生的多少变化，迄今为止，网络应用模式的 发展大致经历了四个阶段4： 1. 以大型机为中心的分时共享模式，它是采用大型机为中心，并配备了多个终 端所组成的一个系统。这种模式是利用主机的超强处理能力，主机是整个系 统的核心，但是一旦主机出现故障，那么整个系统就将瘫痪。 2. 以服务器为中心的资源共享模式，它通过网络将多台计算机连接，以实现资 源的共享。这种模式从分利用了各个站点的计算能力，应用开始出现了真正 意义上的位置的分布式。 3. Client/S

22、erver 计算模式是目前仍在大量使用中的计算模式。在基于 C/S 模式的 应用中，数据一般统一存放在数据服务器上，而有关的业务逻辑一般都在客 户端实现，这就是所谓的胖客户端解决方方案。但是随着 C/S 模式的发展， 许多应用开始体现出它的局限性：1)应用的层次一般比较混乱，不能或者难 以划分应用逻辑；2)应用的安全性比较差；3)应用的可扩展性比较差；4) 应 用的维护工作量比较大。 4. 为了改进 Client/Server 的计算模式，使之更能适应当今的网络和分布式应用的 需求，网络应用的计算模式正在向两个方向发展。首先中间件的出现为 C/S 模式带来了一次革新。在原来的两层结构中，现在可

23、以利用中间件实现多层 结构。而且中间件提供了从消息处理，网络通讯到数据处理等多方位的底层 服务功能，使得应用系统的开发从技术细节的实现中解放出来，能更多的投 入业务逻辑的处理当中。而业务逻辑也逐渐开始从客户端慢慢向服务器端转 移，这就是所谓的瘦客户端。但是客户端的维护问题仍然存在，为了完全解 决这个问题，Brower/Server 计算模式从而应运而生。但是 B/S 计算模式同样 存在自己的一些局限性：1)单一的基于 HTTP 的通讯，效率不高；2)客户端 的表现能力不强；3)同样存在浏览器的类型和版本问题。 在目前的网络应用中，主要以 B/S 结构和多层 C/S 结构的应用为主，而大量 的中

24、间件产品正在为这些应用提供引擎动力。中间件技术涉及到了网络应用中的 各个方面，提供了最核心的底层技术支持，已经发展成为网络应用中不可替代的 关键技术。 2.22.2 分布式网络通讯面临的挑战分布式网络通讯面临的挑战 网络应用经历了从简单到复杂，从集中到分布的演变。大型分布式应用程序 的构建和维护却是一个十分复杂的事情，尤其是不同应用程序之间的通信。伴随 着网络环境的日益复杂，网络中的通信问题也日趋严重。主要表现在两个方面1： 1. 在大型的分布式网络应用中，不同的应用运行在不同的进程中，分布在不同 的计算机上，甚至是跨系统，跨平台的，如何将这些应用有效的集成，使不 同的应用之间能保持良好的通信

25、，使其发挥分布式应用的真正的巨大优势。 这已经成为衡量一个分布式应用是否可靠，是否稳定的重要标准。 2. 大多数传统的通信技术要求发送和接收方必须遵循两个条件：1)双方必须同 时在线，即通讯是同步的；2)双方必须同时知道相互程序之间的调用接口。 这样就要求一旦一个应用程序有任何接口的变化，就必须通知其他的应用程 序。同时为了保持数据的完整性，发送和接收在实际的实现中可能必须使用 分布式事务，以确保一方应用的数据改变能被双方承认。然而，在分布式环 境中，应用并不总是同时运行的；而且网络并不总是可用和可靠的；数据的 流量具有突发性，并可能造成网络的拥塞，这样一来分布式应用之间的异步 通信问题就变得

26、非常突出了。 这些问题的提出对大型分布式应用程序提出了挑战，如何解决这些问题，使 分布式应用程序能高效，稳定和安全的运行，降低开发的成本并提高应用的投资 回报率，成为了开发人员急需解决的问题。 第三章第三章 消息中间件和消息中间件和 JMSJMS 规范概述规范概述 3.1 中间件中间件的概述的概述 3.1.1 中间件的中间件的发展发展 随着计算机技术的迅速发展。从硬件技术看，CPU 速度越来越高，处理能 力越来越强；从软件技术看，应用程序的规模不断扩大，特别是 Internet 及 WWW 的出现，使计算机的应用范围更为广阔，许多应用程序需在网络环境的异 构平台上运行。这一切都对新一代的软件开

27、发提出了新的需求。在这种分布异构 环境中，通常存在多种硬件系统平台(如 PC，工作站，小型机等)，在这些硬件 平台上又存在各种各样的系统软件(如不同的操作系统、数据库、语言编译器等)， 以及多种风格各异的用户界面，这些硬件系统平台还可能采用不同的网络协议和 网络体系结构连接。如何把这些系统集成起来并开发新的应用是一个非常现实而 困难的问题。中间件概念的出现就是为解决这些分布异构问题的。 中间件(Middleware)是位于平台(硬件和操作系统)和应用之间的通用服务，这 些服务具有标准的程序接口和协议。针对不同的操作系统和硬件平台，它们可以 有符合接口和协议规范的多种实现2。 中间件是一种独立的

28、系统软件或服务程序，分布式应用系统借助这种软件在 不同的技术之间共享资源，管理计算资源和网络通讯。它在计算机系统中是一个 关键软件，它能实现应用的互连和互操作性，能保证系统的安全、可靠、高效的 运行。中间件位于用户应用和操作系统及网络软件之间(如图 3-1 所示)，它为应 用提供了公用的通信手段，并且独立于网络和操作系统。中间件为开发者提供了 公用于所有环境的应用程序接口，当应用程序中嵌入其函数调用，它便可利用其 运行的特定操作系统和网络环境的功能，为应用执行通信功能5。 应用应用应用应用 中间件中间件 (提供分布式系统服务提供分布式系统服务) 操作系统操作系统 硬件硬件 操作系统操作系统 硬

29、件硬件 网络网络 图 3-1 中间件的位置 3.1.2 中间件的作用和特点中间件的作用和特点 中间件满足了大量应用的需要，运行于多种硬件和 OS 平台上，它支持分布 计算，提供跨网络、跨硬件和 OS 平台的透明的应用或服务的交互，支持标准的 协议，支持标准的接口。 由于标准接口对于可移植性和标准协议对于互操作性的重要性，中间件已成 为许多标准化工作的主要部分。对于应用软件开发，中间件远比操作系统和网络 服务更为重要，中间件提供的程序接口定义了一个相对稳定的高层应用环境，不 管底层的计算机硬件和系统软件怎样更新换代，只要将中间件升级更新，并保持 中间件对外的接口定义不变，应用软件几乎不需任何修改

30、，从而保护了企业在应 用软件开发和维护中的重大投资。 3.1.3 主要中间件的分类主要中间件的分类 目前，中间件所包括的范围十分广泛，针对不同的应用需求涌现出多种各具 特色的中间件产品。但至今中间件还没有一个比较精确的定义，因此，在不同的 角度或不同的层次上，对中间件的分类也会有所不同。按照 IDC 的分类方法，中 间件大致可分为六类4。 （一）终端仿真/屏幕转换 用以实现客户机图形用户接口与已有的字符接口方式的的服务器应用程序之 间的互操作。 （二）数据访问中间件 适用于应用程序与数据源之间的互操作模型，客户端使用面向数据库的 API，以提请直接访问和更新基于服务器的数据源，数据源可以是关系

31、型、非关 系型和对象型。这类中间件大都基于 SQL 语句，采用同步通讯方式。此类中间件 使应用开发简单，但如果是透过广域网使用，会带来严重的效率问题，因为在低 速网上来回交互 SQL 语句会使通讯流量过大，同时对数据压缩、加密带来不便。 （三）远程过程调用中间件 RPC 机制是早期开发分布式应用时经常采用的一种同步式的请求应答协议。 通过这种协议，程序员编写客户方的应用，需要时可以调用位于远端服务器上的 过程。 当编译一个采用 RPC 机制的客户方应用时，编译器告之代表远程功能调用的 句柄，客户方需要调用远地的过程时，引用相应的功能调用的句柄，由 RPC 机制 来负责客户端程序实时地调用到远地

32、的过程。服务器上的过程返回后，客户方的 程序得到结果并继续往下进行。在采用 RPC 机制时，调用远端的过程只需去引 用它，而不必告之网络地址或其它底层信息。 RPC 机制可用以构造客户机/服务器方式的应用，但由于它是同步方式，因 而在工作的时候，要求客户方和服务方均能正常工作才能很好地运行，有一方不 能工作将导致 RPC 失败。这在网络故障、机器故障存在的情况下，这一要求是很 难保证的。还有一点值得注意的是，不管客户方能做什么或做的多快，它必须依 靠服务方才能有效工作。有些恢复机制可以在一个远程调用阻塞时转而去调用另 一个服务器上的过程，但这种路由方式也会影响效率。 目前，也有的 RPC 机制

33、采用异步方式，客户方非阻塞地调用远端的过程，但 这种方式不太标准而且很难采用。另外，由于大多数 RPC 机制很难建立点到点的 关系，因而也很难用在面向对象的编程当中。 （四）消息中间件 尽管消息中间件不象 RPC 机制那样流行，但越来越多的分布式应用采用消息 中间件来构建，通过消息中间件来把应用扩展到不同的操作系统和不同的网络环 境。 基于消息的机制更多地适用于事件驱动的应用，当一个事件发生时，消息中 间件通知服务方应该进行何种操作。事件可以是一个请求，也可以只是一种警示， 警示到来后，即可进行某种处理，但不需等待应答。 使用消息中间件编程采用的是消息中间件的 API，可以很好地扩展到不同的

34、操作系统和硬件平台上。消息中间件的核心安装在需要进行消息传递的系统上， 在它们之间建立逻辑通道，由消息中间件实现消息发送。消息中间件可以既支持 同步方式，又支持异步方式，实际上它是一种点到点的机制，因而可以很好地适 用于面向对象的编程方式。 中间件领域目前最热门的技术是异步的消息中间件，异步中间件技术比同步 中间件技术具有更强的容错性，在系统故障时可以保证消息的正常传输，因而在 过去的两年里增长迅速。异步中间件技术可以分为两类：广播方式和发布/订阅 方式。广播方式把消息分发给系统的所有用户。发行/订阅方式可以指定哪种类 型的用户可以接收哪种类型的消息。发布/订阅方式由于更加智能有效，事实上 已

35、成为异步中间件的非正式标准。 （五）交易中间件 交易中间件是专门针对联机交易处理系统而设计的。联机交易处理系统需要 处理大量并发进程，处理并发涉及到操作系统、文件系统、编程语言、数据通讯、 数据库系统、系统管理、应用软件，是一个相当艰巨的任务，但是工作的难度可 以通过采用一个交易中间件来简化。交易中间件就是一组程序模块，用以大大减 少开发一个联机交易处理系统所需的编程量。X/OPEN 组织专门定义了分布式交 易处理的标准及参考模型，把一个联机交易系统划分成资源管理（RM） 、交易管 理（TM）和应用（AP）三部分，定义了应用程序、交易管理器、多个资源管理 器是如何协同工作的。资源管理器是指数据

36、库和文件系统，交易管理器可归入交 易中间件。交易中间件管理由应用声明和提交的交易，并通过两阶段提交协议等 方式保证分布式交易的完整性、控制并发、实现交易路由和均衡负载。 交易中间件理论上相对成熟，功能和性能界定清晰，但基本上适用于联机交 易系统，如银行业务系统、定票系统等。尽管交易信息也是消息，交易中间件也 是基于消息的传输，也可支持同步和异步方式，但与消息中间件的定位差距较大， 属于一种较专用的中间件。 （六）对象中间件 面向对象的技术一直是软件界努力追求的目标，传统的对象技术通过封装、 继承及多态提供了良好的代码重用功能。但是这些对象只存在一个程序中，外面 的世界并不知道它们的存在，也无法

37、访问它们。面向对象的中间件就是要解决这 些问题，它提供一个标准的构件框架，能使不同的厂家的软件通过不同的地址空 间、网络和操作系统互相交互访问。该构件的具体实现、位置及所依附的操作系 统对客户来说都是透明的。例如，我们可以通过简单的组装或扩展已有的构件就 可以建立一个客户机/服务器结构的信息系统。面向对象的中间件技术的目标就 是为软件用户及开发者提供一种应用级的即插即用的互操作性，就象现在使用集 成块和扩展板一样。 有关对象中间件的标准相继问世，像 OMG 组织的 CORBA、Microsoft 的 COM 以及 IBM 公司的 SOM 等，这些标准都极大地促进了对象中间件技术的发 展，随着面

38、向对象的应用系统的逐渐增长，对象中间件的需求也在逐年加大。对 象技术的优势和对象中间件的标准化，促使对象中间件的功能将最终涵盖其它几 类中间件的功能而成为中间件产品的主流。 不论各种中间件他们的目的和功能有多少不同，但是它们都可以向上提供不 同形式的通讯服务，包括同步、排队、订阅发布、广播等等，在这些基本的通讯 平台之上，可构筑各种框架，为应用程序提供不同领域内的服务，如事务处理监 控器、分布数据访问、对象事务管理器 OTM 等。平台为上层应用屏蔽了异构平 台的差异，而其上的框架又定义了相应领域内的应用的系统结构、标准的服务组 件等，用户只需告诉框架所关心的事件，然后提供处理这些事件的代码。当

39、事件 发生时，框架则会调用用户的代码。用户代码不用调用框架，用户程序也不必关 心框架结构、执行流程、对系统级 API 的调用等，所有这些由框架负责完成。因 此，基于中间件开发的应用具有良好的可扩充性、易管理性、高可用性和可移植 性。 3.23.2 消息中间件消息中间件的概述的概述 3.2.1 消息中间件的由来消息中间件的由来 在分布式应用中，CORBA、DCOM、RMI 等 RPC 中间件技术已广泛应用于 各个领域。但是面对规模和复杂度都越来越高的分布式系统，这些技术也显示出 其局限性：13（1）同步通信：客户发出调用后，必须等待服务对象完成处理并 返回结果后才能继续执行；（2）客户和服务对象

40、的生命周期紧密耦合：客户进 程和服务对象进程都必须正常运行；如果由于服务对象崩溃或者网络故障导致客 户的请求不可达，客户会接收到异常；（3）点对点通信：客户的一次调用只发 送给某个单独的目标对象。 面向消息的中间件（Message Oriented Middleware，MOM）较好的解决了以 上问题。发送者将消息发送给消息服务器，消息服务器将消息存放在若干队列中， 在合适的时候再将消息转发给接收者。这种模式下，发送和接收是异步的，发送 者无需等待；二者的生命周期未必相同：发送消息的时候接收者不一定运行，接 收消息的时候发送者也不一定运行；一对多通信：对于一个消息可以有多个接收 者。 3.2.

41、2 消息中间件的定义消息中间件的定义 消息传输中间件(Message Oriented Middleware，MOM)是中间件中的一种。消 息中间件也称为消息代理中间件或通信中间件，它是依据消息传输或消息队列的 原理来工作的。它能够简化应用之间数据的传输，提供可靠的，跨平台的消息传 输手段3。 消息中间件支持同步和异步两种通信模式，其中异步通信模式是基于消息队 列转发机制的。消息队列一般提供多协议支持和其他系统管理服务，完成可靠的， 可扩展的异构环境中的通信12。一般来说，消息队列采用分布式计算模型来实现 同步和异步交互。消息中间简化了应用之间数据的传输，屏蔽底层异构操作系统 和网络平台，提供

42、一致的通讯标准和应用开发，确保分布式计算网络环境下可靠 的、跨平台的信息传输和数据交换。它基于消息队列的存储-转发机制，并提供 特有的异步传输机制，能够基于消息传输和异步事务处理实现应用整合与数据交 换。 如果没有消息中间件完成信息交换，应用开发者为了传输数据，必须要学会 如何用网络和操作系统软件的功能，编写相应的应用程序来发送和接收信息，且 交换信息没有标准方法，每个应用必须进行特定的编程从而和多平台、不同环境 下的一个或多个应用通信12。例如，为了实现网络上不同主机系统间的通信，将 要求具备在网络上如何交换信息的知识（比如用 TCP/IP 的 socket 程序设计）； 为了实现同一主机内

43、不同进程之间的通讯，将要求具备操作系统的消息队列或命 名管道(Pipes)等知识。由此可见，消息中间件在提供相应的底层通信功能的同时， 也大大减轻了开发人员的开发过程。 3.2.3 消息中间件的关键技术消息中间件的关键技术 消息队列技术是消息中间件中的关键技术。消息队列是分布式应用间交换信 息的一种技术。消息队列可驻留在内存或磁盘上,队列存储消息直到它们被应用 程序读走。通过消息队列，应用程序可独立地执行-它们不需要知道彼此的位置、 或在继续执行前不需要等待接收程序接收此消息。 在分布式计算环境中，为了集成分布式应用，开发者需要对异构网络环境下 的分布式应用提供有效的通信手段。为了管理需要共享

44、的信息，对应用提供公共 的信息交换机制是重要的。 消息队列为构造以同步或异步方式实现的分布式应用提供了松耦合方法。消 息队列的 API 调用被嵌入到新的或现存的应用中，通过消息发送到内存或基于磁 盘的队列或从它读出而提供信息交换。消息队列可用在应用中以执行多种功能， 比如要求服务、交换信息或异步处理等。 3.2.4 SUN 对消息中间件的贡献对消息中间件的贡献 JMS 在 JMS 规范还没有推出以前，就已经存在了一些消息中间件产品。其中比较 重要的 MOM 系统包括 IBM 的 MQ Series、Microsoft 的 MSMQ 和 BEA 的 MessageQ 等。由于没有一个通用的标准，

45、这些系统很难实现互操作和无缝连接。 Java Message Service（JMS）是 SUN 提出的旨在统一各种 MOM 系统接口的规范， 它包含点对点（Point to Point，PTP）和发布/订阅（Publish/Subscribe，pub/sub） 两种消息模型，提供可靠消息传输、事务和消息过滤等机制16。Java 消息服务 （Java Message Service，JMS）提供了一致的 API 集合，让开发人员可以访问许 多消息通信中间件产品的公共特性。 3.3 JMS 简介简介 3.3.1 JMS 概述概述 Java 消息服务(Java Message Service，JM

46、S)是 J2EE (Java 2 Enterprise Edition) 套件的一部分，它提供了标准 API，Java 开发人员可以使用这些 API 来访问企 业消息系统的共同特性16。Java 消息服务定义了 Java 中访问消息中间件的接口。 JMS 只是接口，并没有给予实现，实现 JMS 接口的消息中间件称为 JMS 实现 (JMS Provider)。JMS 支持发布/订阅和点对点模型，并允许创建由任意 Java 对 象组成的消息类型。 3.3.2 JMS 的目标的目标 JMS 的基本设计目标是为了提供一组一致的接口，消息传递系统客户端可以 独立地使用这些接口，而不必关心基础消息系统的

47、提供商。这样，客户端应用程 序不仅可以跨计算机体系结构和操作系统进行移植，而且也可以跨消息传输产品 进行平台无关的移植。使用 JMS 的客户端应用程序将正常工作，而不用在所有符 合 JMS 的消息传递系统上做修改。同时，JMS 也被设计成最小化的消息传递系统， JMS 提供商为其产品实现 JMS API 所规定的工作；提供了普通消息传递系统的大 多数功能。因此，许多消息系统提供商已经将它们的产品适配成为 JMS 系统， 允许 Java 访问它们系统所提供的功能。 3.3.3 JMS 的体系结构的体系结构 一个完整的 JMS 应用程序是由以下部分组成的6： JMS 实现(JMS provider

48、)，它是一个实现了 JMS 接口并提供管理和控制能 力的消息通信系统。 JMS 客户端是使用 Java 编程语言编写的创建和消费消息的程序或组件。 消息是在 JMS 客户之间用于交流信息的对象。 受管对象(Administered object)是由管理员为客户使用而创建的预先设置 JMS 对象(preconfigured JMS object)。主要有两个受管对象：目的域 (destination)和连接工厂(connection factory)。 如图 3-2 展示了上述对象的交互情况。管理员利用管理工具绑定目的域和连 接工厂到 JNDI(Java Naming and Director

49、y Interface)命名空间。然后，JMS 客户就 能够查找该命名空间内的受管对象，而后通过 JMS 实现建立一个到这些对象的逻 辑连接。 图 3-2 JMS API 的体系结构 3.3.4 JMS 的基本概念的基本概念 消息通信模式消息通信模式 JMS 规范定义了两种消息通信模式：点对点(Point-to-Point，PTP)通信模式和 发布者/订阅者(Pub/Sub)通信模式。 图 3-3 JMS 点对点通信模式 如图 3-3 所示，PTP(Point-to-Point)模型是基于队列的，发送方发消息到队列 (Queue)，接收方从队列接收消息，队列的存在使得消息的异步

50、传输成为可能。和 邮件系统中的邮箱一样，队列可以包含各种消息，JMS Provider 提供工具管理队 列的创建、删除。JMS PTP 模型定义了客户端如何向队列发送消息，从队列接收 消息，浏览队列中的消息。 如图 3-4 所示，JMS Pub/Sub 模型定义了如何向一个内容节点发布和订阅消 息，这些节点被称作主题(topic)。主题可以被认为是消息的传输中介，发布者 (publisher)发布消息到主题，订阅者(subscribe) 从主题订阅消息。主题使得消息订 阅者和消息发布者保持互相独立，不需要接触即可保证消息的传送。 图 3-4 JMS Pub/Sub 通信模式 J

51、MS 消息模型消息模型 在 JMS 中，消息通常是由以下几部分组成：消息头，属性，消息体。 消息头(Header) 消息头包含消息的识别信息和路由信息，消息头包含一 些标准的属性如：JMSDestination, JMSMessageID 等。具体的消息头如表 3-1。 表 3-1 JMS 消息头 消息头由谁来设置 JMSDestinationsend 或 publish 方法 JMSDeliveryModesend 或 publish 方法 JMSExpirationsend 或 publish 方法 JMSPrioritysend 或 publish 方法 JMSMessageIDsend

52、 或 publish 方法 JMSTimestampsend 或 publish 方法 JMSCorrelationID客户 JMSReplyTo客户 JMSType客户 JMSRedeliveredJMS Provider 属性(Properties) 除了消息头中定义好的标准属性外，JMS 提供一种机 制增加新属性到消息头中，这种新属性包含以下几种： 1. 应用需要用到的属性; 2. 消息头中原有的一些可选属性; 3. JMS Provider 需要用到的属性。 标准的 JMS 消息头包含以下属性, 如表 3-2 所示。 表 3-2 JMS 消息属性 JMSDestination消息发送的

53、目的地 JMSDeliveryMode 传递模式， 有两种模式： PERSISTENT 和 NON_PERSISTENT，PERSISTENT 表示该消息一定要 被送到目的地，否则会导致应用错误。 NON_PERSISTENT 表示偶然丢失该消息是被允许的， 这两种模式使开发者可以在消息传递的可靠性和吞吐量 之间找到平衡点。 JMSMessageID唯一识别每个消息的标识，由 JMS Provider 产生。 JMSTimestamp一个消息被提交给 JMS Provider 到消息被发出的时间。 JMSCorrelationID 用来连接到另外一个消息，典型的应用是在回复消息中 连接到原消息

54、。 JMSReplyTo提供本消息回复消息的目的地址 JMSRedelivered 如果一个客户端收到一个设置了 JMSRedelivered 属性 的消息，则表示可能该客户端曾经在早些时候收到过该 消息，但并没有签收(acknowledged)。 JMSType消息类型的识别符。 JMSExpiration 消息过期时间，等于 QueueSender 的 send 方法中的 timeToLive 值或 TopicPublisher 的 publish 方法中的 timeToLive 值加上发送时刻的 GMT 时间值。如果 timeToLive 值等于零，则 JMSExpiration 被设为

55、零，表 示该消息永不过期。如果发送后，在消息过期时间之后 消息还没有被发送到目的地，则该消息被清除。 JMSPriority 消息优先级，从 0-9 十个级别，0-4 是普通消息，5-9 是加急消息。JMS 不要求 JMS Provider 严格按照这十 个优先级发送消息，但必须保证加急消息要先于普通消 息到达。 消息体(Body) JMS API 定义了 5 种消息体格式，也叫消息类型，你可以 使用不同形式发送接收数据并可以兼容现有的消息格式，下面表 3-3 描述这 5 种 类型： 表 3-3 JMS 消息类型 消息类型消息体 TextMessagejava.lang.String 对象，如

56、 xml 文件内容 MapMessage 名/值对的集合，名是 String 对象，值类型可以是 Java 任何基本类型 BytesMessage字节流 StreamMessageJava 中的输入输出流 ObjectMessageJava 中的可序列化对象 3.3.5 JMS 的的 API JMS 支持两种消息类型 PTP 和 Pub/Sub，分别称作：PTP Domain 和 Pub/Sub Domain，这两种接口都继承统一的 JMS 父接口，JMS 主要接口如表 3-4 所示。 其中，ConnectionFactory ：连接工厂，JMS 用它创建连接； Connection ：JMS

57、 客户端到 JMS Provider 的连接； Destination ：消息的目的地； Session： 一个发送或接收消息的会话； MessageProducer： 由 Session 对象创建的用来发送消息的对象； MessageConsumer： 由 Session 对象创建的用来接收消息的对象。 表 3-4 JMS 主要接口 JMS 父接口PTPPub/Sub ConnectionFactoryQueueConnectionFactoryTopicConnectionFactory ConnectionQueueConnectionTopicConnection Destinatio

58、nQueueTopic SessionQueueSessionTopicSession MessageProducerQueueSenderTopicPublisher MessageConsumer QueueReceiver,QueueBrowse r TopicSubscriber 3.3.6 利用利用 JMS 进行客户端开发的主要步骤进行客户端开发的主要步骤 下面我们以如何建立一个异步消息客户端来说明怎么利用 JMS 来创建消息应 用的客户端的基本步骤。 创建连接创建连接 连接为客户端提供了对基础消息传递系统的访问，并执行资源分配和管理。 连接是使用 Connectio

59、nFactory 创建的，而 ConnectionFactory 通常是使用 JNDI 查找得到的。 下面这些代码展示了创建连接过程中涉及的一些步骤： Context messaging = new InitialContext(); / 获得 JNDI 上下文 /创建连接工厂 TopicConnectionFactory topicConnectionFactory = (TopicConnectionFactory)messaging.lookup(TopicConnectionFactory); /由连接工厂创建连接 TopicConnection topicConnection = t

60、opicConnectionFactory.createTopicConnection(); 创建会话创建会话 会话是轻量级 JMS 对象，它提供了用于生产和消费消息的上下文。会话用 于生成消息生产者和消息消费者，以及用于生成消息本身。 TopicSession session = topicConnection.createTopicSession(false, Session.CLIENT_ACKNOWLEDGE); 其中，createTopicSession() 的两个参数分别控制事务和消息的确认。 查找主题查找主题 主题（也称标题、组或频道）是通过 JN