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


Doug,

What we have is a WSRM usecase of allowing entities behind firewalls to 
partake in the WSRM protocol playing the role of an RMD -- the proposal 
provides a solution for that WSRM usecase. Why is a Charter change needed?

-Anish
--

Doug Bunting wrote:
> 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]