第 2 章 客户端编程模型

本章介绍 Message Queue 客户端编程的基本知识，其中包括下列主题：

• 消息传送域

• 编程对象

• 生成消息

• 使用消息

• 请求-回复模式

• 可靠消息传送

• 消息在系统中的传送路线

• Java 客户端与 C 客户端

本章重点介绍 Java 客户端的设计与实现。总体来说，C 客户端设计与 Java 客户端设计大致相同。本章的最后一节概述了 Java 客户端与 C 客户端的区别。有关 Message Queue 客户端编程的详细论述，请参见《Sun Java System Message Queue 3.7 UR1 Developer’s Guide for Java Clients》和《Sun Java System Message Queue 3.7 UR1 Developer’s Guide for C Clients》。

第 3 章，Message Queue 服务介绍如何使用 Message Queue 服务支持、管理和调整消息传送性能。

设计与性能

Message Queue 应用程序的行为取决于多个因素：客户端设计、连接配置、代理配置、代理调整及资源管理。在这些因素中，一部分是开发者的责任，另外一部分则是管理员的责任。不过，最理想的情况是开发者了解 Message Queue 服务如何支持和扩展应用程序设计，而管理员在调整应用程序时了解设计目标。通过重新设计以及仔细的监视和调整，可以优化消息传送性能。所以，开发出高性能 Message Queue 应用程序的关键是开发者和管理员了解应用程序生命周期各阶段可实现的目标，并交流有关预期性能及观测性能的信息。

消息传送域

消息传送中间件使各组件和应用程序可通过生成并使用消息来进行通信。JMS API 定义管理该通信的两种模式或消息传送域：点对点消息传送和发布/订阅消息传送。JMS API 的组织可支持这些模式。基本 JMS 对象包括：用于指定两个域中的消息传送行为的连接、会话、生成方、使用方、目的地和消息。

点对点消息传送

在点对点域中，消息生成方被称为发送者，而使用方被称为接收者。它们通过被称为队列的目的地来交换消息：发送者生成队列中的消息；而接收者则使用队列中的消息。

图 2–1 显示了点对点域中最简单的消息传送操作。MyQueueSender 向队列目的地 MyQueue1 发送 Msg1。然后， MyQueueReceiver 从 MyQueue1 获得该消息。

图 2–1 简单点对点消息传送

图 2–2 显示了一个更为复杂的点对点消息传送图，以说明该域中的可能情况。两个发送者 MyQSender1 和 MyQSender2 使用同一连接向 MyQueue1 发送消息。 MyQSender3 使用另一连接向 MyQueue1 发送消息。在接收端，MyQReceiver1 独占一个连接使用 MyQueue1 中的消息，而 MyQReceiver2 和 MyQReceiver3 共享一个连接以使用 MyQueue1 中的消息。

图 2–2 复杂点对点消息传送

这个较为复杂的图说明了有关点对点消息传送的其他几点。

• 多个生成方可向一个队列发送消息。生成方可共享连接或使用不同连接，但它们均可访问同一队列。

• 多个接收者可以使用一个队列中的多条消息，但每条消息只能由一个接收者使用。所以，Msg1、Msg2 和 Msg3 由不同的接收者使用。（这是 Message Queue 的扩展。）

• 接收者可共享连接或使用不同连接，但它们均可访问同一队列。（这是 Message Queue 的扩展。）

• 发送者和接收者之间不存在时间上的相关性：客户端发送一条消息后，无论接收者是否正在运行，都能获取该消息。

• 可在运行时动态添加和删除发送者和接收者，这样，即可根据需要缩放消息传送系统。

• 消息在队列中按发送的顺序排列，但使用消息的顺序取决于多种因素，例如消息失效日期、消息优先级以及使用消息时是否使用了选择器。

点对点模型具有许多优势：

• 由于多个接收者可以使用同一队列中的消息，因此如果消息的接收顺序不重要，则可以对消息的使用进行负载平衡。（这是 Message Queue 的扩展。）

• 要发送到队列的消息始终保留，即使没有接收者也是如此。

