|
| |
| Sun Java System Message Queue 3 2005Q4 技术概述 | |
第 1 章
消息传送系统：简介Sun Java™ System Message Queue 是一种消息传送中间件产品，它实现并扩展 Java 消息服务 (Java Message Service, JMS) 标准。如果您已熟知这些概念，则请从 Message Queue：元素和功能一节开始阅读。否则，请您从头开始阅读本章。
本章介绍 Message Queue 等产品底层的消息传送技术，并说明 Message Queue 如何实现和扩展对该技术进行标准化的 JMS 规范。本章涵盖以下主题：
面向消息的中间件 (Message-Oriented Middleware, MOM)由于公司、机构和技术在不断变化，因此为它们提供服务的软件系统必须能够适应这些变化。在合并、添加服务或扩展可用服务之后，公司可能无力负担重新创建信息系统所需的成本。正是在这个关键时刻，才需要集成新组件或者尽可能高效地扩展现有组件。要集成异类组件，最方便的方法不是将它们重新创建为同类元素，而是提供一个允许它们进行通信（不考虑它们之间的差异）的层。该层被称作中间件，它允许独立开发且运行于不同网络平台上的软件组件（应用程序、Enterprise Java Bean、Servlet 和其他组件）彼此交互。当能够进行这样的交互时，网络才成为计算机。
如图 1-1 所示，在概念上，中间件位于应用程序层与平台层（操作系统和底层网络服务）之间。
图 1-1 中间件
分布于不同网络节点上的应用程序使用应用程序接口进行通信，而不必关心托管其他应用程序的操作环境的细节，也不必关心将它们连接到这些应用程序的服务。此外，通过提供管理接口，可以使这个新的互连应用程序虚拟系统安全可靠。可以对性能进行度量和调整，也可以在不丢失任何功能的情况下进行扩展。
中间件可分为以下几类：
- 基于远程过程调用 (Remote Procedure Call, RPC) 的中间件，允许一个应用程序中的过程调用远程应用程序中的过程，就好像它们是本地调用一样。该中间件实现一个查找远程过程的链接机制并使调用方能够以透明方式使用这些过程。以前，这种类型的中间件处理基于过程的程序；现在，它还包括基于对象的组件。
- 基于对象请求代理 (Object Request Broker, ORB) 的中间件，使应用程序的对象能够在异类网络之间分布和共享。
- 基于面向消息的中间件 (Message Oriented Middleware, 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 产品的通用元素的标准是如何制订的。这些标准既允许差异存在，又使得进一步发展成为可能。
作为 MOM 标准的 JMSJava 消息传送服务规范最初是为了允许 Java 应用程序访问现有的 MOM 系统而开发的。引入之后，它已被许多现有的 MOM 供应商采用并且已经凭借自身的功能实现为异步消息传送系统。
在创建 JMS 规范时，设计者希望捕获现有消息传送系统的精髓。这包括：
供应商通过提供一个 JMS 提供者来实现 JMS 规范，该提供者由实现 JMS 接口的库、消息的路由和传送功能以及用来管理、监视和调整消息传送服务的管理工具组成。路由和传送功能可以由集中式消息服务器或代理来执行，也可以通过每个客户端的运行时都具备的功能来实现。
同样，JMS 提供者可以扮演多种角色：它可以作为独立产品创建，也可以作为大型分布式运行时系统中的嵌入式组件创建。作为独立产品时，它可以用于定义企业应用程序集成系统的主干；在嵌入到应用服务器中时，它可以支持组件间消息传送。例如，J2EE 使用 JMS 提供者来实现消息驱动 Bean 并允许 EJB 组件发送和接收消息。
如果所创建的是一个包括现有系统所有功能的标准，则会导致系统既难以学习，又难以实现。而 JMS 定义了消息传送概念和功能的一个共同特点。这将导致所创建的标准易于学习，并最大限度地提高了 JMS 应用程序在 JMS 提供者之间的可移植性。一定要注意，JMS 是 API 标准，而不是协议标准。可以很容易地将 JMS 客户端从一个供应商移到另一个供应商。但是，不同的 JMS 供应商之间通常不能直接通信。
下一节将介绍 JMS 规范定义的基本对象和消息传送模式。
JMS 消息传送对象和模式
为了发送或接收消息，JMS 客户端必须首先连接到通常作为消息代理实现的 JMS 提供者：此连接在客户端与代理之间打开一个通信通道。接下来，客户端必须设置一个用来创建、生成和使用消息的会话。可以将该会话视为定义客户端与代理之间的特定对话的消息流。客户端本身是消息生成方和/或消息使用方。消息生成方向代理所管理的目标发送一条消息。消息使用方访问该目标以使用此消息。该消息包括头、属性（可选）和主体。消息主体用来保存数据；消息头中包含代理路由和管理消息所需的信息；属性可以由客户端应用程序或提供者定义，以满足处理消息的需要。连接、会话、目标、消息、生成方和使用方是构成 JMS 应用程序的基本对象。
有了这些基本对象，客户端应用程序就可以使用两种消息传送模式（或域）来发送和接收消息。图 1-4 对此进行了说明。
图 1-4 JMS 消息传送模式
客户端 A 和 B 是消息生成方，它们通过两种不同类型的目标向客户端 C、D 和 E 发送消息。
任何域中的消息使用方都可以选择同步或异步获取消息。同步使用方通过进行显式调用来检索消息；异步使用方则指定一个回调方法，将调用该回调方法来传递待处理的消息。使用方还可以通过为传入消息指定选择标准来过滤消息。
受管理对象
JMS 规范创建了一个标准，该标准结合了现有 MOM 系统的许多元素，但并不试图穷举所有可能的元素。相反，它试图设置一个可扩展的方案来兼顾不同元素之间的区别并适应将来的发展。JMS 将许多消息传送元素留给各个提供者来定义和实现。其中包括负载平衡、标准错误消息、管理 API、安全性、底层线路协议以及消息存储。下一节（Message Queue：元素和功能）将介绍 Message Queue 如何实现其中的许多元素以及如何扩展 JMS 规范。
连接工厂和目标是 JMS 未完全定义的两个消息传送元素。尽管这些元素是 JMS 编程模型中的基础元素，但在提供者定义和管理这些对象的方式上，存在许多现有的和预期的区别，以致于不可能也不值得创建一个公共的定义。因此，这两个对象通常使用管理工具来创建和配置，而不是以编程方式来创建。它们随后将存储在对象存储中，JMS 客户端可以通过标准的 JNDI 查找功能来访问它们。
JMS 客户端不是必须查找受管理对象；它们可以通过编程方式创建这些对象（这些对象随后将存储在代理的内存中）。要快速建立原型，最方便的方法可能是以编程方式创建这些对象。但是，如果要在生产环境中部署，则在中心系统信息库中查找受管理对象会更便于控制和管理消息传送行为：
如图 1-5 中所示，受管理对象的使用是基本 JMS 应用程序图中的最后一项关键技术。
图 1-5 JMS 应用程序的基本元素
图 1-5 显示消息生成方和消息使用方如何使用目标受管理对象来访问对应于该对象的物理目标。带编号的步骤是管理员和客户端应用程序在使用此机制发送和接收消息时需要执行的操作。
连接工厂受管理对象的使用过程与此类似。管理员使用管理工具来创建和配置连接工厂受管理对象。客户端查找连接工厂对象并使用它来建立连接。
尽管使用受管理对象会为消息传送过程添加几个步骤，但它也提高了消息传送应用程序的稳定性和可移植性。
Message Queue：元素和功能至此，我们已经介绍了面向消息的中间件的元素，并指出使用 JMS 可提高 MOM 应用程序的可移植性。接下来介绍 Message Queue 如何实现 JMS 规范，并介绍它用来提供可靠、安全且可扩展的消息传送服务的功能和工具。
首先，与许多 JMS 提供者一样，Message Queue 既可以用作独立产品，也可以作为启用技术嵌入到 J2EE 应用服务器中以提供异步消息传送。第 5 章“Message Queue 和 J2EE”对 Message Queue 在 J2EE 中扮演的角色进行了更详细的介绍。与其他 JMS 提供者不同的是，Message Queue 已被指定为 JMS 参考实现。这一指定证明了这样一个事实：Message Queue 是正确而又完整的 JMS 实现。它还保证了 Message Queue 产品将与以后推出的任何 JMS 修订和扩展保持同步。
Message Queue 服务
作为一个 JMS 提供者，Message Queue 提供一个实现 JMS 接口并提供管理服务和控制的消息传送服务。至此，我们已在说明 JMS 提供者时重点介绍了代理在消息转发过程中扮演的角色。但实际上，除了代理外，JMS 提供者中还必须包括许多元素才能提供可靠、安全且可扩展的消息传送。图 1-6 显示了构成 Message Queue 消息服务的元素。这些元素包括各种连接服务（支持不同的协议）、管理工具以及用于消息传送功能、监视功能和用户信息的数据存储。Message Queue 服务包括该图中用灰色标记的所有元素。
图 1-6 Message Queue 服务
正如您所看到的那样，功能全面的 JMS 提供者比基本 JMS 模型更为复杂。这很容易引起我们的怀疑。以下各节将介绍上面显示的 Message Queue 服务元素。这些元素可以分成三类：代理、客户端运行时支持和管理。
连接到代理
如图 1-6 所示，应用程序客户端和管理客户端都可以连接到代理。JMS 规范未规定提供者实现任何特定的线路协议。Message Queue 服务当前位于 TCP、TLS、HTTP 或 HTTPS 协议的上一层，供应用程序客户端和管理客户端用来连接到代理。（位于 HTTP 上一层的服务使消息可以穿过防火墙。）
默认情况下，当启动代理时，会启动并运行 jms 和 admin 服务。此外，还可以将代理配置为运行上述任一或全部连接服务。每个服务都支持特定的验证和授权（访问控制）功能，每个服务都是多线程的并且支持多个连接。
当连接失败时，Message Queue 服务能够自动重新尝试将客户端连接到同一代理或另一代理（如果启用了此功能）。有关详细信息，请参见附录 B“Message Queue 功能”中有关自动重新连接功能的描述。
当客户端创建连接工厂（它们将从中获取连接）时，可以配置连接运行时支持。可以通过选项来指定要连接到的代理、重新连接的处理方式、消息流控制等。有关如何配置连接的其他信息，请参见连接工厂和连接。
代理
代理是消息服务的核心，它以可靠的方式路由和传送消息，对用户进行验证并收集用来监视性能的数据。
- 为路由和传送消息，代理将传入的消息放入各自的目标并管理传入和传出这些目标的消息流。
- 为了提供可靠的传送，代理使用持久性存储来保存状态信息和持久性消息，直到它们被接收。如果代理或连接失败，所保存的信息使代理可以恢复代理的状态并重试操作。
- 要为所交换的数据提供安全性，代理需要使用经过验证的连接。可以选择通过在安全协议（如 SSL）上运行来对数据进行加密。代理还使用并管理一个系统信息库，该系统信息库保存有关用户以及他们可以访问的数据或操作的信息。代理对请求服务的用户进行验证，并通过在该系统信息库中查找信息来授予他们执行相应操作的权限。
- 要监视系统，代理需要生成度量和诊断信息，以便管理员可以通过访问这些信息来度量性能并调整代理。度量信息还可以通过编程方式来使用，这使应用程序可以调整消息流和模式，从而提高性能。
Message Queue 服务提供各种管理工具，管理员可以使用这些工具来配置代理支持。有关详细信息，请参见管理。
客户端运行时支持
客户端运行时支持在构建 Message Queue 客户端时所链接到的库中提供。可以将客户端运行时视为已成为客户端一部分的 Message Queue 服务的代码。例如，当客户端代码进行 API 调用以发送消息时，将调用这些库中的代码，以便根据用来将消息转发到代理上的物理目标的协议来相应地包装消息位。
Java 和 C 客户端支持
只有当需要支持 Java 客户端时，才需要 JMS 提供者；但是，如图 1-6 所示，Message Queue 客户端可以使用 Java 或特定于提供者的 C API 来发送或接收消息。这些接口是在 Java 或 C 运行时库中实现的，这些库的实际作用是建立与代理的连接并根据所请求的连接服务来相应地包装位。
Message Queue 服务提供一个 C API，使传统 C 和 C++ 应用程序能够参与基于 JMS 的消息传送。这两个 API 所提供的功能有许多不同；Java 客户端与 C 客户端对此进行了说明。
请记住，JMS 规范是仅适用于 Java 客户端的标准。C 支持特定于 Message Queue 提供者，因此在计划移植到其他提供者的客户端应用程序中不应该使用该支持。
对 Java 客户端的 SOAP 支持
Message Queue Java 客户端还能够发送和接收包装为 JMS 消息的 SOAP 消息。使用 SOAP（Simple Object Access Protocol，简单对象访问协议）可以实现在分布式环境中的两个对等方之间交换结构化数据。所交换的数据由 XML 方案指定。
Sun SOAP 处理当前仅限于使用点对点模型并且不能保证可靠性。通过将 SOAP 消息包装到 JMS 消息中并使用代理来路由它，可以利用全功能的 Message Queue 消息传送，从而保证可靠的传送并允许您使用主题和点对点域。Message Queue 提供实用程序例程，使用这些例程，消息生成方可以将 SOAP 消息包装到 JMS 消息中，消息使用方可以从 JMS 消息中提取 SOAP 消息。
使用 SOAP 消息更详细地介绍了 SOAP 消息处理。
管理
Message Queue 服务提供可用来执行以下操作的命令行工具：
还可以使用基于 GUI 的管理控制台来执行以下命令行功能：
扩展 Message Queue 服务
随着客户端或连接数量的增加，您可能需要扩展消息服务以消除瓶颈或改善性能。Message Queue 消息服务根据您的需要提供许多扩展选项。可以很容易地将这些选项归为以下几类：
- 无状态水平扩展是通过使用其他代理并将现有的客户端重新分配给这些代理来实现的。此方法易于实现，但是只有当消息传送操作可以分成多个独立的工作组时，此方法才适用。
- 有状态水平扩展是通过将代理连接成群集来实现的。在代理群集中，每个代理不仅连接到群集内的其他每个代理，而且还连接到本地应用程序客户端。这些代理可以位于同一个主机上，也可以分布在网络中。有关目标和使用方的信息会在群集内的所有代理中复制。目标和订户的更新也会进行传播。因此，每个代理都可以将消息从与它直接相连的生成方路由到与群集内的其他代理连接的使用方。当使用备份使用方时，如果某个代理或连接失败，则发送到不可访问的使用方的消息可以转发到另一个代理上的备份使用方。
如果代理或连接失败，则有关持久性实体（目标和长期订阅）的状态信息可能会失去同步。例如，如果当某个群集代理停机时，在群集内的另一个代理上创建了一个目标，则当前者重新启动时，将不会知道有这个新目标。要防止出现此问题，可以将群集内的某个代理指定为主代理。此代理负责跟踪主配置文件中目标和长期订阅的所有更改，还负责更新群集内临时脱机的代理。有关其他信息，请参见第 4 章“代理群集”。
即使在使用主代理时，当代理或连接失败时，Message Queue 也只是提供服务可用性，而不提供数据可用性。例如，如果群集代理变得不可用，则在该代理恢复之前，由该代理保存的任何持久性消息都将不可用。目前，只能通过使用 SunCluster Message Queue 代理来确保数据可用性。在这种情况下，持久性存储保留在共享文件系统上。如果某个代理失败，则第二个节点上的 Message Queue 代理会启动一个接管共享存储的代理。客户端会重新连接到该代理，从而既可以获得不间断的服务，又可以访问持久性数据。
Message Queue 作为启用技术Java 2 Platform, Enterprise Edition（J2EE 平台）是一种面向 Java 编程环境中分布式组件模型的规范。J2EE 平台的一项要求是，分布式组件之间必须能够通过可靠的异步消息交换来进行交互。此功能是通过可扮演以下两种角色的 JMS 提供者来提供的：它可用于提供服务并且可以支持消息驱动 Bean (message-driven bean, MDB)，MDB 是一种可以使用 JMS 消息的专用 Enterprise Java Bean (EJB) 组件。
符合 J2EE 的应用服务器必须使用由给定的 JMS 提供者提供的资源适配器才能使用该提供者的功能。Message Queue 提供这样的资源适配器。使用插入到 JMS 提供者的支持，在应用服务器环境中部署和运行的 J2EE 组件（包括 MDB）既可以彼此交换 JMS 消息，也可以与外部 JMS 组件交换消息。这为分布式组件提供了强大的集成功能。
有关 Message Queue 资源适配器的信息，请参见第 5 章“Message Queue 和 J2EE”。
产品版本Message Queue 有两个可用的版本：Enterprise Edition 和 Platform Edition。两个版本都完全实现了 JMS 规范，只是它们所对应的功能集和许可功能不同。
Enterprise Edition 在 Platform Edition 的基础上添加了以下功能：
Message Queue Enterprise Edition 许可证有效期理论上是无期限的，但实际受使用的 CPU 数量的限制。许可证对多代理消息服务中的代理数量没有限制。
Message Queue Platform Edition 对代理所支持的客户端连接的数量没有限制。它提供基本许可证或 90 天试用许可证：
有关许可功能、重新分发权限以及将 Platform Edition 升级到 Enterprise Edition 的进一步信息，请参见 Message Queue Installation Guide。
Message Queue 功能概述Message Queue 拥有的功能远远超出了 JMS 规范的要求。这些功能使 Message Queue 可以集成由大量分布式组件组成的系统，这些组件在全天候的关键任务操作中交换数以万计的消息。有关这些功能的概述，请参见附录 B“Message Queue 功能”。
