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