[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] i050 - Delivery assurances and the protocol
The DAs don't affect interop as they don't show up on the wire. Even with the recent addition of the DAs to policy as a parameter or assertion they still don't impact what goes on the wire between systems. You can not build a system that never delivers a message but does ack them and conform to the protocol whether or not the DAs are in the spec. Please see lines 140 to 150 and 179 to 187 of the most recent draft of the spec (wd-05). -----Original Message----- From: Paul Fremantle [mailto:paul@wso2.com] Sent: Friday, October 14, 2005 2:55 PM To: Marc Goodner Cc: ws-rx@lists.oasis-open.org Subject: Re: [ws-rx] i050 - Delivery assurances and the protocol Marc Counterproductive: Firstly - and this may be minor - is that people will find the spec rather pointless without DAs. More importantly, the aim here is to help people build business systems that interoperate and do something useful. The DAs are important at that level. Otherwise I can simply build a system that never delivers a message, acks 1..latestmessagereceived and declare full spec compliance. Paul Marc Goodner wrote: > The DAs are the detail behind the reason you use WS-RM which is simply > that you want to know that your message got where it was sent. > > Can you explain why not mentioning them would be counterproductive? Is > there something about the way they are described that assists you in > implementing or using the protocol? > > -----Original Message----- > From: Paul Fremantle [mailto:paul@wso2.com] > Sent: Friday, October 14, 2005 1:19 PM > To: Marc Goodner > Cc: ws-rx@lists.oasis-open.org > Subject: Re: [ws-rx] i050 - Delivery assurances and the protocol > > Marc > > While I agree that making the spec have no mention of DAs would simplify > > life, I personally think it would be counterproductive. The DAs are the > fundamental reason for using the protocol. So I think keeping them is a > good idea. I agree making a new deliverable would not help. I like > option two: moving the delivery assurances to the policy spec. > > Paul > > > Marc Goodner wrote: > >> I've been considering i050 [1] and would like to hear what other >> people in the TC are thinking about this. >> >> There were a couple of proposed directions in the issue, one was to >> simply remove all references to delivery assurances and the other was >> to move all mention of them to the policy spec. I would prefer not >> pursuing the third option of a new deliverable. >> >> If we did pursue the first option, to remove all references, that >> would seem to include removing the new parameter/assertion in the >> policy spec as well. From my perspective this seems acceptable. It >> would not cause any further complications in the spec to remove >> mentions of the delivery assurances. The delivery assurances have >> never been manifested in the protocol itself so there would be no >> impact there. Furthermore we already seem to be spinning up new >> issues, like the outstanding AI to close i024 [2], which are tied to >> nailing down details of the delivery assurances. I am concerned that >> exposing the delivery assurance is going to result in further >> complication of the protocol in terms of new features to perform >> operations around them such as i006 [3]. As others have noted exposing >> > > >> these does seem to be a violation of general SOA principles [4] and I >> suspect is why additional issues and protocol complications are >> showing up around them. Finally it is not clear to me what people are >> intending to do by exposing the delivery assurances. The only answers >> to this question I have ever gotten relate to optimizations that in >> terms of the additional complications to the protocol, in terms of use >> > > >> and implementation, don't seem worth it. What would we loose by >> removing the delivery assurances from the spec? Would it make >> implementing or using the protocol more difficult with or without >> > them? > >> If we are going to keep the delivery assurances I think the second >> option makes the most sense, the definitions and all mentions of them >> should be moved to the policy assertion spec. >> >> Regards, >> >> Marc g >> >> 1 i050 spec talks about delivery assurances but does not clearly >> relate them to the protocol >> >> >> > [http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14894/R > eliableMessagingIssues.xml#i050] > >> 2 i024 WS-RX policies not manifested on the wire >> >> >> > [http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14894/R > eliableMessagingIssues.xml#i024] > >> 3 i006 Source based delivery QoS policy assertion >> >> >> > [http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14894/R > eliableMessagingIssues.xml#i006] > >> 4 Discussion point on SOA principles in relation to DA and i006 >> >> [http://lists.oasis-open.org/archives/ws-rx/200510/msg00100.html] >> >> > > > -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair "Oxygenating the Web Service Platform", www.wso2.com Yahoo IM: paulfremantle VOIP: +44 844 986 2874 Cell/Mobile: +44 (0) 7740 199 729 Fax: +44 844 484 7459 paul@wso2.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]