用JCA来连接企业应用，第一部分

Connect the enterprise with the JCA, Part 1
用JCA来连接企业应用，第一部分

A look at the J2EE Connector Architecture
J2EE连接器架构一览

-------------------------------
作者：Dirk Reinshagen
翻译：sjoy(shjunsuper@263.net)
出处：http://www.javaworld.com
-------------------------------


概要
在这篇文章中，首先Dirk Reinshagen将为大家介绍JCA － 它是一个标准，以允许从J2EE平台来访问EIS（企业信息系统）系统。Dirk将涉及很多相关的话题，包括对JCA的综述、JCA是如何满足于(fits into)整合策略的、JCA和EAI提供商的产品之间的比较、以及当前JCA平台的一些限制等。


EAI（企业应用整合）产品系列在近10年中已经有了长足的进步。EAI简化了全异的企业信息系统(EIS)的整合过程。尽管如Tibco和Vitria以EAI市场为目标的产品已经取得了成功，然而它们仍然不得不达成广泛的一致性(adoption)。作为JCA(J2EE Connector Architecture)的使命之一，就是它正致力于将EAI整合到主流应用中来。

请阅读关于JCA的系列文章：

  # 第一部分：J2EE连接器架构一览（本文）(http://www.javaworld.com/javaworld/jw-11-2001/jw-1121-jca.html)
  # 第二部分：构建您自己的J2EE连接器架构适配器(http://www.javaworld.com/javaworld/jw-02-2002/jw-0201-jca2.html)

JCA标准的出现带来了一种机制，可以用来在J2EE平台中存储和获取企业数据。许多应用服务器的最新版本，包括BEA的WebLogic服务器和IBM的WebSphere服务器，都增加了连接企业应用的JCA适配器。使用JCA来访问EIS就如同使用JDBC来访问数据库一样。

在JCA出现之前，每个EAI提供商会为它自己的EAI产品建立一个专有的资源适配器接口，要求为每个EAI提供商和EIS的联合实现这些资源适配器（比如，您必须为Vitra开发一个SAP的资源适配器，为Tibco开发另外一个SAP的资源适配器）。为了解决这个问题，也是JCA的一个主要特点(main thrusts)，JCA试图标准化这些资源适配器接口。

在这篇文章中，我将首先从一个较高层次上来介绍一下JCA。然后我将和大家讨论JCA是如何来满足整合策略的。在这之后，我将对JCA和EAI提供商的产品做一比较。最后，讨论一下目前的JCA平台的限制，以及未来它可能会拥有的一些特点。


JCA以及J2EE与EAI产品之比较
在有了以上背景讨论的情况下，让我们考虑一下当前版本的JCA规范－一般而言也就是J2EE规范－是如何达到EAI提供商的产品中已有的特征的。

许多的EAI提供商，比如Vitria和Tibco，宣称它们已经支持JCA，或正处于发布合并了基于JCA适配器产品的过程中。因为JCA 1.0版规范是在2001年7月完成的，不要期望JCA在它最初的发布版本中就匹配了EAI提供商产品中的特征，这并不是它最初的目标。（许多J2EE平台的特征也被比喻成许多EAI产品的特征。）

根据这些，在我们讨论JCA是如何适应EAI之前，很重要的是我们首先要理解一些基本的EAI特征：

  # 资源适配器
  # 数据映射
  # 消息代理
  # 工作流

让我们逐一看来。

资源适配器
大多数的EAI提供商同时提供了专有的适配器以和它们自己的产品协同工作。大多数的适配器允许异步的或者同步的与EIS进行通讯。JCA适配器除了仅包含一个同步的通讯频道之外，是非常类似于那些适配器的。尽管大多数的EAI提供商的适配器提供了远多于JCA适配器的特征集（比如异步通讯能力），但资源适配器是JCA直接匹配支持的EAI特征。

