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