IBM WebSphere 开发者技术期刊: 使用 J2EE Connector Architecture 进行 WebSphere Application Server 和 CICS 的事务集成

文档选项 未显示需要 JavaScript 的文档选项

级别： 初级

Phil Wakelin (Phil_Wakelin@uk.ibm.com), CICS Transaction Gateway 技术设计师, IBM
Dave Seager (SEAGER@uk.ibm.com), Web Services Gateway & WSIF L3 Service , IBM

2004 年 10 月 01 日

本文阐明了如何使用 J2EE™ Connector Architecture（JCA）为部署在 WebSphere® Application Server 的 JCA 管理环境内的 J2EE 应用程序和部署在 CICS® 中现有的应用程序提供事务集成。

引言

在本文中，我们将提供基本事务概念的综述，然后主要着眼于 Transaction Server for z/OS® (CICS TS)、CICS Transaction Gateway（CICS TG）、及 WebSphere Application Server 内部的事务环境。我们将提供对可用于 WebSphere Application Server 内部的 servlet 和 EJB™ 组件的事务控件的详细分析，并且阐明如何使用这些控件在部署到 WebSphere Application Server 和 CICS 中的应用程序之间提供事务集成。

本文是针对那些需要理解使用 JCA 和 CICS 的事务本质的应用程序设计者和体系结构设计者而编写的。本文假设读者具有 CICS 和 JCA 的基础知识，并且没有考虑其它决策因素，如连接管理或安全。（参阅 参考资料以获取有关这些话题的更多信息。）

回页首

事务：它们是什么？

在 J2EE 世界里，事务是活动单元，在活动单元内，把可恢复的资源的多次更新作为原子性的（更确切地说，一个不可分割的工作单元），以使得要么全部更新要么全不更新。然而，在 CICS 世界里，事务是指被特定的事务标识符（transaction-identifier）调用的，通过一个 CICS 程序（或一系列的程序）完成的工作，并且运行在一个特定的 CICS 任务下。该任务本身由多个可恢复的工作单元（也被称为逻辑工作单元）组成，这些工作单元通过同步点区分。这些工作单元是可恢复的原子单元，并且同样类似于 J2EE 世界里的事务。

基本的组件

在事务环境中，把所有的参与者分类为资源管理器或事务管理器。资源管理器负责管理可恢复的数据，例如文件或队列。 事务管理器拥有事务响应能力，并且在多个资源管理器之间协调事务的结果。在它们之间，事务管理器和资源管理器负责可靠地协调对可恢复资源的更新，满足维持原子性、一致性、隔离性和持久性的事务规则。为了达到该目的，每个参与者需要执行共同的体系结构标准。在接下来的部分，我们将简要查看下列标准和协议：

• CICS Intersystem Communication (ISC)
• J2EE Connector Architecture (JCA)
• 两阶段提交（Two-phase commit）。

CICS 本身就拥有它自己专用的事务性的系统间通信（ISC）协议，该协议主要以 LU6.2 SNA 格式和协议为基础。ISC 协议允许跨越不同 MVS 系统或不同平台（例如 iSeries 或 UNIX 系统）的多个 CICS 系统在这些不同系统的应用程序之间支持扩展的工作单元。（要获取更多的信息，参阅 CICS 双向通信指南，SC34-6243。）

JCA 是 J2EE 规范的一部分，它规定了由资源适配器执行的系统契约（system contract ）。这些系统契约定义了资源适配器为事务管理、连接管理及安全提供的服务的质量（参见图 1）。

在 J2EE 体系结构中，分布式事务被认为是全局事务，管理可恢复资源的事务系统被称为资源管理器，例子如 CICS、IMS™、和 DB2。这些资源管理器按照他们对事务的支持被分为支持两阶段协调的资源管理器（通过提供 XAResource 接口），仅仅支持单阶段协调的资源管理器（通过 LocalTransaction 接口）和不支持事务的资源管理器。

为了进行事务管理，需要资源适配器执行下列契约中的一个，这些契约在资源适配器的部署描述符（ ra.xml ）中定义：

• XAResource
  在两阶段提交期间调用的事务参与者，它能影响事务的结果。通常，资源管理器执行 XAResource， 它被用于支持资源管理器事务分支的对外协调。在事务中应用程序服务器管理 XAResource 的使用，XAResource 的使用不涉及应用程序。
