Message-driven Bean是EJB2.0 规范中提出的的Enterprise Bean。

Message-driven Bean 的产生原因

效率原因

在JavaEE™平台中，客户端对Session Bean 和Entity Bean 的方法调用通过RMI或RMI-IIOP协议进行，这是传统的通过网络进行远程调用的方法，当调用请求通过网络传播到容器，容器则将客户端请求变成一序列的方法调用依次进行。客户端只有在容器处理完请求并返回结果后方可继续进行。

可靠性的原因

当客户端对Session Bean或Entity Bean进行调用时，必须保证服务器容器处于运行状态，如容器或网络出现错误，客户端调用将无法进行。

事件的广播

传统的RMI 或RMI-IIOP机制中，客户端在某一时刻只能与某一具体的服务器通讯， 没有任何内置的机制来将事件广播到多个服务器。

Message-driven Bean作为远程方法调用的一种替代方法，在客户端和服务器的直接方法调用之间放置了一个中间层，接收一个或多个客户端的消息，并将消息转发给一个或多个消息的使用者(Message Consumer)。

通过消息机制而非直接的方法调用，客户端可以继续执行而不必等待服务器的运行结果，服务器可以选择在方法调用完成后通知客户，而消息机制本身保证了信息传输的可靠性，同时使用消息域(Message Domain)中的消息类型模型以达到事件广播的机制。

但是，对Message-Driven Bean 的使用也有一定的限制，如不适用于依赖于方法调用、要求具有明确的返回值才能继续的客户端程序。另外，如果在一个应用中过多的使用了Message-Driven Bean， 对应用的执行效率将会产生影响，所以不适用于对时间因素敏感的客户端程序(如在下午两点定购下午四点的机票，而在四点后才得到订购是否成功的结果，这时结果已毫无用处)。

Message-driven Bean 作为一般的JMS 使用者(consumer)

作为一种具有JMS使用者(consumer)功能的Enterprise Bean组件模型，Message-Driven Bean由EJB容器进行管理，具有一般的JMS使用者(consumer)所不具有的优点，如对于一个Message-driven Bean，容器可创建多个实例来处理大量的并发消息，而一般的JMS使用者 (consumer)开发时则必须对此进行处理才能获得类似的功能。同时Message-Driven Bean可取得EJB所能获得的标准服务，如容器管理事务等服务。

由于与Message-driven Bean相关的主题(Topic)或队列(Queue)可以在部署时配置，因此，Message-driven Bean具有更多的灵活性。

但注意，一个Message-driven Bean在部署时只可与一个具体的主题(Topic)或队列(Queue) 建立关联。如有多个主题(Topic)或队列（Queue）需要与一个Message-driven Bean关联，则 可以在部署时部署多个Message-driven Bean类,或使用一般的JMS使用者(consumer) 。

Message-driven Bean 与其他Enterprise Bean

作为Enterprise Bean组件模型之一，Message-driven Bean，具有一些与Session Bean 和Entity Bean相同的方法，但由于Message-driven Bean本身不处理客户端调用，也无会话状态，客户只能通过向与Message Driven Bean关联的队列或主题发送消息从而与Message-driven Bean 进行交互，因此，Message-driven Bean 与Session Bean 和Entity Bean之间最大的不同之处在于Message-Driven Bean不具有组件接口及Home接口。

另外，Message-driven Bean异步地处理队列（Queue）或主题(Topic)中的消息，而非方法调用。

Message-driven Bean

Message-driven Bean是JMS消息驱动的JavaEE™平台服务器端组件，具备无状态、支持事务的特点。当从JMS队列（Queue）或主题（Topic）中接收到JMS消息后，由容器对组件进行调用。一般，可理解为消息的监听器（Listener）及接收者（Consumer）。

Message-driven Bean组件对于客户端是不可见的。客户端如希望调用封装在组件中的业务逻辑，只能通过向组件监听的JMS队列（Queue）或主题（Topic）发送消息，然后容器以事件的形式向组件实例发送消息，组件实例根据消息的内容调用相应的业务逻辑或其他组件。

