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

[Christopher B Ferris <chrisfer@us.ibm.com>]

When (frequency) is an implementation
concern. The point is that it knows that it MUST
poll in order to receive messages.

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295

Doug.Bunting@Sun.COM wrote on 05/08/2006 10:43:11
AM:

> Dug,
> 
> On 08/05/06 05:19, Doug Davis wrote:
> > DougB,
> >  Who said reliable notif w/o reliable subscription?
> You did, when you pointed to "problems" with reliable notifications
> which relate only to the case in which the destination system did
not 
> offer a sequence.  That destination system would be unknown only
in the 
> case where it had not subscribed.
> > Its too bad you think things like reliable notifications, 
> > unreliable-in/reliable-out,
> > out-only, allowing an RMS to choose which sequence a message
goes into...
> > are all 'bizarre'.
> > I would point out that most of my questions on paul's proposal
were 
> > simply based
> > on trying to understand how someone would actually implement
it.  Its 
> > interesting
> > in theory to simply say "oh, just have the client send an
Offer and 
> > the server can
> > use that" - when in practice I think I've shown there are
lots of open 
> > questions around
> > using some of the technique Paul has proposed.  And yes,
I agree its 
> > confusing
> Most of those questions, especially about when the client (destination)
> knows to offer a sequence apply equally to your proposal.  When
does the 
> destination know to poll?
> > because this "narrowly scoped" proposal is claiming
to do things its 
> > just not possible
> > to do (as currently defined anyway).  The other proposal,
in my 
> > unbiased opinion :-),
> > is not confusing, it does just one very simple thing - creates
a 
> > backchannel which is
> > at the heart of issue 089. It doesn't try to do anything more
than 
> > that, which is why
> > all of the types of questions that have been raised with Paul's
> > proposal do not
> > exist in ours.  I think it would fairly easy to claim that
Paul's 
> > proposal actually goes
> > well beyond the scope of i089 because if, in the end, his proposal
> > does things like
> > links two sequences then we're no longer just dealing with anon
EPRs.
> Without section 4.2 of Paul's proposal, I don't think that's the case.
 
> Nor do I think the "heart of issue 89" is about a generic
back-channel 
> for any and all messages one system may have queued for another.
> 
> thanx,
>     doug
> > -Doug
> >
> >
> > Doug.Bunting@Sun.COM wrote on 05/08/2006 01:19:20 AM:
> >
> > > This is all very confusing but I think can be summed up
thus: Dug's
> > > proposal does more than WS-RM protocol or the WS-RX TC charter
needs or
> > > allows.  Paul's proposal doesn't do everything Dug
wants.  Did I miss
> > > something?
> > >
> > > As a number of people on the last call noted, most of us
are listening
> > > to an argument with no clear movement toward a compromise.
 I hope Paul
> > > and Dug are having offline discussions to reach a conclusion
the 
> > rest of
> > > us can support.
> > >
> > > If we must implement something on the table now, I prefer
the more
> > > narrowly scoped proposal.  I have yet to hear justification
for the
> > > bizarre scenarios you're describing Dug.  (Reliable
notification 
> > without
> > > reliable subscription, why?)
> > >
> > > thanx,
> > >     doug
> > >
> > > On 07/05/06 18:38, Doug Davis wrote:
> > > > So, for every request message that had a response there
would have 
> > to be
> > > > a GetMessage?  10 requests == 10 GetMessages?
 Doesn't seem 
> > optimal :-)
> > > > Or if you mean that a GetMessage+msgID can pull back
any response 
> > related
> > > > to any request from the client->server seq, then
how long does the
> > > > server need
> > > > to maintain this state info?  It would need to
save every request
> > > > msgID since it
> > > > might appear later on in a GetMessage.
> > > >
> > > > And, even if it did, can it really make any assumption
about that
> > > > message and any
> > > > message flowing in the other direction?  Remember,
under normal
> > > > circumstances an
> > > > RMS could decide, for any variety of reasons, why a
message goes into
> > > > a sequence.
> > > > You seem to be implying that by passing in a msgID
that _all_
> > > > responses related to
> > > > any message associated with the client->server seq
(as correlated by
> > > > this msgID)
> > > > MUST then use this Offered sequence - seems a bit restrictive.
> >  Or, if
> > > > not MUST, then
> > > > it at least implies that it SHOULD, and if not either
of those then
> > > > what other sequence
> > > > can the server use since the client has no way of knowing
when to
> > > > Offer any other.
> > > >
> > > > I really don't understand the point of the Offered
sequence as
> > > > currently specified in
> > > > your proposal. Without any additional correlation info
what can the
> > > > server possibly
> > > > assume its used for?  It doesn't know which endpoint
sent it.  It
> > > > seems like the only
> > > > option available with your proposal is the Offered
sequence of the
> > > > original
> > > > client->server CS msg - and if either of those sequences
> > > > close/terminate early then
> > > > all bets are off.  And I think it links the two
sequences pretty
> > > > tightly - something I thought
> > > > we were trying to avoid.
> > > >
> > > > -Doug
> > > >
> > > >
> > > > Paul Fremantle <paul@wso2.com> wrote on 05/05/2006
01:14:38 PM:
> > > >
> > > > > Actually that was exactly the motivation for allowing
the 
> > GetMessage to
> > > > > include a messageID for relatesTo matching. However,
I am not yet
> > > > > convinced that the use case of an anon client
shared across multiple
> > > > > endpoints is really so useful. I can't imagine
a case in which this
> > > > > would be necessary. The scenarios for a shared
sequence across an
> > > > > endpoint seem to imply some cluster of machines
or corporate 
> > gateway
> > > > and
> > > > > these usually have well defined endpoints. Alternatively,
its 
> > possible
> > > > > that a gateway could do its own correlation of
responses back to the
> > > > > correct endpoint.
> > > > >
> > > > > If you can persuade me that this is a highly valuable
and very
> > > > important
> > > > > scenario I'd be happy to add the <wsa:MessageID>
back into the 
> > proposal
> > > > > which would fix this. However, at the moment I
would lean towards
> > > > adding
> > > > > a warning "here be dragons", that alerts
implementors to this issue.
> > > > > Since the situation is purely initiated by the
"client" then a 
> > client
> > > > > RMS should not initiate an offered anonymous sequence
if it is 
> > not able
> > > > > to distribute the messages to the right endpoint.
> > > > >
> > > > > Paul
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Doug Davis wrote:
> > > > > >
> > > > > > 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 multiple
> > > > > > endpoints
> > > > > > 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
> > > > > >
> > > > >
> > > > > --
> > > > >
> > > > > 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
> > > > >