[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
First of all let me be clear about something: as I said at the f2f, I'm still of the opinion that the specifications currently use WS-A in a confusing manner, which is why I suggested removing wsa:ReplyTo in favour of something else (wsc:ReplyTo was the placeholder). However, as we've seen there are a number of different ways in which this could be tackled and I think this is an important enough issue that it's worth playing a bit of Devil's Advocate for a while longer. Apologies if this has been covered in the last telecon, but since the minutes haven't been posted yet I can't tell. Alastair Green wrote: > Hi Mark, > > *"One way messages" > > *What does a true one-way message look like? You send it, and you need > know nothing about its passage, delivery or processing thereafter, > other than application-observable effect on application data. In our > context: I send Prepare and get Rollback, Prepared or ReadOnly. I > don't get back a message about the message (a delivery ack): the fact > of delivery or non-delivery has to be inferred by future app-level > interactions (where WS-TX is the app). It can be argued that a one-way message includes delivery ack (it's just not the processing/processed-ack that you get). What you've described is a fire-and-forget message (c.f., vanilla UDP), whereas it's entirely possible to have a one-way message that is reliably delivered (c.f., TCP). The acknowledgement of delivery (or not) of the message is an implementation detail: both are one-way messages in my book because (as you've done, I think) I'd separate the act of delivery from the act of processing - fairly typical for reliable (and group) communications protocols BTW. But that's a slight aside! > > Bob said that one-way messages are rarely seen in the wild, and he > defined them as ones that neither receive a correlated reply, nor a > fault reply (I am paraphrasing an older, very useful summary he posted > 2 or 3 weeks ago). That is exactly the kind of message we need in > WS-TX (and nothing more). > > How do you define such a message using WS-Addressing? By using a > WS-A-defined endpoint, e.g. [source endpoint] that does not imply the > sending of faults or correlated replies. The rules we're interested in > are 3.3 (how to use an EPR). The ones we're not interested in are in > 3.4 (formulating a reply). Avoiding dragging in those latter rules is > where this all started. Not quite true: it was avoiding imposing our own semantics on their use, i.e., overloading the meaning of wsa:ReplyTo, which was leading to confusion. I don't think we can (or should) prevent the use of wsa:FaultTo, for example. > > So, in answer to your question below: "... if WS-A supports one-way > messages (which it does), why not use it?" -- Proposal 2 does exactly > that. It's a pennyweight kind of message, and it requires a > featherweight of WS-Addressing. So I agree, but as I've said in previous emails and at the f2f, we need to be clear in the specifications why we aren't using wsa:ReplyTo. That's not a difficult thing to articulate, but I do think we need to say something. I'll dig out some of my previous emails and can propose some text based on cut-and-paste if necessary. > > *Composition* > > Composition is a means to an end, not an end in itself. Absolutely, but we shouldn't be doing anything here that prevents composition. I want to be able to run secure, reliable and transacted sessions without having to a) introduce vendor specific extensions, or b) raise issues against 1.x versions of the specification, where x> the current minor revision number. > > There is an argument for using WS-Addressing ubiquitously, in order to > facilitate management infrastructure (easy to find the routing > headers), although any management facility that doesn't support > detection of headers from non-standard namespaces is going to be nigh > on useless. Existing implementations would be more radically affected > than necessary if WS-Addressing were removed. And the use of > WS-Addressing in a full request-reply model for WS-C (which I think is > a pointless complication) obviously implies the presence of WS-Addressing. > > Beyond that, we should compose to avoid reinventing the wheel (which > applies here), but we should compose to the minimum. External spec > dependencies are necessary evils, not virtues, because they introduce > sympathy sickness: sloth in creation, and difficulty in evolution. OK, so I think there may be some confusion around the term "composition": I'm not suggesting that this is composition between WS-TX and WS-A, but rather that through our use (or not) of WS-A in WS-TX, we do not impose any implementation restrictions on the use of WS-SX, WS-RX or anything else that may also use WS-A and concurrently. > > WS-RX and WS-SX deal with different domains. I suspect that any > attempt to produce an *X-WS-A composition spec would be a good example > of excessive composition. WS-TX doesn't need the WS-A predefined > faults because of its specific character (ordered conversations, > infinitely retriable message transmission to achieve state > synchronization despite intervening failures). So why mandate their use? Which "WS-A predefined faults" do you mean? > > A smart thing about Proposal 2, as argued by Max and Ian, is that its > silence on WS-A fault traffic allows implementations to pass that > traffic, /if they choose to collaborate to do so/. It also allows that > level of fault to be passed on a transport-level response, if the > sender desires, and again, if the receiver decides to play ball. > Presumably, absent special configuration, a layered WS-Addressing > implementation will tend to play ball. > > (I would not object at all to a statement that a receiver SHOULD play > ball, if the sender either specifies a [fault endpoint] of "anon", or > a non-anon, non-none [fault endpoint], and a [message id]. That would > make things a bit more explicit. I think Max and Ian were keen to hear > the sound of silence, judging from their comments on the call, and > that was codified in a motion that was passed at the meeting.) > > *Faults and messages > * > On "WS-TX fault being a misnomer". I truncated my argument to avoid > too much info in one go. > > There are messages which simply express unusual paths to completion in > a correct implementation, and these are first-class messages that need > to be communicated. Expressions of endpoint incapacity (resource > exhaustion, policy or authorization violations) are examples. > Informational messages ("get status", "status", which WS-TX currently > lacks) would have similar characteristics. If we define a mechanism > for moving this type of message (which we have to), then we can move > all other types of message. You could argue that Invalid State or > Invalid Parameters are similar to some of the WS-Addressing "bug" > faults: conformant implementations shouldn't produce them. But there > is no overhead in supporting their transmission, if we define the > ability to send any WS-TX-level message. WS-A doesn't say what a fault is: [fault endpoint] : endpoint reference (0..1) An endpoint reference for the intended receiver for faults related to this message. So obviously it's assuming a pattern where the receipt (and processing) of a message generates some fault/error, rather than, in our case, the fault/error is a natural part of the protocol (e.g., aborted). I'd like to see us using wsa:FaultTo in cases where it does make sense and I'd say that InvalidState or InvalidParameters are such situations: they are not a natural part of the protocol - they truly are erroneous conditions. > Proposal 2 defines a mechanism that will allow normal, abnormal, > frequent, and infrequent messages to be passed identically, and I > think that is progress. > > Two side notes: > > A) The messages Invalid Parameters, Invalid State or Invalid Protocol > could be returned in response to a "terminal" message. At first glance > that could suggest that terminal messages need to specify [source > endpoint] as well. > > B) I think the one specific (optional) WS-A fault which /is/ relevant > (the "don't bother me again until n seconds later" semantic) should > not be sent as a WS-A fault in our context, but should be sent as a > WS-TX message (it is most relevant for WS-BA). I say this because > there could be a need to send this either as a spontaneous utterance > (the sender is about to quiesce or passivate on application > instructions), or as a "cool it" response to a "pushy" message from > the counterpart. It is not always a reply, therefore. I agree: that could be modelled as a protocol message. Mark. > > Alastair > > Mark Little wrote: >> >> >> 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]