将 IBM WebSphere Application Server 与 WebSphere MQ 系列集成在一起

Kareem Yusuf，博士
中间件咨询专家
IBM 全球 MQSeries 技术销售支持
2001 年 10 月

介绍

当今解决方案的典型特征是要求将不同的软件组件集成在一起。在电子商务体系结构中，下面这些组件的集成正变得越来越常见：

应用程序服务器，为 JSP™、servlet 和 EJB 提供运行服务。
异步消息传递，连接各种应用程序（业务）。
消息中介者，提供数据传输和路由服务。
流程管理器，协调许多应用程序间的交互以达到一个业务目标（那就是，使它们都在业务流程上下文中）。

不要惊讶，解决方案的每个组件（不管是应用程序服务器、消息中介者等等还是其它）都需要相关的技术，并且可能属于企业的不同部门。但是，在制定解决方案时，开发者必须考虑各种不同组件之间的交互是如何影响应用设计的。

在本文中，我研究了 WebSphere® Application Server 和 WebSphere MQ 系列的成员之间的交互，以及它们在应用设计上的互相关联。我重点突出了要考虑的部分，并为设计使用这套产品的解决方案提供指导。

WebSphere 软件平台

IBM 的 WebSphere 软件平台封装了一些领先产品，这些产品提供用于构建电子商务解决方案的平台。在本文中，我讨论了实现上述功能的下列产品。

应用程序服务器（Application Server）： WebSphere Application Server
消息传递（Messaging Transport）： WebSphere MQ（MQ，以前称为 MQSeries®）
消息中介者（Message Broker）： WebSphere MQ Integrator（WMQI，以前称为 MQSeries Integrator）
流程管理器（Process Manager）： WebSphere Process Manager（WSPM，以前称为 MQSeries Workflow）

假定您对这些产品已有基本的了解。（也可参考下面的参考资料，以便获得对这些产品的更详细描述。）

WebSphere Application Server 与 MQ 集成

运行在 WebSphere Application Server 上的应用程序是通过 Java™ 消息服务（Java™ Message Service，JMS） API 与 MQ 集成在一起的。参见下图 1。JMS 是 API 的一个标准集，为调用异步消息传递服务的应用程序提供框架，而几乎不考虑实际使用的消息传递产品。JMS 与 JDBC 和 JNDI 非常类似，只不过是 JDBC 提供了可移植性地访问数据库，JNDI 提供了可移植性地访问命名目录服务。

图 1. WebSphere Application Server 与 MQ 集成

JMS API 支持两种消息传递方式（域），点对点（PTP）和发布／订阅（Pub/Sub）。使用 PTP 时，消息只发送给一个目的地，且只被一个接收方接收。使用 Pub/Sub 时，消息被发送给一个中介者（被发布），然后此中介者将消息分发给许多订阅者。

这两种不同方法是通过 Java 和 JMS 的 MQSeries 类 — MA88（IBM 为 MQ 开发的 JMS实现）来实现的。MA88 允许将应用程序使用 JMS API 中，以便利用 MQ 提供的服务，采用 PTP 或 Pub/Sub 方式来传递消息。Cox 和 Wadley 在他们的文章“在 WebSphere 和 VisualAge® for Java 中使用 Java 消息服务，第 1 部分和第 2 部分”中提供了详尽的，亲身的建立 WebSphere Application Server、MA88 类和 MQ 应用环境的指导。（请参阅下面的参考资料。）

应用程序间的交互由 WebSphere Application Server 和消息传递服务 MQ 进行管理，其中包括发送或接收来自 MQ 队列由 MQ 队列管理器（MQ Queue Manager）管理的消息。这种交互可分为以下 3 种关键模式：

消息产生者（“发送和忽略”）
请求／应答（“往返传递”）
消息消费者

现在我将讨论这些模式和它们在设计上的含义以及解决方案的实现。

消息产生者

