J2EE探索者 用JMS进行企业消息传递（2）实例

look_w

简单JMS客户机尽管JMS是与Java 2 Enterprise Edition一起发布的一种企业级的技术，您仍可以轻松地将一个标准Java客户机转换成一个支持JMS的应用。将企业消息传递功能添加到Javaapplet、命令行应用程序、Swing应用程序或者Java WebStart都非常简单。 您只需简单地将少量方法调用添加到J2SE应用代码中，然后将一个包含了JNDI（也是J2EE的一部分）的接口和实现类的JAR文件添加到类路径（classpath）中。如果您已经在客户机上装载了这个JAR文件，并且将它添加到了您的应用的类路径中，那么您就可以使用JNDI来访问JMS提供者（参见下面的                ，以获得关于JMS消息传递的更多信息的链接）。            
简单JMS 客户机的优点和缺点简单JMS 客户机方法有许多优点，最明显的优点就是它的简单性和普遍性。所有的J2SE应用都可以毫不费力地扩展为可以与一个JMS消息传递系统进行交互。此外，使用JMS的新应用部署起来只需对客户端进行少量的配置，甚至不需要配置。简单JMS客户机是对几乎任何Java体系结构的简单、灵活和轻量级的一个扩展。
从消极的方面来看，我们会遇到安全性、事务处理以及可伸缩性等问题。对于一个简单JMS客户机，您只能选择将安全性和事务处理外包给某个供应商，也就是说，这些问题将是以一种特定于供应商的方式来处理的。如果您的简单JMS客户机既要处理传进来的消息，又要发送消息，那么就会碰到可伸缩性问题。JMS没有能够一次处理多于一个传进来的请求的内建机制。为了支持并发请求，您需要扩展JMS客户机，使其产生多个线程，或者启动多个JVM实例，让这些线程或实例各自运行应用。此外，还需要将JMS提供者配置为在一些适当的目的地上可以有多个订阅者。这时，您（或者您的开发小组）就会质疑简单JMS客户机解决方案是否真的具有简单性。
会话bean与JMS将会话bean与JMS结合起来使用是一种可行的面向企业的解决方案。会话bean被设计用来履行对业务服务的请求。必须查询企业消息传递系统来履行这样的一个请求，就这一点来说，企业消息传递系统可以由一个会话bean透明地来访问。使用会话bean作为JMS客户机还允许将JMS通信合并到一个大型企业事务的上下文环境中。例如，可以建立一个J2EE事务来从一个JMS提供者那里获取一条消息，从该消息中提取数据，并尝试更新数据库。如果更新操作失败并且事务回滚（rollback），则再发送一条消息到一个单独的目的地上的JMS提供者那里，同时给出对事务失败的原因的描述。
企业JavaBeans 技术使用资源管理器连接工厂来访问额外容器（extra-container ）资源。这些资源是标准的企业组件，但不是J2EE容器的核心部分，它们包括数据源、JMS会话、JavaMail会话、URL连接以及Java连接器体系结构（Java Connector Architecture ，JCA）适配器。资源管理器是J2EE容器的一个组件，它管理着某一特定类型的资源的整个生命周期，这些资源包括连接池、事务支持以及实现实际连接所必需的任何网络协议。
企业bean通过三个步骤来获得一个JMS会话的连接：通过JNDI查找获得一个连接工厂引用，通过工厂引用获得一个连接，然后以一种常规的JMS的方式使用主题或者队列连接对象。因为JMS必须有遵从J2EE规范的应用服务器的支持，因此不再需要附加的库或者组件。
JMS会话bean 的优点和缺点将JMS和会话bean结合起来使用，这在企业功能性方面是一个进步，而在简单性和灵活性方面却又是一个退步。通过使用会话bean，应用开发者可以访问EJB容器所提供的整个范围的J2EE功能，包括JNDI、宣告式事务语义、自动并发支持、资源管理、宣告式安全性以及对诸如实体bean、数据源、JavaMail和JCA适配器之类的企业资源的访问。从消息传递的立场来看（跟MDB不一样），会话bean与JMS的联手并没有对您的bean所能访问的主题和队列强加任何数量上的限制。
作为增强企业特性的代价，您牺牲了简单性，客户机占用空间（client footprint）也不再像以前那么小了，而且也没有了异步性。前两项损失倒没什么好奇怪的，如果您已经关注探索者系列有一段时间了，那么您就更能理解这一点。会话bean要求有一个成熟的J2EE EJB容器，这让您的开发小组（针对EJB开发而言）和您的整个系统体系结构（针对客户机占用空间而言）背上了沉重的包袱。
异步性是使用像JMS这样的企业消息传递技术的主要优势之一，而且，在取得这一优势的同时它并没有失去什么。有了JMS，消息传递客户机可以通过提供者发送消息，消息发送出去之后便可以离线，而让提供者从容地传送这条消息。接收消息的客户机可以周期性地上线并检查新的消息，或者也可以设立一个侦听器组件，令其一直处于在线状态以等待来自提供者的消息。会话bean是同步的，因而不能支持“一直在线（always-on）”侦听器组件。与前一种客户机不同，同步的Java客户机必须调用一个会话bean方法。然后由该会话bean方法打开与一个消息传递提供者的连接，以便发送和接收消息。
消息驱动beanEJB 2.0 规范定义了一种新的企业bean，以期弥补其他四种类型的企业bean（两种会话bean和两种实体bean）的不足。这种新的bean就是消息驱动bean（message-drivenbean，MDB），人们期望用它来提供可重用的消息传递组件，以便利用已有的在J2EE应用服务器方面的投资，尤其是利用已有的EJB技术。
MDB 只能通过一条JMS消息异步地进行调用。因此，它并不具有其他bean所具有的本地和远程接口。相反，MDB实现两种特殊的接口：一个与EJB容器之间的接口（javax.ejb.MessageDrivenBean），以及一个消息传递接口（javax.jms.MessageListener）。作为一种成熟的JMS客户机，MDB通过一个MOM服务器既可以发送消息，又可以接收消息。作为一种企业bean，MDB由容器来管理，并且通过一个EJB部署描述符进行宣告式的配置。
MDB 的优点和缺点MDB允许开发者利用已有的在EJB技术方面的投资，但是仍然可以将这些投资整合到一个异步消息传递的上下文环境中。例如，JMS客户机可以发送一条消息给一个MDB（该MDB一直在线等待传进来的消息），而后者可以访问一个会话bean或者一些实体bean。通过这种方式，MDB可以被用作一种异步包装器，提供对业务流程的访问途径，而之前这些业务流程只能通过一个同步的RMI/IIOP调用来访问。
消息驱动bean本身也是一种强大的消息传递解决方案。由于MDB被专门设计用来作为消息的消费者，并且仍然是由EJB容器管理的，因此它们在可伸缩性方面提供了巨大的优势。由于消息bean是无状态的，并且由容器进行管理，因此它们并发地发送和接收消息（容器只是简单地将另一个bean从池中提出）。这一点，加上EJB应用服务器所固有的可伸缩性，构成了一种极其健壮的、可伸缩的企业消息传递解决方案。
另一方面，MDB相对来说还是一种很新鲜的事物，没有经过很多的检验。因而，并不是所有的J2EE供应商都支持它们，即使是支持MDB的那些供应商也只是最近才实现它们的。可以预见，MDB的不成熟意味着供应商实现在稳定性和可靠性方面还有一段很长的路要走。而且，MDB社区也需要经历更多的锤炼，以获得一套成形的使用MDB的最佳实践。
抛开MDB的相对不成熟性不提，理解它是为专门的目的而设计的（即作为JMS消息的消费者）十分重要。MDB只能通过JMS消息来调用，其他方式都不管用。这意味着它们作为消息的消费者非常理想，但未必适合作为消息的生产者。消息驱动bean当然可以发送消息，但前提是它首先要让一条传进来的请求调用它。而且，当前设计的MDB只能映射到单个的目的地。它们只能在那个目的地上侦听消息。这一限制在以后的版本中可以改变，但目前您只能为每个您想侦听的目的地定义一个MDB。
消息传递解决方案指导方针如前所述，选择适当的解决方案时，大部分要做的工作就是衡量您企业的特定需求，包括目前的需求和可预见的将来的需求。如果能记住多种企业消息传递解决方案可以结合使用，那么也会很有帮助。在下一节，我们将看一些常见的消息传递场景和每个场景潜在的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，并且给出了一些指导方针，以方便您选择最适合您企业的解决方案。