在我参与的大多数项目中，异步解决方案的选择一直是很多讨论的源泉......
每次单个实体bean足以管理队列时：我们只在表中存储消息（票证），处理cron将队列取消堆栈。这个简单的解决方案具有非常简单的优点，它基于数据库的事务上下文，我们可以在执行期间管理接收消息的状态。
因此，我提出以下问题：
1）我们对使用JMS有什么兴趣？ JMS有哪些好处？
2）在哪种情况下更喜欢JMS与实体bean？
感谢您的回复和反馈！
答案 0 :(得分：13)
1）我们对使用JMS有什么兴趣？ JMS有哪些好处？ 2）在 哪种情况更喜欢JMS与 实体bean？
只要只有一个消费者，您的方法就可以正常运作。否则，它将需要一个锁定方案，以便相同的消息不会被提供两次，等等。这就是JMS提供的开箱即用：JMS代理管理生产和消费，管理多个消费者/生产者的所有交付问题。
JMS的其他优点是服务质量和管理，例如重新传递尝试，死信息队列，负载管理，可扩展性，聚类，监控等。
JMS还支持publish-subsribe或point-to-point。
这有点像比较JDBC语句在数据库中插入一行而不是完整的ORM。两者都可以在数据库中插入一行，但是ORM会提供更多，而且你不会重新发明轮子来处理低级问题... （类比不是那么好但是孔）
我建议您查看FAQ。
答案 1 :(得分：8)
在Java EE中，基本上有3种处理异步性的机制：
此外，近十年来，JMS规范尚未更新。它仍然非常有用，它展示了API设计的大量前瞻性，但有时它会感觉有点神秘。必须定义管理对象（如目标）的方式，获取连接所需的方式，创建会话等等，这些都感觉有点低级，陈旧和神秘。使用消息驱动的bean可以大大简化接收消息，但发送却没有。
然后，出于某些遗留奇怪的原因，禁止网络模块监听JMS目的地。当然，这已经没有理由了，但它在古老的J2EE 1.3和更新的规范中。兼容的应用程序服务器仍然支持此规则，但它们都提供供应商特定的配置以允许它。但这会使您的应用程序不那么便携。
历史上使用JMS的用例的子集是在单个应用程序中非常简单的基于事件的编程。为此，CDI事件总线现在可以说更适合，因为它更简单，更现代，整体更轻量级的方法。
使用JMS的另一个用例子集就是异步执行任何工作。因为人们有时习惯于创建一个MDB，然后从消息中解开参数并调用一些无状态会话bean的方法直接传递这些参数。在这种情况下，绝对不需要消息传递范例，只需调用@Asynchronous注释方法就是一种更简单，更直接的方法。