JCA——一个名不见经传却重要的JavaEE规范

JCA（Java EE Connector Architecture）规范能够说是JavaEE规范集合里最“默默无闻”的，在JavaEE1.3规范发布时就加入了，比如今重要成员JPA, CDI等都早了不少。从应用开发角度来看，开发一个很普通的Web应用程序，只有几个页面，使用Servlet就能够完成，用JDBC API保存信息到数据库中，部署这个应用到JavaEE应用服务器中时，就会用到JCA技术。这个很简单的应用程序只用了庞大的JavaEE规范集30多项中的Servlet和JCA两项规范而已。那么，如此重要的规范，为什么不多人知晓呢，本文就解释一些其中的原委。

JCA原意是Java企业版本链接器体系结构，这样一个生涩的词语不能很好的描述它的功能。简单来讲，这个规范的做用就是定义如何链接JavaEE应用服务器和外部的信息系统，这类系统包括但不局限于数据库，消息中间件，分布式缓存系统，ERP/CRM为表明的企业软件系统，Tuxedo等事务/消息中间件等。咱们知道JavaEE中的Enterprise是企业的含义，这套规范集的设计目标一开始就定义了是为企业应用软件而设计的。在一个企业领域的范畴内，能够运行着不少应用软件，若是一套软件是用JavaEE规范技术开发并部署运行在应用服务器中，而且它须要和其余应用系统进行信息交互， JCA就能够发挥强大的功能。

JCA产生于J2EE最为繁荣辉煌的1.3版本时代，JCA 1.0版本由JSR16提出，当时J2EE整个技术栈已经比较完备，一个需求产生了：如何把JDBC/JMS等链接管理统一块儿来？与此同时，BEA公司的Tuxedo产品也面临和J2EE进行集成的问题。JCA1.0版本定义了链接管理，以及在链接之上如何管理事务和安全，但只考虑了Outbound(出站)单向请求的需求。

接下来J2EE出现了群雄混战的局面，更多的产商对JCA规范产生了兴趣，包括众多的EAI集成软件厂商和ERP巨头如SAP等等，JCA1.5规范在2003年完成，这个版本就很完备了，加入了Inbound(入站)消息流向，定义了WorkManager等重要内容。直到今日，不少Resource Adapter也只支持1.5规范。

在版本5时J2EE从新命名为JavaEE，这个大版本主要聚焦在JPA和EJB3，JCA没有变更。JavaEE6版本发布时JCA升级到1.6，JSR编号是322，除了功能完善之外，主要是加入对Annotation的支持，今后能够选用XML或者Annotation描述JCA的相关实现类。

去年发布了JavaEE7，JCA做了微小的修改，升级到1.7，但仍是沿用JSR322规范编号。因此咱们如今看到的最新支持JavaEE7的应用服务器中的JCA规范是1.7版本。在最新的Wildfly（原JBossAS）应用服务器中，数据库链接池，JMS链接，接受消息MDB信息等配置信息，都是IronJacamar(JBoss开源组织JCA实现)能够识别并处理的配置选项。

让咱们看一下标准的JCA体系结构图。

四个部分是应用服务器(Application Server)，应用组件(Application Component), 资源适配器(Resource Adapter)和企业信息系统(Enterprise Information System)。

咱们通常开发的应用是将War部署在WebServer中，分别对应于应用组件和应用服务器。企业信息系统是能够独立运行的应用系统，好比数据库，ERP等，资源适配器是为了和企业信息系统进行链接而设计的链接适配器软件，能够把JavaEE应用服务器和外部应用系统链接起来，并提供资源服务给应用组件来使用。

这里你们可能会产生疑问，通常应用能够经过JDBC或者JMS接口得到链接，为何还要定义JCA规范接口呢。答案简单说就是为了统一接入层的API和被容器管理。应用服务器中的资源池容器（能够称为JCA容器）须要管理全部的外部信息系统链接，统一调度给应用程序使用。对于应用开发人员来讲，使用这些资源就很简单，只须要经过JNDI就能够获取到可用资源，获得引用并进行调用，使用完毕后关闭，容器会进行回收，放回可用资源池中供后续使用。全部这样的资源都会被资源容器识别并管理，JCA的规范就定义了这样的接口。咱们看到在JCA Javadoc中定义的很清楚，spi包里面的就是让资源适配器实现的接口集合。

让咱们稍微深刻代码看重要接口：

入口点是ResourceAdapter，这个接口表明了资源管理器的实例，方法定义了实例的生命期回调方法，其中start方法的参数实现了BootstrapContext接口，能够把应用服务器的服务能力做为上下文传入。

经过配置信息，能够得到Outbound信息入口接口ManagedConnectionFactory，经过这个接口的方法，能够得到被管理的链接ManagedConnection。咱们要理解在JavaEE的世界里，几乎任何资源都是被管理的，或者能够当作是逻辑意义上的资源。经过JNDI获取到的接口实现类，在不一样应用场景中，后台程序已经作了不少工做：有可能加入了丰富功能，也有多是只是一个空的代理引用，等须要时再去访问真正的对象，达到节约占用资源的目的。经过ManagedConnection接口，应用能够进一步得到实现业务接口的对象，从而和外部信息系统进行交互。

