- From: Mark Little <mark.little@arjuna.com>
- Date: Thu, 11 Nov 2004 20:49:36 +0000
- To: "Martin Gudgin" <mgudgin@microsoft.com>
- Cc: "Mark Baker" <distobj@acm.org>, <public-ws-addressing@w3.org>
+1 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. Mark. 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 UTC