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