RE: [ws-rx] Minimalist GetMessage proposal: the anon use case

[Doug Davis <dug@us.ibm.com>]

"Durand, Jacques R." <JDurand@us.fujitsu.com>
wrote on 05/05/2006 02:41:05 PM:
...
> I think it is useful to restate the problems
i089 has to solve. Let 
> me try and see if at least we agree on these:
>  
> 1. being able for an RMS-server to sync-up with
an RMD-client to use
> a sequence, either by making a CS available for pulling or by 
> accepting an offer.

Yes but key in this is that I don't think the RMD-client
should be
required to, somehow, know when a new sequence is
needed by the
RMS-server.  This would require quite a bit of
knowledge on its
part or would limit the choices the RMS-server can
make about its
use of sequences.

> 2. case when dealing with several RMD-clients:
how can the RMS-
> server know which seq ID to use when sending a response to an RMD,
> (e.g. how can a sequence be unambiguously associated with the RMD
> endpoint that offered it). 

Having trouble parsing/undestanding this one - so
let me say this:
the RMS-server should have the same degree of freedom
to determine
when/if/which sequence to use for each message as
it would in the
async cases.

> 3. case when an RMD-client is related to several
AD endpoints, and 
> has to communicate a response to the right AD: This is NOT an RM 
> problem when done within a regular in-out exchange (WS stack takes
> care of that correlation). But when doing GetMessage to pull 
> application messages – or triggering their resending – each one
of 
> these messages within the same sequence may still be destined to 
> different (AD) endpoints, and this correlation context is lost with
> GetMessage.

With Paul's GetMessage, yes, the correlation context
is lost.
With ours it is not.

> Did I miss some?

I wouldn't have necessarily claimed that this list
is the
list of things i089 is trying to solve. Rather this
list contains
some of the problems that come up when trying to solve
the issue.
There are others but I think its important to point
out that these
problems do not occur in our proposal.  Because
we focus using 
an EPR as our correlator we use the process of disambiguating
endpoints to solve i089, rather than differentiating
sequences.
Which is exactly how things work in the async case.
 The RMS-
server does a lot of its decision making based on
where the
message is going - we tried to reuse this logic.  Trying
to use seqID, which is scoped at a higher level than
endpoints,
doesn't give us the level of granulatity needed to
make the
decisions needed when trying to respond to a GetMessage.
Thus you run into all of the problems you listed and
more.

> NOTE: A word on a single sequence spanning several
endpoints: I 
> think at some point we considered several RMD endpoints under the
> same sequence, but moved away from that and decided that even if 
> there are several different destination endpoints for the same 
> sequence, they would all be handled under the same “virtual RMD”
(an
> RMD may be distributed but still considered a single RMD, i.e. share
> same state) so this still means a single sequence goes to a single
> RMD…and can be pulled for and by this RMD alone. Even if each RM
> regular message of the sequence is addressed to different AD 
> endpoints behind.) Do we agree on this?

No. Your argument only holds true for RM protocol
messages, not
application message.  When a sequence span multiple
endpoints I
think its true that any RM protocol message, related
to that
seq, can go to any of those endpoints.  In other
words, its 
safe to assume that since the virtual RMD spans multiple
EPRs,
all of those EPR share the RM state.  The same
can not be said
about the application data or any other data - like
WSA data.

Let's say there are two clients talking to a single
server.  Both clients send a GetQuote at the
same time and
provide a non-anon replyTo.  Clearly, each response
would
go to the appropriate replyTo EPR.  Now, if the
replyTo were
changed to anonymous then I hope we both agree that
it would
be wrong for clientA to get clientB's response.  Now,
if it
turn on RM - are you suggesting that it is now ok
for clientA
to get clientB's response simply because they share
the same
RM sequence?  Nothing in the RM spec would suggest
that and
I think they would be upset if that happened.  If
nothing else
WSA's definition of anon means the response must flow
back on
the same http connect as the request (at least as
long as the
back channel is available).
Sharing RM state can not be interpreted as sharing
any other
state or data.

