消息传递是请求/回复的良好实现

JMS或消息传递确实很好地捆绑了不同的应用程序，并形成了许多ESB和SOA体系结构的基础结构。消息传递是请求/回复的良好实现

然而，应用程序A需要来自应用程序B上的服务的即时响应，例如，需要订单的供应细节或需要立即确认某些更新。从性能的角度来看，Messaging是正确的解决方案吗？通常，客户端将连接到队列上的MoM - 然后，必须有空闲的监听器才会接收消息并转发给服务器端处理器 - 该服务器端处理器将处理响应并将其发送回队列或主题，并请求客户将遵循相同的流程并将其提取出来。如果消息的大小很大，那么MoM将不得不考虑这个因素。

让我怀疑Http是否是更好的解决方案来访问这样的解决方案，而不是通过消息传递路径？我已经看到许多应用程序使用像AMQ或TIBCO Rvd这样的MoM实际用于立即请求/响应 - 但是这是不好的设计，或者是一些微调或设置使它与Http相同。

来源

2013-02-23 Soumya

这真的取决于您的要求。通常短信服务将支持一个或所有的以下内容：

保证传递
事务
持久性（即消息一直持续到交付，即使系统中interrim失败）

HTTP连接不能[很容易]实现这些属性，但是如果你不需要它们，那么我想你可以说“简单”HTTP将提供更简单和更轻量级的s olution。（强调“简单”，因为一些消息传递会通过HTTP进行）。

我不认为通过消息传递实现的请求/响应本身就是糟糕的设计。我的意思是，这是事情....你在执行这个过程的两个方面吗？如果没有，并且你已经有了一个建立的消息服务来响应请求，除了所有其他的考虑外，这似乎是要走的路...并绕过使用HTTP重新实现，因为一些设计概念需要一些公平的在我看来，它背后有很强的推理。

但是反过来也是如此。如果您已经拥有HTTP可访问资源，并且您没有任何可能会提供更强大的消息传递解决方案的超级严格要求，那么我不会强制要求其没有担保的地方。

如果你是完全compulata tabula-rasa，你必须从零开始实施双方......然后.....在这里发布另一个问题的一些细节！ :)

来源

2013-02-26 22:22:52 Nicholas

谢谢。那么对于新项目，并且希望为JMS/HTTP中的哪种服务设置一些标准。例如订购过程 - 虽然它可能会在提交订单后仍然执行一系列短暂的自动化事件，但我们可以开火并忘记 - 因此JMS非常适合。但是对于某些位，比如我想要一个服务的状态 - 目前这是通过JMS，我们正在考虑转移到HTTP。 - 我承认，我们没有做任何性能测试，但试图收集，如果反之，在immediete响应比JMS更好的情况下。更改代码很好 - 只需将连接API从JMS – Soumya 2013-03-01 16:51:39

更改为HTTP hi Nicholas - 根据我上面的评论，您可以进一步评论吗？谢谢 – Soumya 2013-03-04 15:34:28

对于你的两个例子，它们在每种情况下听起来都是合适的。JMS非常擅长Fire-n-Forget，但对于更多类似于实用程序的事情（如状态检查），使用HTTP是有意义的，并且还简化了调用并扩展了潜在客户群（发布WGET更容易命令，而不是发送JMS消息....） – Nicholas 2013-03-04 16:36:37

消息传递是请求/回复的良好实现

回答

相关问题