• Java 客户端可以使用队列浏览器对象检查队列的内容。然后，它们可以根据通过该检查所获得的信息来使用消息。也就是说，虽然使用模型一般为 FIFO（first in, first out，先进先出），但如果使用者知道要使用哪些消息，即可使用消息选择器来使用未处于队列最前方的消息。管理客户端也可以使用队列浏览器来监视队列的内容。

发布/订阅消息传送

在发布/订阅域中，消息生成方被称为发布者，而消息使用方则被称为订户。它们通过称为主题的目的地来交换消息：发布者生成主题中的消息；订户则订阅主题并使用主题中的消息。

图 2–3 显示了发布/订阅域中的简单消息传送操作。MyTopicPublisher 向目的地 MyTopic 发布 Msg1。然后，MyTopicSubscriber1 和 MyTopicSubscriber2 均从 MyTopic 接收 Msg1 的副本。

图 2–3 简单发布/订阅消息传送

虽然发布/订阅模型不要求多个订户，但图中仍显示了两个订户来强调通过此域可以广播消息。一个主题的所有订户均可获得发布到该主题的任何消息的副本。

长期订户可能处于活动状态，也可能处于非活动状态。代理会为所有活动订户保留消息，但对于非活动订户，则只为那些长期订户保留消息。

图 2–4 显示了更为复杂的发布/订阅消息传送图，以说明该模式提供的可能情况。多个生成方向 Topic1 目的地发布消息。多个订户使用来自 Topic1 目的地的消息。除非订户使用选择器来过滤消息，否则每个订户均可获得发布到所选主题的所有消息。在图 2–4 中，MyTSubscriber2 已过滤掉 Msg2。

图 2–4 复杂发布/订阅消息传送

这张较为复杂的图说明了有关发布/订阅消息传送的很多其他点。

• 多个生成方可向一个主题发布消息。生成方可共享连接或使用不同连接，但它们均可访问同一主题。

• 多个订户可使用一个主题中的消息。订户可检索发布到一个主题中的所有消息，除非它们使用选择器过滤掉消息或消息在使用之前已过期。

• 订户可共享连接或使用不同连接，但它们均可访问同一主题。

• 长期订户可能处于活动状态，也可能处于非活动状态。在它们处于非活动状态时，代理会为它们保留消息。

• 可在运行时动态添加和删除发布者和订户，这样，即可根据需要缩放消息传送系统。

• 消息按发送的顺序发布到主题，但使用消息的顺序取决于多种因素，例如消息失效日期、消息优先级以及使用消息时是否使用了选择器。

• 发布者与订户之间存在时间上的相关性：主题订户只能使用在它创建订阅后发布的消息。

发布/订阅模型的最大优点是消息可以广播给订户。

特定于域的 API 及统一域 API

JMS API 定义可用于实现点对点域或发布/订阅域的接口和类。这些是表 2–1 的第 2 列和第 3 列中显示的特定于域的 API。JMS API 还定义另外一个统一域，用于通过编程实现常规的消息传送客户端。这类客户端的行为由目的地类型决定，客户端向目的地中生成消息并使用目的地中的消息。如果该目的地是一个队列，则消息传送行为将为点对点模式；如果该目的地是一个主题，则消息传送行为将为发布/订阅模式。

表 2–1 JMS 编程域和对象

基本类型（统一域）	点对点域	发布/订阅域
Destination（队列或主题）	Queue	Topic
ConnectionFactory	QueueConnectionFactory	TopicConnectionFactory
Connection	QueueConnection	TopicConnection
Session	QueueSession	TopicSession
MessageProducer	QueueSender	TopicPublisher
MessageConsumer	QueueReceiver	TopicSubscriber

统一域通过 JMS 版本 1.1 引入。 如果需要遵守早期的 1.02b 规范，则可以使用特定于域的 API。使用特定于域的 API 还能够提供全新编程接口，可以防止出现某些类型的编程错误：例如，为队列目的地创建长期订户。但是，特定于域的 API 的缺点是，不能在同一事务或同一会话中将点对点和发布/订阅操作相结合。如果需要执行该操作，则应选择统一域 API。有关将两种域相结合的示例，请参见请求-回复模式。