• LocalTransaction
  资源适配器参与了相对于资源管理器是本地事务，但是该资源适配器不能参与两阶段提交事务（除了仅仅作为一个代理或最后的参与者）。在本文和其它与 WebSphere 相关的出版物和论文中为了清晰度，我们使用术语“资源管理器本地事务”（RMLT）表示相对于单个资源管理器是本地的事务。
• NoTransaction
  不具有事务功能的的资源管理器，该资源管理器可以参与事务上下文，但是不受事务结果的影响，并对事务结果没有影响。

WebSphere Application Server 事务支持在事务内部协调许多具有两阶段能力的资源管理器。在缺乏其它任何事务资源管理器的事务内部，它也允许使用具有单一的单阶段能力的资源管理器。在全局事务中，也可以使用 Non-transactional 资源管理器，但是它不参与全局事务的作用域。

CICS ECI 资源适配器执行 LocalTransaction 接口，所以对全局事务具有有限的支持。尽管如此，当在 WebSphere Application Server for z/OS 内部运行时，如果使用了本地的 Gateway，那么 CICS ECI 资源适配器支持全局事务。这意味着 CICS Transaction Gateway 运行在 WebSphere Application Server 地址空间内部，所以可以使用 MVS Resource Recovery Services（RRS）的内部功能，仅在 z/OS 上适用。这提供了 RRS 全局事务支持，并且允许 CICS ECI 资源适配器参与基于 z/OS 的 WebSphere Application Server 中带有许多具有两阶段能力资源管理器的全局事务。

被用于访问基于 3270 终端的程序的 CICS EPI 资源适配器不支持全局事务。这是因为基于 3270 接口的 CICS 的性质，这些接口不能被用于 CICS 应用程序的全局事务。

两阶段提交

所有事务标准的一个基本部分是两阶段提交流程。 该部分是流程的体系结构集，事务管理器使用它来确保不管任何故障都能可靠地协调事务中所有的资源管理器。通过所有的事务协议来执行这些流程，基本概念本质上是相同的。下面的叙述根据 XA 规范概括了这些流程；其它协议如 CICS 或 LU6.2 可能在流程中使用不同的术语和变量。（有关 CICS 同步点流程的更多的详细资料请参考 CICS 内部通信指南，SC34-6243，第 2 章：互连系统中的恢复和重启。）

在第一阶段（或阶段 1）中，事务管理器请求所有的资源管理器准备提交可恢复的资源（准备），每个资源管理器可以做确定答复（已准备）或否定答复（回滚）。如果资源管理器打算确定地答复，那么它稳定地记录它需要这样做的信息并且答复已准备，然后不得不遵循下一阶段决定的事务的最后结果。目前把资源管理器描述为处于可疑（in-doubt）状态，因为它已经把最后的事务控制委托给了事务管理器。

在阶段 2 中，假设所有的资源管理器都做了确定的答复，事务管理器回复每个资源管理器一个提交流程。资源管理器一收到提交流程就结束对可恢复资源的更新，并且释放所有抓住资源不放的锁。资源管理器然后以最后的已提交流程响应，该已提交流程向事务管理器显示它已经不处于可疑状态。如果事务管理器没有接受到最后的已提交流程，那么事务管理器必须假定资源管理器没有接受到提交命令，因此需要重新发送提交命令。

尽管两阶段提交流程通常是分布式事务支持的先决条件，但是在一些特定的场合中，一步提交（single-phase）流程已经足够了。在 J2EE 事务环境中，WebSphere Application Server Enterprise 的 last participant support (LPS) 功能扩展了全局事务模型，允许单一的单阶段提交资源参与带有许多具有两阶段提交能力资源的全局事务。在事务提交时，应用服务器首先准备两阶段提交资源管理器，如果成功，然后调用单阶段提交资源提交。然后根据单阶段提交资源的响应，提交或回滚两阶段提交资源，有效地把事务协调委托给了单阶段提交资源。

不像两阶段提交资源，单阶段提交资源不能从通信故障中恢复。在单阶段提交资源提交过程中，这样的通信故障引入了混合事务结果的危险。虽然回滚了两阶段提交资源，但是单阶段提交资源的结果却不清楚；它可能已被提交，也可能被回滚。因此必须配置应用程序使其接受这些试探性结果的额外风险。 事务配置场景中的 问题 5给出了更详细的资料。

