[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-tx] Re: Editorializing on MEPs etc
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]