[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Need to finish-up DA def discussion...
Jacques
Here are the things that I think I need to incorporate into the
consolidated PR 035 proposal. I have put all proposed text in colour (if
you can see it). Could you please review?
1.Modify the definition of "Deliver" in section 2.1 (Glossary)
Existing wording is
Deliver: The act of transferring a message from the RM Destination to
the Application Destination.
Change to use new words proposed by Chris Ferris:
Deliver: The act of transferring responsibility for a message from
the RM Destination to the Application Destination.
2. Words for the AtLeast/AtMost/Exactly DAs
For reference, here is the original proposal from Matt and me
AtLeastOnce
Each message is to be delivered at least once. The requirement on an RM
Source is that it SHOULD retry transmission of every message sent by the
Application Source until it receives an acknowledgement from the RM
Destination. The requirement on the RM Destination is that it SHOULD retry
delivery to the Application Destination of every message that it accepts
from the RM Source. There is no requirement for the RM Destination to
apply duplicate message filtering.
AtMostOnce
Each message is to be delivered at most once. The RM Source MAY retry
transmission of unacknowledged messages, but is NOT REQUIRED to do so. The
requirement on the RM Destination is that it MUST filter out duplicate
messages, i.e. that it MUST NOT redeliver any message.
ExactlyOnce
Each message is to be delivered exactly once. The requirement on an RM
Source is that it SHOULD retry transmission of every message sent by the
Application Source until it receives an acknowledgement from the RM
Destination. The requirement on the RM Destination is that it MUST filter
out duplicate messages, i.e. that it MUST NOT redeliver any message.
Following comments from you and Stefan, and discussion on Thursday's call,
I suggest modifying these to the following
AtLeastOnce
"Each message is to be delivered at least once, or else an error MUST be
raised by the RM Source and/or RM Destination. The requirement on an RM
Source is that it SHOULD retry transmission of every message sent by the
Application Source until it receives an acknowledgement from the RM
Destination. The requirement on the RM Destination is that it SHOULD retry
the transfer to the Application Destination of any message that it accepts
from the RM Source, until that message has been successfully delivered.
There is no requirement for the RM Destination to apply duplicate message
filtering."
Comments: First change (about the error) is as agreed on Thursday's call.
In the last sentence I have changed "retry delivery" to "retry the
transfer" since we have now changed the meaning of "delivery". The "until
the message has been successfully delivered" is not quite precise. In
programming terms what we actually mean is "while that message has not been
successfully delivered", but I think that wording is too clumsy for use
here.
AtMostOnce
"Each message is to be delivered at most once. The RM Source MAY retry
transmission of unacknowledged messages, but is NOT REQUIRED to do so. The
requirement on the RM Destination is that it MUST filter out duplicate
messages, i.e. that it MUST NOT deliver a duplicate of a message that has
already been delivered."
Comments: This is the change you suggested. In combination with the
redefinition of "deliver" this addresses Stefan's concern
ExactlyOnce
"Each message is to be delivered exactly once, or else an error MUST be
raised by the RM Source and/or RM Destination. The requirement on an RM
Source is that it SHOULD retry transmission of every message sent by the
Application Source until it receives an acknowledgement from the RM
Destination. The requirement on the RM Destination is that it SHOULD retry
the transfer to the Application Destination of any message that it accepts
from the RM Source until that message has been successfully delivered, and
that it MUST NOT deliver a duplicate of a message that has already been
delivered."
Comments: Combination of the relevant parts of AtLeastOnce and AtMostOnce
3. The InOrder DA
Your proposal
Messages from a same sequence are to be delivered in the same order they
have been sent by the Application Source. The requirement on an RM Source
is that it MUST annotate messages so that the order in which they have been
sent from the Application Source, is manifest in the message. The
requirement on the RM Destination is that it MUST deliver received messages
for this sequence in the order indicated by the annotation mechanism - e.g.
sequence numbers. The RM Destination MAY decide to delay delivery of
messages in order to maximize the number of deliveries. Some received
messages MAY never be delivered.
I suggest modifying this as follows:
Messages from each individual sequence are to be delivered in the same
order they have been sent by the Application Source. The requirement on an
RM Source is that it MUST ensure that the ordinal position of each message
in the sequence (as indicated by its MessageNumber) is consistent with the
order in which the messages have been sent from the Application Source.
The requirement on the RM Destination is that it MUST deliver received
messages for each sequence in the order indicated by the sequence
MessageNumbers. This DeliveryAssurance can be used in combination with any
of the AtLeastOnce, AtMostOnce or ExactlyOnce assertions. If messages are
received out of order by the RM Destination then, if the AtLeastOnce or
ExactlyOnce assertion applies, then the RM Destination SHOULD delay
delivery of these messages. If the AtMostOnce assertion applies then the RM
Destination MAY decide to delay delivery of these messages.
Comments: I have changed your reference to "annotations" to make it clear
that it is MessageNumbers that we are talking about. I have added some text
to make it clear that this DA does not weaken the requirements of
ExactlyOnce or AtLeastOnce.
5. Placement of these DA's (RM or RM policy spec?)
I'm not quite clear where we ended up on this question. I propose that we
put them in a new section (2.6) of the main spec, with an introductory
paragraph as follows
"This section defines a number of Delivery Assurance assertions, which can
be supported by RM Sources and RM Destinations. These assertions can be
specified as policy assertions using the WS-Policy framework [WS-Policy].
For details on this see the WS-RM Policy specification [WS-RMPolicy] "
Then in the WS-RM Policy document we include the following (from Chris
Ferris' original strawman)
<wsrmp:DeliveryAssurance ...>
<wsp:Policy>
<wsp:All>
[<wsrmp:ExactlyOnce/>|<wsrmp:AtLeastOnce/>|<wsrmp:AtMostOnce>]
<wsrmp:InOrder/>?
</wsp:All>
</wsp:Policy>
</wsrmp:DeliveryAssurance>
wsrmp:DeliveryAssurance
When applied to an RM Destination, this element defines a policy assertion
that identifies a requirement on RM Sources. Any RM Source that transmits
messages to this RM Destination SHOULD conform to the requirement expressed
by this assertion. Conversely, when it is applied to an RM Source this
assertion identifies a requirement on RM Destinations. Any RM Destination
that receives messages from this RM Source SHOULD conform to the
requirement expressed by this assertion.
/wsrmp:DeliveryAssurance/wsp:Policy/wsp:All/wsrmp:ExactlyOnce
This expresses the ExactlyOnce Delivery Assurance defined in [WS-RM].
/wsrmp:DeliveryAssurance/wsp:Policy/wsp:All/wsrmp:AtLeastOnce
This expresses the AtLeastOnce Delivery Assurance defined in [WS-RM].
/wsrmp:DeliveryAssurance/wsp:Policy/wsp:All/wsrmp:AtMostOnce
This expresses the AtMostOnce Delivery Assurance defined in [WS-RM].
/wsrmp:DeliveryAssurance/wsp:Policy/wsp:All/wsrmp:InOrder
This expresses the InOrder Delivery Assurance defined in [WS-RM].
Regards
Peter Niblett
IBM Senior Technical Staff Member
"Durand, Jacques
R."
<JDurand@us.fujit To
su.com> Peter Niblett/UK/IBM@IBMGB
cc
26/01/2007 00:30 <ws-rx@lists.oasis-open.org>
Subject
Need to finish-up DA def
discussion...
The editorial action item on DAs only talk about merging the "consensus"
discussed so far regarding DAs.
But as we decided to timebox discussion on DAs today, there was additional
updates left undiscussed. In order to make sure we have enough time to
discuss these on the list before next meeting, here they are:
- the AtMostOnce DA. (See previous mails) To summarize, here is the latest
on the table, addressing comment from Stefan:
"Each message is to be delivered at most once. The RM Source MAY retry
transmission of unacknowledged messages, but is NOT REQUIRED to do so. The
requirement on the RM Destination is that it MUST filter out duplicate
messages, i.e. that it MUST NOT deliver a duplicate of a message that has
already been delivered."
- the Exactlyonce DA. (see previous mails). Here is the latest on the
table:
"Each message is to be delivered at least once, or else a "delivery error"
MUST [be raised by RMS and/or RMD]. A message also MUST NOT be delivered
more than once. The requirement on an RM Source is that it SHOULD retry
transmission of every message sent by the Application Source until it
receives an acknowledgement from the RM Destination. The requirement on the
RM Destination is that it SHOULD retry delivery to the Application
Destination of every message that it accepts from the RM Source in case of
unsuccessful delivery, and that it MUST NOT deliver a duplicate of a
message that has already been delivered."
- the InOrderDA. (see previous mails). Here is the latest on the table:
Messages from a same sequence are to be delivered in the same order they
have been sent by the Application Source. The requirement on an RM Source
is that it MUST annotate messages so that the order in which they have been
sent from the Application Source, is manifest in the message. The
requirement on the RM Destination is that it MUST deliver received messages
for this sequence in the order indicated by the annotation mechanism - e.g.
sequence numbers. The RM Destination MAY decide to delay delivery of
messages in order to maximize the number of deliveries. Some received
messages MAY never be delivered.
-Jacques
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]