编程对象

用于实现 JMS 消息传送的对象在编程域中基本保持不变：连接工厂、连接、会话、生成方、使用方、消息和目的地。图 2–5 中显示了这些对象。图中从连接工厂对象开始，自上而下地显示对象是如何派生出来的。

显示的连接工厂和目的地这两类对象驻留在对象存储库中。这是为了强调通常将这些对象作为受管理对象来创建、配置和管理。我们假定本章中的连接工厂和目的地都是以管理方式（而不是以编程方式）创建的。

图 2–5 JMS 编程对象

表 2–2 总结了发送和接收消息所需的步骤。请注意，步骤 1 到 6 对于发送者和接收者来说是相同的。

表 2–2 生成和使用消息

生成消息	使用消息
1. 管理员创建连接工厂受管理对象。
2. 管理员创建物理目的地以及引用该目的地的受管理对象。
3. 客户端通过 JNDI 查找获得连接工厂对象。
4. 客户端通过 JNDI 查找获得目的地对象。
5. 客户端创建连接并设置特定于此连接的任何属性。
6. 客户端创建会话并设置用于决定消息传送可靠性的属性。
7. 客户端创建消息生成方	客户端创建消息使用方
8. 客户端创建消息。	客户端建立连接。
9. 客户端发送消息。	客户端接收消息。

下面各节介绍生成方和使用方使用的对象：连接、会话、消息和目的地。之后，我们将通过说明消息的生成和使用来完成对 JMS 对象的介绍。

连接工厂和连接

客户端使用连接工厂对象 (ConnectionFactory) 创建连接。连接对象 (Connection) 表示客户端与代理之间的活动连接。它使用在默认情况下启动或者由管理员为该客户端明确启动的底层连接服务。

创建连接时会分配通信资源并对客户端进行验证。这是一个相当重要的对象，大多数客户端均使用一个连接来完成所有的消息传送。连接支持并发使用：一个连接可由任意数量的生成方和使用方共享。

创建连接工厂时，可通过设置它的属性来配置从它派生的所有连接的行为。对于 Message Queue，这些设置可指定以下信息：

• 代理所在主机的名称、需要的连接服务以及客户端用于访问该服务的端口。

• 连接失败时应如何处理与代理的自动重新连接。（如果连接断开，此功能会将客户端重新连接到同一个代理或另一个代理。但不保证进行数据故障转移：如果重新连接到不同代理，持久性消息及其他状态信息可能会丢失。）

• 需要代理跟踪长期订阅的客户端 ID。

• 尝试进行连接的用户的默认名称和密码。如果连接时未指定密码，则该信息用于验证用户和授权操作。

• 对于已确认可靠性的那些客户端是否应抑制代理确认。

• 如何管理代理与客户端运行时环境之间的控制消息和有效负荷消息的流动。

• 应如何处理队列浏览。（仅限于 Java 客户端。）

• 是否应覆盖某些消息头字段。

可以在用于启动客户端应用程序的命令行上覆盖连接工厂属性。还可以通过设置任意给定连接的属性来覆盖该连接的属性。

可使用连接对象来创建会话对象，从而设置异常侦听器或者获得 JMS 版本及提供者信息。

会话

如果连接代表客户端与代理之间的通信渠道，则会话标记客户端与代理之间的单次对话。会话对象主要用于创建消息、消息生成方和消息使用方。创建会话时，通过多个确认选项或通过事务来配置可靠传送。有关详细信息，请参见可靠消息传送。

根据 JMS 规范，会话是生成和使用消息的单线程上下文。可以为一个会话创建多个消息生成方和使用方，但只能顺次使用它们。Java 客户端和 C 客户端的线程实现稍有不同。有关线程实现与限制的其他信息，请参考相应的开发者指南。

还可以使用会话对象来完成以下任务：

• 为不使用受管理对象定义目的地的那些客户端创建和配置目的地。

• 创建和配置临时主题和队列，它们将用作请求-回复模式的一部分。请参见请求-回复模式。

• 支持事务处理。

