我过去曾使用 JMS 来构建应用程序，效果很好。现在，我与愿意使用规范：基于 Java 消息服务 1.0 的 SOAP 的架构师合作。
这个规格接缝过于复杂。
我没有看到太多的实现（除了推动规范的供应商之外）。
这里有人在生产环境中使用这个规范吗？
使用此规范的主要好处是什么？
Link: http://www.w3.org/TR/2009/CR-soapjms-20090604/ http://www.w3.org/TR/2009/CR-soapjms-20090604/
我在使用 SOAP over JMS 时运气不佳。如果它用于即发即弃操作（WSDL 中没有定义响应消息），那么它确实有意义。在这种情况下，您可以使用 WSDL 生成客户端框架，并且可以将 WSDL 存储在服务注册表中。此外，您还可以获得 JMS 的所有常见好处（发送方和接收方解耦、负载平衡、优先级、安全性、桥接多个目的地 - 例如非侵入式审核）。
另一方面，SOAP 主要用于请求/回复类型的操作。通过 JMS 实现请求/回复模式会带来以下问题：
- 无法正确处理超时。您永远不知道请求是否仍在等待交付或卡在被调用的组件中。
- 响应通常在临时队列上发送。如果客户端在收到响应之前断开连接，并且响应消息上没有明确设置生存时间，则临时队列可能会卡在 JMS 服务器中，直到您重新启动它。
- 中间有 JMS 服务器会显着增加往返时间并增加不必要的复杂性。
- JMS 提供了一种可靠的传输介质，可将发送方与接收方解耦，但在请求/回复的情况下，客户端不应与服务器解耦。客户端需要知道服务器是否已启动且可用。
我能想到的唯一优点是可以在客户端不知情的情况下移动服务器或进行负载平衡，但使用 UDDI 和 HTTP 负载平衡器是更好的解决方案。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
