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


Are you proposing a Charter change?

On 10/05/06 18:48, Patil, Sanjay wrote:
> If a proposal happens to address other use cases (with no added 
> complexity) beyond the current scope of an issue, that may actually be 
> a better proposal, IMO. For example, it will help implementers in 
> reusing the same underlying technology stack and design/communication 
> patterns in building different solutions. At least that's what I 
> sense as the general preference of the product teams in my company!
>  
> Can we please focus on the technical aspects of how Dug's (or other) 
> proposal addresses the stated problem. I don't think that 
> applicability to problems that are not stated in our scope is a 
> sufficient argument to shoot down any proposal. 
>  
> -- Sanjay
>
>     ------------------------------------------------------------------------
>     *From:* Doug Davis [mailto:dug@us.ibm.com]
>     *Sent:* Wednesday, May 10, 2006 14: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
>     <http://www.google.com/search?hl=en&lr=&q=%22cutting+your+nose+off+despite+your+face%22>.
>
>     -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
>     >
>


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