RE: [ws-rx] i050 - Delivery assurances and the protocol

["Marc Goodner" <mgoodner@microsoft.com>]

Tom,

The concern you mention below is addressed by the addition of the Close
function to the protocol. No matter which DA is in effect the RMS can
know the final state.

-----Original Message-----
From: Tom Rutt [mailto:tom@coastin.com] 
Sent: Thursday, October 20, 2005 10:49 AM
To: Duane Nickull
Cc: ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] i050 - Delivery assurances and the protocol

Duane Nickull wrote:

My Comments inline below

> Marc:
>
> I would prefer to have them removed all together as I previously 
> stated. I chose the first option solely on the fact that the DA's 
> violate what I perceive to be the core tenets and values of SOA. 
> Interface based design and SOA infer that abstracting the underlying 
> implementation behind the service is a healthy thing. Services should 
> remain as opaque as possible. The benefits of this have been argued in

> several forums including during the development of the W3C WSA, the 
> UN/CEFACT architecture and several OASIS SOA TC's. Once you start 
> poking holes to see the underlying mechanisms behind a service 
> interface, you start on a slippery slope to tight coupling with 
> intricate dependencies. Keeping services as opaque, clearly defined 
> action boundaries is logical.
>
> I would prefer architecture whereby the service itself only makes 
> visible whether or not the service invocation request succeeded or 
> failed and hides the reasons (including DA's), decisions for such from

> those who are using the service. Exposing DA's to the service consumer

> starts to poke holes in the managed transparency of services.
>
Well, it so happens that the DA level affects the behaviour the consumer

(message sender) perceives.

In particular, with exactly once in order, a received message (which is 
acked by the current protocol)
must be held from delivery until all prior messages have been received 
and delivered. If that sequence
is terminated, those buffered messages will not be delivered. However, 
if the in order DA had not been
asserted, they would have been delivered as soon as received at the RMD.

Tom Rutt

> Duane
>
>
------------------------------------------------------------------------
>
> *From:* Marc Goodner [mailto:mgoodner@microsoft.com]
> *Sent:* Friday, October 14, 2005 12:45 PM
> *To:* ws-rx@lists.oasis-open.org
> *Subject:* [ws-rx] i050 - Delivery assurances and the protocol
>
> 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