我过去曾使用JMS来构建应用程序，它运行良好。现在我和想要使用Spec：SOAP over Java Message Service 1.0的Architects一起工作。
这个规格过于复杂。我没有看到很多实现（除了供应商推动规范）。
这里有人在生产环境中使用此规范吗？使用此规范的主要好处是什么？
我使用SOAP over JMS运气不好。如果它用于fire-and-forget操作（WSDL中没有定义响应消息），那么它确实有意义。在这种情况下，您可以使用WSDL生成客户端框架，并且可以将WSDL存储在服务注册表中。此外，您还可以获得JMS的所有常见优势（将发送方和接收方解耦，负载平衡，优先级排序，安全性，桥接到多个目的地 - 例如非侵入式审计）。
另一方面，SOAP主要用于请求/回复类型操作。通过JMS实现请求/回复模式会引入以下问题：
我能想到的唯一优势是可以在客户端不知道的情况下移动或负载均衡服务器，但使用UDDI和HTTP负载均衡器是一种更好的解决方案。
我想说，从建筑师的探矿中，同样的问题是关于为什么要有一个5层互联网模型，第五个是应用程序，当一个人可以简单地在套接字级编码整个应用程序。从您的应用程序生成或使用的内容（SOA消息）中抽象出传输层（在您的情况下为JMS）是一个很好的做法，其中可能的原因是独立单元测试以及未来迁移到其他平台是我首先想到的
天哪，我讨厌与建筑师宇航员合作。我觉得你的痛苦兄弟。除了“这是一个标准”之外，他们实际上是否有实际的功能性原因？这个决定是否会将它们锁定到特定的EE容器供应商（比如WebSphere）？那是2002年;很少有人真正需要它;事实上，大多数实际的，成功的实现都忽略了SOAP。除非他们真正需要比JMS或SOAP-over-HTTP单独提供的更多可靠性，否则您就是在旅途中。
查看Apache CXF站点以获取一些示例（特定于CFX）。
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/
SOAP / JMS和SOAP / HTTP用于不同的场景，尽管使用Message Fire和Request / Response。 SOAP / JMS实际上很简单，只需使用SoapAction和targetService就可以将发现的（如果需要转换的）消息传播到多个sourec。 JMS规范还使用标头帮助进行复杂路由。
事实上，UDDI以及构建服务器可以用AND作为源来发现从大规模中间件部署（无论引擎架构）作为SOAP / JMS消息到单一SOA Repository Sinks的已发布WSDL（内联）。在企业治理中非常重要
因此，当异步性至关重要时，对于线接头模式来说，这是至关重要的。
SOAP / HTTP和现在的REST（使用动词名词模型）最适合可信的子系统调用
你实现了一个经常使用的Web服务的图像，它往往会运行你的线程，而你承诺，没有任何消息会丢失。
在会话bean上运行的Web服务实现（服务器）带有有限数量的线程（比如池中的n个活动PE），它可以同时运行n个Web服务请求。 n + 1请求会发生什么？
MRDE，你没有答应你的应用程序所有者，没有消息会丢失。因此，JMS会保留此功能。 Web服务框架只需将数据存储在队列中，这也为负载峰值提供了可靠性。
WS over JMS的有趣之处在于，正在运行的WS请求所用的时间非常短，因此计算重新将立即返回给服务器下一个请求。
来自here：
SOAP over JMS为SOAP over HTTP提供了另一种消息传递机制。虽然它尚未标准化，因此可能无法跨平台进行互操作，但SOAP over JMS提供比SOAP over HTTP更可靠和可扩展的消息传递支持。随着JAX-RPC和JSR-109成为J2EE标准的组成部分，使用SOAP over JMS的Web服务中的企业消息传递将变得非常成熟。