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部署描述文件才能使用这项功能。