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