[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?
Tom Rutt wrote: I would like to clarify the point I was trying to raise here. Having a policy value (no retrasmission or Ack) would be a sinificant optimization over using a "very large value" for the retransimssion interval. In particular the sender would never retransmit, and the reciever will never send acks. However, the received message ids would be stored on the receiving rm side, for use in duplicate elimination or ordered delivery. Tom Rutt > 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]