架构师迫切希望在JMS上使用SOAP

Question

我过去曾使用JMS来构建应用程序，它运行良好。现在我与想要使用Spec：SOAP over Java Message Service 1.0的架构师合作。

这个规格过于复杂。 我没有看到很多实现（除了供应商推动规范）。

这里有人在生产环境中使用此规范吗？ 使用此规范的主要好处是什么？

链接：http://www.w3.org/TR/2009/CR-soapjms-20090604/

Answer 1

我使用SOAP over JMS运气不好。如果它用于fire-and-forget操作（WSDL中没有定义响应消息），那么它确实有意义。在这种情况下，您可以使用WSDL生成客户端框架，并且可以将WSDL存​​储在服务注册表中。此外，您还可以获得JMS的所有常见好处（将发送方和接收方解耦，负载平衡，优先级排序，安全性，桥接到多个目的地 - 例如非侵入式审计）。

另一方面，SOAP主要用于请求/回复类型操作。通过JMS实现请求/回复模式会引入以下问题：

• 无法正确处理超时。您永远不知道请求是否仍在等待传递或被卡在被调用的组件中。
• 响应通常在临时队列上发送。如果客户端在接收响应之前断开连接并且没有明确的时间设置在响应消息上，则临时队列可能会卡在JMS服务器中，直到您重新启动它。
• 在中间使用JMS服务器会大大增加往返时间并增加不必要的复杂性。
• JMS提供了一种可靠的传输介质，可以将发送方与接收方分离，但在请求/回复的情况下，客户端不应与服务器分离。客户端需要知道服务器是否已启动且可用。

我能想到的唯一优势是可以在客户端不知道的情况下移动或负载均衡服务器，但使用UDDI和HTTP负载均衡器是一种更好的解决方案。

Answer 2

我会说，从建筑师的探矿中，同样的问题是关于为什么要有5层互联网模型，第5个是应用程序，当人们可以简单地在套接字级别编码整个应用程序时。从您的应用程序生成或使用的内容（SOA消息）中抽象出传输层（在您的情况下为JMS）是一个很好的做法，其中可能的原因是独立单元测试以及未来迁移到其他平台是我首先想到的

Answer 3

天啊，我讨厌与建筑师宇航员合作。我觉得你的痛苦兄弟。除了“这是一个标准”之外，他们实际上是否有实际的功能性原因？这个决定是否会将它们锁定到特定的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-thing/

Answer 4

SOAP / JMS和SOAP / HTTP用于不同的场景，尽管有Message Fire和Request / Response。 SOAP / JMS实际上很简单，通过使用SoapAction和传播（如果需要转换）消息到多个sourecs是非常好的 targetService。 JMS规范还使用标头帮助进行复杂的路由。

事实上，UDDI和构建服务器可以使用AND作为源来发现从大规模中间件部署（无论引擎架构）作为SOAP / JMS消息到单一SOA存储库接收器的已发布WSDL（内联）。在企业治理中非常重要

因此，当异步性至关重要时，它最重要的是电线分接模式。

SOAP / HTTP和现在的REST（使用动词名词模型）最适合可信的子系统调用

Answer 5

您实施了经常使用的Web服务的图像 倾向于运行ouf线程，而你承诺，没有消息 将失去。

在a上运行的Web服务实现（服务器） 会话bean带有有限数量的线程（比如说n 可能会运行n个Web服务请求的池中的活动PE） 同时。 n + 1请求会发生什么？

MRDE，你没有答应你的应用程序所有者，没有 消息将丢失。因此，JMS会保留此功能。 Webservice骨架只需将数据存储在队列中， 这也为负载峰值提供了可靠性。

WS over JMS的有趣之处在于经过的时间 正在运行的WS请求很短，因此计算重新进行 将立即回到服务器下一个请求。

Answer 6

来自here：

  

SOAP over JMS为SOAP over提供了一种替代的消息传递机制   HTTP。虽然尚未标准化，因此可能尚未标准化   跨平台可互操作的SOAP over JMS提供了更可靠的   可扩展的消息传递支持，而不是基于HTTP的SOAP。作为JAX-RPC和JSR-109   成为J2EE标准的组成部分，   在JMS上使用SOAP的Web服务将变得完善。