java soa 事务_构建事务型SOA

在企业应用程序集成 (EAI) 领域中，所有参与的系统必须在整个全局事务下操作，以便这些系统在发生故障的情况下都返回到一致的状态。在支持不同协议的各种系统中，事务语义必须在这些协议中进行传播，以便这些协议可以无缝地参与全局事务。本文将通过一个示例向您详细介绍使常见集成场景成为事务集成所需的步骤。

企业正逐渐转为使用面向服务的方法来实现 EAI 。本文的目标是演示在将 IBM® WebSphere® Process Server 用作基于面向服务的体系结构 (SOA) 的企业集成平台时的事务控制和传播。WebSphere Process Server 运行在基础 IBM WebSphere Application Server 平台上，该平台为 WebSphere Process Server 提供核心分布式事务功能。在 WebSphere Process Server 中执行的关键组件类型(例如业务流程执行语言 [BPEL]、人工任务、业务规则和状态机)都符合服务组件体系结构 (SCA) 规范。

注意：本文假设您熟悉 WebSphere Process Server、IBM WebSphere MQ、IBM WebSphere Integration Developer、Enterprise JavaBeans (EJB) 组件和 Web Serivces 。

开发和测试此解决方案的环境为：

WebSphere Process Server 和 WebSphere Integration Developer V6.0.2.x

WebSphere MQ V6.0.2

IBM DB2® Universal Database V8.1.14.292

Oracle Database 10g Express Edition Release 10.2.0.1.0

考虑具有以下三种系统的情况：A、B 和 C。

系统 A：通过在 WebSphere MQ 队列上放置消息来生成事件。需要将此事件传播到系统 B 和 C。

系统 B：在接收此事件(从系统 A)时，系统 B 将数据插入到其数据库中。系统 B 提供 EJB 接口并使用 DB2 作为后端。

系统 C：在接收同一事件(从系统 A)时，系统 C 从其数据库中删除数据。系统 C 提供 Web Serivces (WS) 接口并使用 Oracle 作为后端。

此场景的成功依赖于系统 B 和 C 是否都成功完成其各自的事务。如果不能成功完成，则系统 B 和 C 需要返回到它们接收事件之前的初始状态，并且初始事件数据必须移动到临时保存的队列。

建议的解决方案使用的方法是将 SCA 组件(BPEL 流程)定义为用于此集成的协调器。它侦听 WebSphere MQ 队列上的输入，然后调用这两个系统公开的、需要传递接收的数据的 EJB 组件和 Web Serivces接口。图 1 描述了建议的解决方案。

不过，此解决方案实现前一部分中声明的需求的关键是使用 WebSphere 中的分布式事务功能。WebSphere 充当事务协调器，并作为在各种资源管理器(包括 DB2、Oracle 和 WebSphere MQ)中分布的单个分布式工作单元管理上面的场景。

本文向您介绍如何结合使用 SCA 事务限定符、Java™ 2 Platform. Enterprise Edition (J2EE) 事务规范、Web Service Atomic Transaction (WS-AT) 规范定义和 WebSphere MQ 设置来创建事务型企业集成解决方案。

正如前面提到的，本文的重点是演示各种组件如何在单个事务下工作。因此，您会看到使用了非常简单的数据类型和组件逻辑。本文的重点并不是介绍 BPEL 的所有特征和功能、业务对象和接口定义或组件开发的详细信息。本文还介绍了项目交换文件，该文件包括用于模拟上述系统和演示事务传播的所有组件(请参阅下载部分)。

PIF(项目交换文件)包含以下元素：

SYSTEMA：此 J2EE 项目模拟系统 A。它包含将消息放在 WebSphere MQ 队列上的 Servlet。在 WebSphere MQ 服务器上和 WebSphere Process Server 中的 WebSphere MQ JMS 提供程序上创建了适当的队列定义。在 WebSphere Process Server 中的 WebSphere MQ Java Message Service (JMS) 提供程序上定义了 XA WebSphere MQ Connection Factory，以便与 WebSphere MQ 进行通信。

