soapwsdlsoapfault

What's the Fault element declaration in WSDL good for?

In WSDL, the wsdl:Fault element declares the structure of SOAP fault messages the service may return. Or more precisely, it declares the structure of the <detail> element of the SOAP fault message.

Q: What precisely is the purpose of this wsdl:Fault declaration? Does it specify that the SOAP fault message detail MUST have the declared namespace and structure? Or does it specify that the SOAP fault message detail typically has the declared namespace and structure? In other words, if a SOAP service returns SOAP faults with structure of the <detail> element having namespace other than declared in the WSDL, will the message be invalid with respect to the WSDL?

In my opinion, the wsdl:Fault declaration is just a suggestion. A SOAP fault may be returned by another layer than by the service itself (e.g. by a proxy gateway), and this layer may return an arbitrary content in the SOAP fault detail. Hence I deduce that if the service implementation returns a different fault detail than is declared in the WSDL, it should be fine, is it?

Solution

  • I haven't found any explicit answer to my question. But from various hints in various documentation on the internet I deduce that:

    1. Fault message can contain any number of children of the <detail> element. Even such detail structures that are not declared in the WSDL. See e.g. Example 16-6.
    2. Faults declared in WSDL are considered modeled faults, others are unmodeled faults. Modeled faults represent business logic faults, the other faults usually represent runtime/technical faults (see here).
    3. Having multiple elements under the <detail> element does not contradict the WS-I Basic Profile. In particular, the requirement R1002 says:

    R1002: A RECEIVER MUST accept faults that have any number of elements, including zero, appearing as children of the detail element. Such children can be qualified or unqualified.

    So, to sum this up:

    A service should return modeled faults for business errors. The consumers might handle these modeled faults in a special way, for example to retry the request with modified parameters. Unmodeled faults are used mainly for technical errors, validation errors and other runtime errors.

    When you start returning an unmodeled fault instead of a modeled one, you might break the business logic for the consumer application.