Sun Java System Application Server 9.1 部署规划指南

Message Queue 代理部署规划

Java 消息服务 (Java Message Service, JMS) API 是一种消息传送标准，它允许 J2EE 应用程序和组件创建、发送、接收和读取消息。并启用了松散耦合的可靠异步分布式通信。Sun Java System Message Queue（用于实现 JMS）与 Application Server 相集成，使您可以创建消息驱动 Bean (Message-Driven Bean, MDB) 之类的组件。

Sun Java System Message Queue (MQ) 使用连接器模块（也称为资源适配器）与 Application Server 集成在一起，此模块是由 J2EE 连接器体系结构规范 (J2EE Connector Architecture, JCA) 1.5 定义的。连接器模块是一种在 Application Server 中添加功能的标准方法。部署到 Application Server 上的 J2EE 组件使用通过连接器模块集成的 JMS 提供者交换 JMS 消息。默认情况下，JMS 提供者是 Sun Java System Message Queue，但如果愿意，您也可以使用不同的 JMS 提供者，只要它可以实现 JCA 1.5。

在 Application Server 中创建 JMS 资源将会在后台创建连接器资源。因此，每个 JMS 操作将调用连接器运行时并在后台使用 MQ 资源适配器。

除了使用资源适配器 API 以外，Application Server 还使用其他 MQ API 以提供与 MQ 更好的集成。这种紧密集成实现了如下功能：连接器故障转移、传出连接的负载平衡以及传入到 MDB 中的消息的负载平衡。这些功能可实现消息传送通信容错能力和高可用性。

多代理群集

MQ Enterprise Edition 支持使用多个互连的代理实例（称为代理群集）。使用代理群集的情况下，客户机连接将分布在群集的所有代理中。群集可以提供水平可伸缩性并提高可用性。

单个消息代理可扩展到大约 8 个 CPU，并为典型的应用程序提供足够的吞吐量。如果代理进程失败，将会自动重新启动该进程。但是，随着连接到代理的客户机数以及传送的消息数的增加，代理最终将超过诸如文件描述符数量和内存容量之类的限制。

通过在群集中设置多个代理而不是一个代理，您可以：

提供消息传送服务，而不管单个计算机上是否出现了硬件故障。
在执行系统维护时，最大限度地减少停机时间。
满足具有不同用户系统信息库的工作组的需要。
规避防火墙限制。

不过，具有多个代理并不能确保正在处理事务的代理发生故障时，可以在备用代理上继续处理这些事务。虽然 MQ 将与群集中的其他代理重新恢复连接，但会中断事务消息传送并回滚正在进行的事务。这不会影响用户应用程序，但会影响无法完成的事务。由于可以继续使用这些连接，因此可确保服务的故障转移。

因此，MQ 在群集中不支持高可用性持久性消息传送。如果在出现故障后重新启动代理，它将自动恢复并完成持久性消息的传送。持久性消息可以存储在数据库或文件系统中。不过，如果承载代理的计算机不能从硬盘故障中恢复，则可能会丢失消息。

具有 Sun Cluster Data Service for Sun Message Queue 的 Solaris 平台支持透明的持久性消息故障转移。此配置利用 Sun Cluster 的全局文件系统和 IP 故障转移功能提供真正的高可用性，此配置包含在 Java Enterprise System 中。

主代理和客户机同步

在多代理配置中，将在群集的所有代理上复制每个目的地。每个代理知道为所有其他代理上的目的地注册的消息使用方。因此，每个代理可以将消息从其自己直接连接的消息生成方路由到远程消息使用方，然后将消息从远程生成方传送到其自己直接连接的使用方。

在群集配置中，每个消息生成方直接连接的代理将路由该生成方发送给它的消息。因此，持久性消息是由消息的主代理存储和路由的。

每当管理员在代理上创建或销毁目的地时，此信息将会自动传播到群集中的所有其他代理。同样，每当在主代理中注册消息使用方时，或者使用方与其主代理断开连接时（显式断开、由于客户机或网络故障或其主代理出现故障），就会在整个群集中传播该使用方的相关信息。还会以类似方式将持久订阅的相关信息传播到群集中的所有代理。

配置 Application Server 以使用 Message Queue 代理

Application Server 的 Java 消息服务表示的是 Message Queue 的连接器模块（资源适配器）。您可以通过管理控制台或 asadmin 命令行实用程序管理 Java 消息服务。

MQ 代理（JMS 主机）在 Application Server 进程的单独 JVM 中运行。这允许多个 Application Server 实例或群集共享一组相同的 MQ 代理。

在 Application Server 中，JMS 主机指的是 MQ 代理。Application Server 的 Java 消息服务配置包含了一个 JMS 主机列表（也称为 AddressList），其中列出了将使用的所有 JMS 主机。

使用管理控制台管理 JMS

在管理控制台中，可以使用 Java 消息服务节点为特定配置设置 JMS 属性。您可以设置诸如“重新连接时间间隔”和“重新连接尝试”之类的属性。有关更多信息，请参见《Sun Java System Application Server 9.1 管理指南》中的第 4 章 “配置 Java 消息服务资源”。

Java 消息服务节点下的 JMS 主机节点中包含 JMS 主机列表。可以在该列表中添加和删除主机。对于每个主机，您可以设置主机名、端口号以及管理用户名和密码。默认情况下，JMS 主机列表中包含一个名为 "default_JMS_host" 的 MQ 代理，它表示的是与 Application Server 集成的本地 MQ 代理。

