在 WebSphere MQ V6.0 上运行独立 Java 应用程序

人们可能会感到奇怪，为什么要编写在 J2EE 环境外部执行的 JMS 消息传递程序？的确，J2EE 接收了许多主要消息，但是在 J2EE 之前也有一些消息，我们仍需要对使用的消息做许多相同的工作——J2EE 环境可能限制太严格或者根本不适用。这包括对实际事件的批处理作业、桥接、转换、实用程序、管理、检测、监视和通知等。不过，在 J2EE 环境外部进行编码并不排除对 JMS 的使用。假设 Java 是选择的编程语言，JMS 是 Java 的标准消息 API，那么实际的问题是：为什么不使用 JMS 来满足这些消息需求？

JMS 应用程序的层

运行的 JMS 应用程序包含三个截然不同的代码层，如图 1 如示：

JMS 应用程序——与提供程序无关；使用 JNDI 通过 JMS 访问提供程序。
JMS 实现——特定于提供程序的 JMS 对象。
消息提供程序——消息系统本身，在本例中是 WebSphere MQ。

图 1. JMS 应用程序的层

如图 1 所示，应用程序代码不直接访问消息提供程序；而是通过特定于提供程序的代码层完成访问，其中，通过 JNDI 访问其各个独立对象。

JMS 隐藏 JMS 实现和提供程序层的大多数细节，以便 Java 开发人员可以构建与提供程序尽可能无关的 JMS 应用程序。不过，管理 JMS 提供程序的人员无疑需要理解 JMS 实现层，因为这里需要进行配置，才能将应用程序与提供程序一起使用。JMS 规范描述编程 API，但将实现的具体细节留给了供应商。标准 JMS API 对 Java 开发人员隐藏实现详细信息，但是 JMS 提供程序管理员必须知道配置详细信息，这些配置详细信息因每个供应商的产品而异。

理解 JMS 应用程序、JMS 实现和消息提供程序的交互方式非常重要，所以我们将分别对它们进行讨论，首先讨论提供程序。

消息提供程序

消息提供程序通过网络连接在进程之间可靠地传输消息。它不必支持 JMS。例如，在出现 JMS 规范（用于调用 IBM MQSeries）之前，WebSphere MQ 就存在很长时间了，甚至现在的许多非 Java 应用程序都使用 WebSphere MQ，而不使用 JMS。不过，这里我们假设消息提供程序是 WebSphere MQ，并且该应用程序将通过其可选 JMS 接口访问它。

WebSphere MQ 作为一个或多个队列管理器运行。每个队列管理器都是一组进程，它定义一组队列，组织这些队列中的消息，在内存中或磁盘上存储消息，并在消息客户机和其他队列管理器之间传输消息。WebSphere MQ 使用队列实现点到点的消息传递。称为发布/订阅代理的 WebSphere MQ 进程将本机 WebSphere MQ 队列用作其数据存储，提供发布/订阅功能。WebSphere MQ 使用这些功能来实现 JMS 队列和主题。

不存在与 WebSphere MQ 队列管理器对应的 JMS 对象和以编程方式执行管理和配置任务的 JMS API，如启动或停止队列管理器、定义或删除 WebSphere MQ 对象或者执行任何其他特定于 WebSphere MQ 的管理任务。因此，需要完全了解基本 WebSphere MQ 管理，才能确保队列管理器运行，并且知道是使用 JMS 应用程序对其配置了期望的资源。在您的环境中，这可以由 WebSphere MQ 管理员执行。

如果您对发布/订阅消息域感兴趣，则需要知道的重要一点是，在 WebSphere MQ 中，当队列管理器启动时，发布/订阅代理不会自动启动。启动队列管理器后，还必须启动代理，应用程序才能执行发布/订阅消息。先启动 WebSphere MQ V6，然后配置代理，以便在队列管理器的控制下进行启动和停止。

客户机模式和绑定模式

在 WebSphere MQ 中，有两种方法可以将应用程序连接到 WebSphere MQ 队列管理器。这两种方法称为绑定模式和客户机模式。了解每种模式的不同点和优缺点非常重要：

