Re: [xml-dev] Handling Multiple Service Responses

Yes a fair point Noah. When I was talking about this to one of my colleagues they suggested that when returning a SOAP Fault their might be some behaviour implemented by the particular library used (consistent with SOAP Fault processing) which may occur by default and which, in some cases of business errors, may not be what is intended. So his suggestion was, if you want to be sure that that doesn't happen, don't send back a SOAP Fault send back a business error payload where the identification and handling are completely under the control of the recieving client application (h'mmm).

On 22/01/2008, noah_mendelsohn@us.ibm.com <noah_mendelsohn@us.ibm.com > wrote:

Fraser Goffin writes:

> I considered just using 2 response types, success and SOAP Fault,
> but I think it might be better to reserve SOAP Faults to non
> business messages that we don't really want a caller to have to be
> concerned with (other than the fact that the invocation failed).

You are of course free to do this if it meets your needs. I do note that the SOAP Primer [1] 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. "

Note that this primer is non-normative, and I think the above advice goes somewhat beyond what a strict reading of the normative parts of the Recommendation require. Still, it does signal quite clearly that the authors of SOAP intended that SOAP Faults be used to reflect errors insofar as practical.

Noah

[1] http://www.w3.org/TR/soap12-part0/#L11549

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------