W3C home > Mailing lists > Public > public-ws-addressing@w3.org > March 2005

Re: NEW ISSUE: Handling arbitrary sets of associated endpoints

From: David Hull <dmh@tibco.com>
Date: Tue, 15 Mar 2005 22:43:48 -0500
To: Savas Parastatidis <Savas.Parastatidis@newcastle.ac.uk>
Cc: Rich Salz <rsalz@datapower.com>, public-ws-addressing@w3.org
Message-id: <4237AB74.2080901@tibco.com>
A few points, in no particular order:

    * I'll note that these comments were clearly marked
      "BlueSkySpeculation", so I'm not going to defend any of them with
      any great deal of energy.
    * I agree that faults, or something materially like them, /are/ one
      way of dealing with errors in the asynchronous world.  My main
      point was that they're not universally applicable there.  For
      example, if I broadcast a one-way message to a gazillion
      subscribers, I may well /not/ want to hear faults coming back. 
      This would be a case where dropping errors on the floor might well
      be an acceptable strategy.
    *  From the brief look I had, I liked SSDL, particularly its
      extensibility story.  Actually demonstrating two or more clearly
      distinct extensions that might otherwise have been treated as part
      of the core makes a pretty convincing case.  One may draw one's
      own conclusions as to how this relates to WSA.

Savas Parastatidis wrote:

>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
>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.
Received on Wednesday, 16 March 2005 03:44:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:28:24 UTC