• 定义生成或使用消息的顺序。

• 为异步使用方序列化消息侦听器的执行。

• 创建队列浏览器。（仅限于 Java 客户端。）

消息

消息由三部分组成：消息头、属性和主体。必须了解此结构，才能正确编写消息和配置某些消息传送行为。

消息头

消息头是每条 JMS 消息所必需的。消息头包含十个预定义字段，表 2–3 中列出并介绍了这些字段。

表 2–3 JMS 定义的消息头

头字段	描述
JMSDestination	指定消息要发送到的目的地对象的名称。（由提供者设置。）
JMSDeliveryMode	指定消息是否为持久性消息。（默认情况下由提供者设置，也可以由客户端为生成方或为单独的消息显式设置。）
JMSExpiration	指定消息的到期时间。（默认情况下由提供者设置，也可以由客户端为生成方或为单独的消息设置。）
JMSPriority	在 0（低）到 9（高）的范围内指定消息的优先级。（默认情况下由提供者设置，也可以由客户端为生成方或为单独的消息显式设置。）
JMSMessageID	指定消息在提供者安装的上下文中的唯一 ID。（由提供者设置。）
JMSTimestamp	指定提供者接收消息的时间。（由提供者设置。）
JMSCorrelationID	客户端用于定义两条消息之间的对应性的值。（由客户端在需要时设置。）
JMSReplyTo	指定使用方应发送回复的目的地。（由客户端在需要时设置。）
JMSType	可由消息选择器评估的值。（由客户端在需要时设置。）
JMSRedelivered	指定消息是否已传送但尚未得到确认。（由提供者设置。）

从表中可以看出，消息头字段有多种用途：标识消息、配置消息的路由以及提供有关消息处理的信息等。

其中最重要的字段之一 JMSDeliveryMode，用于决定消息传送的可靠性。该字段指示一条消息是否为持久性消息。

• 持久性消息保证一次即可传送并成功使用。即使消息服务失败，持久性消息也不会丢失。

• 非持久性消息最多保证传送一次。如果消息服务失败，非持久性消息将丢失。

部分消息头字段由提供者（代理或客户端运行时环境）设置，其他头字段则由客户端设置。消息生成方可能需要配置头字段值，才能实现某些消息传送行为；消息使用方可能需要读取头字段值，才能了解消息的路由方式以及可能需要对它执行哪些进一步处理。

头字段（JMSDeliveryMode、JMSExpiration 和 JMSPriority）可以在三个不同的级别上进行设置：

• 对于通过从连接工厂派生的每个连接发出的消息。

• 对于生成的每条消息。

• 对于特定消息生成方发出的所有消息。

如果这些字段在多于一个级别上进行设置，则为连接工厂设置的值将覆盖为单条消息设置的值；为给定消息设置的值将覆盖为消息生成方设置的值。

消息头字段的固定名称因语言实现而异。有关详细信息，请参见《Sun Java System Message Queue 3.7 UR1 Developer’s Guide for Java Clients》或《Sun Java System Message Queue 3.7 UR1 Developer’s Guide for C Clients》。

消息属性

消息还可以包含称为属性的可选头字段，这类字段以属性名/属性值对的形式来指定。客户端和提供者可以使用属性来扩展消息头，并可以在其中包含有助于客户端或提供者标识和处理消息的任何信息。通过消息属性，接收客户端可以只传送符合给定标准的消息。例如，使用方客户端可能请求获得有关新泽西州兼职雇员工资单的消息。提供者将不会传送不符合指定标准的消息。

JMS 规范定义了九个标准属性。其中某几个属性由客户端设置，另外几个由提供者设置。属性的名称以保留字符 "JMSX" 开头。客户端或提供者可以使用这些属性决定消息的发送者、消息的状态以及消息传送的频率和时间。这些属性有助于提供者提供路由消息和诊断信息。

Message Queue 也定义消息属性，它们用于标识压缩消息以及在无法传送消息时应如何处理消息。有关详细信息，请参见《Sun Java System Message Queue 3.7 UR1 Developer’s Guide for Java Clients》中的“Managing Message Size”。

