为什么不使用会话 Bean 而不是消息驱动 Bean？答案

【问题标题】：Why not use Session Beans instead of Message Driven Beans?为什么不使用会话 Bean 而不是消息驱动 Bean？
【发布时间】：2010-10-01 08:54:02
【问题描述】：

我在想，为什么不使用 Session Beans 而不是 Message Driven Beans 呢？

如果您可以从 EJB 调用远程方法，那么为什么还要使用消息驱动 Bean（它比会话 bean 更难开发）来发送/接收消息？

Message Driven Bean 在哪些场景下有用？

【问题讨论】：

【解决方案1】：

我在想，为什么不使用 Session Beans 而不是 Message Driven Beans 呢？

嗯，它们的用途不同，消息驱动的 bean 允许 Java EE 应用程序异步处理消息。

如果您可以从 EJB 调用远程方法，那么为什么还要使用消息驱动 Bean（它比会话 bean 更难开发）来发送/接收消息？

因为 MDB 为您提供异步和松散耦合，这是您在某些情况下可能想要/需要的：

顺便说一句，我个人一直认为 MDB 是最容易开发的 Enterprise Bean。

Message Driven Bean 在哪些场景下有用？

见上文。

【讨论】：

我要补充一点，MDB 不一定是异步的，真正驱动通信方式的是连接器。 MDB 源于 JMS，连接器 API 是从该用例中抽象出来的，但现在连接器/MDB 关系实际上允许任何类型的通信。我对 EJB.next 有一些想法，以进一步简化 MDB/连接器关系，以便连接器可以提供 MDB 可以使用的自己的注释，从而使 @ActivationConfig 和显式 MessageListener 接口的需要无关紧要。然后像 JAX-RS 这样的事情可以作为连接器/MDB 来完成。
@David 没错（我大大简化了）。你提到的是一个非常有趣的方向。非常感谢你分享这个，大卫。
是的，我有点兴奋。一直想在一篇博文中讨论它，但由于我们正在聊天，我终于咬紧牙关，这样做了bit.ly/bym3SC 在进一步的旁注中，我希望整个“我使用哪种 bean 类型”的问题是一个我们可以通过将所有内容都基于 @ManagedBean 并让人们专注于他们想要使用的服务以及他们希望如何公开他们的 bean 来杀死。

【解决方案2】：

消息驱动的 bean 监听 JMS 队列异步不像实体/会话 bean。

这不会阻塞服务器资源，因为仅当消息到达队列时才会进行处理。

除了大量的 Java 论坛和网站之外，维基百科还有一组很好的用例，MDB 可以派上用场

【讨论】：

【解决方案3】：

两者都有不同的用途。

1) 如果您只想将其用于远程方法，那么只需使用 Session Bean

2) 但是如果响应/结果不重要，但后面的消息对您来说很重要，那么请使用 JMS，因为它正在创建队列以使其工作并设置消息。但是会有性能问题。

如果您只需要使用方法，那么只需使用会话 bean，因为它是轻量级 bean。并且表现不错。

【讨论】：