ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: [NEW ISSUE] Reword "Closing a Sequence" section
- From: Matthew Lovett <MLOVETT@uk.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Wed, 2 Nov 2005 14:55:39 +0000
Title: Reword "Closing a Sequence"
section
Description:
Section 3.6 "Closing a Sequence" contains in introduction to
the close operation, and its justification. I think that the current text
would benefit from a rework. Lines 625 - 648 of working draft 05 say:
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 aSequenceAcknowledgement 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 SequenceClosed 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.
Justification: The above text could be clearer.
Target: core
Type: editorial
Proposal:
Replace the above text (lines 625 - 648) with the following:
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. Simply terminating the Sequence discards the state managed
by the RM Destination, leaving the RM Source unaware of the final ranges
of messages that were successfully delivered to the RM Destination. To
ensure that the Sequence ends with a known final state both the RM Source
and RM Destination may choose to 'close' the Sequence before terminating
it.
If the RM Source wishes to close the
Sequence then it sends a <wsrm:CloseSequence> element, in the body
of a message, to the RM Destination. This message indicates that the 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 SequenceClosed 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.
Related issues: None
Thanks,
Matt
--
Matt Lovett, WebSphere MQ Development
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]