在 WebSphere Application Server for z/OS 外，CICS ECI 资源适配器只能当作具有 LocalTransaction 能力的资源适配器使用，因此使用它对 WebSphere Application Server 的 LPS 功能有好的效果。使用 LPS 时，J2EE 组件不需要考虑在事务中做更新的次序，因为应用程序服务容器完全处理提交流程。

恢复日志

为了执行从故障场景中恢复，事务管理器和资源管理器必须能够在事务流程的任何点从故障中恢复。通过使用基于可恢复介质（例如物理的 DASD）的事务日志来完成这个目标。如果在处理的任何关键时期发生致命故障，那么刚一重新启动，只要任一事务处于可疑状态，事务或资源管理器就可能重做日志中的工作以发现事务先前在哪一点终止的。在分布式平台上的 WebSphere Application Server 和 z/OS 上的 CICS TS 都执行它们自己内部的日志系统。用于 z/OS 的 WebSphere Application Server 和 CICS TG 都利用 RRS 的事务服务提供的恢复日志。

回页首

CICS 工作单元：事务、任务、和同步点

如前面提到的，术语“事务”被反复使用。在本文中， CICS 事务指的是在 CICS 领域内启动的，并且使用四个字符事务 ID（tranid）的操作。这些 tranids 是 CICS 资源定义，用来指定被加载的初始程序和 CICS 事务的特性，相关的任务在这些 CICS 事务下运行。从历史上看，通过宏命令来定义事务 ID，这些宏命令创建程序控制表（Program Control Table，PCT），但是目前是在在线资源定义数据库（resource definition on-line，RDO）内部的 TRANSACTION 定义中定义事务 ID。在事务开始时，CICS 隐含地开始一个新的任务，这是承担事务工作的初始边界。对可恢复资源的所有更新或对其它事务系统的请求现在都是该工作单元的一部分，直到在 CICS 程序内部到达一个同步点（syncpoint）。在 CICS 应用程序内部使用 EXEC CICS SYNCPOINT 命令明确的编写同步点，或当任务终止时隐含地达到同步点。在同步点，作为事务管理器的 CICS 将准备所有的相关资源管理器并且协调原子结果要么为成功的提交，要么当成功提交不可能时进行回滚，在这种情况下，把所有可恢复的更新回滚到工作单元开始前的状态（参见图 4）。

在特定的情形中，例如如果使用系统间分布式程序连接（DPL）请求，远程的 CICS 系统可以协调被连接的 CICS 事务。CICS TG 通过使用外部调用接口（ECI）启动和协调 CICS 工作单元扩展该情况。在术语 CICS Transaction Gateway 内部，CICS TG 指的是扩展的逻辑工作单元。当使用 DPL 请求调用 CICS 程序时，不允许 CICS 程序执行同步点命令，因为是远程系统在协调事务。

此外，相反的情况也是可能的；该情况是指被调用的 CICS 事务在独立于调用应用程序的事务上下文中运行。该情况被认为是使用 sync-on-return 运行，sync-on-return 是指 CICS 中的控制镜像事务在控制权交给调用应用程序时发送同步点（请参见图 6）。sync-on-return 类型连接的使用也允许被调用的应用程序发送 EXEC CICS SYNCPOINT 命令，因为对于其它事务管理器来讲它并不是次要的（sub-ordinate）。

回页首

使用 CICS Transaction Gateway 事务支持

当使用 CICS Transaction Gateway 提供从 J2EE 应用程序到 CICS 的事务集成时，ECI 提供基础的连通性，ECI 允许调用应用程序（例如 J2EE servlet 或 EJB 组件）协调被调用的 CICS 事务。尽管如此，为了理解提供的功能，必须理解 CICS Transaction Gateway 提供的有关两阶段提交网络连接和恢复日志的基本组件的事务支持。

当使用 ECI 协议时，可能需要考虑两种不同的网络连接，即从 J2EE 组件到 CICS Transaction Gateway 的连接，和从 CICS Transaction Gateway 到 CICS 的网络连接（参见图 7）。这些连接支持多种网络协议，如下所示：

• J2EE 组件到 CICS Transaction Gateway：TCP/IP、SSL 或本地绑定
• CICS Transaction Gateway 到 CICS：SNA、TCP62、TCP/IP、EXCI。

