JMS或消息传递非常适合捆绑不同的应用程序并构成许多ESB和SOA体系结构的基础结构。
然而，说应用程序A需要来自应用程序B上的服务的即时响应，例如需要订单的配置详细信息或需要立即确认某些更新。从性能的角度来看，Messaging是否是正确的解决方案？通常，客户端将连接到队列上的MoM - 然后必须是空闲的侦听器将获取消息并转发到服务器端处理器 - 处理器将处理响应并将其发送回队列或主题并请求客户将遵循相同的流程并捡起来。如果消息大小很大，那么MoM也必须考虑到这一点。
让我想知道Http是否是访问此类解决方案而不是通过消息传递路径的更好解决方案？我已经看到许多应用程序使用MoM（如AMQ或TIBCO Rvd）来实际用于即时请求/响应 - 但这是一个糟糕的设计，还是一些微调或设置使其与Http相同。
答案 0 :(得分：2)
这实际上取决于您的要求。通常，消息传递服务将支持以下一项或全部：
HTTP连接不能[轻松]实现这些属性，但是再次，如果你不需要它们，那么我想你可以说“简单”HTTP会提供更简单的更轻量级的解决方案。 （强调“简单”因为某些消息传递实施将通过HTTP运行。）
我认为通过消息传递实现的请求/响应本身就是糟糕的设计。我的意思是，这就是......你在实施这个过程的两个方面吗？如果没有，并且你已经有一个已建立的消息服务，它将响应请求，除了所有其他考虑因素之外，这似乎是要走的路......并且绕过它以重新实现使用HTTP因为一些设计概念需要一些公平的在我看来，背后有很强的推理力。
但反过来也是如此。如果您已经拥有HTTP可访问资源，并且您没有任何超级严格的要求，否则可能会建议更强大的消息传递解决方案，我不会强制要求它不在保证的位置。
如果你完全赞同tabula-rasa并且你必须从头开始实施双方.....那么.....在这里发布另一个问题并提供一些细节！ ：）