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] Proposed NEW ISSUE: Alignment and Refinement of Definitionsfor 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

I took an action Item to align the Delivery Assurance definition text in 
the body document with the resolution of Issue 009. 

The resolution of Issue 009 is documented at:

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.


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]"? ...="" >

    A policy assertion that makes a claim as to the delivery assurance 
    observed by the destination endpoint.

    This required attribute specifies which delivery assurance is asserted.

    A value of 'AtMostOnce' means that the Delivery Assurance “at Most 
    defined in section xxx, is asserted.

    A value of 'AtLeastOnce' means that the Delivery Assurance “At Least 
    defined in section xxx, is asserted..

    A value of 'ExactlyOnce' means that the Delivery Assurance “Exactly 
    defined in section xxx, is asserted.

    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 

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]