> Jacques
>  
> 
> From: Doug Davis [mailto:dug@us.ibm.com] 
> Sent: Thursday, May 04, 2006 8:07 PM
> To: ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] Minimalist GetMessage proposal: the anon use
case
>  
> 
> "Durand, Jacques R." <JDurand@us.fujitsu.com> wrote
on 05/04/2006 10:44:03 PM:
> > I believe the challenge of the multiple RMD-clients is more for
the 
> > RMS-server about associating the [offered] sequenceIDs with their
> > respective RMDs. Once this done, Paul has no more problems with
> > subsequent instances of  the in/out pattern: correlation
between in 
> > / out is supported by WS stack as done for non-reliable  exchanges.
> 
> Well, yes and no.  I agree that the challenge is to figure out
which 
> client initiated the GetMessage - which is the same thing as associating
> the passed-in SeqID with the desired RMD/client.  However, doing
that 
> is non-trivial. You seem to be suggesting that WSA can provide some
> help here and it doesn't.  The wsa:RelatesTo can be used to correlate
> a response to a request, yes, but it can not be used to correlate
> the response to an endpoint.  By that I mean, if you send a response
> to the wrong endpoint (wrong client) you can not assume that the client
> will be able to pass that response over to the right client by simply
> looking at the wsa:RelatesTo.  At best all it can do is know
whether or 
> not the message was really something it should have received. If not
> there's nothing it can do - there's no assumption that all clients/RMDs
> share WSA state info and can move messages between each other. 
> 
> > Now he still has a problem with the Notify kind of exchange (out
> > only) as you said before: that’s a use case discussion (how
much do 
> > we want to support that case?). 
> 
> Yup. 
> 
> > Back to the the wsrm:Offer/wsrm:Endpoint, regardless whether
we use 
> > it or not, it appears that the wording in the spec excludes the
use 
> > of this offered sequence for multiple endpoints – at least excludes
> > multiple RMD endpoints for that seq. In that case we can still
> stickto [1 seq 
> > à 1 RMD] and the RMD can safely pull based on sequence Id. 
> 
> Really?  The text in the spec says: 
> This REQUIRED element, of type wsa:EndpointReferenceType as specified
> by WS-Addressing [WSAddressing] specifies the endpoint reference to
> which WS-RM protocol messages related to the offered Sequence 
> are to be sent. 
> 
> How does this restrict us to one endpoint?  This EPR is there
so the 
> server know where to send things like Close/Terminate - not RM-enabled
> app messages.  This EPR is, sort of, the equivalent of the wsa:To
on a 
> CreateSequence, but since in the Offer case there is no CS we needed
> to tell it what the EPR is.  We could have just as easily told
the 
> RMD to use the wsa:ReplyTo from the Offer message but because its
> possible people may want their RM protocol messages to go to somewhere
> else we chose to allow that flexibility by providing yet another EPR.
> (At least that's what I remember about this EPR :-) 
> 
> > Now, what should go in this wsrm:Endpoint element could be the
> > response to the identification of the RMD-client – couldn’t
this be 
> > the same as the EPR you recommend to use with the  */polling
URI in 
> > your proposal? 
> 
> Not sure I follow but I think its because we're disagreeing on what
> this EPR is there for. 
> 
> -Doug 
> 
> 
> > Jacques 
> >   
> > 
> > From: Doug Davis [mailto:dug@us.ibm.com] 
> > Sent: Thursday, May 04, 2006 7:13 PM
> > To: ws-rx@lists.oasis-open.org
> > Subject: RE: [ws-rx] Minimalist GetMessage proposal: the anon
use case 
> >   
> > 
> > Maybe I didn't follow the thread but I thought the problem related
> > to how, when a 
> > client sends a GetMessage, does the server know which client
is sending the 
> > message?  It can't just send any message in the sequence
to any client who 
> > happens to be an RMD for that sequence.  If the RMD spans
multipleendpoints 
> > the server needs to make sure that the messages for clientA go
to 
> clientA and
> > not clientB.  SequenceID alone isn't enough - so what other
> correlation does 
> > Paul's proposal use?  Or is the answer that Paul's solution
only works for 
> > one endpoint per sequence?  If so, we have yet another restriction
> > on the use-cases 
> > that it supports.   
> > 
> > -Doug 
> > 
> 
> > 
> > "Marc Goodner" <mgoodner@microsoft.com> 
> > 05/04/2006 09:22 PM 
> > 
> > To 
> > 
> > Doug Davis/Raleigh/IBM@IBMUS, <ws-rx@lists.oasis-open.org>
> > 
> > cc 
> > 
> >   
> > 
> > Subject 
> > 
> > RE: [ws-rx] Minimalist GetMessage proposal: the anon use case
> > 
> >   
> > 
> >   
> > 
> >   
> > 
> > 
> > 
> > 
> > So how does telling the other side where to send the RM protocol
> > messages not solve the problem you perceive Doug? 
> >   
> > Marc Goodner 
> > Technical Diplomat 
> > Microsoft Corporation 
> > Tel: (425) 703-1903 
> > Blog: http://spaces.msn.com/mrgoodner/ 
> >   
> > 
> > 
> > From: Doug Davis [mailto:dug@us.ibm.com] 
> > Sent: Thursday, May 04, 2006 6:17 PM
> > To: ws-rx@lists.oasis-open.org
> > Subject: RE: [ws-rx] Minimalist GetMessage proposal: the anon
use case 
> >   
> > 
> > If I remeber correctly, that part of the spec just tells the
other 
> > side where to send RM protocol messages to for the Offered sequence
> > - since it otherwise has no idea where they go. 
> > -Doug 
> > 
> > "Durand, Jacques R." <JDurand@us.fujitsu.com>
> > 05/04/2006 07:39 PM 
> > 
> >   
> > 
> > To 
> > 
> > Doug Davis/Raleigh/IBM@IBMUS, <ws-rx@lists.oasis-open.org>
> > 
> > cc 
> > 
> >   
> > 
> > Subject 
> > 
> > RE: [ws-rx] Minimalist GetMessage proposal: the anon use case
> > 
> > 
> >   
> >   
> > 
> >   
> > 
> >   
> > 
> > 
> > 
> > 
> > 
> > That crossed my mind too… 
> > But then the spec seems to rule that case out in case of offered
> > sequences, given the exclusive scoping to one endpoint assumed
by: 
> > wsrm:Offer/wsrm:Endpoint (WD12, Line283) 
> >  
> > Jacques 
> >   
> > 
> >   
> > 
> > 
> > 
> > From: Doug Davis [mailto:dug@us.ibm.com] 
> > Sent: Thursday, May 04, 2006 3:53 PM
> > To: ws-rx@lists.oasis-open.org
> > Subject: RE: [ws-rx] Minimalist GetMessage proposal: the anon
use case 
> >  
> > 
> > I'm a bit lost - too much email on this today :-)  but even
if there
> > as a wsrm:Identifier 
> > in a message that doesn't tell you which client it is since a
> > sequence can span 
> > multiple endpoints. 
> > -Doug 
> > 
> > "Durand, Jacques R." <JDurand@us.fujitsu.com>
> > 05/04/2006 03:17 PM 
> > 
> >   
> >   
> > 
> > To 
> > 
> > "Paul Fremantle" <paul@wso2.com> 
> > 
> > cc 
> > 
> > "wsrx" <ws-rx@lists.oasis-open.org> 
> > 
> > Subject 
> > 
> > RE: [ws-rx] Minimalist GetMessage proposal: the anon use case
> > 
> > 
> > 
> >   
> >   
> >   
> > 
> >   
> > 
> >   
> > 
> > 
> > 
> > 
> > 
> > - The case reliable-in/reliable-out works quite well, provided
the RMS
> > does the correlation between initial sequence and offered seq,
as
> > recommended in 4.2.
> > - The case unreliable-in/reliable-out seems to need the "hint"
you
> > mention in 4.2., plus some other way to offer a sequence than
the CS
> > carrier.
> > 
> > In any case, the many-anonymous(RMD)clients- to-one-(RMS)server
appears
> > to be quite a common case (many users of the same WS instance),
to
> > justify adding back 4.2 in your proposal...
> > 
> > Jacques
> > 
> > -----Original Message-----
> > From: Paul Fremantle [mailto:paul@wso2.com] 
> > Sent: Wednesday, May 03, 2006 11:15 PM
> > To: Durand, Jacques R.
> > Cc: wsrx
> > Subject: Re: [ws-rx] Minimalist GetMessage proposal: the anon
use case
> > 
> > Jacques
> > 
> > You are quite right. This is an interesting situation. One of
the 
> > problems is that we do not in this spec define how messages are
> > allocated to sequences. The IBM proposal simply shifts this problem
to 
> > the EPRId as you point out.
> > 
> > In one of my own early drafts of the proposal I had these words
in 
> > section 4.2, but I removed them for simplicity. However, if they
are 
> > useful they could be added back.
> > 
> > "The WSRM specification does not define the allocation of
messages to a 
> > sequence. In the case of reliable request-response with an anonymous
> > client, the server MAY make a correlation between an incoming
sequence 
> > and an offered sequence. In the case where the request message
is 
> > unreliable, and the client is anonymous, there might not be a
clear 
> > basis to allocate messages to a given sequence. In this scenario
the 
> > client MAY add the <wsrm:Identifier> of the offered sequence
as a SOAP 
> > Header element or elsewhere in the message as a hint to the server."
> > 
> > Paul
> > 
> > Durand, Jacques R. wrote:
> > > Paul:
> > >
> > > Are you sure this works when two different (un-addressable)
clients
> > are
> > > sending an anonymous wsrm:Offer/wsrm:Endpoint to the same
RMS-to-be
> > > endpoint, say for offering sequences S1 and S2? 
> > > The offered sequences S1 and S2 have to be clearly associated
from the
> > > start with the right client-RMD, by the server-RMS.
> > > With an in/out pattern where the in message is not sent
reliably, how
> > > would the server-RMS know if it should use S1 or S2 when
sending the
> > out
> > > message for an in  message of one of the two initiators?
> > > Don't we still face the same issue of distinguishing anonymous
> > endpoints
> > > that IBM proposal tries to address ( with wsrm:EPRid) ?
> > > (Do I miss something?)
> > >
> > > Jacques
> > >
> > > -----Original Message-----
> > > From: Paul Fremantle [mailto:paul@wso2.com] 
> > > Sent: Wednesday, May 03, 2006 12:05 PM
> > > To: wsrx
> > > Subject: [ws-rx] Minimalist GetMessage proposal
> > >
> > > Based on some of the discussions it seemed to me that it
could be 
> > > valuable to produce a completely "minimalist"
GetMessage proposal.
> > >
> > > This is a new proposal that is based on the previous WSO2
proposal.
> > >
> > > The proposal removes the MessageID selector in the GetMessage
-
> > relying 
> > > on simply getting whatever message the server sends back
next.
> > >
> > > Also it removes the section 4.2. Effectively section 4.2
is an 
> > > optimisation: for example to support unreliable-in/reliable-out
a
> > client
> > >
> > > could do a createsequence+offer and never use the outgoing
sequence.
> > In 
> > > this case there is an overhead, which 4.2 aimed to remove,
but this 
> > > simplifies the proposal by focussing on the bare minimum
required to 
> > > support the most common use cases, but still allowing the
other use
> > case
> > >
> > > with a slight overhead.
> > >
> > > I've also included a sample message flow which I hope helps
understand
> > 
> > > the proposal and show the general usage.
> > >
> > > Paul
> > >
> > >   
> > 
> > -- 
> > 
> > Paul Fremantle
> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > 
> > http://feeds.feedburner.com/bloglines/pzf
> > paul@wso2.com
> > 
> > "Oxygenating the Web Service Platform", www.wso2.com