消息产生者模式，如下图 2 所示，其中包括发送消息（数据报)。一旦消息被安全传递给 MQ 队列管理器，发送应用程序与消息传递服务的交互便告完成。用法示例包含发送注册信息、付款或数据填充，其中消息产生者持续发布事件数据（例如，股票价格）。

图 2. 消息产生者模式

从应用程序的角度来看，首先应考虑的一件事就是 MQ 是否应该持久保留消息。当 MQ 持久保留消息（持久性消息）时，它确保万一 MQ 队列管理器处理失败时，消息可以恢复；相反，在 MQ Queue Manager 处理失败时，非持久性消息则无法恢复，但由于它们的处理不会引起任何磁盘 i/o 操作（为了持久性）， MQ 队列管理器在处理它们时速度会更快。

使用持久性消息还是非持久性消息通常取决于业务要求。在提供股票价格数据时，当前数据是在一个相对较小的窗口内被更新；相应地，消息丢失造成的影响也很小，由于数据关联性很快会被下一次发布（发送）取代，因此这些消息通常是非持久性的。但是，在发送注册信息时，用户期望只仅仅提交一次注册信息，相应地，会选择持久性消息传递以确保不管发生什么样的中断，信息都会被传递。

应用程序可以将消息作为工作单元（事务）的一部分发送，这意味着某个时刻应用程序或应用程序服务器会提交事务来影响发送（ WebSphere Application Server，版本 3.5.3 和 MA88，版本 5.2 可提供这种便利的功能）。虽然从消息传递的角度来看，一旦把消息发送除去，应用程序交互便告结束，但应用程序可能仍会向用户返回确认任务完成的响应。

消息产生者实现的注意事项

尽管应用程序这个普通术语，已经被用于指代运行在应用程序服务器上的消息产生者，但仍存在下列问题：消息产生者出现在什么实体上？“模型-视图-控制器”（Model-View-Controller）模型建议对企业资源的访问（消息传递基础构造）应该通过会话 EJB 进行。如果您希望将消息作为事务（将由 Application Server 统一管理）的一部分发送（例如，发送消息并更新事务中的一个本地数据库），那么就必需使用 EJB。但是，在 servlet 中实现消息产生者也是很常见的；这就提供了一种更简单的（与 EJB 相比）编程框架，但也随即无法使用全局工作单元，或无权使用 WebSphere Application Server EJB 容器提供的其它任何特有功能。

请求／应答

如下图 3 所示，请求／应答模式包括发送请求消息和等待应答。一个普通的用法示例可能会是一个状态请求，比如请求帐户余额。请求／应答模式中最重要的因素是时间（也就是应答到达所需的时间）。您应该记住：请求／应答模式本质上是异步传输上的同步交互。

因此，通常使用的是非持久性消息传递，就好象尚未在给定的时间内接收到应答；应用程序采用一条异常路径，有可能重新提交请求。但是，如果使用情况包括发送注册请求（就象消息产生者示例中那样）并等待确认应答，请求就很可能是持久性消息，在给定的时间帧内接收不到应答，就触发“稍后核对”机制。

图 3. 请求／应答模式

不管在哪种情况下，您都必须考虑如何处理应答延迟问题，在规定的时间帧内没有到达并不意味着消息根本不会到达。消息到期，MQ 消息的一个属性，在这种情况下证明是有用的。为应答消息设置了到期时间后，如果在一个给定的时间帧内没有检索到此消息， MQ 队列管理器会将其废弃。估计将来许多客户机应用程序实例可能会共享用于发送和接收请求／应答的相同的消息传递基础结构（队列）。在这种情况下，应用程序可以将它们的请求和应答关联起来 — 使用 MQ 消息的消息／关联标识属性，从共享队列中选出它们的特定应答。另一种供选的设计允许每个客户机实例拥有自己的应答队列。当不知道客户机数目时，MQ 允许应用程序在运行时创建动态队列，在被删除之前，此队列持续的时间可以和应用程序的生命期一样长。是否采用这种方法一般取决于性能的要求。

