File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Web Services and the fly likes Mark Hansen: Best practices on SOAP Faults Big Moose Saloon
  Search | Java FAQ | Recent Topics
Register / Login


JavaRanch » Java Forums » Java » Web Services
Reply Bookmark "Mark Hansen: Best practices on SOAP Faults" Watch "Mark Hansen: Best practices on SOAP Faults" New topic
Author

Mark Hansen: Best practices on SOAP Faults

Sergio da Silva
Greenhorn

Joined: Feb 09, 2005
Posts: 8
Following some recent discussion with some folks, some believe that using SOAP Faults as the mechanism to deal with (application) exceptions is not good because of performance and the fact that once a SOAP Fault is generated there is not a lot of info you can return along with the fault. Say, you have a Web Service X which can fail because of a (business) domain exception, what is the best approach?
1)Create a SOAP Fault which contains the DomainException

2)Design the web service operation to return something like a Status object which would contain code and description as attributes?

Your input is greatly appreciated.
Tks!
Rahul Bhattacharjee
Ranch Hand

Joined: Nov 29, 2005
Posts: 2300
Originally posted by Sergio da Silva:
you have a Web Service X which can fail because of a (business) domain exception.

There is a attribute in Fault that specifies the origin of the fault.Whether if because of some issue with the request or its because of some stuff that the service is not understanding and its suppose to understand that(mustUnderstand) or something wrong while executing the service.

Originally posted by Sergio da Silva:
Create a SOAP Fault which contains the DomainException
Design the web service operation to return something like a Status object which would contain code and description as attributes.

Exceptions and status objects might not be making sense for non java consumers.

Originally posted by Sergio da Silva:
..which would contain code and description as attributes.

I think fault has these features to send code and a short description of the fault.


Rahul Bhattacharjee
LinkedIn - Blog
Mark D. Hansen
author
Ranch Hand

Joined: May 29, 2007
Posts: 61
From a SOA perspective, when an exception occurs in the service processing, you should return a SOAP Fault so that the client can take appropriate action.

A status object is a good idea, in order to provide the client with structured information about the nature of the fault (like a specific type of Java Exception). However, that should be done by using a SOAP Fault to contain the status information.

In addition to the basic faultcode that SOAP specifies, the WSDL specification provides a mechanism for richer fault reporting using the soap:fault element.

The soap:fault element specifies the contents of the SOAP Fault detail element contained in your SOAP Fault message. So, the detail element can contain the status object, and the structure of the status object is specified in the WSDL.

Further, a Java client, using JAX-WS, can take advantage of the soap:fault element in the WSDL. JAX-WS will generate a specific Exception class corresponding to each soap:fault. So, your status object will be mapped to a specific Exception class. And the client application code can then easily obtain information about the nature of the exception that occurred in the service by processing that exception.

SOAP Fault processing is covered in Chapters 6 (client) and 7 (service) of my book. Specifically sections 6.1 and 7.5 - where you will find code examples illustrating what I have described in this post.

Hope that helps!


Mark D. Hansen
Founder and President, AgileIT LLC http://agileitinc.com/
Author of "SOA Using Java Web Services" - http://soabook.com/
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Mark Hansen: Best practices on SOAP Faults
 
Similar Threads
RunTime Exception
Using SOAP fault messages
handling SOAP fault in JAVA
Exception Handling Best Practice
SOAPFault