运用JMS传递消息

有很多可选方法可以发送和确认接收消息，这就使开发人员可以灵活地在应用程序之间传递消息。
by Peter Varhol

企业中的消息传递（messaging）越来越被公认为是创建企业应用程序的重要工具，对于创建应用程序本身来说，它的重要性也许不太明显，但对于跨商业过程的应用和集成来说，其重要性就很大了。消息传递可以使我们在不能同步工作的应用程序或应用程序组件之间建立异步的通讯通道。建立这些类型的通道有什么好处呢？企业可以得到更多的信息，而不需要创建新的底层架构和定制新的企业应用程序。

对于初学者来说，他们会对消息本身产生一个疑问：什么是消息，它包括什么？消息是完全由商业过程的需要定义的，而不是由一个运算单位定义的。一个消息可以是任何不连续的消息片段。它可以包含一个文件、或其它格式化的文件、一个文本请求或响应、或一条执行一个特定动作的指令。

Java Messaging Service（JMS）不会改变消息内容。它只是确保数据传递的一种方式。这种功能使JMS在用途和对不同用途的响应方面非常灵活（见图1）。

图1. 确保消息的传递

Java 2 Platform、Enterprise Edition（J2EE）1.2提供了同步的消息传递，这就意味着，消息提供者和接收者在消息的内容和发送时间上必须达成一致。 从J2EE 1.3开始，Java就在其企业应用解决方案中集成了异步消息传递。JMS这个机制包括一个底层API用来访问企业消息传递系统。JMS支持消息队列和更现代的发布-订阅（publish-subscribe）消息传递方法。

企业中的用户不太可能通过直接运用JMS来传递消息。作为替代，集成软件供应商将在一个较大的架构中运用JMS，这个架构包括应用程序、服务器、和提供更全面和更高级解决方案的消息提供者。企业将在这些架构中运用JMS，它可以提供高级的开发工具和应用程序管理支持。

那些开发和宣传应用程序服务器（application server）的公司（IBM、BEA、Sun和Oracle）也都在专心研究运用JMS的消息传递技术，因为将JMS作为不同应用程序之间有效的通讯机制可能需要应用程序服务器的一些功能。特别的是，运用Enterprise Java Beans (EJBs) 的bean-driven的消息传递使应用程序服务器成为该结构中的一个主要部分了。随着消息传递成为应用程序之间通讯的可行的解决方案，JMS将成为应用程序服务器供应商的一个重要的考虑因素。

实际上，消息传递将更多地用来连接现有的应用程序和数据库，而不是用来连接新组件。消息传递，或者更明确的消息传递架构，在以前遗留的系统、数据仓库（data warehouse）、目的单一的应用程序、交易系统、甚至新的分布式应用程序之间提供了连接，但它是典型的应用程序部署后的整合，而不是企业应用程序和数据策略的一个计划了的部分（见工具条“JMS与Web Services的比较”）。

JMS与Web Services的比较 正如我们可能都知道的，Web services... 更多

下面是企业运用消息服务的方式：在大多数企业中，我们开发和部署应用程序是为了解决特定的商业进程问题。随着时间的推移，用户发现，如果可以得到更多的数据，这些应用程序就会提供更多的商业信息。如果这些应用程序是用J2EE编写的，那么JMS就是在给商业问题提供一个技术解决方案的同时，保持应用程序完整性的一个自然的选择了。即使一个或两个应用程序都是在以前遗留的平台上编写的，如果企业是在计划一个长期的Java策略，那么JMS仍然有意义。

供应商运用JMS
作为一种技术，消息传递已经出现好几年了。诸如IBM MQSeries（现在的WebSphere MQ）和Microsoft MSMQ这样的产品是基于交易的分布式应用程序的消息传递提供者。但是，大多数情况下，发送机制是由企业开发人员决定的。这些消息传递提供者在很大程度上是为另一个时代设计的，在这个时代中，一个交易客户端或终端必须从大的遗留系统或数据仓库发送和接收数据。

JMS下的架构有些不同。JMS的消息提供者组件是在应用程序服务器内部实现的。这么做有一定的概念上的意义，因为许多运用消息传递的应用程序也都在那个环境中运行。

然而，当消息传递所包含的应用程序是遗留的应用程序时，运用应用程序服务器就意味着，有些JMS功能不能用。相反，运用许多JMS解决方案中的专有功能就意味着，你被束缚到那个解决方案了，而没有了跨平台的可移植性。

