友情提示：如果本网页打开太慢或显示不完整，请尝试鼠标右键“刷新”本网页！
JMS简明教程(PDF格式)-第4部分
快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部! 如果本书没有阅读完，想下次继续接着阅读，可使用上方 "收藏到我的浏览器" 功能 和 "加入书签" 功能！
可以从任何客户端接收消息。每个客户端连接到提供创建、发送和接受消息的消息代理。
每个系统都提供了定位消息的方式。每个系统都提供了创建消息并给他填充数据的途径。
有些系统可以想多个目的地广播消息。其他的系统也可以只支持向一个目的地发送消息。
某些系统提供了异步接收消息的功能（当消息到达时被转发到客户端）。其他的系统可
以支持同步接收（客户端必须请求每个消息）。
每个消息系统通常提供多种服务供不同的消息来选择。重要的问题是系统能保证转发的
长度是多少。它们可能不是一次就能转发完全的。其他重要的问题是消息是有时效、有优先
级和是否要求响应。
8 / 66
…………………………………………………………Page 9……………………………………………………………
1。2。3 JMS 目标
如果 JMS 提供了现有消息系统的所有特性，那么对用户来讲它就太复杂了。在另一个
方面，JMS 更多是所有消息产品公共特性的交集。重要的是JMS 要包含实现专业企业应用需
要的功能。
JMS 定义了一系列通用的企业消息概念和工具。它试图最小化 Java 语言程序员使用企
业消息产品而必须了解的概念集。它致力于最大化消息应用的可移植性。
1。2。3。1 JMS 提供商
正如前面提到的，JMS 提供商是一个在消息产品实现JMS 的实体。
理想情况下，JMS 提供商用纯Java 来实现消息产品，这样它就能运行在applet 中，简
化安装，并且可以架构和OS 工作。
JMS 的一个重要目标是最小化实现一个提供商所需要的工作。
1。2。3。2 JMS 消息
JMS 定义了一系列消息接口。
客户端使用由JMS 提供商提供的消息实现。
JMS 的一个主要目标是客户端使用统一的API 来创建和与独立于JMS 提供商的消息一起
工作。
1。2。3。3 JMS 域
消息产品可以广义上可以分为点对点或发布┒┰南低场！ �
点对点（PTP）产品围绕着消息队列创建。每个消息被放置在一个特定的队列中；客户
端从队列中取出消息。
发布和订阅（Pub/Sub）客户端将消息放置到某个内容继承层次上的节点上。发布者和
订阅者通常都是匿名的，通常可以动态的发布或订阅内容层级。系统关注将来自一个节点的
多个发布者的消息分发到这个节点的多个订阅者。
JMS 提供了一系列的接口来让客户端在两种域下发送和接收消息，同时支持每个域的语
义。JMS 也为每个域提供了相应的客户端接口。JMS1。1 规范以前的版本，只有对应于每个域
的客户端接口。这些接口继续被支持以提高向后的兼容性。实现客户端的最好方式是使用不
依赖域的接口。这些接口称为“通用接口”是域特有接口的父类。
1。2。3。4 可移植性
最主要的可移植目标是新的只有JMS 的应用可以在同一个消息域内可以跨产品。
另外，JMS 客户端跨机器架构和操作系统是期望的可移植性（当时有同一个JMS 提供商
时）。
9 / 66
…………………………………………………………Page 10……………………………………………………………
尽管设计 JMS 的目的是让客户端可以和现存的在混合语言应用中使用的消息格式一起
工作，但是这种客户端通常是不可移植的（将一个混合语言应用从一个产品移植到另一个产
品超出了JMS 的范围）。
1。2。4 JMS 不包含什么
JMS 没有包含下列功能：
z 负载均衡/容错（Load Balancing/Fault Tolerance ）——许多产品为对多个协同的客户
端提供了关键的服务。JMS API 没有指定这种客户端协同如何作为一个单独的统一
的服务出现。
z 错误/劝告通知（Error/Advisory Notification）——多数消息产品定义系统消息来向
客户端提供问题或系统事件的异步通知。JMS 没有试图标准化这些消息。通过遵循
由JMS 定义的指南，客户端可以避开这些消息，这样就可以防止由于使用这些消
息而引入的可移植性问题。
z 管理——JMS 没有定义管理消息产品的API 。
z 安全——JMS 没有定义用于控制消息私密性和完整性的API 。它也没有指定数字签
名或密钥如何被分发到客户端。安全是由 JMS 提供商要考虑的问题——由管理员
配置这些特有的特性，而不是由客户端使用JMS API 来控制。
z 通讯协议（Wire Protocal）——JMS 没有定义消息的通讯协议。
z 消息类型存储池——JMS 没有定义存储消息类型定义的存储池，也没有定义创建消
息类型定义的语言。
1。3 JMS 的要求是什么
在这个规范内讨论的功能都是对JMS 提供商的要求，除非它被显式的指出。
JMS 点对点功能的提供商不要求提供发布/订阅功能，反之亦然。
JMS 也可以用在J2EE 平台。参加章节1。4 ，“与其他Java API 的关系”来了解当JMS 被
集成到那种软件环境时对JMS 的附加要求。
1。4 与其他Java API 的关系
1。4。1 JDBC 软件
JMS 客户端也可以使用JDBC API 。他们可能希望在同一个事务内使用JDBC API 和JMS API 。
大多数情况下，通过将这些客户端实现为EJB 组件可以自动实现这个愿望。也可能直接使用
JTA 来实现这个愿望。
1。4。2 JavaBean 组件
JavaBean 组件可以使用JMS 会话来发送/接收消息。JMS 本身是一个API ，它定义的接口
没有打算直接作为JavaBean 组件来使用。
10 / 66
…………………………………………………………Page 11……………………………………………………………
1。4。3 EJB 组件模型
JMS API 是EJB 组件开发者可以获得的重要资源。它可以和类似JDBC 的资源一起使用来
实现企业服务。
EJB2。0 规范定义了通过来自EJB 客户端调用的方法被同步调用的bean。也定义了一种异
步bean，当一个JMS 客户端向他发送消息时它被调用，称为消息驱动bean。EJB 规范支持
同步和异步消息消费。另外，EJB2。0 指定JMS API 如何参与bean 管理的或容器管理的事务。
EJB2。0 规范限制了当实现EJB 客户端时如何使用JMS 接口。参考EJB2。0 规范来了解更详细的
内容。
1。4。4 Java 事务API （JTA ）
Javax。transaction 包为划分分布式事务提供了客户端API ，并提供了获取要参与到分布式
事务中的资源的API 。
JMS 客户端可以使用JTA 来划分分布式事务；但是，这是运行客户端的事务环境的功能。
不是JMS 的功能。
JMS 提供商可以通过JTA 支持分布式事务，也可以不支持。
1。4。5 Java 事务服务（JTS ）
JMS 可以和JTS 联合使用来组成分布式事务，这个分布式事务将消息的发送和接收与数
据更新及其他JTS 感知的服务结合起来。当JMS 客户端在应用服务器中（如EJB 服务器）被
运行时，分布式事务应当被自动处理；但是对JMS 客户端来说，显式的通过程序使用JTS 也
是可能的。
1。4。6 Java 命名和目录接口API （JNDI ）
JMS 客户端使用JNDI API 查找已配置的JMS 对象。JMS 管理员使用提供商提供的工具来
创建和配置这些对象。
通过将特定提供商的工作代理给管理员最大化了客户端的可移植性。它也导致了更多的
可管理应用，因为客户端不需要将管理用的值嵌入到他们的代码中。
1。4。7 J2EE 平台
J2EE 平台规范（版本1。3）要求将JMS API 作为J2EE 平台的一部分。J2EE 平台规范对JMS
的实现提出了附加的要求，这些要求超出了 JMS 规范中描述的要求，包括既要支持点对点
域又要支持发布/订阅域。
11 / 66
…………………………………………………………Page 12……………………………………………………………
1。4。8 JMS 和EJB 组件的集成
J2EE 平台和 EJB 规范描述了要集成到J2EE 平台的JMS 提供商实现的附加要求。一个关
键的需求集是JMS 消息生产和JMS 消息消费如何与容器管理事务的事务需求进行交互。参
考这两个规范来来了解JMS 集成的所有要求。
JMS API 规范没有说明实现这些集成要求的模型。因此，不同的JMS 提供商实现可以使
用不同的方式来实现与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
Mes
快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部!
温馨提示： 温看小说的同时发表评论，说出自己的看法和其它小伙伴们分享也不错哦！发表书评还可以获得积分和经验奖励，认真写原创书评 被采纳为精评可以获得大量金币、积分和经验奖励哦！