我过去曾使用 JMS 来构建应用程序，它运行良好。现在我与喜欢使用规范的架构师合作：SOAP over Java Message Service 1.0。
此规范接缝过于复杂。 我没有看到很多实现（除了供应商推动规范）。
这里有人在生产环境中使用此规范吗？ 使用此规范的主要好处是什么？
【问题讨论】：
标签： java soap web-services jms soa
该死的，我讨厌与 Architect Astronauts 一起工作。我感觉到你的痛苦兄弟。除了“这是一个标准”之外，他们是否真的有一个实际的、功能性的理由这样做？这个决定是否会将它们锁定在特定的 EE 容器供应商（比如 WebSphere）中？ 2002 年就是这样；很少有人真正需要；事实上，大多数实际、成功的实现几乎都忽略了 SOAP。除非他们真正需要比 JMS 或 SOAP-over-HTTP 单独提供的可靠性更高的可靠性，否则您就是在旅行。
查看 Apache CXF 站点以获取一些示例（特定于 CXF）。
http://cxf.apache.org/docs/soap-over-jms-10-support.html
经验法则是真正使用最低限度，而不是全部堆栈。如果你的建筑师宇航员仍然坚持使用整个东西，你可能只是走进了一个痛苦的世界。对不起。
顺便说一句，您将使用什么应用程序容器？ WebLogic、JBoss、WebSphere？以及哪个 Web 服务框架？ Apache CFX、Axis？
建筑师宇航员会喜欢说这些是实施细节。公牛。任何对变更带来巨大成本（或实施带来显着节省）的系统的决策都是架构决策。这些几乎决定了事情将如何实施（以及更改的成本是多少），因此尽早确定您将使用哪个是架构决策，除非是非常独立的系统。
关于这个有争议的主题的更多链接：
http://www.subbu.org/blog/2005/03/soap-over-jms http://parand.com/say/index.php/2005/03/29/soap-over-jms-no-such-thing/
【讨论】：
我想说，从架构师的前景来看，同样的问题是为什么要有一个 5 层 Internet 模型，而第 5 层是应用程序，当人们可以简单地在套接字级别对整个应用程序进行编码时。从您的应用程序生成或使用的内容（SOA 消息）中抽象出传输层（在您的情况下为 JMS）是一个很好的实践，其中可能是独立单元测试以及未来向其他平台的迁移是我首先想到的原因
【讨论】：
我运气不好使用 SOAP over JMS。如果它用于即发即弃操作（在 WSDL 中没有定义响应消息），它确实有一定的意义。在这种情况下，您可以使用 WSDL 来生成客户端框架，并且可以将 WSDL 存储在您的服务注册表中。此外，您还可以获得 JMS 的所有常见好处（解耦发送方和接收方、负载平衡、优先排序、安全性、桥接到多个目的地 - 例如非侵入式审计）。
另一方面，SOAP 主要用于请求/回复类型的操作。在 JMS 上实现请求/回复模式会引入以下问题：
我能想到的唯一优点是服务器可以在客户端不知道的情况下移动或负载平衡，但使用 UDDI 和 HTTP 负载平衡器是更好的解决方案。
【讨论】：
图片你实现了一个常用的 Web 服务，即 往往会跑出线程，而你承诺，没有消息 会丢失。
运行在 会话 bean 带有有限数量的线程（比如 n 池中的活动 PE），可能会运行 n 个 Web 服务请求 同时。 n+1 请求会发生什么？
MRDE，你不是答应过你的应用程序所有者吗？ 消息将丢失。所以 JMS 隔离了这个功能。 Webservice 骨架只需要将数据存储在队列中， 这也为负载峰值提供了可靠性。
WS over JMS 的有趣之处在于，经过的时间 正在运行的 WS 请求的时间很短，因此计算资源 将立即返回服务器下一个请求。
【讨论】：
SOAP/JMS 和 SOAP/HTTP 用于不同的场景，尽管使用 Message Fire 和 Request/Response。 SOAP/JMS 实际上非常适合通过使用 SoapAction 和 目标服务。 JMS 规范还有助于使用标头进行复杂路由。
事实上，UDDI 以及构建服务器可以、现在和已经被用作从大量中间件部署（不考虑引擎架构）中发现已发布 WSDL（内联）的源，作为 SOAP/JMS 消息到单个 SOA 存储库接收器。在企业治理中非常重要
因此，当异步性至关重要时，它对线抽头模式至关重要。
SOAP/HTTP 和现在的 REST（带有动词名词模型）最适合受信任的子系统调用
【讨论】：
来自here：
SOAP over JMS 提供了一种替代 SOAP over 的消息传递机制 HTTP。虽然它尚未标准化，因此可能不会 跨平台互操作，SOAP over JMS 提供更可靠和 可扩展的消息传递支持比 SOAP over HTTP。作为 JAX-RPC 和 JSR-109 成为 J2EE 标准的组成部分，企业消息传递 使用 SOAP over JMS 的 Web 服务将变得成熟。
【讨论】：