JAVA基于JMX框架的JMS服务器的设计和实现(硕士论文).doc

分类号 TP31 密级 公开 UDC 编号 硕士研究生学位论文题 目 基于JMX框架的JMS服务器 的设计和实现学院（所、中心） 软件学院 专业名称 软件工程 研究生姓名 陈冬 学号 1200400668导师姓名 周华 职称 研究员 2007年 4月声 明本人声明所呈交的论文是我个人在导师指导下进行的研究工作及取得的研究成果。尽我所知，除了文中特别加以标注和致谢的地方外，论文中不包含其他人已经发表或撰写过的研究成果，也不包含为获得云南大学或其他教育机构的学位或证明而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均已在论文中作了明确的说明并表示了谢意。研究生签名： 日 期： 论文使用和授权说明本人完全了解云南大学有关保留、使用学位论文的规定，即：学校有权保留并向国家有关部门或机构送交学位论文和论文电子版；允许论文被查阅或借阅；学校可以公布论文的全部或部分内容，可以采用影印、缩印或其他复制手段保存论文；授权学校将学位论文的全部或部分内容编入有关数据库进行检索。 （保密的论文在解密后应遵循此规定）研究生签名： 导师签名： 日 期： 摘 要随着世界经济的全球化进程，电子商务的蓬勃发展以及网络应用的日益普及，对于分布式应用和计算的要求越来越高。如何高效，安全，准确地进行分布式系统间的通信已经成为了目前网络应用和分布式计算所迫切需要解决的关键问题之一。消息中间件为应用系统之间提供了可靠，高效，跨平台的消息传递服务，有利于应用之间的数据交换，是解决如上问题有效方案。虽然消息中间件实现的目标和功能大同小异，但是在具体的实现上有很大的差异，不同的厂商基于各自的开发标准和接口，因而不同系统之间兼容性不好，这样不利于降低企业的成本，同时也加重了应用开发者和系统维护的负担。因此，作为消息中间件的一个规范接口标准，JMS规范已经被各大厂商所接受。论文正是基于以上目的设计了一个遵从JMS1.1规范的基于JMX技术的消息中间件。论文首先对中间件技术及其分类做了综述，介绍了与消息中间件相关的一些概念和模型。其次，对Sun公司提出的JMS API接口规范进行分析，解决了JMS实现的关键问题，并且将JMX技术引入到消息中间件的管理中，提出了JMS消息中间件的设计和实现的思路。论文给出了系统整体构架的分析和设计，对其中的关键技术进行了深入分析，提出了相应的解决方案，并实现了系统的各个主要功能模块。最后，论文指出了存在的问题和下一步的改进工作。关键词 消息中间件; JMS规范; JMX分布式管理框架.ABSTRACTAlong with the economy globalities and the progress of e-commerce 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 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. Therefore, 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 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 the 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. Finally, the existing problem and future step are pointed out. KEYWORDS Message-oriented middleware(MOM); JMS API specification; Java Management Extensions(JMX).目 录摘 要IABSTRACTII目 录III第一章 引言11.1 研究目的及问题概述11.2 研究范围及创新11.3 论文结构2第二章 分布式应用的挑战32.1 网络应用模式的发展32.2 分布式网络通讯面临的挑战4第三章 消息中间件和JMS规范概述53.1 中间件的概述53.1.1 中间件的发展53.1.2 中间件的作用和特点63.1.3 主要中间件的分类63.2 消息中间件的概述93.2.1 消息中间件的由来93.2.2 消息中间件的定义103.2.3 消息中间件的关键技术103.2.4 SUN对消息中间件的贡献 JMS113.3 JMS简介113.3.1 JMS概述113.3.2 JMS的目标113.3.3 JMS的体系结构123.3.4 JMS的基本概念123.3.5 JMS的API153.3.6 利用JMS进行客户端开发的主要步骤163.4 小结18第四章 JMS关键技术研究194.1 消息队列的设计194.1.1 消息队列的工作方式194.1.2 消息队列的实现原理204.2 JMS接口的封装和实现244.2.1 JMS接口的实现策略244.2.2 为Connection对象建立对象池254.3 XML技术在XMB中的应用314.3.1 XML技术概述314.3.2 利用XML实现消息的持久化存储324.3.3 利用XML实现JMS服务器的启动配置354.4 JMX技术在XMB中的应用364.4.1 JMX技术概述364.4.2 利用JMX实现JMS服务器的管理384.5 小结41第五章 XMB的设计425.1 设计思想和系统目标425.1.1 系统构思425.1.2 系统所需的java技术425.2 系统的基本处理流程435.3 系统架构445.3.1 XMB的体系结构445.3.2 JMS 实现模块详解455.4 接口实现部件的设计465.4.1 模块上下文环境465.4.2 模块的内部交互475.4.3 模块的内部结构495.5 对象传输层的设计525.5.1 模块上下文环境525.5.2 模块的内部交互535.5.3 模块的内部结构555.6 系统中的XML处理部件的设计565.6.1 系统的启动配置575.6.3 持久化JMS受管对象595.7 管理框架的设计595.7.1 管理框架的上下文595.7.2 管理框架的内部交互605.7.3 管理框架的内部结构625.8 小结65第六章 总结与展望666.1 总结666.2 进一步工作66参考文献68致 谢70第一章 引言1.1 研究目的及问题概述回顾互联网的发展轨迹，我们可以看到互联网的面貌正在迅速发生变化，互联网所能传递、共享的各种信息呈现出不同的形态，使得互联网能够提供越来越丰富的应用。可以看到，从通信方式、娱乐方式到商业模式，互联网应用在多个领域实现着对传统模式的颠覆。随着互联网的发展，网络应用经历了从简单到复杂，从集中到分布的演变。大型分布式应用程序的构建和维护却成了一个复杂的事情，尤其是不同应用程序之间的通信问题。伴随着网络环境的日益复杂，网络中的通信问题也日趋严重。主要表现在两个方面1：首先，在大型的分布式网络应用中，不同的应用运行在不同的进程中，分布在不同的计算机上，甚至是跨系统，跨平台的，如何将这些应用有效的集成，使不同的应用之间能保持良好的通信，使其发挥分布式应用的真正的巨大优势已经成为衡量一个分布式应用是否可靠，是否稳定的重要标准。其次，大多数传统的通信技术要求发送和接收方必须遵循两个条件：1)双方通讯是同步的；2)双方必须同时知道相互程序之间的调用接口。然而，在分布式环境中，应用并不总是同时运行的；而且网络并不总是可用和可靠的；数据的流量具有突发性，并可能造成网络的拥塞，这样一来分布式应用之间的异步通信问题就变得非常突出了。这些问题的提出对大型分布式应用程序提出了挑战，如何解决这些问题，使分布式应用程序能高效，稳定和安全的运行，降低开发的成本并提高应用的投资回报率，成为了开发人员急需解决的问题。1.2 研究范围及创新消息中间件无疑是解决分布式应用程序之间通信的核心技术之一。消息中间件可利用高效，可靠的消息传输机制进行平台无关的数据传输，并基于消息的通信进行分布式系统的集成3。它适用于任何需要进行网络通信的系统，负责建立网络通信的通道，进行数据或文件发送。消息中间件可以跨平台操作，为不同操作系统上的应用软件集成提供方便，从而满足企业对系统伸缩性和可扩展性的要求。在此背景下，本论文设计了基于JMX框架的JMS服务器 (下文称为JMX-oriented Message Bus Server，简称为XMB服务器)系统。XMB是一个遵从JMS1.1规范的基于JMX管理框架的消息中间件实现。该中间件从逻辑上分为两大部分：一部分是客户端编程接口；另一部分则实现一个基于JMS规范的消息中间件服务器6。本论文首先对中间件技术及其分类做了综述，介绍了与消息中间件相关的一些概念和模型，然后讨论了设计一个JMS实现的关键技术并给出了相应的解决方案，最后论文从XMB系统的体系结构入手，分别设计了XMB系统中的各个关键模块和重要部件。XMB符合JMS1.1规范的相应要求，支持两种消息通讯模式，支持消息的异步通讯，支持消息的持久化和消息消费者的持久化。同时，本论文通过JMX技术的引入填补了JMS规范在服务器管理方面的空白。由于JMX技术可以跨越一系列异构操作系统平台、系统体系结构和网络传输协议，灵活的开发无缝集成的系统、网络和服务管理应用15。系统通过JMX技术的引入大大简化JMS服务器的管理工作，并为整个XMB系统提供了极具伸缩性和可扩展性的体系结构。1.3 论文结构本论文组织结构如下：第一章介绍了本论文的研究目的，研究范围以及论文的创新点；第二章简单介绍了网络应用模式的发展以及分布式应用面临的问题；第三章介绍了消息中间件技术的发展和特点，并重点介绍了JMS技术规范以及相关的概念和特点；第四章讨论了设计一个JMS实现可能遇到的关键技术问题，并给出了相应的一些解决方案；第五章从XMB系统的架构入手，分别讨论了该系统各个关键模块和主要部件的设计；第六章对论文进行了总结并对后续研究提出了展望。第二章 分布式应用的挑战2.1 网络应用模式的发展回顾互联网的发展轨迹，我们可以看到互联网的面貌正在迅速发生变化，互联网所能传递、共享的各种信息呈现出不同的形态，使得互联网能够提供越来越丰富的应用。可以看到，从通信方式、娱乐方式到商业模式，互联网应用在多个领域实现着对传统模式的颠覆。例如在商业领域，互联网可以支持更加个性化、定制化的服务，赋予了客户更多的自由度和选择空间。可以说，互联网应用的丰富不仅体现在数量的增多，而且针对不同领域提供的服务的满足度正在不断提高，由此带动了互联网本身的社会和经济价值不断提升，并且对传统的社会和经济形态形成了强有力的冲击。但是不管互联网的内容和形式发生的多少变化，迄今为止，网络应用模式的发展大致经历了四个阶段4：1. 以大型机为中心的分时共享模式，它是采用大型机为中心，并配备了多个终端所组成的一个系统。这种模式是利用主机的超强处理能力，主机是整个系统的核心，但是一旦主机出现故障，那么整个系统就将瘫痪。2. 以服务器为中心的资源共享模式，它通过网络将多台计算机连接，以实现资源的共享。这种模式从分利用了各个站点的计算能力，应用开始出现了真正意义上的位置的分布式。3. Client/Server计算模式是目前仍在大量使用中的计算模式。在基于C/S模式的应用中，数据一般统一存放在数据服务器上，而有关的业务逻辑一般都在客户端实现，这就是所谓的胖客户端解决方方案。但是随着C/S模式的发展，许多应用开始体现出它的局限性：1)应用的层次一般比较混乱，不能或者难以划分应用逻辑；2)应用的安全性比较差；3)应用的可扩展性比较差；4) 应用的维护工作量比较大。4. 为了改进Client/Server的计算模式，使之更能适应当今的网络和分布式应用的需求，网络应用的计算模式正在向两个方向发展。首先中间件的出现为C/S模式带来了一次革新。在原来的两层结构中，现在可以利用中间件实现多层结构。而且中间件提供了从消息处理，网络通讯到数据处理等多方位的底层服务功能，使得应用系统的开发从技术细节的实现中解放出来，能更多的投入业务逻辑的处理当中。而业务逻辑也逐渐开始从客户端慢慢向服务器端转移，这就是所谓的瘦客户端。但是客户端的维护问题仍然存在，为了完全解决这个问题，Brower/Server计算模式从而应运而生。但是B/S计算模式同样存在自己的一些局限性：1)单一的基于HTTP的通讯，效率不高；2)客户端的表现能力不强；3)同样存在浏览器的类型和版本问题。在目前的网络应用中，主要以B/S结构和多层C/S结构的应用为主，而大量的中间件产品正在为这些应用提供引擎动力。中间件技术涉及到了网络应用中的各个方面，提供了最核心的底层技术支持，已经发展成为网络应用中不可替代的关键技术。2.2 分布式网络通讯面临的挑战网络应用经历了从简单到复杂，从集中到分布的演变。大型分布式应用程序的构建和维护却是一个十分复杂的事情，尤其是不同应用程序之间的通信。伴随着网络环境的日益复杂，网络中的通信问题也日趋严重。主要表现在两个方面1：1. 在大型的分布式网络应用中，不同的应用运行在不同的进程中，分布在不同的计算机上，甚至是跨系统，跨平台的，如何将这些应用有效的集成，使不同的应用之间能保持良好的通信，使其发挥分布式应用的真正的巨大优势。这已经成为衡量一个分布式应用是否可靠，是否稳定的重要标准。2. 大多数传统的通信技术要求发送和接收方必须遵循两个条件：1)双方必须同时在线，即通讯是同步的；2)双方必须同时知道相互程序之间的调用接口。这样就要求一旦一个应用程序有任何接口的变化，就必须通知其他的应用程序。同时为了保持数据的完整性，发送和接收在实际的实现中可能必须使用分布式事务，以确保一方应用的数据改变能被双方承认。然而，在分布式环境中，应用并不总是同时运行的；而且网络并不总是可用和可靠的；数据的流量具有突发性，并可能造成网络的拥塞，这样一来分布式应用之间的异步通信问题就变得非常突出了。这些问题的提出对大型分布式应用程序提出了挑战，如何解决这些问题，使分布式应用程序能高效，稳定和安全的运行，降低开发的成本并提高应用的投资回报率，成为了开发人员急需解决的问题。第三章 消息中间件和JMS规范概述3.1 中间件的概述3.1.1 中间件的发展随着计算机技术的迅速发展。从硬件技术看，CPU速度越来越高，处理能力越来越强；从软件技术看，应用程序的规模不断扩大，特别是Internet及WWW的出现，使计算机的应用范围更为广阔，许多应用程序需在网络环境的异构平台上运行。这一切都对新一代的软件开发提出了新的需求。在这种分布异构环境中，通常存在多种硬件系统平台(如PC，工作站，小型机等)，在这些硬件平台上又存在各种各样的系统软件(如不同的操作系统、数据库、语言编译器等)，以及多种风格各异的用户界面，这些硬件系统平台还可能采用不同的网络协议和网络体系结构连接。如何把这些系统集成起来并开发新的应用是一个非常现实而困难的问题。中间件概念的出现就是为解决这些分布异构问题的。中间件(Middleware)是位于平台(硬件和操作系统)和应用之间的通用服务，这些服务具有标准的程序接口和协议。针对不同的操作系统和硬件平台，它们可以有符合接口和协议规范的多种实现2。中间件是一种独立的系统软件或服务程序，分布式应用系统借助这种软件在不同的技术之间共享资源，管理计算资源和网络通讯。它在计算机系统中是一个关键软件，它能实现应用的互连和互操作性，能保证系统的安全、可靠、高效的运行。中间件位于用户应用和操作系统及网络软件之间(如图3-1所示)，它为应用提供了公用的通信手段，并且独立于网络和操作系统。中间件为开发者提供了公用于所有环境的应用程序接口，当应用程序中嵌入其函数调用，它便可利用其运行的特定操作系统和网络环境的功能，为应用执行通信功能5。 应用应用中间件(提供分布式系统服务)操作系统硬件操作系统硬件 网络图3-1 中间件的位置3.1.2 中间件的作用和特点中间件满足了大量应用的需要，运行于多种硬件和OS平台上，它支持分布计算，提供跨网络、跨硬件和OS平台的透明的应用或服务的交互，支持标准的协议，支持标准的接口。由于标准接口对于可移植性和标准协议对于互操作性的重要性，中间件已成为许多标准化工作的主要部分。对于应用软件开发，中间件远比操作系统和网络服务更为重要，中间件提供的程序接口定义了一个相对稳定的高层应用环境，不管底层的计算机硬件和系统软件怎样更新换代，只要将中间件升级更新，并保持中间件对外的接口定义不变，应用软件几乎不需任何修改，从而保护了企业在应用软件开发和维护中的重大投资。 3.1.3 主要中间件的分类 目前，中间件所包括的范围十分广泛，针对不同的应用需求涌现出多种各具特色的中间件产品。但至今中间件还没有一个比较精确的定义，因此，在不同的角度或不同的层次上，对中间件的分类也会有所不同。按照IDC的分类方法，中间件大致可分为六类4。（一）终端仿真/屏幕转换用以实现客户机图形用户接口与已有的字符接口方式的的服务器应用程序之间的互操作。（二）数据访问中间件适用于应用程序与数据源之间的互操作模型，客户端使用面向数据库的API，以提请直接访问和更新基于服务器的数据源，数据源可以是关系型、非关系型和对象型。这类中间件大都基于SQL语句，采用同步通讯方式。此类中间件使应用开发简单，但如果是透过广域网使用，会带来严重的效率问题，因为在低速网上来回交互SQL语句会使通讯流量过大，同时对数据压缩、加密带来不便。（三）远程过程调用中间件RPC机制是早期开发分布式应用时经常采用的一种同步式的请求应答协议。通过这种协议，程序员编写客户方的应用，需要时可以调用位于远端服务器上的过程。当编译一个采用RPC机制的客户方应用时，编译器告之代表远程功能调用的句柄，客户方需要调用远地的过程时，引用相应的功能调用的句柄，由RPC机制来负责客户端程序实时地调用到远地的过程。服务器上的过程返回后，客户方的程序得到结果并继续往下进行。在采用RPC 机制时，调用远端的过程只需去引用它，而不必告之网络地址或其它底层信息。RPC机制可用以构造客户机/服务器方式的应用，但由于它是同步方式，因而在工作的时候，要求客户方和服务方均能正常工作才能很好地运行，有一方不能工作将导致RPC失败。这在网络故障、机器故障存在的情况下，这一要求是很难保证的。还有一点值得注意的是，不管客户方能做什么或做的多快，它必须依靠服务方才能有效工作。有些恢复机制可以在一个远程调用阻塞时转而去调用另一个服务器上的过程，但这种路由方式也会影响效率。目前，也有的RPC机制采用异步方式，客户方非阻塞地调用远端的过程，但这种方式不太标准而且很难采用。另外，由于大多数RPC机制很难建立点到点的关系，因而也很难用在面向对象的编程当中。（四）消息中间件尽管消息中间件不象RPC机制那样流行，但越来越多的分布式应用采用消息中间件来构建，通过消息中间件来把应用扩展到不同的操作系统和不同的网络环境。基于消息的机制更多地适用于事件驱动的应用，当一个事件发生时，消息中间件通知服务方应该进行何种操作。事件可以是一个请求，也可以只是一种警示，警示到来后，即可进行某种处理，但不需等待应答。使用消息中间件编程采用的是消息中间件的API，可以很好地扩展到不同的操作系统和硬件平台上。消息中间件的核心安装在需要进行消息传递的系统上，在它们之间建立逻辑通道，由消息中间件实现消息发送。消息中间件可以既支持同步方式，又支持异步方式，实际上它是一种点到点的机制，因而可以很好地适用于面向对象的编程方式。中间件领域目前最热门的技术是异步的消息中间件，异步中间件技术比同步中间件技术具有更强的容错性，在系统故障时可以保证消息的正常传输，因而在过去的两年里增长迅速。异步中间件技术可以分为两类：广播方式和发布/订阅方式。广播方式把消息分发给系统的所有用户。发行/订阅方式可以指定哪种类型的用户可以接收哪种类型的消息。发布/订阅方式由于更加智能有效，事实上已成为异步中间件的非正式标准。（五）交易中间件交易中间件是专门针对联机交易处理系统而设计的。联机交易处理系统需要处理大量并发进程，处理并发涉及到操作系统、文件系统、编程语言、数据通讯、数据库系统、系统管理、应用软件，是一个相当艰巨的任务，但是工作的难度可以通过采用一个交易中间件来简化。交易中间件就是一组程序模块，用以大大减少开发一个联机交易处理系统所需的编程量。X/OPEN 组织专门定义了分布式交易处理的标准及参考模型，把一个联机交易系统划分成资源管理（RM）、交易管理（TM）和应用（AP）三部分，定义了应用程序、交易管理器、多个资源管理器是如何协同工作的。资源管理器是指数据库和文件系统，交易管理器可归入交易中间件。交易中间件管理由应用声明和提交的交易，并通过两阶段提交协议等方式保证分布式交易的完整性、控制并发、实现交易路由和均衡负载。交易中间件理论上相对成熟，功能和性能界定清晰，但基本上适用于联机交易系统，如银行业务系统、定票系统等。尽管交易信息也是消息，交易中间件也是基于消息的传输，也可支持同步和异步方式，但与消息中间件的定位差距较大，属于一种较专用的中间件。（六）对象中间件面向对象的技术一直是软件界努力追求的目标，传统的对象技术通过封装、继承及多态提供了良好的代码重用功能。但是这些对象只存在一个程序中，外面的世界并不知道它们的存在，也无法访问它们。面向对象的中间件就是要解决这些问题，它提供一个标准的构件框架，能使不同的厂家的软件通过不同的地址空间、网络和操作系统互相交互访问。该构件的具体实现、位置及所依附的操作系统对客户来说都是透明的。例如，我们可以通过简单的组装或扩展已有的构件就可以建立一个客户机/服务器结构的信息系统。面向对象的中间件技术的目标就是为软件用户及开发者提供一种应用级的即插即用的互操作性，就象现在使用集成块和扩展板一样。有关对象中间件的标准相继问世，像OMG组织的CORBA、Microsoft的COM 以及IBM公司的SOM等，这些标准都极大地促进了对象中间件技术的发展，随着面向对象的应用系统的逐渐增长，对象中间件的需求也在逐年加大。对象技术的优势和对象中间件的标准化，促使对象中间件的功能将最终涵盖其它几类中间件的功能而成为中间件产品的主流。不论各种中间件他们的目的和功能有多少不同，但是它们都可以向上提供不同形式的通讯服务，包括同步、排队、订阅发布、广播等等，在这些基本的通讯平台之上，可构筑各种框架，为应用程序提供不同领域内的服务，如事务处理监控器、分布数据访问、对象事务管理器OTM等。平台为上层应用屏蔽了异构平台的差异，而其上的框架又定义了相应领域内的应用的系统结构、标准的服务组件等，用户只需告诉框架所关心的事件，然后提供处理这些事件的代码。当事件发生时，框架则会调用用户的代码。用户代码不用调用框架，用户程序也不必关心框架结构、执行流程、对系统级API的调用等，所有这些由框架负责完成。因此，基于中间件开发的应用具有良好的可扩充性、易管理性、高可用性和可移植性。3.2 消息中间件的概述3.2.1 消息中间件的由来在分布式应用中，CORBA、DCOM、RMI等RPC中间件技术已广泛应用于各个领域。但是面对规模和复杂度都越来越高的分布式系统，这些技术也显示出其局限性：13（1）同步通信：客户发出调用后，必须等待服务对象完成处理并返回结果后才能继续执行；（2）客户和服务对象的生命周期紧密耦合：客户进程和服务对象进程都必须正常运行；如果由于服务对象崩溃或者网络故障导致客户的请求不可达，客户会接收到异常；（3）点对点通信：客户的一次调用只发送给某个单独的目标对象。面向消息的中间件（Message Oriented Middleware，MOM）较好的解决了以上问题。发送者将消息发送给消息服务器，消息服务器将消息存放在若干队列中，在合适的时候再将消息转发给接收者。这种模式下，发送和接收是异步的，发送者无需等待；二者的生命周期未必相同：发送消息的时候接收者不一定运行，接收消息的时候发送者也不一定运行；一对多通信：对于一个消息可以有多个接收者。3.2.2 消息中间件的定义消息传输中间件(Message Oriented Middleware，MOM)是中间件中的一种。消息中间件也称为消息代理中间件或通信中间件，它是依据消息传输或消息队列的原理来工作的。它能够简化应用之间数据的传输，提供可靠的，跨平台的消息传输手段3。消息中间件支持同步和异步两种通信模式，其中异步通信模式是基于消息队列转发机制的。消息队列一般提供多协议支持和其他系统管理服务，完成可靠的，可扩展的异构环境中的通信12。一般来说，消息队列采用分布式计算模型来实现同步和异步交互。消息中间简化了应用之间数据的传输，屏蔽底层异构操作系统和网络平台，提供一致的通讯标准和应用开发，确保分布式计算网络环境下可靠的、跨平台的信息传输和数据交换。它基于消息队列的存储-转发机制，并提供特有的异步传输机制，能够基于消息传输和异步事务处理实现应用整合与数据交换。如果没有消息中间件完成信息交换，应用开发者为了传输数据，必须要学会如何用网络和操作系统软件的功能，编写相应的应用程序来发送和接收信息，且交换信息没有标准方法，每个应用必须进行特定的编程从而和多平台、不同环境下的一个或多个应用通信12。例如，为了实现网络上不同主机系统间的通信，将要求具备在网络上如何交换信息的知识（比如用TCP/IP的socket程序设计）；为了实现同一主机内不同进程之间的通讯，将要求具备操作系统的消息队列或命名管道(Pipes)等知识。由此可见，消息中间件在提供相应的底层通信功能的同时，也大大减轻了开发人员的开发过程。3.2.3 消息中间件的关键技术消息队列技术是消息中间件中的关键技术。消息队列是分布式应用间交换信息的一种技术。消息队列可驻留在内存或磁盘上,队列存储消息直到它们被应用程序读走。通过消息队列，应用程序可独立地执行-它们不需要知道彼此的位置、或在继续执行前不需要等待接收程序接收此消息。在分布式计算环境中，为了集成分布式应用，开发者需要对异构网络环境下的分布式应用提供有效的通信手段。为了管理需要共享的信息，对应用提供公共的信息交换机制是重要的。消息队列为构造以同步或异步方式实现的分布式应用提供了松耦合方法。消息队列的API调用被嵌入到新的或现存的应用中，通过消息发送到内存或基于磁盘的队列或从它读出而提供信息交换。消息队列可用在应用中以执行多种功能，比如要求服务、交换信息或异步处理等。3.2.4 SUN对消息中间件的贡献 JMS在JMS规范还没有推出以前，就已经存在了一些消息中间件产品。其中比较重要的MOM系统包括IBM的MQ Series、Microsoft的MSMQ和BEA的MessageQ等。由于没有一个通用的标准，这些系统很难实现互操作和无缝连接。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，JMS)是 J2EE (Java 2 Enterprise Edition) 套件的一部分，它提供了标准 API，Java 开发人员可以使用这些 API 来访问企业消息系统的共同特性16。Java 消息服务定义了Java 中访问消息中间件的接口。JMS 只是接口，并没有给予实现，实现JMS 接口的消息中间件称为JMS实现(JMS Provider)。JMS 支持发布/订阅和点对点模型，并允许创建由任意 Java 对象组成的消息类型。3.3.2 JMS的目标JMS 的基本设计目标是为了提供一组一致的接口，消息传递系统客户端可以独立地使用这些接口，而不必关心基础消息系统的提供商。这样，客户端应用程序不仅可以跨计算机体系结构和操作系统进行移植，而且也可以跨消息传输产品进行平台无关的移植。使用JMS的客户端应用程序将正常工作，而不用在所有符合JMS的消息传递系统上做修改。同时，JMS也被设计成最小化的消息传递系统，JMS提供商为其产品实现JMS API所规定的工作；提供了普通消息传递系统的大多数功能。因此，许多消息系统提供商已经将它们的产品适配成为 JMS系统，允许Java访问它们系统所提供的功能。3.3.3 JMS的体系结构一个完整的JMS应用程序是由以下部分组成的6：l JMS实现(JMS provider)，它是一个实现了JMS接口并提供管理和控制能力的消息通信系统。l JMS客户端是使用Java编程语言编写的创建和消费消息的程序或组件。l 消息是在JMS客户之间用于交流信息的对象。l 受管对象(Administered object)是由管理员为客户使用而创建的预先设置JMS对象(preconfigured JMS object)。主要有两个受管对象：目的域(destination)和连接工厂(connection factory)。如图3-2展示了上述对象的交互情况。管理员利用管理工具绑定目的域和连接工厂到JNDI(Java Naming and Directory Interface)命名空间。然后，JMS客户就能够查找该命名空间内的受管对象，而后通过JMS实现建立一个到这些对象的逻辑连接。 图3-2 JMS API 的体系结构3.3.4 JMS的基本概念3.3.4.1 消息通信模式JMS规范定义了两种消息通信模式：点对点(Point-to-Point，PTP)通信模式和发布者/订阅者(Pub/Sub)通信模式。图3-3 JMS 点对点通信模式如图3-3所示，PTP(Point-to-Point)模型是基于队列的，发送方发消息到队列(Queue)，接收方从队列接收消息，队列的存在使得消息的异步传输成为可能。和邮件系统中的邮箱一样，队列可以包含各种消息，JMS Provider 提供工具管理队列的创建、删除。JMS PTP 模型定义了客户端如何向队列发送消息，从队列接收消息，浏览队列中的消息。如图3-4所示，JMS Pub/Sub 模型定义了如何向一个内容节点发布和订阅消息，这些节点被称作主题(topic)。主题可以被认为是消息的传输中介，发布者(publisher)发布消息到主题，订阅者(subscribe) 从主题订阅消息。主题使得消息订阅者和消息发布者保持互相独立，不需要接触即可保证消息的传送。图3-4 JMS Pub/Sub通信模式3.3.4.2 JMS消息模型在JMS中，消息通常是由以下几部分组成：消息头，属