Re: [ws-rx] Proposed NEW ISSUE: Alignment and Refinement of Definitionsfor Delivery Assurances

[Tom Rutt <tom@coastin.com>]

Christopher B Ferris wrote:
comments In line.

General comment, I agree we shall always have the protocol requiring 
guaranteed receipt.

My point it only that "at most once" as it is defined in the resolution 
to Issue 9, is out of place with the
rest of the DAs.

>Tom,
>
>In ALL cases, the obligation on the RMS is the same. Below, you claim that 
>for AtMostOnce,
>there are no obligations on the RMS which is not the case.
>  
>
I agree, I must have mistyped on one place.  My point is that the 
current definition of "at most once" from issue 9 resolution
implies a permission contract on the RMD which allows it to throw away 
successfully received and acknolwedged messages. 

This is not a reliability function, but a reliability permission.

>I fail to see why you wish to characterize AtMostOnce in the terms below. 
>It merely means that
>the RMD might not, for a variety of unspecified reasons, not deliver a 
>received message to the AD.
>Nothing more, nothing less.
>
>I thought that the TC had come to consensus agreement that the protocol 
>operated the way it
>is described in the resolution to i020[1]. Why is it then that you write:
>
>The delivery assurance ?at most once?, as defined in WS-rm spc, seems 
>out of place.  If the ws-rm spec is going to allow for ?best effort 
>Delivery? as a conformant behaviour contract for an RMD under special 
>circumstances, why is it only allowed in combination with Guaranteed 
>receipt and Duplicate Elimination reliability functions?
>
>  
>
Do we really want to have this "permission" of Best Effort Delivery of 
received and acked messages as an official part of the spec,
with a conformance point, then it better be justified.

If we keep BED init, why not also apply it to "exactly once"?

>Whether or not the definition of AtMostOnce seems out of place or not is 
>irrelevant. It is merely important
>to make it clear that the protocol operates consistently regardless of DA, 
>and that DA is exclusively a
>function of the contract between the RMD and AD in terms of the level of 
>assurance that a received message
>will, or will not, be (eventually) delivered.
>  
>
I agree the protocol is consistent, we are talking about reliability 
contracts between the RMD and it destination application.

Tom Rutt

