Re: [ws-rx] PR035, PR009, PR020: DA defs

[Christopher B Ferris <chrisfer@us.ibm.com>]

Jacques,

Actually, I think that the definitions
you have suggested are not quite right. It is important
IMO that the defnitions not prescribe
the behavior of the RMD, but rather describe the
outcome as perceived external to the
RMD/AD processing.

My reasoning is that we don't want to
be specifying the implementation of the RMD. 

To say that the RMD can only "deliver"
the message to the AD once would need a formal
definiton of "deliver". Does
that mean that it will only ATTEMPT delivery to the AD once? What of that

fails? What if there is transactionality
between the RMD and AD such that a failed processing
of the message results in a rollback?
Would a retry be in violation of the expressed DA since the
message is delivered more than once?

I think that the definitions should
read something along the following lines:

AtLeastOnce - describes a delivery assurance
characteristic of the processing of the messages
within an RM Sequence received by the
ultimate receiver such that the each message in the Sequence, 
received by the RMD, is processed to
conclusion at least once. This means that a given message in the 
Sequence that  was received and
acknowledged by the RMD MAY be processed to conclusion more than 
once. It also means that duplicate filtering
SHOULD NOT be applied by the ultimate receiver.

AtMostOnce - describes a delivery assurance
characteristic of the processing of the messages 
within an RM Sequence such that the
messages within the Sequence received by the ultimate
receiver are processed to conclusion
at most once. This means that a given message(s) within 
the Sequence that was received and acknowledged
by the RMD might not be processed to conclusion. 
It also means  that a given message
within the Sequence MUST NOT be processed to 
conclusion more than once (ie. duplicate
filtering MUST be applied by the ultimate receiver).

ExactlyOnce - describes a delivery assurance
characteristic of the processing of the messages
within a Sequence such that each message
within an RM Sequence received by the ultimate receiver
MUST be processed to conclusion exactly
once (ie, duplicate filtering MUST be applied).
It also means that the receiving endpoint
SHOULD make every effort to ensure that each message 
within the Sequence received by the
RMD will be processed to conclusion. 

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 377 9295

"Durand, Jacques R." <JDurand@us.fujitsu.com>
wrote on 01/08/2007 02:19:34 AM:

> 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 DAs. Also, 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.]