消息中间件和JMS

消息中间件和JMS

当前，CORBA、DCOM、RMI等RPC中间件技术已广泛应用于各个领域。但是面对规模和复杂度都越来越高的分布式系统，这些技术也显示出其局限性：（1）同步通信：客户发出调用后，必须等待服务对象完成处理并返回结果后才能继续执行；（2）客户和服务对象的生命周期紧密耦合：客户进程和服务对象进程都必须正常运行；如果由于服务对象崩溃或者网络故障导致客户的请求不可达，客户会接收到异常；（3）点对点通信：客户的一次调用只发送给某个单独的目标对象。

面向消息的中间件（Message Oriented Middleware，MOM）较好的解决了以上问题。发送者将消息发送给消息服务器，消息服务器将消息存放在若干队列中，在合适的时候再将消息转发给接收者。这种模式下，发送和接收是异步的，发送者无需等待；二者的生命周期未必相同：发送消息的时候接收者不一定运行，接收消息的时候发送者也不一定运行；一对多通信：对于一个消息

可以有多个接收者。

已有的MOM系统包括IBM的MQSeries、Microsoft的MSMQ和BEA的MessageQ等。由于没有一个通用的标准，这些系统很难实现互操作和无缝连接。Java Message Service（JMS）是SUN提出的旨在统一各种MOM系统接口的规范，它包含点对点（Point to Point，PTP）和发布/订阅（Publish/Subscribe，pub/sub）两种消息模型，提供可靠消息传输、事务和消息过滤等机制。

1.JMS

JAVA 消息服务(JMS)定义了Java 中访问消息中间件的接口。JMS 只是接口，并没有给予实现，实现JMS 接口的消息中间件称为JMS Provider，iLink实现了JMS接口，用户可以通过使用JMS 接口，在iLink中进行JMS编程。 iLink支持JMS1.0.2版本。

2.JMS接口描述

JMS 支持两种消息类型PTP 和Pub/Sub，分别称作：PTP Domain 和Pub/Sub Domain，这两种

Connection ：JMS 客户端到JMS Provider 的连接

Destination ：消息的目的地

Session：一个发送或接收消息的线程

MessageProducer：由Session 对象创建的用来发送消息的对象

MessageConsumer：由Session 对象创建的用来接收消息的对象

3.JMS消息模型

JMS 消息由以下几部分组成：消息头，属性，消息体。

3.1 消息头(Header)

消息头包含消息的识别信息和路由信息，消息头包含一些标准的属性如：JMSDestination,JMSMessageID 等。

3.2 属性(Properties)

- 除了消息头中定义好的标准属性外，JMS 提供一种机制增加新属性到消息头中，这种新属性包含以下几种：

1. 应用需要用到的属性;

2. 消息头中原有的一些可选属性;

3. JMS Provider 需要用到的属性。

标准的JMS 消息头包含以下属性：

3.3 消息体(Body)

- JMS API 定义了5种消息体格式，也叫消息类型，你可以使用不同形式发送接收数据并可以兼容现有的消息格式，下面描述这5种类型：

下例演示创建并发送一个TextMessage到一个队列：

TextMessage message = queueSession.createTextMessage();

message.setText(msg_text); // msg_text is a String

queueSender.send(message);

下例演示接收消息并转换为合适的消息类型：

Message m = queueReceiver.receive();

if (m instanceof TextMessage) {

TextMessage message = (TextMessage) m;

System.out.println("Reading message: " + message.getText());

} else {

// Handle error

}

4. 消息的同步异步接收

消息的同步接收是指客户端主动去接收消息，JMS 客户端可以采用MessageConsumer 的receive方法去接收下一个消息。

消息的异步接收是指当消息到达时，主动通知客户端。JMS 客户端可以通过注册一个实现MessageListener 接口的对象到MessageConsumer，这样，每当消息到达时，JMS Provider

会调用MessageListener中的onMessage 方法。

5. PTP模型