在这些可能的选项之外，唯一支持 ECI 流程的两阶段提交事务协调的协议是 External CICS Interface（EXCI）。它是 CICS TS for z/OS 提供的接口，当 CICS Transaction Gateway 和目标 CICS 区域在相同的 MVS 映射中时，该接口在和 MVS™ Resource Recovery Services（RRS）连接中提供事务支持。当在 WebSphere Application Server for z/OS 的本地模式下运行时，该支持和 CICS Transaction Gateway 本地模式（本地绑定的一种形式）共同提供两阶段提交全局事务支持。在所有的其它情形下，必须使用单阶段提交，因此必须把 CICS Transaction Gateway 当作本地的具有事务能力的资源管理器。

当在基于 JCA 的基础架构中利用 CICS Transaction Gateway 作为中间层组件时，在控制与 CICS 的交互中涉及几个组件和相关的连接。Gateway 守护进程是这些组件和连接的中心，并与 WebSphere Pool Manager 和被连接的 CICS 系统都交互（参见图 7）。

当发出从 J2EE 组件到 Gateway 守护进程的 ECI 请求时，必须首先建立从 CICS ECI 资源适配器到 Gateway 守护进程的连接。WebSphere Connection Management Pool Manager 管理该连接，WebSphere Connection Management Pool Manager 控制着到 Gateway 守护进程的基础连接的分配和池。每个连接表示一个到 Gateway 守护进程的 socket 连接，在 Gateway daemon 里，Socket 的生命周期的专用连接管理器线程管理该 socket 连接。如果该连接被丢失，那么事务上下文会被终止，并且 Gateway 守护进程和 WebSphere Application Server 将会回滚所有相关的操作。

有关使用 WebSphere Connection Management Pool Manager 的连接用法的更多详细资料请参阅 在 WebSphere Application Server V5 中共享连接。

回页首

WebSphere Application Server 中的事务支持

WebSphere Application Server 为不同类型的 J2EE 组件提供不同的服务质量，通过一组容器的使用来实现。四个容器是 Web 容器、EJB 容器、客户端容器和 applet 容器。在 WebSphere Application Server V5 中，Web 和 EJB 容器里提供 JCA 支持，这两个容器都支持 JCA 连接池机制以及事务上下文从 J2EE 组件到 JCA 交互的传播。

Web 容器

Web 容器的主要功能是针对 servlet 和 JSP 组件的，但是它也提供全局事务支持。然而，Web 容器不提供容器管理事务服务，但是应用程序可以通过程序来利用本地事务或 bean 管理的事务（BMT）。通过在从 ECIConnectionFactory 获得 Connection 对象上调用 getLocalTransaction() 方法控制资源管理器的本地事务；它为 JCA 连接工厂提供程序上的特定的事务上下文。通过使用 javax.transaction.UserTransaction 接口开始和结束事务来创建 BMT。该应用程序必须到 HTTP 请求的生命周期末提交事务。越过多个对 servlet 的 HTTP 请求扩展事务的生命周期是不可能，或不值得的，WebSphere Application Server 回滚所有在 servlet service() 方法结束时没有结束的全局事务。

EJB 容器

EJB 容器提供对全局事务的充分的事务支持，包括容器管理事务（CMT）和 Bean 管理事务。会话 bean 和消息驱动 bean 可以使用任一类型；实体 bean 被受限于仅仅使用 CMT。使用 BMT 的 bean 负责事务划分并且必须使用 javax.transaction.UserTransaction 接口开始和结束事务。CMT 是优先选用的机制，因为它把事务控制委托给应用程序服务器，这允许开发者集中精力开发业务逻辑，此时也允许根据部署决定应用程序的事务特性。使用 CMT 的事务控制的关键是接下来讨论的 EJB 事务属性。

事务属性

在 EJB 部署描述符（ ejb-jar.xml 文件）中设置事务属性，事务属性是控制属性，在控制情形下当调用 bean 方法时启动全局事务。该事务属性出现在 <container-transaction> 部分并且由 <trans-attribute> 标签指定。例如，下面的 XML 定义了在 CTGTesterCCI 上的远程 execute() 方法具有 Required 事务属性。

<container-transaction>
   <method>
      <ejb-name>CTGTesterCCI</ejb-name>
      <method-intf>Remote</method-intf>
      <method-name>execute</method-name>
   </method>
   <trans-attribute>Required</trans-attribute>
</container-transaction>

图 8 展示了使用 WebSphere Studio Application Developer EJB Deployment Descriptor 编辑器定义这些设定值。

事务属性和它们的描述的可能值在表 1 中给出：

表 1. EJB 事务属性

