基于OSGI的完全分布式EAI实践框架

李春芳

（长沙理工大学 计算机与通信工程学院，湖南 长沙410004）

0 引 言

针对现有企业应用的集成方案EAI（enterprise application integration）是目前应用程序开发的热点之一。EAI集成方案主要集中在Web service［1，2］与ESB （enterprise service bus）［3，4］2种。其中Web service是面向服务架构SOA（service oriented architecture）框架技术的关键与基础性内容，它通过开放的XML标准来描述、发布、发现、协调与配置企业原有的应用程序，并通过框架提供的API来获取与处理这些XML配置信息，最终完成应用程序间的数据与逻辑 通信。Web services 的通信核心技术SOAP （simple object access protocol）是一种建立在远程过程调用基础上的技术，它只对需要进行通信与交互的对象进行简单封装，因此不能根据不同外部应用程序的要求提供区别性服务；除此之外，Web service技术是基于B／S模式构建的，它往往只支持单向应用对象的调用与访问，也没有设定专门的机制来完成不同应用程序间大量的通讯需求与逻辑调用，因此需要重新开发应用程序来延展到其它应用程序，导致基于Web service的应用程序集成很难再继续扩展。IBM 提出了ESB （enterprise service bus）概念并提供了其具体 技术实现方案［5］，Oracle也提出了类似的OSB （oracle service bus）框架［6］来解决多应用程序集成问题，通过总线的方式来接入需要进行通信与交互的应用程序，这样便具备了很好的可扩展性以及通信之间的管理。但由于这些服务总线技术都要求基于相同的基础平台，而相应基础平台成本高昂，导致相应服务总线技术的应用非常有限，难以拓展到非基础平台支持的应用程序。

OSGI（open service gateway initiative）［7］最初是为了研究在制造工艺和结构互异的设备上提供统一发现与通信的技术框架，而其在具体实现过程中逐渐发展了模块化、动态加载、安全以及事务处理方面的优势，由此被广泛用于分布式与服务演化［8，9］，以构建基于Java的动态模型系统。本课题在充分利用OSGI的封装、模块化以及动态构型的基础上，利用了Java的其它技术，通过构建一个良好的框架，解决了异构现有应用程序在集成时的拓展、管理以及安全性问题。

1 OSGI关键技术说明

OSGI框架是OSGI规范的核心，它提供了1 个通用、安全、支持动态管理的Java框架来实现对各种Bundles的配置、下载、安装与运行，并在严格生命周期模式管理下支持向外部提供不同需求的服务内容。由于OSGI框架在对动态扩展管理Bundles的能力以及严格约定了Bundles与Services（服务）之间的对应关系，OSGI开始被应用于EAI系统中。OSGI框架功能结构层次如图1所示。

图1 OSGI框架功能结构层次

Bundle是OSGI框架的管理基础。Bundle既可以是本地1个类、口、应用程序、界面、共享库、JSP 或Servlet请求、数据库，也可以是本地Bundle与外部Bundle组织后形成的。开发者可使用简单的接口实现完成现有Java对象到Bundle的转换。OSGI使用配置文件为每个Bundle严格约束了其接口、服务、依赖与使用权限等内容。部署到OSGI框架的Bundle将随着OSGI框架的启动而自动启动，进入Active状态。

基于OSGI框架的组件执行环境只要支持Java对象运行即可 （如J2SE、J2EE 或Android等），因此需要集成的安装环境简单、易于移植。

OSGI框架自带的模块层可以自动对本地组件用到的Bundles进行解析、有效性检验及加载，并根据提取出的Bundle依赖、包约束、强制性属性、类过滤、提供者约束等信息，完成对相应Bundle的加载。OSGI框架为Bundles提供了专门的加载体系以提高加载效率。如果相应Bundle校验不成功，则相应Bundle将无法被OSGI框架加载，也无法使用OSGI框架提供的基础服务，更无法向其它Bundle提供服务。

OSGI框架的生命周期层向开发者提供API来管理Bundles 在各种运行状态时 （如INSTALLED、RESOLVED、 UNINSTALLED、 STARTING、 ACTIVE、STOPPING）的执行内容。OSGI框架自动加载与运行配置到该框架的Bundle，并为每个进入启动状态的Bundle生成一个BundleContext对象来管理该Bundle的引用；开发者可使用BundleContext对象的registerService方法将Bundle的特定方法内容注册为一个服务。