PTP(Point-to-Point)模型是基于队列的，发送方发消息到队列，接收方从队列接收消息，队列的存在使得消息的异步传输成为可能。和邮件系统中的邮箱一样，队列可以包含各种消息，JMS Provider 提供工具管理队列的创建、删除。JMS PTP 模型定义了客户端如何向队列发送消息，从队列接收消息，浏览队列中的消息。

下面描述JMS PTP 模型中的主要概念和对象：

5.1 JMS队列术语

JMS使用消息队列的概念来实现点到点的消息发送。在点到点的消息发送中，总是有一个明确的消息生产者和一个消息消费者。在点到点的消息发送中，与时间没有多大的关系，除非消息发送者为消息定义了一个期限。消息接受这可以接收由消息生产者在过去任何一个时候发送的消息，即使在该消息被编入队列时消息消费者没有处于运行状态。

下面的图显示了一个点到点的消息发送场景。

JMS提供者是一个消息发送服务器，它负责处理消息的持久性、超时、重发、事务回滚以及由JMS提供的其他服务。对于J2EE SDK这种情况，JMS提供者是J2EE服务器程序的一部分。消息生产者发送对象到由JMS维护的一个队列中。消息消费者则从该队列接收消息，并发出确认，表示已经收到消息。

JMS规范定义了一些可用于在进程间发送消息的对象：

JMS管理的对象。有两种JMS管理的对象：目的地和连接工厂。这两种对象都是由系统管理员通过环境管理工具创建的。

目的地。这是一种服务器端的对象，通过这个对象进行消息的发送和接收。JMS队列就是一种目的地对象。连接工厂。这是一种服务器端的对象，负责配置和创建到一个特定目的地的连接。JMS 队列的JMS连接工厂就是一种QueueConnectionFactory。

连接。这是一种到一个JMS提供者（而不是到一个目的地）的虚拟连接。它被用来创建会话。用于访问队列的一个连接就是一种QueueConnection。

会话。这是一个潜在的消息传送和接收的事务性的工作单元。会话用于创建消息、消息生产者和消息消费者。用于访问队列的一个会话就是一种QueueSession。

消息。这是一种可以从消息目的地发送到消息消费者的对象。消息的类型随要发送的对象类型的不同而不同。例如，为本期提供的示例代码就使用了TextMessage对象。

消息生产者。这是一种由JMS客户端程序使用的、用于发送消息到目的地的对象。JMS客户端程序从一个会话中获取消息生产者对象。程序可以使用QueueSender这种类型的消息生产者对象来发送消息到一个队列中。

消息消费者。这是一种由JMS客户端程序使用的、用于从一个目的地接收消息的对象。JMS客户端程序从一个会话中获取消息接受者对象。程序可以使用QueueReceiver这种类型的消息消费者对象来从一个队列中接收消息。

这里颇有几个新的术语。现在让我们看看如何发送消息。以下步骤展示了从与本期一起提供的示例代码中抽出的一些例子。（想知道如何下载和运行该示例代码，请参考运行示例代码一节。）不过，在运行示例代码之前，你需要配置一下服务器（参见配置服务器一节）。

6. PUB/SUB模型

JMS Pub/Sub 模型定义了如何向一个内容节点发布和订阅消息，这些节点被称作主题(topic)。

主题可以被认为是消息的传输中介，发布者(publisher)发布消息到主题，订阅者(subscribe) 从主题订阅消息。主题使得消息订阅者和消息发布者保持互相独立，不需要接触即可保证消息的传送。

下面描述JMS Pub/Sub 模型中的主要概念和对象：

7. 开发JMS的步骤

广义上说，一个JMS 应用是几个JMS 客户端交换消息，开发JMS 客户端应用由以下几步构成：

用JNDI 得到ConnectionFactory 对象；

用JNDI 得到目标队列或主题对象，即Destination 对象；

用ConnectionFactory 创建Connection 对象；

用Connection 对象创建一个或多个JMS Session；

用Session 和Destination 创建MessageProducer 和MessageConsumer；

