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应用程序服务器，并且打开该服务器的验证和授权服务；
◆ 在安全性上下文环境中，把安全机密凭证信息从应用程序服务器传递到资源适配器。
通用客户接口(CCI)
CCI提供了一个简单的方式来解决编写基层EIS资源更复杂的、Java接口的问题。出现了CCI之后，这个问题已经成为Java开发者和EIS厂商之间都知道的“集成问题”。通过在资源适配器中实现CCI，EIS厂商可以提供对它们的EIS产品的一个Java接口，它将在任何遵守J2EE 1.3规范的应用程序服务器上运行。
CCI为J2EE应用程序组件定义了一个独立于EIS的客户API，它为运行与EIS相关的查询和EIS事务处理定义了远程功能调用接口，还可以用于获得结果。
CCI为J2EE应用程序服务器提供了功能调用，它通过一个JCA资源适配器提供的组件，生成和管理与一个EIS资源的连接，执行与一个EIS资源有关的操作。
JCA技术规范推荐，CCI应该形成更丰富功能的，并且成为一个由EIS资源适配器厂商提供的更丰富的编程模型，而不是成为多数应用程序开发者使用的API。JCA技术规范还推荐，所有EIS资源适配器应把CCI作为它们的客户API实现，同时它仍然要求这些资源适配器提供与J2EE应用程序服务器相关的系统合同。需要注意的是，一个资源适配器还可以选择与CCI不同的附加客户API，类似于在JDBC实现中可以使用厂商提供的客户API一样。使用CCI极大地提高了开发者的生产率，减少了系统集成的成本，使代码具有可移植性，应用程序可以扩展,以及良好的可维护性。
CCI被分成四部分（见表1）。所有的具体CCI类和接口在javax.resource.cci程序包都可以方便地找到。
表1 CCI接口与类
<ccid_nobr>
| 接口类型 | 名称 |
| 与连接有关的接口，描述一个工厂类连接和一个应用程序类连接。 | javax.resource.cci.ConnectionFactory javax.resource.cci.Connection javax.resource.cci.ConnectionSpec javax.resource.cci.LocalTransaction |
| 与交互有关的接口，能使组件驱动一个与EIS实例的交互。 | javax.resource.cci.Interaction javax.resource.cci.InteractionSpec |
| 与数据表现有关的接口，用来描述与EIS实例交互中涉及到的数据结构。 | javax.resource.cci.RecordFactory javax.resource.cci.Record javax.resource.cci.MappedRecord javax.resource.cci.IndexedRecord javax.resource.cci.IndexedRecord javax.resource.cci.ResultSet java.sql.ResultSetMetaData |
| 与元数据有关的接口，提供了一个资源适配器与EIS连接的基本的元信息。 | javax.resource.cci.ConnectionMetaData javax.resource.cci.ResourceAdapterMetaData |
资源适配器的打包和实施
JCA定义了打包和实施接口，所以各种资源适配器可以很容易地以一种模块化和可移植的方式，插入一个遵守J2EE规范的应用程序服务器。这种模块称为资源适配器模块，它与J2EE应用程序模块相似，可以包括Web和EJB组件。
图3显示出一个资源适配器模块的打包和实施过程，这个模块将用于连接一个J2EE应用程序和一个EIS资源。典型情况下这个过程与在一个J2EE容器中实施EJB或Web组件相似。一个资源模块的打包和实施过程如下：
◆ EIS资源适配器提供者(通常是EIS厂商)开发一组Java接口和实用程序类作为资源适配器实现的组成部分。这些Java类实现了JCA合同和资源适配器提供的EIS专门功能。
◆ Java类及资源适配器提供者提供的本机库(如果可用)被打包，同时还有一个实施描述符，构成一个资源适配器模块(RAR文件)，与其它J2EE组件实施描述符类似, 资源适配器模块的实施描述符定义了资源适配器提供者与负责资源适配器的实施者之间的服务合同属性。
◆ 在实施过程中，应用程序实施者在一个应用程序服务器上安装一个资源适配器模块，然后利用J2EE应用程序服务器进行配置，并且确定基层EIS环境目标。
一个应用程序的资源适配器模块打包和实施过程类似于其它J2EE打包和实施过程，特别是与Web和EJB组件相似。但是，在打包和实施资源适配器中涉及到的角色和责任与其它J2EE组件的相应过程稍有不同。资源适配器打包的一个EIS资源适配器就是一个包含在一个RAR档案文件中的J2EE服务器组件。它可以在一个目录中准备一个或者多个资源适配器，并且把它们打包成.rar文件。