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