本地事务容器

EJB 2.0 规范没有指定如果没有全局事务下运行方法时容器的行为。servlet、使用 bean 管理事务的会话 bean 及一些其它场景可能发生这种情况。在该种情况下，应用程序被请求在“未指定的事务”上下文中执行。为了实现一致性和可移植性，WebSphere Application Server 使用本地事务容器策略（LTC）执行该未指定的事务上下文。该 LTC 策略是一个划分范围的方法，Web 和 EJB 组件使用它划分分派到全局事务之外的操作的开始和结束。在该 LTC 内对资源管理器的所有访问都通过资源管理器本地事务（RMLT），在 LTC 结束时必须解决这种事务。在程序上，没有控制 LTC 的可能，并且 LPC 辖区影响应用程序的方法由三个扩展的部署描述符（XDD）控制，这三个部署描述符可以在 J2EE 组件部署时设置，如下所示：

• Boundary
  它可以有值 BeanMethod （默认）或 ActivitySession 。ActivitySession 是对仅仅在 WebSphere Application Server Enterprise Version 5 中适用的 EJB 容器的扩展。它在基于资源管理器的本地事务的边界方法之外提供了一个扩展的工作单元作用域。（参阅 WebSphere Application Server Enterprise V5 中的事务服务，REDP3759获得更多信息。）
• Resolver
  这个可以有值 ContainerAtBoundary 或 Application （默认）。当在全局事务上下文（例如带有 Never 事务属性的）外面的 EJB 容器发出 ECI 请求时，如果 Resolver 属性被设置为 Application，那么 ECI 调用类型是非扩展的。相反地，如果 Resolver 属性被设置为 ContainerAtBoundary，那么将会启动资源管理器本地事务，且 ECI 调用类型是扩展的，会被容器在 EJB 方法的边界解决。
• UnresolvedAction
  它具有两个值 Commit 或 Rollback （默认）。它可以被指定用于 EJB 或 Web 容器，并表示容器如何使用 LTC 边界上的 RMLT 来清除所有的连接。该属性是 Web 组件（servlet）唯一能配置的 LTC 设定值，通过在连接上使用 LocalTransaction.begin() 方法应用于 bean 管理事务。在交互完成后，所有的容器管理事务被自动提交，因此在 Web 容器中容器管理事务不使用该属性。

有关 LTC 策略的使用需要注意以下几点：

• LTC 作用域对于每个 J2EE 组件来讲是本地的；因此如果在 LTC A 下分派 EJB 组件 A，并且该组件调用 EJB 组件 B，那么需要在一个单独的 LTC 下分派组件 B。
• 如果应用程序在全局事务外执行，那么容器经常会建立 LTC 作用域，除非 Web 组件或 BMT 企业 bean 是 J2EE 1.3 以前的标准。

回页首

事务部署场景

在该部分，我们解释把 servlet 和 EJB 组件部署到 WebSphere Application Server 环境中的事务本质，以及有效利用事务控制器的方法。关于 Web 容器和 EJB 容器两个环境，我们给出了一组经常有人问的问题，并且提供了所提出的问题或场景的实际解决方案：

1. 在同一事务作用域内，servlet 能否发出多个 ECI 请求？
2. 在 Web 容器内能否使用带有 ECI 请求的全局事务？
3. 在同一事务作用域内，EJB 组件能否发出多个 ECI 请求？
4. 在同一事务作用域内，能否使用两个不同的连接工厂以及发出多个 ECI 请求？
5. 怎样发出对全局事务的 CICS 部分的 ECI 请求？
6. 如果使用 z/OS 平台上的 WebSphere Application Server，支持有什么不同？
7. 如果在 WebSphere Application Server 内使用 CICS TG ECIRequest 类或 Java Common Connector Framework（CCF）类的 VisualAge 怎么办？

部署到 Web 容器

在 Web 容器中部署的 Servlet 缺乏 EJB 组件的大多数事务属性。尽管如此，Web 容器还是支持 RMLTs 和 LTC 容器策略，使用这两个策略可以影响 ECI 资源适配器发出的 JCA 请求。

1. 在同一事务作用域内，servlet 能否发出多个 ECI 请求？

   如果在一个交互中两次调用 execute() 方法，这样会调用两个相应的到 CICS 的 ECI 调用。下面的代码样本说明该方法：

   Context ic = new InitialContext(); cxfn = (ConnectionFactory) ic.lookup("java:comp/env/eis/ECICICS"); Connection cxn= cxnf.getConnection(); Interaction ixn= cxn.createInteraction(); ECIInteractionSpec ixnSpec= new ECIInteractionSpec(SYNC_SEND_RECEIVE,"CICSPROG"); JavaStringRecord jsr = new JavaStringRecord() jsr.setText("DATA1"); ixn.execute(ixnSpec, jsr, jsr); ... jsr.setText("DATA2"); ixn.execute(ixnSpec, jsr, jsr); ... ixn.close(); cxn.close();

   
   

   然而，与其在同一事务上下文下运行两个对 CICS 的请求，倒不如发现它们各自在 CICS 中作为独立的工作单元运行，并且使用单独的 CICS 镜像事务实例。这是因为在 Web 容器内部，在随后的请求发出之前，每个交互都是自动提交。

   如果您需要两个这样的对 CICS 的请求在同一事务作用域内运行，那么有两种解决方案可以讨论。首先可以使用在 问题 3 中讨论的 EJB 容器的事务控制。其次可以通过程序创建和控制 RMLT。在下面的代码样本中说明该方法：

   Context ic = new InitialContext(); cxfn = (ConnectionFactory) ic.lookup("java:comp/env/eis/ECICICS"); Connection cxn= cxnf.getConnection(); Interaction ixn= cxn.createInteraction(); ECIInteractionSpec ixnSpec= new ECIInteractionSpec(SYNC_SEND_RECEIVE,"CICSPROG"); JavaStringRecord jsr = new JavaStringRecord() LocalTransaction tran = cxn.getLocalTransaction(); tran.begin(); jsr.setText("DATA1"); ixn.execute(ixnSpec, jsr, jsr); ... jsr.setText("DATA2"); ixn.execute(ixnSpec, jsr, jsr); ... tran.commit(); ixn.close(); cxn.close();

   
   

   当控制这样一组交互时，事务上下文对于单个连接来讲是本地的，因此对于基础的 ConnectionFactory 和 引用的 CICS 区域来讲也是本地的。所以全局事务上下文不需要维护事务的完整性，因为在事务里只有一个资源管理器。然而，在事务作用域内增加任何其它可恢复的更新都是不被支持的，因为这需要全局事务。

2. 在 Web 容器内能否使用带有 ECI 请求的全局事务？

   Web 容器不支持任何全局事务的容器管理，所以所有的事务控制都必须使用 BMT。 javax.transaction.UserTransaction 接口是控制 BMT 的机制，尽管在 Web 容器中支持该接口，但是在与从 CICS ECI 资源适配器中获得的连接连接时，不能使用该接口。这是因为 CICS ECI 资源适配器仅仅支持 LocalTransaction 接口，并且也是因为 WebSphere Application Server for z/OS 的 CICS ECI 全局事务支持不支持 BMT。

部署到 EJB 容器

WebSphere Application Server 中的 EJB 容器完美地适合于事务组件的部署，并且提供对容器和 bean 管理事务两者的支持。容器管理事务具有这样的优势：J2EE 服务器执行所有的事务协调以及应用程序开发者可以集中精力开发业务逻辑而不是事务逻辑。为了控制事务组件的行为，EJB 容器提供了一组用于控制容器管理组件的事务行为的属性。在该部分，我们将叙述这些属性并且阐明如何在与 CICS ECI 资源适配器连接中使用它们。

3. 在同一事务作用域内，EJB 组件能否发出多个 ECI 请求？

   事务属性的设置和全局上下文是否存在，都会影响CICS中的 ECI 的访问类型和最后所得到的事务作用域。表 2 描述了 CICS 镜像任务的最后所得到的 ECI 调用类型和事务作用域。长期的 CICS 镜像任务需要 CICS 中扩展的工作单元，尽管 synconreturn 镜像任务意味着 CICS 事务运行在相对于 EJB 组件的上下文来讲独立的 CICS 事务上下文，在各个 ECI 调用结束后镜像任务终止。

   表 2. EJB 事务属性的 ECI 调用类型

   属性	ECI 调用类型	CICS 镜像任务事务性作用域
   NotSupported	非扩展	Synconreturn
   Required	扩展的逻辑工作单元	长期
   RequiresNew	扩展的逻辑工作单元	长期
   Supports	依赖于存在的上下文；在调用程序上下文内执行 bean 方法时，ECI 调用类型是 ECI_EXTEND，或者，如果没有现场（none present），方法在未指定的上下文内执行。如果在在未指定的上下文内，LTC 设置控制最后的 ECI 调用类型。（参阅 本地事务容器。）	Synconreturn 或长期
   Mandatory	扩展的逻辑工作单元或抛出异常；在调用程序内执行 bean 方法。如果调用程序没有提供上下文（换句话讲没有全局活动），那么运行失效，抛出异常。如果存在全局事务活动，那么 ECI 类型是 ECI_EXTEND。	长期
   Never	非扩展	Synconreturn

4. 在同一事务作用域内，能否使用两个不同的连接工厂以及发出多个 ECI 请求？

   当使用两个不同的连接工厂时，把这两个连接工厂都当作独立的事务资源（即使它们指的是同一 CICS TG 或 CICS 区域）。下面显示的是使用两个这样的连接工厂的代码样本：

   Context ic = new InitialContext(); // Create first connection factory and get connection cxfn1 = (ConnectionFactory) ic.lookup("java:comp/env/eis/ECICICS1"); Connection cxn1 = cxnf1.getConnection(); // Create first interactin and flow to CICS Interaction ixn1 = cxn1.createInteraction(); ECIInteractionSpec ixnSpec1 = new ECIInteractionSpec(SYNC_SEND_RECEIVE,"CICSPROG"); JavaStringRecord jsr = new JavaStringRecord() ixn1.execute(ixnSpec, jsr, jsr); cxfn2 = (ConnectionFactory) ic.lookup("java:comp/env/eis/ECICICS2"); Connection cxn2 = cxnf2.getConnection(); Interaction ixn2 = cxn2.createInteraction(); ECIInteractionSpec ixnSpec2 = new ECIInteractionSpec(SYNC_SEND_RECEIVE,"CICSPROG"); jsr.setText("DATA2"); ixn2.execute(ixnSpec, jsr, jsr); ixn1.close(); cxn1.close(); ixn2.close(); cxn2.close();

   
   

   当在 WebSphere Application Server for z/OS 内执行该代码时，CICS ECI 资源适配器提供的 RRS 全局事务支持允许在全局事务作用域内使用许多 ECI 连接。

   在分布式平台的 WebSphere Application Server 上，CICS ECI 资源适配器支持的 JCA LocalTransaction 契约仅仅提供 RMLT 支持。因此如果执行该代码，那么 ECI 资源适配器将尝试为每个 Connection 创建唯一的 RMLT－－但是这会失败，因为在 EJB 容器内，全局事务作用域内由于 RMLT 的单阶段性质只可能有一个 RMLT。

5. 怎样发出对全局事务的 CICS 部分的 ECI 请求？

   有三种方法实现该效果，依赖于应用服务器环境以及是否在全局事务中有任何其它的具有 XAResource 能力的资源管理器：

   1. 当在 WebSphere Application Server for z/OS 中使用 CICS ECI 资源适配器时，CICS ECI 资源适配器提供的 RRS 全局事务支持允许在全局事务作用域内使用许多 ECI 连接。
   2. 如果在事务内部没有调用具有 XAResource 能力的资源管理器（例如 JDBC 数据源），那么与 CICS 的交互是全局事务的一部分，当 EJB 容器提交全局事务时，它将会被提交。该方法是可行的因为全局事务提供一个对两阶段提交协议的单阶段优化，在优化中，如果在事务中仅仅只有一个单一的资源管理器分支（也是就说，一个单一的资源），那么事务管理器使用单阶段提交流程。有时，该方法被称为“唯一的代理优化”（only agent optimization）。当该方法是主要的性能优化方法，这意味着在不需要被准备的全局事务中可能支持单一的单阶段提交资源管理器（例如 CICS SCI Connection）。
   3. 如果在连同 CICS ECI ConnectionIf 一起的全局事务中调用了具有 XAResource 能力的资源管理器，那么通常在提交时，EJB 容器内部会产生一个异常，该异常带有的信息说：

      An illegal attempt to enlist a one phase capable resource with existing two-phase capable resources has occurred.

      这是因为在全局事务中 EJB 容器不能同时提交单阶段提交资源和两阶段提交资源。然而，有一个解决该问题的方案即以 WebSphere Application Server Enterprise Version 5 提供的 Last Participant Support（LPS）形式。这允许单一的具有单阶段提交能力的资源（例如 CICS ECI Connection）参与拥有许多具有两阶段提交能力的资源管理器的全局事务。
      
      通过扩展的部署描述符（XDD）为特定的 EJB 组件启用 LPS 功能。应用程序装配工具提供了一个 WebSphere Application Server Enterprise 选项卡，在该选项卡上有一个 Accept heuristic hazard复选框。选中该复选框部署的应用程序可以使用 LPS 。WebSphere Studio Application Developer Integration Edition 提供了一个有关 J2EE Application Deployment Descriptor 编辑器的 Extended Services 选项卡，在该选项卡上有一个 Last participant support复选框（如图 9）。
      
      
      图 9. WebSphere Studio Application Developer：Last participant support
      
      也可以配置 WebSphere Application Server Enterprise 事务服务程序在提交单阶段提交资源以前写入额外的日志条目以便在恢复期间确保合适的启发式报告。在 Administration 控制台的 Transaction Configuration 选项卡完成该操作。选项是 Application Servers => Server => Server properties => Transaction Service菜单的 enableLoggingForHeuristicReporting。