消息主体

消息主体包含客户端需要交换的数据。

JMS 消息类型决定了主体可以包含哪些内容以及使用方应如何处理主体，如表 2–4 中所指定的那样。Session 对象包含各类消息主体的创建方法。

表 2–4 消息主体类型

类型	描述
StreamMessage	主体中包含 Java 基元值流的消息。它的填充和读取均按顺序进行。
MapMessage	主体中包含一组名/值对的消息。没有定义条目顺序。
TextMessage	主体中包含 Java 字符串的消息，例如 XML 消息。
ObjectMessage	主体中包含序列化 Java 对象的消息。
BytesMessage	主体中包含连续字节流的消息。
Message	包含消息头和属性但不包含主体的消息。

Java 客户端可以对属性进行设置，使客户端运行时环境压缩要发送的消息的主体。而使用方一端的 Message Queue 运行时环境会在传送消息前先解压缩该消息。

生成消息

消息由消息生成方在连接和会话的上下文中发送或发布。生成消息相当简单：客户端使用消息生成方对象 (MessageProducer) 将消息发送给物理目的地，在 API 中用目的地对象表示。

创建生成方时，可以指定发送所有生成方消息的默认目的地。您也可以指定决定持久性、优先级和有效期的消息头字段的默认值。这样，从该生成方发出的所有消息都使用这些默认值，除非您通过在发送消息时指定替代目的地，或者为给定消息的头字段设置替代值来覆盖它们。

这些消息生成方还可以通过设置 JMSReplyTo 消息头字段实现请求-回复模式。有关详细信息，请参见请求-回复模式。

使用消息

消息由消息使用方在连接和会话的上下文中接收。客户端使用消息使用方对象 (MessageConsumer) 接收指定物理目的地中的消息，在 API 中表示为目的地对象。

消息如何由代理传送给使用方受三方面因素的影响：

• 使用是同步的还是异步的

• 是否使用选择器来过滤传入消息

• 如果使用主题目的地中的消息，则订户是否为长期订户也会有影响。

影响消息传送和客户端设计的另一主要因素是使用方需要的可靠度。请参见可靠消息传送。

同步和异步使用方

消息使用方可以支持同步或异步消息使用。

• 同步使用表示使用方明确要求传送消息并使用该消息。

  根据请求消息时使用的方法，同步使用方可选择等待（无限期）消息到达，等待指定的时间或者在不存在可供使用的消息时立即返回。（“可供使用”是指对象立即可供客户端使用。成功发送但代理尚未处理完成的消息还不能使用。）

• 异步使用是指，自动将消息传送给为使用方注册的消息侦听器对象 (MessageListener)。当会话线程调用消息侦听器对象的 onMessage() 方法时，客户端将使用该消息。

使用选择器过滤消息

消息使用方可以使用消息选择器，使消息服务只传送属性符合特定选择标准的消息。该标准在创建使用方时指定。

选择器使用类似 SQL 的语法与消息属性匹配。例如，

color = ”red’
size > 10

Java 客户端还可以在浏览队列时指定选择器，这样就可以查看哪些选定消息正在等待使用。

使用长期订户

可以使用会话对象创建主题的长期订户。即使订户变为非活动状态，代理也会为这些类型的订户保留消息。

由于代理必须维护订户的状态并在订户被重新激活后恢复消息传送，因此，代理必须能够在给定订户的订阅期内识别该订户。订户标识是根据创建该订户的连接的 ClientID 属性以及创建订户时指定的订户名构造的。

请求-回复模式

可以在一个连接中同时包含生成方和使用方（在使用统一 API 时甚至可包含会话）。此外，JMS API 允许使用临时目的地来实现消息传送操作的请求-回复模式。

要设置请求-回复模式，需要执行以下操作：

1. 创建使用方可发送回复的临时目的地。

2. 在要发送的消息中，将消息头的 JMSReplyTo 字段设置为该临时目的地。

消息使用方处理消息时，将检查消息的 JMSReplyTo 字段以决定是否需要回复，并将该回复发送到指定目的地。

