[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] i0019 - a formal proposal
Comments inline.
Cheers,
Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295
Doug Davis/Raleigh/IBM wrote on 08/25/2005 08:36:49 AM:
> Anish,
> comment inline.
> thanks
> -Doug
>
> Anish Karmarkar <Anish.Karmarkar@oracle.com> wrote on 08/25/2005
02:15:18 AM:
>
> > I have some friendly (I hope) ammendment/suggestions below.
> >
> > HTH.
> >
> > -Anish
> > --
> >
> > Doug Davis wrote:
> > >
> > > 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/>
> > >
> >
> > Couldn't this be an attribute on the wsrm:SequenceAcknowledge element
> > (in the spirit of optimizations that Chris had sent earlier)?
>
> Yes, if we pick up Chris' changes then we should that.
+1
>
> > We also should say that wsrm:Final MUST NOT be present if wsrm:Nack is
> > present. I.e., a RM Dest should not nack a message (or messages) and
> > include the wsrm:Final marker -- which does not give the RM Sender any
> > idea as to what message have been received by the RM Dest.
>
> Good point. Since a NACK doesn't make any statement about any other
> message # in the sequence, a Final on a NACK could lead to some very
> bad misinterpretation of the state of the sequence.
+1
>
> > > 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
> >
> > We would probably want to say more than 'new messages'. Something
along
> > the lines of '... indicates that the RM Destination will not deliver
any
> > message that is not listed in the acknowledgement, to the Application
> > Destination.
Seems to me that we need to make it abundantly clear that once an RMD
has issued such a SeqAck, any received message with a <Sequence> element
belonging to the Sequence identified by the SeqAck MUST be silently
ignored by the RMS. We do need to permit AckRequested as well as Close()
and Terminate() messages for the Sequence though... it is only those
messages
that carry a Sequence header that are affected.
> If the point is to make sure that even retries of Ack'd messages are
> not delivered then perhaps it should be more like:
> ..indicates that the RM Destination will not accept or process
> any further messages for the specified sequence.
> But I'm not sure if that's any better than the original. It all
> means the same thing to me. :-)
See comment above.
>
> > > 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.
> > >
s/will complete it use of/will complete its use of/
> >
> > I thought we were distinguishing between terminating a sequence (which
> > requires acks for all the messages) and closing a sequence.
> > If that is so, then the text around terminating the squence should not
> > change.
> Yes but I wanted the spec to be clear that you don't need to wait for
> a sequence to be fully ACKd before you send a terminate. The old
version
> of the text implied you should only send a terminate after all acks have
> been received, IMO.
+1
>
> > > 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.
> >
> > Similar to my comment above, I would like to suggest that we talk
about
> > 'delivery' to Application Destination rather than 'accepting any new
> > message'. Also, the 'MUST NOT' should be after the SeqAck with a
> > wsrm:Final marker has been sent by the RM Dest and not after the
> > wsrm:Close is received by the RM Dest (as it is untestable).
> I think all we can really talk about is whether or not the RM
destination
> can accept/process messages - the delivery of the messages from the
> RMD to the AppDestination is out of scope of the spec.
+1
> Not sure about the 2nd part...the Close() is a way to trigger the MUST
NOT
> so I'm not sure why that isn't testable. Send a Close(), next SeqAck
> received MUST have a "Final" and any future SeqAcks should not have new
> ranges no matter what messages are retried.
+1
>
> > >
> > > 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.
> >
> > Does it have to? Why?
> > Can it not just ignore the lower-numbered messages that are received
> > after the final ack is sent? For example, a message that was sent
> > earlier than the 'close' message may be received after the 'close'
> > message. In such a case, wouldn't it be more efficient to just ignore
> > the message.
> This text is for the case where you sent 5 messages but message 3 is
> lost. If a Close() is sent I don't believe that messages 4 and 5 should
> be delivered to the Dest.App. since message 3 was never recieved. In
> this case the only think that makes sense to me is to generate a fault
> for message 4 and 5 just as if they had arrived late to the RMD -
meaning
> a SequenceClosed fault.
I guess I'm with Anish... I don't see why this is necessary. I think that
we should make it clear that as per the InOrder DA requirement, since
there
is a gap below, that the messages MUST NOT be delivered for processing by
the
AD.
Consider that the SeqAck has already acknowledged that the messages had
been received, seems to me that subsequently receiving a fault on the
ack'ed
messages might confuse the RMS.
> The RMS can know for sure that all messages in the first Ack range
(meaning
> up to the first gap) have been successfully delivered/processed and
anything
> higher was not.
This is true regardless of whether they are faulted or not so long as the
InOrder DA is applied consistently (as it should be).
> Oh, if you're asking why generate a Fault instead of just ignore it,
then
> I think its important that we don't just ignore messages - when possible
> if a message is not going to be processed by the RMD there should be an
> attempt to notify the RMS.
I think I'd have to disagree. See comment above.
>
> > I'm also wondering if we need the wsrm:Close? We could change the
> > wsrm:TerminateSequence schema to have something like a abnormal='true'
> > or immediate='true' attribute.
> Since Terminate is a one-way and all SeqAcks are not sent reliably we
> have no way to guarantee that the RMS knows the true final state of the
> seq w/o some explicit hand-shaking between the two parties. And since
> a Terminate allows the RMD to completely forget about everything we need
> some way for the RMS to get this final state (possibly asking for it
> many times in the case of a bad network) before the RMD forgets.
+1
>
> > >
> > > 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]