BEA通过其标志性的WebLogic应用程序服务器来支持JMS。WebLogic JMS实现了几个JMS功能，包括一个可选的用来定义消息用户服务器管理池的JMS工具。目前，WebLogic下的JMS不是集群服务（clustered service），就是说，它不支持负载平衡（load balancing）或failover。

由于JMS不是个集群服务，所以所有的客户端都必须被配置，在一个集群的特殊成员上运用JMS的相同的实例。用户必须配置其中一个服务器，作为JMS提供者。这种配置就意味着，属性文件应该定义所有客户端用来访问JMS的connection factory，和JMS要用的连接池。总之，将消息提供者和使用者放在同一个服务器上可以增强应用程序的可靠性，因为如果服务器坏了，那么所有的消息就会丢失，每个人都必须从头开始。

IBM的WebSphere系列也通过其WebSphere MQ产品（在添加了JMS 消息传递支持功能后，从MQSeries产品线重新命名的）实现了一个JMS工具。在2002年，该公司增加了对Java的支持，包括发布-订阅消息，并改进了性能和可扩展性。

有些供应商，如Spiritsoft，已经又前进了一步了，它将JMS用做构建更广泛的应用程序集成架构的机制，企业开发人员可以用它来连接不同种类的企业系统。这些架构不需要包括应用程序服务器，但作为替代，它可以提供一个独立于平台的方式，用Java来连接企业中的Java和本地应用程序。SpiritSoft的SpiritWave架构声称可以连接所有遗留的面向消息传递的中间件系统，在各种遗留的应用环境中运用JMS。

几个供应商正将JMS整合到更全面的消息传递底层架构中。例如，Ashnasoft的AshnaMQ包括对JMS 1.1的支持，它可以用于实时Web、无线、Microsoft .Net和Java客户端。AshnaMQ的管理工具可以动态地创建连接和sessions，它拥有多个消息发送者、接收者和浏览器，来发送、接收和查看消息。

同样的，Sonic Software的SonicMQ可以从JMS、C、C++、COM和HTTP客户端访问到，并支持与应用程序服务器、其它消息传递系统、FTP和电子邮件的消息传递整合。Sonic的Dynamic Routing Architecture和集群技术可以为高级的可扩展性进行SonicMQ部署。

事实上，所有实现JMS的应用程序服务器供应商都至少提供了消息发送和处理功能。在许多情况下，供应商都扩展了消息确认或应用程序集群这些领域中的标准。从部分程度上来说，对供应产品的专有扩展代表JMS标准还不成熟。还有很多消息传递的方面JMS都没有考虑到，或者确认了这些方面但还没实现。

JMS的一个重要方面是可以控制谁接收了什么消息以及可以得到哪种消息发送保证，因为并不是所有的消息的创建都是平等的。在有些情况下，消息是否到达目的地不是特别重要。例如，如果一个消息包括给某人发送的一个天气预报，而由于这个人不在他或她的无线设备接收范围内，那么消息就不被认为是重要的。

另一方面，有时侯，接收并处理一个消息是绝对很重要的。在商务活动中，就有必要确定是否接收并处理了一个订单、信用确认或存货订购。有些情况下，在医疗保健、国防或太空探索中，如果出现故障，就会造成灾难性的后果。

图2. Point-to-point消息传递

JMS可以完成各种任务。当然需要进行权衡。要确认接收到消息、允许复制消息或实现一个定制的确认工具会需要更复杂的代码和更高的处理能力。然而，开发人员已习惯于进行这种权衡了，这种类型的功能可以使JMS用于很多不同的应用程序。

JMS给消息传递提供了两种方法：point-to-point和publish-subscribe。每种方法都可以用于各种不同情况。Point-to-point消息对于每个消息都有一个接收者。接收者可以不同，但是只有一个接收者来使用消息。这种方法可以用于独特的交易，如在线购买（见图2）。

图3. 订阅者

另一方面，publish-subscribe认为消息传递是针对多个订阅者的。这种方法可以使多个用户订阅一个特殊的消息并接收那个消息，而不管其它订阅者的数量是多少。消息在发送时，不是自动处理的；作为替代，你可以认为它被订阅者接收了（见 图3）。

Javax.jms包中的不同机制实现了这些方法。在两种情况下，起点都是Destination接口。Destination代表了一个消息传递通道，它是连接消息源和接收者的机制。对于point-to-point消息来说，接口Queue扩展了Destination。正如你所预料的，Queue将消息排列起来，按顺序一次使用一个。Queue也需要指定消息的接收者，一个消息只有一个接收者。

