本文共 5725 字,大约阅读时间需要 19 分钟。
在企业应用程序集成 (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 。
开发和测试此解决方案的环境为:
考虑具有以下三种系统的情况:A、B 和 C。
此场景的成功依赖于系统 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(项目交换文件)包含以下元素:
在本部分中,将重点定义在部分中定义的各种组件的事务方面。
图 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 组件提供事务功能。
共有两种事务支持形式:
注意:有关 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 队列管理器和两个队列:
在本部分中,将重点部署上述构件和测试成功及失败场景,借以演示如何满足需求。
作为第一个测试案例的一部分,您将测试成功场景,最后将新的数据库插入到 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 涉及对支持不同技术接口的各种应用程序的集成。因此,了解如何实现事务型集成系统非常重要,它可以确保在参与者之一发生故障时数据的完整性和一致性。由于工具和技术日益成熟,实现此类强健的解决方案变得越来越容易——甚至比本演示还容易。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/14789789/viewspace-417708/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/14789789/viewspace-417708/