数据映射
下一个EAI特征－数据映射－就是通过资源适配器以一种格式获得数据（比如以EIS的原始格式），然后以某种商业对象要求的数据格式进行传输。从一个系统到另一个系统的数据映射经常强烈的证明了系统整合是需要很多时间来完成，这是因为您必须在两个系统中匹配每个商业对象数据。相应的，大多数的EAI提供商通常提供了一个可视化工具来允许开发者设置这样的映射。

JCA并没有提供这样类似的数据映射工具，EJB（企业Java Bean）的容器管理的持久性(CMP)工具提供了类似的功能。然而，到目前为止并不是所有的EJB容器都能和JCA一起使用EJB CMP（使用JCA作为数据源以替代JDBC）。大概这点会随着JCA被更加广泛的使用而有所改变。

信息代理
信息代理，另外一个对于EAI产品来说常见的特征，通常支持点对点的(point-to-point)以及发布/预定(publish/subscribe)这两种消息处理方式。EAI产品通常把消息作为一个连接层以和全异的系统配合使用。

目前JCA并不支持以消息驱动的方式来和EIS进行连接。然而，有可能在EAI产品中通过使用JMS(Java Messaging Service，J2EE的一部分)来实现一些消息代理特征集。

工作流
工作流是对商业流程的管理。把工作流看做是一个协调者。工作流自己内部并没有能力来完成任何事情，它依赖于商业对象、消息、以及其它外部的实体来执行功能（比如在数据库中创建一个用户的对象）。工作流协调商业对象、消息以及等等如此的东西的使用以执行商业流程。

JCA并没有包含工作流。然而，尝试着在J2EE领域中去寻找一些支持工作流的内容，因为当开发一个复杂的系统的时候，工作流往往是作为一个非常重要的组件提供服务的。

我们已经对JCA（以及J2EE）和EAI工具进行了比较，现在非常重要的是应该看一下JCA是如何满足于一个整体的整合策略的。


JCA和通常的整合策略
这段时间以来，许多的系统都面临着必须和其它系统整合的问题。但是，这是什么意思呢？在这一节中，我将介绍各种整合类型，并且介绍JCA满足的那种情况。

整合可以归结到下面两个方面：

  # Inbound整合：外部系统初始化你的系统所需要的数据
  # Outbound整合：你的系统初始化外部系统所需要的数据

所有以下的整合类型都既可以提供inbound整合方式也提供outbound整合方式。

用户接口整合
用户接口(UI)整合代表了比较粗粒度类型的整合。UI级别的整合也就暗示着数据是以UI所表现出来的形式在不同系统间进行传递的。UI级别的outbound整合必须从远程系统上请求UI（大多数情况是一个web页面），然后可能在被显示出来以前对它进行操作，就好像它是你自己系统UI的一部分一样。UI级别的inbound整合必须允许其它系统向你的系统发出请求，使这些被请求的UI页面被包含在远程系统内。

如果对于区分所获得的数据类型并不重要，那么UI整合比其它选择更容易被接受。实现UI整合所花费的精力通常是最少的。

消息整合
随着Web服务似狂风暴雨般的来临，暗示着消息级别的整合在不同系统之间数据的传递将以消息的格式（预定义的、以数据驱动的文本格式）进行。outbound消息整合包含了从远程系统中以消息格式请求数据（大多数情况就象SOAP（简单对象访问协议）消息）。而inbound整合则是你自己的系统通过消息来接收数据请求然后再以消息的格式进行回应。

因为系统并不关心实际存在于远程系统上的对象类型，消息整合倾向于系统之间的松偶合状态。对于那些期望通过Internet来进行通讯的应用来说，这种松偶合类型的整合是非常合适的。

对象/RPC整合
对象/RPC（远程过程调用）整合意味着使用分布式对象（就是使用EJB调用来整合）整合系统。用对象级别的整合方式，数据是以被调用的方法的参数在系统之间进行传递的。在outbound的对象级别整合中你的系统会调用远程系统的对象，而在inbound级别的整合中，远程系统调用你的系统上的对象以获取数据。

