亚信WEB中间件团队 zhangzhende
目录
Jakarta 连接器规范
背景
在连接器出现之前,应用程序服务器厂商为集成EIS系统提供了各种可自定义的适配器。这些适配器还提供了自定义的本机接口。但这些内容很复杂,不易理解,并且他们的统一支持标准还受到一些限制。其中一些具体的限制情况如下:
1、EIS的应用程序编程本身是专用的,而应用系统又是多样的,这意味着没有适用于与开放式体系结构集成的通用接口机制。
2、大型Web应用程序要求在客户、连接管理等方面具有高可用性和可扩展性。通常情况下,在—个EIS中维护客户的数量及他们的活动连接的代价是昂贵的,并且自定义的适配器也缺乏应用程序服务器提供的连接管理机制。
3、管理众多后端应用的安全性和分布式事务极其复杂,也缺乏可靠的机制。这意味着现在没有标准的基础设施解决方案,用来提供一个比较中性的安全性机制,也没有对众多EIS资源管理器的通用事务管理支持。这种情况会给EAI的实现带来巨大的问题。
针对上述难点, JCA架构的出现,为J2EE服务器与异构EIS资源的集成提供一个标准的体系结构。其主要目标是,通过在一个一致的Jakarta EE环境中定义一个通用的API及一组通用的服务来简化开发过程。JCA为开发者提供了一种容易的办法,以便把EIS与Jakarta EE系统平台组件无缝地集成起来
优点
Jakarta连接器架构为众多应用服务和EIS之间的双向连接问题提供了Java解决方案。通过使用Jakarta连接器,EIS供应商不再需要为每个应用服务定制产品。符合Jakarta连接器规范的应用服务供应商,如果想扩展功能以支持与新EIS的连接,也不需要添加自定义代码。这样就大大简化了异构系统的集成。
应用服务供应商只扩展其系统一次,以支持Jakarta Connectors,然后可以确保连接到多个EIS。同样,EIS供应商提供了一个标准的资源适配器,它能够插入任何支持Jakarta Connectors的应用服务。
标准约定
Jakarta连接器定义了一套应用服务和EIS之间标准约定:
- Jakarta 连接器定义了一个标准的架构,用于连接Jakarta EE平台和各种企业信息系统(EIS)。企业信息系统包括像 企业资源规划(Enterprise Resource Planning ERP),大型机的事务处理(transaction processing)和数据库系统(database systems)。
- Jakarta 连接器定义了一系列可拓展的、安全的、事务的机制,从而能够让企业信息系统集成应用服务和企业应用。
- Jakarta连接器也定义了一个通用客户端接口(Common Client Interface ,CCI),用以访问企业信息系统。通用客户端接口定义了一套客户端API,用以各种企业信息系统相互之间互相调用。
- Jakarta连接器能够让企业信息提供商来提供标准的资源适配器给企业信息系统。资源适配器是一个系统级别的软件驱动,java应用用它来连接企业信息系统。资源适配器添加到应用服务中,提供了企业信息系统、应用服务、企业应用之间的连通性。
- 一个企业信息系统提供商提供一个标准的资源适配器,那么他就可以适配任何一个支持连接器架构的应用服务
资源适配器ResourceAdapter
资源适配器是可部署的 Jakarta EE 组件,提供使用 Jakarta Connectors 规范的 Jakarta EE 应用和企业信息系统(EIS)之间的通信
一个ResourceAdapter可以提供不同类型的Connection:
- Outbound communication(由JavaEE应用服务器创建到EIS的连接):资源适配器允许应用程序连接到EIS系统并执行工作。所有通信都由应用程序启动。在这种情况下,资源适配器充当连接到EIS的依赖库,并在应用程序线程的上下文中执行
- Inbound communication(由EIS创建到JavaEE应用服务器的连接):资源适配器允许EIS调用应用程序组件并执行工作。所有通信均由EIS发起。资源适配器可以从应用服务器请求线程或创建自己的线程。
- Bi-directional communication(双工通信连接):资源适配器同时支持出站和入站通信。
资源适配器启动过程
1、应用服务器实例化ResourceAdapter,并根据部署描述符设置相应的属性。(每次部署只允许实例化一个ResourceAdapter对象)
2、应用服务器调用ResourceAdapter的start方法,在参数中传入BootstrapContext对象,BootstrapContext对象向ResourceAdapter暴露应用服务器的组件服务,比如WorkManager,ResourceAdapter可以使用这些组件。
资源适配器停止过程
ResourceAdapter的停止分为两个阶段。
阶段一: 在停止Resource之前(调用ResourceAdapter的stop方法),应用服务器必须保证所有使用此ResourceAdapter资源的相关应用都已经停止,包括停止Message endpoints。阶段一用于保证应用不再会使用到ResourceAdapter实例,这意味着所有相关应用的活动和事务活动都已经完成。因此阶段一保证了即使下一阶段中Resource Adapter不能正常停止,ResourceAdapter也不再会被使用。
阶段二: 应用服务器调用ResourceAdapter的stop方法,ResourceAdapter将在stop方法中执行停止操作以便被卸载。停止的操作包括以下几个方面:
1、关闭网络端口(Outbound and Inbound)
2、释放线程以及活动的Work任务。
3、允许ResourceAdapter内部正在 处理的事务完成提交,并将缓存的数据刷出到EIS中。
stop方法抛出任何异常都不会阻止应用服务器销毁ResourceAdapter
资源适配器实现
1.ResourceAdapter实现类由部署描述符或者@Connector注解来指定,
2.ResourceAdapter实现类必须是一个JavaBean,部署的时候Deployer需要对它配置并设置相应的属性。
ManagedConnectionFactory
当ManagedConnectionFactory创建的时候,它可以继承一些ResourceAdapter的配置,并覆盖一些默认的配置参数。出站通信由应用来发起,并且与EIS通信的过程在应用的上下文中执行,ResourceAdapter也可以另起一个线程来处理通信过程。
在使用ManagedConnectionFactory之前,应用服务器必须将它与ResourceAdapter实例关联起来(通过调用ManagedConnectionFactory.setResourceAdapter方法)ManagedConnectionFactory.setResourceAdapter方法只允许调用一次,并且在ManagedConnectionFactory 的生命周期当中不能改变这个关联关系。
ActivationSpec
在初始化的时候,ActivationSpec也可以继承来自ResourceAdapter的配置。
入站通信由EIS来发起,通信过程在ResourceAdapter线程上下文中执行,没有应用的线程参与、Resource Adapter可以使用Work Management contract接口来申请线程来处理入站通信。
同ManagedConnectionFactory类似,使用ActivationSpec时,应用服务器必须将它与ResourceAdapter关联,ActivationSpec生命周期过程中不允许改变这个关联关系。
连接管理架构
1.应用服务从部署描述符和注解中获取配置信息来配置ResourceAdapter实例,ResourceAdapter提供Connection和ConnectionFactory。
2.应用组件通过jndi中的lookup操作来获取一个 Connection Factory,并通过这个Connection Factory获取一个连接到EIS的Connection实例。Connection Factory将connection 的创建请求委托给ConnectionManager来处理 。
3.ConnectionManager实例接收到从Connection Factory过来的 Connection创建请求时,它从jndi上去获取应用服务器提供的连接池资源,如果连接池上没有能够满足相应请求的连接的话,应用服务器使用ManagedConnectionFactory接口(由ResourceAdapter来实现)来创建一个新的连接到EIS的物理连接。并将它加入到这个连接池当中。
jakarta Connector 规范文档: