利用 J2EE Connector Architecture

　　引言

　　CICS 应用程序与事务的服务质量有同等含义;将这些应用程序与主流 J2EE 组件集成在一起是当今许多企业面临的共同难题。可以使用 J2EE Connector Architecture (JCA) 和 CICS Transaction Gateway 提供对 WebSphere Application Server 中部署的 CICS 应用程序和 J2EE 组件的事务集成。

　　为了向您介绍如何实现这一集成，我们将从概述基本事务概念开始，然后具体介绍以下软件中的事务环境：IBM WebSphere Application Server、CICS Transaction Server for z/OS™ (CICS TS) 和 CICS Transaction Gateway (CICS TG)，其中包括 CICS TG V6.1 for z/OS 中新的 XA 两阶段提交支持。我们将详细分析 WebSphere Application Server 中的 Servlet 和 EJB 组件的事务控制，并阐述如何使用这些控制来提供 WebSphere Application Server 中部署的应用程序与 CICS 之间的不同级别的事务集成。

　　本文的目标读者是需要了解将 JCA 和 CICS 一起使用的事务本质的应用程序设计人员和架构师。本文假设您了解 CICS 和 JCA 方面的基础知识。

　　事务为何物?

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

　　基本组件

　　在事务环境中，所有参与者都被划分为资源管理器或事务管理器。资源管理器负责管理可恢复数据，例如文件或队列。事务管理器负责事务响应，并且在多个资源管理器之间协调事务的结果。在它们之间，事务管理器和资源管理器负责可靠地协调对可恢复资源的更新，以便维护原子性、一致性、隔离性和持久性之类的事务规则。为实现此目标，有必要为每个参与者实现一个共同的体系结构标准。在下面的部分中，我们将简要介绍下列标准和协议：

　　J2EE Connector Architecture (JCA)

　　两阶段提交。

　　JCA 是 J2EE 标准的一部分，并指定由资源适配器实现的系统契约。这些系统契约定义资源适配器为事务管理、连接管理和安全提供的服务质量(图 1)。

　　图 1. JCA 系统契约

　　在 J2EE 体系结构中，分布式事务称为全局事务，管理可恢复资源的系统称为资源管理器，示例有 CICS、IMS™ 和 DB2®。这些资源管理器基于它们支持的事务分类，它们或者支持两阶段协作(通过提供 XAResource 接口)、或者仅支持单阶段协作(通过 LocalTransaction 接口)、或者为非事务管理器。

　　对于事务管理，资源适配器需要实现下列契约之一，这在资源适配器的部署描述符中进行了定义(ra.xml 文件)：

　　XA 事务——可以完全参与两阶段提交进程的资源适配器，该资源适配器可以影响全局事务的结果。

　　LocalTransaction——可以参与资源管理器本地事务的资源适配器(在我们的示例中是 CICS 区域)，但该资源适配器不具有任何两阶段提交事务功能。为便于清楚地说明，在本文中(以及在其他与 WebSphere 相关的出版物和论文中)，我们使用术语资源管理器本地事务 (RMLT) 来表示位于单个资源管理器本地的事务。

　　NoTransaction——指无事务属性的资源适配器;它可以参与事务上下文，但不受事务结果的影响(也不影响事务的结果)。

　　WebSphere Application Server 事务支持为事务中任何数量的具有两阶段功能(XA 事务)的资源管理器提供协作。它还允许在事务中没有任何其他资源管理器的情况下使用一个具有单阶段功能的(本地事务)资源管理器。

　　两阶段提交

　　分布式事务处理的基本部分是两阶段提交进程。这是流的体系结构集，用于确保无论发生什么故障，事务中的所有资源管理器都能够可靠地协作。两阶段提交由所有事务协议实现，并且基本概念在本质上是相同的。以下描述根据 XA 规范总结了流;其他协议(如 CICS 或 LU6.2)可能对流使用不同的术语和变体。(有关 CICS 同步点流的进一步详细信息，请参阅《CICS Intercommunication Guide》，SC34-6243，第 2 章“Recovery and restart in interconnected systems”。)

　　在两阶段提交进程之前，事务过程中执行的所有工作都被认为是“在处理中”，并且在此期间如果失败将会导致工作回滚。只有在事务管理器启动两阶段提交进程时，更新才会变得确定。

　　图 2. 两阶段提交

　　在两阶段提交进程的第一个阶段中(或称阶段 1)：

　　事务管理器请求所有资源管理器准备提交可恢复资源(准备)。

　　每个资源管理器可以积极表决(已准备)或消极表决(已回滚)。如果资源管理器积极应答，则它稳定地记录需要这样做的信息，应答已准备，然后必须遵循下一个阶段确定的事务的最终结果。

　　现在可以将资源管理器描述为“未确定”，因为它已将事务的最终结果指派给事务管理器，现在还不知道事务的实际结果。

　　在第二个阶段(或称阶段 2)，假设所有资源管理器都积极应答：

　　事务管理器使用提交流应答每个资源管理器。然而，如果资源管理器未能应答，则在假定事务应中断之前，事务管理器可以重新传输准备流。

　　在接收提交流之后，资源管理器完成对可恢复资源的更新，并释放对资源或打开的文件所持有的任何锁。

　　资源管理器然后使用最终提交的流进行响应，指示事务管理器不再处于未确定状态。

　　如果事务管理器没有收到最终提交的流，则事务管理器必然假定提交未到达资源管理器，因此需要重新传输提交，直至收到积极回复。

　　如果在提交过程中事务管理器失败，则事务可能在资源管理器中处于未确定状态。在重新启动后，事务管理器将与资源管理器重新同步，以发现事务的状态，然后继续执行提交过程，并根据需要提交事务或退回事务。

　　最后的参与者支持

　　在 J2EE 事务环境中，WebSphere Application Server 的最后的参与者支持功能扩展了全局事务模型，可以支持一个单阶段提交资源参与具有任何数量的两阶段提交能力的资源的全局事务。在事务提交时，应用程序服务器 style="COLOR: #000000" href="http://server.it168.com/" target=_blank>服务器首先准备两阶段提交资源管理器，如果成功，则调用单阶段提交资源进行提交。然后，两阶段提交资源或者提交或者回滚，具体取决于来自单阶段提交资源的响应。此过程有效地指派了对单阶段提交资源的事务协作。

　　图 3. 最后的参与者支持

　　与两阶段提交进程不同，单阶段提交资源在通信失败时无法恢复。因此，在提交单阶段提交资源时通信失败会带来混合的事务结果风险(启发式危险)。两阶段提交资源可以回滚，但单阶段提交资源的结果是未知的，它可能已提交或者已回滚。因此，必须将应用程序配置为接受此类启发式结果的额外风险，下文对此进行了详细说明。