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] 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/ReliableMessagingIssues.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/ReliableMessagingIssues.xml#i024] 
>
>
> 3 i006 Source based delivery QoS policy assertion
>
> [http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14894/ReliableMessagingIssues.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]