Mark,
That's what I thought. I first came to this conclusion looking at the
CR (2005-08): as I said, I see no essential difference between the
2004-08 edition and the CR on these points.
I understand the intended behaviour with the so-called notification
messages. The desire is to have an element which is an EPR that MAY be
used as a substitute, and the original reason for this was to avoid a
situation where the responder no longer remembers the EPR given in the
original WS-C R/RR exchange. By extension it can be used to supply
alternate addresses in the course of the coordination protocol
execution. You may recall that BTP 1.0 was bugged in not having an
address for this purpose: I believe that was rectified in BTP 1.1 in
the light of implementation experience.
However, I think that WS-TX is arguably abusing WS-A to achieve this
(laudable) end. I think it might be useful to get the view of the
WS-Addressing group on this point.
In today's call Max made the argument that it's OK to do this because
the message exchanges of e.g the AT protocol are not "replies" in the
WS-A sense, and therefore we have a free hand.
The following text made me dubious about this line of argument:
WS-Addressing, CR, "3. Message Addressing Properties":
'The basic interaction pattern from which all others are composed is
"one-way". In this pattern a source sends a message to a destination without
any further definition of the interaction. "Request-response" is a
common interaction pattern that consists of an initial message sent by
a source endpoint (the request) and a subsequent message sent from the
destination of the request back to the source (the response). A
response in this case can be either an application message, a fault, or
any other message. Note, however, that reply messages may be sent
as part of other message exchanges as well, and are not restricted to
the usual single Request, single Response pattern, or to a particular
WSDL transmission primitive or MEP. The contract between the
interacting parties may specify that multiple or even a variable number
of replies be delivered.' (My emphasis)
To accord with Max's view, one could argue that the contract can
also state that subsequent messages in the exchange are not deemed to
be replies (i.e. that all of this apparatus and constrained behaviour
are optional, available for use, but are not to be used). This is Max's
basic contention, as I understand it.
This is interesting. It implies that a WS-Addressing level
(e.g. in a standalone WS-A implementation) it is not possible to deduce
anything from the presence of a [reply endpoint] property. I.e. if the
supra-WS-A contract (in our case the contract expressed in the WS-AT/BA
specs) states that the exchange has no replies in the strict sense,
then the receiving processor should simply accept and present the
[reply endpoint] to the application. Whereas, if the contract states
that the multi/variable-message exchange uses replies then the [reply
endpoint] must be used in accordance with the rules you cite.
One could then say: the definition of a message that is
part of a request-reply pattern is that it contains, not only a [reply
endpoint] but a [message id] as well. Therefore, by this criterion, the
presence of both is sufficient to establish that we are executing a
request-reply pattern.
In fact this cannot be sufficient: the next outbound
message sent to the [reply endpoint] might be a completely fresh,
spontaneous message (with no contract-inherent relationship to the
prior inbound message). The fact of a reply relationship can only
be established by a supra-WS-A application which understands the
overarching contract, and therefore chooses to embark upon
reply processing (tells the WS-Addressing implementation that the
following message must be treated as a reply to the following message,
identified by the message id already received.
If that is true (which I think it has to be) then the
WS-Addressing spec allows the replying application to automatically
communicate to the initial sender that insufficient information has
been received (no inbound message id) to send a reply (i.e. to send a
fault via the WS-A implementation); and also for the application to
receive an exception from the WS-A implementation if that occurs, or if
the reply [address] property is "none", and therefore no reply is
actually sent. (I don't understand the use case for that last one, but
it seems it can occur).
[Of course, it is now difficult to see how I can ever get
into the situation of sending the no-message-id fault, unless I have
another handle on inbound messages, and can allow the
contract-conscious application to communicate that e.g. message 54 (not
the message id, an internal id) has no message id, and so please send
back a fault. How the original sender is supposed to work out which
message the fault relates to (after all, it has no correlating id to
identify which of its sent messages was faulty) is a bit of a mystery.]
But, and after all that, I am not sure this is the design spirit or
maybe even the letter of WS-Addressing. The [reply endpoint] property
is defined thus:
'[reply endpoint] endpoint reference : (0..1)
An endpoint reference for the intended receiver for replies to
this message.'
This tends to imply that if you send a [reply endpoint] you intend to
receive a "reply". Is reply here a casual term, or does presence of the
property indeed imply we're in the business of sending a reply with all
of the special meaning defined in the sections you quote?
So, my conclusion would be that an opinion from the WS-Addressing group
would be useful. Is there anyone on the WS-TX group with the right
connections to get this considered with the right context?
If this is deemed to be a wrong use of WS-A then the remedy would be
very simple: we put the optional reply address in our messages as a
standard element for all notification messages.
Alastair
Mark Little wrote:
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
|