[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 030 - Refining Proposal 2
I'd be happy with the amendment. Mark. Alastair Green wrote: > Mark, Max: > > Some comments arising from the recent exchanges, and then a proposal > to refine Proposal 2 (see bold heading *Proposal *towards end of this > mail). > > I agree it is not a layering violation /per se/ to use WS-Addressing > to target messages. There is no difference in principle between using > [source endpoint] (or [reply endpoint]) and [fault endpoint]. In each > case WS-A offers assistance to the upper (app) layer for next/related > message processing. > > The argument that "it makes no sense to send faults to a different > endpoint" is ... well, arguable. WS-Addressing allows faults to be > directed somewhere different than normal responses. I could see an > architecture that centralizes fault reporting for the WS-A level, > while sending normal, good replies to the "real destination". You > could argue that the same might apply for WS-TX faults. However, I > think it is true that the WS-TX interlocutor might appreciate a rapid > notification that it, or its counterpart, are operating bugged, and > this makes the TX counterpart the natural recipient of errors such as > Invalid State. > > I think that Max's argument that the current scheme > "... includes bits of WS-A that complicate or confuse the core protocol > being described." > is a central point. > > The difference between WS-A-layer faults and WS-TX-layer abnormal > messages is that WS-A layer faults require message-id-based > correlation to be targeted correctly, while WS-TX layer error messages > (like all other WS-TX messages) do not. They can avail of EPR > reference parameters, /which are produced and consumed by the > app-layer only/. EPRs provide an application-level mechanism for > correlation, and that is the fundamental model for AT/BA. Their use to > argue and describe the resolution to 007 (handling duplicate > registrations) shows that they can also fulfil all the correlation > needs of WS-C. > > Given this premise: > > 1. Only if we need WS-A-layer faults for correctness, MUST we include > [fault endpoint] and [message id] on all messages. I have argued that > we do not need them, and that is a fundamental premise of Proposal 2. > > 2. The WS-TX protocols do not need WS-A level correlation. We should > not exploit [fault endpoint] to communicate the (non-critical) logic > errors such as Invalid State etc /for this reason/. That is the core > argument for sending WS-AT/BA "faults" in the same way as "normal > messages". It would not be a layering violation to use [fault > endpoint] for abnormal messages, any more than sending a normal > message to [source endpoint] would be a layering violation. Its use > /is/ overweight and redundant (and potentially misleading, as Max > observes). > > 3. The Invalid X faults defined in WS-C must be capable of being sent > in the same way as all other WS-AT/BA messages. > > 4. Given WS-Coordination's use of [reply endpoint] and [message id] > (which is part of what I think is meant by "request-reply") we would > either have to send Invalid X faults using [relationship], or we could > ignore the received [reply endpoint] and [message id], and send them > without [relationship] (abandoning the S3.4 rules in this special > case). In either approach we end up with inconsistent treatment -- > Invalid X messages are sent correlated in WS-C but uncorrelated in > WS-AT/BA, or, faults are sent uncorrelated, but responses are sent > correlated, in WS-C. > > 5. But, we do not need [reply endpoint], [message id] and > [relationship] for WS-Coordination exchanges. We simply need an EPR > target for responses, which can equally well be [source endpoint] as > [reply endpoint]. (Cf. Resolution of 007). Then all WS-C messages > (normal responses or Invalid X messages) would travel to the > initiator's [source endpoint]. In this sense, the WS-C CCC/CCCR and > R/RR exchanges are no more (or less) "naturally" request-reply than > the WS-AT Completion exchanges, for example. The presence of [message > id] and [relationship] creates two mechanisms for registration > correlation when only one is needed, which is a good example of the > current use of WS-A introducing complexity and confusion. > > 6. Invalid X messages may be sent in response to terminal messages, > therefore they need a response address, which should also be [source > endpoint]. > > > *Proposal* > > Therefore, we should move to a simple, uniform model, refining and > restating Proposal 2: > > *All WS-TX messages MUST contain a WS-Addressing [source endpoint] > property whose value is neither [the anon URI] nor [the none URI], > which MAY be used by the receiver to target a subsequent message back > to the sender. All WS-TX messages MUST contain a WS-Addressing [reply > endpoint] property whose value is [the none URI].* > > (Note in passing that the term "physical address" was meant, I > believe, as a synonym for "non-anon, non-none", and that the current > text of Proposals 1 and 2 has narrowed it down to meaning "non-anon".. > The square brackets around [the anon URI] etc indicate: substitute the > proper value or a formal reference.) > > This model would apply to all of the protocols, including WS-C. > > I would further propose that we facilitate delivery of WS-Addressing > SOAP Binding predefined faults, which can be useful in internal and > interop testing, by stating: > > *If the WS-Addressing [fault endpoint] and [message id] properties are > present in an inbound message then the receiver SHOULD use > WS-Addressing Section 3.4 rules to formulate and send any relevant > WS-Addressing SOAP Binding Predefined Fault as a reply. > > *Interop scenario executions should not be deemed to fail if an > implementation fails to generate such WS-A faults. > > These two principles on use of WS-Addressing properties could be > stated once, in WS-C, and would apply to all referencing > specifications. The non-anon, non-none rule needs to be restated in > respect of the coordinator and participant protocol endpoints for > Register and RegisterResponse, also in WS-C, using the following text: > > *This endpoint reference must have a value which is neither [the anon > URI] or the [none URI] > > *to be inserted in the element description for > Register/ParticipantProtocolService and > RegisterResponse/CoordinatorProtocolService. > > Alastair > > > Mark Little wrote: >> >> >> Max Feingold wrote: >>> If the question is why the WS-A mechanism isn't good enough, I believe >>> the answer has already been provided: the semantic embodied by >>> 'Aborted' is similar to the semantic embodied by 'InvalidState' in that >>> both signals are generated and consumed by the same architectural >>> layer. >>> It makes little sense to compose them differently and send them to >>> potentially different endpoints. We have already defined a mechanism >>> for sending the first, so why not use it for the second? This is not a >>> declaration of WS-A inadequacy, but a statement about how our protocols >>> should work. >>> >> >> Actually that is an interesting argument for not using wsa:FaultTo. >> Maybe I missed it in previous emails, or it's in the minutes of the >> last telecon (where are they ;-)? However, taken to the extreme, it >> could then be argued that the same discussion will eventually be had >> by most/all users of WS-A and as a community we should agree that >> wsa:FaultTo is only for WS-A related errors/faults (something which >> the current WS-A specification does not state). >> >> Mark. >> >>> -----Original Message----- >>> From: Bob Freund-Hitachi [mailto:bob.freund@hitachisoftware.com] >>> Sent: Sunday, April 23, 2006 3:14 PM >>> To: Alastair Green; Ian Robinson >>> Cc: ws-tx@lists.oasis-open.org >>> Subject: RE: [ws-tx] Issue 030 - Proposal 2 silence on WS-A faults >>> >>> 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]