i0019 - a formal proposal - take 2

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

Based on feedback from Anish, Jacques
and Chris here's an update.

All - I'd like to make it clear that
I believe this proposal covers both issues i019 and i028. I think it covers
i019 because it changes the semantics of the faults so that they don't
terminate the sequence.

There has been a lot of discussion,
mainly between Jacques and Chris, concerning whether RM can/should/does
support the AtMostOnce mode - this proposal DOES NOT address that issue
at all.  Based on reading i019 I don't think it related and if there
is some change needed to the spec related to AtMostOnce then I think a
new issue should be opened.  I'm mentioning this because some people
have indicated to me (off-line) that there might be some confusion as to
whether or not the AtMostOnce discussion is part of this proposal - and
it is not.

thanks
-Doug


__________________



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: 

Change lines 340-347, the SeqAck syntax, to:
<wsrm:SequenceAcknowledgement ...>
  <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier>
  [ <wsrm:AcknowledgementRange ...
      Upper="xs:unsignedLong"
      Lower="xs:unsignedLong"/>
+
    <wsrm:Final/> ?
  | <wsrm:Nack> xs:unsignedLong </wsrm:Nack>
+ ]
  ...
</wsrm:SequenceAcknowledgement>

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.
  Note: this element MUST NOT be used when sending
a Nack, it 
  can only be used when sending AcknowledgementRanges.

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 its use of
  the sequence when all of the messages in the
Sequence have been 
  acknowledged.  However, the RM Source
is free to Terminate 
  or Close 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, i.e. it will not attempt
to send any
  additional application messages to the RM Destination.
 RM protocol
  messages, e.g. AckRequested, Closed and Terminate,
may still be sent.

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

  While the RM Destination MUST NOT accept any
new application messages
  it MUST still accept and process RM protocol
messages.  For example,
  it MUST accept and respond to AckRequested,
Terminate as well as
  Close messages.  Note, subsequent Close
messages have no effect on the 
  state of the 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
has closed 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
has closed 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 closed.
  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