我想检查设计方法的可行性，以使用面向消息的中间件（MOM）技术（如JMS或ActiveMQ或RabbitMQ）来处理单个Web应用程序中的异步处理，即发布者和MOM服务器的订阅者将是包含在同一个Web应用程序中。 这种设计背后的基本原理是将一些重型处理功能卸载为后台异步操作。在这种情况下，发布者是服务器端实时web服务方法，其需要立即（<1秒）响应回调用web服务客户端，并且发布者在MOM主题上发出消息。订阅者包含在与发布者相同的Web应用程序中，订阅者使用该消息异步处理复杂的稍微耗时（5-7秒）的功能。 通过这种设计，我们可以避免在应用程序服务器容器中生成新线程，以处理重型复杂处理功能。
在这种情况下，使用MOM服务器是否在同一Web服务器地址空间中包含消息发布者和消息订阅者的过度杀伤？据我所知，MOM技术主要用于应用程序间通信，并希望检查是否可以将MOM用于应用程序内部通信。
让我们知道你的想法。
谢谢，
答案 0 :(得分：0)
也许您不会认为这是一个很好的例子，但在JEE世界中使用JMS进行应用程序内部通信非常普遍。产生新线程被认为是糟糕的，而消息驱动的bean使消息消息相对容易，并且您获得了事务支持。像GlassFish这样的兼容应用程序服务器上有JMS，因此消息的生成和消费不涉及套接字通信，就像独立的ActiveMQ一样。但是可能有理由拥有一个独立的JMS，例如：如果有一个消费者群集，并且您希望活动实例从失败的实例中接管工作......但随后独立的JMS服务器成为单点故障，现在您需要它们的集群，依此类推。
JMS的一个重要特性是（可选）消息持久性。您可能会担心长时间运行的任务由于某种原因而失败，并且客户端的请求将丢失。但是持久性消息因为它们导致磁盘IO而要昂贵得多。
从您所描述的内容中我可以看出MOM的常见功能（异步处理，保证传送，消息顺序），您只需要异步处理。因此，如果保证不重要，我会使用某种线程池。