对于Inbound来讲，开发人员经过描述文件或者Activation注解定义，编写MDB来接受外部系统传入的消息。这里就引出一个颇有趣的话题，咱们学习JavaEE技术，特别是用到EJB时，规范有一个要求是不能建立线程，由于这样会让线程资源很难被容器全面管理。但一个常见的需求就是打开一个端口来接收外部的消息或者调用请求。通常实现方式会建立线程来完成端口侦听和接收消息，这样就违反了JavaEE规范要求。那么面对这样的需求该怎么作？这时WorkManager就发挥了它的做用。

WorkManager调度Work，而Work扩展了Runnable接口，这样能够把须要执行独立线程的代码逻辑封装到Work的实现类中，提交给WorkManager去调度执行。通常来讲应用服务器会维护线程池来合理分配可用的线程资源，进行高效调度管理。这样相似于打开一个端口去接收消息的需求就能够被知足，绝大多数JMS实现的资源适配器就是这样作的。

说了这么多，可能你们以为也不过如此，以上的需求不用JCA彷佛也能实现，为何要搞得很复杂来使用JCA呢？这样就引出JavaEE核心思想--事务性。

给企业开发应用，事务是一个极其重要的商业因素。咱们知道财务会计核心准则之一就是有借必有贷，借贷必相等，这句话就充分体现了事务思想。企业的业务，流程，事件处理，都是有必定的管理规定的，每一个涉及商业逻辑的业务系统，都会充分考虑知足业务事务一致性的需求。除了刚才说的财务系统之外，其余的企业软件系统也须要对事务有良好的支持，好比请假被批准了，同时可用年假记录数额也须要减小。整个系统内完成这个业务事务以后，仍是处于一个“平衡”的状态，能够说企业应用的绝大多数软件都须要事务支持。

基于JavaEE开发的应用，通常来讲也须要支持事务，同时和外部系统配合来支持完成一项事务过程。咱们知道数据库，JMS服务器等都是支持事务的，和它们的链接中会带有事务上下文信息，这样就能够经过必定的契约（接口），来进行事务信息的传递。在JavaEE的设计思路中，能够经过声明式编程和对象功能增强来屏蔽必定程度的事务处理复杂性，这部分知识在讲述EJB核心思想的书籍里都有论述。简单来讲是对象经过容器内部传递上下文(Context)信息来屏蔽一部分业务开发人员处理事务细节的繁杂编程工做。

这个上下文同时还能够传递安全相关信息，也就是JavaEE的安全相关的内容。JCA一样对链接管理的安全性进行了规范定义，从而能够方便的对应用服务器和外部系统的安全身份，受权信息进行管理和映射。在JCA1.6之后，对Inbound的事务和安全的定义也完善了。

既然这么好，那咱们把JCA彻底用在Java业务软件中如何？等等，JCA也有一些在技术选型上须要考量的地方。

首先是事务支持，咱们知道事务能够说和系统可扩展性是冤家对头。事务过程当中必然带有状态，而远程调用服务/可扩展的设计原则之一就是无状态的，这个矛盾没法避免。那么在不须要事务支持或者要求不高的业务范畴，好比论坛，博客等，咱们能够选择取消事务支持来提升系统效率。其实这一点也是JavaEE技术在互联网领域面临尴尬的缘由之一。

其次，JCA的关注点主要在链接管理上，规范并无定义拿到链接后如何获取业务对象引用，以及业务对象接口的宽泛程度等内容。因此对于复杂的业务系统来讲，资源适配器中绝大多数配置项都是私有的，没法所有规范化， 引入JCA对实际应用帮助有限。

第三，链接池是高性能业务系统的核心组件之一，数据库链接池的管理是运维工做的主要内容。但链接池功能众多，配置繁杂，每一个应用服务器实现都不一致，而这部份内容并无在规范中定义。因此应用在不一样服务器间迁移变得很困难，光链接池配置就须要作不少工做。

那么什么场景适合使用呢？若是使用兼容JavaEE的应用服务器来开发，好比JBossAS(WildFly,Redhat JBoss EAP)，Weblogic，Glassfish，Webshpere等，那么已经用上JCA。此外对须要支持分布式事务的软件系统，进行二次开发，JCA都是良好的技术选择。典型例子有各类MQ/JMS具有事务能力的系统，和Tuxedo链接的WTC资源适配器等。

还有一个更重要因素，就是JCA规范是系统间集成技术经验的一种体现，任何开发者基于JavaEE开发，须要和外部系统交互，在设计/编码/上线运营/系统成熟后会发现和目前JCA定义的体系架构会很是类似。学习JCA规范就可以快速掌握这套架构模型，这就是知识凝聚的力量。