DB Helper：此 Java 项目包含 helper 类，该类让实际的 JDBC 代码分别连接 DB2 或 Oracle 数据库表以及插入或从中删除数据。此项目还包含用于 DB2 和 Oracle 的客户表的数据定义语言 (DDL) 文件。

SYSTEMB：此 J2EE 项目模拟系统 B。它包含使用 DB Helper 项目中的 Java 类将数据插入到 DB2 数据库表的 EJB 组件。XA 数据源已在 WebSphere Process Server 上定义，并用于与 DB2 进行通信。

SYSTEMC：此 J2EE 项目模拟系统 C。它包含公开为 Web Serivces 的 EJB 实现，Web Serivces 使用 DB Helper 项目中的 Java 类从 Oracle 数据库表中删除数据。XA 数据源已在 WebSphere Process Server 上定义，并用于与 Oracle 进行通信。

Integrator：此模块包含作为 BPEL 流程实现的 SCA 组件。SCA 组件使用 WebSphere MQ JMS 导出(export)来接收 WebSphere MQ 队列中的消息。它使用 WS 和无状态会话 Bean EJB 导入(import)分别与系统 B 和系统 C 的 EJB 和 WS 接口进行通信。

在本部分中，将重点定义在建议的解决方案部分中定义的各种组件的事务方面。

图 2 显示了包含 Integrator SCA 流程的模块 (Integrator) 的组装关系图，该流程包含 WebSphere MQ 和 JMS 导出和两个导入：一个到无状态会话 Bean(通过映射程序)，另一个到 Web Serivces 。

您需要在接口/操作级别和 SCA 组件的实现级别设置事务限定符。在导入的接口/操作级别设置它们。图 3 至 9 显示了如何设置这些限定符。

现在已经启用了调用系统 B 和系统 C 接口的 Integrator 组件上的事务设置，您必须确保到系统 B 和系统 C 的接口如以下两部分中描述的那样在事务上下文中执行。

EJB 组件的事务模型由 J2EE 规范定义。所有 J2EE 供应商(本例中为 WebSphere Application Server)实现规范，为 EJB 组件提供事务功能。

共有两种事务支持形式：

容器管理的事务 (CMT) 涉及在 EJB 部署描述符上定义适当的事务设置。

Bean 管理的事务 (BMT) 涉及在会话或消息驱动的 Bean (MDB) 中使用代码，以使用 Java Transaction API (JTA) 显式标记事务的边界。

注意：有关 EJB 事务模型的详细信息，请参阅本文结尾处的参考资料部分。

请注意，SYSTEMB 提供无状态会话 Bean 接口并使用 CMT。

无状态会话 Bean 的声明式事务设置可以在 EJB 部署描述符 (ejb-jar.xml) 中完成。缺省情况下，EJB 远程接口上的所有方法具有 TRANSACTION_REQUIRED 的事务设置(请参见 10)。

在 EJB 实现代码中，作为异常处理的一部分将事务设置为 Rollback，如图 11 所示。

无状态会话 Bean 使用 DBHelper 类(使用了 JDBC 声明)执行数据库事务。为 DB2 数据库定义了 XA 数据源，并使用它执行 JDBC 声明。

用 WS-AT 规范定义 Web Serivces 的事务模型。(注意：此规范的详细内容超出了本文讨论的范围。有关 WS-AT 的详细信息，请参阅参考资料。)在 WebSphere 中启用对 Web Serivces 的 WS-AT 支持是声明性的。您只需对部署描述符进行简单的更改，不需要任何编码。系统 C 提供 Web Serivces 接口。此 Web Serivces 是通过将 EJB 组件公开为 Web Serivces 生成的。此同一 Web Serivces 可能已成为 Microsoft® .NET 组件，因为此处使用的事务规范是由 WebSphere 和 .NET 实现的 WS-AT。

在 SYSTEMCWeb 项目中打开 web.xml 部署描述符，并选择 Servlets 选项卡。图 12 显示了需要为 WS-AT 启用的简单设置。