绑定模式是 WebSphere MQ 的本机连接模式。在绑定模式中，JMS 应用程序必须在与队列管理器相同的主机上运行，它们将使用进程间通讯 (IPC) 协议进行通信。
在客户机模式中，JMS 应用程序通常在 TCP/IP 上建立与队列管理器的代理进程之间的网络会话。然后代理使用绑定模式与队列管理器对话，从而代表应用程序执行 API 调用。

绑定模式和客户机模式之间的消息客户机 API 中不存在任何差异。在 JMS 中，这些模式的所有连接参数都存储在连接工厂对象中，并且对应用程序不可见。不过，需要注意一些重要的操作事项：

所有客户机模式 API 调用都按以下三个步骤执行：
1. 将 API 调用从客户机应用程序传输到代理。
2. 代理执行对队列管理器的调用。
3. 将调用的结果从代理传输回到客户机应用程序。
如果在此交换过程中网络连接断开，则客户机应用程序无法确定连接是在第一个步骤中断开（将 API 调用提交到代理进程之前），还是在第三个步骤中断开（在要传回结果时）。因此，如果客户机模式连接断开，则无法确定最后 API 调用的结果。因此，当使用（或可能使用）客户机模式时，建议使用事务处理会话和代码显式 commit() 和 rollback() 方法调用。使用此方法，应用程序可以在断开连接后接收重复的消息，而不会丢失任何内容。
在使用基础 WebSphere MQ 客户机时，XA 事务在客户端模式中不可用。IBM 提供称为 Extended Transactional Client 的增强版本，它通过客户机模式连接提供 XA 功能，但是这是单独授权的定价产品，不应该与免费 WebSphere MQ 基本客户机混淆。
因为绑定模式连接使用共享内存，所以不存在与网络连接上的传输关联的开销。客户机模式性能可能因网络负载，甚至断开连接的点的不同而不同。防火墙和路由器也可能会超时，并断开客户机会话。

出于上面列出的原因，只要有可能，就请使用绑定模式。另一方面，绑定模式要求将队列消息安装在与应用程序相同的主机上（这不是总能做到的）；客户机模式允许应用程序在不同的主机上访问队列消息。即，一般来说绑定模式较好，但是客户机模式也有优点。好的做法是：承载 J2SE JMS 应用程序的计算机应该安装队列管理器（只要有可能），并且应用程序应该通过绑定模式连接。示例代码包括客户机和绑定模式的连接工厂，以演示如何实现二者。

存在一些接受客户机模式连接所需的 WebSphere MQ 配置详细信息。首先，必须启动侦听器进程。WebSphere MQ 提供名为 runmqlsr 的可执行文件，在缺省情况下，它侦听端口 1414。客户机模式还需要队列管理器上的 SVRCONN 通道定义。为使连接能够工作，连接工厂必须包括通道名称、侦听器端口和队列管理器计算机的主机名或 IP 地址。在下一部分中提供了运行示例代码的侦听器和通道配置。

还应注意：提供 WebSphere MQ 客户机功能的最好方式是将最新 WebSphere MQ 软件包安装在服务器版本或客户机版本中。可以从一个安装直接获取 Java JAR 文件，并将它们重新部署到客户机，许多人都是这样操作的。当应用程序按此方式运行时，此安排不能安装完整包中提供的许多有用的实用工具和诊断工具。特别是，WebSphere MQ 客户机的完全安装便利了应用程序的维护和修补，以及对所安装版本的查询。考虑到本文的目的，假设已安装了 WebSphere MQ 服务器，这样我们可以在本地创建队列管理器，并且还可以选择安装客户机支持选项。（请参见参考资料，以下载用于此示例的 WebSphere MQ 的试用版。）

JMS 实现

每个提供程序都可以实现特定于提供程序工作方式的 JMS API。此特定于提供程序的实现使 JMS 程序中与提供程序无关的代码能够附加到特定的 JMS 提供程序。因为对于每个提供程序来说此实现是不同的，所以管理 JMS 对象或消息提供程序的人员必须了解如何配置实现层。由于在本例中提供程序是 WebSphere MQ，所以这里提供的说明是特定于 WebSphere MQ 的。

