Architect desperately wants to use SOAP over JMS_问答_开发者

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 J开发者_如何学Pythonava 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/

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.

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

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 out the Apache CXF site for some examples (specific to CXF).

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/

SOAP/JMS and SOAP/HTTP are used for different scenarios albeit with Message Fire and Request/Response. SOAP/JMS is actually terrific for propagating discovered (if required converted) messages to multiple sourecs simply by usage of SoapAction and targetService. The JMS Specs also help in complex routing using the headers.

In Fact, UDDI as well as build servers can, is AND has been used as sources to discover published WSDLs (inline) from massive middleware deployments (Irrespective of engine architecture) as a SOAP/JMS Message to singular SOA Repository Sinks. Very Important in Enterprise Governance

Hence it is of utmost importance for wire tap patterns essentially when asynchronicity is of paramount importance.

SOAP/HTTP and now REST (with the verb noun model) work best for trusted sub-system calls

Image you implemented a frequently used Web-Service, that tends to run ouf threads, while you promised, that no message will be lost.

A Webservice implementation (the server) that runs over a session bean comes with a limited amount of threads (say n active PE in your pool), that may run n web-service request concurrently. What will happen to the n+1 request ?

MRDE, didn't you promised you application owner, that no message will be lost. So the JMS quaranties this functionality. The Webservice skeleton only has to store the data in a queue, and this give reliability also with regard to load-peaks.

The interesting thing about WS over JMS is, that the elapsed time of a running WS-request is quite short, so the computing ressouce will be back immediately to server the next request.

From here :

SOAP over JMS offers an alternative messaging mechanism to SOAP over HTTP. While it is not yet standardized and hence may not be interoperable across platforms, SOAP over JMS offers more reliable and scalable messaging support than SOAP over HTTP. As JAX-RPC and JSR-109 become integral parts of the J2EE standard, enterprise messaging in Web services using SOAP over JMS will become well-established.