Java理论与实践: 应该在下一个企业应用程序中使用JMS吗？
需积分: 0 30 浏览量
2020-03-04
12:27:52
上传
评论
收藏 49KB DOC 举报
Java 理论与实践: 应该在下一个企业应用程序中使用 JMS 吗？
学习消息排队是如何能够改进企业应用程序的灵活性和可伸缩性的
欢迎来到 Java 理论与实践专栏，这是由经验丰富的 Java 开发人员 Brian Goetz 撰写的一个
新的专栏月刊。本专栏旨在探索设计原则如何满足解决实际问题的需求这一难以捉摸的结
合点。每个月我们都将探索设计模式、可靠软件设计的原则以及为什么“最佳实践”是最好
的，同时也关注如何将它们应用于实际问题。这个月，Brian 讨论企业消息排队技术。
最近几年，开发人员可以更广泛地得到企业消息排队（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 服务器用于面向事件的应用程序（例如财务服务应用程序）或者作为
评论0
最新资源