请求-回复机制为生成方免去了设置回复目的地的受管理对象的麻烦，同时让使用方可以轻松地响应请求。当生成方只有在确保请求已处理后才能继续时，此模式非常有用。

图 2–6 说明了请求-回复模式，即向主题中发送消息并接收临时队列中的回复。

图 2–6 请求-回复模式

如图所示，MyTopicPublisher 生成 Msg1 并将它发送到目的地 MyTopic。MyTopicSubsriber1 和 MyTopicSubscriber2 接收该消息并向 MyTempQueue 发送回复，MyTQReceiver 从 MyTempQueue 中检索该回复。该模式可能适用于向大量客户端发布定价信息，并将客户端的回复订单排队以便按顺序进行处理的应用程序。

临时目的地的存在时间只能与创建它们的连接的存在时间一样长。任何生成方都可以向临时目的地发送消息，但只有创建目的地的连接所创建的那些使用方能够访问临时目的地。

由于请求/回复取决于临时目的地的创建，因此在下列情况中不应使用此模式：

• 如果预计创建临时目的地的连接可能在回复发送前终止。

• 如果您需要向临时目的地发送持久性消息。

可靠消息传送

消息传送在两个跃点上进行：第一个跃点从代理上的物理目的地的生成方获得消息；第二个跃点从使用方的目的地获得消息。因此，在下面的三个阶段，消息可能丢失：在至代理的跃点上，当代理发生故障时在代理内存中，以及在代理至使用方的跃点上。可靠传送可保证传送过程在上述任一阶段都不会失败。由于当代理发生故障时非持久性消息总是会丢失，因此可靠传送仅适用于持久性消息。

使用了两种机制来确保可靠传送：

• 客户端可以使用确认或事务确保成功生成和使用消息。

• 代理可以在持久性存储库中存储消息，这样，如果代理在消息被使用前发生故障，它可以检索存储的消息副本并重试操作。

以下各节将介绍这两个方面的可靠性保证措施。

确认

确认是指客户端与消息服务之间为确保可靠消息传送而发送的消息。对于生成方和使用方，确认的用途是不同的。

如果是生成消息，则代理将确认收到消息、将消息传送到其目的地并将其持久存储。生成方的 send() 方法会被阻止，直至它收到此确认为止。这些确认对于持久性消息要发送到的客户端是透明的。

使用消息时，客户端确认已收到从某个目的地传送来的消息并已使用它，然后代理从该目的地中删除该消息。JMS 指定不同的确认模式代表不同的可靠度。

• 在 AUTO_ACKNOWLEDGE 模式下，会话自动确认客户端使用的每条消息。会话线程会被阻止，以等待代理确认它已处理了每个已使用消息的客户端确认。

• 在 CLIENT_ACKNOWLEDGE 模式下，在一条或多条消息被使用后，客户端通过调用消息对象的 acknowledge() 方法来显式确认。这样该会话就确认了自上次调用该方法后使用的所有消息。会话线程会被阻止，以等待代理确认它已处理了客户端确认。

  Message Queue 提供使客户端可仅仅确认收到一条消息的方法，从而扩展了该模式。

• 在 DUPS_OK_ACKNOWLEDGE 模式下，会话在使用了十条消息后进行确认。会话线程不会因等待代理确认而被阻止，因为在该模式下代理确认不是必需的。虽然该模式可保证不会丢失消息，但并不能保证不会收到重复的消息，因此名称为：DUPS_OK。

对于更关心性能而不是可靠性的客户端， Message Queue 服务通过提供 NO_ACKNOWLEDGE 模式来扩展 JMS API。在该模式下，代理不跟踪客户端确认，所以不保证使用方客户端已成功处理了消息。对于发送至非长期订户的非持久性消息，选择该模式可提高性能。

事务

事务是将一条或多条消息的生成和/或使用组合到一个工作单位的方法。上述客户端和代理确认过程同样适用于事务。在这种情况下，客户端运行时环境和代理确认默认在事务级别进行。当事务提交时，将自动发送代理确认。

可以将会话配置为事务，并且 JMS API 提供了启动、提交和回滚事务的方法。

