Doug:
few comments inline <JD>
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Thursday, August 25, 2005
6:55 AM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] i0019 - a formal
proposal - take 2
Based on feedback from Anish, Jacques and Chris here's
an update.
All
- I'd like to make it clear that I believe this proposal covers both issues
i019 and i028. I think it covers i019 because it changes the semantics of the
faults so that they don't terminate the sequence.
<JD>
I am still not sure for the faults not terminating sequences (assumption we
need for resolving fully i019) can you point me at where that would be taken
care of? (maybe I missed the part)
There has been a lot of discussion, mainly between
Jacques and Chris, concerning whether RM can/should/does support the AtMostOnce
mode - this proposal DOES NOT address that issue at all. Based on reading
i019 I don't think it related and if there is some change needed to the spec
related to AtMostOnce then I think a new issue should be opened. I'm
mentioning this because some people have indicated to me (off-line) that there
might be some confusion as to whether or not the AtMostOnce discussion is part
of this proposal - and it is not.
<JD>
agree, we can separate these issues, at least for the sake of our resolution
process.
thanks
-Doug
__________________
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:
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, Closed and Terminate, 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 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 application 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.
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, Terminate as well as
Close
messages. Note, subsequent Close messages have no effect on the
state
of the 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.
<JD>
it is important to also say that it should not acknowledge them either.
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 has closed 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 has closed 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 closed.
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