JMS 受管理对象

受管理对象是实现 JMS 接口并且特定于根提供程序的对象，并且可以通过应用程序直接访问。JMS 应用程序使用 Java Naming and Directory Interface (JNDI) 从注册中心按名称检索受管理对象。该项同时包含由 JMS 应用程序使用的公共属性，如对象类型（实例的查询或主题）和由提供程序的 JMS 实现类使用的私有属性。尽管在注册中心可以表示许多类型的资源，但是以下三种类型的受管理对象对 JMS 最重要：连接工厂、查询和主题。JMS 应用程序通过这些受管理对象与 WebSphere MQ 队列管理器通信。

连接工厂使 JMS 程序能够使用队列管理器打开连接，发送和接收消息。然后使用队列或主题对象生成或使用消息。JMS 队列和队列的 WebSphere MQ 实现之间存在一一对应关系；不过，不存在直接与 JMS 主题对应的 WebSphere MQ 对象。WebSphere MQ 通过发布/订阅代理实现主题，该代理将代理控制队列和流队列应用到发布的消息。这些运行时详细信息是 WebSphere MQ 的 JMS 实现的一部分，并且对 JMS 应用程序完全透明。从应用程序角度来看，WebSphere MQ 中的队列和主题实现是作为 JMS 管理对象通过 JNDI 访问的，行为与 JMS 规范中描述的完全相同。

这些特定于提供程序的对象的另一个重要功能是设置并强制执行管理策略或业务需求。例如，消息优先级可以在应用程序代码中指定，但是也可以通过管理对象中的设置覆盖。对于队列、主题和连接工厂，有许多其他特定于提供程序的对象属性，有必要熟悉一下。

乍看上去，当您需要做的所有工作是运行简单的代码片段时，这些特定于提供程序的对象似乎是需要学习和管理的另一内容。但是，这些特定于提供程序的对象的功能是将代码与提供程序分离，然后使保留的代码独立于环境并且可移植。例如，对于不同环境（开发、测试和生产等）中的队列或不同版本的应用程序通常有不同的名称。由于 WebSphere MQ 名称封装在 JMS 受管理对象中，因此应用程序代码不受这些更改的影响。事实上，大多数应用程序代码从来不需要知道对象是否表示队列或主题，甚至不需要知道使用的是哪一个供应商的提供程序。特定于提供程序的对象使所有这些实现详细信息位于代码的外部。

受管理对象注册中心

必须在实现 JNDI API 的目录中注册 JMS 受管理对象。无论将资源存储在何处，资源是如何实现的，或者容器及其 JNDI 提供程序实际上如何支持对资源的访问，JNDI 都允许 Java 组件通过唯一名称访问资源。资源可以是程序全局访问需要的任何对象——Java Database Connectivity (JDBC) 数据源、Enterprise JavaBeans (EJB) Home 和 J2EE Connector Architecture 连接器等。

根据提供的对象，WebSphere MQ 为以下三种不同类型的目录服务提供 JNDI 支持：J2EE 环境（如 WebSphere Application Server）、LDAP 和基于文件系统的实现。我们将使用基于文件系统的服务，因为除 WebSphere MQ 安装中提供的组件外，它不需要任何其他附加软件或硬件组件。JMS 应用程序至少需要一个连接工厂和至少一个队列或主题。接下来，我们将分析 WebSphere MQ 如何将这些内容表示为 JNDI 可访问的注册表项。

连接工厂提供应用程序连接到 WebSphere MQ 队列管理器需要的所有信息。应用程序不需要知道是否通过客户机或绑定模式连接，也不需要知道队列管理器的名称。应用程序代码仅使用 JNDI 按名称查找连接工厂；访问队列管理器和创建连接的底层细节信息由特定于 WebSphere MQ 的对象处理。

连接工厂实现二十多个特定于 WebSphere MQ 的属性。缺省设置使用最保守的选项，适用于简单的程序，如本文附带的示例。不过，要有效地管理 JMS 对象或 WebSphere MQ，必须了解二者如何交互。

