MDB基本概念

1.JMS客户端：使用JMS的应用程序。

2.JMS provider：处理消息的路由与传递的消息系统。

3.JMS应用：由多个JMS客户端和一个JMS provider构成的业务系统。

同一JMS客户端既可以是生产者也可以是消费者。

JMS

MDB同样具有上下文对象。MessageDrivenContext，它简单地继承自EJBContext，并不包含任何新方法。
在从EJBContext，继承而来的MessageDrivenContext的方法中，只有与事务有关的方法才对MDB有意义。
注意：这里的事务上下文并非从JMS的发送方传播过来，而是由容器发起，或由bean明确使用

javax.jta.UserTransaction被发起的。
MDB可以访问其他session bean,可以对任务流进行控制，并在期间与其他bean或资源进行交互。例如：根据MDB

所处理的消息内容，对它来说，利用JDBC来访问数据库是很平常的事情。
MDB在BMT中执行，或者在具有NotSupported属性的容器管理的事务中执行时，确认模式不是不能被忽略的。
Dups-ok-acknowledge模式对性能提升影响不大。

当MDB使用Topic时，需要指定订阅是Durable或NonDurable。NonDurable订阅模式可以改善JMS provider 的性能，但也会降低MDB的可靠性。使用Queue时，就没必要指定了。

回调方法：

@PostConstruct，可以起任何名，但是必须返回void，不带任何参数，且不能抛出任何checked exception。每个bean class 只能定义一个@PostConstruct方法。

@PreDestroy 同上，可以用来处理一些类似关闭连接之类的清理工作。

基于JMS的MDB的局限性：
1.不可在不同的EJB容器间进行移植。
2.它只支持JMS编程模型而不支持其他类型的消息系统。虽然JMS非常有用，但是它并不是唯一可用的消息系统。

SOAP、emai、CORBA消息系统，以及在ERP系统中使用的专有消息系统(SAP、PeopleSoft等)，还有遗留消息系统

，这些都是非JMS消息系统的例子。

基于连接器的Message-Driven Bean
EJB3.0(还有2.1)支持一个扩展的，更为开放的MDB定义，使之可以对任何开发商的任何消息系统提供服务。唯一

的要求是，这些新型的MDB必须遵循MDB的生命周期。在EJB3.0中，EJB厂商仍然可以通过编写定制代码来整合新

的消息系统（非JMS消息系统），但是他们必须支持任何基于JCA1.5的MDB类型。
基于连接器的MDB所实现的消息处理接口并非一定要使用onMessage()方法来传递消息。可以根据需要选择任何形

式的方法名称和签名，该方法甚至可以拥有返回值。

消息连接
专门定义一个MDB来处理具体的分发工作可以获得更好的灵活性和系统性能。
EJB并没有为消息连接提供注解，因此我们必须使用XML部署描述文件才能使用这项功能。