J2EE Connector Architecture 1.5 的新特性
作者:Jennifer Rodoni
Java2 的最新版本有一些激动人心的修改和增强。这篇文章所讲述的是企业版的 Connector Architecture。尽管本文简要介绍了
Connector Architecture,但是还是假设读者熟悉 Connector Architecture 1.0 版,尤其是资源适配器。(有关于
1.0 版的详细信息,请参见规范。有关于他的资源适配器和系统级规范的概述可以在上一篇文章中看到)。
这篇文章是两部分系列中的第一部分,该系列主要集中在资源适配器的修改和增强上,特别关注新的系统级规范,特别是生存期管理和任务管理规范。本文将讨论实现细节和规范要求,同时,我们将研究一些伪代码,看看
EIS 供应商如何为符合 1.5 版本的资源适配器实现新的规范。本示例的第二部分(很快与读者见面)将集中讲述事务流和消息流规范。
Connector Architecture 概述
J2EE Connector Architecture 为将 J2EE 平台连接到异构的企业信息系统(EIS)定义了标准的架构。EIS 供应商不再需要与每个不同的
J2EE 应用程序服务器进行交互来定制其产品。与此类似,应用程序服务器供应商无论何时要连接到另一个 EIS,也不需要进行修改。相反,应用程序服务器供应商只需要一次性地实现
Connector Architecture 框架。EIS 供应商只需要开发一个基于该架构的标准资源适配器即可。在这些环境下,一个兼容的 EIS
可以插入任何一个支持 Connector Architecture 的应用程序服务器中,而一个应用程序服务器也可以连接到任何一个提供标准资源适配器的
EIS。图 1 描述了这种在兼容应用程序服务器和企业信息系统之间的无缝集成。

图 1: EIS 和应用程序服务器之间的系统集成
|
通过开发标准的资源适配器,EIS 供应商减少了开发时间和成本。同时,只要适配器符合规范,那么供应商对集成问题就有了一个可伸缩的、安全的和事务性的解决方案。
资源适配器概述
在 EIS 和应用程序服务器的集成和连接中,资源适配器起中心作用。它在应用程序组件、应用程序服务器和企业信息系统之间充当联系点。资源适配器及其他组件必须根据定义良好的规范进行通信,这些规范是由
J2EE Connector Architecture 中指定的。图 2 描述了不同组件和它们之间的交互。

图 2: Connector Architecture 组件与交互 |
为了与应用程序服务器无缝集成,资源适配器必须遵循一系列由 Connector Architecture 定义的准则(称为系统级规范)。这些规范存在于应用程序服务器和
EIS 之间,并通过资源适配器来实现。它们指定 J2EE 平台的一个外部系统如何通过支持一些由 J2EE 容器控制的基本功能来与之集成。其中最重要的功能包含连接管理、事务管理、安全、消息流、任务管理和生存期管理。
1.0 版规范
在 1.0 版的 Connector Architecture 中有三条规范用于说明上面提到的功能:
- 连接管理规范:让应用程序通过资源适配器连接 EIS。它还允许应用程序服务器池化(pool)到 EIS 的连接请求。
- 事务管理规范:允许应用程序跨一对多的 EIS 资源适配器来管理和执行事务访问。
- 安全规范:提供对 EIS 安全访问的支持。
1.5 版中的新规范
在 J2EE Connector Architecture 1.5 版中,由于新的功能和特性也出现在规范中,所以资源适配器必须支持更多的规范。通过实现为每个规范定义的必要接口,一个适配器可以支持四个新的规范:
- 生存期管理规范:让应用程序服务器管理资源适配器的生存期,即具有启动和关闭功能。
- 任务管理规范:允许资源适配器将任务提交给应用程序服务器进行执行。由于应用程序服务器为资源适配器工作,所以资源适配器本身就不用操心线程管理。相反,应用程序服务器可以有效地管理这个方面,如果需要,可以使用线程池。尽管任务管理规范并非必需的(资源适配器可以选择管理自己的线程进行工作),但在此毫不犹豫地推荐使用该规范。
- 事务流入规范:允许资源适配器将导入的事务传递到应用程序服务器,允许完成流入的事务及 EIS 的崩溃恢复。
- 消息流规范:允许资源适配器将消息同步或异步发送到应用程序服务器中的末端,不用考虑消息的形式、语义和基础结构。
本文其余部分将关注新规范中的两个规范——生存期管理和任务管理。我们将介绍每个接口和类(与两个规范有关),为在 n 层环境中设计和实现特定的资源适配器打下基础。必须将用于符合架构的资源适配器的规范和接口标记为必须。代码示例说明了如何实现部分接口。
生存期管理规范
正如前面所述,生存期管理规范为应用程序服务器管理资源适配器实例的生存期提供了一种途径,该途径是通过启动和停止该实例达到的。在部署资源适配器期间,或在应用程序服务器启动期间,应用程序服务器通过在自己的地址空间初始化适配器来启动资源适配器。在取消部署或应用程序程序服务器关闭时,应用程序程序服务器通过通知资源适配器来关闭它。
该规范的功能是通过为应用程序服务器和资源适配器提供生存期管理接口而提供的。资源适配器要符合生存期管理规范,就必须实现 ResourceAdapter
接口,图 3 描述了它在 Connector Architecture 中所处的位置。

