[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
There was a discussion at the f2f that when the WS-TX specification talks about faults it is actually talking about messages that convey information about the unsuccessful outcome of a transaction, registration attempt etc. If memory serves, the discussion centred on whether wsa:FaultTo should really be meant to "low-level" faults such as "failure to bind", "failure to deliver message" etc.: essentially things that aren't covered by messages defined within WS-TX. It is an arbitrary interpretation of the use of wsa:FaultTo, to be sure and one could argue that if we are to make such a determination, then why not introduce wsc:FaultTo (as well as wsc:ReplyTo)? The more that we remove dependencies on/utilization of WS-Addressing, the more I become worried about the composability of WS-TX. Mark. Bob Freund-Hitachi wrote: > In that case, you might consider removing all references to > ws-addressing, since you seem not to want to deal with it. I am curious > as to what the motivation for dumping it might be. > > Does ws-tx presume that it will always be operating in a soap bound to > http environment? > Will all endpoints be addressable at all times? > Will all transports supported by the spec allow implicit success/failure > status transmission to the sender? HTTP provides a backchannel > mechanism (the equivalent to anonymous replyto) but some don't. > I get the distinct feeling that folks are imagining an environment where > the medium is raw (or shall I say unconstrained) tcp/ip. > > I often hear use of the phrase "one-way" message, and occasionally its > definition is cited as being contained within Ws-addressing (which does > no such thing). At the moment I have no idea exactly what is meant by a > "one-way" message since currently, no bindings that describe it > normatively exist. > > Can these one-way messages generate a fault that might be communicated > to the sender or perhaps to someplace else? > > I do not see the distinction that is being made between "infrastructure" > faults and protocol faults. If a fault of either sort needs to go > somewhere, is that somewhere addressable at the time the fault is > generated or will the soap/http implicit backchannel have gone away > since the fault managed to happen some time after "200/202/204" and your > one chance of returning a single http response entity (as per HTTP 1.1. > > If I were to imagine a soap over scsi environment, there is NO WAY to > send a non-encoded fault message unless you retain the id of the > initiator and establish some sort of correlation mechanism to the > message that caused the fault. > > I think that the happy implementer may be finding that he has a bit of > infrastructure to replicate. > > I have no trouble with tossing the stuff that ws-addressing provides, > provided that it is done with malice and forethought. > > At the moment, I am completely baffled over the motivation behind > proposal 2. > Thanks > -bob > > -----Original Message----- > From: Alastair Green [mailto:alastair.green@choreology.com] > Sent: Friday, April 21, 2006 8:21 AM > To: Ian Robinson > Cc: ws-tx@lists.oasis-open.org > Subject: Re: [ws-tx] Issue 030 - Proposal 2 silence on WS-A faults > > Leaving the cheerful implementer free to never generate [fault endpoint] > > and [message id], and always to ignore them. Good stuff. > > Alastair > > Ian Robinson wrote: > >> Alastair, >> Yes, these 4 points all follow - as you have stated them - from our >> Proposal 2. >> >> Regards, >> Ian Robinson >> >> >> >> >> > > >> Alastair Green >> > > >> <alastair.green@c >> > > >> horeology.com> >> > To > >> Ian Robinson/UK/IBM@IBMGB >> > > >> 21/04/2006 09:54 >> > cc > >> ws-tx@lists.oasis-open.org >> > > > Subject > >> [ws-tx] Issue 030 - Proposal 2 >> > > >> silence on WS-A faults >> > > > > > > > > > > > > > > >> >> >> Ian, >> >> Further to yesterday's call, I want to make sure of my understanding >> > of the > >> deliberate "silence on infrastructure faults" in your Proposal 2. >> >> 1. Sender of a notification message may set values for [fault >> > endpoint], > >> [message id], neither, or both. >> >> 2. [fault endpoint]'s value, if present, is of no concern to WS-TX at >> > all, > >> and can therefore be set to none, anon, or a "real address" at the >> > sender's > >> will. >> >> 3. Receiver of a notification message may send WS-A faults to the >> > fault > >> endpoint using [relationship]; may send to the anon endpoint if anon >> specified as [fault endpoint] value, may choose to refuse to send a >> > WS-A > >> fault at will, may be unable to send a WS-A fault through lack of >> > property > >> values needed to follow the fault-formulation rules in WS-A SOAP >> Binding/Core (absence of either of [fault endpoint] or [message id] >> > has > >> this disabling characteristic).. >> >> 4. Under no circumstances is sender of "protocol messages" (including >> > e.g. > >> InvalidState) to ever use or pay attention to the value of [fault >> endpoint]: it can only use cached EPR or [source endpoint]. >> >> Is this a correct summary of the inferences that you and Max intended >> > to be > >> drawn from silence in this circumstance? >> >> Thanks, >> >> Alastair >> >> >> Alastair Green wrote: >> Ian, >> >> In the document on this issue that I submitted just after the >> > last > >> meeting, I raised four possible solutions: >> >> >> >> > http://www.oasis-open.org/apps/org/workgroup/ws-tx/download.php/17588/20 > 06-04-07.WS-Addressing.and.WS-TX.doc > >> Your proposal 2 is very close to my Option 2 (Minimal Use of >> > WS-A). > >> This is the cleanest and best approach, in my view. >> >> My Option 3 somewhat resembles your proposal 1, but avoids >> > active > >> (non-none) use of [reply endpoint]. I believe that active use of >> [reply endpoint] has always been a source of confusion, and >> > should be > >> avoided in any resolution. >> >> Your Proposal 1 is probably closest to my Option 4, but deftly >> > avoids > >> the MUST use of a [reply endpoint]. I raised Options 1 and 4 as >> "strawmen" to elucidate the spectrum. >> >> * * * >> >> Your Proposal 2, while very close to my Option 2, does not fully >> > deal > >> with all the points that must be tackled. >> >> My Option 2 bullet points were: >> >> >> 2.A) Use either WS-A [source endpoint] or a WS-TX [ws-tx >> > amnesia > >> endpoint] for non-terminal messages >> >> >> 2.B) Do not mandate (but tolerate) presence of [fault >> endpoint] and [message id] on any message. Or, ban use of >> > these > >> two properties. Or mandate that they must be ignored if >> > received. > >> 2.C) Treat WS-TX faults as terminal notifications, which >> > can > >> always be delivered, either to cached EPR or to supplied amnesia >> address. WS-A fault delivery rules (part of reply-processing >> > model) > >> do not apply. >> >> >> 2.D) Set [reply endpoint] to "none", to avoid dragging in >> > "anon" > >> default. This is necessary because infrastructure fault delivery >> might pick up on an anon value in some circumstances. >> >> >> 2.E) Incorporate a statement in the spec making it clear >> > that > >> the reply-processing model of WS-A is not being used. If we >> > choose > >> to process [fault endpoint] and [message id] if supplied by >> > the > >> sender, then Section 3.4 reply-formulation rules may apply to >> faults, and that should be explained. >> >> >> 2.F) Treat WS-A predefined (infrastructure) faults as >> undeliverable (or potentially undeliverable), because >> >> >> i. [fault endpoint] will or may be omitted >> >> >> ii. [reply endpoint] is set to none to avoid use of >> > anon, > >> which is forbidden >> >> >> iii. WS-A does not send faults when [fault endpoint] is >> absent, and [reply endpoint] is set to "none" >> >> >> iv. [ws-tx amnesia endpoint] is unknowable to >> infrastructure (layer violation) >> >> >> >> I believe that your proposal 2 does not yet address bullet >> > points > >> 2.B), 2.E) and 2.F). >> >> * * * >> >> If we are not going down the Option 2/Proposal 2 route, then, in >> > my > >> view, Option 3 is preferable to your proposal 1 in a couple of >> respects. >> >> My Option 3 bullet points are repeated here: >> >> 3.A) Use either WS-A [source endpoint] or a WS-TX [ws-tx >> > amnesia > >> endpoint] for non-terminal messages >> >> >> 3.B) Mandate presence of [fault endpoint] and [message >> > id] on > >> all messages >> >> >> 3.C) Treat WS-TX faults as WS-A faults. WS-A fault delivery >> rules (part of reply-processing model) do apply. All faults are >> always deliverable, because of B). >> >> >> 3.D) Set [reply endpoint] to "none", to avoid dragging >> > in > >> "anon" default. This is strictly unnecessary because the >> > receiver > >> will never use the [reply endpoint], but it does help make it >> clear that [reply endpoint] is not part of the picture, and >> > that > >> the "anon" endpoint will never be used. >> >> >> 3.E) Incorporate a statement in the spec making it clear >> > that > >> the reply-processing model of WS-A is not being used, other >> > than > >> for faults >> >> >> I believe we should avoid the tangle with [reply endpoint] >> altogether: the combination of [source endpoint] and [fault >> > endpoint] > >> properly differentiates the two models for two kinds of >> > messages. > >> It is not made clear that all messages must have message ids. >> > They > >> must, to apply reply-formulation rules for faults, and this >> > should be > >> clearly said. (Equally, if your proposal 1 is adopted, it is >> impossible to follow the reply-formulation rules for "amnesia" >> > unless > >> [relationship] is used, which requires [message id].) If you >> > omit > >> message id then you can legally create an undeliverable response >> which seems unnecessary. >> >> * * * >> >> My point 3.B) does not take account of the possibility of a >> > [fault > >> endpoint] = "none". Your proposal 1 does not address the >> > possibility > >> of a [reply endpoint] = "none" in the amnesia case. Can we not >> mandate that [fault/reply/souce endpoints] are non-anon, >> > non-none > >> unless specifically stated otherwise (e.g. to switch off [reply >> endpoint])? I think we may be in danger of losing an aspect of >> > the > >> original, intended content of the term "physical address" (i.e. >> > a > >> repliable, usable address, not a null value, nor an anon). >> >> *** >> >> Independently of the option chosen, and in line with dropping >> > the > >> term "physical address", the WS-Addressing spec definitions of >> "request-reply" or "one-way" do not exactly line up with what >> > WS-TX > >> is up to. One-way is defined as "no indication of future >> interactions", and that is not true of our messages. >> > "Request-reply" > >> is rather loosely, or flexibly, defined, and it would be hard to >> argue that some of the behaviours we have fall cleanly outside >> > the > >> scope of that term as described in WS-A. The point here is that >> > we > >> use the WS-A properties in a complex and partial way, to >> > describe a > >> bilateral conversation. References to the terms "one way" and >> "request-reply" could simply be avoided in favour of concrete >> descriptions of how WS-A properties are actually used, and >> > direct > >> reference to use of EPRs (WS-A Core 3.3) and reply-formulation >> > (WS-A > >> Core 3.4). >> >> This is most significant in WS-Coordination, where greater >> explicitness than you suggest would be appropriate (specify that >> [reply endpoint] and [message id] must be present on request >> messages, and that 3.4 should apply to all responses, fault or >> otherwise). >> >> *** >> >> I also suggested a procedure for triage of the various >> > sub-points, > >> which I still think would enable the discussion to effectively >> proceed from primary to secondary points in a clear way: >> >> >> 1. Which option? My Option 2/Your Proposal 2 (which have same >> > broad > >> thrust) >> My Option 3 >> Your Proposal 1 >> [any other proposals raised] >> >> >> [If we want to make this simple procedurally, then I would >> > suggest > >> that we vote first on a motion to adopt the thrust of my Option >> 2/your Proposal 2. If that wins then the rest can fall away. >> > That is > >> the big fault line, if you will pardon the pun.] >> >> >> 2. If Option 2 (Your proposal 2) selected: >> >> >> a) [source endpoint] or [ws-tx amnesia endpoint]? >> >> >> b) Permit and optionally process [fault endpoint] + >> > [message > >> id] if supplied. OR >> >> >> Permit and forcibly process [fault endpoint] + [message >> > id] if > >> supplied, OR >> >> >> Pemit but ignore [fault endpoint] and [message id] if >> > supplied. > >> OR >> >> >> Ban [fault endpoint] and [message id]? >> >> >> 3. If Option 3 selected: >> >> >> a) [source endpoint] or [ws-tx amnesia endpoint]? >> >> >> b) Do we set [reply endpoint] to "none", or allow it to >> > default > >> to "anon"? >> >> >> 4. Remove wording on "physical addresses", replace with ban on >> "anon"? [mandate non-none values for [source/fault endpoint]? >> >> >> [Remove refs to one-way or request-reply?] >> >> >> 5. Revisit use of reply-processing model in WS-C? >> >> >> >> Yours, >> >> >> Alastair >> >> >> >> >> >> Ian Robinson wrote: >> >> >> Max and I have been working on some options for resolving >> > issue > >> 030 [1]. >> There has been a lot of good discussion on this issue >> > already; > >> we have >> suggested 2 (different) concrete resolutions that we can >> discuss on the >> call. >> Proposal 1 is closer to the status quo; it retains the use >> > of > >> the >> wsa:ReplyTo MAP for non-terminal notifications but adds a >> requirement for >> terminal notifications to set wsa:ReplyTo to 'None'. >> >> Proposal 2 replaces wsa:ReplyTo with wsa:From to further >> emphasize that >> protocol message are never replies. This proposal also >> classifies WS-TX >> "faults" raised during the agreement protocols (e.g. 2PC) >> > as > >> terminal >> notification messages. >> >> Proposal 1 (Issue30_Propsal_1_WSAT.doc) (See attached >> > file: > >> Issue30_Proposal_1__WSAT.doc) >> >> >> Proposal 2 (Issue30_Propsal_2_WSAT.doc) (See attached >> > file: > >> Issue30_Proposal_2__WSAT.doc) >> >> For either of these proposals, we believe WS-Coordination >> simply needs to >> remove text that is already stated in WS-Addressing: >> >> (See attached file: Issue30_Proposal__WSCOOR.doc) >> >> [1] >> >> > http://docs.oasis-open.org/ws-tx/issues/WSTransactionIssues.xml#i030 > >> Regards, >> Ian Robinson >> STSM, WebSphere Messaging and Transactions Architect >> IBM Hursley Lab, UK >> ian_robinson@uk.ibm.com >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]