按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
端提供了关键的服务。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 