因此，任何向组件监听的特定JMS队列（Queue）或主题（Topic）发送JMS消息的客户端，即可视为Message-driven Bean的客户端。

Message-driven Bean组件模型不具备会话状态，也就是说，当组件实例在没有对客户端的JMS消息提供处理的时候，所有的实例间没有差别。

Message-driven Bean的运行和客户端的运行是异步的。同时，对于客户端不可见。其实例由容器创建，其生存周期由容器控制。

Message-driven Bean与EJB容器、客户端、消息系统

下图是EJB容器、客户端、消息系统与EJB之间的关系：

EJB容器、客户端、消息系统与EJB之间的关系

客户端发送消息到JMS消息系统中的队列或主题。Message-driven Bean在部署到容器中时，指定的队列或主题，容器对其进行监听；当容器从队列或主题中接收到消息之后，将消息作为事件的一部分通知容器中相应的Message-driven Bean实例。

组件模型单元

Message-driven Bean由容器控制其生存周期，容器提供安全、并发、事务等等服务，对于客户端来说，Message-driven Bean是不可见的。因此，Message-driven Bean不同于Session Bean和Entity Bean，不具有组件接口和Home接口。

Message-driven Bean组件模型包含两个单元，即组件类和部署描述。下面分别对开发这些单元时，涉及的普遍过程、规则及注意事项进行描述。

组件类

 javax.ejb.MessageDrivenBean接口

EJB2.1规范中的Message-driven Bean组件中的组件类必须实现MessageDrivenBean接口。EJB3.0规范不强制Message-driven Bean实现该接口，而通过@MessageDriven注解进行标记并通过依赖注入与注解实现类似功能。

MessageDrivenBean接口中定义了两个容器管理回调的方法：

·             setMessageDrivenContext方法，容器创建Bean实例后，容器将调用该方法将由容器维护的Bean实例的上下文（context）与Bean实例进行关联。在EJB3.0规范中，可使用@Resource注解通知容器注入MessageDrivenContext实例。

·             ejbRemove方法，在实例被容器清除时，容器将调用此方法。一般，实例会在此方法中对实例占用的资源进行释放。在EJB3.0规范中，可使用@PreDestroy注解标记此方法。

 javax.jms.MessageListener接口

Message-driven Bean组件中的组件类必须实现MessageListener接口。

在消息到达Message-driven Bean指定的监听队列或主题时，容器将调用javax.jms.MessageListener接口中定义的onMessage方法。开发者在此方法中提供对消息进行处理的业务逻辑。

Session Bean和Entity Bean不可实现javax.jms.MessageListener接口。

 javax.ejb.MessageDrivenContext接口

容器将提供一个MessageDrivenContext对象，使实例可以访问由容器维护的实例的上下文环境。在此接口中，定义了如下方法：

·             getEJBHome、getEJBLocalHome方法，从EJBContext接口继承的方法，Message-driven Bean实例不可调用此方法；

·             getCallerPrincipal方法，从EJBContext接口继承的方法，Message-driven Bean实例不可调用此方法；

·             isCallerInRole方法，从EJBContext接口继承的方法，Message-driven Bean实例不可调用此方法；

·             setRollbackOnly方法，当前事务将被永久标记为回滚，不会被提交。只有容器管理事务的Message-driven Bean可被允许使用此方法；

·             getRollbackOnly方法，检查当前事务是否已被标记为回滚。例如，EJB实例可以通过此方法，决定是否继续在当前事务边界内继续进行计算。只有容器管理事务的Message-driven Bean可被允许使用此方法；

·             getUserTransaction方法，返回javax.transaction.UserTransaction接口。EJB实例可通过此接口对事务边界进行划分，并取得事务的状态。只有容器管理事务的Message-driven Bean可被允许使用此方法；

 串行化的调用

