SOAP fault required for application error?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

SOAP fault required for application error?

Jim Hollister

In a request-response scenario, does SOAP 1.2 require that a SOAP fault be
returned in the case of an application error? In the non-normative SOAP 1.2
Part 0 document, I find text that says:

“The SOAP fault model (see SOAP Part 1, section 2.6) requires that all
SOAP-specific and application-specific faults be reported using a single
distinguished element, env:Fault, carried within the env:Body element.”

Which indicates that I am required to return a SOAP fault, but the only
text I could find in the normative SOAP 1.2 Part 1 document pertaining to
this says:

“An ultimate SOAP receiver MUST process the SOAP body, in a manner
consistent with 2.5 Structure and Interpretation of SOAP Bodies. Failure is
indicated by the generation of a fault (see 5.4 SOAP Fault). SOAP message
processing MAY result in the generation of a SOAP fault; more than one
SOAP fault MUST NOT be generated when processing a SOAP message.”

I don't see the word MUST in the sentence "Failure is indicated by the
generation of a fault" and I do see the word MAY in the phrase "SOAP
message processing MAY result in the generation of a SOAP fault", so it
appears to me that I'm not required to return a SOAP fault in the case of
an application error.

Am I interpreting this correctly?

Jim Hollister


Reply | Threaded
Open this post in threaded view
|

Re: SOAP fault required for application error?

John Kemp (Nokia-S&S/Williamstown)

Hello Jim,

ext [hidden email] wrote:
> In a request-response scenario, does SOAP 1.2 require that a SOAP fault be
> returned in the case of an application error?

You have touched on what was a controversial point in development of the
SOAP specification. Some would say yes, and others probably no.

> In the non-normative SOAP 1.2
> Part 0 document, I find text that says:
>
> “The SOAP fault model (see SOAP Part 1, section 2.6) requires that all
> SOAP-specific and application-specific faults be reported using a single
> distinguished element, env:Fault, carried within the env:Body element.”
>
> Which indicates that I am required to return a SOAP fault, but the only
> text I could find in the normative SOAP 1.2 Part 1 document pertaining to
> this says:
>
> “An ultimate SOAP receiver MUST process the SOAP body, in a manner
> consistent with 2.5 Structure and Interpretation of SOAP Bodies. Failure is
> indicated by the generation of a fault (see 5.4 SOAP Fault). SOAP message
> processing MAY result in the generation of a SOAP fault; more than one
> SOAP fault MUST NOT be generated when processing a SOAP message.”
>
> I don't see the word MUST in the sentence "Failure is indicated by the
> generation of a fault" and I do see the word MAY in the phrase "SOAP
> message processing MAY result in the generation of a SOAP fault", so it
> appears to me that I'm not required to return a SOAP fault in the case of
> an application error.

In general, it depends on what you call an application error, and how
that relates to what you might call an exception.

I believe (and I did spend quite a lot of time working on SOAP) that the
intent of the SOAP specification is that a SOAP fault is used to
indicate an exception to normal processing, which is considered a
separate thing from an application error, occurring during normal
processing.

So if you are a Java programmer, a SOAP fault might be considered
roughly equivalent to a Java exception - something try-able and
catch-able. That would be something more significant than an application
error such as "validation failed for the phone number field".

>
> Am I interpreting this correctly?

I think so, yes. But I should note that this is my *opinion*, and that
there may be others on this list who have different ones.

In the end, however, the answer that will make sense for you should
largely depend on pragmatic concerns - what do your tools/SDKs support?
Who will you inter-operate with, and what do they expect?

Regards,

- johnk

>
> Jim Hollister
>
>