Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Mark Hansen: Best practices on SOAP Faults  RSS feed

 
Sergio da Silva
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 2308
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Mark D. Hansen
author
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!