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:]
Sent: Monday, September 05, 2005
5:05 PM
To:
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