对于publish-subscribe消息来说，接口Topic扩展了Destination。Topic可以使多个订阅者接收到消息。接收者必须订阅，就是说，采取一些行动来确保他们在这些消息的接收者名单上。

从概念上讲，Destination不是个传递机制。它是一个有顺序的列表，就像Queue这个名字的含义一样。对于Queue接口来说，它就像一个队列数据结构，可以让接收者按顺序使用消息。Topic也像一个队列数据结构，不同的是，在所有的订阅者都接收到消息后，它才会从列表中去除。

消息提供者，通常是某种类型的应用程序，创建了消息并用Destination接口来放置它们等待发送。使用者，即消息接收者，读取到消息，在Queue接口情况下，将消息从列表中去除。从概念上说，这个过程很简单，只是将数据从一个应用程序传递到另一个应用程序。然而，细节并不是这么简单的。

打算将JMS用于应用程序的任何人都需要考虑消息传递、消息接收确认、组件故障和故障恢复方法。JMS提供了各种可选方法，需要我们进行权衡。Auto模式是确认接收的最简单的形式，可以自动确认消息。运用auto模式就为消息提供了一次性发送保证。列表1是运用autoacknowledgement接收JMS消息的一个例子。

作为对比，在dupicates okay模式中，尽管消息仍可以自动确认，但在确认响应时间上就没有保证了。当处理能力和带宽可以进行确认时，消息就得到了确认。当确认是必要的时，这种方法很有用，但处理进一步的消息就不能依赖它了。列表2说明的是运用duplicates okay方法的一个实现例子。

第三种方法是client模式，在这种模式下，没有自动确认。作为替代，接收者负责给发送者提供确认。这种方法可以调整确认，所以它最满足应用程序的需要。权衡点是，如果运用确认，确认必须在接收应用程序内实现，而不是用JMS提供的工具。代价是代码很复杂，而且手动实现也需要资源。

JMS供应商提供的其它类型的确认在很大程度上是这些选项的变异形式。其它方法不是JMS的确定部分，所以运用它们有利也有弊。它们可以给你提供更适合你的应用程序需求的选择方案，但是是以标准化和可移植性为代价的。

从应用程序的立场来看，消息传递机制也有几个可选方法。拥有多个可选方法是很重要的，因为应用程序可能不仅需要确保消息的接收，也要确保完成处理消息。如果在消息被处理完前，应用程序或其硬件发生故障，可能就需要另一个机制来重新发送消息。

一个交易式的session可以使一个应用程序通过创建一个本地交易来接收消息。在这种方式下，接收的应用程序通过其功能（如在适当的时候提交交易，或在出现问题时回滚交易）来控制消息的发送。

你也可以用message-driven beans来控制消息的处理，运用container或noncontainer方法。Container方法可以使bean container监控交易是否成功。运用这种方法，bean指定部署描述符中的container，container根据它对应用程序的确认，来确定是否提交交易或回滚交易。

作为选择，bean也可以在container不参与的情况下监控交易是否成功。在这种情况下，监控必须是手动实现的。我们通过代码来描述消息发送过程和交易是否提交或回滚。这种手动的方法再次以代码复杂性为代价提供了更高程度的灵活性。

JMS适合你的企业吗？
在运用JMS时你应该考虑的第一个方面是你的应用程序是否接受基于消息的通讯。如果你已经运用了一个队列结构，那么你就可以运用JMS了。如果不是，那就问问自己，你是否有单独的应用程序可以从交易中受益。你可能还没有运用消息传递，但你可以将它作为一个更长远的目标来简化商业进程或改进数据流。

一旦你确定了你的应用程序或进程可以利用JMS消息传递，那么你就需要确定你是否有底层架构支持它。该底层架构包括用于网络和应用程序服务器的硬件，以及对应用程序服务器的支持。同时，确定你对性能、消息传递、确认和故障的需求也是很重要的，而且要保证你选用的硬件和软件支持这些需求。

JMS可以用于任何企业的各种应用程序。通过仔细设计和实现消息传递，基于交易的过程可以被扩展和改进。JMS提供了基于Java的消息传递，它支持这些目标，同时运用了Java技术和现有的计划了的Java应用程序。它们的整合使JMS架构可以给应用集成项目提供实际的价值。

关于作者:
Peter Varhol是Compuware Corporation的一名技术传播者。他的联系方式是 peterv@mv.mv.com。