>Cheers,
>
>Christopher Ferris
>STSM, Emerging e-business Industry Architecture
>email: chrisfer@us.ibm.com
>blog: http://webpages.charter.net/chrisfer/blog.html
>phone: +1 508 377 9295
>
>
>
>Tom Rutt <tom@coastin.com> 
>09/28/2005 01:49 PM
>Please respond to
>tom
>
>
>To
>tom@coastin.com
>cc
>wsrx <ws-rx@lists.oasis-open.org>
>Subject
>Re: [ws-rx] Proposed NEW ISSUE: Alignment and Refinement of Definitions 
>for Delivery Assurances
>
>
>
>
>
>
>Tom Rutt wrote:
>
>  
>
>>NEW ISSUE ? Alignment and Refinement of Definitions for Delivery 
>>Assurances
>>
>>    
>>
>The previous email has a mistake in the two tables, in that there is no 
>need for a "hold for prior" column.
>
>The complete new issue proposal, with the fix,::
>-------
>
>NEW ISSUE ? Alignment and Refinement of Definitions for Delivery 
>Assurances
>
>Description:
>I took an action Item to align the Delivery Assurance definition text in 
>the body document with the resolution of Issue 009. 
>
>Justification:
>The resolution of Issue 009 is documented at:
>http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14682/ReliableMessagingIssues.xml#i009 
>
>:
>
>It is best if the Delivery assurances are defined in only one place in 
>the document. 
>
>The definition of Delivery assurances is simplified by introducing the 
>concept of Reliability Functions.
>
>Proposals:
>
>The proposal to resolve this ISSUE is presented in Three Steps.
>
>
>Step 1) of Proposed Resoluton:  Change the use of in line definitions in 
>the proposal for Issue 009 to references to the definitions in section
>
>Resulting text for Proposal for Issue 009:
>
>?
>    <wsrm:DeliveryAssertion mode="[AtLeastOnce|AtMostOnce|ExactlyOnce]" 
>ordered="[xs:boolean]"? ...="" >
> 
>
>    /wsrm:DeliveryAssertion
>    A policy assertion that makes a claim as to the delivery assurance 
>policy
>    observed by the destination endpoint.
> 
>
>    /wsrm:DeliveryAssertion/@mode
>    This required attribute specifies which delivery assurance is 
>asserted.
> 
>
>    A value of 'AtMostOnce' means that the Delivery Assurance ?at Most 
>Once,
>    defined in section xxx, is asserted.
> 
>
>    A value of 'AtLeastOnce' means that the Delivery Assurance ?At Least 
>Once?,
>    defined in section xxx, is asserted..
> 
>
>    A value of 'ExactlyOnce' means that the Delivery Assurance ?Exactly 
>Once?,
>    defined in section xxx, is asserted.
> 
>
>    /wsrm:DeliveryAssertion/@ordered
>    This attribute, of type xs:boolean, specifies whether, or not, the
>    ?in order? reliability function defined in section xxx is asserted.  .
>     A value of 'true' asserts that the     ?in order? reliability 
>function is required.
>     A value of 'false' asserts that the ?in order? reliability function 
>is not required.
>     If omitted, the default implied value is 'false'.
>?
>
>
>Step 2)  of Proposed Resolution: Clarify Definitions of Delivery 
>assurances, using concept of reliability functions
>
>The term ?Delivery assurance? is used to refer to a set of engaged 
>reliability functions associated with a Reliable Messaging Sequence.
>
>Fundamental Reliability Functions:
>?    Guaranteed Receipt:
>o    RM-Source must buffer the message, to allow for potential 
>re-transmission, until an acknowledgement is received from the 
>RM-Destination for that message. 
>o    RM-Destination must return an acknowledgment upon successful 
>receipt of the message.
>?    Duplicate Elimination:
>o    No obligations on RM-Source. 
>o    RM-Destination must not deliver to application destination any 
>message which has the same ID as a previously delivered message.
>
>In addition, to allow the definition of Delivery assurance ?at most 
>once?, as in the resolution of Issue xx, the following ?reliability 
>function? is defined
>?    Best Effort Delivery
>o    No obligations on RM-Source
>o    RM-Destination is allowed to abort delivery of received messages to 
>application destination if it cannot delivery the received message.
>
>Note: the Best Effort Delivery function is really a function at all: it 
>has no obligations, while it does have a contractual permission for not 
>delivering a message which it has received.  This does not seem to be a 
>valid reliability function.
>
>The following table specifies the delivery assurances in terms of 
>engaged reliability functions.
>
>Delivery Assurance |Guaranteed Receipt |Duplicate Elimination | Best 
>Effort Delivery
>-------------------|-------------------|----------------------|---------------------
>At least once      |         y         |             n        | n
>Exactly once       |         y         |             y        | n
>?At most once?     |         y         |             y        | y
>
>The following reliability function may be asserted along with any of the 
>above Delivery Assurances:
>
>?    In-order:
>o    Order is determined by the value of the RM message number.  Ordered 
>delivery would mean that the messages would be delivered in ascending 
>order of the message number value.
>o    No obligations on RM-Source
>o    RM-Destination must hold a received message, for delivery to the 
>application destination, until all messages with smaller message number 
>within a sequence have been delivered to the application destination.
>
>Note:  The guaranteed delivery function is the only one which puts an 
>obligation on the rm-source. All of the reliability functions defined 
>above place obligations (or permissions in the case of ?Best Effort 
>Delivery?) on the rm-destination. 
>
>
>------------------
>
>Step 3) of Proposal:  Refinement of DA Definitions Required to Resolve 
>Discrepancy with traditional semantics of  ?At Most Once?
>
>The delivery assurance ?at most once?, as defined in WS-rm spc, seems 
>out of place.  If the ws-rm spec is going to allow for ?best effort 
>Delivery? as a conformant behaviour contract for an RMD under special 
>circumstances, why is it only allowed in combination with Guaranteed 
>receipt and Duplicate Elimination reliability functions?
>
>I propose two ways to fix this discrepancy:
>
>3 a) Remove the concept of ?at most once? as defined in this spec. 
>
>The traditional use of the term ?at most once? delivery assurance 
>requires engagement of the duplicate elimination function without 
>requiring the guaranteed delivery function.  Since it has been agreed 
>that the ws-rm protocol will always support the guaranteed Receipt 
>function, this traditional concept of ?at most once? is not compatible 
>with this protocol.
>
>2 b) define two new delivery assurances with Best effort Delivery  (for 
>consistency)
>
>Delivery Assurance |Guaranteed Receipt |Duplicate Elimination |Best 
>Effort Delivery
>-------------------|-------------------|----------------------|---------------------
>At least once BED  |         y         |           n          |         y
>Exactly once BED   |         y         |           y          |         y
>
>
>Approach 3b) adds complexity to the Delivery assurance assertion 
>mechanism.  It does not seem to go along with the concept of Reliable 
>messaging, and systems which do this should be considered as acting 
>outside the scope of the WS-rm specification.
>
>I prefer proposal 3a).
>
>
>  
>


-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133