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