对象级别整合的一个最主要的优点是，你完全可以类型安全地并且详细的调用API，并且可以在系统之间轻松地传播(propagate)错误代码以及异常。

数据整合
最后，数据级别的整合意味着不同系统之间的数据传递将以数据/记录导向的方式进行。在outbound的数据级别的整合中，你的系统以记录导向方式从其它系统中请求数据。而用inbound的数据级别的整合，远程系统会以记录导向方式向你的系统请求数据。

数据级别整合的优点有：它倾向于从一个系统到另一个系统上商业对象的数据映射。JCA属于数据级别整合这个类型，因此它也就具有了这种类型的优点以及缺点。

既然我们已经介绍了JCA所满足的整合类型这个难题，那么我们该去讨论一下JCA的结构了。


JCA的组成
让我们先从JCA的基本情况开始。它包含如下的组件：资源适配器、系统契约、以及公共客户端接口(CCI)，所有这些使得JCA有能力在企业级系统中访问数据。

资源适配器
为了在J2EE容器中使用JCA，你必须首先拥有一个JCA资源适配器，它类似于JDBC驱动。一个JCA适配器是EIS特定的（比如针对SAP或者PeopleSoft的），并且被包含在资源适配器存档(RAR)中，这个RAR文档由一些用来在J2EE容器中配置资源适配器的jar文件以及基本类库(native libraties)组成的。

一个JCA适配器通过系统契约和J2EE服务器进行交互。系统契约使J2EE服务器传播那些JCA适配器被调用的上下文。一共有三种类型的系统契约：

  # 连接管理契约
  # 事务管理契约
  # 安全契约

连接管理契约
连接管理契约描述了J2EE容器使用适配器的过程中，关于建立连接、维持连接池、以及释放这些连接的含义。连接管理契约还允许在连接上建立监听以对事件进行响应（比如当连接丢失或者发生错误的时候）。还需要注意的是，适配器用来连接EIS的基本协议超出了JCA规范所讨论的范围。

所有JCA资源适配器必须提供两个实现。首先，类ConnectionFactor提供了建立连接的手段。其次，类Connection实现这个特别的资源适配器的基本连接事宜。

事务连接契约
事务连接契约以两种不同的方式控制事务处理。第一种方式，也就是分布式的事务处理，提供了一种公告事务的机制，最初从应用服务器内部产生，然后传播到EIS系统中。比如，在EJB中，可能创建了一个事务。如果这个EJB又使用了JCA资源适配器，那么事务管理契约就使得该事务生效，并公告给EIS（通过应用服务器调用资源适配器的X/Open XA接口）。在这种情况下，应用服务器上的事务管理器将控制多个资源以引导并协调处理分布式事务。（比如使用两阶段提交协议）。

第二种方式，事务管理契约能够通过建立“本地事务”来控制事务。本地事务是名义上的本地，它们仅存在于特定的EIS资源上。事务契约允许这些事务被控制，但是它们又和运行了JCA资源适配器的应用服务器上所存在的任何事务都关联起来了。

还要注意的是资源适配器并不需要一定实现事务管理契约。将它作为可选就可以允许资源适配器存在于非事务资源环境下。

安全契约
安全契约让应用服务器使用安全属性来连接EIS系统。应用服务器通过使用安全属性（由用户id和密码、或者认证等组成）来鉴别EIS系统。应用服务器能使用两种方法来鉴别EIS系统（通过资源适配器）。

