1定义
JCA(J2EE Connector Architecture, 也缩写为，J2C， J2CA)，是
J2EE平台上连接传统系统的一个技术规范。JCA1.0提供了出站操作，1.5提供了消息流入和
事务流入，以及生命周期管理和工作管理等系统契约。但是由于JCA尚未规定统一的
元数据获取方式，开发工具对JCA的支持还很有限。各厂商对JCA的支持也不足，因此JCA在通用性和广泛接受方面存在不足。
2性质
JCA是
J2EE体系架构的一部分，为开发人员提供了一套连接各种异类的
企业信息系统(EIS，包括ERP、
SCM、CRM等,这些系统可能是历史遗留下来非
JAVA语言编写的系统)的体系架构，对于EIS开发商而言，它们只需要开发一套基于JCA的EIS连接适配器，开发人员就能够在任何的J2EE
应用服务器中连接并使用它。基于JCA的连接适配器的实现，需要涉及J2EE中的事务管理、安全管理及连接管理等服务组件。
注意JCA也有成龙历险记之意,英文缩写.
JCA及其特点
JCA即Java Connector Architecture，或
Java连接器体系，它完善了用
J2EE构造企业应用的
技术体系。在 JCA出现之前，基于J2EE应用服务器的开发体系为企业应用各个部分提供了相应的开发工具，但是，与传统系统连接的部分仍未得到很好的解决。为了与这些EIS系统集成，各个公司为每一种系统提供了定制的开发工具。有了JCA，应用服务器厂商就能够为
Java平台组件与后端系统的连接提供一层抽象。应该说，JCA完全符合J2EE
应用服务器市场的自然发展历程。
在JCA出现之前，人们在连接EIS时面临着一系列类似的问题。
首先，每一个EIS应用有自己的
编程接口，与一个异种的EIS应用交互意味着要针对一组特定的API编程。因此，人们需要一组公共的客户端接口，以便简化客户端编程。
其次，与后端EIS系统的交互通常总是很繁忙。为了降低连接开销、提高性能，人们需要
连接池。
第三，与EIS应用的连接往往是面向
事务的。为了保证
数据完整性，人们需要内建的事务支持，以便把编程工作量降低到最少限度。 最后一点（但并非最不重要的一点）是人们迫切需要提高EIS应用和EIS客户程序集成的安全性。
仔细分析上述问题，可以发现，它们与人们以前连接数据库时面临的问题相似。对于数据库连接，由于JDBC API之类的技术被广泛采用，问题已经得到解决：作为一个程序员，你现在再也不必直接与数据库交互，而是可以通过
JDBC与数据库交互，JDBC接口对于所有流行的
数据库系统来说都是一样的；你可以方便地使用
数据库连接池，却不必自己动手实现它；你可以方便地使用
事务支持和安全集成能力，因为这些功能都是内建的。要是对于EIS应用也有类似JDBC的技术，它一定能够为你带来不少方便吧？如果你的回答是肯定的，答案就是JCA。
为了解决连接EIS时面临的各种问题，JCA提供以下功能：
连接缓冲池：EIS连接通常属于昂贵的资源，创建EIS连接需要大量的时间开销。连接池使得
应用服务器能够创建和共享EIS应用的连接，使得应用能够更高效地使用昂贵的连接资源。
事务管理：事务管理能力使得EIS应用能够获取应用服务器提供的事务环境的支持，使得服务器能够把EIS系统的事务作为一个单元管理。
安全：安全接口的实现允许应用服务器在不影响EIS特有安全机制的情况下，对整体安全性进行有效的管理。验证、授权和安全关联都属于该接口包含的范围，它们都属于为JCA
适配器和J2EE
应用服务器内建的服务。
公共的客户端接口：JCA还定义了用户级的
编程接口，称为公共客户端接口（CCI，Common Client Interface）。这个接口集在JCA 1.0中是可选的，允许EIS客户程序的开发者按照一种标准的方式，连接目标EIS系统，或与目标EIS交互（执行命令并获取结果）。
应用服务器的JCA支持
对JCA的支持来自两个方面：支持JCA的应用服务器，支持JCA的EIS应用适配器。JCA 1.0是J2EE 1.3规范的一部分，遵从J2EE 1.3规范的应用服务器必须提供合适的环境支持必要的JCA功能，包括缓冲池、
事务和集成的安全机制。表一列出了常见的
应用服务器以及它们的JCA支持情况。
表一：JCA支持现状
BEA的WebLogic Server是最早支持JCA的应用服务器之一。从2001年开始，WebLogic 6.0就内建了对JCA Beta的支持，当时的JCA 1.0规范正处于最终草案状态。经过一年的发展之后，多次获奖的WebLogic Server已经是支持JCA的最佳应用服务器之一。IBM的
WebSphere应用服务器是另一个广受欢迎并获奖的
J2EE应用服务器，2001年中期左右，它开始支持JCA。
JBoss也是值得特别指出的应用服务器，如果预算比较紧张，你就应该注意一下这个应用服务器。JBoss也支持JCA，而且它具有无可比拟的价格优势--它是免费的！
适配器厂商和产品
连接后端EIS应用时要用到JCA适配器。目前已经有许多
集成商开发了JCA适配器，如表二所示。
表二：JCA厂商与适配器
从表二可以看出，有许多厂商为同样的EIS应用提供了JCA适配器。然而，即使对于同一个EIS应用，来自不同厂商的JCA适配器可能支持不同的功能集。这是由于两个因素造成的。首先，一些规范，例如JCA 1.0中的CCI，是可选的；是否在当前发行版中包含某个功能，完全由适配器厂商决定。其次，一些重要的EIS集成功能并未包含在当前的JCA规范中；为了增强适配器，适配器厂商可能决定增加一些额外的功能。这些在规范中没有定义的功能将在稍后详细讨论。
由于这些在JCA规范中没有定义的功能可能是很重要的，许多厂商在这个问题上采取了更实在的策略，走到了规范之前；即使面临着非标准化的风险，为了提供额外的功能，它们也会为适配器加上一些辅助特性。
Insevo为许多EIS应用提供了JCA适配器，包括SAP、
PeopleSoft、Edwards和Siebal。这些适配器除了支持JCA定义的CCI之外，还支持一种基于XML的接口。它们既支持客户程序和EIS应用之间的
同步通信，也支持
异步通信。另外，它们还支持双向通信，而不是JCA定义的单向通信。这些额外的功能使得Insevo的适配器不仅适用于应用集成，而且适用于过程集成（Process Integration）；另外，这些附加的功能已经被作为JCA 2.0规范的一部分考虑。因此，从某种意义上来说，Insevo的适配器是一个超前JCA规范的版本。尽管额外增加的功能不遵从当前的JCA规范，但如果你确实需要它们，还有比这更好的事情吗？
Resource Adapters的RAi连接器是另一组采取此种策略的JCA适配器，也包含了一些预期将在JCA 2.0规范中定义的功能。RAi支持输入（Inbound）连接和输出（Outbound）连接，支持同步和
异步通信模式。RAi连接器除了支持CCI之外，还支持一组基于XML的API和XML
元数据，并提供了日志和监视工具，为实际工作带来了巨大的方便。
除此之外，Attunity和Insevo还提供了许多数据源适配器和传统适配器，这些适配器往往只需单向的
同步通信。一些数据源和传统适配器不支持
事务之类的JCA功能，因此，它们并不提供对JCA的完整支持。
与其他类型的适配器比较
除了JCA适配器，还有其他一些根据不同需求而开发的适配器类型，其中之一是
Web服务适配器，它是一种重要的新适配器类型，正在迅速地获得人们的认可。另外，在JCA出现之前就有许多非标准的适配器被开发出来，因此这些适配器拥有更长的发展和成熟时间。
Web服务适配器
当前，企业应用的平台有各种各样的类型，当然有一部分是以
Java为基础的。在开发各类系统的过程中，企业投入了大量的资源，当然不肯轻言放弃。问题在于，如何才能在不增加额外投资的情况下，让这些异种的系统能够协作运行？两种流行的技术使这一切成为可能：第一是HTTP，第二是XML。这两者是每一种平台上都使用的技术，非常适合于异种平台的集成。Web服务规范就建立在这两种简单但关键的技术的基础上。尽管详细讨论Web服务已经超出了本文的范围，但从下面的简要说明可以看出Web服务的主要特点： 网管网
HTTP/HTTPS协议：Web服务事实上的
通信协议。
SOAP：基于WSDL的Web服务和HTTP/HTTPS通信协议之间的绑定协议。
Web服务仍未提供任何
QoS机制，因此是一种
异步协议。对于异种系统的宽松结合来说，它是一种很合适的协议。
Web服务和JCA提供的功能互相完善了对方。如果这两种技术最终把它们的特点合并了起来，我们不应该感到奇怪。实际上，一些厂商已经向这个方向发展。例如，Attunity和Sirvisetti等厂商已经在它们的JCA适配器中提供了对Web服务的支持。
非标准化的适配器
在JCA出现之前，一些中立的厂商，例如webMethods和
TIBCO等，推出集成适配器已有数年。这些适配器一般具有非标准化的API，有时它们不能从集成软件包分开。尽管如此，这些适配器已经经过多年实践的检验，比JCA适配器涵盖范围更广泛的EIS。特别地，webMethods Enterprise Adapter和B2B适配器拥有迄今为止最广泛的覆盖面。webMethods拥有的适配器多达60个以上，这些适配器还不支持JCA，但webMthods正在快速地向支持JCA的方向发展。
JCA的优点和不足
JCA的优点很明显。它为EIS厂商提供了一种按照开放的产业标准定义EIS接口的途径。通过使用公共的可调用接口以及继承JCA提供的
QoS机制，程序员能够在不牺牲性能和系统完整性的前提下，简化EIS的集成工作。
JCA的局限不是显而易见，但不容忽视。和所有其他新技术一样，JCA第一个版本的不成熟性往往成为最令人担心的问题。另外，JCA适配器应该是可在
应用服务器之间移植的；然而，就目前的情况来看，对于你正在使用的应用服务器来说这一判断未必正确，因为适配器对某种应用服务器的支持情况由适配器厂商根据个案进行测试和发布。此外，JCA还有其他一些已知的局限，其中有些局限有望在JCA标准的下一个版本中得到解决，其中包括：
异步消息传输：调用EIS应用时，JCA 1.0采取同步消息传输方式；它不能处理来自EIS应用的异步消息或向EIS应用传递异步消息。如果要异步传递消息，就要在使用JCA时结合JMS（Java Message Service）或其他队列服务，或者选择使用JCA适配器中内建的非标准化异步消息支持。
长时间运行的
事务：这是一种运行时间可能达到数天甚至
3应用
JCA与EIS集成应用
![JCA 了解-LMLPHP]( "JCA 了解-LMLPHP")
在电子商务时代，具有因特网功能的业务应用程序，以及在因特网上集成业务处理已经成为各大厂商获得竞争优势的基础。不过在 因特网经济之前，许多公司已经在业务和管理信息应用系统方面进行了大量的投入，如：
◆ 企业资源规划(Enterprise Resource Planning，ERP)应用，如SAP R/3和 BAAN。
◆ 客户关系管理(Customer Relationship Management，CRM)应用，如 Siebel和Clarify。
◆ 数据库应用程序，如 DB2和 Sybase。
◆ 大型 事务处理应用，如 CICS。
◆ 老式 数据库系统，如 IBM公司的IMS。
这些系统一般称为 企业信息系统（EIS ，Enterprise Information Systems)。EIS为整个企业提供信息基础设施和服务。这些信息的形式可能是—个数据库中的一组记录、一个ERP中的 业务对象、一个CRM系统的工作流对象，或者是一个事务处理应用程序中的事务程序。
在连接器出现之前，一些应用程序 服务器厂商为集成EIS系统提供了各种可自定义的适配器。这些适配器还提供了自定义的本机接口。但这些内容很复杂，不易理解，并且因为它们试图支持一种标准体系结构而受到限制。其中一些具体的限制情况如下：
◆ EIS的应用程序编程本身是专用的，而应用系统的多样性表明没有适用于与 开放式体系结构集成的通用接口机制。
◆ 大型Web应用程序要求在客户、连接管理等方面具有 高可用性和 可扩展性。传统情况下，客户的数量及他们的活动连接在—个EIS中代价是昂贵的，并且自定义的适配器也缺乏应用程序服务器提供的连接管理机制。
◆ 管理众多后端应用的安全性和 分布式事务极其复杂并且缺乏可靠的机制。这意味着现在没有标准的基础设施解决方案来提供一个比较中性的安全性机制，也没有对众多EIS资源管理器的通用事务管理支持。这种情况对于EAI实现会带来巨大的问题。
考虑到上述难点，Su公司发布了JCA，以便为 J2EE服务器与异构EIS资源的集成提供一个标准的体系结构。其主要目标是，通过在一个一致的J2EE环境中定义一个通用的API及一组通用的服务来简化开发过程。JCA为开发者提供了一种容易的办法，以便把EIS与J2EE系统平台组件无缝地集成起来。图1显示了一个带有JCA的组件和EIS集成应用的结构图。
从图1可看出，如果需要把一个基于J2EE的应用程序与一个现有的EIS集成起来，所需做的就是把适当的EIS连接器(一个遵守JCA规范的资源适配器，即Resource-adapter)安装到应用程序服务器上。安装了这个适配器之后，我们可以开发J2EE组件，以便使用CCI（ Common Client Interface，通用客户接口）API与EIS接口。采用的方式与使用JDBC与关系数据库接口相同。也就是说，通过采用非EIS专门化的编程而简化开发，并且所做配置与后端EIS完全独立。
![JCA 了解-LMLPHP]( "JCA 了解-LMLPHP")
图一
图-1
Sun的想法是，所有应用程序服务器厂商最终都会实现JCA服务，并且EIS厂商将实现遵守JCA规范的EIS资源适配器。通过支持JCA，所有遵守 J2EE的应用程序服务器都可以保证能够处理众多和异构的EIS资源。因此，JCA既提高了J2EE应用程序开发者的生产率，同时又通过J2EE提供一个可以扩展的集成方案，减少了 开发成本，并且保护了在EIS系统中的现有投资。
从版本2.5开始，spring还支持基于JCA的MessageListener容器。 JmsMessageEndpointManager将尝试从提供程序的ResourceAdapter类名称自动确定ActivationSpec类名。 因此，通常可以提供Spring的通用JmsActivationSpecConfig，如下例所示。
<bean class="org.springframework.jms.listener.endpoint.JmsMessageEndpointManager">
<property name="resourceAdapter" ref="resourceAdapter"/>
<property name="activationSpecConfig">
<bean class="org.springframework.jms.listener.endpoint.JmsActivationSpecConfig">
<property name="destinationName" value="myQueue"/>
</bean>
</property>
<property name="messageListener" ref="myMessageListener"/>
</bean>
或者，您可以使用给定的ActivationSpec对象设置JmsMessageEndpointManager。 ActivationSpec对象也可能来自JNDI查找（使用<jee：jndi-lookup>）。
<bean class="org.springframework.jms.listener.endpoint.JmsMessageEndpointManager">
<property name="resourceAdapter" ref="resourceAdapter"/>
<property name="activationSpec">
<bean class="org.apache.activemq.ra.ActiveMQActivationSpec">
<property name="destination" value="myQueue"/>
<property name="destinationType" value="javax.jms.Queue"/>
</bean>
</property>
<property name="messageListener" ref="myMessageListener"/>
</bean>
使用Spring的ResourceAdapterFactoryBean，可以在本地配置目标ResourceAdapter，如以下示例所示。
<bean id="resourceAdapter" class="org.springframework.jca.support.ResourceAdapterFactoryBean">
<property name="resourceAdapter">
<bean class="org.apache.activemq.ra.ActiveMQResourceAdapter">
<property name="serverUrl" value="tcp://localhost:61616"/>
</bean>
</property>
<property name="workManager">
<bean class="org.springframework.jca.work.SimpleTaskWorkManager"/>
</property>
</bean>
指定的WorkManager也可能指向环境特定的线程池 - 通常通过SimpleTaskWorkManager的“asyncTaskExecutor”属性。考虑为您的所有ResourceAdapter实例定义一个共享线程池，如果您恰好使用多个适配器。
在某些环境（例如WebLogic 9或更高版本）中，可以从JNDI（使用<jee：jndi-lookup>）获取整个ResourceAdapter对象。然后，基于Spring的消息侦听器可以与服务器托管的ResourceAdapter进行交互，也可以使用服务器内置的WorkManager。
有关详细信息，请参阅JmsMessageEndpointManager，JmsActivationSpecConfig和ResourceAdapterFactoryBean的javadoc。
Spring还提供了一个通用的JCA消息端点管理器，它不绑定到JMS：org.springframework.jca.endpoint.GenericMessageEndpointManager。该组件允许使用任何消息侦听器类型（例如CCI MessageListener）和任何提供者特定的ActivationSpec对象。查看您的JCA提供商的文档，了解连接器的实际功能，并参考“GenericMessageEndpointManager的javadoc”，了解特定于Spring的配置详细信息。