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] ISSUE I0006 and Substibutabllity of Delivery Assurancelevels


Tom Rutt wrote:

> This email introduces the concept of substitubility of Delivery 
> Assurance levels, to aid in discussing Issue 0006.


Small mistake, on the row of the substitutabiliy matrix for exactly 
once, change the two (rule 1) column entries to (rule 2).

>
> Tom Rutt
> Fujitsu
>
I attache the corrected contribution

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


Title: This email presents taxonomy of Delivery assurances, to assist in the discussion of Issue 006: Source based Delivery Qos assertion

 

This email introduces the concept of substitutability for Delivery assurances, to assist in the discussion of Issue 006: Source based Delivery Qos assertion

 

“Is there a requirement that the sender can assert that the receiver must deliver a particular reliability assurance on a given sequence?”

 

1) Relevance of Substitutability to Issue 6

 

Given an rm-destination supports a Delivery Assurance which is substitutable for the rm-source’s assertion of its required Delivery assurance for a sequence, it may create that sequence supporting a substituted Delivery assurance.

 

One possible negotiation scenario would be for the rm-source to include a parameter in the create sequence operation indicating the delivery assurance required for a sequence, and the operation response message could indicate a substituted delivery assurance for that sequence.

 

 

2)  Delivery assurances as engaged Reliability functions

 

The following table lists reliable messaging delivery assurance levels on the left column, with an “x” used to indicate which reliable messaging functions are engaged for that level of Delivery assurance.  The reliability functions are defined below.

 

Delivery Assurance

Reliability Functions

Guaranteed Delivery

Duplicate Elimination

Hold for Prior

Monotonic Filtering

At least once

x

 

 

 

Exactly once

x

x

 

 

in-order

x

x

x

x

At most once

 

x

 

 

increasing

 

x

 

x

Monotonic

 

 

 

x

at-least once in-order

x

 

x

x

 

Note: The first four delivery assurances are mentioned in WS-Reliable Messaging, and are also supported explicitly by WS-Reliability. 

 

The last three deliver assurances (named “Strictly increasing”, “Monotonic”, and “at-least once in order”)  are shown in this taxonomy because they are potentially “meaningful” (useful in some context) combinations of the Reliable messaging functions defined below. In the end, the TC may decide to not have them be supported by the OASIS standard.

 

Combinations of engaged reliability functions deemed by myself to be meaningless (i.e., useless combinations) are not shown in the table..

 

Reliability Functions:

  • Guaranteed Delivery:
    • RM-Source must buffer the message, to allow for potential re-transmission, until an acknowledgement is received from the RM-Destination for that message.   
    • RM-Destination must return an acknowledgment upon successful receipt of the message.
  • Duplicate Elimination:
    • No obligations on RM-Source. 
    • RM-Destination must not deliver to application destination any message which has the same ID as a previously delivered message.
  • Hold for Prior:
    • No obligations on RM-Source
    • RM-Destination must hold a message (waiting for delivery to application destination) until all messages with smaller sequence number have been delivered to the application destination.
  • Monotonic Filtering
    • No obligations on RM-Source
    • RM-Destination must not deliver to application destination any message with a sequence number smaller that than the sequence number of any message which has been delivered to the application destination.

 

Note that the guaranteed delivery function is the only one which puts an obligation on the rm-source. All of the reliability functions defined above put obligations on the rm-destination.

 

2) Substitutability matrix for Delivery Assurances

 

A required delivery assurance may be substituted by another delivery assurance which does not violate either of the following 2 rules:

  1. Does not add reliability function obligations associated with the rm-source
  2. Engages, at least, those rm-destination reliability function obligations required by the substituted delivery assurance..

 

Required DA

Substitutable DA

At least once

Exactly once

In-order

At most once

Increasing

Monotonic

At least once in-order

At least once

s

s

s

no (rule 2)

no (rule 2)

no (rule 2)

s

Exactly once

no (rule 2)

s

s

no (rule 2)

no (rule 2)

no (rule 2)

no (rule 2)

in-order

no (rule 2)

no (rule 2)

s

no (rule 2)

no (rule 2)

no (rule 2)

no (rule 2)

At most once

no (rules 1, 2)

no (rule 1)

no (rule 1)

s

s

no (rule 2)

no (rule 1)

increasing

no (rules 1,2)

no (rule 1)

no (rule 1)

no (rule 2)

s

no (rule 2)

no (rules 1,2)

Monotonic

no (rules 1,2)

no (rules 1,2)

no (rule 1)

no (rule 2)

s

s

no (rule 1)

At least once in-order

no (rule 2)

no (rule 2)

s

no (rule 2)

no (rule 2)

no (rule 2)

s

 

 

 

 

 

 



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