jms应用程序_您是否应该在下一个企业应用程序中使用JMS？

消息队列（MQ）工具不像数据库工具（例如关系（SQL）数据库）那样广为人知或理解，它们是几乎所有企业应用程序和大量简单应用程序的关键组件。 开发人员始终可以访问各种数据库产品，从廉价的仅台式机数据库（例如dBase或Microsoft Access）到工作组数据库服务器（例如Sybase SQL / Anywhere），再到企业数据库服务器（例如DB2或Oracle。）无论您的项目是什么，都有一个包含价格，性能和所需功能的数据库产品。

像数据库一样，MQ产品（有时也称为面向消息的中间件（MOM））已经存在了一段时间。 但是，直到最近，MQ服务器还是昂贵的高端产品，仅提供给资金最雄厚的企业开发人员。 结果，越来越少的开发人员可以在其应用程序中使用消息传递。

群众信息排队

幸运的是，这种情况正在开始改变。 当今市场上有几种低成本的MQ服务器。 1997年，Microsoft发布了事务性消息队列产品MSMQ，将其作为Windows NT Server的集成部分-无需支付额外的许可费用。 Sun在最初的J2EE规范中包含JMS API时，极大地推动了消息传递。 在J2EE规范的1.3版中，所有J2EE容器都必须包含JMS提供程序。

JMS（Java消息服务）是一种API，它允许Java应用程序通过标准化接口访问广泛的MQ服务器（或者，按JMS的说法是提供者），就像JDBC允许程序通过通用接口访问许多不同的数据库服务器一样接口。 大多数J2EE容器都包含一个JMS提供程序。 将来，所有J2EE容器都会使用。 也可以在没有J2EE容器的情况下使用JMS。 市场上有几种独立的JMS提供程序实现。 另外，EJB 2.0规范引入了一种新型的EJB（消息驱动的Bean），这使得创建使用实体和会话Bean的消息驱动的组件非常容易。

现在我们都可以使用JMS服务，我们应该学习在应用程序中利用消息传递的优势。 IBM的电子商务架构师Willy Farrell撰写了关于使用JMS的出色的入门教程（请参阅参考资料 ）。 它涵盖了创建消息和队列的基础，以及用于对消息进行优先级排序，检索和编码的所有选项。

消息传递和数据库提供了互补的优势，并且在许多情况下，将消息传递和关系数据库一起使用可以提供一种解决方案，该解决方案要比单独使用两者都要好得多。

从历史上看，MQ服务器已用于面向事件的应用程序中，例如金融服务应用程序，或作为接口异构系统的手段（例如，连接异构数据库应用程序或将一个企业连接到供应链网络中的另一家企业。）面向消息的中间件”通常应用于MQ服务器，并强调了这样一种观念，即MQ技术的主要用途是连接不同的系统。 但是，随着MQ产品成本的降低，许多其他应用程序现在可以从消息排队中受益。

MQ服务器做什么？

用MQ的话来说，消息只是字节流（可以是XML文档，序列化的Java对象，文本字符串，甚至是空消息）。 消息的解释权留给应用程序域。 MQ基础结构不对消息强加任何语义或结构。 消息存储在队列中，并且MQ服务器允许您将消息排队到队列中，以及从队列中取出消息。

到目前为止，消息队列听起来很像一个简单的链接列表。 最简单的形式就是它，但是企业MQ服务器通过将链接列表管理包装为许多功能来增强功能：

• 控制谁可以写入队列或从队列读取数据的安全性
• 网络接口，允许消息生产者和使用者位于不同的位置
• 事务支持，因此入队和出队操作表现出原子性，一致性，隔离性和持久性的事务特性
• 分布式事务支持，因此队列操作可以与其他资源管理器（例如SQL数据库）一起参与分布式事务
• 坚持不懈
• 负载均衡
• 故障转移
• 管理

MQ的优势

