ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ws-rx] i0019 - a formal proposal
- From: Doug Davis <dug@us.ibm.com>
- To: Jacques Durand <JDurand@us.fujitsu.com>
- Date: Fri, 19 Aug 2005 01:50:23 -0400
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/>
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.
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 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.
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.
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. 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.
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.
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.
/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.
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]