RE: [ws-rx] Concrete proposal for PR035

[Peter Niblett <peter_niblett@uk.ibm.com>]

Jacques

I'm happy with your first two proposals, I just have a concern about your
second InOrder point.

Let's see if we are in agreement about what should happen, in the various
DA combinations, if the RMD receives and accepts messages 1,2,4,5,6
(message 3 is missing/delayed).

1. The way I see it is that if InOrder is specified, then it must not be
violated.. i.e. once the RMD has delivered any message, it must not deliver
any earlier message. Likewise the AtMostOnce DA must not be violated by
"delivering" the same message more than once. So if the DA is AtMostOnce
and InOrder, then it should deliver 1 and 2 and then wait an
implementation-determined time to see if 3 turns up. If 3 doesn't arrive
within this time, it then goes on to deliver 4,5,6. It never delivers 3,
even if it does turn up later since that would violate inOrder.

RMS--1--->RMD  gets delivered
RMS--2--->RMD  gets delivered
RMS--4--->RMD  gets held
RMS--5--->RMD  gets held
RMS--6--->RMD  gets held

time passes...RMD decides to give up on 3

RMD delivers 4,5,6
RMS--3--->RMD  gets discarded


2. If it is atLeastOnce or exactlyOnce with inOrder, then the RMD should
wait for 3 before delivering 4,5,6. There could be situations where message
3 never turns up (RMS fails to resend). In this case I would expect the RMS
(or someone else) to give up eventually and then close the sequence.
Clearly the IncompleteSequenceBehavior would apply when the sequence
closes, but it doesn't apply before. Even if the IncompleteSequenceBehavior
were NoDiscard, the RMD can't decide to deliver 4 while the sequence is
open,  because there's still the possibility that 3 might appear, and when
that happens we aren't allowed to drop it nor deliver it out of order.

If the sequence does close and 3 still hasn't turned up, then what happens
depends on the IncompleteSequenceBehavior
- DiscardEntireSequence and DiscardFollowingFirstGap means that 4,5,6 are
discarded
- NoDiscard means that 4,5,6 are delivered

So how to capture all that in a concise sentence? I think it is best if we
don't talk about delaying at all (which is really an implementation
technique) and just talk about the things that must be obeyed. How about
this?

This DeliveryAssurance can be used in combination with any of the
AtLeastOnce, AtMostOnce or ExactlyOnce assertions, and the requirements of
those assertions MUST also be met. In particular if the AtLeastOnce or
ExactlyOnce assertion applies and the RM Destination detects a gap in the
sequence, then the RM Destination MUST NOT deliver any subsequent messages
from that sequence until the first missing message is received or until the
sequence is closed.

Regards

Peter Niblett
IBM Senior Technical Staff Member



                                                                           
             "Durand, Jacques                                              
             R."                                                           
             <JDurand@us.fujit                                          To 
             su.com>                   Peter Niblett/UK/IBM@IBMGB,         
                                       <ws-rx@lists.oasis-open.org>        
             31/01/2007 01:32                                           cc 
                                                                           
                                                                   Subject 
                                       RE: [ws-rx] Concrete proposal for   
                                       PR035                               
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




I think we are getting close.

I would suggest the following  - mostly editorial - modifications on the DA
defs:

ExactlyOnce:
"...Each message is to be delivered exactly once, or else an error MUST be
raised by the RM Source and/or RM Destination. "
This could be misleading as the reader might understand that it is OK to
deliver duplicates provided that an error is raised... which is not what we
had in mind - at least according to the way we handled AtMostOnce DA.  Now,
the last sentence of the DA contradicts the idea that duplicates might be
delivered, but which one is the reader to believe?. So to dissipate this
ambiguity I propose to reword the first sentence as:


"...Each message is to be delivered exactly once, and if the message could
not be delivered then an error MUST be raised by the RM Source and/or RM
Destination. "


InOrder:


I would avoid any forward reference to the details of the protocol solution
that is supposed to help this DA, as specified later on in the spec body-
or at least would try to keep away from the XML details and just allude to
the mechanism to be used:


propose to replace: (as indicated by its MessageNumber) with: (as indicated
by a message sequence number)


propose to replace: in the order indicated by the sequence MessageNumbers
with: in the order indicated by the message numbering


One more sugegstion on the InOrder DA again: I think we go too far when we
recommend to "delay" delivery of out of order messages in case of InOrder +
AtLeastOnce. Reasons are, several options for the ultimate delivery
behavior in case of out-of-order messages,  still need be kept open (e.g.
as signaled with IncompleteSequenceBehavior), provided that the overall
monotonic order is preserved. E.g. in some cases, the out-of-order messages
will be discarded, not just delayed.


So instead of:


"...then the RM Destination SHOULD delay delivery of these messages"


we coud say:


"...then the RM Destination SHOULD wait for a reasonable time window before
forgoing missing messages"





Thanks,


- Jacques











-----Original Message-----
From: Peter Niblett [mailto:peter_niblett@uk.ibm.com]
Sent: Tuesday, January 30, 2007 3:28 PM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] Concrete proposal for PR035


Here are my proposed changes to the WS-RM and WS-RMP specs, consolidating
the various input and discussion we had on last week's call

(See attached file: wsrm-1.1-spec-wd-16-PR035.pdf)(See attached file:
wsrmp-1.1-spec-wd-11-PR035.pdf)

All changes are in section 2 of each spec, and they are all additions. I
have used Adobe Pop-up annotations to show the new material.

Peter Niblett
IBM Senior Technical Staff Member