在事务中生成或使用消息时，消息服务跟踪各个发送和接收过程，并只有在 JMS 客户端发出提交事务的调用时才完成这些操作。如果事务中特定的发送或接收操作失败，将引发异常。客户端代码可以通过忽略异常、重试操作或回滚整个事务来处理异常。事务提交时，所有操作都已完成。事务回滚时，所有成功的操作都取消。

事务的作用范围始终为一个会话。也就是说，可以将在单个会话上下文中执行的一个或多个生成方或使用方操作组成一个事务。由于事务只能跨越单个会话，因此不存在既包括消息生成又包括消息使用的端对端事务。

JMS 规范还支持分布式事务。也就是说，消息的生成和使用可以是大型分布式事务的一部分，该事务中包括涉及其他资源管理器（如数据库系统）的操作。必须有事务管理器（例如，Java Systems Application Server 提供的事务管理器）才能支持分布式事务。

在分布式事务中，分布式事务管理器使用在 Java 事务 API (Java Transaction API, JTA) XA 资源 API 规范中定义的两阶段提交协议，来跟踪和管理由多个资源管理器（如消息服务和数据库管理器）执行的操作。在 Java 领域中，资源管理器和分布式事务管理器之间的交互在 JTA 规范中进行了说明。

支持分布式事务是指消息传送客户端可通过 JTA 定义的 XAResource 接口参与分布式事务。此接口定义了实现两阶段提交的许多方法。当客户端进行 API 调用时，JMS 消息服务只与分布式事务管理器（由 Java 事务服务 (Java Transaction Service, JTS) 提供）协作来跟踪分布式事务中的各种发送和接收操作、跟踪事务状态并完成消息传送操作。与本地事务一样，客户端可以通过忽略异常、重试操作或回滚整个分布式事务来处理异常。

---

注 –

仅当 Message Queue 用作 Java Enterprise Edition 平台中的 JMS 提供者时，Message Queue 才支持分布式事务。有关如何使用分布式事务的其他信息，请参考应用服务器提供者提供的文档。

---

持久性存储库

另一方面的可靠性就是确保在将持久性消息传送至使用方之前，代理不会将它们丢失。这意味着，当消息到达物理目的地时，代理必须将其放入持久性数据存储库中。如果代理由于某种原因发生故障，它可以在以后恢复此消息并将此消息传送至相应的使用方。

代理还必须持久存储长期订阅。否则，当代理发生故障时，就无法向长期订户传送消息；当有消息到达主题目的地后，长期订户就会变为活动状态。

要保证成功传送消息，消息传送应用程序必须将消息指定为持久性消息，并将它们传送给具有长期订阅的主题目的地或传送给队列目的地。

第 3 章，Message Queue 服务介绍了 Message Queue 服务提供的默认消息存储库，以及管理员如何设置和配置备用存储库。

消息在系统中的传送路线

作为对上述内容的总结，本节介绍如何使用 Message Queue 服务从生成方向使用方传送消息。为了描绘一个完整的画面，我们需要补充另外一个细节：在传送过程中，系统处理的消息分为以下两类：

• 有效负荷消息，由生成方发送给使用方的消息。

• 控制消息，代理与客户端运行时环境之间传送的私有消息，用于确保有效负荷消息成功传送和控制跨连接的消息流。

消息传送在图 2–7 中进行了说明。

图 2–7 消息传送步骤

以持久、可靠的方式传送消息的步骤如下：

消息生成

1. 客户端运行时环境通过连接将消息从消息生成方传送到代理。

消息处理和路由

2. 代理从连接中读取消息并将此消息放入相应的目的地中。

3. 代理将（持久性）消息放入数据存储库中。

4. 代理向消息生成方的客户端运行时环境确认已收到消息。

5. 代理确定消息的路由。

6. 代理将消息从目的地写入适当的连接，并使用使用方的唯一标识符标记该消息。

消息使用

7. 消息使用方的客户端运行时环境将消息从连接传送到消息使用方。

8. 消息使用方的客户端运行时环境向代理确认消息已使用。

消息生命周期结束

