[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] AS need for ordered delivery?
http://news.bbc.co.uk/1/hi/scotland/2201198.stm Doug Davis wrote: > > Can't help but think that with Chris's beer-googles he may not be in the > best state to make that 'beauty' assessment. > -Doug > > > > *"Yalcinalp, Umit" <umit.yalcinalp@sap.com>* > > 10/28/2005 02:15 PM > > > To > Christopher B Ferris/Waltham/IBM@IBMUS, <ws-rx@lists.oasis-open.org> > cc > > Subject > RE: [ws-rx] AS need for ordered delivery? > > > > > > > > > However, it may be critical for an application to use or not to use a > specific endpoint that supports RM. > > The beauty is always on the eyes of the beholder :-) > > --umit > > > > > ------------------------------------------------------------------------ > *From:* Christopher B Ferris [mailto:chrisfer@us.ibm.com] * > Sent:* Friday, Oct 28, 2005 10:55 AM* > To:* ws-rx@lists.oasis-open.org* > Subject:* RE: [ws-rx] AS need for ordered delivery? > > > I would only point out that this position means that it is clearly not > necessary to the > correct operation of the protocol. > > Cheers, > > Christopher Ferris > STSM, Emerging e-business Industry Architecture > email: chrisfer@us.ibm.com > blog: http://webpages.charter.net/chrisfer/blog.html > phone: +1 508 377 9295 > > "Yalcinalp, Umit" <umit.yalcinalp@sap.com> wrote on 10/28/2005 01:35:30 PM: > > > Doug, > > > > The whole point in having DAs represented is to be provide the > > capability to "view" the contract so that among a set of specific > > endpoints with different DA claims, a client application can make a > choice. > > > > You made an excellent point. There is a very big distinction between > > what the contract is than requiring the RM protocol to define how to > > support the contract. > > > > I am one of those people who is interested in addressing the former. > > This view should NOT be skewed/interpreted as being interested in > > changing the RM protocol or the definition of how to support this > > contract. We have hashed that the requirements on the RM protocol > > and its semantics and I do hope that there is general understanding > > that the tc is not going to address the latter. > > > > Therefore, I find the ongoing discussion on removing DAs, etc not > > very useful. The TC has made a decision to include DA in the spec > > with the understanding that the goal is to specify the claim about > > DA, nothing more nothing less. > > > > Lets work with that. > > > > Thanks, > > > > --umit > > > > > > > > > > From: Doug Davis [mailto:dug@us.ibm.com] > > Sent: Thursday, Oct 27, 2005 7:36 PM > > To: ws-rx@lists.oasis-open.org > > Subject: RE: [ws-rx] AS need for ordered delivery? > > > > > +1 > > > > Short version: remove DAs entirely from the spec > > > > Longer version: I think Duane's comparison with TCP is a very good > > one. It illustrates how the upper layer treats the transport as a > > block box and that works well. IMO, the RM layer should be a black > > box as well (for this discussion anyway :-). If a layer above TCP > > messes up the order of the packets before it actually reaches the > > TCP code then they're hosed. If the layer above the RMS (meaning > > the AS) messes up the order of the soap messages before it reaches > > the RMS then they're hosed. For that reason, the > > interactions/contract between the AS and the RMS are out of scope of > > this spec. Likewise, for the most part, I think the > > interactions/contract between the RMD and the AD are out of scope > > too - with one exception, I do agree that the AS/RMS may want to > > know what the contract is - if for nothing else to know whether or > > not it wants to use that endpoint. However, knowing what the > > contract is very different than requiring the RM protocol to define > > how to support that contract. > > > > That last sentence could lead one to believe that I might be ok with > > specifying the DA in Policy and adopting Anish's proposal for issue > > 6, which allows the RMS to specify the DA on the CreateSeq. And to > > be honest I actually could go for that if I thought this entire DA > > discussion would end with that - but I doubt it would :-) I fear > > that any mention of DA in the spec would cause this discussion to > > continue to be rehashed over and over. So, unless we can find the > > right text that would allow us to do what Anish is proposing w/o > > reopening this can of worms again my current leaning is to just > > remove it from the spec and let it be a problem for the Policy folks > > to work out. After all, since it doesn't effect the protocol it > > just becomes a matter of advertising and negotiating the QoS levels > > of a service - which is a much bigger problem than our one little spec. > > > > thanks, > > -Doug > > > > > > > > > > > "Duane Nickull" <dnickull@adobe.com> > > 10/26/2005 07:53 PM > > > > To > > > > "Jacques Durand" <JDurand@us.fujitsu.com> > > > > cc > > > > <ws-rx@lists.oasis-open.org> > > > > Subject > > > > RE: [ws-rx] AS need for ordered delivery? > > > > > > > > > > > > <SNIP/> > > <JD> I notice though that TCP is designed - or implemented at least > > - so that the upper layer does not have to worry about packet > > reordering or numbering: so in effect TCP stacks interpret InOrder > > the same way we do so far in WS-RM: it is a black-box. Don't you > > prefer that to letting the upper layer "figuring it out" with > > packets numbers on its hand...? > > <SNIP/> > > Yes – that is exactly what I am implying. A RMD is a black box that > > will be able to completely recreate the original stream as it was > > intended to be received based on a solid base WS-RX protocol. What > > it does from that point on is discreet. I am not in favor of > > specifying anything about the AD or any other upper layer. > > > > My gut instinct is that DA’s should be removed all together from this > work. > > > > D
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]