通知Connection 开始传递消息。

消息总线模式

在面向消息中间件（MOM）——基础架构样式中，消息总线模式是唯一最重要的架构设计。消息总线概念的核心部分是：所有的业务应用程序都连接到消息分发引擎上，该引擎确保将所有的消息可靠且有效的分发到它们该去的地方。通过事件驱动消息总线的每一个业务应用程序都是其它应用程序的同位体。总线接收到的每一个消息都是总线下一步需要处理的事件，通过处理该事件来确定该事件将影响哪个客户端（换句话说，需要接收及处理消息）。

图 1. 消息总线模式

虽然消息总线模式的实现与供应商有根大的关系，但其中仍有几个核心通用的概念：?消息通道：消息总线组件主要包含一个或多个单独的通道，可以通过这些通道传递消息。通道有下列特性：

o通道可以是应用程序指定的或消息指定的。

o通道可以是单向的或双向的。

o通道可以是定向广播的（所有的消息发向所有的应用程序），点对点的（消息发向特定的应用程序）或基于订阅的（消息发向特定感兴趣的应用程序）。

?消息代理: 消息总线可以包含消息代理，通过代理可以根据不同的业务标准确定该往何处发送消息。在基本模式中代理是可选的但是在企业系统中经常是关键性部件。

?通道过滤器: 过滤器是通道中执行某种类型操作的透明的截取消息的组件，例如记录日志、转换、上下文处理等等。就像代理一样，在理论上过滤器可选的，但在实际中却是很关键的。

图 2. 公共消息总线组件

应用程序通过一个或多个通道与消息总线交互。通道将消息移入或移出消息总线。应用程序有两种方式可从总线中接收消息：push或pull。在push 交换（也被称为事件通知）中，总线为某些等待的应用程序启动消息的传输。在pull 交换中，应用程序通过给总线发送某种形式的请求并接收一个或多个在响应中排队等候的消息来启动传输。推动模型是应用程序有能力保持固定连接或监听消息传递的通道。拖拽模型是应用程序仅间歇的连接到总线或不能与总线保持持久连接。

图 3. 应用程序要消息总线连接选项

不管消息总线是如何实现的、使用的通道类型以及消息传送模型，总线模型总是表现于这样的事实之上：一个应用程序发送的消息将很可靠的被传递给任何适当的目的地，而不管该目的地在哪或它是如何被实现的。消息的接收者可以与发送消息的应用程序同处于相同的机器上或完全不同的机器上。接收者可以使用相同或不同的部署技术或编程语言来实现。关键是，发送消息的应用程序可以确保消息将会被发送这个事实。可能不会立即传输，特别是在推动模型传输的情况下更是如此，但是消息将知道它该去向何处。

实现消息总线

确实有一些方法可以实现消息总线，并且也有许多设计的第三方工具使得实现它更容易了。例如，IBM? 提供了WebSphere? MQ 和 WebSphere Business Integration Message Broker 产品，他们都是基于 Java Messaging Service API 标准的。这些产品共同提供了健壮的、企业质量的消息总线架构，它们能满足大多数业务案例的需要。另外一个关键部分是一大部分工作已经进入了定义一套 Web 服务标准，该标准提供实现事件及基于通告的服务的模型。规范的 WS-Notification 系列为 Web 服务定义了全面的模型，可以利用该模型来实现消息总线样式服务（参见参考资料，规范的 WS-Notification 系列）。然而在本文中我将重点放在解释基本的设计模式是如何聚到一起的，所以我基本上使用开源的 JMS 实现：OpenJMS 以及 Java servlet 来创建我自己的实现，因此我们根本不用担心什么标准或产品。

这个实现由三个 JMS 主题组成（发布－订阅模型通道）：

?可以通过 Web 服务接口将消息推进消息总线中

?JMS Queue 通常通过 Web 服务接口实现响应消息的拖拽模型传输

?少数监听流程消息的组件被推进消息总线中。

图 4. 消息总线举例