开发者可以通过OSGI服务层 （service）动态Bundle编程模型的ServiceRegistration对象来建立某服务接口与特定Bundle之间的对应关系，从而可以为外部应用程序的不同需要提供不同服务，而对其具体实现Bundle进行完好封装与隐藏。开发者也可以通过编程模型BundleContext对象的getServiceReference方法获取一个服务索引通过服务层来管理具体服务实现的注册与注销。服务使用者通过的来获取对一个服务的索引，并利用该索引的gerService方法实现对一个服务的调用。

由于OSGI框架本身为Bundles提供了完备得安全、用户管理、日志、Http服务等基础服务，使得Bundles可在OSGI框架下安全有效地运行。OSGI框架还为各服务提供了统一的封装与声明，以便外部应用Bundle可以很快发现与使用所需服务，并在无需系统重启的前提下进行服务具体实现的快速更新。

2 基于OSGI的完全分布式EAI实践框架定义

基于OSGI的完全分布式EAI实践框架需要解决2大问题：①OSGI对现有Java对象等有良好的封装与服务管理，而现实应用中还有大量非Java应用程序；②需要专门建立服务管理组件来管理OSGI组件之间的远程调用与交互。本课题基于此提出基于OSGI的完全分布式EAI实践框架 （OSGI－based completely distributed EAI practice framework，OD－EAI框架），其框架如图2所示。

图2 基于OSGI的完全分布式EAI框架组成结构

OD－EAI框架由基于OSGI的服务程序 （OSGI－based service program，OP）以及基于OSGI的服务管理器 （OSGI－based service manager，OM）2 大组件类型组成。其中OP组件是将原有应用程序或新开发的应用程序部署到OSGI框架上以便被统一发现、调用、加载与执行；OM 组件主要用于管理远程注册到本组件的服务，并提供对这些服务命名、访问安全、通信管理等功能。

2.1 OP的服务封装

OM 组件应用程序来源分Java与非Java程序2种。对于Java程序，可使用简单方法直接进行封装；对于非Java程序则需要先封装为Java程序，然后再进行OSGI封装。这样可以使更多的应用程序纳入OSGI平台，可以支持统一的通信与服务。

2.1.1 基于Java源程序的OSGI封装

基于Java源程序的OSGI封装主要通过以下几个步骤完成：

（1）在具体实现业务逻辑的Java对象所在包不交叉的位置创建包用于包含根据不同服务需求定义不同的接口对象及与之对应的Activator对象。在与接口对象不交叉的位置创建包包含具体实现业务逻辑的对象及与之对应的Activator对象；其包与原有实现业务逻辑的对象包也应不交叉。通过这种方法形成3 个Bundle：接口Bundle、实现Bundle、具体逻辑Bundle。它们之间会形成一定的依赖关系，但是由于它们相互独立，因此它们可以选择性开放与共享，从而可以面向不同应用开放或隐藏相应实现，以支持多样服务的实现。相应Bundle形成的类空间如图3所示。

图3 Bundle之间类空间依赖关系

最终注册到框架的是接口实现的服务Bundle，在其Activator对象的start、stop、update等方法中定义对实际实现相应业务功能对象方法的调用。源Java应用程序的具体实现根据需要被开放或隐藏。

（2）定义与相应接口Activator对象对应的服务，在相应的服务声明文件中声明相应服务与特定Bundle Activator对象之间的关联。该服务声明文件必须声明该Bundle的激活模式、起始类、引用名、许可、导入包、导出包、依赖Bundle等信息。其中起始类对应一特定Bundle Activator对象名称；该服务Bundle的导入包声明需要包含要使用的对象包路径信息，导出包声明可被外部使用的对象包路径信息。如果一个服务Bundle需要引用另一个Bundle中的对象，则需要将引用Bundle的导出包声明为导入包，则相应包中所有对象对该Bundle来说就是可见的。

OSGI就是通过以上2大步骤来直接配置、更新Bundle的服务内容与依赖关系。

除了Java对象，OSGI还可以封装Java客户端程序，如静态页面、JSP和Servlet等，以便以Bundle的形式获取用户请求并返回结果。OSGI对一个已经存在的jsp文件封装步骤如下：

