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