- From: Savas Parastatidis <Savas.Parastatidis@newcastle.ac.uk>
- Date: Tue, 15 Mar 2005 22:10:16 -0000
- To: "David Hull" <dmh@tibco.com>, "Rich Salz" <rsalz@datapower.com>
- Cc: <public-ws-addressing@w3.org>
Hey David, <snip /> > > 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. > Since faults are messages that carry 'something went bad' semantics, they do have a place in other MEPs apart from request/response. I personally don't see faults as a mechanism to deal with exceptions at the implementation (e.g. procedure/method call exceptions), which if I understood correctly is what your message suggested. Although difficult to support in WSDL, there may still be ways of describing more complex MEPs than request/response. In such MEPs, fault messages may have a place in conveying protocol or application fault semantics. For example, imagine the following MEP that a service may support: msg 1 in -> msg 2 out -> msg 3 in -> (fault msg 1 out) OR (msg 5 out -> msg 6 out -> msg 7 in -> (msg 8 out OR fault msg 2 out)) These are the kind of protocol interactions for a service we can describe with SSDL (http://ssdl.org). The messages are part of a single, multi-message protocol exchange. Regards, .savas.
Received on Tuesday, 15 March 2005 22:16:59 UTC