[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Re: Editorializing on MEPs etc
Hi Max. I agree that overstating things like this is not necessarily a bad thing, but my concern would be that we then have an editorial dependency on the WS-A spec, in that, if that text changes we'd have to update our specs. I'm not bothered either way, to be honest. My original question was just to check why the test was there, and that's been answered. Thanks, Mark. Max Feingold wrote: > Mark: > > I agree with you. I included that text mainly for completeness, given > the earlier discussion concerning the client using relates-to vs. > refParams to correlate the response. I wanted to be clear that both > mechanisms were equally viable. > > As stated today on the call, I am largely ambivalent to the text that > replays WS-A, erring on the side of keeping it in order to facilitate > interop. (As a side note, our experience in general interop testing is > that you can never be too clear about what we expect people's underlying > WS-A implementations to do.) > > -----Original Message----- > From: Mark Little [mailto:mark.little@jboss.com] > Sent: Thursday, March 09, 2006 4:13 AM > To: Max Feingold > Cc: ws-tx@lists.oasis-open.org > Subject: Re: [ws-tx] Re: Editorializing on MEPs etc > > Max, once comment: > > * MUST include the reference parameter elements from the request's > wsa:ReplyTo header in their header blocks. > > > Why do we have to be explicit about this? It's stated in the > WS-Addressing specification anyway. For example, from the 2004/08 > edition, which we still use in the current specs: > > * Each [reference property] and [reference parameter] element > becomes a header block in the SOAP message. The element > information item of each [reference property] or [reference > parameter] (including all of its [children], [attributes] and > [in-scope namespaces]) is to be added as a header block in the new > message. > > > Which seems pretty explicit to me. > > Mark. > > > > Max Feingold wrote: > > >> To be more crisp about what I am proposing, I have created the >> attached document. It contains a proposed division of the text in >> WS-AT's section 9 between WS-C and WS-AT (and eventually WS-BA). >> >> The change markers represent the differences from the status quo for >> each spec's allotted portion. The highlighted text represents >> potentially duplicate text from WS-Addressing that we could consider >> eliding. >> >> Finally, I have included an amended WS-AT coordinator state table with >> > > >> change markers representing the required changes to correctly process >> duplicate RegisterResponse messages. >> >> >> > ------------------------------------------------------------------------ > >> *From:* Max Feingold >> *Sent:* Friday, March 03, 2006 1:47 PM >> *To:* Alastair Green; ws-tx@lists.oasis-open.org >> *Subject:* RE: [ws-tx] Re: Editorializing on MEPs etc >> >> In my view, modeling Register / RegisterResponse using the standard >> WS-A RR MEP is simply the most natural way to represent the pattern. >> By composing with WS-A's definition of the MEP, we simply re-use >> existing art and compose with a pattern that /every WS-A stack /is >> likely to implement anyway. >> >> I think we are overcomplicating the issue by bringing up requester >> correlation as an interop problem. I do not believe it is within the >> scope of interoperability to define how a requester correlates and >> routes a response message. By re-using the WS-A RR MEP, we are simply >> stating the following principles: >> >> * Request messages MUST have a wsa:MessageId. >> * Request messages MUST have a wsa:ReplyTo >> * Response messages MUST have a wsa:RelatesTo built from the >> request's MessageId. >> * Response messages MUST contain any RefParams provided in the >> request's RelatesTo. >> >> This is simply a restatement of WS-A. We may wish to be more or less >> verbose in WS-C when indicating that we conform to this pattern. The >> current text in WS-AT opted for verbosity and re-statement. >> >> Now, from the perspective of interoperability, a conformant server >> simply has to follow these rules when composing replies. A conformant >> client, however, can implement reply correlation as it sees fit. It >> can use the MessageId, its own RefParams or both at the same time. >> It's an implementation detail. Some WS-A stacks will include a >> built-in RR implementation that manages a vector of MessageIds. Others >> > > >> will not, so the WS-C implementer will use some form of manual >> correlation. Either approach is fine and will be interoperable. >> >> Concerning the question of transport-duplicate messages, I think we >> have to (perhaps reluctantly) conclude that they need to be included >> in the state table of any protocol that does not explicitly call out a >> > > >> dependency on an at-most-once transport. Fortunately, as Ian has >> indicated, we can trivially re-use the existing 'deliberate' duplicate >> > > >> handling to deal with transport duplicates. That leaves the question >> of duplicate RegisterResponse in WS-AT, which is not currently handled >> > > >> correctly. >> >> In my view, all this calls for the following actions to resolve this >> issue: >> >> 1. Move the text relating to the RR MEP from WS-AT to WS-C. >> /Remove/ the text that is redundant with what WS-A already says >> wrt message headers. Simply reference the appropriate WS-A text >> or supplement it where it is underspecified. (Remember that >> we're composing with WS-A 2004/08 at the moment.) >> 2. Amend the WS-AT participant view state table to ignore duplicate >> RegisterResponse messages. >> 3. Decide where to put the one-way message definitions. I would >> prefer to keep them in the derived specs, based on the factoring >> principles that we have consistently applied. However, it's >> largely an editorial question so I don't feel too strongly about >> > it. > >> > ------------------------------------------------------------------------ > >> *From:* Alastair Green [mailto:alastair.green@choreology.com] >> *Sent:* Thursday, March 02, 2006 8:49 AM >> *To:* Andrew Wilkinson3 >> *Cc:* ws-tx@lists.oasis-open.org >> *Subject:* [ws-tx] Re: Editorializing on MEPs etc >> >> Andrew, >> >> [I'm going to put this exchange out onto the main list, because I >> think we may need some guidance.] >> >> Aha, a penny has dropped. >> >> Are you are thinking of a situation where a set of RegisterResponses >> are coming back to the same ReplyTo EPR (acting as a reply gateway for >> > > >> several participants)? I have been assuming that we ask for a reply to >> > > >> e.g. the ParticipantProtocolService EPR (or some EPR that maps it >> one-to-one). i.e that the EPR is participant-specific. >> >> In other words, in your view, the message id is a kind of explicit >> universally unique participant id :-) . >> >> If the reply EPR is per-participant then correlation occurs by virtue >> of delivering RR to the per-participant EPR, and message id is >> > irrelevant. > >> If the reply EPR is not, then we can't ignore (or dispense with) the >> message id. >> >> If we expect the reply EPR to incorporate enough information to lead >> us to the participant behind the scenes, then I don't see what the >> message id is doing for us. Explicit participant ids are unpopular in >> this committee, but in this case you'd like to keep one as an >> alternative means of correlation to the use of EPRs? >> >> If that is the case, then you are right: we cannot make the MEP a free >> > > >> choice. >> >> Either way, we may need some kind of additional spec statement. >> >> The rule in my mind has been: that the reply-to EPR supplied in the >> header of Register will allow the reply (RegisterResponse) to be >> unambigously identified with/correlated with the Participant, as >> defined or identified by the value of ParticipantProtocolService EPR >> >> The rule in the existing spec's mind, as it were, is that the >> combination of reply-to EPR and Register message id is sufficient to >> allow the recipient of RR to correlate it with the value of the >> ParticipantProtocolService EPR. >> >> By the way, this discussion is forcing me to read WS-Addressing with >> ever greater care and attention. Two points: >> >> 1) I think that we have to obey a reply-to EPR if we given one. This >> directly relates to the definition of the terminal and non-terminal >> messages, wihich currently (WS-AT ll. 445-446), says that the use of >> the reply-to EPR is optional. >> >> 2) I also think that the WS-A spec is ambiguous (at least) on the >> following point: it could be read to say -- if you are sending a reply >> > > >> you must state the relationship of this response message to the >> stimulant message, i.e. that you have to use relates-to. I'm not sure >> that's what it really means to say, but it does imply it quite >> strongly. This stands at odds with the current WS-A Section 9 rules >> for non-terminal messages. >> >> Yours, >> >> Alastair >> >> >> Andrew Wilkinson3 wrote: >> >> Alastair, >> >> >> >> I don't believe we can make use the RR MEP optional for the >> >> register/registerResponse exchange as it would bring with it unwanted >> >> interop complications. >> >> >> >> Observing that the only real difference between the RR and one-way MEPs >> > is > >> the inclusion of a relates to header in a RR response message imagine >> > two > >> separate implementations, one which uses the RR MEP for register / >> >> register response, the other which uses the one-way MEP. The >> >> implementation using the RR MEP sends a register request and stores the >> > > >> WSA uid of the message which it will subsequently use to correlate the >> >> reply. The implementation using the one-way MEP receives this message >> > and > >> replies, the relatesTo header is not included in the message. The >> > register > >> response message is received but without a relatesTo entry in the >> > header > >> the implementation is unable to correlate it with the register message >> > - > >> at this point we're broken. For this reason I believe that we need to >> > make > >> a definite statement about the use of the RR MEP and, in the interests >> > of > >> not unnecessarily perturbing the specs, that statement should be that >> > the > >> register / registerResponse exchange MUST be conducted using the RR >> > MEP. > >> >> Andy >> >> >> >> >> >> >> >> >> >> Alastair Green <alastair.green@choreology.com> >> > <mailto:alastair.green@choreology.com> > >> 01/03/2006 20:42 >> >> >> >> To >> >> Andrew Wilkinson3/UK/IBM@IBMGB >> >> cc >> >> jharby@gmail.com <mailto:jharby@gmail.com>, Mark Little >> > <mark.little@jboss.com> <mailto:mark.little@jboss.com>, Max Feingold > >> <Max.Feingold@microsoft.com> <mailto:Max.Feingold@microsoft.com>, >> > Thomas Freund <tjfreund@us.ibm.com> <mailto:tjfreund@us.ibm.com> > >> Subject >> >> Re: Editorializing on MEPs etc >> >> >> >> >> >> >> >> >> >> >> >> >> >> Andrew, >> >> >> >> On the procedural point, as already expressed, I agree. >> >> >> >> Your proposal on 2. was my initial inclination. >> >> >> >> I would be more open to it, if we were to make use of RR MEP optional >> >> for WS-C (i.e. that implementers can choose either one-way or RR MEP >> > for > >> the WS-C exchanges). That would be a good move, in my view, as RR MEP >> > is > >> a "Habsburg's tail" (a vestigial organ with no current function: the >> >> extra verterbra that the Habsburg royal family allegedly often >> >> possessed), and would fully justify the positioning of the >> >> terminal/non-terminal definition in the base, WS-C, spec. >> >> >> >> Alastair >> >> >> >> Andrew Wilkinson3 wrote: >> >> >> >> >>> I think that we should be careful not to exceed our remit when >>> > producing > >>> >>> >>> >> >> >> >>> text to address issue 9. If the resolution to issue 007 has exposed a >>> >>> problem with the WS-AT state tables then I believe it would be >>> >>> procedurally correct to raise a seperate issue to address it rather >>> > than > >>> >>> >>> >> >> >> >>> trying to resolve multiple issues under issue 009. >>> >>> >>> >>> I would like to suggest an alternative to Alastair's 2. below and that >>> > > >>> >>> >>> >> is >> >> >> >> >>> that we produce a set of definitions in WS-C that defines use of the >>> > RR > >>> MEP and the one-way MEP including defintions of terminal and >>> >>> >>> >>> >> non-terminal >> >> >> >> >>> messages. While WS-C doesn't use the one-way MEP I believe there's >>> > some > >>> value in attempting to produce a list of commonly used MEPs within >>> > WS-C > >>> which can be referenced by other specs. Whether or not we attempt to >>> >>> >>> >>> >> make >> >> >> >> >>> this list exhaustive is a point for discussion. Again, this is >>> > possibly > >>> something that should be done under a separate issue is it's arguably >>> >>> >>> >>> >> not >> >> >> >> >>> directly related to the RR MEP - issue 011 may well be more >>> > appropriate. > >>> >>> Andy >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Alastair Green <alastair.green@choreology.com> >>> > <mailto:alastair.green@choreology.com> > >>> 01/03/2006 16:51 >>> >>> >>> >>> To >>> >>> Mark Little <mark.little@jboss.com> <mailto:mark.little@jboss.com> >>> >>> cc >>> >>> Thomas Freund <tjfreund@us.ibm.com> <mailto:tjfreund@us.ibm.com>, >>> > Andrew Wilkinson3/UK/IBM@IBMGB, > >>> jharby@gmail.com <mailto:jharby@gmail.com>, Max Feingold >>> > <Max.Feingold@microsoft.com> <mailto:Max.Feingold@microsoft.com> > >>> Subject >>> >>> Re: Editorializing on MEPs etc >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Hi Mark, >>> >>> >>> >>> Sorry, I don't think we can ignore the the duplicate RegisterResponse >>> >>> issue or hope it will be dealt with at the infrastructure level >>> > without > >>> >>> >>> >> a >> >> >> >> >>> bit of extra specification, in WS-AT and WS-BA. >>> >>> >>> >>> To recap: duplicate Registers are deemed to be OK by resolution of >>> > 007: > >>> the Coordinator generates a new EPR for the deemed "new participant". >>> >>> >>> >>> Duplicate registers can arise either by impatient retry, or by >>> > transport > >>> >>> >>> >> >> >> >>> redelivery. The ensuing RegisterResponses will both be delivered to >>> > the > >>> same EPR, so the receiving end can work out that it's received one >>> > twice > >>> >>> >>> >> >> >> >>> (ignore the second one). >>> >>> >>> >>> The rule is: if an RR message is received twice targeted on the same >>> > EPR > >>> >>> >>> >> >> >> >>> then it has to be thrown away. This is the same kind of rule that is >>> >>> expressed in the WS-AT state tables for e.g. duplicate Prepares. Not >>> >>> >>> >>> >> quite >> >> >> >> >>> the same -- the action is not to resend a response, but the fact that >>> >>> >>> >>> >> this >> >> >> >> >>> may happen has to be captured somewhere. >>> >>> >>> >>> As Max points out, the current PV state table assumes that >>> >>> RegisterResponse will arrive once. It doesn't cope with duplicate >>> >>> RegisterResponses. >>> >>> >>> >>> This is only OK if the "throw away" (no-op) rule is stated elsewhere. >>> >>> >>> >>> Here are two implementaton strategies that might be adopted: >>> >>> >>> >>> A. Set a participant state machine to a state of "initial" or >>> >>> "registering", and send Register to C. Keep a vector of all message >>> > ids > >>> for all Registers sent for the current P EPR, with a vector status of >>> >>> "live". If a RegisterResponse arrives whose reply-to value is equal to >>> > > >>> >>> >>> >> one >> >> >> >> >>> of the stored message ids, and the vector is "live" then set the >>> >>> participant state machine to "active", mark the vector as "dead". If >>> > the > >>> >>> >>> >> >> >> >>> RR arrives when the vector is "dead" then ignore the inbound message >>> >>> (no-op). [This is very artificial: I am trying to imagine why and how >>> >>> >>> >>> >> you >> >> >> >> >>> would actually use the values of message id and reply to.] >>> >>> >>> >>> B. Set a participant state machine to a state of "initial" or >>> >>> "registering" and send Register to C. If a RegisterResponse arrives at >>> > > >>> >>> >>> >> the >> >> >> >> >>> current P EPR, and the state machine is in state "registering" set the >>> > > >>> state machine state to "active", and proceed. If an RR arrives when >>> > the > >>> state machine is "active" then ignore the inbound message (no-op). >>> >>> >>> >>> Logically, these are the same state machine. In the first case we have >>> > > >>> created an ancillary mini-machine that uses the Request-Reply MEP >>> >>> features. In the second case the implementation state machine is a >>> >>> >>> >>> >> direct >> >> >> >> >>> reflection of the logical state machine (that does not use the RR MEP >>> >>> features). . >>> >>> >>> >>> In my view the specification describe the logical state machine, and >>> >>> should leave the implementation strategy to the implementer >>> > (especially > >>> >>> >>> >> as >> >> >> >> >>> implementation strategy A is so unnatural). >>> >>> >>> >>> Note that this problem is created by the fact that we are potentially >>> >>> processing a sequence of messages, each with its own message id. There >>> > > >>> >>> >>> >> is >> >> >> >> >>> no concept in WS-A of such a sequence. Therefore, we need to say -- >>> >>> >>> >>> >> here, >> >> >> >> >>> in these specs -- that such a sequence can exist, and how to deal with >>> > > >>> >>> >>> >> it. >> >> >> >> >>> Otherwise it becomes one of those cases where "we all know what we >>> > meant > >>> >>> >>> >> >> >> >>> to say", which is not a good practice. Right now, if you look at the >>> > row > >>> >>> >>> >> >> >> >>> RegisterResponse, column Active, in the 2PC PV of WS-AT you will read >>> >>> >>> >>> >> the >> >> >> >> >>> following: Invalid State/Active. And according to the text immediately >>> > > >>> above, Invalid State means: "send an Invalid State fault" -- which is >>> >>> >>> >>> >> not >> >> >> >> >>> what we want. >>> >>> >>> >>> Either we change the state table, or we write text enforcing an >>> > approach > >>> >>> >>> >> >> >> >>> similar to strategy A. On grounds of consistency, minimalism, and >>> >>> >>> >>> >> freedom >> >> >> >> >>> of implementation choice I would prefer to change the WS-AT state >>> > table. > >>> >>> >>> >> >> >> >>> It's an unfortunate fact that the RR MEP is not doing anything >>> >>> >>> >>> >> fundamental >> >> >> >> >>> here except forcing implementers into a particular (unspecified) >>> >>> behaviour. As I am tired of fighting City Hall, I don't mind acceding >>> > to > >>> >>> >>> >> >> >> >>> the (pointless, harmless) presence of RR MEP, but it isn't a finished >>> >>> >>> >>> >> job, >> >> >> >> >>> unless we address this possibility in one of the two ways I have >>> > raised. > >>> >>> >>> >> >> >> >>> There is nothing in the current spec to stop a faithful implementation >>> > > >>> receiving a duplicate RR and directing it at a state machine that will >>> > > >>> fault it. >>> >>> >>> >>> Furthermore, and taking off from another of your comments: we could >>> >>> introduce a statement into WS-C (there is none there now) which stated >>> > > >>> that duplicate RegisterResponses are discarded. This would be contrary >>> > > >>> >>> >>> >> to >> >> >> >> >>> the resolution of 007 which contains the statement: >>> >>> The manner in which the participant handles duplicate protocol >>> > messages > >>> depends >>> >>> on the specific coordination type and coordination protocol. >>> >>> Even if we introduced a textual statement on discards in the AT and BA >>> > > >>> specs, we are not finished with the problem. The whole >>> > RegisterResponse > >>> row of the AT state table has to cope with the arrival of a duplicate >>> >>> RegisterResponse (late, out of order). At present that row incorrectly >>> > > >>> faults a late duplicate, when in fact the duplicate RR should always >>> > be > >>> thrown away. This strongly indicates that the AT state table is the >>> >>> >>> >>> >> place >> >> >> >> >>> to define all duplicate RR behaviours. >>> >>> >>> >>> I assume that the same will apply to BA. >>> >>> >>> >>> Alastair >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Mark Little wrote: >>> >>> Hi Alastair. Apologies for the delay in replying, but I was traveling >>> >>> >>> >>> >> last >> >> >> >> >>> week. Comments inline ... >>> >>> >>> >>> >>> >>> Hi, >>> >>> >>> >>> This mail is being sent to everyone who is an editor of WS-C, WS-AT or >>> > > >>> WS-BA. >>> >>> >>> >>> I've picked up the AI from the TX TC meeting of 23 Feb to propose (in >>> >>> conjunction with you the editors) a concrete proposal for 009, based >>> > on > >>> the premise that the RR MEP is going to stay. >>> >>> >>> >>> To kick this off, before putting work into writing a concrete change >>> >>> proposal, I want to suggest how to address this in principle. Please >>> > let > >>> >>> >>> >> >> >> >>> me know if you agree, disagree, have amendments to this approach. >>> >>> >>> >>> 1. The RR MEP is primarily used by WS-Coordination: the parts of WS-AT >>> > > >>> Section 9 that deal with that MEP should be moved to WS-C. There are >>> >>> normative references to the effect of Register/RegisterResponse in the >>> > > >>> WS-AT state tables, but these references have nothing to do with the >>> >>> character of these messages as RR MEP messages. >>> >>> >>> >>> Agreed. Are you also proposing updating the state table in WS-C to >>> > cover > >>> >>> >>> >> >> >> >>> the WS-AT case you mentioned above? >>> >>> >>> >>> >>> >>> 2. The one-way MEP is not used by WS-C, but is used by WS-AT and >>> > WS-BA. > >>> I would suggest that we produce text which covers the use of this MEP, >>> > > >>> and reproduce it in both specs separately. Alternative would be to put >>> > > >>> the text in WS-AT and then cross-reference in WS-BA. In this context I >>> > > >>> think it would be easier to cut-and-paste than do an x-ref (section >>> >>> numbers will change etc). >>> >>> >>> >>> I'd go with copy-and-paste too. >>> >>> >>> >>> >>> >>> 3. I would like you to revisit, if you get a chance, the original 009 >>> >>> issue to see what I proposed in terms of wording re terminal and >>> >>> non-terminal. There was a bit of discussion on e-mail between Tom and >>> >>> me, back in November or December, about refining that. I'd like to >>> >>> create consensus between us on what the shape of that rewording should >>> > > >>> be, if rewording is needed. >>> >>> >>> >>> Please note that I believe that the outcome of the resolution of 007 >>> > is > >>> that the RR MEP message-id based correlation need never be used, and >>> > is > >>> therefore fundamentally pointless (if harmless). The rules for >>> > duplicate > >>> >>> >>> >> >> >> >>> processing are partly expressed in the existing WS-AT state tables, >>> > but > >>> need amplification (i..e 007 is not fully resolved, in respect of >>> >>> duplicate Register/RegisterResponse processing). I would welcome >>> >>> contrary comments if anyone believes we need to say anything about the >>> > > >>> use of the message-id/reply-to features beyond what is currently >>> > stated > >>> in WS-AT S. 9, i.e. that they have to be present (even if they need >>> >>> never be used). You could say something like: you can use the reply-to >>> > > >>> to detect duplicates RRs and therefore eliminate the message before it >>> > > >>> hits the P state machine, but in specification terms that is just a >>> >>> restatement of the 2PC PV state table (if it were correctly >>> > specified). > >>> >>> I would have thought that we can ignore duplicate detection and >>> >>> elimination at the level of WS-A: surely that will be taken care of by >>> > > >>> >>> >>> >> the >> >> >> >> >>> "underlying" infrastructure (not trying to impose any specific >>> >>> implementation here, but hopefully you get my point)? >>> >>> >>> >>> Mark. >>> >>> >>> >>> >>> >>> Yours, >>> >>> >>> >>> Alastair >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> >> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]