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

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

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)?

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.

> 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.

>   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.

> 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).

> 
>   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.

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.

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