MQ的优势源自消息处理的异步性质所提供的固有的松散耦合 。 一个实体将消息发布到队列中以及删除消息并由另一个实体处理消息的过程是完全分开的。 这两个实体不必同时运行，不必位于同一系统上，甚至不必知道对方的身份。 他们每个人仅按照自己的时间表与队列互动。 他们只需要就彼此接受的消息形式达成共识； 否则，他们不必了解彼此。

松耦合具有许多优点。 它提供了一种自然的机制，可将工作单元划分为较小的独立组件，从而在处理请求的各个阶段之间隐式创建抽象。 通过这种细分，我们可以轻松地将每个组件的实现彼此抽象，更好地衡量和管理每个组件的资源利用率，或者将一个组件替换为具有类似功能的另一个组件，而不必更改其他组件。

JMS规范要求JMS提供程序还必须实现发布和订阅功能，这些功能允许您创建不同的，应用程序定义的称为主题的通道，并允许各个实体订阅主题。 排队到主题的消息将自动放置在已订阅该主题的任何实体的专用队列上。 主题在金融服务或新闻发布应用程序中执行有价值的排序功能。 例如，虽然在美国主要交易所交易的股票超过5000只，但每个投资者可能只对30只股票感兴趣。因此，您可以为每个股票代码创建一个主题，让用户订阅他们感兴趣的股票代码，然后让MQ引擎仅显示每个投资者想要的报价，从而避免了重复报价的传递。 使用SQL数据库很难实现此过程。

经典MQ使用模式

有许多常见的使用模式非常适合使用消息队列。 当您在应用程序中看到其中之一时，应该考虑使用消息传递。

面向事件的应用

高度面向事件的应用程序非常适合使用MQ技术。 其中包括金融服务应用程序（想想显示股票价格更新的交易站，根据价格变化或其他订单的执行情况启动交易，报告订单状态等），新闻专线服务应用程序，以及供应链应用程序。 在金融市场中，必须Swift采取措施。 您想在重要事件发生时尽快得到通知。

轮询数据库

数据库非常适合持久存储数据，但是存储临时数据并在数据更改时通知我们并不是他们的强项。

尽管效率低下，但轮询数据库却极为普遍。 每个机场的显示监视器都在不断轮询数据库以更新它们所显示的信息。 具有许多柜员窗口的银行通常使用电子标志来指示下一个免费柜员的位置。 电子商务站点内的订单处理系统可能会轮询数据库，以查看是否需要处理任何新订单。 或者，保险理赔工作流系统可能会轮询以查看是否有任何新的理赔可以分配给可用的理赔员。

所有这些轮询都需要大量额外的工作。 如果有许多实体频繁轮询（并且如果他们想要快速反映数据中的更新，则必须这样做），这可能会给数据库服务器和网络造成很大的负担。 在大多数情况下，轮询不会返回任何数据，或更糟的是，我们不会看到已经被发现并且必须再次处理或标识为已被处理的数据。

数据库根本不是为轮询或事件而设计的。 如果必须在事件发生或数据更改后相对Swift地采取措施，那么到目前为止，异步消息传递是一种更轻松，更有效的方法。 每当发现自己轮询数据库以获取更新时，请考虑使用JMS。

工作流程

根据工作流门户网站（由工作流管理联盟和工作流与再造国际协会的共同努力），工作流是“ ...业务流程的全部或部分自动化，在此过程中传递文档，信息或任务根据一系列程序规则从一个参与者到另一个参与者采取行动。” 工作流应用程序（例如文档路由和批准，保险索赔处理等）特别适合MQ解决方案，因为MQ技术紧密地模拟了如何在纸质办公室中解决工作流问题，每个参与者都有一个收件箱和一个发件箱。

