Architect desperately wants to use SOAP over JMS

Question

Hello, 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/

Answer 1

Goddammit, I hate working with Architect Astronauts. I feel your pain brother. Do they actually have a actual, functional reason for doing so other than "it's a standards"? Is this decision going to lock them into a specific EE container vendor (say WebSphere)? That is so 2002; very few people have a real need for it; and in fact, SOAP has been pretty much ignored by most practical, successful implementations. Unless they have a real need for more reliability than what it is provided by JMS or SOAP-over-HTTP alone, you are in for a trip.

Check the Apache CFX site for some examples (specific to CFX).

http://cxf.apache.org/docs/soap-over-jms-10-support.html

The rule of thumb would be to really use the bare minimums, and not the full stack. If your architect astronauts still insist in using the whole thing, you might just be walking into a world of pain. Sorry.

---

EDIT:

BTW, what application container will you be using? WebLogic, JBoss, WebSphere? And which web service framework? Apache CFX, Axis?

Architects astronauts will love to say that those are implementation details. Bull. Any decision on a system whose change carriers a great cost (or whose implementation carries significant savings) is an architectural decision. These pretty much dictate how things will be implemented (and what the cost of change will be) so determining early on which you will be using is an architectural decision except with very self-contained systems.

A few more links on this controversial subject:

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 2

I'd say that from an Architect's prospecting the same question would be about why having a 5 layer Internet model, with the 5th being the application when one could simply code the entire application at the socket level. To abstract out the Transport layer (JMS in your case) from what your application produces or consumes (SOA messages) is a good practice for may reasons amongst which independent unit testing, and future migration to other platforms are the first to come to my mind

Answer 3

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.