（1）打开为该JSP文件封装后形成的Bundle项目配置文件，并在导入包中增加支持对JSP 文件进行封装的包信息，如org.eclipse.equinox.jsp.jasper，org.apache.jasper，org.eclipse.equinox.jsp.jasper.registryi，org.eclipse.osgi.services等。

（2）为该JSP文件创建一个与之对应的Bundle Activator对象，在该对象中定义一个ServiceTracker对象；在Bundle Activator对象的start方法中初始化化该Service－Tracker对象，并传递该Bundle的Context作为其初始化参数，以便建立BundleContext对象与ServiceTracker对象的映射关系。需要在该ServiceTracker 对象的addService、modifyService及removeService方法定义需要添加、更新或移除服务的内容，然后在Bundle Activator对象中通过调用ServiceTracker对象的getService方法来查找服务并绑定方法。在封装某JSP为其中一服务时，利用BundleContext的getService方法获得一个服务索引，并将其强制转换为HttpService类型；利用BundleContext对象的getBundle （）方法以及一个jspFolder对象创建一个BundleEntryHttp－Context对象；调用HttpService.registerResources 方法将该BundleEntryHttpContext对象注册为Http响应源，返回该HttpService对象。

（3）将该Bundle部署到OSGI框架中。

2.1.2 基于非Java程序的OSGI封装

JNI（Java native interface）［10］是由Sun公司提供的Java程序与系统中原生方法的交互技术，可支持C／C＋＋与Java程序的互相调用。本课题中使用其将C／C＋＋等程序封装成可被外部应用识别与调用的Java对象，然后再将其部署到OSGI框架以统一的形式向外部提供服务。

将C／C＋＋等程序封装为Java程序的基本操作步骤如下：

（1）编写Java代码并在Java源程序中声明可被其它Java程序调用的本地方法 （native method code）信息；编译该Java程序使本地方法可被其它Java程序像调用普通方法一样使用。

（2）使用原生方法生成工具 （native method generator tool），为包含了本地方法的Java对象生成符合目标语言格式的函数声明头文件。如SDK 中的javah.exe可以为Java程序生成C头文件，该工具自动将Java中声明的方法类型转换到对应目标语言的类型格式。

（3）编写该目标函数具体实现。编写符合目标程序结构的函数实现说明，并在实现定义过程中调用已存在的C／C＋＋程序函数。

（4）利用目标程序编译器创建可被Java程序使用的共享库。如Windows下使用cl－Ic：＼jdk＼include－Ic：＼jdk＼include＼ win32－LD Sample1.c－FeSample1.dll 为Sample1.c生成对应的共享库。

（5）在引用本地方法的Java 程序中调用System.loadLibrary方法加载相应共享库对象，然后调用相应Java对象的本地方法完成具体功能执行与结果返回。

JNI技术实际上是通过为包括C／C＋＋在内的源应用程序生成Java动态共享库的方法实现对非Java源程序的封装。这些动态共享库包含一个或多个已被成功编译、链接的函数字节码。当一个Java程序通过创建Java对象，并调用其声明的本地方法时，系统将传递一个JNIEnv指针、一个jobject指针以及Java程序中的方法参数给相应链接库具体执行，然后返回声明类型结果给发出调用请求的Java应用程序。

2.2 OM 服务管理器构建

OM 服务管理器主要用于接收远程OSGI服务注册并管理它们之间的通信。OM 服务管理器管理体系是基于层级模式的，这样既容易管理，又可以减少不必要的通信浪费，并可以快速识别服务访问通路。OM 服务管理器的具体功能包括向注册到本服务管理器的OSGI服务提供基础服务以及通信服务。

2.2.1 基础服务

由于OSGI本身包含对各Bundle的事务、安全管理，因此基于OSGI的OM 自动包含了远程申请注册到该OM的服务的事务性及安全性管理。OM 提供的基础性服务内容包括：

（1）OM 并不具体定义服务的实现，而是收集与管理各下级OSGI服务或下级OM 可提供的服务内容与特性，对其进行重新分类与索引，以便可以快速定位相应服务具体实现的OSGI框架位置。各级OM 存储的与之直接交互的OSGI服务信息也需要在其上级OM 中进行备份。一些成功的服务引用查找路径信息也将被存储到各级OM 中，以提高OSGI服务定位与引用效率。

