消息传递解决方案指导方针

　　如前所述，选择适当的解决方案时，大部分要做的工作就是衡量您企业的特定需求，包括目前的需求和可预见的将来的需求。如果能记住多种企业消息传递解决方案可以结合使用，那么也会很有帮助。在下一节，我们将看一些常见的消息传递场景和每个场景潜在的JMS解决方案。当您为您的企业选择适当的消息传递技术，或者混合使用多种技术时，这些内容可以提供一般的指导方针。

　　从一个组件访问多个主题和队列

　　如果您的业务流程规定了消息目的地只能有条件地访问(换句话说，如果x<5，则访问主题A，如果x>5，则访问主题B)，那么您将不能使用MDB。不过，您可以使用一个简单JMS客户机，或者将会话bean与JMS结合起来使用。为了在这两种选择之间作出决定，您必须在简单JMS客户机的轻量级特性(特别适合于applet、Swing应用程序和独立的控制台应用程序)以及J2EE容器的健壮性(包括透明的事务性支持、宣告式安全性和其他EJB型资源管理功能)之间进行权衡。

　　异步地访问会话bean和实体bean

　　有两种方式来处理这一场景。比较明显的一种方式就是使用一个消息驱动bean，但前提是您的供应商支持MDB技术。MDB被设计用来 消费异步消息并代表消息发送方访问企业功能性。此外，应用服务器可以维护一个MDB的多个实例，来处理并发的服务请求。如果您不能使用MDB，您可以创建一个简单JMS客户机，以此来作为一个侦听器。当收到一条消息时，该客户机便可以与应用服务器建立一个同步的RMI连接，并按照常规的方式调用会话bean或者实体bean。不过，MDB是更值得推荐的解决方案。

　　构建尽可能瘦的JMS客户机

　　在这一方面，简单JMS客户机显然是赢家。如果对您来说更重要的是提供一个轻量级的消息传递客户机，而不是拥有像会话bean这样的J2EE客户机的可伸缩性和健壮性，那么简单JMS是正确的选择。无论是会话bean与JMS的组合，还是MDB，两者都需要一个J2EE应用服务器，这使得两种选择都不适合瘦客户机实现。

　　并发地发送和接收消息

　　这里惟一合适的选择是使用消息驱动bean。消息驱动bean是专门为这一场景量身定做的。从技术上讲，简单JMS客户机也可以利用多线程技术来提供类似的支持，但这种解决方案开发起来很复杂，并且最后开发出来的东西并没有很好的可伸缩性。

　　将消息传递合并到J2EE过程中

　　您或许已经在J2EE体系结构中有所投入，并且认识到将企业消息传递合并到这些J2EE过程中的需要。在大多数情况下，您最好的解决方案是将会话bean与JMS资源连接结合起来使用。您可以采用已有的会话bean来访问一个或多个主题和队列，而不必重建整个基础设施。这些会话bean将继续履行传统的对业务服务的请求，并且还担负起了消息传递的任务。在某些情况下，将您已有的业务服务暴露给一个JMS客户机是有好处的，这从前面的讨论中也可以发现。

　　结束语

　　就今天技术前景的多样性和日趋于异步的特点来说，消息传递是一种激动人心的、日益流行的解决方案。Java 消息服务提供了一种独立于 供应商和平台的媒介，通过使用企业消息传递将多个系统系在一起。在本文中，我们简要地浏览了企业消息传递和JMS，并且给出了一些指导方针，以方便您选择最适合您企业的解决方案。