[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 030 - Proposal 2 silence on WS-A faults
Alastair Green wrote: > > > The exception is Endpoint Unreachable/transient. It is useful to > communicate the semantic: "Not yet. Come back in half an hour and I > will be ready for you". This is a feature that BTP included in the 1.1 > revision in November 2004, to reduce network chatter in long-running > transactions. However, this is a semantic that has to be communicated > and understood at the TX level: TX retry strategies cannot always be > depressed to a lower layer, and I believe a new TX message (so-called > "fault") should be created to convey it. > > The TX "protocol faults" are really messages that express unusual but > legitimate paths of conformant execution (or at least, that is the > class of message that we /must/ be able to convey). Examples include > any message that conveys incapacity to process because of receiver > state (which could include security breaches, resource limitations, > desynchronized state shifts). These are not expressions of bugs, they > are first-class protocol messages. The term "fault" is a misnomer, as > I think Tom Rutt has pointed out. That all depends on how you interpret wsa:FaultTo. In other specifications/standards (e.g., the CORBA Object Transaction Service), such erroneous behaviour (still protocol specific messages) is conveyed either through SystemExceptions or UserExceptions. The distinction between the two is really one of signatures on the method invocations, which is then related to likelihood of occurrence: if it can happen at any point, then it's a SystemException, otherwise it's specific to only a subset of the invocations and probably makes more sense to be a UserException. Rather than ignore "WS-A faults" (whatever that means), which I believe is potentially a bad idea from the composability perspective, I'd prefer us to make some explicit statement in the specification to make it clear what we mean and why. > > Nothing in Proposal 2 or in what I have laid out here demands or > assumes HTTP or TCP/IP. The ordered conversation/endless retry model > which underlies WS-TX protocols allows them to operate over highly > unreliable protocols where messages may be lost, misordered, > duplicated, and where no notification of receipt or processing is > received. If acks are available then they can be exploited, but they > are not required. You're right in that if we mandate that all information relevant to the specifications must be conveyed as first-class messages that are tied together or routed/directed via mechanisms prescribed solely within our specifications, then it all works. But I think one of Bob's points is: why? What's the reason for doing so, when WS-A provides support for this which is being built on in WS-RX and WS-SX, to name but two other standardisation efforts. Maybe this is something that was discussed during the last telecon, and is covered in the minutes (where are they ;-)? > I agree that WS-Addressing has no template for "one way message" and > "request reply". It has optional properties and rules for their use, > and these need to be referenced concretely and specifically. But WS-TX > does need one-way messages (and it only needs one-way messages). Which comes back to the question above: if WS-A supports one-way messages (which it does), why not use it? Mark.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]