那些不熟悉消息传递应用程序的人通常会犯这样的错误 — 设法在同一个事务中发送请求，接收应答。由于在事务被提交之前无法发送请求，而直到接收到应答才能提交事务，所以在同一个事务中发送请求，接收应答是没用的。因此记住这一点很重要 — 在采用请求／应答模式时，在同一个事务中发送请求并等待应答是不可能的。如上图 3　所示，需要两个事务：一个用于发送消息，一个用于接收应答（虽然每个事务自身可能包含另一个资源，如一个数据库）。

请求／应答实现的注意事项

在使用 EJB 会话 bean 实现此模式时，有一点需要注意的是，在 EJB 线程被阻塞期间 EJB 需要等待应答。某些考虑事情比较绝对的学派憎恨 EJB 容器中的阻塞的线程概念，特别是在很可能存在大量 EJB 会话 bean 实例（阻塞的线程）的时候。

另一种供选实现方法是让 EJB 会话 bean 作为消息产生者，其它的一些实体例如 servlet，处理应答消息并将其传递给一个 EJB 实例（消息消费者模式）。但是，如果全局事务内待处理的应答消息包含一个数据库，使用除 EJB 之外的任意东西检索消息，这是不受欢迎的（在下一部分，我将讨论为什么目前无法将 EJB 实现为消息消费者）。

如果发送 EJB 是要充当其应答的接收方，您必须仔细考虑允许 EJB 等待的时间长度（以毫秒为单位），以及它对应用程序服务器环境的影响。

消息消费者

如下图 4 所示，消息消费者模式以 WebSphere Application Server 中的一个应用程序开始，在消息到达某个特定的队列时被触发。在这种模式下，Application Server 可能会管理业务应用服务请求，也可能是接收更新（如在线目录的改变）的前端应用程序服务器。如上面请求／应答实现的注意事项这一部分所述，消息消费者甚至可以根据对消息产生者发送的请求的应答行事。

图 4. 消息消费者模式

我已经讨论过关于消息持久性和事务处理作用域的注意事项。根据业务需要，消息可以是持久性的，也可以是非持久性的，消息的接收方可以是全局事务的一部分。

消息消费者实现的注意事项

在 JMS 中，消息侦听器接口提供实现消息消费者的支持。实现消息侦听器类的 Java 类实现 onMessage 方法。onMessage 方法是在一个消息到达指定队列时，由 JMS 实现调用的。

当使用消息侦听器时，应用程序不是发出一个被阻塞的等待／接收，而是为感兴趣的队列注册一个消息侦听器。这暗示 JMS 实现使用的是多线程设计，这样工作程序线程执行实际被阻塞的接收（一般采用轮询机制 — 不建议无限期地等待），一旦收到，马上将检索到的消息发送到消息侦听器的 onMessage 方法。但是，EJB 1.0 和 EJB 1.1 规范声明“EJB 不准启动新线程，或尝试终止正在运行的线程。”原因是那样会使容器无法正确管理资源，因此 EJB 不应该实现消息侦听器类。

EJB 2.0 提供了一种权宜方法 — 消息驱动器 Bean（Message Driven Bean，MDB）。这些是实现消息侦听器接口的 EJB，而 EJB 容器负责监视队列（这些队列被指定为 MDB 的部署描述符的一部分）。容器衍生并管理必需的工作程序线程，保护 EJB 环境的完整性。当消息到达时，该容器调用 MDB 的 onMessage 方法，传递获得的消息。遗憾的是，在撰写本文时，EJB 2.0 仍然只是建议终稿，这意味这它还不是一个最终规范。因此，应用程序服务器厂商无法在它们的产品中以任何形式提供 EJB 2.0 支持，只能把它们作为一种技术前瞻（不应将它们用于生产）。因此，WebSphere Application Server 尚未提供对 MDB 的支持。这意味着目前我们还需要一种供选方法。

