[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] i0019 - a formal proposal
|
Sorry I missed that email... I think
it is pretty close - mostly have some editorial suggestions, See inline <JD>. This text is addressing i028 (the twin
issue) so far. For i019, (after all that is the subject
of this email...) I still think we need to say that sequence Faults do not
directly terminate a sequence, but only close it at best (in that case, a "final"
SequenceAck must be sent within the Fault). Cheers, Jacques 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/> <JD> or:
<wsrm:Final/>? (optional)</JD> 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. <JD> mostly editorial: The statement "Any
attempt to deliver additional messages to this sequence MUST generate
a SequenceClosed fault by the RM Destination. "
is already in the Closing a Sequence section. We do not need to have it here too (it
seems kind of marginal to "Final") </JD> 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 ... <JD> shouldn't it be
more precisely: "When the RM Source has
completed its use of the Sequence, and usually after the sequence has been
closed, it sends a ... " </JD> 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. <JD> should we say:
"is free to Close and Terminate ..." instead of "is free to Terminate
..." </JD> 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. <JD> it is mostly
editorial, but to avoid any confusion, we need to be clear about what "use of the
sequence" means: does it include the possible subsequent querying of Acks? (e.g. with
AckRequested) if not, I'd rather say that: - indication of end of use
[for message transfer] = Closing - indication of resource
release = Terminate </JD> 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. <JD> because of
ambiguous "new message" (it also concerns "old messages" still in flight...)
and in order to make it easier to describe the behavior expected, (because
this behavior may also take place when closing occurs in other ways than the
<Close> element, e.g. due to some Fault) I'd introduce more
abstractly the notion of "closed" state: "To alleviate this, the
RM Source can send a <wsrm:Close> element, in the body of a
message. Once this element is interpreted by the RMD, the sequence is closed. The
closed state is characterized by the following behavior on RMD side: - the RMD MUST NOT further
accept nor acknowledge any received message for the specified sequence, even if
these were missing messages sent before the closing occured. - a SequenceClosed fault
MUST be generated for each one of these rejected messages. - the RMD must still respond to other
sequence-level operations for this sequence such as requests for
acknowledgements (AckRequested), closing (which is idempotent). </JD> 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. <JD> the following
paragraph may be subsumed by my previous rewriting, if accepted </JD> 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. <JD> could replace
this last sentence by a more general: "It indicates that the RM Destination has closed
the sequence." </JD> 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. <JD> same remark as
previous. </JD> /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. <JD> same remark as
previous: if we define a "closed" state, we would mention it here instead of always repeating
[one of] the effects of being closed. </JD> 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. <JD> OK 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.
<JD> we can address
that separately I guess - the current solution is good enough IMO.</JD> 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. <JD> I suspect the
concern about InOrder may just need a more precise description of what happens
when closing in that case. </JD> thanks, -Doug From: Doug Davis
[mailto:dug@us.ibm.com]
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]