对于Java消息服务中常见问题的解答

核心提示：问. 什么是 java 消息服务？答: Java 消息服务(Java Message Service，JMS) API 是一个用于访问企业消息传递系统的 API，对于Java消息服务中常见问题的解答，是 Java 2 Platform, EnterPRise（J2EE）的一部分，Java 消息服务使得编写那些需要异步发

　　问. 什么是 java 消息服务？
　　
　　答: Java 消息服务(Java Message Service，JMS) API 是一个用于访问企业消息传递系统的 API。是 Java 2 Platform, EnterPRise（J2EE）的一部分。
　　
　　Java 消息服务使得编写那些需要异步发送及接收重要业务数据和事件的业务应用变得轻易。Java 消息服务定义了一个公共的企业消息传递 API，该 API 设计来被大范围的企业消息传递产品轻易而有效地支持。Java 消息服务不仅支持消息队列，还支持消息传递的发布/订阅模式。
　　
　　问. Java 消息服务是另一种邮件 API 吗？
　　
　　答: 不是。术语“消息传递”在计算机领域的定义很广。它被用来描述不同的操作系统概念，用于描述电子邮件和传真系统；假如使用了 JMS API，它被用来描述企业应用之间的异步通信。
　　
　　JMS 消息是指由企业应用（而不是人）消费的异步请求、报告或事件。它们包含了协同这些系统所需的重要信息，包含了描述特定业务活动的精确格式化的数据。通过这些消息的交换，每个应用可以跟踪企业的进展。
　　
　　问. Java 消息服务是一种产品吗？
　　
　　答: 不是，Java 消息服务是一个用于企业消息传递的公共 API 的规范,使用它需要一个由企业消息传递供给商提供的 JMS 提供者。
　　
　　问. 可从哪里获得 Java 消息服务规范？
　　
　　答: Java 消息服务 1.0.2 规范可从 http://java.sun.com/prodUCts/jms/docs.Html 处获得。在线的 JMS API 文档也可在这个链接地址中找到。
　　
　　问. Java 消息服务有何引人注目的？
　　
　　答: Java 消息服务引人注目的原因是：它是第一个得到广泛行业支持的企业消息传递 API。通过提供适应广泛企业消息传递系统的标准消息传递概念和约定，它简化了企业应用的开发。它利用现有的，经过企业验证的消息传递系统。
　　
　　问. 开发人员为何应该使用 Java 消息服务？
　　
　　答: 因为 Java 消息服务能使下面的工作变得简单：编写可移植的，基于消息的业务应用。通过加入新的能够与现有非 JMS 客户端完全协作的 JMS 客户端，以扩展现有的基于消息的应用。
　　
　　问. 为了学习使用 Java 消息服务，程序员需要具备什么？
　　
　　答: 基于消息的应用和基于远程过程调用的应用是根本不同的。一旦开发人员理解了如何最好地使用这两个技术, JMS API 就使得编写基于消息的应用跟学习几个附加接口一样轻易。
　　
　　问. Java 消息服务和企业 JavaBeans 组件有何关系？
　　
　　答: 自从 J2EE 1.2 版本发布以来，企业 JavaBeans 组件已经能够使用 JMS API 来同步地发送和接收企业消息。J2EE 1.3 版本现在已可获得，它提供了一种新的答应企业应用异步地接收消息的企业 Bean，即消息驱动 Bean。
　　
　　问. Java 消息服务 API 与 Java 命名和目录接口(JNDI) API 之间有何关系?
　　
　　答: 跟其他 Java 企业 API 一样，JMS API 使用 JNDI API 来进行治理。JMS API 将 ConnectionFactories 和 Destinations 定义为被治理对象，它们被配置并放入到 JNDI 命名的上下文中。然后 JMS 客户端查找和使用这些预先配置好的对象。这样保证了 JMS 应用易于部署和治理。
　　
　　问. Java 消息服务 API 与 Java 数据库连接（JDBC）API 之间有何关系？
　　
　　答: JMS 客户端或许也使用 JDBC API。在同一个事务中它们可能既使用 JMS API 也使用 JDBC API。大多数情况下，通过把这些客户端实现为企业 Bean，JMS 客户端可自动完成。JMS 客户端可能也使用 Java 事务 API。
　　
　　问. Java 消息服务与 Java 事务 API 及 Java 事务服务之间有何关系？
　　
　　答: Java 事务 API (Java Transaction API，JTA) 提供了一个用于划分分布式事务的客户端 API，以及一个用于访问资源以能够参与分布式事务的 API。JMS 客户端可能使用 JTA 来划分分布式事务。JMS 提供者通过 JTA 可以自如地支持分布式事务。
　　
　　Java 事务服务 (Java Transaction Service，JTS) 能和JMS API一道用来形成分布式的事务，该事务结合了消息收发与数据库更新以及其他 JTS 能识别的服务。当 JMS 客户端在应用服务器（比如 J2EE 服务器）中运行时，这些服务应该被自动处理；可是, 也有可能需要 JMS 客户端去明确编写它们。
　　
　　问. 在哪里可以找到 JMS API 讨论组？
　　
　　在 http://java.sun.com/j2ee/community/forums/index.html 处可找到一个 JMS API 论坛。要加入这个论坛，您必须是 Java Developer Connection 的成员。
　　
　　问. 为什么 JMS API 发展成为一种在企业内部组件间提供通信的技术，而不是用于在企业间通过 Internet 进行企业－企业（B2B）的通信？
　　
　　答: 提供基于 Internet 的 JMS API 消息传递的主要问题是，JMS API 供给商们必须使用一种共同的通信格式，并且 JMS 规范必须指定一个路由器－路由器 API。
　　
　　B2B 消息传递是一个重要的领域，有它自己独特的要求。该领域正被一些不断涌现的标准所占据，比如电子商务 xml计划，即 ebXML (参见 http://www.ebxml.org/),SUN 公司在这一方面起到了积极的作用。现在，ebXML 计划定义了一个消息传递服务，它支持通过Internet 的 XML 消息传递。
　　
　　当前的 ebXML 规范着重于，通过使用多种传输协议，比如 HTTP、mail 和 FTP，通过 Internet 提供终端间的点到点异步通信。ebXML 还计划提供发布/订阅式的 XML 消息传递。Sun 公司和它的合作伙伴正在定义一个新的 Java API for Messaging，即 JAXM (参见 JSR #000067, Java APIs for XML Messaging 1.0), 它支持 ebXML 消息服务规范。早先版本的 JAXM 可以从 Java Developer Connection 的 The M Project 1.0 Early access 处得到。
　　
　　总之, JMS API 是特意设计为在企业内部使用的，而独立企业之间通过 Internet 进行的 XML 消息传递将得到 ebXML 计划和新的支持不同 ebXML 规范的 Java API（包括 JAXM）的支持。
　　
　　技术问题
　　
　　问. JMS API 需要哪一种 JDK 版本？
　　
　　答: JMS API 需要 JDK/JRE 1.1.x 或者更高的版本。
　　
　　问. JMS API 是否提供了一个分布式 Java 事件模型的版本？
　　
　　答: 一般来讲，JMS API 可以被用作通知服务；但是，它没有定义 Java 事件的分布式版本。一个实现分布式 Java 事件的可选方案是作为 JavaBeans 组件，该组件通过 JMS API 透明地向事件产生 Bean 和事件监听 Bean 分布事件。
　　
　　问. 为什么有两个各自分开的 JMS API 域，即点到点和发布/订阅，而不合为一个域呢？
　　
　　答: 即使有许多类似之处,提供独立的域仍然很重要。这意味着厂商不必被强迫支持不属于他们的域内的设备，客户端代码也更加轻便灵活，因为产品更充分地支持一个域（相对于支持一个合并域中较少定义的子集而言）。
　　
　　问. 为什么 JMS API 不指定一套 JavaBeans 组件？
　　
　　答: JMS API 是一个低级的 API, 就像其他低级的 Java API 一样, 它无助于直接表现为 JavaBeans 组件。
　　
　　问. JMS API 如何与 CORBA 通知服务相结合？
　　
　　答: 通知服务为 CORBA 事件服务增加了过滤功能、传输保证语义、持久性连接和事件网络的集结。它从 CORBA 消息服务（该服务定义了异步 CORBA 方法调用）获得传输保证语义。
　　
　　Java 技术与 CORBA 很好的结合在一起。它提供了 Java IDL 和 COS Naming 技术。另外，OMG 最近定义了 RMI over IIOP。
　　
　　预计大多数 Java 对 IIOP 的使用将通过 RMI。预计大多数 Java 对 COS Naming 的使用将通过 JNDI API（Java 命名和目录服务）。JMS API 是 Java 特定的 API，它设计位于大范围现有和未来的面向消息中间件（Message Oriented Middleware，MOM）系统的上层（正如 JNDI API位于现有命名和目录服务的上层一样）。
　　
　　问. 为什么 JMS API 不提供端到端的同步消息传输和传输通知?
　　
　　答: 作为一个实现可靠应用的机制，一些消息传递系统提供到目的地的同步传输。一些系统为客户端提供了不同形式的传输通知，这样客户端就能检测出被删除或忽略的消息。这不是由 JMS API 定义的模型。
　　
　　JMS API 消息传递通过一次并且只有一次的 PERSISTENT 消息传输语义来提供有保障的传输。另外，消息消费者可以通过使用 CLIENT_ACKNOWLEDGE 模式或事务会话来确保可靠的消息处理。这样使用最小的同步实现了可靠的传输，这是大多数厂商和开发者都喜欢的企业消息传递模型。
　　
　　JMS API 没有定义系统消息（如传输通知）的模式。假如应用需要消息收到的确认回复，可以定义一个应用级的确认消息。
　　
　　这些问题放到发布/订阅应用的上下文中考察，将能更清楚地理解。在这个上下文中，同步传输和/或系统接收确认对于实现可靠的应用并不是一个有效的机制（因为，按照定义，生产者不会，也不想负责端到端的消息传输）。
　　
　　问. 为什么 JMS API 不提供群体发送(send-to-list)机制？
　　
　　答: 当前，JMS API 提供大量的消息传送选择；但是，消息在同一时刻只能发送到一个目的地。
　　
　　群体发送的好处是，程序员只需做很少的工作，并且还有 JMS 提供者对发送同样的消息到多个目的地的情况进行优化的潜力。
　　
　　群体发送机制不利的方面是，目的列表在效果上是由客户端实现并维护的集合。这将增加 JMS 客户端治理的复杂度。
　　
　　不使用提供群体发送机制的 JMS API，而推荐提供者支持配置代表一个群体的目的。这答应客户端通过一次发送便可以到达所有的消费者，同时保证群体被正确地治理。
　　
　　问. 为什么 JMS API 不提供订阅通知？假如发布者