架构师迫切希望在JMS上使用SOAP [英] Architect desperately wants to use SOAP over JMS

问题描述

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

I have used JMS in the past to build application and it works great. Now I work with Architects that would love to use the Spec : SOAP over Java Message Service 1.0.

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

This spec seams overly complicated. I do not see many implementation (Beside the vendors pushing for the spec).

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

Does anyone here is using this specification in a production environment? What is your main benefit of using this spec?

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

推荐答案

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

I had the bad luck using SOAP over JMS. It does make some sense, if it is used for fire-and-forget operations (no response message defined in the WSDL). In this case you can use the WSDL to generate client skeletons and you can store the WSDL in your service registry. Plus you get all the usual benefits of JMS (decoupling sender and receiver, load-balancing, prioritising, security, bridging to multiple destinations - e.g. non-intrusive auditing).

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

On the other hand SOAP is mainly used for request/reply type operations. Implementing request/reply pattern over JMS introduces the following problems:

• 无法正确处理超时。您永远不知道请求是否仍在等待传递或卡在被调用的组件中。


• 响应通常在临时队列上发送。如果客户端在接收响应之前断开连接并且没有明确的时间设置在响应消息上，则临时队列可能会卡在JMS服务器中，直到您重新启动它。


• 拥有中间的JMS服务器大大增加了往返时间并增加了不必要的复杂性。


• JMS提供了一种可靠的传输介质，可以将发送方与接收方分离，但是在请求/回复的情况下，客户端不应该与服务器分离。客户端需要知道服务器是否已启动且可用。

• Impossible to handle timeouts properly. You never know if a request is still waiting for delivery or got stuck in the called component.
• Responses are typically sent on temporary queues. If the client disconnects before receiving the response and there is no explicit time to live set on the response message, the temp queue can get stuck in the JMS server until you restart it.
• Having a JMS server in the middle dramatically increases roundtrip times and adds unnecessary compexity.
• JMS provides a reliable transport medium that decouples the sender from the receiver, but in case of request/reply the client should not be decoupled from the server. The client needs to know if the server is up and available.

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

The only advantage I could think about is that the server can be moved or load-balanced without the client knowing about it, but using UDDI and HTTP load balancer is a better solution.

这篇关于架构师迫切希望在JMS上使用SOAP的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！