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



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