W3C home > Mailing lists > Public > public-ws-addressing@w3.org > November 2004

Re: Why FaultTo?

From: Mark Little <mark.little@arjuna.com>
Date: Thu, 11 Nov 2004 20:49:36 +0000
Message-Id: <32D64760-3423-11D9-9DDF-00039399DACE@arjuna.com>
Cc: "Mark Baker" <distobj@acm.org>, <public-ws-addressing@w3.org>
To: "Martin Gudgin" <mgudgin@microsoft.com>


Also, atomic transaction systems often have heuristic decisions 
(specific types of faults that occur after the transaction terminator 
has received the official commit/rollback response) delivered to a 
different endpoint. In this case it may be because the originator of 
the commit/rollback response has gone away (legitimately and not 
because of some error in the application), and/or to ensure that a 
separate failure recovery subsystem can deal with them later.


On 11 Nov 2004, at 20:23, Martin Gudgin wrote:

> There are systems out there that do exactly that. For example, in
> message queuing systems, error messages are often sent to a specific
> queue.
> Gudge
>> -----Original Message-----
>> From: public-ws-addressing-request@w3.org
>> [mailto:public-ws-addressing-request@w3.org] On Behalf Of Mark Baker
>> Sent: 11 November 2004 19:19
>> To: public-ws-addressing@w3.org
>> Subject: Why FaultTo?
>> Hi.
>> I'm not grokking the need for FaultTo.  I can't imagine a situation
>> where you'd want a fault response to go someplace different than where
>> a non-fault response was headed.  A fault is a specific type of
>> response, after all.
>> Is there a use case for it that I'm missing?
>> Mark.
>> -- 
>> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Received on Thursday, 11 November 2004 20:50:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:59 GMT