在 JMS 1.1 之后，不需要使用 JMS 应用程序区别队列和主题。在应用程序代码中，它们两个都是生成或使用消息的目的地。不过，队列和主题在传输级别上有本质的不同，所以必须将任何给定目的地的注册项专门定义为队列或主题。当 JMS 应用程序执行 JNDI 目的地查询时，将根据其名称查找正确的对象，返回的结果或者是队列的实例，或者是主题的实例。在大多数情况下，应用程序可以直接使用目的地对象，不管它是表示队列还是主题，并且仅根据需要生成或使用消息。如果需要，可以使用 instanceof 运算符来确定指定的目的地子类型。

和连接工厂一样，队列和主题注册表项有许多特定于 WebSphere MQ 的属性。同样，缺省设置就能满足本文附带的简单演示应用程序的需要，但是，在部署生产应用程序之前，管理员应该熟悉所有的属性及其结果。

JMS 应用程序

JMS 应用程序堆栈的顶级是 JMS 应用程序本身。应用程序使用 JNDI 查找它需要的各种 JMS 受管理对象，并使用这些对象来附加到 WebSphere MQ 消息提供程序。应用程序只需知道资源的 JNDI 名称。这些名称必须完全匹配，并且区分小大写。

如前所述，从 JMS 角度看，最显著的更改之一是将点到点的消息和发布-订阅合并到单个域。尽管特定于域的类（如 Queue、Topic、QueueConnectionFactory 和 TopicConnectionFactory）仍然可用，但是已由 Destination 和 ConnectionFactory 之类的中性类替换，这适合于队列和主题。

队列和主题域的这一统一非常重要，有必要进行深入的研究。在旧的规范下，必须专门为队列或主题编写应用程序代码，因为类本身是特定于域的。因而，从队列到主题的更改涉及重新编码、重新编译和重新部署应用程序。这里隐含着一个难以察觉但非常重要的要求，在设计时，您必须知道目的地是队列还是主题。在 JMS 1.1 中，在运行时之前通常不必知道目的地是何类对象。这意味着仅知道高级消息流就可以对程序进行编码。

本文提供的示例代码将演示这些统一域类的使用。示例利用队列管理器上的队列和主题，并使用 JNDI 绑定在它们之间来回切换。注意，如果在程序运行时更改 JNDI 绑定，则不能在队列和主题之间动态切换程序。仅当在 JNDI 中查找对象时更改才有效，这通常在程序初始化时才出现一次。

示例应用程序

了解 JMS 应用程序如何附加到 WebSphere MQ 后，现在让我们了解一下示例 JMS 程序，以及如何配置 WebSphere MQ 才能运行它。为此，我们将：

1. 配置 WebSphere MQ

要为示例代码配置 WebSphere MQ，我们必须：

创建队列管理器。

要运行示例代码，我们需要有队列管理器。在创建队列管理器时，提供了许多不同的选项，但是我们真正需要关心的是配置了死信队列的队列管理器，以及配置为缺省的队列管理器：
- 队列管理器和 Java 类使用死信队列，才能保存无法提交到预期目的地的消息。我们认为最佳实践是每个队列管理器拥有一个死信队列。
- 将队列管理器配置为缺省队列管理器时，应用程序可以在不知道其名称的情况下对其进行访问。这样编写示例代码就会更容易；但作为一般规则，应用程序不应该依赖此设置。
有多种方式可定义新的队列管理器，就我们的目的而言，最快的方式或许是来自图形用户界面 WebSphere MQ Explorer：
1. 从 Windows® 开始菜单导航到 All Programs => IBM WebSphere MQ => WebSphere MQ Explorer。在 WebSphere MQ Explorer 运行后，右键单击 Queue Managers 文件夹，然后选择 New => Queue Manager 以启动 New Queue Manager 向导。（图 2）
  
  图 2. 新建队列管理器
2. 当向导打开时，键入队列管理器名称 JMSDEMO，并选中 Make this the default queue manager 框。接下来，输入缺省“死信队列”的名称：SYSTEM.DEAD.LETTER.QUEUE。输入时，确保全部使用大写字母。（图 3）
  
  图 3. 定义队列管理器
