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

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

Funny, that isn't how I read Doug's
response. Maybe you shouldn't be putting words in other people's mouth's.

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

"Marc Goodner" <mgoodner@microsoft.com>
wrote on 05/10/2006 05:18:58 PM:

> So you are advocating using the polling mechanism you are proposing
> for unreliable messaging as well?
>  
> 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: Wednesday, May 10, 2006 2:17 PM
> To: ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] Minimalist GetMessage proposal: the anon use
case
>  
> 
> Kill a simple idea because even though it solves our problems, and
> does so (IMO) w/o the complexity you fear, simply because it _might_
> be used in other situations. wow. 
> -Doug 
> 

> 
> "Marc Goodner" <mgoodner@microsoft.com> 
> 05/10/2006 05:04 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
> 
>  
> 
>  
> 
>  
> 
> 
> 
> 
> Yes but it is not tied to RM in any way besides it’s namespace. That
> is going to lead to it being used for non RM applications. There be
dragons. 
>   
> 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: Wednesday, May 10, 2006 2:05 PM
> To: ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] Minimalist GetMessage proposal: the anon use
case 
>   
> 
> Interesting... a generic polling mechanism should consider things
> like batching.  I suppose it could also do such other basic things
> like examine the wsa:ReplyTo so the polling response could be sent
> to someplace else. All these kinds of things could make perfect 
> sense for a general purpose polling mechanism.  I wonder why
our 
> proposal doesn't do stuff like that?  Could it be because its
not a 
> general purpose polling mechanism?  Could it be that our proposal
> focuses on just one thing, the re-establishment of a lost 
> backchannel? naaa  :-) 
> -Doug 
> 
> "Marc Goodner" <mgoodner@microsoft.com> 
> 05/10/2006 03:59 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
> 
> 
>   
>  
> 
>   
> 
>  
> 
> 
> 
> 
> 
> Well Dave’s mention below is the first I’ve seen. Why is this such
a
> bad idea though? Returning multiple messages to a client after it
> polls a mailbox location certainly seems a reasonable design choice.
> Such an approach could compose well with something like WS-
> Enumeration. Considerations like this need to be taken into account
> in any honest examination of designing a general purpose polling mechanism.
>  
> Of course this, and the other two proposals (from one person), just
> further illustrates to me why doing this in this TC is a bad idea.
> Polling is a general purpose mechanism that should be designed 
> completely, not partially as it is in the three current proposals
> that take that approach. 
>  
> 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: Monday, May 08, 2006 1:15 PM
> To: ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] Minimalist GetMessage proposal: the anon use
case 
>  
> 
> Blimey - who suggested that! :-) 
> -Doug 
> 
> "David Orchard" <dorchard@bea.com> 
> 05/08/2006 03:47 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
> 
> 
> 
>   
>   
>  
> 
>   
> 
>  
> 
> 
> 
> 
> 
> One thing I do not want to see is boxcarring of multiple responses
> for a single "Get*" response.   
> 
> Blimey and crikey, what happens if the connection fails partway 
> through such a boxcarred response.  Argh and yuck. 
> 
> Dave 
>   
> 
> 
>   
> 
> 
> 
> 
> From: Doug Davis [mailto:dug@us.ibm.com] 
> Sent: Sunday, May 07, 2006 6:39 PM
> To: ws-rx@lists.oasis-open.org
> Subject: Re: [ws-rx] Minimalist GetMessage proposal: the anon use
case 
> 
> 
> 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
> >