第一个方法是容器管理的认证，当资源适配器被部署到应用服务器上的时候，安全契约便完成了信任配置。在使用容器管理的认证方法来配置安全属性的时候，你有下面几种方式可以选择。第一种方式，可以选择已配置的认证方式(Configured Identity)，这种方式下所有资源适配器在连接到EIS系统的时候使用相同的认证。第二种方式，当连接EIS系统所使用的基本属性是基于当前应用服务器和映射（映射了应用服务器中的基本属性是如何和EIS系统中的基本属性映射起来的）的联合时，可以选择基本属性映射方式(Principal Mapping)。第三种方式是调用者扮演(Caller Impersonation)的方式，在EIS系统中所使用的基本属性是完全和应用服务器中的基本属性相匹配的。第四种方式是信任书映射(Credentials Mapping)的方式，除了它的信任类型必须是从应用服务器的信任映射到EIS系统的信任的之外，它和调用者扮演(Caller Impersonation)的方式是比较类似的。

虽然在配置期进行安全属性的配置是非常容易的，但是这种策略被证明缺乏一定的灵活性，这是因为安全属性不能在运行时被更改。作为一种可供选择的方式（也就是第二种鉴别EIS系统的方法），你可以通过组件管理认证方法来配置安全属性，这样你就可以每次在资源适配器需要建立连接的时候再把安全属性传递过去。

CCI
为了获得并且更新数据，你必须使用JCA的CCI层，它是类似于使用JDBC来调用存储过程的一个程序。JCA资源适配器并不需要一定支持CCI层（资源适配器建立器能选择它们自己的API集），并且，即使资源适配器支持CCI，它也可以为了那个特殊的适配器而支持特定的API。

CCI API可以分为四个部分：首先是用于创建连接EIS系统相关的API，称之为连接接口(Connection Interfaces)。其次是涵盖了在EIS上执行命令的CCI API，称之为交互接口(Interaction Interfaces)。再次是记录/记录集接口(Record/ResultSet Interfaces)API，它们封装了查询EIS系统结果的操作。最后就是称之为元数据接口(Metadata Interfaces)API，它们允许查询EIS的元数据（数据类型）。

在对CCI API有了一个大致的介绍后，让我们来看一个例子，它演示如何从EIS中查询员工数量：

...
        int count;
        try {
            ConnectionSpec spec = new CciConnectionSpec(user, password);
            Connection con = cf.getConnection(spec);

            Interaction ix = con.createInteraction();
            CciInteractionSpec iSpec = new CciInteractionSpec();
            iSpec.setSchema(user);
            iSpec.setFunctionName("EMPLOYEECOUNT");
            RecordFactory rf = cf.getRecordFactory();
            IndexedRecord iRec = rf.createIndexedRecord("InputRecord");

            Record rec = ix.execute(iSpec, iRec);
            Iterator iter = ((IndexedRecord)rec).iterator();
            while(iter.hasNext()) {   
                Object obj = iter.next();
                if(obj instanceof Integer) {
                    count = ((Integer)obj).intValue();
                }
            }
            con.close();
        }
        catch(Exception e) {
            e.printStackTrace();
        }
        System.out.println("Employee count is: " + count);
...

JCA 1.0的限制以及对它的展望
JCA唯一最大的缺点就是它缺乏异步通讯机制。它带来的结果就是，虽然被证明从EIS系统中拉信息(pulling infomation)非常简单明了，但是在目前的JCA规范中并不包含从EIS中送信息(send infomation)。

它的另外一个主要的缺点就是，JCA规范缺乏对访问数据的一个通用的API。上面提到的CCI是可选的，所以还不存在一个可以依赖的机制能让开发者使用，以通过JCA来访问数据（只有系统契约可以保证具有相容性）。

好消息是大多数当前的JCA限制将在下个版本(JCA 2.0)规范中包含进来，当前已经开发到JSR(Java规范请求）112。2.0版将包含异步能力、JMS和JCA的整合、CCI层的元数据、以及在CCI层中使用XML等。

Wrap up
这篇文章对JCA 1.0规范做了一个大致的介绍，并且介绍了它是如何适应EAI产品目录的。一个尚未广泛展开的方面是，JCA规范需要证明是开发大型J2EE系统的有力工具。JCA系列的第二部分将通过开发一个简单的JCA适配器来更进一步的学习JCA的细节。

原文转自：http://www.ltesting.net