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 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. 
>  
>
The text which is currently in the protocol spec regarding DA mentions 
"an Error must be raised at
at least one endpoint".   This sounds like it could be DA specifiec 
protocol behaviour.  We need to
clarify the definitions as part of the other issue resolution :i 049.

Also it depends on the resolution of I006 as well (unless a generic 
policy value exchange is used
to resolve I006).

Tom Rutt

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


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