基本的方法是在容器外监视队列，将消息数据传递给 EJB（如果需要的话），以便进行进一步处理。一般情况下，是使用 Servlet（由 Application Server 启动）和单独的 Java 应用程序执行这种任务。在论文 “WebSphere JMS/JTA support for MQSeries Overview”中，Hogdson et al. 讨论了使用 com.ibm.ejs.sm.server.ServiceInitializer 接口来指定一个服务实现消息消费者，Application Server 会在启动时启动该服务并在关闭时终止该服务（请参阅下面的参考资料）。如果希望 EJB 检索实际消息，将它调整为带有数据库的全局事务的一部分，消息消费者可以“刺激”EJB，通知 EJB 期望的消息现在已在队列中。这样会使消息消费者浏览队列而不是从队列中检索消息，并将消息标识符发送给 EJB 以便立即检索。显然，您必须仔细考虑额外处理的开销以及它对总的等待时间的影响。

容器管理的消息传递（Container Managed Messaging）

应用程序服务器应该根据消息传递提供的工具仍在定义中。例如，记住我们关于对消息驱动 Bean（Message Driven Bean）的支持的讨论（请参阅消息消费者实现的注意事项部分）。另一个将影响消息传递应用程序在 WebSphere Application Server 中的实现的新兴规范是容器管理消息传递。

容器受管消息传递（CMM）将与消息传递进行交互的责任都转移给了 EJB 容器。EJB 将能够使用消息传递工具而无需显式调用 JMS。这一点与容器受管持久（CMP）类似，无需开发者实现任何数据库调用，实体 EJB 中的数据就可以与适当的数据库表保持一致。消息传递交互能够有效地通过工具自动进行，这对于简化应用程序开发将有重大意义。

根据这些新兴的规范，选选择 EJB 作为实现实体对开发者来说已变得更有吸引力，因为它将在充分利用 EJB 容器即将出现的特有功能时，占据有利位置。

物理位置的注意事项

关于是否在同一个机器上部署队列管理器和应用程序服务器有很多因素您必须考虑。 MQ 允许应用程序作为一个客户机或本地（服务器）应用程序连接到 MQ Queue Manager。客户机连接方式允许应用程序在 MQ 队列管理器的远程机器上运行并使用一个网络交换协议（TCP/IP）调用服务。客户机连接不支持全局事务协调，通信的分布式本质会导致“不确定”状态，在这种状态下，应用程序不能确定它的 MQ 请求是否被成功处理（因为在接收到响应之前连接丢失了）。

相反，本地应用程序（绑定）必须作为队列管理器运行在同一机器上，通过进程间通信（MQJMS 实现使用了 JNI 对队列管理器的 C 库进行调用）调用队列管理器服务。显然，本地连接提供比客户机连接更好的性能优势，如果 WebSphere Application Server 要充当事务协调器，也要求使用本地连接。通常情况下，MQ 队列管理器的存储和其主要的功能（作为 Application Server 应用的存储和转发机制）意味着从硬件角度来说将 WebSphere Application Server 和 WebSphere MQ 托管在同一个机器上是可行的。实际上，这种配置正越来越流行。

进入 WebSphere MQ Integrator

WebSphere MQ Integrator（WMQI）是 IBM 的消息中介者解决方案。它通常负责从 MQ 队列检索消息并按照已定义好的消息流（各项功能操作顺序是由接收到的消息决定的）对它们进行处理。消息流封装了一些处理逻辑如数据传输和动态路由，典型情况下以一个输出操作结束，此操作通常将消息发送给许多 MQ 队列。

从 WMQI 中的消息处理逻辑一般通过消息到达 MQ 队列来调用的角度来看，那么引入 WMQI 并不会改变集成应用中的各个功能组件。参见下图 5。WebSphere Application Server 中的应用程序仍要参与发送消息和从队列中检索消息，但是，一个新的要注意的问题出现了，它与应用程序正通过 MQ 消息发送的数据有关。

图 5. 进入 WebSphere MQ Integrator