9. 代理处理客户端确认，并在收到所有确认后删除（持久性）消息。

10. 代理向使用方的客户端运行时环境确认，告知客户端确认已得到处理。

如果管理员删除目的地中的消息，或者管理员删除或重新定义长期订阅，导致主题目的地中的消息未被传送即被删除，则代理可以在消息被使用前将它丢弃。在其他情况下，您可能希望代理将消息存储在称为停用消息队列的特殊目的地中，而不是将它们丢弃。在以下情况，消息会被放入停用消息队列中：消息过期时、消息因内存限制而被删除时，以及因客户端引发异常而导致传送失败时。通过将消息存储在停用消息队列中，您可以解决系统问题并在某些情况下恢复消息。

使用 SOAP 消息

使用 SOAP（请参见对 Java 客户端的 SOAP 支持）可以在分布式环境中的两个对等方之间交换结构化数据（由 XML 方案指定）。SOAP 的 Sun 实现当前不支持可靠 SOAP 消息传送，也不支持发布 SOAP 消息。不过，您可以使用 Message Queue 服务获得可靠的 SOAP 消息传送，并在需要时发布 SOAP 消息。Message Queue 服务并不直接传送 SOAP 消息，但它允许您将 SOAP 消息包装为 JMS 消息并像生成和使用正常的 JMS 消息一样生成和使用这些消息，然后从 JMS 消息中提取 SOAP 消息。

Message Queue 通过两种软件包提供 SOAP 支持：javax.xml.messaging 和 com.sun.messaging.xml。可以使用这些库中实现的类接收 SOAP 消息、将 SOAP 消息包装为 JMS 消息以及从 JMS 消息提取 SOAP 消息。J2EE 平台提供软件包 java.xml.soap，您可以使用它来组合和分解 SOAP 消息。

获取可靠 SOAP 消息传送

1. 使用 java.xml.soap 软件包中定义的对象构造 SOAP 消息，或使用 javax.xml.messaging 软件包中定义的 servlet 接收 SOAP 消息，也可以使用 JAX-RPC 等 Web 服务来接收 SOAP 消息。

2. 使用消息转换器实用程序将 SOAP 消息转换为 JMS 消息。

3. 将 JMS 消息发送到所需的目的地。

4. 异步或同步使用 JMS 消息。

5. 使用 JMS 消息后，使用消息转换器实用程序将其转换为 SOAP 消息。

6. 使用 SAAJ API（在 java.xml.soap 软件包中定义）分解 SOAP 消息。

   有关 SOAP 消息及其处理的详细信息，请参见《Sun Java System Message Queue 3.7 UR1 Developer’s Guide for Java Clients》中的第 5  章 “Working with SOAP Messages”。

Java 客户端与 C 客户端

Message Queue 向消息传送服务提供 C API，使传统 C 应用程序和 C++ 应用程序可参与基于 JMS 的消息传送。

JMS 编程模型是 Message Queue C 客户端设计的基础。《Sun Java System Message Queue 3.7 UR1 Developer’s Guide for C Clients》介绍了 C 数据类型和函数如何实现此模型。

与 Java 接口类似，C 接口也支持以下功能：

• 发布/订阅连接和点对点连接

• 同步及异步接收

• CLIENT、AUTO 和 DUPS_OK 确认模式

• 本地事务

• 会话恢复

• 临时主题和队列

• 消息选择器

但一定要理解 Java 消息服务规范是只适用于 Java 客户端的标准；而 C Message Queue API 是特定于 Message Queue 提供者的，且不能在其他 JMS 提供者中使用。包含 C 客户端的消息传送应用程序不能由另一个 JMS 提供者进行处理。

C 接口不支持以下功能：

• 使用受管理对象

• 映射、流或对象消息类型

• 基于使用方的流控制

• 队列浏览器

• JMS 应用服务器工具（连接使用方，分布式事务）

• 接收或发送 SOAP 消息

• 接收或发送压缩的 JMS 消息

• 自动重新连接或故障转移，使客户端运行时环境可在连接失败的情况下自动与代理重新连接

• NO_ACKNOWLEDGE 模式