JCA (J2EE 连接器架构,java Connector Architecture)是对J2EE标准集的重要补充。因为它注重的是将Java程序连接到非Java程序和软件包中间件的开发。连接器特指基于Java连接器架构的源适配器，其在J2EE1.3规范中被定义。JCA连接器同时提供了一个重要的能力，即它使J2EE应用服务器能够集成任何使用JCA适配器的企业信息系统（EIS），大大简化了异构系统的集成。有了JCA，企业只要购买一个基于JCA规范的适配器，就可以将企业应用部署到J2EE服务器上，这样不用编写任何代码就可以实现与J2EE应用服务器的集成。JCA还提供了一个应用服务器和EIS连接的标准Java解决方案。
JCA定义了一套标准的接口，用于让连接器把兼容的应用程序服务器无缝的整合起来。同时，定义的另一套标准接口答应客户(或者应用程序服务器的应用程序主机)用一种统一的方法使用连接器。这样，连接器对于跨应用程序服务器就是可移植的，而客户程序成为很轻便的连接器。
JCA的目标在于企业应用程序集成方面，它提供的标准化体系结构让J2EE组件能够对异构EIS进行“即插即用”的访问，其中包括ERP、事务处理、老式数据库系统等。
JCA与EIS集成应用
在电子商务时代，具有因特网功能的业务应用程序，以及在因特网上集成业务处理已经成为各大厂商获得竞争优势的基础。不过在因特网经济之前，许多公司已经在业务和治理信息应用系统方面进行了大量的投入，如：
◆ 企业资源规划(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完全独立。
Sun的想法是，所有应用程序服务器厂商最终都会实现JCA服务，并且EIS厂商将实现遵守JCA规范的EIS资源适配器。通过支持JCA，所有遵守J2EE的应用程序服务器都可以保证能够处理众多和异构的EIS资源。因此，JCA既提高了J2EE应用程序开发者的生产率，同时又通过J2EE提供一个可以扩展的集成方案，减少了开发成本，并且保护了在EIS系统中的现有投资。
J2EE连接器体系结构及其元素
JCA是在一个遵守J2EE 1.3规范的应用程序服务器上实现的，同时有一个由EIS厂商提供的遵守JCA的资源适配器。这个资源适配器在应用程序服务器中是—个EIS专用的可插入J2EE组件，它提供了一个用于与基层EIS系统通信的接口。JCA定义了下列元素和服务：
◆ 系统级合同(Contract)和服务,定义了J2EE组件、应用程序服务器提供者和EIS系统之间的标准接口。这些合同和服务是由J2EE服务器提供者实现的，并且也位于EIS厂商的资源适配器中。这些合同和服务的实现在应用程序服务器与资源适配器的系统级角色和责任之间定义了一个逻辑划分(不是物理划分)。这样就使J2EE服务器和资源适配器能够彼此协作。不仅如此，它还使得一个遵守JCA规范的资源适配器可以插入到任何J2EE服务器中。
◆ JCA通用客户接口(CCI),定义J2EE组件(如jsp、EJB)可以用于连接到EIS系统或者与之交互的一个客户API。除了J2EE客户组件之外，它还答应非治理的应用程序(如Java applet和应用程序客户)使用一个遵守JCA的资源适配器与一个EIS集成。
◆ 打包和实施接口,答应各种EIS资源适配器插入J2EE应用程序中。
图2显示了J2EE连接器体系结构和访问EIS资源的组件。资源适配器很明显被看作了JCA的基础组件，因为它用作J2EE组件、应用程序服务器和EIS系统的中心连接器。
在一个使用JCA的J2EE应用程序框架中，EIS厂商提供了遵守JCA的资源适配器，并且CCI作为实现的组成部分。J2EE服务器厂商提供了支持JCA系统级合同的应用程序服务器，从而使得这些资源适配器可以插入到应用程序服务器,并且提供与基层EIS资源的连接能力。这样就使J2EE应用程序开发者可以使用CCI开发集成组件。
JCA技术规范支持两类环境，划分的基础是使用资源适配器的客户应用程序类型,这两类环境为：
◆ 治理的环境 定义一个多层、具有Web能力、基于J2EE并且访问EIS的应用程序。这个应用程序可以包含一个或者多个应用程序组件(例如EJB、JSP网页、servlet)，它们都实现在各自的容器中。在JCA的上下文环境中，这些应用程序被称为是治理的应用程序。
◆ 不治理的环境 连接器体系结构支持Applet或者Java客户应用程序这样的方式访问EIS。典型情况下这是一个两层体系结构，其中一个应用程序客户直接使用一个资源适配器库。资源适配器为客户提供了低级的事务和安全性处理。在一个JCA上下文环境中，这些应用程序称为不治理的应用程序。
资源适配器及其合同
资源适配器包含一个EIS专用的库(它可以用Java编写或者用本机接口组件)，并提供了与EIS的连接能力。在J2EE应用程序服务器中，资源适配器运行在应用程序服务器的地址空间中，并且治理着对基层EIS的连接。
JCA要求所有遵守JCA的EIS资源适配器及J2EE应用程序服务器支持系统级合同。JCA还推荐(但并不规定)所有的资源适配器都像对待它们的客户API一样支持CCI。这样就为应用程序开发、集成多个EIS提供了一个基于J2EE的解决方案，并且使EIS资源适配器“具有插入能力”，可以用于应用程序服务器中，并与所有的系统级机制协作。
一般情况下，在上下文环境中的一个合同就是在应用程序各层之间一个简单的责任陈述，这个应用程序实现了这些层之间的一个标准接口。根据JCA技术规范，资源适配器一般实现两类合同。这两类合同为：
◆ 应用程序合同
应用程序合同定义了CCI API，通过这个API，—个J2EE客户组件(例如一个EJB或者servlet)可以与基层EIS资源通信。
◆ 系统级合同
系统级合同定义了一组系统合同，可让资源适配器与应用程序服务器链接起来。JCA技术规范为资源适配器和J2EE应用程序服务器的实现定义了许多系统级合同。
连接治理
连接治理由服务合同表示，这个服务合同使—个应用程序服务器能够提供自己的服务，以生成和治理与基层EIS资源进行连接的连接缓冲池。这样就提供了一个可以扩展的连接治理设施以支持大量的客户。
事务治理
这个合同把应用程序服务器的事务处理能力扩充到了基层的EIS资源治理器。在JCA的上下文环境中，一个EIS资源治理器治理着一组共享的EIS资源以参与事务处理。一个资源治理器可以治理XA事务和本地事务两类事务。
安全性治理
这项服务让开发者可以定义应用程序服务器和EIS资源之间的安全性。有多种机制用于保护EIS不受未授权的访问及其它安全性威胁，其中包括：
1． 使用标识符、验证和授权机制；
2． 应用程序服务器和EIS资源之间实现安全通信，使用像Kerberos这样的开放网络通信安全协议，这样可以为验证和机密服务提供端对端的安全性；
3． 启用EIS专用的安全机制，J2EE服务器和EIS资源适配器之间的安全性合同，实际上把连接治理沿着安全性的方面进行了扩展。这种安全性合同提供了如下的一个EIS签发(sign-on)机制：
◆ 把连接请求从资源适配器传递到J2EE应用程序服务器，并且打开该服务器