工作流应用程序的特征是具有许多代理（代理可以是人类，自动处理步骤，甚至是物理设备，例如机器或打印机），它们各自执行一小部分任务，然后将其传递给业务规则确定的下一个代理。 考虑批准和支付电子费用报告的过程。 员工创建并提交报告，然后该报告需要得到员工经理的批准（如果美元金额超过某个阈值，则可能需要另一级管理层批准）。 然后转到HR，在此将对其进行准确性检查和审查，以确保这些费用是有效的业务费用并符合公司的政策。 如果批准，将创建付款请求，并安排支票打印。 此后，它可以转到会计中，在此将各个费用应用于适当的帐户和成本中心。 在这些阶段的每个阶段，费用报告都可以退回给员工或员工的经理。

在构建工作流应用程序时，主要的设计目标是确保从一个代理到另一个代理的工作Swift完成，并确保任务不会落空。 MQ服务器与数据库紧密结合，可以轻松地在您的应用程序中构建灵活，可扩展和可扩展的工作流处理。

使用MQ摆脱关键路径的风险操作

尽管大多数步骤涉及电子参与者而不是人工参与者，但在电子商务或供应链应用程序中接受，批准和填写订单的过程与工作流应用程序有很多共同点。 订单的接受和履行可能包括以下一些或全部步骤：

• 接受订单并将其存储在数据库中。
• 对于消费客户，请验证信用卡。
• 对于商业客户，请通过信用报告机构或公司的信用部门检查客户的信用。
• 执行一些欺诈检查分析。
• 检查库存。
• 如果有多个履行中心，请决定哪个中心将执行订单。
• 发送确认电子邮件给客户。
• 发送通知给客户的销售代表。
• 生成拣配清单并将其路由到履行中心。
• 运送订单。
• 向客户收费或向客户收费。

您不希望客户在单击“购买”以获取其确认号和收据后必须等待很长的时间，因此，由于提交订单而执行的任何代码路径都应简短且可预测的执行时间。 但是，这些步骤中的许多步骤都涉及访问在客户下订单时可能会或可能无法使用的资源，或者其响应时间可能无法预测的资源。 在这种情况下，应将它们从关键路径上移开； 让订单的启动使事件链运动，但通过使提交步骤做最小的事情来启动订单，使用户尽可能快地退出循环。 除了为客户提供更好的用户体验外，将订单处理分为多个离散（且更短）的步骤可以提高资源利用率并减少争用，这意味着交易更短（因此锁将更早释放）和所使用的资源第一步（例如网络或数据库连接）被提前释放。

订单处理中最不可预测的步骤之一是发送确认电子邮件。 邮件服务器通常很拥挤，可能需要很长时间才能接受邮件，或者可能会完全拒绝连接。 如果客户的邮件服务器拒绝确认消息，则要稍后重试。 这样，发送确认电子邮件是“危险的”，因为它可能不会第一次成功或可能需要很长时间才能处理，并且您不希望吸引客户（或者其他任何原因）等待直到发送确认。 同样，库存可能存储在与订单处理不同的数据库中（库存数据库甚至可能由外包的履行服务拥有），并且在下订单时可能不可用。 否则信贷部门可能在星期五休息。

通过使用消息队列存储挂起的确认电子邮件，库存检查或信用检查，您可以将“风险”操作与其余过程分开，从而使其余过程免受操作失败的风险的影响。或花很长时间。 由于每个处理步骤仅执行一个简单的任务，因此这也往往会大大简化每个任务的错误处理。

结论

如果正确应用消息队列（MQ）技术，则可以通过将任务分解为简单的子任务来大大简化复杂任务的处理，并可以提高应用程序的灵活性和可伸缩性。 从J2EE 1.3版开始，每个J2EE容器都将包含一个JMS提供程序，这意味着我们所有人都将能够利用应用程序中异步消息队列的功能。

下个月，我们将探讨Java事务处理服务（JTS）的工作原理。 尽管它比EJB或J2EE的其他元素受到的关注要少得多，但JTS也许是J2EE的最关键部分-事务使我们能够构建可靠的分布式应用程序。 我们将在以后的专栏中再次访问MQ，并构建一个工作流应用程序，以演示消息队列和关系数据库如何提供互补的优势。

---

翻译自: https://www.ibm.com/developerworks/java/library/j-jtp0205/index.html