All,
We actually have scenarios we care about where we use Offer and rely on
the relationship between the two sequence that it implies. I would like to get
a chance to explain these scenarios to the list but, unfortunately, this has
not been a good week for so I don’t have anything formal to show. We
would like to postpone voting on this issue before we get a chance to prepare a
description of what we are thinking.
In short though, I think my position is that I’d like to retain
Offer and resolve the issues around it’s semantics. For example the spec
could say something along the lines of:
The RMS chooses to use the optimization because is knows the
“scope” (to use the terminology the TC members use in this thread)
of the EPR’s it uses is safe. To make this obvious, some clarifications
to the spec would be necessary. Something like this (this need word smithing,
what you need to think about is whether you agree with what I’m saying
rather than how I’m saying it):
If a CreateSequence message carries an Offer element and the
corresponding CreateSequenceResponse carries an Accept element then the ReplyTo
EPR of the CreateSequence element SHOULD be used by the RMD for application
messages as well as for the CreateSequenceResponse and TerminateSequence
messages. Note that this implies that the Offer optimization is limited to
cases where the AD’s EPR is the same as the RMS’ EPR.
Thoughts?
From: Doug
Davis [mailto:dug@us.ibm.com]
Sent: Tuesday, January 24, 2006
7:20 AM
To: ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] [i090] Use of
offered sequences unclear in current spec
Paul
Fremantle <paul@wso2.com> wrote on 01/24/2006 09:54:02 AM:
> It has no more or less information than in
the previous case. I am
> guessing again, that most implementations
will associate the offered
> sequence with either the ReplyTo EPR or the
incoming sequence.
Which
replyTo? The CS - which I think might be anon most of the time
for
performance reasons? The ReplyTo on the first message - which might
actually be
the last one received? (And in a non-InOrder DA world would
be processed
last) Is there some kind of EPR comparing
to know when
the ReplyTo of one particular message matches the
ReplyTo EPR
that will be used for the offered sequence? Do ref-p's
matter in
that comparison?
> Those
are
> the logical options based on the lack of any
other information. (I'm
> assuming no out-of-band config). But again
the spec doesn't define this.
> However, the case is just the same in the
case of no offer. The
> Responding RMS (RRMS) has to create a
sequence. I'm guessing that
> without out-of-band information the RRMS is
going to send the CSM to the
> ReplyTo. It still has to decide for which
response messages to use that
> sequence. I don't believe that Offer adds any
further unclarity to this
> part of the spec.
Paul, yes
the RRMS needs to decide which response messages should use the
offered
sequence but the problem with the current spec is that I think
there are
two different ways to interpret the current wording around
offer:
1 - it
applies to all replies regardless of the wsa:ReplyTo on each
individual message
2 - it
applies just to replies targeted to some EPR (see above's Q's)
3 - it
applies to all messages (replies or new msgs) from the RMD to
the RMS (this is actually what it says today, IMO)
The problem
with '1' is that it assumes that all of the wsa:ReplyTo's
are linked
and can handle RM state-sharing. I'm not comfortable with
that
assumption.
The problem
with '2' is that we have no idea which EPR we're talking
about.
The problem
with '3' (aside from what problems '2' has) is that
whichever
EPR we choose may not live long enough to deal with the
non-reply
messages that it encompasses.
Keeping
offer in the spec, like it or not, is going to make
people make
some assumption about when the offered sequence can be
used - if
the RM spec doesn't clear up that assumption then we have
an interop
nightmare. If we clear up the spec and point people towards
interpretation
#2 or #3 and make it clear which EPR we're talking about
then things
might not be so bad, although I'm still not really clear
on how we
choose the right EPR or tell people how to compare them.
-Doug