OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [ws-rx] i019/i028 - final proposal


Rebecca,
  1 - yes, its 596.  :-)
  2- I'm ok with either - I was just following the rest of the spec's example.  If we changed that one we'd need to change all of 'em.  Either way works for me.
thanks
-Doug



"Bergersen, Rebecca" <Rebecca.Bergersen@iona.com>

09/08/2005 03:39 PM

To
Doug Davis/Raleigh/IBM@IBMUS, <ws-rx@lists.oasis-open.org>
cc
"Bergersen, Rebecca" <rebeccab@iona.com>
Subject
RE: [ws-rx] i019/i028 - final proposal





Hi!
 
I agree with your proposal, but have a couple of editorial nits:
 
You say, “After line 396, add a new section ….”  I believe you mean line 596.
You say “The following exemplar defines the CloseSequence syntax:”  Exemplars don’t define.  How about “The following defines the CloseSequence syntax:”  ?
 
(Just making the editors’ job easier….)
 
Regards,
--Becky
 


From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Thursday, September 08, 2005 2:02 PM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] i019/i028 - final proposal
 

Based on Jacques comments I've modified the text to avoid using terms that are not defined in the glossary.  I'm concerned that there are too many version of this proposal out there.  All of the suggestions people have made have been great and I do really think they've helped mold this into a better proposal.  However, when comparing this version with the original one I think the basic idea is still the same.  And for the purposes of the TC voting on this, while a totally complete proposal certainly helps, I don't think it needs to be bullet-proof in order for people to vote one way or the other.  Leaving some of the minor textual changes for the editors allows them to do something too  :-)
So, barring some major change request from someone I'd like this to be the version we vote on.
thanks
-Doug

ps just got Jacques' note about possibly updating the term 'received' in the glossary but I'd prefer to leave that for the editors as well.  With 2 hrs left before the call I need to send something :-)

- - - - - - - -

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 receiving 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.  This element MUST be present when the Sequence    
is no longer receiving new message for the specified sequence.
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 messages to the RM Destination referencing this 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 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 receive any new 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.

While the RM Destination MUST NOT receive any new messages for the
 specified sequence it MUST still process RM protocol messages.
 For example, it MUST 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 receive any new messages for this sequence.  
A SequenceClosed fault MUST be generated by the RM Destination
 when it receives a message for a sequence that is closed.

/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. This fault MUST be generated
 when an RM Destination is asked to receive a message for a sequence
 that is closed.
Properties:    
[Code] Sender  
[Subcode] wsrm:SequenceClosed  
[Reason] The sequence is closed and can not receive new messages.  
[Detail] <wsrm:Identifier...> xs:anyURI </wsrm:Identifier>

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]