Re: NEW ISSUE: Handling arbitrary sets of associated endpoints

Rich Salz wrote:

> You edge up to an interesting question:
>     Do SOAP Faults make sense in other than request/response?

Indeed.

<BlueSkySpeculation relevanceToWgSchedule="low" timesinkPotential="high">

Faults model exceptions in method calls.  These in turn are a reaction 
to the practice of piggybacking error codes onto return values: Function 
f returns a positive integer, so I'll encode error conditions as 
negative values, or, function g returns an int, but I'll appropriate a 
few special ints for error conditions.  These are both kludges aimed at 
implementing a choice type.  F is returning (0 .. maxint)|error1|error2 
... , g is returning something like (minint .. maxint - 
N)|error1|...|errorN.  The overall approach of using choice types 
doesn't work so well in the C family.  There are ways to do it, but it's 
awkward (use a struct with a tag and a union with case statements in C, 
use a visitor pattern in C++/Java).  IMO one reason exceptions have 
proved so popular is because they implicitly provide choice types 
through the ability to throw more than one type of exception and 
dispatch through catch clauses.

On the other hand, XML supports choices natively.  It's no problem to 
have a response type of "value|error1|error2 ..."  This leads to 
something of an impedance mismatch between C++/Java procedures with 
exceptions and XML message exchanges.  SOAP request/reply and WSDL 
in/out resolve this in favor of procedures, by calling out "fault 
messages" (i.e., exceptions) explicitly.  The alternative would have 
been to provide a means to map a response "A|B|C" into one of "A, throws 
B, C", "B, throws A, C", "C, throws A, B" or "D, throws C" where D 
covers A|B, or "void, throws A,B,C" or ...  This might not be as hard as 
it looks from that description, but in any case the tribe has spoken and 
request/reply web services in the world today follow the 
request;reply|fault1|fault2|... pattern.  There is no need to revisit 
the issue in this context.

But what if we're modeling a pure message passing system, where a 
message send just sends a message and there is no concept of exception 
per se, at least not at the application level?  In that case, there may 
be any number of ways of dealing with application level errors, ranging 
from simply dropping the offending message on the floor to initiating a 
complex error-recovery choreography.  Certainly some of these mechanisms 
will look a fair bit like faults.  There will be cases where it's 
legitimate to send an error notification back to the original sender and 
stop processing.  However, unlike the case of modeling procedure calls 
with exceptions, there doesn't seem to be any particular reason to call 
out such a pattern specifically in this context.

In short, I don't think faults make much sense outside 
request/response.  Even in request/response, they're more a 
well-established convenience for binding to languages that use 
exceptions than they are an inherent necessity.

</BlueSkySpeculation>

Received on Friday, 11 March 2005 20:59:46 UTC