可以配置 JMS 主机列表以包含群集中的所有 MQ 代理。例如，要建立一个包含 3 个 MQ 代理的群集，请在 Java 消息服务中为每个代理添加一个 JMS 主机。Message Queue 客户机使用 Java 消息服务中的配置信息与 MQ 代理进行通信。

使用 asadmin 管理 JMS

除了管理控制台以外，您还可以使用 asadmin 命令行实用程序来管理 Java 消息服务和 JMS 主机。请使用以下 asadmin 命令：

配置 Java 消息服务属性：asadmin set
管理 JMS 主机：
- asadmin create-jms-host
- asadmin delete-jms-host
- asadmin list-jms-hosts
管理 JMS 资源：
- asadmin create-jms-resource
- asadmin delete-jms-resource
- asadmin list-jms-resources
  
  有关这些命令的更多信息，请参见《Sun Java System Application Server 9.1 Reference Manual》或相应的手册页。

Java 消息服务类型

Application Server 与 MQ 代理之间共有两种类型的集成：本地和远程。您可以在管理控制台的 Java 消息服务页中设置此类属性。

本地 Java 消息服务

如果 Type 属性为 LOCAL，Application Server 将启动和停止 MQ 代理。当 Application Server 启动时，它将启动指定为默认 JMS 主机的 MQ 代理。同样，在关闭 Application Server 实例时，它将关闭 MQ 代理。LOCAL 类型是适用于独立 Application Server 实例的最佳类型。

在类型为 LOCAL 的情况下，请使用“启动参数”属性指定 MQ 代理的启动参数。

远程 Java 消息服务

如果 Type 属性为 REMOTE，Application Server 将使用在外部配置的代理或代理群集。在这种情况下，您必须在 Application Server 之外启动和停止 MQ 代理，并使用 MQ 工具来配置和调整代理或代理群集。REMOTE 类型是适用于 Application Server 群集的最佳类型。

在类型为 REMOTE 的情况下，您必须使用 MQ 工具指定 MQ 代理启动参数。忽略“启动参数”属性。

缺省 JMS 主机

可以在管理控制台的 Java 消息服务页中指定默认 JMS 主机。如果 Java 消息服务类型为 LOCAL，则在 Application Server 实例启动时，Application Server 将启动默认 JMS 主机。

要使用 MQ 代理群集，请删除默认 JMS 主机，然后将群集中的所有 MQ 代理添加为 JMS 主机。在这种情况下，默认 JMS 主机将变为 JMS 主机列表中的第一个 JMS 主机。

也可以显式地将默认 JMS 主机设置为某个 JMS 主机。当 Application Server 使用 Message Queue 群集时，默认 JMS 主机将执行特定于 MQ 的命令。例如，为 MQ 代理群集创建物理目的地时，默认 JMS 主机将执行该命令来创建物理目的地，但群集中的所有代理将使用该物理目的地。

示例部署方案

为满足消息传送需求，请根据您的部署、性能和可用性需求修改 Java 消息服务和 JMS 主机列表。以下各节介绍了一些典型方案。

为获得最佳可用性，如果 Application Server 无法满足消息传送需求，请将 MQ 代理和 Application Server 部署到不同的计算机上。另一种方法是，在每台计算机上运行 Application Server 实例和 MQ 代理实例，直至有足够的消息传送能力。

默认部署

在安装 Application Server 时，将会自动创建域管理服务器 (Domain Administration Server, DAS)。默认情况下，DAS 的 Java 消息服务类型为 LOCAL。因此，在启动 DAS 时，还会启动其默认 MQ 代理。

在创建新的域时，还会创建新的代理。默认情况下，在域中添加独立服务器实例或群集时，会将其 Java 消息服务配置为 REMOTE，并且其默认 JMS 主机是由 DAS 启动的代理。

默认部署列举了一个 Application Server 群集中包含 3 个实例的默认部署示例。

将 MQ 代理群集与 Application Server 群集结合使用

要配置 Application Server 群集以使用 MQ 代理群集，请在 Application Server 的 Java 消息服务中将所有 MQ 代理添加为 JMS 主机。然后，创建的任何 JMS 连接工厂和部署的 MDB 将使用指定的 JMS 配置。

下图展示了一个部署示例，其中代理群集中包含 3 个 MQ 代理，某一群集中包含 3 个 Application Server 实例。

指定特定于应用程序的 MQ 代理群集

在某些情况下，应用程序可能需要使用一个不同于 Application Server 群集所使用的 MQ 代理群集。指定特定于应用程序的 MQ 代理群集说明了这样一个示例方案。为此，请使用 JMS 连接工厂的 AddressList 属性或 MDB 部署描述符中的 activation-config 元素指定 MQ 代理群集。

有关配置连接工厂的更多信息，请参见《Sun Java System Application Server 9.1 管理指南》中的“JMS 连接工厂”。有关 MDB 的更多信息，请参见《Sun Java System Application Server 9.1 Developer’s Guide》中的“Using Message-Driven Beans”。

应用程序客户机

在应用程序客户机或独立应用程序首次访问 JMS 管理对象时，客户机 JVM 将从服务器中检索 Java 消息服务配置。只有重新启动客户机 JVM 后，客户机 JVM 才能获取有关 JMS 服务的其他更改。