Skip to main content

Application-level header faults - do you need them ?

Posted by arungupta on August 1, 2005 at 5:45 PM PDT

WSDL 1.1, section
3.7
defines SOAP header fault as:

The optional headerfault elements which appear inside soap:header and have the same syntax as soap:header)
allows specification of the header type(s) that are used to transmit error information pertaining to the header
defined by the soap:header. The SOAP specification states that errors pertaining to headers must be returned
in headers, and this mechanism allows specification of the format of such headers.

This means that details about any errors pertaining to SOAP header processing
should be transmitted in the SOAP header block. A common use case is to send
mustUnderstand fault details from a service endpoint to the client. All
practical use cases for transmitting headerfault details from service endpoint
to client seem to be handled by the runtime. For instance, WS-I
Sample Application Retailer.wsdl
define headerfaults in in the submitOrder operation, but in my past
experience have never used it. Querying the JAX-WS/JAX-RPC
users list
for "headerfault"
returned no match. A step further, WSDL 2.0 does not even have a headerfault
concept at all.

JAX-RPC 1.1 allows a headerfault to be mapped to a service specific
exceptions iff soap:header is also mapped to a Java method argument.
But just now I mentioned that headerfault does not seem to be a useful construct
from an application perspective.

Do applications really need to throw an exception and know that it is a
header fault ? Let us know your opinion by either posting a comment here or
sending comments here.

Technorati:



Related Topics >>