最近几年，开发人员可以更广泛地得到企业消息排队（MQ）产品。适当地使 用 MQ 技术经常可以改善应用程序的组织、性能和可伸缩性。Java 消息服务 （Java Message Service (JMS)）是集成到 J2EE 中的一部分，它使得 MQ 服务 可以为任何 J2EE 应用程序所用。在本文（也是本专栏系列的第一部分）中， Brian 概述了在 Java 应用程序中使用消息排队的一些好处，并探讨了能够从 MQ 技术中获益最大的问题类型。请在 论坛上（或者通过单击本文顶部或底部的 讨论）同作者及其他读者分享您对本文的想法。
消息排队（MQ）工具没有数据库工具（例如关系（SQL）数据库）为人所知或 为人理解，数据库工具是几乎所有企业应用程序和大量比较简单的应用程序中的 关键组件。开发人员总是可以采用多种类型的数据产品，其范围包括从廉价的、 只能在台式机上使用的数据库（例如 dBase 或 Microsoft Access），到工作组 数据库服务器（例如 Sybase SQL/Anywhere），再到企业数据库服务器（例如 DB2 或 Oracle）。无论您的项目是什么样子的，总有一个价格、性能及功能都 适合的数据库产品可供您使用。
和数据库相似，MQ 产品有时被称为面向消息的中间件（MOM），已经出现相 当一段时间了。然而，直到最近，MQ 服务器还一直是昂贵的、只能被资金最充 足的企业开发人员所用的高端产品。结果，只有非常少的开发人员可以享受在其 应用程序中使用消息传递所带来的好处。
大众化的消息排队
幸运的是，这一状况正在开始改变；现在市场上已经出现了几种价格较低的 MQ 服务器。1997 年，Microsoft 发布了 MSMQ，它是一个事务性消息排队产品 ，作为 Windows NT Server 中的集成部分 ― 无需额外的许可费用。Sun 将 JMS API 包括在最初的 J2EE 规范中，这极大地促进了消息传递的大众化。在 J2EE 规范的版本 1.3 中，所有的 J2EE 容器都要求包含 JMS 提供程序 （provider）。
JMS，也就是 Java 消息服务，它是一种允许 Java 应用程序通过标准化的接 口访问范围广泛的 MQ 服务器（或者，按照 JMS 的说法，是提供程序）的 API ，就象 JDBC 允许程序通过一个公共接口访问许多不同的数据库服务器一样。大 多数 J2EE 容器包含 JMS 提供程序；将来，所有 J2EE 容器都将包含 JMS 提供 程序。没有 J2EE 容器也可以使用 JMS；市场上有几种独立的 JMS 提供程序实 现。此外，EJB 2.0 规范引入了一种新的 EJB 类型 ― 消息驱动 bean ― 它使 得创建利用实体和会话 bean 的消息驱动的组件非常容易。
既然我们都可以使用 JMS 服务，我们就应该学会在应用程序中使用消息传递 的能力。Willy Farrell 是 IBM 的一名电子商务设计师，他写了一本优秀的关 于使用 JMS 的介绍性教程（参阅 参考资料）。它涉及创建消息和队列的基本知 识，以及对消息划分优先级、检索消息和编码消息的所有选项。
消息传递和数据库起了相互补充的作用，在许多情况下，同时使用消息传递 和关系数据库可以产生比只使用它们中的一个好得多的解决方案。
历史上，曾经将 MQ 服务器用于面向事件的应用程序（例如财务服务应用程 序）或者作为一种与完全不同的系统进行相互操作的方式（例如连接完全不同的 数据库应用程序或将一个企业同另一个在供应链网络中的企业相连接）。术语“ 面向消息的中间件”经常应用于 MQ 服务器，它强调 MQ 技术主要用途是连接完 全不同的系统。然而，随着 MQ 产品成本的降低，许多其它应用程序现在也可以 从消息排队中获益。
MQ 服务器做什么？
用 MQ 的说法，消息只是一个字节流（这个字节流可以是一个 XML 文档、一 个序列化的 Java 对象、一个文本字符串或甚至是一条空消息）。对消息的解释 留给应用程序域来做；MQ 基础结构不对消息施加任何语义和结构限制。消息存 储在队列里，MQ 服务器允许您将消息加入到队列以及从队列中取走消息。
到目前为止，消息队列听起来很象简单的链表。从其最简单形式来说，的确 是这样的，但是企业 MQ 服务器通过将一些功能特性封装进这一链表管理而增强 了其功能：
控制谁可以向队列中写以及谁可以从队列中读的安全性
网络接口，它允许消息生产者和消费者位于不同的地方
事务性支持，这样入队和出队操作都具有事务特性：原子性、一致性、隔离 性以及可持久性
分布式事务支持，这样队列操作可以同其它资源管理器（如 SQL 数据库）一 起参加分布式事务
持久存储性
负载均衡
故障转移
管理