[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
Good thing some of us pushed for a use case document so we can figure out what things we think are in/out of scope! Dave > -----Original Message----- > From: Doug.Bunting@Sun.COM [mailto:Doug.Bunting@Sun.COM] > Sent: Wednesday, May 10, 2006 10:55 PM > To: Patil, Sanjay > Cc: Doug Davis; ws-rx@lists.oasis-open.org > Subject: Re: [ws-rx] Minimalist GetMessage proposal: the anon use case > > The subject of our Charter is (basically) whether a use case needs to be > solved within this TC. I /strongly/ object to ruling discussion of this > concern immaterial. > > My basic technical difficulty with Doug's proposal is that most of the > use cases it supposedly solves are out of scope. Paul's proposal is much > more aligned with the work of this TC. It skates close to the edge but > fits in my estimation; Doug's does not fit. > > I could go into lower level details about Doug's proposal but they are > irrelevant given the Charter. > > On 10/05/06 22:43, Patil, Sanjay wrote: > > Hi Doug, > > > > No, I am not proposing any charter change. If I were, I would have made > > it amply clear. > > > > Basically, I am trying to discourage TC members from using spurious > > charter related arguments to drive core technical issues. Taking the > > risk of repeating myself -- I think that the TC members should focus on > > how a proposal solves problems within the scope of the charter and not > > on how the same proposal may be useful for solving problems outside of > > the charter! > > > > -- Sanjay > > > > > >> -----Original Message----- > >> From: Doug.Bunting@Sun.COM [mailto:Doug.Bunting@Sun.COM] > >> Sent: Wednesday, May 10, 2006 19:01 PM > >> To: Patil, Sanjay > >> Cc: Doug Davis; ws-rx@lists.oasis-open.org > >> 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]