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] DA and Protocol: is the date over?


Jacques Durand wrote:

> Chris:
>
>  
>
> Your keep referring to "The Protocol" in a (kind of axiomatic) way 
> that leaves me with the uneasy feeling that you are more willing to 
> adjust the "end" to the "means", rather than the opposite. Now I 
> believe I can guess some of the concerns behind this approach, namely 
> to isolate and encapsulate the RM basics in the protocol layer, in a 
> way that makes it native and pervasive to the WS infrastructure, while 
> making all sorts of DA enforceable above - and orthogonal to - this 
> layer (am I right?). If so, that should be clearly stated as one of 
> our requirements - or use case.
>
>  
>
> Assuming the following, that seems to be shared by many in the TC:
>
>  
>
> 1- AtMostOnce, AtLeastOnce, InOrder, and various combinations of 
> these, are all legitimate DAs that we are chartered to support.
>
>  
>
> 2- We cannot presume of the value of either one of these DA 
> combinations, precisely because each of us has his/her own ideas on 
> this, as Dan said. (Maybe in last resort we'll have to make some tough 
> choice, but if so these will be caused by technical issues, and I 
> don't think we are at this point yet.)
>
>  
>
> Let me advance a slightly different perspective on the protocol, and 
> some idea that I pretend can help all of the above:
>
>  
>
> - the common, base RM protocol that supports ANY of these DAs, is in 
> fact the sequence numbering and nothing more. This protocol is 
> designed to also support AtMostOnce alone: there is a huge benefit in 
> scalability and performance when checking for duplicates based on 
> sequence numbers and intervals (as opposed as in a list of messageIDs, 
> which does not scale well). So I see great value in the whole sequence 
> management thing even in the bare-bone no-Ack mode Doug mentioned (to 
> mention the ordering case).
>
>  
>
> - We know that the Ack and resending mechanism is not without overhead 
> nor implementation cost. That is why it can be tuned in so many 
> different ways: it can make a huge difference whether SequenceAcks are 
> sent back for every message, or every hour, or at midnight daily. Same 
> for the resending policy. So that is where RM policy assertions come 
> handy: I assume they will be used for configuring *both* sides.
>
>  
>
> - This protocol tuning will not just be based on network 
> considerations: it will also depend on application needs. For some it 
> may be acceptable to get a SeqAck every day, for some others it won't. 
> Serving this purpose, I notice that these policy assertions can be 
> attached at port level, meaning that the tuning of the protocol can be 
> done based on which service is being invoked (or say, URL used).  So I 
> see no harm in having a policy assertion attached to a service, that 
> says "No Acks served here, so forget about retries", for the same 
> reasons one would say "Acks every hour only".
>
What would happen with the existing WS-RM protocol if the policy for ack 
inteval was set to <a very large number>.  What would the
behaviour of the receiving and sending RM processor?

I think that having "no ack" as a policy is a more direct way of setting 
the ack interval to infinity, to meet the needs of some DA.

>  
>
> - Now, whether we consider these tuning parameter as DA attributes or 
> not, is another issue. Although I'd prefer to see them related somehow 
> (SLAs often go down to network QoS level) I am not opposed to a clear 
> separation  of concerns. After all, I'd argue that even AtLeastOnce 
> makes sense regardless of the protocol tuning and even when the latter 
> is no-Ack ! (the requirement to raise an error in case of delivery 
> failure may be the most important aspect of it in some cases).
>
>  
>
> - that is why I believe we do not need to require RMS to be able to 
> understand Acks and do resending in order to conform to this spec: 
> only to do proper sequence management, which still has great value for 
> some DAs.
>
>  
>
> - So we could have two sides on an RM agreement: (1) the DA level, 
> that may be decided (and possibly published) by the deployer of a WS 
> based on its application semantics and on what the underlying platform 
> supports, (2) the protocol tuning level, which may be imposed or 
> restricted by the IT folks managing the server - and in many cases the 
> WS deployer will just have to live with it, though if lucky will have 
> some elbow room here too (in both ways: IT in high volume centers may 
> be happy to be told half of their hosted WS don't need to send Acks... 
> that can help them better support other policy assertions that do.)
>
>  
>
> Thoughts?
>
>  
>
> Jacques
>
>  
>


-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]