Apusic应用服务器中的EJB容器支持Message-driven Bean的多个实例的并发运行，但是每个实例只“看到”一个串行的方法调用过程，因此开发Message-driven Bean时，不需要将其以可重入（reentrant）的方式进行编写。

 消息处理的并发

Apusic应用服务器允许Message-driven Bean的多个实例并发执行，提供对流（Stream）消息并发处理。

 Message-driven Bean方法的事务上下文

onMessage方法在何种事务范围内被调用，取决于部署描述中指定的事物属性，如Bean被指定使用容器管理的事务的方式，则必须将事务属性设置为“Required”或“NotSupported”。

当Bean采用Bean管理的事务的方式，即使用javax.transaction.UserTransaction接口进行事务划分时，导致Bean实例被调用的消息接收操作并非是事务中的一部分。如果希望消息接收操作是事务中的一部分，则Bean必须使用容器管理事务的方式，并且设置事务属性为“Required”。

 消息接收确认（Message Acknowledgement）

Message-driven Bean不能使用JMS API中提供的消息接收确认操作。消息接收确认操作由容器自动完成。如Bean采用了容器管理事务的方式，则消息接收确认操作作为事务提交的一部分自动进行。如使用了Bean管理事务的方式，消息接收确认操作不能作为事务提交的一部分，开发者可通过在部署描述中的acknowledge-mode元素指定消息接收确认操作的方式为AUTO_ACKNOWLEDGE或DUPS_OK_ACKNOWLEDGE，如未指定acknowledge-mode元素，容器将使用AUTO_ACKNOWLEDGE方式进行消息接收确认操作。

指定队列（Queue）或主题（Topic）

当Message-driven Bean被部署到容器时，必须关联到某个消息队列（Queue）或主题（Topic），以便容器对此队列或主题进行监听。

开发者可通过@MessageDriven注解的mappedName属性或部署描述文件中的message-driven-destination元素指定关联的队列或主题。

如Bean关联的是一个消息主题，则通过部署描述中的subscription-durability元素指定对队列进行的是持久还是非持久订阅，如此元素未指定，则使用非持久订阅的方式。

 异常处理

Message-driven Bean中的onMessage方法不能声明抛出java.rmi.RemoteException异常。

一般来说，Message-driven Bean在运行期间不应向容器抛出RuntimeException异常。RuntimeException异常是指会导致Message-driven Bean进入“不存在”状态的非应用级异常。如果Bean使用了Bean-managed事务并抛出了RuntimeException异常，容器不应确认收到了这条消息。

从发信端看来，收信端一直存在，若发信端继续对该目的地发送消息，容器会自动把消息转向到其他Message-driven Bean实例。

遗漏的PreDestroy调用

在系统发生异常的情况下，不能保证容器总会调用Bean的PreDestroy方法，因此，如果Bean在PostConstruct方法中打开了一些资源，并在PreDestroy方法中释放这些资源，在这种情况下，则这些资源不能被释放。

鉴于以上原因，使用Message-driven Bean的应用需要提供一种机制，以便周期性的清除这些未释放的资源占用。

 必须遵守的规则

在开发Message-driven Bean时，开发者必须遵守如下规则：

 组件类

·             使用EJB2.1规范时，必须间接或直接实现javax.ejb.MessageDrivenBean接口；使用EJB3.0规范时，可改为使用@MessageDriven注解对组件类进行标记。

·             必须间接或直接实现javax.jms.MessageListener接口；

·             类必须声明为public，不可被声明为final或abstract类；

·             必须拥有一个无参数的public构造函数（constructor）；

·             类不能定义finalize()方法；

·             在原EJB2.1规范中，类必须实现ejbCreate()方法用来创建组件实例，在EJB3.0中，这一要求已被移除了。EJB3.0的兼容规则规定，如果Message-driven Bean类实现了ejbCreate()方法，将看作被@PostConstruct注解标记的方法处理。此时若同时使用@PostConstruct注解，则只能标记ejbCreate()方法。

 onMessage方法

