[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
I agree with a lot of what has been said on this thread already, but I did want to clarify a couple of points, as quickly and succinctly as I can. I'm concerned that Bob has the impression that proposal 2 is effectively 'dumping' WS-A. That is not the intention of proposal 2. In fact, we are attempting to achieve just the opposite, to compose with WS-A in an architecturally appropriate manner. With proposal 2, I think that we have come much closer to an appropriate layering of the more complex MEPs in WS-AT and WS-BA on top of the WS-A / SOAP primitives. I think that the use of WS-A in the WS-Tx status quo commits two different kinds of architectural sins: 1) It takes bits of WS-A that have existing semantics and imbues them with overridden semantics. The use of wsa:ReplyTo in the status quo is an example of this. 2) It includes bits of WS-A that complicate or confuse the core protocol being described. The potential misuse of MessageId/RelatesTo for correlating potentially unrelated notification messages is an example of this. Another is the use of FaultTo to send protocol signals in a different way than other protocol signals. This isn't to say that there is something fundamentally incorrect in the status quo. I've said before that i030 is not about correctness, but about simply making some choices. Nevertheless, both classes of problems, together, have led different readers to draw different conclusions about how the protocols work. That is a warning sign that I have increasingly come to believe that we should heed. Proposal 1 is a least-effort attempt at resolving the first class of problems. However, it does not address the second class of problem; in fact, in some cases it exacerbates them. Proposal 2 is a more extensive attempt to address both classes of problems by creating a clear layering separation between the higher level protocols in WS-Tx and WS-A. I think this approach has benefits in making WS-Tx both easier to understand and implement and less likely to have interoperability problems with diverse implementations. I'll talk about infrastructure faults in another message. -----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]