Web Serivces 实现使用 DBHelper 类(使用了 JDBC 声明)执行数据库事务。为 Oracle 数据库定义了 XA 数据源，并使用它执行 JDBC 声明。

现在，让我们设置 WebSphere MQ 队列管理器和两个队列：

发送消息的队列 (MQREQUESTQ)

如果存在事务故障，则使用临时回滚队列 (ERRORQ)

将 MQREQUESTQ 上的回滚阈值设置为 1(参见图 13)。

在 WebSphere 中的 WebSphere MQ JMS Provider 上，设置启用 XA 的 WebSphere MQ Queue Connection Factory (QCF)。SYSTEMA 使用此 QCF 将消息放在队列上，并通过 Integrator 组件从队列拾取消息。

在允许 Integrator 组件侦听 MQREQUESTQ 的 WebSphere 中设置侦听器端口。确保将 Maximum retries 字段设置为 2。此设置以及 MQREQUESTQ 上设置为 1 的回滚阈值可以确保在发生事务故障时，当消息回到 MQREQUESTQ 时，可以将该消息移动到临时队列，即 ERRORQ(参见图 14)。

在本部分中，将重点部署上述构件和测试成功及失败场景，借以演示如何满足需求。

我们将 WebSphere Integration Developer 中的 WebSphere Process Server 测试环境用作部署目标。

在同一服务器上部署所有组件，其中包括集成组件和系统模拟器(SYSTEMA、SYSTEMB 和 SYSTEMC)。在实际环境中，它们将部署在不同的服务器上。

在 WebSphere Process Server 测试环境中启用 TCPMON，以查看带有 WS-AT 标头的 SOAP 消息(参见图 15)。

作为第一个测试案例的一部分，您将测试成功场景，最后将新的数据库插入到 DB2 数据库，并从 Oracle 数据库中将其删除。

作为第二个测试案例的一部分，您将测试失败场景。您关闭了 Oracle 数据库，以防止 SYSTEMC 完成事务，因此该事务进行了回滚。数据没有插入到 DB2，并向 ERRORQ 记录了一条消息。

图 16、17 和 18 显示了执行成功场景之前的系统状态。DB2 CUSTOMER 表中没有任何数据，但 Oracle 表中存在数据。在 WebSphere MQ 上的 ERRORQ 中没有任何消息。按照先后显示的图片查看；它们演示了初始状态。

执行成功的场景后，数据应插入到了 DB2，并根据需求的定义从 Oracle 中删除了这些数据。因为没有任何错误，所以 WebSphere MQ ERRORQ 中没有任何消息。SOAP 消息显示了 WS-AT header 信息，该信息演示了事务到 WS 接口的传播内容。

成功场景：执行 URL http://localhost:9080/SYSTEMAWeb/SystemASimulator?fileName=success_customer.xml。注意：文件 success_customer.xml 中的客户数据被放入 WebSphere MQ 队列。

图 22 至 25 显示了执行失败场景后的系统状态。通过关闭 Oracle 数据库模拟了此故障。SYSTEMC 无法完成其事务。尽管向 DB2 成功地插入了数据，但是当整个分布式事务回滚时，仍可以确保插入到 DB2 的任何数据和初始消息不会移入 WebSphere MQ 的 ERRORQ。满足了在发生故障时让系统保持其初始状态的要求，并按照要求初始消息不在 WebSphere MQ 队列中。

失败场景：执行 URL http://localhost:9080/SYSTEMAWeb/SystemASimulator?fileName=failure_customer.xml。注意：文件 failure_customer.xml 中的客户数据被放入 WebSphere MQ 队列。

 

EAI 涉及对支持不同技术接口的各种应用程序的集成。因此，了解如何实现事务型集成系统非常重要，它可以确保在参与者之一发生故障时数据的完整性和一致性。由于工具和技术日益成熟，实现此类强健的解决方案变得越来越容易——甚至比本演示还容易。