ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ws-rx] PR035, PR009, PR020: DA defs
- From: "Durand, Jacques R." <JDurand@us.fujitsu.com>
- To: "Christopher B Ferris" <chrisfer@us.ibm.com>
- Date: Thu, 11 Jan 2007 13:16:11 -0800
Chris:
I think we are wordsmithing here... your defs still
abundantly mention the RMD and imply some behavior from
these...;-)
Your " process to conclusion" is still quite too
vague for me (what is a conclusion?)
If you define it in turn as "either delivered or generate a
failure that is accessible to either party" or something like it, then we are in
agreement.
I'd really would like to see it relate somehow to delivery,
which is actually defined in our model - after all, we talk of "delivery
assurances" and isn't the delivery what realy matters to the
end-users?
I think your AtMostOnce is actually closer to mine than to
the original one, which to me is the most important
improvement.
AtLeastOnce: why "SHOULD NOT be applied
by the ultimate receiver" ? I suggest to drop this
limitation that makes it difficult to consider EXactlyOnce as logical
combination of AtMostOnce + AtLeastOnce.
Cheers
Jacques
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.]
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]