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?
Link: http://www.w3.org/TR/2009/CR-soapjms-20090604/
Advertisement
Answer
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).
On the other hand SOAP is mainly used for request/reply type operations. Implementing request/reply pattern over JMS introduces the following problems:
- 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.
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.