Re: [ws-rx] i0019 - a formal proposal

[Doug Davis <dug@us.ibm.com>]

Anish,
 comment inline.
thanks
-Doug


Anish Karmarkar <Anish.Karmarkar@oracle.com>
wrote on 08/25/2005 02:15:18 AM:

> I have some friendly (I hope) ammendment/suggestions below.
> 
> HTH.
> 
> -Anish
> --
> 
> Doug Davis wrote:
> > 
> > Using the pdf file at 
> > http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/13493/WS-
> ReliableMessaging-v1.0-wd-01.pdf 
> > 
> > here's a more formal proposal:
> > 
> > After line 345, add to the XML for SeqAck:
> >   <wsrm:Final/>
> > 
> 
> Couldn't this be an attribute on the wsrm:SequenceAcknowledge element
> (in the spirit of optimizations that Chris had sent earlier)?

Yes, if we pick up Chris' changes then we should that.
 
> We also should say that wsrm:Final MUST NOT be present if wsrm:Nack
is 
> present. I.e., a RM Dest should not nack a message (or messages) and
> include the wsrm:Final marker -- which does not give the RM Sender
any 
> idea as to what message have been received by the RM Dest.

Good point.  Since a NACK doesn't make any statement
about any other
message # in the sequence, a Final on a NACK could
lead to some very
bad misinterpretation of the state of the sequence.

> > After line 378, add to the description of the SeqAck elements:
> >   /wsrm:SequenceAcknowledgement/wsrm:Final
> >   This optional element, if present, indicates that the
RM
> >   Destination is not accepting new messages for the
> 
> We would probably want to say more than 'new messages'. Something
along 
> the lines of '... indicates that the RM Destination will not deliver
any 
> message that is not listed in the acknowledgement, to the Application
> Destination.

If the point is to make sure that even retries of
Ack'd messages are 
not delivered then perhaps it should be more like:
  ..indicates that the RM Destination will not
accept or process
  any further messages for the specified sequence.
But I'm not sure if that's any better than the original.
 It all
means the same thing to me.  :-)

> >   specified Sequence.  The RM Source can be assured
that
> >   the ranges of messages acknowledged by this
> >   SequenceAcknowledgement header block will not change in
the
> >   future.  Any attempt to deliver additional messages
to this
> >   sequence MUST generate a SequenceClosed fault by the RM
> >   Destination.  This element MUST be present when the
Sequence
> >   is no longer accepting new message.
> > 
> > On lines 569 and 570 change:
> >   After an RM Source receives the <SequenceAcknowledgement>
> >   acknowledging the complete range of messages in a Sequence,
it
> >   sends a ...
> > to
> >   When the RM Source has completed its use of the Sequence,
it
> >   sends a ...
> > 
> > To the end of that para, at the end of line 574, add:
> >   Note, under normal usage the RM source will complete it
use of
> >   the sequence when all of the messages in the Sequence
have been
> >   acknowledged.  However, the RM Source is free to
Terminate
> >   a Sequence at any time regardless of the acknowledgement
state
> >   of the messages.
> > 
> 
> I thought we were distinguishing between terminating a sequence (which
> requires acks for all the messages) and closing a sequence.
> If that is so, then the text around terminating the squence should
not 
> change.

Yes but I wanted the spec to be clear that you don't
need to wait for
a sequence to be fully ACKd before you send a terminate.
 The old version
of the text implied you should only send a terminate
after all acks have
been received, IMO.

> > Change lines 581 and 582 from:
> >   This element is sent by an RM Source after it has received
the
> >   final <SequenceAcknowledgement> covering the full
range of a Sequence.
> > to
> >   This element is sent by an RM Source to indicate it has
completed
> >   its use of the Sequence.
> > 
> > After line 396, add a new section about closing a Sequence:
> >   3.6 Closing A Sequence
> >   There may be times during the use of an RM Sequence that
the RM
> >   Source will wish to discontinue using a Sequence even
if some of the
> >   messages have not been successfully delivered to the RM
Destination.
> >   While the RM Source can send a TerminateSequence to the
RM Destination,
> >   since this is a one-way message and due to the possibility
of late
> >   arriving (or lost) messages and Acknowledgements, this
would leave
> >   the RM Source unsure of the final ranges of messages that
were
> >   successfully delivered to the RM Destination.
> > 
> >   To alleviate this, the RM Source can send a <wsrm:Close>
element,
> >   in the body of a message, to the RM Destination to indicate
that
> >   RM Destination MUST NOT accept any new messages for the
specified
> >   sequence.  Upon receipt of this message the RM Destination
MUST
> >   send a SequenceAcknowledgement to the RM Source.  Note,
this
> >   SequenceAcknowledgement MUST include the <wsrm:Final>
element
> >   indicating that the RM Destination will not accept any
new messages
> >   for this sequence.
> 
> Similar to my comment above, I would like to suggest that we talk
about 
> 'delivery' to Application Destination rather than 'accepting any new
> message'. Also, the 'MUST NOT' should be after the SeqAck with a 
> wsrm:Final marker has been sent by the RM Dest and not after the 
> wsrm:Close is received by the RM Dest (as it is untestable).

I think all we can really talk about is whether or
not the RM destination
can accept/process messages - the delivery of the
messages from the
RMD to the AppDestination is out of scope of the spec.
Not sure about the 2nd part...the Close() is a way
to trigger the MUST NOT
so I'm not sure why that isn't testable.  Send
a Close(), next SeqAck
received MUST have a "Final" and any future
SeqAcks should not have new 
ranges no matter what messages are retried.