3. 按 Finish 按钮，此时，将使用所有缺省设置创建队列消息。（图 4）其中：
  - 队列管理将立即启动。
  - 队列管理器将设置为在计算机重新启动时启动。
  - 将在端口 1414 上创建并启动新的侦听器。
  现在，新的队列管理器应该在 WebSphere MQ Explorer 窗口中可以看到。
  
  图 4. 队列管理器列表
创建队列

从 WebSphere MQ Explorer 定义队列也非常容易（图 5）：
1. 单击 JMSDEMO 队列管理器旁边的加号 (+)，以展开文件夹树，然后单击 Queues 文件夹。缺省情况下，系统队列会被过滤掉，由于刚构建了队列管理器，因此在右侧面板中应该没有任何可见的队列。
2. 接下来，右键单击 Queues 文件夹，并在上下文菜单中选择 New => Local Queue，以打开 Local Queue 向导。
  
  图 5. 创建新的队列
3. 在向导中，键入 JMSDEMO.QL 作为队列的名称，并单击 Finish 按钮。我们稍后创建的 JNDI 目录项将查找此特定的队列名称，所以输入的名称必须与所示的名称完全相同。（图 6）
  
  图 6. 定义新的队列
  
  在完成向导后，新的队列应该在 Queues 窗口中可见。（图 7）
  
  图 7. 队列的列表
设置发布/订阅

到目前为止，我们定义和启动了队列管理器，并为点到点消息传递创建了队列。设置发布/订阅需要多个附加步骤。在启动代理之前，代理将其内部状态存储在我们需要创建的队列中。IBM 已在命令脚本中提供了所有的定义，因此我们需要做的全部工作就是运行 runmqsc 命令解释器内部的脚本。完成此任务后，我们将设置在队列管理器控制下开始和结束的发布/订阅代理。
1. 打开命令窗口，并导航到 WebSphere MQ 的安装目录。从该位置逐层展开到 Java/bin 目录，您将在其中找到 MQJMS_PSQ.mqsc 脚本。执行 runmqsc，并将此脚本重定向到作为输入的位置（如图 8 所示）。将输出重定向到文件，以便稍后进行查看。
  
  图 8. 重定向 runmqsc 脚本
2. 接下来，我们需要将代理配置为服务。WebSphere MQ 服务是版本 6 之后的一个新功能，名为 SYSTEM.BROKER 的服务就是为此目的提供的。所需的所有操作是将服务放置在队列管理器控制之下，然后启动它。
  
  先启动 WebSphere MQ 命令解释器 runmqsc。使用命令 alter service(SYSTEM.BROKER) control(qmgr) 将 SYSTEM.BROKER 服务更改到队列管理器控制之下。由于队列管理器已经运行，所以第一次需要手动启动代理。发布命令 start service(system.broker)。（注意，除非用引号括起来，否则 runmqsc 参数不区分大小写。）按 Ctrl-C 从 runmqsc 退出。
我们将使用名为 JMSDemo 的主题，不过，在使用缺省设置时，事先没有必要定义主题。这样，就完成了运行 JMSDemo 应用程序所需的配置。

2. 获取示例代码

演示应用程序是以压缩格式提交的。请使用您喜欢的解压缩实用工具将文件解压缩到您的本地磁盘中。选择保留目录的选项，以便将文件解压缩到本地磁盘上名为 JMSDEMO 的新目录中。在该目录中，您可以找到运行程序所需的所有文件。花些时间来熟悉一下这些文件：

JMSAdmin.config——通知 JMSAdmin 工具将文件系统用于 JNDI 注册服务。
JMSAdmin.bat——执行 WebSphere MQ JMS Administration 工具。
JMSDemoPub.bat——作为发布者执行示例程序。
JMSDemoReceive.bat ——执行示例程序，以便在队列上使用消息。
JMSDemoSend.bat ——执行示例程序，以便在队列上生成消息。
JMSDemoSub.bat ——作为订户执行示例程序。
jmsdemoJNDIbindings.scp ——将定义为连接工厂的受管理对象设置为使用绑定模式。
jmsdemoJNDIclient.scp ——将定义为连接工厂的受管理对象设置为使用客户机模式。

