[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
One question Bob raises is why we would distinguish infrastructure faults from protocol 'faults'. The answer is the same as the overall justification for proposal 2, which is to get the layering right. In short, layering and composition are brothers. Consider the following examples of errors: 1) The SOAP envelope of a message is malformed or unreadable. 2) The SOAP envelope of a message is readable, but a MustUnderstand=true header was not understood. 3) The entire message is well-formed and understood, but the semantics of the message are for some reason unacceptable to the recipient. The first error must be handled at the binding/profile/transport layer. The message may have included a wsa:MessageId and wsa:FaultTo, but the recipient cannot read it. Consequently, it does not make sense for WS-A or WS-A's SOAP binding to define error handling for this condition. Whether the message is dropped or an HTTP 400 error code is sent or something else happens is largely a matter for the specific binding/profile/transport. The second error is a violation of WS-A semantics. The appropriate result is a WS-A or SOAP fault sent following the rules in the WS-A SOAP binding. While this is an important error that may occur in any higher-level specification/application that uses WS-A and SOAP, it makes little sense to repeat the discussion of how to handle this error in every such specification. The third error occurs at the 'application' level. The appropriate result is an application-level error message or fault signal, following the rules defined by the protocol or MEP that the application is implementing. The authors of that application protocol should define the results in such a case, but - ideally - would not need to even mention the first two classes of error. It should be sufficient to simply refer to a dependency on WS-A / SOAP. The WS-Tx TC is in the position of defining a protocol that operates at this 'application' level with respect to an assumed underlying WS-A / SOAP infrastructure. This is why it is appropriate for us to define and constrain how our own protocol errors are embodied and manifested, but not how WS-A or transport-level errors should be handled. 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. -----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]