在 JMS 中，存在着许多消息对象，它们代表出应用程序可能想要发送或接收的各种不同的数据种类。这些数据种类如下：

JMSBytesMessage： 无格式二进制数据
JMSTextMessage： 字符数据
JMSStreamMessage： 格式化的数据字段序列
JMSMapMessage： 格式化的数据字段集（名称／值对）
JMSObjectMessage： 序列化的 Java 对象

MQ 消息的正文部分携带与这些消息类型相关的有效载荷。MQ 不了解正在通过特定消息传递的数据，所有的数据都被视为一个字节序列。这是因为它的任务只是根据指定服务质量（例如，持久性）将数据传送到一个特定的端点。相反，WMQI 中的消息流通常要求了解组成消息的各个域，这样它们就能够影响所需的处理逻辑（例如，将一个域从 XML 映射到记录结构）。这就引起了下列问题：WMQI 怎样知道如何对一条消息进行解析，更重要的是，对于运行在 WebSphere Application Server 中的应用程序，如果有什么含义，这些含义又是什么？

WMQI 消息模型

WMQI 的消息模型将检索到的消息映射到消息字典中的模板（元数据），向消息流返回一个消息树（语法分析树），这样便可在处理期间访问元素。然后，在消息流的结束处，可根据消息树的当前状态构建一个物理消息，并将其输出到一个 MQ 队列，如下图 6 所示。

图 6. WMQI 消息模型

WMQI 提供能够对消息格式进行建模的消息库和工具。消息格式可以分为两大类：

面向记录
这种消息由许多按次序排列的固定长度的元素组成。
标记定界／可变长度
消息的元素用标记，如分号、逗号或空格分开，因此元素的长度是可变的（如 XML 专门设计成这样）。

WMQI 依赖许多与 MQ 消息有关的属性来识别消息正文的内容，从库中选择合适的模板（元数据）。这些属性是消息域、消息集、消息类型和消息格式。消息域是关键属性（因为它设置其它属性的基本信息）并具有下列属性之一：

XML: 消息正文是 XML 格式，不存在元数据。使用一般的 XML 解析器进行语法分析。
MRM: 此消息正文的元数据是在消息库管理器（Message Repository Manager）中定义的。使用相关的消息集、类型和格式检索合适的模板。
NEONMSG: 此消息正文的元数据是在“新纪元网络格式库”（New Era of Networks Formatter Repository）中定义的，使用相关的消息集和类型检索合适的模板。
JMSMap: 消息正文包含一个 JMSMapMessage 对象。JMSMapMessage 对象表明是 XML 消息，它可以很容易地提供名称／值对结构。
JMSStream: 消息正文包含一个 JMSStreamMessage 对象。JMSStreamMessage 对象表明是 XML 消息，它被用于描述域的次序、类型和值。
BLOB: 不对消息正文进行语法分析。

消息属性对应用设计的影响

消息属性可定义为 WMQI 中消息流的缺省值；这意味着被消息流处理的全部消息都会被当做指定的类型（格式）对待。但是，在要求给定的消息流处理不同类型的消息时，每个消息都要带消息属性，各个消息被分别识别为特定的类型。在这种情况下，属性由发送应用程序设置。

消息属性放在特定的 MQ 头（MQRFH2）中，运行在 WebSphere Application Server 中的应用程序要注意的关键一点是 WMQI 中定义的逻辑是否要求它在发送消息之前明确识别出消息的格式。如果要求或期望这样，那么 MQ JMS 实现以一种不会影响 JMS API 的可移植性的方式来设置属性。（也就是，JMS 应用程序不应该包含特定于厂商的代码）。对于 JMSText 和 JMSByte 消息，您可以使用 setJMSType 方法设置消息属性：

setJMSType("mcd://domain/set/type/fmt");

要设置消息属性，WMQI 开发小组必须向应用程序开发者提供域、集等属性的合适的值。

WMQI 作为 JMS 发布／订阅中介者