3. 配置受管理对象

在示例应用程序中使用的每个连接工厂或目的地必须使用唯一名称在 JNDI 目录中注册。示例应用程序使用该名称查找 JMS 受管理对象。使用基础 WebSphere MQ 对象名称和属性配置特定于提供程序的对象。下载文件提供的 .scp 文件中包含示例定义。

了解受管理对象的属性非常重要，因为它们控制 JMS 应用程序和 WebSphere MQ 之间的交互。各种对象属性的设置对 JMS 应用程序的行为和性能有重要影响。然而，此配置不是 JMS 应用程序的一部分；如何执行该配置的详细信息是特定于 WebSphere MQ 的。

配置所需的受管理对象：

配置连接工厂

连接工厂需要声明队列管理器名称参数，但不需要此参数包含值。当填充此参数时，提供的值必须匹配队列管理器名称，否则连接将失败。当值为空时，如果将本地队列管理器配置为缺省队列管理器，使用绑定模式，连接将成功，或对于任何队列管理器使用客户机模式，连接也会成功。在示例中，此值保留为空。

传输参数也是必需的，它通知 JMS 是使用客户机模式连接，还是使用绑定模式连接。当使用客户机模式时，必须指定 host、chan 和 port 参数：
- host ——队列管理器驻留的主机名或 IP 地址。
- chan ——包含连接队列管理器所使用的 SVRCONN 通道的名称。
- port——队列管理器侦听的端口号。
某些连接工厂参数没有严格要求，但是这些参数非常重要，需要在这里提一下：
- FAILIFQUIESCE ——使队列管理器能够中断任何 API 调用，以便关闭。此参数的缺省值是启用；请注意，禁用它可能对队列管理器带来负面影响。尤其是在使用客户机模式连接时。
- SYNCPOINTALLGETS—— 有助于确保应用程序不丢失任何消息。在以客户机模式运行时，这一点尤其重要，因为从队列删除消息和通过网络将其发送到应用程序之间存在一个延迟。如果在此期间失去网络连接，则消息无法恢复，除非消息位于同步点之下。在连接工厂中设置 SYNCPOINTALLGETS 可以确保消息回滚（除非消息被确认）。确认是自动发生的，因此这不影响程序代码。（有关同步点操作的完整讨论，请参见 WebSphere MQ Application Programming Guide 和 WebSphere MQ Using Java 手册。）
对于演示程序，提供了两个连接工厂目录定义，一个配置为绑定模式，另一个配置为客户机模式，如下所示。

绑定模式连接工厂定义（来自 jmsdemoJNDIbindings.scp 文件）：

#---------------------------------------------------------------
#ConnectionFactoryforBindingsmode
#DeletetheConnectionFactoryifitexists
DELETECF(JMSDEMOCF)

#DefinetheConnectionFactory
DEFINECF(JMSDEMOCF)+
SYNCPOINTALLGETS(YES)+
TRAN(bind)+
QMGR()

#Displaytheresultingdefinition
DISPLAYCF(JMSDEMOCF)

客户机模式连接工厂定义（来自 jmsdemoJNDIclient.scp 文件）：

#---------------------------------------------------------------

#ConnectionFactoryforClientmode

#DeletetheConnectionFactoryifitexists

DELETECF(JMSDEMOCF)

#DefinetheConnectionFactory

DEFINECF(JMSDEMOCF)+

SYNCPOINTALLGETS(YES)+

TRAN(client)+

HOST(localhost)CHAN(SYSTEM.DEF.SVRCONN)PORT(1414)+

QMGR()

#Displaytheresultingdefinition

DISPLAYCF(JMSDEMOCF)

