EJB 2.0规范对这个潜在的瓶颈进行了关注处理,引进了消息驱动bean。消息驱动bean的运作是异步的,一旦接收到信息,bean就相应地对其进行处理,客户机程序并不等待响应而且bean也不会发送响应。
可以在这里下载这篇文章的代码。
要完全地理解消息驱动bean的理念,开发者需要对JMS如何工作有所了解。本质上讲,JMS消息服务器为消息递送提供了两个选择:消息主题和消息队列。主体担任下标的角色,消息客户机程序只接收与特定主题相对应的消息。在较低识别力的队列上的消息客户机程序接收所有列入队列中的消息。一个在消息服务器上注册的应用程序来监听消息,当监听程序得到来自服务器的消息时,就会对信息进行处理。
除了EJB context的增加内容,消息驱动bean以相同的方式运作。由于有 javax.ejb.MessageDrivenBean 界面,他应用了所有的消息驱动bean,扩展了javax.jms.MessageListener类,这就消除了开发JMS的复杂性,同时也向JMS服务器压缩了消息应用程序开发连接,消息回复等方面中更加困难的内容。这就使得开发者可以更加地关注于功能性问题而不是应用细节。
与无声明的 Session beans相似,消息驱动bean缺少对应用程序的声明的支持。当一个消息驱动bean处理预期的信息,EJB容器将其返回到可用的实例池之中,并等待下一个消息。不像其他类型的bean那样,消息驱动bean不需要一个home或是远程的界面,这是由于他们仅仅是监听消息而不是响应来自客户机程序的直接调用。
消息驱动bean是异步的,他在向调用的客户机程序返回响应时并不消耗处理时间,消息驱动bean附加的帮助显示了他在自动消息递送方面的理念。想象一下最坏的情景:一个Session bean在JMS客户机程序向JMS服务器贴出一个消息时加倍,JMS服务器返回一个“消息贴出”的响应,而EJB容器则崩溃。JMS服务器将保留贴出的消息直到消息监听器(在这里是一个消息驱动bean)恢复了信息。当EJB容器重起后,消息驱动bean从JMS服务器获得消息并象容器未发生崩溃时一样对消息进行处理。当然,这是要在JMS服务器没有崩溃的前提之下的,这在另一篇文章中会提到。
由于异步行为支持着消息驱动bean的操作,他们对于驱动其他bean的函数功能方面是很理想的。消息驱动bean接收到一个消息后即调用其他的EJB来对其进行处理。这样,消息的起始者(客户机程序)并不需要等待来自众多beans的每一个响应。这要求编码的紧密性来保证消息妥当地被传递和处理,同时加速应用程序的整体处理时间。