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: NEW ISSUE - Allignment and refinement of defintions for DA - Restatement


This email is a recast of my earlier email, which focuses more on the 
problem, taking out
some of the proposed solution: in the earlier email I prefer this to be 
the new issue for discussion by the TC

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.

Source: Tom Rutt, Fujitsu

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.

There is a discrepancy with the current text in secton 2 and the 
resolution of issue 009, regarding
the necessity for raising an error on at least one endpoint.

The definition in the current text of DA in Section 2 :
"
There are four basic delivery assurances that endpoints can provide:
- AtMostOnce Messages will be delivered at most once without duplication 
or an error
will be raised on at least one endpoint. It is possible that some 
messages in a
sequence may not be delivered.
- AtLeastOnce Every message sent will be delivered or an error will be 
raised on at
least one endpoint. Some messages may be delivered more than once.
- ExactlyOnce Every message sent will be delivered without duplication 
or an error
will be raised on at least one endpoint. This delivery assurance is the 
logical "and" of
the two prior delivery assurances.
- InOrder Messages will be delivered in the order that they were sent. 
This delivery
assurance may be combined with any of the above delivery assurances. It 
requires
that the sequence observed by the ultimate receiver be non-decreasing. 
It says
nothing about duplications or omissions.
"

while the current text for resolution of issue 009 adds the following 
for DA policy assertion:
"

<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 whether or not all of the messages
within an RM Sequence will be delivered by the RM Destination to the
Application Destination, and whether or not duplicate messages will be
delivered.

A value of 'AtMostOnce' means that messages received by the RM Destination
will be delivered to the Application Destination at most once, without
duplication. It is possible that some messages in a sequence may not be
delivered.

A value of 'AtLeastOnce' means that every message received by the RM
Destination will be delivered to the Application Destination. Some
messages may be delivered more than once.

A value of 'ExactlyOnce' means that every message received by the RM
Destination will be delivered to the Application Destination without
duplication.

/wsrm:DeliveryAssertion/@ordered
This attribute, of type xs:boolean, specifies whether, or not, the
destination endpoint ensures that the messages within an RM Sequence will
be delivered in order, by the RMD to the AD. 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.
A value of 'true' indicates that messages will be delivered in order.
A value of 'false' makes no claims as to the order of delivery of the 
messages within a RM Sequence.
If omitted, the default implied value is 'false'.


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, including the requirment for error indication.

We need to align the two definitions and put the resulting agreed text 
in section 2:

- the definitions of AtLeastOnce and of ExactlyOnce from Issue 009 do 
not mention the possibility
of an error (delivery failure) while they do in the current core spec 
definition. Is that intentional, or a lapse?
It seems the the same reasons that may lead an RMD to drop received 
messages under AtMostOnce,
may also apply under AtLeastOnce (e.g. some resource shortage).
The difference seems to be about proper error raising/notification when 
a received message is not delivered..

- Similarly, AtMostOnce as defined in the resolution to issue 009 
assumes that duplicates are never delivered -
that seems stronger than the original requirement in the core spec that 
says
"... or else an error will be raised". These need to be aligned one way 
or the other.


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