图 3:
资源适配器的生存期管理接口
|
ResourceAdapter
ResourceAdapter 接口允许应用程序服务器管理资源适配器的启动和停止,该接口必须作为一个 JavaBean 实现,该类的名字必须在资源适配器的部署描述符中指明。应用程序服务器通过该描述符找到并调用两个必需的方法
start 和 stop。
start
start 方发初始化资源适配器实例。它在资源适配器部署时或在应用程序服务器启动时(如果资源适配器已经部署),由应用程序服务器调用。应用程序服务器将一个参数——一个
BootstrapContext 实例——传递给资源适配器,这表明资源适配器可以方便地使用应用程序服务器。如果 start 方法抛出异常,表明有错误发生,则资源适配器的初始化不成功。
stop
stop 方法关闭资源适配器的实例,它在应用程序服务需要关闭时或在资源适配器取消部署时,由应用程序服务器调用。在调用 stop 之前,应用程序服务器必须保证停止使用该适配器的所有应用程序。这确保了在正常情况下未能关闭资源适配器不会危害单个应用程序。stop
方法抛出任何异常既不会阻止应用程序服务器关闭,也不会阻止资源适配器取消部署。
下面是一个代码示例,说明 EIS 供应商如何实现这个接口。
import javax.resource.spi;
public class MyEISResourceAdapter implements ResourceAdapter {
void start(BootstrapContext appServerContext)
throws ResourceAdapterInternalException {
/* Initialize the resource adapter instance (steps depends on specific resource adapter). */
/* Get the application server's WorkManager instance from appServerContext
so the resource adapter can submit Work to the
application server. */
WorkManager appServerWorkManager = appServerContext.getWorkManager();
/* If there is work to do, create a Work instance and submit it to the
WorkManager with the WorkManager's startwork method. */
Work job1 = new MyEISWork (...);
try {
appServerWorkManager.startWork (job1);
}catch (WorkException we) {...}
}
void stop() {
// Perform orderly shutdown of resource adapter
}
}
任务管理规范
任务管理规范允许资源适配器将任务提交给应用程序服务器执行来进行工作。资源适配器将任务提交给应用程序服务器后,该应用程序服务器会指派一个线程去运行该任务。虽然这不是一个必须的规范,但对于资源适配器允许应用程序服务器处理自己的任务这方面,有诸多的原因说明该规范是有益的。应用程序服务器可以有效地管理线程,甚至可以禁止资源适配器创建自己的线程。同样,一旦让应用服务器来管理线程,资源适配器就会变得更加轻便。
该规范的功能是通过为应用程序服务器和资源适配器提供任务管理接口和类来提供的。对资源适配器
的任务管理规范有用的类和接口包括 Work、ExecutionContext 和 WorkListener。WorkListener 是一个可选的接口,ExecutionContext
是一个可选的类。图 4 说明了这些接口和类。

