java 2企业版(j2ee)连接器架构(jca)是对j2ee标准集的重要的补充. 它注重的是用于将java程序连接到非java程序和软件包的中间件的开发.jca是由sun公司领导的java标准化组织开发的.jca 目前还是在最后的草案阶段, 它定于2001年年底发布并且将成为j2ee 1.3 的一部分.jca 提供了许多值得注意的好处, 但是直接的jca编程并不是每个人都能学会.
　　
　　jca包括三个关键的元素:
　　jca 资源适配器
　　系统介面
　　通用客户介面(cci common client interface,目前还是可选内容)
　　
　　jca 是软件工业界在应用程序集成领域建立标准进行的第一步工作,而以前要做到这一点基本上是通过专有的中间件完成的.这是迈向正确方向的第一步, 因为应用程序的集成已经不仅成为了业界领袖面临的首要问题而且也让大多数主流软件商无法回避.
　　
　　jca 资源适配器是定制的java程序用来实现对特定的外部程序的连接(无论它是一个以前遗留下来的程序,还是购买的程序).一个遵循jca标准的资源适配器都必须支持jca系统界面,以便通过连接缓冲进行性能优化并支持自动的安全签名.jca还提供一组界面支持事务管理(虽然实际上在资源适配器中对分布式事务的支持是可选的).
　　
　　一个全功能的资源适配器允许连接到外部(目标)程序来完成以下功能:
　　
　　使得目标程序能够参与与其它应用程序和数据库之间分布式的基于xa的事务过程.
　　
　　能够在不牺牲应用程序的安全级别的前提下掩盖外部平台的安全细节.
　　
　　能够增加应用程序的可伸缩性.
　　
　　要支持jca的事务和安全功能需要目标程序通过资源适配器为程序的访问暴露足够的事务和安全界面.过时的应用程序或者是应用程序平台如果不经过加强则有可能只能部分的符合jca标准. 许多的适配软件很可能只能支持最小的"无事务"选项而且可能只能拥有一个部分支持目标环境的安全结构的安全界面.
　　
　　最小化的资源适配器也许只能改进那些在jca出现以前由不同的销售商开发的非标准适配器.在目前的开发阶段,jca与更现代的和更开放的目标应用程序或环境结合的时候最能体会它的威力.到2004年,在软件集成项目中少于百分之三十的软件包和遗留下来的适配软件将使用jca, 而且拥有完全功能的将少于百分之十--包括对事务的支持,完全的安全性,以及cci(0.7 的可能性).
　　
　　
　　
　　资源适配器用系统界面来与底层的j2ee应用服务器交互.资源适配器通过jca系统界面将繁杂的细节处理过程交给底层的应用服务器,从而满足可伸缩性,集成性,和安全性方面的要求,上层的应用程序假设底层的应用服务器知道如何处理对jca系统界面调用.因此,应用服务器销售商声明支持jca,其本身并不保证能够提供对应用程序集成的支持除非销售商还提供(通过合作或是独立开发)预先开发的jca资源适配器.
　　
　　jca 通用客户界面是调用程序(用户程序或是集成中间件)使用的一套应用编程界面(api).jca cci被用做对资源适配器的标准访问过程,不管实际的目标程序或是环境是如何工作的.因为所有的资源适配器支持相同的一套aip,所有的调用程序和外界程序间的交互过程就形成了标准.但是对cci支持在jca 1.0中是可迁的.许多的资源适配器会暴露非标准的但是满足特定目标或平台访问方式的客户界面.
　　
　　cci与企业版javabeans(ejb)的调用界面是不同的,而且jca 资源适配器的封装方式也不尽相同;jca的java编译文件(jar)与ejb jar文件有不同的设计方式.所以cci代表了j2ee范围内一个新的专门的编程模型;它是复杂的而且需要专门的技术知识.但是实际使用cci的开发者的大部分很可能将是工具软件销售商(例如webgain和ibm visual age)以及集成中间件生产商(例如webmethods和tibco software),而不是企业应用开发者.
　　
　　要支持jca, 集成中间件销售商一般不得不采用一整套j2ee平台,就象jca设计需要的那样(也就是"managed"选项).但它们中的大多数还没有这样的能力,所以可能只是实现jca标准的功能弱一些的"unmanaged"选项.这种情况很可能拖延集成中间件销售商对jca全部标准的采用,因而也就会拖延对整个jca的采用.到2004年,所有主导的集成中间件销售商都将通过独立开发或是合作在它们的产品里捆绑进一个j2ee应用服务器(0.7的可能性).
　　
　　jca 对 web服务(web services)
　　资源适配器的代码是复杂的,需要对目标平台内部结构的深刻了解和程序设计方面高级的知识.因此,外部应用程序(而不是调用程序的开发者)销售商将开发大部分的资源适配器.所以,套装软件销售商和运行环境销售商对它的采用程度将决定整个工业对jca的接受程序.目前,很少有销售商已经开始(并己决定了发布时间)致力于为它们的程序提供jca资源适配器.虽然我们可以预见在未来的六个月内还会有类似的宣称出现,但是销售商必须决定是否支持jca或者web服务描述语言(wsdl)作为它们标准的外部访问界面.
　　
　　jca在功能上比web服务要丰富,但是它发布起来更难而且限制了销售商只能从java环境访问它们.web服务界面能够自动的包括对java,微软,和其它结构的支持.一个可能的折衷是销售商同时提供对jca和web服务界面的支持,也许使用web服务来打包jca cci.在未来的版本里,jca很可能扩展它对xml和松偶合访问的支持.未来的jca版本还可能提供对cci和web服务的标准化的支持.因此,jca将为对jca资源适配器的紧耦合(jca)和松耦合提供协议.
　　
　　未来对适配器的改进要求
　　jca要求资源适配器运行在j2ee容器里;非java目标程序的本地适配器是不被支持的.通常,将适配器和目标应用程序放在一起能够提高集成度和事务交换的能力.要达到这个目的,用户将不得不走到标准的前面去.开发一个外部的非jca适配器然后为它开发一个jca包容器是可能的.但是这种分布的适配器将不那么好管理而且不太可能实现jca标准的完整功能.
　　
　　jca标准没有解决一个资源适配器是应该总是代表整个目标环境(3270 cics)还是代表一个或多个外部程序的功能(例如这样的功能,"从一个3270 cics 应用程序获取客户信息").复合资源适配器--那些为几个外部环境(例如as/400和r/3)--则连提都没有提到.当前的应用集成的实际显示一个适配器的功能范围可以是"瘦"或者含有很多的技术而在商业逻辑方面变得"胖"而笨重.对大多数集成项目来说关键性的异步集成方式也没有出现在jca 1.0里. 当实际采用jca的时候这些问题就会出现而且有可能需要在jca未来的版本里做进一步的扩展和明确.制定jca 2.0的工作已经开始.
　　
　　应用集成更大的一幅画面
　　jca的范围被限制在适配器技术里,这相对于整个应用集成平台来说是一个小部分.许多应用集成的需求和方案还没有包括在j2ee里.它不支持语义数据传输,业务进程管理,异步集成(jca 的目标只有请求/应答 式的适配器风格),消息仓库和集成系统管理.jca完全面向对同步复合应用的支持,支异步应用程序集成视而不见.要满足这些要求,到2004年附加的与集成有关的标准将被添加进j2ee(0.8的可能性).
　　
　　总结
　　jca是对j2ee显著的扩展,但它没有能够适应所有应用集成项目的需求. 不管jca如何,j2ee的用户在建立它们的集成内构的时候将继续部分的依赖专有解决方案.