（2）如果相应OSGI服务需要被注销，则其需要向相应的服务管理器发出通知，并由OM 通知其所有上级OM对该引用进行注销。

（3）如果相应服务被更新，则采用先注销再注册的方式来保障相应服务引用安全与一致性。

各OSGI服务提供者与使用者需要遵循特定的服务声明与引用约定，相应约定具体信息存储在OM 中。

OM 的服务声明约定包括以下内容：

（1）服务提供者声明：服务提供者需要经过申请与认证，以确认其提供服务功能的合法性。服务提供者的认证由OSGI服务对应的OM 来完成。

（2）服务提供内容声明：该内容主要用于服务提供的文字性说明、服务引用名、服务引用级别、服务关键词、参数内容声明以及返回内容声明，作为服务使用者确认和使用相应服务的基本依据。其中文字性说明用于定义服务大致功能内容，该服务提供内容声明用于在确定使用相应服务时的人工确认基础；服务引用名说明服务引用使用对象名称，包含该对象可提供的方法名称信息；服务引用级别用于完成对服务引用的安全性保护，其内容包括公用、私用、权限引用、认证引用4种，其中公用意味着无需校验则直接调用与返回，私用意味着仅为服务提供者在其它服务中引用，权限引用意味符合特定条件的权限声明拥有者使用，而认证引用意味着需要通过服务提供商的认证才能引用。服务关键词用于服务管理器查找相应服务提供商所使用的搜索关键词，以便快速定位服务提供商。参数内容声明用于说明参数个数、参数含义以及参数顺序，所有的参数都是字符串类型，因此相应OSGI服务提供商在对外声明服务时就必须依此进行定义，OSGI服务使用者必须将传递的参数内容预先进行转换；返回内容可是以字符串形式存放的返回结果，返回结果必须包括返回内容说明以及具体值信息，返回内容之间需要通过特定字符来隔离（如 “；”号）。

OM 的引用声明约定包括：

（1）服务引用者声明：服务引用者需要经过申请与认证，以确立其引用者的合法身份。

（2）服务引用内容声明：该内容包括服务引用关键词说明。

一个OSGI服务程序需要使用的服务在本地框架中查找失败时，则该OSGI服务程序将向其上级服务管理器发出查找与调用请求。服务管理器将根据服务使用者提供的服务引用者声明和引用内容声明在本地服务管理器查找并向OSGI服务引用者返回查找结果，如果服务使用者提示继续搜索，则相应服务管理器再向上级发出引用继续查找，最终将查找结果全部提示服务使用者选择。当一个OSGI服务使用者经常使用某服务并确定某特定服务引用选项，则当服务使用者需要时则自动形成对相应服务的引用，直到服务使用者自动注销对相应服务的引用。

2.2.2 服务通信管理

OP与OM 之间以及OM 与OM 之间的通信管理通过JMS （Java messaging service）［11］技术来实现。JMS是一个基于Java的消息通信服务中间件，它以消息为中心定义消息发送者、消息接收者以消息内容，并通过创建连接、创建会话、发送消息、接收消息、消息发送与接收异常处理的基本流程完成消息的发送与服务。JMS支持异步的点对点或发布／订阅模式的消息通信，OD－EAI框架中的OP 与OM 以及OM 与OM 之间通常只使用点对点消息通信模式。在JMS点对点模式下，OD－EAI中的OP 与OM 既是JMS消息发送端，又是JMS 消息接收端；它们都需要建立在OSGI框架基础上增加消息服务的支持。OD－EAI的JMS消息遵循JMS约定。OD－EAI将来自于某OP 的服务引用封装为JMS消息，然后发送给其注册到的OM；OM 对JMS消息内容进行分析，然后在本地或上级进行服务查找，并将产生的服务引用结果以JMS消息的形式返回给OP；OP分析该返回消息，然后根据需要确定是否引用与执行相应服务引用或者要求重新搜索。通过在OM 消息接收Bundle中设定消息过滤信息，则可以过滤一些不安全或不合理的消息发送请求，以减轻整个OD－EAI消息传递负载。

