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