Re: LC107 Discussion

Francisco Curbera wrote:

>{snip]
>  
>
>Unlike replies, faults are almost never "expected"; a fault is always the
>consequence of an unexpected error, an that is why it is no natural to
>require clients to decide when they "expect" a fault - they would just not
>send a fault-generating message to begin with. So it makes sense both to
>treat them as separate and to maintain the asymmetry between faultTo and
>replyTo, with the current defaulting of the destination of faults to the
>replyTo address when faultTo is absent.
>  
>
I think the implication runs the other way.  In some situations --
notably fire-and-forget non-robust one-way -- a sender can definitely
say it does /not/ expect a fault reply.  In all other cases, the sender
should be prepared to listen to a fault that comes back.  By "fault"
here, I mean "application-level fault", where the receiver got the
message and found it to be well formed, but had a problem with its
content.  In /all/ cases, even fire-and-forget, you can still have
transport-level errors, which are distinct from application-level faults.

For example, a pure one-way operation will never produce an
application-level fault, but a sender trying to send such a message may
supply an invalid address, or try to send during a network failure, or
whatever.

In effect, a receiver that advertises that it may produce a fault is
saying "Even if the message you send is properly addressed to me and
arrives safely, I reserve the right to complain about it."  As far as
I'm concerned, a fault in this sense is just another kind of
application-level message.  The main wrinkle that it adds is that
replies and faults may be addressed separately, which requires a bit of
care when one kind (it doesn't matter which) is directed to the
anonymous address and the other (it doesn't matter which) is directed
elsewhere.

Received on Monday, 23 May 2005 18:08:33 UTC