事件排序是一个需要处理多重异步请求的技术。这些请求中的一部分或全部必须要有序。一个常见的用例就是用多重请求来更新账户,这个账户必须在存钱或提款前就已经开立好了。本文将演示如何用其开发环境 WebSphere Integration Developer(以下简称为 Integration Developer) 为 WebSphere Process Server(以下简称为 Process Server)配置事件排序。
我们将使用一个 WebSphere MQ 队列来提供一个演示事件排序的异步通道,事件排序也可以用来处理其他类型的输入,例如平面文件和 EIS 系统。从图 1 可以看到我们已经加载了一个虚构的购物订单请求的 MQ 队列。所有相同颜色的记录都要按顺序处理,但其中的紫色、蓝色和红色的记录可以被并行处理。
图 1. 事件排序的例子
事件排序确保了每个颜色的订单都能够按照它们在队列中的排序被加以处理,同时它还允许独立地处理其他颜色的订单。这样可以在不损失数据完整性的情况下更充分地利用服务器。但如果没有事件排序,这些记录就会被串行处理以保持其排序。
一个重要提示:事件排序虽然可以确保具有相同可配置键的消息可以按照它们在异步通道(比如队列)上所处的顺序被处理,但事件排序却不能检查或修改这些消息的排序。例如,如果一个对某个特定键的更新是在插入前被放到队列上的,那么事件排序仍会允许这个更新先发生。
本文的 下载 部分包括了有关如何配置并运行这个应用程序的完整指导。下载文档中包括了分步指导。
- IBM® WebSphere Integration Developer 6.2.0.1,包括一个 WebSphere Process Server 测试环境
- IBM DB2® 8 或 9
- IBM MQ 6 或 7
- 对 WebSphere Integration Developer 和 MQ 有一定的了解
在此示例应用程序中,一个 sender 应用程序将消息按照购物订单号放到一个队列上。这个购物订单号被用作事件排序的键。这个 sender 应用程序会为它所接收到的每个购物订单在队列上放一个插入和两个更新。这些更新可以是任意顺序,但插入总是要放在更新的前面。
一个名为 SOAPUI 的免费软件应用程序可用来向这个 sender 发送 PO 请求。SOAPUI 可以让我们灵活地增加请求与并行线程的数量,借此,我们就可以模拟将大量请求放置到队列上。
图 2 中所示的是这个应用程序的主要组件。
图 2. 事件排序应用程序的布局
在事件排序开启后,程序通常会按 FIFO(先进先出)的顺序处理具有相同购物订单号的那些消息。如果没有事件排序,这些消息将会被异步处理。若更新发生在插入之前,那么在我们试图更新一个因未做插入处理而不存在的记录时,会抛出一个 DB2 失败故障。
WebSphere Integration Developer (开发)
事件排序还需要经过开发和运行时配置这两个步骤
配置事件排序很容易,只需有点 XPath 知识就可以。事件排序一般作为一种 Quality of Service (QoS) 在连接到要被排序的资源的那个组件的接口上配置。在本例中,接口指的是具有 MQ 导出并需要按顺序处理消息的一个过程的接口。从图 3 和图 4 可以看到事件排序限定词的 QoS 设置。
图 3. 事件排序应用程序的组装图
图 4. 事件排序 QoS 设置
查看了接口的属性后,可以发现为本例添加的事件排序限定词。这个 XPath 表达式/数字引用了名为 PO 的这个业务对象中的一个属性,这个 PO 代表的是这个例子中的购物订单。图 5 中定义了此 PO 模式。
图 5. PurchaseOrder 业务对象模式
这样,就可以确保具有相同单号的所有购物订单都能够按其在队列上的最初顺序被处理。
WebSphere Process Server (运行时)
在本文的这个例子中,通过 Integration Developer 内的一个 MQ 导出绑定集,一个 MQ 队列被用作这个排序的源。当在 Integration Developer 中定义一个 MQ 导出时,一旦部署在 Process Server 内,就会生成一个侦听器端口。
这个消息侦听器服务是由基础运行时提供的,并管理负责侦听此队列的 Message Driven Bean 的运行时配置。这包括所生成的侦听器端口、它的运行时状态及侦听器服务设置。在使用 MQ 绑定和事件排序时,必须在这个 messagelistener 服务上设置一个定制属性,如图 6 所示。
图 6. 来自于 Administration Console 消息侦听器服务的定制属性
具有非零值的 NON.ASF.RECEIVE.TIMEOUT 是侦听器端口上的一个必备定制属性,因为事件排序需要严格的消息顺序。
要获取关于此设置的更多信息,请参阅 WebSphere Application Server Information Center 中的主题 消息侦听器服务定制属性。
在侦听器端口配置属性中,需要定义一个 Max Sessions 变量,如图 7 所示。
图 7. 为侦听器端口设置 Max Sessions
默认情况下,“Maximum sessions” 字段表明有一个 Message Driven Bean 正在队列上侦听。为了能让事件排序正确工作,此值必须保持为 1 以便所有请求都能被相同的 singleton 做排序处理。一旦消息被排好序,它就会将那些排了序的消息放在由服务集成总线提供的 SCA 内部队列上。由于这些消息不共享同一个键值,Process Server 可以用多重线程从这个内部队列处理这些消息。
注意:在一个集群 Process Server 环境中,整个集群中只能启动一个侦听器端口。侦听器端口可以通过编写脚本或从 Process Server Administration Console 启动或终止。在一个集群环境中,在所有集群成员上,需要在服务器启动时只开启一个侦听器端口同时禁用其他所有的侦听器端口。
需要按顺序处理的这些消息由客户机应用程序放入 MQ Ext Queue。在 Process Server 上定义的这个侦听器端口侦听这个队列,并且从 MQ Ext Queue 一次读取一个消息,并对它进行排序,然后将它放在 SCA Int Event Queue 上。倘若在 Event Lock 表(图 8)内有一个可用的锁定,Process Server 就会读取来自于 SCA Int Event Queue 的消息以便处理。如果出现两个以上的消息具有相同的排序 ID,就需要应用一个锁定。如有在一个给定的排序 ID 上有一个锁定,那么只有在这个锁定可用后,该消息才会被处理。默认情况下,Process Server 可以提供 100 个锁定来处理这些排好序的消息。这些锁定可针对此运行时配置。
图 8. 事件排序的图示
假设对于一个给定的排序 ID,需要一个插入记录处理,后跟 Update #1 记录和 Update #2 记录处理。如果由于某些问题(比如,消息内的不良数据),Update #1 未能被处理,那么在设计时有两个选择:一是选择继续进行 Update #2 的处理,一是等待 Update #1 被纠正和处理完毕。此特性被称为消息的严格排序。需要在 WebSphere Integration Developer 内的设计时恰当选择这一特性。图 9 显示了这个特性。
图 9. 消息严格排序的选项
这个失败的事务将显示在 Failed Event Manager 中,在这里,可以修改数据并重新提交数据以做处理。更多关于 Failed Event Manager 的信息,请见 管理 WebSphere Process 服务器失败事件。
当异步请求处理需要排序时,事件排序是一种常用模式。事件排序可以被应用于很多入站资源,包括平面文件记录、EIS 系统和队列。它还经常在 SCA 适配器或队列的一个导出完成后立即应用于此接口。在本文中,我们已经展示了在 WebSphere Process Server 内使用事件排序的配置和运行时的特点。此外,在下载部分还有关于配置及运行这个示例程序的指导。
| 描述 | 名字 | 大小 | 下载方法 |
|---|---|---|---|
| 代码示例 | EventSequencingFromMQDownload.zip | 5374 KB | HTTP |
学习
讨论

Greg Wadley 是 West Integrated Marketing Team 的一名高级 IT 顾问专家,负责为 WebSphere 软件产品提供技术销售支持,并主要致力于业务集成和业务过程管理。Greg 为 IBM 的顶级客户提供实用的概念阐释、架构培训、课堂指导和技术销售演示。他在 IT 行业有 20 多年的工作经验,担任过各种职务。

Satish Mamindla 是 West Integrated Marketing Team 的一名高级 IT 顾问专家,负责为 WebSphere 软件产品提供技术销售支持。Satish 还致力于概念的阐释以及进行 Proof of Technology 的课堂培训以展示产品特性。Satish 在 IBM for Software Services for WebSphere (ISSW) 担任 WebSphere 顾问时服务的客户遍布全球。他使用 WebSphere 产品套件帮助客户设计和开发各种解决方案并帮助优化客户的系统以供生产之用。