服务引用被确立后，由OM 为服务使用者创建一个会话对象，用于管理相应的服务调用与返回。由此可见，ODEAI框架中传递3种消息：一种是查找服务的消息，一种是引用服务的消息，一种是服务引用结果执行返回的消息，它们是异步的。OP与OM 都采用监听机制来处理到达的每条JMS消息，并对其进行解析。JMS消息发送者会为每个合法JMS消息发送创建一个连接与会话，直到消息发送被取消或已完成，相应连接与会话被关闭。同一连接允许多个会话执行；OM 跟踪与管理这些会话，并进行统计，以便进行合理的调度、事务以及异常处理。

3 OD－EAI的应用案例分析

由于OD－EAI的统一性、兼容性以及可扩展性，其可被广泛应用到政务、电信、银行等各种网上服务系统以支持跨部门以及企业的应用程序集成。以一个城市的政务综合管理服务平台构建为例说明该OD－EAI框架的使用方法。在集成的开始需要对要集成的对象进行分析与总结。传统的政务服务平台大致由以下几种应用程序组成：

（1）政府部门内部的办公系统。这种局部范围内的办公系统往往通过利用现代化的办公设备－计算机来代替办公人员的手工作业。它们的功能往往比较单一，大多采用了各自独立的开发语言和技术实现，但是这些系统有个比较共同的特点就是以数据为中心。

（2）各政府部门的门户网站。政府部门通过门户网站建立公众与政府部门之间广泛的沟通关系。其中一部分主要完成信息发布与共享，该部分功能使政务执行流程与信息公开化；而另一部分则包含了与特定政务功能对应的网上申请、验证以及查询功能，可以有效提高政府部门工作效率和工作质量。需要集成的往往是后者，它们的开发通常由页面逻辑处理、业务逻辑处理以及数据源3大块组成，而其中每一部分的具体开发方法与技术不一致。

（3）政府部门之间的信息共享与实时通信。这部分主要是由于各政府部门根据需要而专门开发的信息共享与实时通信通道。如铁路车票验证系统与公安身份管理系统之间的信息共享与实时通信，然而这些通信在安全管理以及事务管理方面存在一定的隐患，且都属于单向开发，开发成本较高。完成以上几种政务应用程序集成的基于OD－EAI的政务综合服务系统结构如图4所示。

图4 基于OD－EAI的政务综合服务系统结构

基于OD－EAI的政务综合服务系统由基于OSGI的政务服务程序以及基于OSGI的政务管理程序2部分组成。其中基于OSGI的政务服务程序就是OD－EAI中的服务程序，它是源于对以上政务系统类型的以下具体整合实现的：

（1）针对政府部门内部办公系统的OSGI整合。根据需要采用基于数据源的OSGI封装模式或基于应用程序的OSGI封装模式；其中前者关注的是数据集成，而后者关注的应用逻辑的集成。

（2）针对各政府部门门户网站的OSGI整合。可根据需要从页面逻辑或业务逻辑入手。如果原有应用逻辑与实际需求大致吻合，则采用前者；如果需要额外补充功能实现，则采用后者。

（3）针对政府部门之间的信息共享与实时通信。分别对信息发送端与信息服务端应用程序进行OSGI封装，然后分别注册到相应上级OM，以被其它OP访问与引用。

政务管理程序实际上就是OD－EAI中的OM，相应政务管理程序可根据需要进行行政区域或功能级别上的划分。图4主要体现的是基于行政区域划分的OD－EAI实现。基于功能级别的划分实现与之类似，并且可与行政区域划分实现共存，以实现多级服务共享。

本课题利用遵守OSGI规范的Equinox框架来支持OSGI Bunlde的管理。每个政务服务程序都有一个向外请求Bundle以及1个提供服务的Bundle。每个向外提供服务的Bundle需要验证外部请求的类型、请求来源；每个向外请求的Bundle需提供请求类型、功能与性能需求说明等内容；由政务服务管理Bundle逐级在本级与上级政务管理Bundle中查找可提供相应请求的Bundle，并将其反馈给相应政务服务Bundle，并由此通过创建会话来管理政务管理Bundle与政务服务Bundle之间、政务管理Bundle与政务管理Bundle之间的通信。政务管理Bundle通过管理会话的排序、调度以及安全来实现请求与服务提供的并行处理，从而达到服务的高效访问与管理。基于OD－EAI框架的某区域政务系统经测试运行良好，实现了高峰段的访问管理，并实现了在廉价机器上的分布式政务处理运行。

4 结束语

