为什么选择JMS进行异步解决方案？为什么它比简单的实体bean更好？

Question

在我参与的大多数项目中,异步解决方案的选择已成为众多讨论的源泉......

每次单个实体bean足以管理队列时:我们只是在表中存储消息(票证),处理cron将队列取消堆栈.这个简单的解决方案具有非常简单的优点,它基于数据库的事务上下文,我们可以在执行期间管理接收消息的状态.

因此,我提出以下问题:

1)我们对使用JMS有什么兴趣？JMS有哪些好处？

2)在哪种情况下更喜欢JMS与实体bean？

感谢您的回复和反馈!

Answer 1

1)我们对使用JMS有什么兴趣？JMS有哪些好处？2)在哪种情况下更喜欢JMS与实体bean？

只要只有一个消费者,你的方法就能很好地发挥作用.否则,它将需要一个锁定方案,以便相同的消息不会被提供两次,等等.这就是JMS提供的开箱即用:JMS代理管理生产和消费,管理多个消费者/生产者的所有交付问题.

JMS的其他优点是服务质量和管理,例如重新传递尝试,死信息队列,负载管理,可扩展性,集群,监控等.

JMS还支持publish-subsribe或point-to-point.

这有点像比较JDBC语句在数据库中插入一行而不是完整的ORM.两者都可以在数据库中插入一行,但是ORM会提供更多,而且你不会重新发明轮子来处理低级问题...... (这个类比并不是那么好但是很好)

我建议你看一下FAQ.

Answer 2

在Java EE中,基本上有3种处理异步性的机制:

ewernli已经很好地解释了JMS的优势.它是一个功能非常全面的系统,但所有这些功能在开销和管理所涉及的管理对象的复杂性方面确实花费了一些.

此外,近十年来,JMS规范尚未更新.它仍然非常有用,它展示了API设计的大量前瞻性,但有时它会感觉有点神秘.必须定义管理对象(如目标)的方式,获取连接所需的方式,创建会话等等,这些都感觉有点低级,陈旧和神秘.尽管使用消息驱动的bean已经大大简化了接收消息,但发送却没有.

然后,出于某些遗留奇怪的原因,禁止Web模块监听JMS目的地.当然,这已经没有理由了,但它在古老的J2EE 1.3和更新的规范中.兼容的应用程序服务器仍然支持此规则,但它们都提供供应商特定的配置以允许它.但这会使您的应用程序不那么便携.

历史上使用JMS的用例的子集是在单个应用程序中非常简单的基于事件的编程.为此,CDI事件总线现在可以说更适合,因为它更简单,更现代,整体更轻量级.

使用JMS的另一个用例子集就是异步执行任何工作.因为人们有时习惯于创建一个MDB,然后从消息中解开参数并调用一些无状态会话bean的方法直接传递这些参数.在这种情况下,绝对不需要消息传递范例,只是调用@Asynchronous注释方法是一种更简单,更直接的方法.