缺省情况下，每个队列管理器上都存在 SYSTEM.DEF.SVRCONN 通道。为方便起见，我们在这里使用此通道，但是，它作为最佳实践却意义不大，因为通常不使用 SYSTEM.* 对象。如果您希望在队列管理器上运行其他人管理的示例，那么 WebSphere MQ 管理员需要定义 SVRCONN 通道，您才能使用。在这种情况下，请确保将正确的通道名称放置到 jmsdemoJNDIclient.scp 文件中。

配置目的地

其他定义是 jmsdemoJNDIclient.scp 文件和 jmsdemoJNDIbindings.scp 文件共有的。

我们已经知道，每个 JMS 受管理对象必须在可以通过 JNDI 访问的目录中注册。为了将目录名称映射到队列名称或主题名称，必须设置 WebSphere MQ、队列或主题属性，这是众所周知的。此属性不存在缺省值，并且区分大小写。

FAILIFQUIESCE 属性对队列和主题对象有效。它不从连接工厂继承；不过，其缺省值为“YES”，所以它并不包括在示例定义中。除了队列名称的 WebSphere MQversion 属性外，所有其他属性也可以采用其缺省值。

队列定义（在 jmsdemoJNDIclient.scp 和 jmsdemoJNDIclient.scp 文件中）：

#---------------------------------------------------------------

#QueueObject

#DeletetheQueueifitexists

DELETEQ(JMSDEMOQueue)

#DefinetheQueueobject

DEFINEQ(JMSDEMOQueue)QUEUE(JMSDEMO.QL)

#DisplaytheresultingQueueobjectdefinition

DISPLAYQ(JMSDEMOQueue)

除了有关队列的属性外，WebSphere MQ 主题定义还包括促进与发布/订阅代理通信的许多属性。其中包括服务的不同类、订阅持久性和将消息发布到或从中读取消息的队列。如果在您创建的队列管理器上运行的是演示版，则缺省值就可以了。如果您在其他人管理的队列管理器上运行，则管理员可能提供其中的一些属性值，特别是 BROKERPUBQ 和 BROKERSUBQ。示例定义采用所有缺省值。

主题定义（在 jmsdemoJNDIclient.scp 和 jmsdemoJNDIclient.scp 文件中）：

#---------------------------------------------------------------

#TopicObject

#DeletetheTopicifitexists

DELETET(JMSDEMOTopic)

#DefinetheTopic

DEFINET(JMSDEMOTopic)TOPIC(JMSDEMOtopic)

#DisplaytheresultingTopicdefinition

DISPLAYT(JMSDEMOTopic)

绑定受管理对象

在前面步骤中创建的受管理对象在供 JMS 应用程序使用之前，需要在目录中注册。告诉注册项将 JNDI 名称“绑定”到特定于提供程序的资源。WebSphere MQ 提供管理工具，以便在 JNDI 可访问的任何目录服务中创建和管理受管理对象。示例代码包括一个调用 WebSphere MQ JMS 管理工具的脚本，还包括我们将使用的受管理对象的定义脚本。
1. 打开命令提示符，并转到 JMSDEMO 目录。
2. 运行带有绑定定义的 JMSAdmin 脚本，如图 9 所示。
图 9. 运行 JMSAdmin

此时，您应继续进行下一步，并执行代码。使用绑定模式成功执行示例后，您可以重新回到此步骤，并使用客户机模式定义运行 JMSAdmin 脚本。这将导致示例代码通过 TCP/IP（而不是通过 IPC）连接到队列管理器。您可以在绑定模式和客户机模式之间自由切换，而不会影响示例应用程序。在使用客户机模式时，SVRCONN 通道在处于 ACTIVE 状态的 WebSphere MQ Explorer 中可见。

4. 运行示例代码

现在已经配置了 WebSphere MQ，并在 JNDI 目录中定义了受管理对象，我们已经准备好运行本文附带的示例。为此，请执行以下步骤：

