[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
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. > > At least the text in Section 4 would have to change: " 4. Coordination Faults WS-Coordination faults MUST include as the [action] property the following fault action URI: http://schemas.xmlsoap.org/ws/2004/10/wscoor/fault The faults defined in this section are generated if the condition stated in the preamble is met. Faults are targeted at a destination endpoint according to the fault handling rules defined in [WSADDR]. The definitions of faults in this section use the following properties: [Code] The fault code. [Subcode] The fault subcode. [Reason] The English language reason element. [Detail] The detail element. If absent, no detail element is defined for the fault. " These are written as "faults" and seem to be mapped to soap faults. Since ws addressing has a fault model, which is designed to work with soap fault model, If we are going to go with the "straw poll" of the last meeting, we really should not use the word "fault" for these "things". If we do not want to use the ws addressing faul model, we should treat these as independent "event reports" which are sent as ws-addressing "requests" rather that ws addressing "replies". Some other term "WSTX State Indications" or "WSTX Event Reports" should be used for these (and the ones in wsat as well) to avoid confusion. If we do not want them to obey the ws addressing fault model, they should not be called faults. Tom Rutt >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 >> >> > > > -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]