·             方法必须被声明为public；

·             方法不能被声明为final或static；

·             返回值必须为void；

·             方法只能有一个javax.jms.Message类型的参数；

·             不能抛出java.rmi.RemoteException异常

·             运行期间一般来说不应抛出RuntimeException。请参考：

 ejbRemove方法

·             方法名必须是ejbRemove;

·             方法必须被声明为public；

·             方法不能被声明为final或static；

·             返回值必须为void；

·             方法不能有参数；

·             不能抛出java.rmi.RemoteException异常。

·             在EJB3.0规范中，可使用@PreDestroy注解实现同样效果。若实现javax.ejb.MessageDrivenBean接口同时使用注解，则只能把ejbRemove()方法注解为@PreDestroy

生存周期

下图表示Message-driven Bean的生存周期。

Message-driven Bean的生存周期

事务处理：
　　服务器提供对EJB组件的事务控制服务，多个业务操作同时成功，或全部失败，可以通过代码外的　部署描述来设置组件事务处理级别 ；

EJB的客户端有以下几种类型：

一般，EJB组件由以下几个部分组成，即组件服务器 (Server)，容器 (Container)，类 (Class) ，实例 (Instance)
接口、Home接口，Remote 接口、Enterprise Bean类和部署描述文件(Message-driven Bean不具有组件接口和Home接口）。下面分别描述这些组成部分

EJB的组件接口
　　客户端通过EJB的组件接口访问EJB对象，组件接口中定义了可被客户端访问的业务方法(Message-driven Bean不具有组件接口）。组件接口分为远程接口和本地接口。

EJB对象通过远程或本地接口，提供远程客户访问或本地客户访问的支持。

　　　提供远程接口的EJB拥有可被远程客户访问或本地客户访问的能力。对于提供了远程接口的对象，客户可通过标准的Java RMI（Remote Method Invocation）进行远程对象调用。

　　提供本地接口的EJB只可被本地组件通过本地接口进行调用。所谓本地组件，即是运行于相同Java虚拟机中的本地EJB对象。本地调用通过一般的标准Java编程语言接口进行。

EJB可以同时提供本地接口和远程接口，但一般只提供二者之一。

HOME接口
　　　EJB2.0规定了通过Home接口来提供客户端创建、清除和在同种类型的EJB中查找特定EJB对象的方法(Message-driven Bean不包含Home接口）。对于提供远程接口的EJB，需要提供远程Home接口；提供本地接口的EJB，需要提供本地Home接口。

　　　Home接口由EJB开发人员编写，远程Home接口必须扩展（extend）javax.ejb.EJBHome接口；本地Home接口必须扩展（extend）javax.ejb.EJBLocalHome接口。

EJB客户端通过标准的JNDI（Java Naming and Directory Interface™）API定位Home接口。

　EJB3.0中，Home接口的功能由依赖注入以及可选的生命周期回调方法实现。EJB组件不再需要提供Home接口

Enterprise Bean类
Enterprise Bean类包含了组件的实现细节。

　　Enterprise Bean类由EJB开发人员编写，EJB2.0规范中的Enterprise Bean组件，必须分别声明实现如下接口，javax.ejb.SessionBean、javax.ejb.EntityBean和javax.ejb.MessageDrivenBean。符合EJB3.0规范的Enterprise Bean组件则不须实现以上接口，而使用@Stateful、@Stateless、@MessageDriven注解标记EJB类。

部署描述文件
　　　部署描述文件是用于包含Enterprise Bean的运行时属性(安全性，事务性等等)信息的文件，与以上部分一起形成完整的EJB组件，通常部署描述文件使用图形化的部署工具进行处理。在EJB3.0规范中，EJB部署描述文件并不是必须的，可以在代码中使用注解来为EJB类附加部署信息。但部署描述文件可以令管理人员在部署时更为灵活。EJB3.0规范规定，当部署描述文件的信息与程序代码中的注解信息出现冲突时，以部署描述文件为准。这样管理人员就可以通过修改部署描述文件来改变部署信息，而不须重新编译应用程序。

五. 简化的编程模型

关注于业务逻辑实现：EJB 负责生命周期 (lifecycle), 数据存储 (persistence), 事务处理语义 (transactional semantic), 安全(security), ...
通用的编程模型：各种服务的高层 API
Java 是其编程语言


EJB( 业务逻辑代码 ) 表示了与特定商业领域（例如银行、零售等行业）相适应的逻辑。它由
运行在业务逻辑层的 enterprise bean 处理。一个 enterprise bean 可以从客户端接受数据，对
它进行处理，并将其发送到企业信息系统层以作存储；同时它也可以从存储器获取数据，
处理后将其发送到客户端应用程序。
有三种类型的 enterprise beans：session beans、entity beans 和 message-driven beans。
Session bean 描述了与客户端的一个短暂的会话。当客户端的执行完成后，session bean 和
它的数据都将消失；与之相对应的是一个 entity bean 描述了存储在数据库表中的一行持久
稳固的数据，如果客户端终止或者服务结束，底层的服务会负责 entity bean 数据的存储。
Message-driven bean 结合了 session bean 和 Java 信息服务（JMS）信息监听者的功能，它允
许一个商业组件异步地接受 JMS 消息。

六:EJB组件模型的灵活性

EJB组件模型的灵活性表现在:
EJB可作为表示无状态服务的对象；
EJB可作为表示无状态服务的对象，可通过向指定的消息队列或主题发送JMS消息，以实现对此对象的异步调用；
EJB可作为表示与特定客户的会话对象。此类对象在客户进行跨越方法的调用时，自动维持会话状态；
EJB可作为表示业务对象的实体对象，在多个客户间共享；
EJB可作为一个细粒度的持久对象，包含在一个粗粒度业务对象的持久状态中。
通常，被远程访问的组件往往是粗粒度的业务对象，如订单、雇员纪录；细粒度的业务对象往往不会采用可远程访问的EJB组件模型，如订单中的采购项、雇员纪录中的地址，而是采用可本地访问的EJB组件模型或是作为EJB的附属类出现。

七:何时使用EJB组件:

下面是在使用EJB组件模型构建企业应用时，一些判断EJB组件模型是否适用的标准。
EJB组件是构建分布式企业应用的组件模型技术；
EJB组件规范是针对分布式企业应用制定的，是基于分布式对象技术的Java组件；EJB组件不涉及表示层的内容，因此，必须与其他表示层技术一起使用；应用服务器提供了可以解决安全性、资源共享、持续运行、并行处理、事务完整性等复杂问题的服务，从而简化了商业应用系统。
应用客户端类型的考虑；
一般，企业应用开发都会有多种类型的客户端的需求，访问相同的数据或业务逻辑。如使用Web客户提供对应用的基于Internet的访问，使用应用客户端提应用基于Intranet的访问。EJB组件模型将业务逻辑与数据封装到EJB组件中，提供对多种客户端的支持。

应用数据与业务逻辑的并发访问控制的考虑；
企业应用通常需要提供数据或业务逻辑的并发访问能力，以此保证数据的完整性，由于EJB 组件控制对后台数据的访问，并管理当前事务和数据库的内部锁定。节省了编写数据库控制逻辑的工作量，同时也保证了数据的一致性与正确性，从而降低了总编程量。
全局事务控制的考虑；
企业应用通常需要对不同的资源进行事务性的操作，如某个操作需要对数据库进行访问，同时可能需要通过JMS消息服务发送消息，或者，需要访问两个位于不同物理位置的异种数据库，这些操作必须在相同的事务环境中完成。
基于访问控制的考虑；
企业应用中往往需要对某些资源进行访问控制，如需要针对不同用户对组件方法调用设置访问控制策略，对访问特定Web资源的用户设置访问控制策略等.