根据OD－EAI的理论与实践，OD－EAI框架具有如下几个特点：①结构简单。由于OD－EAI采用了统一框架来约束定义EAI系统上的所有应用组件，因此结构简单，容易管理。②可扩展性强。通过在相应服务管理器补充注册与更新相应服务程序，可以快速实现整个EAI系统的功能扩展与更新。③安全性强。除了OSGI服务程序对服务引用者的身份与使用权限的验证，服务管理器也可以进行有效的引用来源验证与过滤，从而加强了框架使用的安全性。④开发与维护成本低。由于OSGI是种动态加载技术，无需在原有Java程序上做太多修改，通过充分利用OSGI框架提供的基础功能，可以大大降低开发与维护费用。且Bundle之间的依赖关系，Bundle与服务之间的绑定关系通过配置文件完成，相应Bundle间调用组织成的业务流程也可以因此可视化定义，因此更加降低了系统开发与维护成本。⑤应用层面广泛。由于OD－EAI通过跨语言调用技术实现了多种开发技术的融合，Java对各种数据源的良好支撑，因此OD－EAI应用层面非常广泛，可以应用于各行各业。当然由于OD－EAI涉及的具体实现技术众多，因此OD－EAI初次实践会产生一定困难；另外OD－EAI中传递的消息内容、服务声明与引用声明还未标准化，都会对ODEAI的具体应用造成一定困难。总而言之，OD－EAI框架为新一代应用程序整合提供了良好的理论和实践参考。

［1］ZHANG Haifeng，MA Su.SOA－based enterprise application integration technology research and implementation ［J］.Computer Applications and Software，2011，28 （7）：57－60（in Chinese）.［张海峰，马苏.基于SOA 的企业应用集成技术研究与实现 ［J］.计算机应用与软件，2011，28 （7）：57－60.］

［2］LIU Xianmei，LIU Qian，XU Feng.Research of enterprise application integration model based on SOA ［J］.Computer Engineering and Design，2009，30 （16）：96－99 （in Chinese）.［刘贤梅，刘茜，徐锋.基于SOA 的企业应用集成模型的研究［J］.计算机工程与设计，2009，30 （16）：96－99.］

［3］LIN Yongqin，HUANG Chenhui.Research on ESB framework for enterprise application integration ［J］.Journal of Computer Applications，2010，30 （6）：234－236 （in Chinese）. ［林泳琴，黄晨晖.面向企业应用集成的ESB框架的研究 ［J］.计算机应用，2010，30 （6）：234－236.］

［4］HU Liang，LI Wei.Research and design of a high reliability enterprise service bus ［J］.Computer Applications and Software，2012，29 （6）：106－110 （in Chinese）.［胡亮，李玮.1种高可靠性企业服务总线的研究与设计 ［J］.计算机应用与软件，2012，29 （6）：106－110.］

［5］IBM.Enterprise service bus［EB／OL］.http：／／www.ibm.com／developerworks／cn／websphere／zones／esb／，2009.

［6］Oracle.Oracle service bus white paper ［EB／OL］.http：／／www.oracle.com／us／products／middleware／soa／overview／maximizing－benefits－oracle－soa－150680.pdf，2013.

［7］The OSGI Alliance.OSGI core release 5 ［EB／OL］.http：／／www.osgi.org／Download／File？url＝／download／r5／osgi.core－5.0.0.pdf，2012.

［8］WU Yuanli，ZHANG Zhuxi，YANG Hongqiao，et al.Research and development of distributed OSGI［J］.Application Research of Computers，2010，27 （11）：4010－4014 （in Chinese）.［吴元立，张瞩熹，杨宏桥，等.分布式OSGI研究与发展 ［J］.计算机应用研究，2010，27 （11）：4010－4014.］

［9］ZHANG Shi，HUANG Linpeng.Dynamic service evolving based on OSGI ［J］.Journal of Software，2008，19 （5）：1201－1206 （in Chinese）. ［张仕，黄林鹏.基于OSGI的服务动态演化 ［J］.软件学报，2008，19 （5）：1201－1206.］

［10］Oracle.Java native interface specification－contents［EB／OL］.http：／／docs.oracle.com／javase／1.5.0／docs／guide／jni／spec／jniTOC.html，2004.

［11］Oracle.JMS specification ［EB／OL］.http：／／www.oracle.com／technetwork／java／jms／index.html，2013.