面向消息的中间件 (Message-Oriented Middleware, MOM)

由于业务、机构和技术是不断变化的，因此为其服务的软件系统必须适应这样的变化。在合并、添加服务或扩展可用服务之后，公司可能无力负担重新创建信息系统所需的成本。正是在这个关键时刻，才需要集成新组件或者尽可能高效地扩展现有组件。要集成异类组件，最方便的方法不是将它们重新创建为同类元素，而是提供一个允许它们进行通信（不考虑它们之间的差异）的层。该层被称作中间件，它允许独立开发且运行于不同网络平台上的软件组件（应用程序、Enterprise Java Bean、Servlet 和其他组件）彼此交互。当能够进行这样的交互时，网络才成为计算机。

如图 1–1 所示，在概念上，中间件位于应用程序层与平台层（操作系统和底层网络服务）之间。

图 1–1 中间件

分布于不同网络节点上的应用程序使用应用程序接口进行通信，而不必关心托管其他应用程序的操作环境的细节，也不必关心将它们连接到这些应用程序的服务。此外，通过提供管理接口，可以使这个新的互连应用程序虚拟系统安全可靠。可以对性能进行度量和调整，也可以在不丢失任何功能的情况下进行扩展。

中间件可以划分为以下几类：

• 基于远程过程调用 (Remote Procedure Call, RPC) 的中间件，允许一个应用程序中的过程调用远程应用程序中的过程，就好像它们是本地调用一样。该中间件实现一个查找远程过程的链接机制并使调用方能够以透明方式使用这些过程。以前，这种类型的中间件处理基于过程的程序；现在，它还包括基于对象的组件。

• 基于对象请求代理 (Object Request Broker, ORB) 的中间件，使应用程序的对象能够在异类网络之间分布和共享。

• 面向消息的中间件或基于 MOM 的中间件，使分布式应用程序可以通过发送和接收消息来进行通信和交换数据。

所有这些模型都使一个软件组件可以通过网络影响另一个组件的行为。它们的区别在于基于 RPC 和 ORB 的中间件会创建紧密耦合组件系统，而基于 MOM 的系统允许组件进行更松散的耦合。在基于 RPC 或 ORB 的系统中，一个过程调用另一个过程时，必须等待调用的过程返回才能执行其他操作。正如前面所提到的，在这些模型中，中间件在一定程度上充当超级链接程序，在网络上查找被调用过程，并使用网络服务将函数或方法参数传递到被调用过程，然后返回查找结果。

基于 MOM 的系统允许通过异步交换消息来进行通信，如图 1–2 所示。

图 1–2 基于 MOM 的系统

面向消息的中间件使用消息传送提供者来协调消息传送操作。MOM 系统的基本元素是客户端、消息和 MOM 提供者，后者包括 API 和管理工具。MOM 提供者使用不同的体系结构路由和传送消息：它可以使用集中式消息服务器，也可以将路由和传送功能分布在每个客户端上。某些 MOM 产品结合了这两个方法。

使用 MOM 系统，客户端可以进行 API 调用，以便将消息发送到由提供者管理的目的地。该调用会调用提供者服务以路由和传送消息。在发送消息之后，客户端会继续执行其他工作，并确信在接收方客户端检索该消息之前，提供者一直保留该消息。基于消息的模型与提供者的协调耦合在一起，使得创建松散耦合的组件系统成为可能。这样的系统可以继续可靠地工作，即使在有个别组件或连接失败时也不会停机。

由消息传送提供者协调客户端之间的消息传送的另一个优点是：通过添加管理界面，可以监视和调整性能。这样，客户端应用程序便不必关心发送、接收和处理消息之外的任何问题。对于互操作性、可靠性、安全性、可伸缩性和性能之类的问题，应当由管理员通过编码实现 MOM 系统来解决。

至此，我们已经介绍了使用面向消息的中间件连接分布式组件的很多优点。下面将介绍其缺点。缺点之一源自松散耦合本身。在 RPC 系统中，只有在被调用函数完成任务之后，才能返回调用函数。在异步系统中，调用方客户端会继续为接收方装入工作，直到处理装入工作所需的资源耗尽且被调用组件发生故障。当然，可以通过监视性能和调整消息流来尽量减少或避免这些情况，但对于 RPC 系统却不必这样做。有一点很重要，那就是了解每种系统的优缺点。每种系统所适合执行的任务都不同。有时，您需要结合两种系统才能完全获得所需的行为。

图 1–3 显示 MOM 系统如何使两个基于 RPC 的系统进行通信。该图的左侧显示在不同的网络节点上分布客户端、服务器和数据存储库组件以提高性能的应用程序。这是一个折扣机票预定系统：最终用户为使用此服务支付一定的费用，使用该服务可以找到特定目的地和时间的最低费用。数据存储库保存有关注册用户和参与此折扣计划的航空公司的信息。服务器上的逻辑功能根据用户的请求在所参与的航空公司中查询价格、对信息进行排序并向用户提供三个最低报价。该图的右侧展示了基于 RPC 的系统，表示所参与的任一航空公司的机票/预定系统。该图的右侧将为折扣系统所连接到的任意多个航空公司进行复制。对于每个这样的航空公司，数据存储库都将保存有关可用航班的信息（座位、飞行时间和价格）。服务器组件将更新这些信息以响应最终用户输入的数据。航空公司的服务器还订阅 MOM 服务，接收折扣预定系统的信息请求，并返回座位和价格信息。如果用户决定购买 PanWorld 航空公司的折扣机票，则该系统的服务器组件将更新数据存储库中的信息，然后为请求者生成机票或者向折扣服务发送一条消息以生成机票。

图 1–3 结合 RPC 和 MOM 系统

此示例说明 RPC 和 MOM 系统之间的一些区别。前面已经提到了其中一个区别就是分布式组件耦合的方式。另一个区别是，RPC 系统通常用于分布和连接客户端与服务器组件（在这些组件中，客户端通常是最终用户），而在 MOM 系统中，客户端通常是只能通过消息传送进行交互操作的异构软件组件。

MOM 系统较为严重的问题是 MOM 作为专用产品来实现。如果您的公司依赖于 SuperMOM-X，但最近收购了一家使用 SuperMOM-Y 的公司，会出现什么情况？要解决此问题，需要一个标准的消息传送接口。如果 SuperMOM-X 和 SuperMOM-Y 均实现了此接口，则针对一个系统开发的应用程序也可以运行在另一个系统上。这样的接口应该易于学习，同时提供足够的功能来支持复杂的消息传送应用程序。1998 年推出的 Java 消息服务 (Java Message Service, JMS) 规范就是为了实现这样的目的。下一节将介绍 JMS 的基本功能，并说明包含现有专用 MOM 产品的通用元素的标准是如何制订的。这些标准既允许差异存在，又使得进一步发展成为可能。