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 <>
09/06/2005 09:24 PM
To
Doug Davis/Raleigh/IBM@IBMUS,
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:]
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