图 4:
资源适配器的任务管理接口和类
|
为使资源适配器符合任务管理规范,它必须且只须实现 Work 接口。但请记住,对于资源适配器来说,这只是个可选的规范。
Work
Work 接口允许资源适配器创建任务实例并提交到应用程序服务器执行。资源适配器创建一个 Work 实例,然后提交给应用程序服务器的 WorkManager
实例,而该实例是从 BootStrapContext 实例中获得的,BootStrapContext 在资源适配器初始化时由应用程序服务器传递给
start 方法。应用程序服务器的空闲线程得到该 Work 实例并且在一个可选的上下文 ExecutionContext 中执行,ExecutionContext
由资源适配器通过 run 方法传递(Work 继承了 Runnable)。当应用程序服务器希望资源适配器释放线程时,会调用 release
方法。release 是该接口需要的唯一一个方法。Work 实例必须是线程安全(thread-safe)的,release 方法必须是可重入(re-entrant)的。run
和 release 方法均可以有同步块,但不能声明为同步方法。
下面的代码块包含了 Work 示例的实现。
import javax.resource.spi.work;
public class MyEISWork implements Work {
void run () {
...
}
void release() {
// Do clean up necessary on resource adapter so the
// application server thread can be released.
}
}
ExecutionContext
ExecutionContext 是一个类,资源适配器可以有选择地使用该类将执行上下文及 Work 实例一起传递给应用程序服务器。一经传递,应用程序服务器在执行任务时就必须使用该
ExecutionContext。要将一个特定的上下文传递到应用程序服务器,资源适配器必须在 ExecutionContext 实例中植入正确的信息。否则,将传递一个默认的实例
null 到应用程序服务器。
由于 ExecutionContext 并不是一个必须实现的接口,因而不给出示例代码。ExecutionContext 的具体实现需要继承规范说明书中的
ExecutionContext 类,并且要提供合适的执行上下文信息。需要了解更多关于 ExecutionContext 配置的信息,请参阅规范。
WorkListener
WorkListener 是一个可选接口,它允许应用程序服务器将任务的执行情况通知给资源适配器。在提交 Work 实例时,资源适配器将 WorkListener
提供给应用程序服务器。一旦传递了 WorkListener,应用程序服务器就必须通过应用程序服务器线程向 WorkListener 提供相关任务的最新情况。WorkListener
监听的通知包括接受的任务、拒绝的任务、开始的任务及结束的任务。WorkListener 的实现必须是线程安全的,并且不能对其接收的通知顺序做任何假设。
下面的代码块包含了一个 WorkListener 实现示例。
import javax.resource.spi.work;
public class MyEISWorkListener implements WorkListener
{
void workAccepted (WorkEvent e){
}
void workRejected(WorkEvent e) {
}
void workStarted(WorkEvent e) {
}
void workCompleted(WorkEvent e) {
}
}
为了避免实现所有的方法,资源适配器还可以继承 WorkAdapter。如果继承了 WorkAdapter,该实现可以只重载那些感兴趣的方法。要获得更多信息,请参见
JavaDoc
了解关于该类的信息。
结束语
在 EIS 和应用程序服务器之间的标准集成中,资源适配器是一个重要的部分。J2EE Connector Architecture 1.0 版革新了这些集成的方式——降低设计和实现的时间和成本,同时,也创建了一个可移植的、标准的解决方案。1.5
版在新规范的形式下包含了更强有力的增强特性,本文涵盖了其中的两个。最后两个规范,消息流和事务流,将在本系列的第二部分阐述。
参考资料
关于作者
Jennifer Rodoni 是 Sun 的工程师,她目前在 Market Development Engineering Organization
工作并帮助传播 Java 技术。她还是“Java Connector Architecture 介绍”一文的作者,您可以通过 jennifer.rodoni@sun.com
和她联系。