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

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

Jacques,  
  Comments inline, and a new updated
version of the proposal will soon follow.
thanks
-Doug

Jacques Durand <JDurand@us.fujitsu.com> wrote
on 08/24/2005 08:50:34 PM:

> Sorry I missed that email... I think it is pretty close - mostly have
some 
> editorial suggestions,
> See inline <JD>.
>  
> This text is addressing i028 (the twin issue)
so far.
>  
> For i019, (after all that is the subject of this
email...) I still think we need to
> say that sequence Faults do not directly terminate a sequence, but
only close it at
> best (in that case, a "final" SequenceAck must be sent within
the Fault).

I think I suggested some changes to the spec to cover
this but perhaps more is 
needed.

> Cheers,
>  
> Jacques
>  
>  
> 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/> 
>  
> <JD> or: <wsrm:Final/>? (optional)</JD>

Fixed.
  
> 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 
>   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. 
>  
> <JD> mostly editorial:
> The statement "Any attempt to deliver additional
messages to this 
>   sequence MUST generate a SequenceClosed
fault by the RM 
>   Destination. " is already in the
Closing a Sequence section. We do not
> need to have it here too (it seems kind of marginal
to "Final")
> </JD>

I agree things seemed a bit repetitive, but other
places in the
spec seemed to do it so I did it too  :-)  Let's
see how it looks
once its all in place - removing text is easy.
  
> 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 ... 
>  
> <JD> shouldn't it be more precisely: 
> "When the RM Source has completed its use
of the Sequence, and usually after 
> the sequence has been closed, it sends a ...
"
> </JD>

I'm not sure I want to suggest why its closing it
- I'd prefer to leave
it a bit more open.
 
> 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. 
>  
> <JD> should we say: "is free to Close
and Terminate ..." instead of 
> "is free to Terminate ..." </JD>

Yes, done.

> 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. 
>  
> <JD> it is mostly editorial, but to avoid
any confusion, we need to be clear about
> what "use of the sequence" means: does
it include the possible subsequent querying 
> of Acks? (e.g. with AckRequested)
> if not, I'd rather say that:
> - indication of end of use [for message transfer]
= Closing
> - indication of resource release = Terminate
> </JD>

I've added more text that I think helps.
 
> 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.  
>  
> <JD> because of ambiguous "new message"
(it also concerns "old messages"
>  still in flight...) and in order to make
it easier to describe the 
> behavior expected, (because this behavior may
also take place when closing occurs
> in other ways than the <Close> element,
e.g. due to some Fault) 
> I'd introduce more abstractly the notion of "closed"
state:
> "To alleviate this, the RM Source can send
a <wsrm:Close> element, 
>   in the body of a message. Once this element
is interpreted by the RMD, 
> the sequence is closed. The closed state is characterized
by the following
> behavior on RMD side:
> - the RMD MUST NOT further accept nor acknowledge
any received message for the 
> specified sequence, even if these were missing
messages sent before the closing occured.
> - a SequenceClosed fault MUST be generated for
each one of these rejected messages.   
> - the RMD must still respond to other sequence-level
operations for this sequence 
> such as requests for acknowledgements
> (AckRequested), closing (which is idempotent).
> </JD>

I'm not comfortable introducting a state machine into
the spec when one isn't
there now.  I did however add some text that
I hope address some of your
concerns.

> 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. 
>  
> <JD> the following paragraph may be subsumed
by my previous rewriting, if accepted </JD>

I think its important to say what should happen to
previously received
messages - this new Fault is very important.

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

>  
> <JD> could replace this last sentence by
a more general: "It indicates that the 
> RM Destination has closed the sequence."
</JD>

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

>  
> <JD> same remark as previous. </JD>

Done

>   /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. 
>  
> <JD> same remark as previous: if we define
a "closed" state, we would mention it here
> instead of always repeating [one of] the effects
of being closed. </JD>

Done
 
>   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. 
>  
> <JD> OK
>  
> 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. 
>  
> <JD> we can address that separately I guess
- the current 
> solution is good enough IMO.</JD>
>  
> 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. 
>  
> <JD> I suspect the concern about InOrder
may just need a more precise
> description of what happens when closing in that
case. </JD>
>  
>  
> thanks, 
> -Doug 
>  
>  
>  
>  
> 
> From: Doug Davis [mailto:dug@us.ibm.com] 
> Sent: Thursday, August 18, 2005 10:50 PM
> To: Jacques Durand
> Cc: Christopher B Ferris; ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] i0019 - a formal proposal
>  
> 
> 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/> 
> 
> 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 
>   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. 
> 
> 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. 
> 
>   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. 
> 
>   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