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: PR035, PR009, PR020: DA defs


Rationale for a rewording of DA definitions that were used a year ago:
 
AtLeastOnce

Previous:

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

 Proposed:

for every sent message, either the RMD has received the message and successfully delivered it, or at least one of the AS or the AD is made aware of a delivery failure. Note: There is no guarantee that if delivered, the message is delivered just once. Also it may happen that both delivery and failure notification occur for a message.

[comment: pretty much same. Just relate it better to the messaging model: re-emphasizes that " deliver"  must be understood with the precise meaning given in glossary,  i.e. as delivery to AD, not in its general sense. Same for errors raised. Also mention that cases where message is delivered yet an error is raised, are not ruled out - cannot be always prevented.]

AtMostOnce

Previous:

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.

Proposed:

A message shall not be delivered more than once by the RMD. Message duplicates are identified based on Sequence ID and Sequence number. Note: there is no guarantee that the message is delivered or that an error is raised if not.

[comment: the previous definition is not crisp enough - users expect more than to tolerate accidental duplicate deliveries provided they have been flagged (why not just prevent the delivery of duplicate if you can notify about it, which assumes you can detect them in the first place?) In any case, I believe the protocol has the ability to enable this stronger definition, which also defines duplicates]

ExactlyOnce (can be added although just a combination of other DAs)

Previous:

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.

Proposed: This DA is equivalent to the combination of  AtLeastOnceDelivery and AtMostOnceDelivery DAs (i.e. combining their requirements).

[comment: previous no longer adequate with a new, tighter definition of AtMostOnce. Prefer to just say that this is a logical combination of two prior DAsAlso, do we really need this DA if we can combine DAs?]

InOrder

Previous:

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 messages within a Sequence will be delivered in an order so that the message numbers are monotonically increasing. Note that this assurance says nothing about duplications or omissions. Note also that it is only applicable to messages in the same Sequence. Cross Sequence ordering of messages is not in the scope of this specification.

Proposed: When delivering messages from a same sequence, an RMD does so in the same order they have been sent by the application source (AS) to the RMS. This only means a message will not be delivered if another message sent after it has already been delivered. Note: The ordering concerns only messages from the same sequence - not across sequences. Additional delivery constraints are not precluded by this delivery assurance - e.g. to not deliver a message if a previous one is still missing. 

[comment: reworded in order to be explicit that "send"  must be understood as in glossary: passing a message from AS to RMS, not in its general sense. Also previous wording seems to imply that " messages will be delivered"  is a guarantee, in first sentence, which may be confusing even if denied subsequently. Also avoiding references to "message numbers"  in a general DA def. That already assumes a specific protocol (how are these numbers assigned, etc.) which is introduced only later in the spec.]



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