> > 
> >   When a Sequence is closed and there are messages at the
RM Destination
> >   that are waiting for lower-numbered messages to arrive
(such as the
> >   case when InOrder delivery is being enforced) before they
can be
> >   processed by the RM Destination's application, the RM
Destination
> >   MUST NOT deliver those messages and a SequenceClosed fault
MUST
> >   be generated for each one.
> 
> Does it have to? Why?
> Can it not just ignore the lower-numbered messages that are received
> after the final ack is sent? For example, a message that was sent
> earlier than the 'close' message may be received after the 'close'
> message. In such a case, wouldn't it be more efficient to just ignore
> the message.

This text is for the case where you sent 5 messages
but message 3 is
lost.  If a Close() is sent I don't believe that
messages 4 and 5 should
be delivered to the Dest.App. since message 3 was
never recieved.  In 
this case the only think that makes sense to me is
to generate a fault
for message 4 and 5 just as if they had arrived late
to the RMD - meaning
a SequenceClosed fault.
The RMS can know for sure that all messages in the
first Ack range (meaning
up to the first gap) have been successfully delivered/processed
and anything
higher was not.
Oh, if you're asking why generate a Fault instead
of just ignore it, then
I think its important that we don't just ignore messages
- when possible
if a message is not going to be processed by the RMD
there should be an 
attempt to notify the RMS.

> I'm also wondering if we need the wsrm:Close? We could change the
> wsrm:TerminateSequence schema to have something like a abnormal='true'
> or immediate='true' attribute.

Since Terminate is a one-way and all SeqAcks are not
sent reliably we
have no way to guarantee that the RMS knows the true
final state of the
seq w/o some explicit hand-shaking between the two
parties.  And since
a Terminate allows the RMD to completely forget about
everything we need
some way for the RMS to get this final state (possibly
asking for it 
many times in the case of a bad network) before the
RMD forgets.

> > 
> >   The following exemplar defines the Close syntax:
> >     <wsrm:Close wsrm:Identifier="xs:anyURI"/>
> > 
> >   /wsrm:Close
> >   This element is sent by an RM Source to indicate that
the RM
> >   Destination MUST NOT accept any new messages for this
sequence.
> >   Any attempt to deliver additional messages to this sequence
> >   MUST generate a SequenceClosed fault by the RM Destination.
> > 
> >   /wsrm:Close@Identifier
> >   This required attribute contains an absolute URI conformant
> >   with RFC2396 that uniquely identifies the sequence.
> > 
> >   /wsrm:Close/{any}
> >   This is an extensibility mechanism to allow different
(extensible)
> >   types of information, based on a schema, to be passed.
> >  
> >   /wsrm:Close@{any}
> >   This is an extensibility mechanism to allow additional
attributes,
> >   based on schemas, to be added to the element.
> > 
> >   A <wsrm:Closed> is sent in the body of a response
message by
> >   an RM Destination in response to receipt of a <wsrm:Close>
request
> >   message.  It indicates that the RM Destination will
no longer
> >   accept new messages for the sequence.
> > 
> >   The following exemplar defines the <wsrm:Closed>
syntax:
> > 
> >   /wsrm:Closed
> >   The element is sent in the body of a response message
by
> >   an RM Destination in response to receipt of a <wsrm:Close>
request
> >   message.  It indicates that the RM Destination will
no longer
> >   accept new messages for the sequence.
> > 
> >   /wsrm:Closed/{any}
> >   This is an extensibility mechanism to allow different
(extensible)
> >   types of information, based on a schema, to be passed.
> >  
> >   /wsrm:Closed@{any}
> >   This is an extensibility mechanism to allow additional
attributes,
> >   based on schemas, to be added to the element.
> > 
> > On lines 735 and 746 make these faults non-terminating by removing:
> >   It is an unrecoverable error and terminates the Sequence.
> >  
> > After line 760, add a new fault:
> >   4.8 Sequence Closed
> >   This fault is sent by an RM Destination to indicate that
it has
> >   received a message for a sequence that is no longer accepting
> >   new messages.
> >   Properties:
> >   [Code] Sender
> >   [Subcode] wsrm:SequenceClosed
> >   [Reason] The sequence is closed and can not accept new
messages.
> >   [Detail] empty.
> > 
> > Add the proper XML to the schema and WSDL....
> > 
> >  - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
> > 
> > Some notes:
> > I didn't include the Identifier on the Closed since its not needed.
> > The correlation back to the Seq can be done thru WS-A relates
to.
> > Trying to follow Chris' lead and save space.
> > 
> > I didn't include anything about LastMessage because I consider
its
> > demise or continued existence orthogonal to the Final and Close/Closed
> > discussion.  In other words, I believe that it can be killed
or
> > saved regardless of whether the above text is adopted and should
> > therefore be considered a new issue.
> > 
> > I didn't include the parameters Chris mentioned in his note because,
> > to be honest, I didn't understand them  :-)
> > The source is sending a Close() because it wants to shutdown
the
> > sequence regardless of its state.  Passing in the HiMsgNum
or
> > a Truncate flag shouldn't change the fact that the source wants
> > the sequence to shut down _now_.  What would the destination
do with
> > this info?  Not closing down the sequence shouldn't be an
option.
> > Sending back a final Ack on the Closed() will tell the source
the
> > final state of the sequence.
> > 
> > Didn't follow the part about Faults in the closed() either.  
> > Its way to late.  :-)
> > 
> > w.r.t. Stefan's comment on the call about InOrder - without seeing
a
> > note from him I can only guess....but I added some text about
> > what to do when InOrder is in use.
> > 
> > thanks,
> > -Doug
> >