• Post Reply Bookmark Topic Watch Topic
  • New Topic

Multiple faults in WSDL???  RSS feed

 
Andrew Lawson
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,

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.

Thanks,
Andy
 
Ulf Dittmer
Rancher
Posts: 42970
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In your fault handler, you can get at the SOAPFault object, from which you can extract all kinds of information. This might look like:


There's a useful article here, which may help you get going.
 
Andrew Lawson
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ulf,

Thanks for your reply. I've seen how to get at the fault.

Let me try to explain further what I want to know ...

How should a web service respond if an operation fails and that operation (in the WSDL) has multiple fault messages....

Imagine my (simple) WSDL has the following for an operation:

<wsdl peration name="op1">
...
<wsdl:fault name="fault1"/>
<wsdl:fault name="fault2"/>
</wsdl peration>

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.

Many thanks,
Andy.
 
Ulf Dittmer
Rancher
Posts: 42970
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This error handling seems a little too bare-bones. I would either (mis-)use the fault-string or fault-code as a discriminator, or map the two faults to different Java exceptions.
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd hazard a guess the that solution is along the lines of:


The resulting fault would look something like this:


So in the end it's the child-element contained by the detail element which tells you which fault occurred.

The article (Web services programming tips and tricks: Exception Handling with JAX-RPC) that Ulf has already pointed out seems to use this strategy.
[ February 16, 2006: Message edited by: Peer Reynders ]
 
Andrew Lawson
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ulf, Peer,

Thanks for your replies. Have to admit I was still waking up when Ulf posted his first reply, so thanks again.

Looks like I have found what I needed. Will give this a go.
Andy.
 
Reid M. Pinchback
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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)
 
Andrew Lawson
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks guys for all your help and advice.
Andy.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!