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

[Paul Fremantle <paul@wso2.com>]

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