WebSphere Application Server 与 MQ 集成部分已提到，运行在 WebSphere Application Server 中的应用程序可以使用 JMS 发布／订阅模式与 MQ 进行通信。这与点对点模式不同，它是根据识别主题将消息发布给一个中介者，而不是发送给单个接收方。中介者将消息分发给那些注册了与发布的消息相匹配的订阅（也就是，感兴趣的主题）的订户。我早先讨论的消息传递模式仍适用于消息产生者发布应用程序、消息消费者订阅应用程序和既充当发布者又充当订户的应用程序（那些发布者和订户松散地映射到请求／应答模式）。

WMQI 充当发布／订阅中介者，通过订阅应用程序来注册自己的订阅，并通过发布应用来发送消息到中介者，然后中介者将这些主题映射到已注册的订户并将消息转发给所有的有意方。除使用不同的 API 集之外，我在前面部分提出的注意事项仍然适用。注意：即使分发机制延期（消息通过了中介者），应用程序基本上仍要发送和接收来自队列的消息。

将 WebSphere Process Manager 引入方案中

WebSphere Process Manager（WSPM）允许从业务流程的角度为应用程序交互建模；已建模的业务流有可能调用参与的（包括与人类的交互）或不参与的应用程序。下图 7 描述了运行在 WebSphere Application Server 中的应用程序可以与 WSPM 进行交互的两种方法：通过 Web 客户机和 XML 消息传递接口。

图 7. 将 WSPM 引入图中

Web 客户机

Web 客户机封装了许多 JavaServer Pages™ 和 Java bean，它们提供对 WSPM 客户机 API 的访问。WSPM 客户机通过 MQ 与 WSPM 通信，同样地消息传递仍被用于在这两个实体之间进行通信。Web 客户机的使用一般和参与的应用程序（包括与人类的交互）有关，它将作为处理流的一部分被调用；因此，您可以创建使用 Web 客户机的 Web 应用程序来提供数据和控件交互作为业务流程的一部分。例如，可以在 WSPM 中为一个贷款应用业务流程建模，其中一个活动如贷款请求没通过自动批准流程，则贷款负责人必手工批准或拒绝。WSPM 通过 MQ 与贷款负责人通信，并且托管在 Application Server 上的基于 Web 客户机的应用程序提供工作项，并向 WSPM 返回响应以便进行进一步处理。

XML 消息传递接口

WSPM 提供了 XML 消息传递接口，该接口使得应用程序能够调用处理流或通过 MQ 消息参与处理流。MQ 消息包含了遵循特定语法格式的 XML 数据。这意味着我们在 WebSphere Application Server 与 MQ 集成一条涉及到的消息使能的应用，可以通过发送带有特定 XML 数据（消息产生者）的消息来调用一个处理流，或者可以通过接收方消息（消息消费者）将它作为处理流的一部分进行调用。

根据交互的影响，您必须考虑应用程序是否将按照 WSPM 要求的格式创建消息数据或者 WMQI 是否将被用于传输，在这种情况下，应用程序只简单地以 WSPM 期望的格式发送和接收去往 MQ 的消息，而不管消息将调用什么服务。

全部集成在一起

既然您已读完了全文，您应该已经清楚在 WebSphere Application Server 与 WebSphere MQ 系列集成的各种案例中，最核心的要素是 MQ 。简单地说，只要运行在 WebSphere Application Server 上的应用程序能够从 MQ 发送或接收消息，它就可以使用 WMQI 的服务，被作为业务流程（由 WSPM 协调）的一部分调用，并能与众多业务系统相联接，而无需考虑它的消息实际上将被怎样处理。

如下图 8 所示，WebSphere Application Server、MQ、WMQI 和 WSPM 集成在一起，形成企业范围的面向服务体系结构，我们可以通过众多完全不同的资源访问其中的各个服务点 — 应用程序服务器、消息代理、流程管理器 — 以达到一个确定的业务目标。

图 8. 全部集成在一起