JMS简明教程(PDF格式)-第5部分
按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
用不同的方式来实现与J2EE 平台的集成，以及支持EJB 的要求。
将来，JMS 集成到J2EE 平台的集成点将用J2EE 连接器架构来提供。
1。5 JMS1。1 的新特性是什么？
在 JMS 的以前版本中，用于点对点和Pub/Sub 域的客户端编程都是类似的，但使用不
同的类层次。在JMS1。1 中，现在有一个不依赖域的方式来编写客户端应用。这有以下几个
好处：
z 对于客户端程序员，简化了编程模型。
z 提供了在同一事务中使用队列（Queue ）和主题（topic ）的能力，现在可以在同一
个会话内创建它们。
z 对于JMS 提供商，通过线程池管理增加了优化实现的机会。
为使用这些优点，JMS 客户端开发者需要使用不依赖域的或“通用”的API 。将来，某
些域专有的API 可能被废弃。
在 JMS1。1 中，所有来自JMS1。0。2b 的类和方法仍然被保留以提供向后的兼容性。两种
消息域的语义也被保留；PTP 域和Pub/Sub 域的行为仍然是相同的，正如在第5 章“JMS 点
对点模型”和第6 章“JMS 发布/订阅模型”描述的一样。
为了详细的了解本规范的变更情况，参见第11 章“变更历史”。
2 架构
2。1 概述
本章描述基于消息的应用的环境和JMS 在环境中扮演的角色。
2。2 什么是JMS 应用
JMS 应用由以下部分组成：
z JMS 客户端——发送和接收消息的Java 语言程序。
z 非JMS 客户端——使用消息系统的本地客户端API 而不是JMS 的API ，如果应用先
于JMS ，那么它很可能既包含JMS 又包含非JMS 客户端。
z 消息——每个应用定义一系列的消息，这些消息用于在客户端之间交换信息。
z JMS 提供商——它是一个消息系统，它实现了JMS 以及其他的完整消息产品所需要
的管理和控制功能。
12 / 66
…………………………………………………………Page 13……………………………………………………………
z 被管理的对象——被管理的对象是预先配置好的 JMS 对象，它由管理员为客户端
使用而创建。
2。3 管理
期望 JMS 提供商和它们的后台消息技术有大的区别。也期望在如何安装和管理提供商
的系统也有大的区别。
如果 JMS 客户端是可移植的，那么他们必须与提供商专有的方面隔离开来。通过定义
JMS 被管理的对象来做到隔离，这些对象由提供商的管理员创建和客户化，接下来由客户端
使用。通过 JMS 接口来使用它们的客户端是可移植的。管理员使用提供商专有的工具来创
建它们。
有两种类型的JMS 被管理对象：
z ConnectionFactory——这个对象用于客户端来创建和提供商的连接。
z Destination——这个对象用于客户端来指定发送消息的目的地，也是接收消息的来
源。
被管理对象被管理员放置在JNDI 命名空间。JMS 客户端通常在它的文档中注上它要求
的JMS 被管理对象和这些对象的JNDI 名字应当如何提供给它。
图2�1 解释了JMS 管理如何工作。
图2�1 JMS 管理
2。4 两种消息风格
JMS 应用既可以使用PTP 风格又可以使用Pub/Sub 消息风格，在后面的章节中会有更详
细的描述。应用也可以将两种风格组合到一个应用中。消息的这两种风格常被称为消息域。
JMS 提供了这两种消息域，因为它们代表了两种通用的消息模型。
当使用JMS API 时，开发人员可以使用两种消息模型的接口和方法。当使用接口时，消
息系统的行为可能会稍有不同，因为两种消息域有不同的语义。这些语义的差别在第 5 章
“JMS 点对点模型”和第6 章“JMS 发布/订阅模型”中描述。
13 / 66
…………………………………………………………Page 14……………………………………………………………
2。5 JMS 接口
JMS 基于一系列通用的消息概念。每个JMS 消息域—PTP 和Pub/Sub—也为这些概念定
义了各自的接口集。
表2�1 PTP 和Pub/Sub 接口的关系
JMS 公共接口 PTP 专有接口 Pub/Sub 专有接口
ConnectionFactory QueueConnectionFactory TopicConnectionFactory
Connection QueueConnection TopicConnection
Destination Queue Topic
Session QueueSession TopicSession
MessageProducer QueueSender TopicPublisher
MessageConsumer QueueReceiver ， TopicConsumer
QueueBrowser
JMS 通用接口提供了一个独立于PTP 和Pub/Sub 消息域的域视图。鼓励JMS 客户端程序
员使用这些接口来创建他们的客户端程序。
下面列出了这些JMS 概念的简要定义。参见第4 章“JMS 通用工具”来详细了解这些
概念。
对于两种消息域的差别的详细内容，参见第5 章“JMS 点对点模型”和第6 章“JMS 发
布/订阅模型”。
z ConnectionFactory——客户端使用这个被管理对象来创建一个Connection 。
z Connection——一个到JMS 提高商的活动连接。
z Destination——封装了消息目的地标识的被管理对象。
z Session——一个用于发送和接收消息的单线程上下文。
z MessageProducer——一个由Session 创建用于往目的地发送消息的对象。
z MessageConsumer——一个由Session 创建用于接收发送到目的地的消息的对象。
图2�1 JMS 对象间关系概览
在这个文档中使用的术语“消费”是指通过JMS 客户端接收消息；也就是说，一个JMS
提供商已经收到一个消息并将它给了它的客户端。由于 JMS 支持同步和异步接收消息，因
14 / 66
…………………………………………………………Page 15……………………………………………………………
此术语“消费”在不需要区分它们的时候使用。
术语“生产”用作发送消息的最通用的术语。它指给予 JMS 提供商一个消息以转发到
一个目的地。
2。6 开发一个JMS 应用
广义的讲，一个JMS 应用是一个或多个交换消息的JMS 客户端。应用也涉及非JMS 客
户端；但是，这些非JMS 客户端使用JMS 提供商的本地API 而不是JMS 的API 。
一个JMS 应用可以被架构和部署为一个单元。在许多情况下，JMS 客户端是被逐渐增加
到线程的应用中的。
应用使用的消息定义可以来源于JMS ，或者他们可能已经由应用的非JMS 部分定义了。
2。6。1 开发一个JMS 客户端
典型的JMS 客户端执行下面的JMS 设置过程：
z 使用JNDI 来发现ConnectionFactory 对象。
z 使用JNDI 来发现一个或多个Desitination 对象。
z 使用ConnectionFactory 来创建一个具有消息转发约束的JMS Connection 。
z 使用Connection 来创建一个或多个JMS Session 。
z 使用Session 和Destination 来创建需要的MessageProducer 和MessageConsumer。
z 告诉Connection 开始转发消息。
此时，客户端有了生产和消费消息的基本的JMS 设置。
2。7 安全
JMS 没有提供控制或配置消息完整或消息私密的特性。
这期望由 JMS 提供商来提供。也期望由提供商专有的管理工具来配置这些服务。客户
端将得到正确的安全配置作为他们使用的被管理对象的一部分。
2。8 多线程
JMS 已经要求它的所有对象都支持并发誓要。由于支持并非访问通常会增加一些成本和
复杂性，所以 JMS 限制了那些很自然要被多线程客户端并发访问的对象的要求。其他的都
被设计成在一个时间只能被一个逻辑线程访问。
表2�2 支持并发使用的JMS 对象
JMS 对象 支持并非使用
Destination YES
ConnectionFactory YES
Connection YES
Session NO
MessageProducer NO
15 / 66
…………………………………………………………Page 16……………………………………………………………
MessageConsumer NO
JMS 定义了一些特殊的规则来限制Session 的并发使用。由于他们要求比在这里呈现的
更多的JMS 知识，所以他们将在后面描述。这里我们将描述他们必须遵守的基本原理。
有两个原因要限制并发访问Session 。第一个，Session 是支持事务的JMS 实体。实现多
线程的事务是非常困难的。第二，Session 支持异步的消费消息。重要的是JMS 不要求用于
消费异步消息的客户端代码有处理多个并发的消息的能力。另外，如果Session 被设置有多
个异步的消费者，那么不强迫客户端处理这些并发执行的分散的消费者。这些约束使得通常
的客户端更加容易地使用JMS 。更专业的客户端可以通过使用多个会话来获得他们期望的并
非性。
2。9 触发式客户端
某些客户端被设计成被周期性的唤醒来处理等待它们的消息。一个基于消息的应用触发
机制常和客户端的风格一起使用。触发器通常是等待消息的起点，等等。
JMS 没有提供触发客户端执行的机制。某些提供商可以通过它们的管理工具提供这样的
触发机制。
2。10 请求/ 回复
JMS 提供了 JMSReplyTo 消息头字段来指定回复的消息应当被发送到的目的地。回复的
JMSCorrelationID 头字段可以被用于引用原始的请求。参见 3。4 章节“消息头字段”了解详
细信息。
另外，JMS 提供了创建临时队列和主题的功能，它可以用作回复的唯一目的地。
企业消息产品支持许多请求/ 回复风格，从简单的“一个消息请求产生一个消息回复”
到“一个消息请求产生一串回复，回复消息来自多个应答者”。JMS 不仅架构了一个特定的
请求/ 回复抽象，而且提供了基本的工具，许多企业消息产品可以基于它来构建。
为了方便，JMS 为PTP 和Pub/Sub 域定义了请求/ 响应帮助类（这些类用JMS 实现），它
实现了请求/ 回复的基本形式。JMS 提供商和客户端可以提供更加专业的实现。
3 JMS 消息模型
3。1 背景
企业消息产品把消息看作是轻量级的实体，它由消息头和消息体组成。消息头包含了用
于消息路由和标识的字段；消息体包含了被发送的应用数据。
通常情况下，消息的定义随产品的不同有很大的差别。主要的差别是消息头的内容和语
义。某些产品使用自描述的规范的消息数据编码；其他的可能将数据认为是完全不透明的。
某些产品为能被用于标识和解释消息内容的消息描述提供了存储池；其他的就没有。
对JMS 来讲捕获偶尔冲突的消息模型组合的范围是非常困难的。
16 / 66
…………………………………………………………Page 17……………………………………………………………
3。2 目标
![[全息剑三]我大明教也有绿洲封面](http://www.8btxt.com/cover/noimg.jpg)
