RE: [ws-rx] i019 - Proposal #5

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

Jacque,
  You're correct that using additional
terms might lead to confusion - and I need to me more careful about that.
 What if I simply used the term "receive" instead, and tried
to avoid using the term "application message"?  So, for
the example you sited it would be:  ...to the RM Destination to indicate
that the RM Destination MUST NOT receive any new messages for the specified
sequence.

thanks
-Doug

Jacques Durand <JDurand@us.fujitsu.com>

09/06/2005 09:24 PM

To	Doug Davis/Raleigh/IBM@IBMUS, ws-rx@lists.oasis-open.org
cc
Subject	RE: [ws-rx] i019 - Proposal #5

Doug:
 
Rereading your proposal end-to-end,
 a couple of lingering concerns on the terminology side:
 
1. The proposal uses at quite
a few places the term "accept" : e.g. "  ... to
the RM Destination to indicate that    
  RM Destination MUST NOT accept any new application messages."
The reliance on an intuitive
meaning of what "accept "means could lead to some misinterpretation:
we all understand that a message could be "Received"  yet
not "Accepted" . Although it is implied that a non-accepted message
shall not be acknowledged, that is not very clear, as the specification
only associates Ack semantics with "successful message reception"
.  One way to clarify this  is to add in the Glossary: "
message acceptance: commitment to process the message further beyond reception,
including acknowledging it." Also, in Section 3.2 beginning: "...The
RM Destination informs the RM Source of successful message receipt using
a
<SequenceAcknowledgement> header
block."  Shouldn't
 we add "and acceptance" after "receipt".
 
2. I thought we had defined
this before: "application message: a message containing a wsrm:Sequence
header". (also candidate for the Glossary).
 
I'd vote for the proposal even
without these precisions, but then would have to file additional editorial
issues here...
 
Jacques

---

From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Monday, September 05, 2005 5:05 PM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] i019 - Proposal #5
 

DougB proposed some good editoral fixes.  Picked up the change about
when Close should be used, removed the bit about InOrder+ExactlyOne DA,
and the typo he noticed. 
thanks 
-DougD 

__________________   



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 the 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, CloseSequence and TerminateSequence
  
  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 or RM Destination will wish to discontinue using a Sequence
  
  even if some of the messages have not been successfully delivered
  
  to the RM Destination.   

  In the case where the RM Source wishes to discontinue use of a 
  sequence, while it 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:CloseSequence>
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, other than those already received at the time
  the <wsrm:CloseSequence> element is interpreted by the RMD.
 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, TerminateSequence as
well as   
  CloseSequence messages.  Note, subsequent CloseSequence messages
have no   
  effect on the state of the sequence. 

  In the case where the RM Destination wishes to discontinue use of
a
 sequence it may 'close' the sequence itself.  Please see wsrm:Final
 above and the Sequence Closed fault below. Note the SequenceClosed
 Fault SHOULD be used in place of the SequenceTerminated Fault, 
 whenever possible, to allow the RM Source to still receive 
  Acknowledgements. 

  The following exemplar defines the CloseSequence syntax:  
    <wsrm:CloseSequence wsrm:Identifier="xs:anyURI"/>
    

  /wsrm:CloseSequence  
  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:CloseSequence@Identifier   
  This required attribute contains an absolute URI conformant  
  
  with RFC2396 that uniquely identifies the sequence.  

  /wsrm:CloseSequence/{any}    
  This is an extensibility mechanism to allow different (extensible)
    
  types of information, based on a schema, to be passed.    
    
  /wsrm:CloseSequence@{any}  
  This is an extensibility mechanism to allow additional attributes,
    
  based on schemas, to be added to the element.   

  A <wsrm:CloseSequenceResponse> is sent in the body of a response
message by     
  an RM Destination in response to receipt of a <wsrm:CloseSequence>
request   
  message.  It indicates that the RM Destination has closed the
  
  sequence.   

  The following exemplar defines the <wsrm:CloseSequenceResponse>
syntax:     

  /wsrm:CloseSequenceResponse  
  The element is sent in the body of a response message by  
  
  an RM Destination in response to receipt of a <wsrm:CloseSequence>
request   
  message.  It indicates that the RM Destination has closed the
  
  sequence.   

  /wsrm:CloseSequenceResponse/{any}   
  This is an extensibility mechanism to allow different (extensible)
    
  types of information, based on a schema, to be passed.    
    
  /wsrm:CloseSequenceResponse@{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 the 
  specified sequence has been closed. 
  Properties:    
  [Code] Sender   
  [Subcode] wsrm:SequenceClosed   
  [Reason] The sequence is closed and can not accept new messages.
  
  [Detail] <wsrm:Identifier...> xs:anyURI </wsrm:Identifier>

Add the proper XML to the schema and WSDL....  

thanks,     
-Doug