[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Re: Editorializing on MEPs etc
Alastair, you're right in your interpretation of WS-Addr and this came
up during WS-Addr interop. testing.
Section 3.3 in the current 2005 Candidate recommendation is clear on
this too:
3.3 Formulating a Reply Message
This section specifies the WS-Addressing-specific rules for creating a
reply or fault message related to another message.
1.
Select the appropriate EPR:
*
If the reply is a normal message, select the EPR from the
related message's [reply endpoint] message addressing
property. If none is present, the processor MUST fault.
*Note:*
When using the XML Infoset representation, in the absence of
a wsa:ReplyTo element the value of the [reply endpoint]
message addressing property defaults to an EPR with an
[address] property of
"http://www.w3.org/2005/08/addressing/anonymous"; - see
section *3.2 XML Infoset Representation of Message
Addressing Properties* <cid:part1.05010902.05050303@jboss.com>.
*
Otherwise, if the reply is a fault message and the related
message's [fault endpoint] message addressing property is
not empty, select the EPR from that property. If the [fault
endpoint] property is empty, select the EPR from the related
message's [reply endpoint] message addressing property.
Otherwise, if the [reply endpoint] property is empty, the
behavior of the recipient of the related message is
unconstrained by this specification.
*
In either of the above cases, if the related message lacks a
[message id] property, the processor MUST fault.
2.
If the selected EPR's [address] property is
"http://www.w3.org/2005/08/addressing/none"; the reply message is
discarded, if not then populate the reply message's message
addressing properties:
*
[destination]: this property takes the value of the selected
EPR's [address] property.
*
[relationship]: this property MUST include a pair of IRIs as
follows; the relationship type is the predefined reply URI
"http://www.w3.org/2005/08/addressing/reply"; and the related
message's identifier is the [message id] property value from
the message being replied to; other relationships MAY be
expressed in this property
*
[reference parameters]: this property takes the value of the
selected EPR's [reference parameters] property
Mark.
Alastair Green wrote:
> Andy,
>
> I can't resist observing that the id concerned is unique, universal,
> participant-authored, and identifies a particular putative participant
> state machine instance. Quack, quack, quack ;-) . I think we may see
> this particular duck again when we look at WS-BA in more detail.
>
> In principle, I'm resigned to keeping the MEP RR. The perturbation, in
> my view, would be very slight, but as I say, I am resigned. It would
> be simpler (spec and implementation-wise) to have one pattern (one
> way), and the modifications being proposed to the AT state table do
> indeed leave the optional use of RR message ids for correlation as
> something of a Habsburg's tail, but I can understand the desire to
> avoid change.
>
> However, I am more concerned at this point with the issue I raised
> (see thread below) of WS-A compliance with respect to optional or
> mandatory observance of the reply-to element.
>
> There is no essential difference between 2004-08 and 2005-08 versions
> of WS-A (as I read them) on this point. If we are composing against
> 2004-08 for the moment, it is worth looking again at the following
> section of that spec:
>
> [reply endpoint] : endpoint reference (0..1)
> An endpoint reference that identifies the intended receiver for
> replies to this
> message. If a reply is expected, a message MUST contain a [reply
> endpoint]. _The
> sender MUST use the contents of the [reply endpoint] to formulate the
> reply
> message as defined in Section 3.2._ If the [reply endpoint] is absent,
> the contents
> of the [source endpoint] may be used to formulate a message to the
> source. This
> property MAY be absent if the message has no meaningful reply. _If
> this property
> is present, the [message id] property is REQUIRED._
>
> The two underlined sentences are highly relevant for us.
>
> At present (and in Max's proposed reshuffle), the WS-TX specs say two
> things that seem to violate these sentences:
>
> 1. WS-A says the responder MUST use the [reply endpoint], and WS-TX
> says it MAY use it.
>
> 2. WS-A says: if the [reply endpoint] property is present, then
> [message id] is REQUIRED to be present too, whereas WS-TX uses reply
> without a message id, when the RR MEP is not being used (when we are
> working one-way).
>
> Am I misreading WS-A here?
>
> Alastair
>
>
>
> Andrew Wilkinson3 wrote:
>
>>Alastair,
>>
>>In my example the EPR would not be participant-specific, instead the
>>implementation had chosen to rely upon the WSA message id for correlation.
>>I don't agree that this is analogous to a universally unique participant
>>id as this usage of the message id to identify the participant is entirely
>>internal to the participant implementation. That said, I do take your
>>general point.
>>
>>I would find it hard to argue with your view that the message id and the
>>RR MEP are not doing a great deal for us, however there is a lot to be
>>said for not unnecessarily perturbing the specs - WS-C's use of the RR MEP
>>for register / registerResponse works fine as it is.
>>
>>Andy
>>
>>
>>
>>
>>Alastair Green <alastair.green@choreology.com>
>>02/03/2006 16:49
>>
>>To
>>Andrew Wilkinson3/UK/IBM@IBMGB
>>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>
>>01/03/2006 20:42
>>
>>To
>>Andrew Wilkinson3/UK/IBM@IBMGB
>>cc
>>jharby@gmail.com, Mark Little <mark.little@jboss.com>, Max Feingold
>><Max.Feingold@microsoft.com>, Thomas Freund <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>
>>01/03/2006 16:51
>>
>>To
>>Mark Little <mark.little@jboss.com>
>>cc
>>Thomas Freund <tjfreund@us.ibm.com>, Andrew Wilkinson3/UK/IBM@IBMGB,
>>jharby@gmail.com, Max Feingold <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]