OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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
> >


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]