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.