WSDL-Design: "Soap over JMS" + Fault --> Does it make any sense?

[Kai Wähner]

Hi there,

I just created a WSDL 1.1 interface (manually, i.e. contract-first design), which uses Soap-over-JMS. At the moment I used the WSIF-namespace "http://schemas.xmlsoap.org.wsdl/jms", but maybe this will change to the W3C recommendation "Soap over Java Message Service 1.0". Whatever...

Now my question: The application already works (without any WSDL as interface), a client sends a message to a RequestQueue, and the Server sens the answer to a ReplyQueue. The reply message contains the result (i.e. success) or some error text. So, the communication model is IN --> OUT. Now, the customer wants me to create the model IN --> OUT or FAULT, i.e. I have to add "SOAP Fault" messages.

In my opinion, this does not make any sense:

1) You would send OUT and FAULT to the same Reply-Queue, so why change the current solution? The only thing that changes is that faults would be included within a "<soap:Body><soap:Fault><soap:Reason>ERROR-MESSAGE..."-structure instead of the "<soap:Body>ERROR-MESSAGE..."

2) Bad tool support: E.g. WAS 6.1 does not support this and proposes to use a JMS-Property to define a marker instead of using explicit fault messages. WSIF only offers some custom Fault-WSDL-Extensions for native JMS (i.e. TextMessage / ObjectMessage), but no extensions for SOAP-over-JMS.


So I am pretty sure, that the customer has no usage and cannot generate any clients with a tool, if I alter the WSDL and add Fault messages? Of course, we will discuss it before I change the WSDL, but I would like to hear some other opinions... What do you think?

[R Srini]

Just some thoughts:

-->"The only thing that changes is that faults would be included"
This also makes it a standards-based and SOAP-compliant application. That is the appeal to businesses ... this whole standardization thing. So while you do have a pointthat is what your customer may be looking for.

-->"Bad tool support: E.g. WAS 6.1 does not support this"
Two questions:
1. WAS probably does support SOAP faults. What exactly were you referring to that WAS does not support?
2. I didn't understand the relation of Fault-WSDL-Extensions to JMS. The SOAP message has the Fault element in there somewhere, and the JMS infrastructure guarantees that the SOAP message will get to the destination. What do the SOAP extensions have to do with JMS? I don't understand this: "extensions for SOAP-over-JMS"

-->"customer has no usage and cannot generate any clients with a tool"
The customer can always log the SOAP messages and have an automated tool to periodically inspect and report on faults. The customer can generate a client from the WSDL if its accessible.

[Kai Wähner]

I agree with all your comments, but that is the theory :-(

In practice, several problems occur, for WAS 6.1 support for SOAP over JMS see:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/rwsf_restrict.html

And you are right: SOAP is the message structure and JMS transports it. But there is no standard recommendation yet: WAS 6.1 uses WSIF namespaces to declare the transport within the WSDL, WAS 7 depcrecates this and uses a W3C proposal...

You can generate a client stub from a WSDL, true. But again: That is the theory, in practice several problem occur, e.g. if you need to use JMS...