6. 如果使用 z/OS 平台上的 WebSphere Application Server，支持有什么不同？

   在 WebSphere Application Server for z/OS 的本地模式中，CICS ECI 资源适配器通过使用内部的 RRS 功能支持全局事务。这意味着当使用 CMT 事务时，许多 CICS ECI Connections 可以参与带有两阶段提交资源的全局事务。

   然而，如果使用了远程 Gateway（也就是说在 ConnectionFactory 指定了非局部 GatewayURL），那么 ECI Connection 变成了只具有单阶段提交能力。在该情况下，WebSphere Application Server for z/OS 允许在同一事务中使用带有任何具有 RRS 能力的资源的单一的具有单阶段提交能力的资源。不像在分布式平台上的 WebSphere Application Server，不需要指定 LPS XDD 特性使用该行为。

7. 如果在 WebSphere Application Server 内使用 CICS TG ECIRequest 类或 Java Common Connector Framework（CCF）类的 VisualAge 怎么办？

   在 WebSphere Application Server V5 中，仅仅在 Web 容器内部支持 ECIRequest 类和 CCF 类，并且仅仅用于使用非扩展的本地工作单元。除此之外，它们不能够参与 WebSphere Application Server 提供的 JCA 管理环境，因此不能参与 RMLT 的作用域或全局事务。因而，必须仔细设计任何使用这些类的事务请求应用程序，并且利用足够的补偿逻辑（compensation logic ）确保一致的结果。

回页首

结束语

在本文中，我们回顾了 WebSphere Application Server 和 CICS 都提供的事务支持，并且阐明了如何使用 CICS ECI 资源适配器在两个环境之间提供事务协调。该集成的关键是资源适配器和 J2EE 应用程序服务器之间的 JCA 事务管理契约。多种因素影响该契约，包括 Web 或 EJB 容器的使用、EJB 事务属性、LTC 设置以及带有 z/OS 上的 WebSphere Application Server 的 RRS 的使用。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  
  
• 使用 JCA 集成 WebSphere Application Server 和 CICS
  
  
• WebSphere Application Server V5 的共享连接
  
  
• WebSphere Application Server Enterprise V5 的事务服务
  
  
• WebSphere 零售书籍
  

作者简介

		Phil Wakelin是 IBM Hursley 的 CICS Transaction Gateway 技术设计师，负责制定该产品的未来发展的计划，该产品提供从 WebSphere Application Server 到 CICS 的连接。他在 1990 年加入了 IBM，原先在 IBM Hursley 的系统测试部门工作，在加入 Installation Support Center 之前，在该部门他作为一名 CICS 客户端和服务器端的售前支持专家在 CICS 的大多数平台和版本上工作过。然后加入了 IBM San Jose 的 IBM International Technical Support Centre，在那里他负责了 3 年与 11 CICS 相关的 IBM Redbooks 的开发和发布。他是具有 IBM 认证的解决方案专家、CICS Web Enablement 和高级 IT 专家，拥有英国 University of Bath 的应用生物学的理学学位。

		Dave Seager1997 年加入 IBM 。在调到 Web Services 支持团队的当前角色以前，是 CICS Transaction Gateway 的软件开发人员和系统测试员。在 IBM 期间，他广泛地参与 WebSphere Application Server 的工作，是一些有关 developerWorks WebSphere 论文的作者。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？

回页首