Last week, we had the author of TDD for a Shopping Website LiveProject. Friday at 11am Ranch time, Steven Solomon will be hosting a live TDD session just for us. See for the agenda and registration link
I understand that an operation within a WSDL file can define more than one fault message.
So, how would a client calling the web service identify the fault message that had been returned to him? I can see that the WSDL standard talks about a "name" attribute associated with the fault, but I can't find any examples showing the returned <fault> messages.
Has anybody seen anything on this, or got any ideas?
To return messages to the client, we thought of adding an "unqualified" attribute to the <detail> part of the <fault> message to identify the fault using some form of id. The WS-I basic profile says that a received should accept the message. I'm pretty sure this would work and not break with the standards ....
Any comments, suggestions etc. would be appreciated.
Now if that operation fails, I should respond with a fault message. What I'm unsure of, is how the client would know from that fault if it was "fault1" or "fault2" that the operation returned.
I have found nothing clear on this. I proposed using an attribute on the <detail> part of the message e.g. <detail fault="fault1"> ... As far as I am aware my soap fault would still be well-formed and conform with standards.
What I'd like to know if anybody else has seen this and how they got around it.
If you are using JAX-RPC tools to create the WSDL instead of doing it by hand, you might see some other options. For example, using Weblogic's ant tasks you can create server and client equivalent versions of a Java exception class. That way identifying your fault is no different than identifying any Java exception.
The only trick to it (and I'm pretty sure this is a Weblogic-specific issue with its JAX-RPC implementation) is that you may have to add Javabean-style properties directly to your exception class if you want to pass along other information, like the message or an error code. Even the standard exception message won't get shipped through SOAP unless you go to the extra effort of making it a property of the most-derived class you will be feeding to the Ant tasks generating the WSDL and codec.
Originally posted by Reid M. Pinchback: If you are using JAX-RPC tools to create the WSDL instead of doing it by hand, ... That way identifying your fault is no different than identifying any Java exception.
That's true even if you create the WSDL manually; you just catch a Java exception. WSDL2Java will still do the mapping for you. The following code was based on the code generated by WSDL2Java. The fleshed out generated service template:
The client using the generated code:
The WSDL file FaultGenerator.wsdl
SOAP response for type 1 fault (XML Schema SimpleType)
Apparently Axis likes to sneak in additional information in the fault detail: ns2:exceptionName and ns3:hostname. Also the first detail child element is named after the fault�s part name.
SOAP response for type 2 fault (XML Schema ComplexType)
For a complexType the first detail child element is named after the fault part�s element name.
SOAP response for type 3 fault (extended XML Schema ComplexType)
Oh, oh. Something went wrong here. That first detail child element should have been <ns1:accountInsufficientFundsFault>. And the client stub promptly complains about that: "org.xml.sax.SAXException: Invalid element in com.example.InsufficientFundsFault � account". Well, maybe some time in the future. If you don�t extend/inherit you are fine.
SOAP response for type 4 fault (distinct XML Schema ComplexType)