执行点到点示例
1. 打开三个命令提示符窗口，并在每个窗口中转到 JMSDEMO 目录。
2. 要执行点到点的示例，请在一个窗口（图 10）中运行 JMSDemoSend.bat，在另一个窗口（图 11）中运行 JMSDEMOReceive.bat。程序将显示一些诊断信息，然后等待输入。
3. 将任何消息键入到 JMSDemoSend.bat 窗口，它应该在 JMSDemoReceive.bat 窗口中显示。输入一个空行，以结束操作。
  
  图 10. JMSDemoSend.bat 窗口
  
  图 11. JMSDemoReceive.bat 窗口
  
  注意，在第一个窗口（图 10）中，我们发送的消息内容是“Test message”。然后您会注意到，在第二个窗口（图 11）中，我们接收的消息内容是“Test message”。
执行发布/订阅示例

运行发布/订阅示例：
1. 通过输入 strmqbrk 命令，确保发布/订阅代理运行。
2. 在一个窗口（图 12）中运行 JMSDemoPub.bat，在其他两个窗口（图 13）中运行 JMSDemoSub.bat。
3. 将任何消息输入到 JMSDemoPub.bat 窗口，它将在两个 JMSDemoSub.bat 窗口中显示。输入一个空行，以结束操作。
图 12. JMSDemoPub.bat 窗口

图 13. 两个 JMSDemoSub.bat 窗口应该完全相同。

注意，在第一个窗口（图 12）中，我们发送的消息内容是“Test publication”，在第二个和第三个窗口（图 13）中，接收的消息内容均为“Test publication”。

结束语

在本文中，您了解了 J2SE 应用程序如何作为消息提供程序使用 JMS 和 JNDI 访问 WebSphere MQ，而无需在 J2EE 应用服务器（如 WebSphere Application Server）中进行部署。

您已了解了以下内容：

JMS 应用程序如何包含三个特殊层：
- 与提供程序无关的 JMS 应用程序。
- 特定于提供程序的 JMS 实现。
- JMS 提供程序。
应用程序如何使用两种模式（绑定模式和客户机模式）中的任一模式附加到 WebSphere MQ。
应用程序如何使用 JNDI 在 JMS 实现层中访问 JMS 受管理对象。
如何配置 WebSphere MQ。
如何管理 WebSphere MQ 资源，以便作为 JMS 管理对象使用 JNDI 来访问它们。

为使用 WebSphere MQ，您现在已做好了部署新的和现有的 Java 应用程序的准备。

下载

描述名字大小下载方法 Code sample

JMSDEMO.zip	10 KB	HTTP


	关于下载方法的信息

参考资料

学习

您可以参阅本文在 developerWorks 全球站点上的英文原文。
WebSphere MQ——产品主页
WebSphere MQ V6.0 library——所有产品手册
WebSphere MQ Product support——WebSphere MQ 支持主页
Extended Transactional Client——支持 XA 事务的客户机模式 WebSphere MQ 客户机
IBM WebSphere MQ Information Center——WebSphere MQ 的核心文档
WebSphere MQ Using Java ——从 Java 使用 WebSphere MQ
WebSphere MQ System Administration Guide——如何管理 WebSphere MQ
IBM developerWorks WebSphere zone——为开发人员提供所有 WebSphere 家族产品（包括 WebSphere MQ）的信息
为 WebSphere MQ 开发独立的 Java 应用程序——作者 Bobby Woolf，developerWorks，2005 年 4 月 01 日——WebSphere MQ V5.3 的初始文章
JMS 1.1 通过统一的域简化了消息传递——作者 Bobby Woolf，developerWorks，2002 年 9 月 3 日——阐释 JMS 1.1 中如何将队列和主题统一起来
在 J2EE 1.3 中消除服务定位器实现中的缓存——作者 Bobby Woolf，developerWorks，2004 年 11 月 01 日——包含 JNDI 的详细解释
这些关于 WebSphere Application Server 中 JMS 实现的文章还讨论了 JMS 应用程序如何与消息提供程序连接。
- 将消息驱动 Bean 和 JMS 应用程序部署到服务集成总线中——作者 Roland Barcia 和 Saravana Chandran，developerWorks，2005 年 4 月 13 日——讨论 JMS 点到点的工作方式
- 在服务集成总线中部署发布/订阅应用程序——作者 Roland Barcia 和 Bobby Woolf，developerWorks，2005 年 8 月 17 日——讨论 JMS 发布/订阅的工作方式