[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] i0019 - a proposal: (more complete)
Please see my inline comments below.
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
Jacques Durand <JDurand@us.fujitsu.com> wrote on 08/18/2005 06:17:29 PM:
> To summarize where we are I think in resolving i019 and Proposed-01:
>
> Consensus on:
>
> (a) [for i019] A final SeqAck tagged "final" sent by RMD when it
closes a sequence on Fault .
> The RMS may query to get this Ack again.
yes. we need specific language. Assume by "query" that you mean via a
"naked" AckRequested (no
SOAP body, and wsa:Action=".../AckRequested". I think that we also need to
be precisely clear
what the criteria for when the @final="true" (assume we want it to be a
boolean attribute) to be
required to be set, etc.
> (b) [for Proposed-01] A new "Close" operation (idempotent) for the
RMS to freeze the state of
> a sequence on RMD and return a final Ack.
Yes, and predicated on resolution to i019 as above one would assume.
>
> Still on the table:
>
> (c ) [improving by simplifying] removing LastMessage feature, as it is
kind of subsumed by (b) above.
Think so, yes. I believe that Dug wanted to "sleep" on this still.
Frankly, <LastMessage/> is difficult
to implement unless you expose RM through to the application programming
model and even then, it is often
not until after the fact that you know which message is the last.
What I think is needed is a param in the Close() operation that indicates
whether or not
the RMS wants the RMD to process any further messages in the Sequence, and
also what the
RMS thinks is the highest message number in that Sequence. That way, we
have
effectively preserved the feature that signals to an RMD whether the
Sequence is to be
closed gracefully (normally), or whether it is to be truncated "as is",
etc.
<wsrm:Close ...>
<wsrm:Sequence ...>
[as specified with MessageNumber = highest message number sent]
...
</wsrm:Sequence>
<wsrm:Truncate/>?
<!-- indicates whether the RMD should close gracefully (absent) or
"truncate" the Sequence -->
...
</wsrm:Close>
<wsrm:Closed ...>
<wsrm:SequenceAcknowledgement final="true|false"? ...>
[as specified]
...
</wsrm:SequenceAcknowledgement>
...
</wsrm:Close>
> (d) [needed by i019 to allow querying again for Ack] Sequence faults do
not terminate sequences
> anymore. At best, they "close" them.
I think that as Close() is idempotent, that it can be issued repeatedly
until the RMS
gets a SequenceAcknowledgement with @final="true" in the Closed response.
A question though.
many implementations might find it unnatural to "receive" a Fault in
anything but a response
message. Granted, this is not a constraint of SOAP, but... We could also
provide Close
with the ability to carry Fault information for faults generated by the
RMS.
<wsrm:Close ...>
<wsrm:Identifier>[Sequence Id]</wsrm:Identifier>
<wsrm:MessageNumber>[value of highest MessageNumber
sent]</wsrm:MessageNumber>
<wsrm:Truncate/>?
<!-- indicates whether the RMD should close gracefully (absent) or
"truncate" the Sequence -->
<soap:Fault>[yadda]</soap:Fault> | <soap12:Fault>[yadda]</soap12:Fault>?
...
</wsrm:Close>
Just a thought.
> (e) [improving fault termination case] Sequence Faults to not even
Close a sequence (except for
> "SequenceTerminated" fault) (see my recent mail to Doug D.) Most faults
are "message-scope" faults
> not affecting seq integrity if message ignored. RMS has now choice to
close or not a Faulted sequence.
> (f) [just a resource mgt issue for special case] Use of
TerminateSequence by RMS authorized even
> on non-complete sequences, assuming they have been Closed.
I think that this needs to be raised as a separate issue. I am still
firmly of the belief that
a Sequence operates in AtLeastOnce mode between RMS and RMD. I can see
closing a Sequence that
has gaps only in the case where the RMS is willing to see the Sequence end
with a SeqAck covering
the "complete range" of messages (e.g. it will retransmit unacked
messages) or in the case where
the Sequence has suffered some sort of fault (at either end) that prevents
it from being normally
completed (in which case it is "truncated" as above).
I still do not believe that we should be using the protocol in a manner
other than the one
I have described repeatedly.
>
> Do we agree on this status?
Not quite. Stefan mentioned that he has issues with regards to closing a
Sequence with
gaps in the context of InOrder (if I recall correctly from the call). He
indicated he
would send details of his concerns to the list.
>
> Jacques
>
> From: Jacques Durand
> Sent: Thursday, August 18, 2005 11:33 AM
> To: 'Christopher B Ferris'; ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] i0019 - a proposal: (more complete)
>
> Chris:
> Extracting some of your answers from the logbook...
> >I think more correctly, the RMD, upon receipt of a Close() message MUST
> >NOT process any subsequent messages received for that Sequence that
have a
> >wsrm:Sequence header block belonging to the closed Sequence.
> I think that's a precise statement for describing the Closed semantics.
> >Hmmm... I would be more inclined to eliminate LastMessage, as part of
the
> >proposal to close whichever issue this is related. That way, it can be
> > analyzed in its full glory. I too see Close() as a replacement for
> > <LastMessage/>.
> That is what I meant. I am all in favor of removing LastMessage feature
in this resolution, if
> that's not too much to do for closing this issue.
>
> >i019 Sequence termination on RMD generated Fault
> Better than current title, though I was also pleased with my own
proposal in a past mail:
> - I019: "Accurate final acknowledgement of a Sequence terminated on
Fault by RMD"
> - Proposed-01: "Accurate final acknowledgement of a Sequence with gaps
when RMS decides to stop using it."
>
> ...
> >I disagree, I think that it would be preferable that the
> > SequenceAcknowledgement MUST be marked as "final" to ensure that there
is
> > no ambiguity...
> Sounds good - indeed otherwise there may be some corner cases.
> >I don't quite understand. What rule? To the best of my knowledge, there
is
> > nothing in the spec that says that the TerminateSequence for a given
> > Sequence MUST NOT be sent more than once by the RMS. However, I could
see
> > utility in making it clear that both Close() and TerminateSequence()
> > are idempotent operations and MUST be implemented as such.
> I meant the rule that TerminateSequence can only be used on fully
acknowledged (complete)
> sequences. It is definitely OK to send any of these ops more than once.
Idempotency reflects also
> in what is returned by these ops, if applicable.
>
> Cheers,
> Jacques
> -----Original Message-----
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> Sent: Thursday, August 18, 2005 9:24 AM
> To: ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] i0019 - a proposal: (more complete)
> I've interspersed some comments thoughout this post (including the
> included emails)
> 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
> Jacques Durand <JDurand@us.fujitsu.com> wrote on 08/16/2005 07:50:07 PM:
> > Ooops, backtrack this: something is missing in your proposal Doug,
that
> I didn't catch before:
> > - remember this is the issue where termination is on sequence
> Fault from RMD side: the
> > RMS does not even get a chance to do some closing.
> > - So I think we should also give all Sequence Faults a
> "closing" semantics, rather than
> > an actual "termination" semantics. When getting the Fault, the RMS
knows
> the sequence has closed,
> > but can still send a "close" op to get a final Ack. Then it would have
> to Terminate the sequence
> > (unless it lets inactivity or expiration time kick-in).
> > - Your proposal seems to be more appropriate for the twin
issue
> - reworded Proposed-01
> > -, where RMS just wants the final tab after deciding to not use the
> sequence anymore, regardless
> > of gaps and regardless of termination process (expiration, inactivity,
> or TerminateSequence if allowed here)
> I agree, IMO, i019's title should possibly better reflect the
description,
> which clearly suggests
> that it is concerned with faults generated by the RMD. I would proposed
> re-titling the issue:
> i019 Sequence termination on RMD generated Fault
> I agree that much of the discussion here is probably more relevant in
the
> context of
> proposed issue 01 for this week's call.
>
>
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200508/msg00084.html
> With that said, I still have further comments below.
> >
> > Jacques
> >
> >
> > From: Jacques Durand
> > Sent: Tuesday, August 16, 2005 3:20 PM
> > To: 'Doug Davis'; ws-rx@lists.oasis-open.org
> > Subject: RE: [ws-rx] i0019 - a proposal
> >
> > Doug:
> >
> > Overall that seems to do the trick.
> > More Inline <JD>
> >
> > A related comment:
> >
> > - the use of LastMessage marker appears now like a subcase of
> closing, where the RMD will
> > close if (1) LastMessage was received, (2) all messages before were
> received.
> > - After we are done with i019, I think we should reconsider
how
> useful LastMessage is (I
> > guess a separate issue). My expectation here is to keep the protocol
> simple. At least, I would
> > like i019 and your proposal to NOT be perceived as making the protocol
> more complex... as I
> > believe it makes it possible to trade one feature ("LastMessage") for
> another ("Close").
> Hmmm... I would be more inclined to eliminate LastMessage, as part of
the
> proposal to close
> whichever issue this is related. That way, it can be analyzed in its
full
> glory. I too see
> Close() as a replacement for <LastMessage/>. read on...
> >
> > Cheers,
> > Jacques
> >
> >
> > From: Doug Davis [mailto:dug@us.ibm.com]
> > Sent: Sunday, August 14, 2005 4:26 PM
> > To: ws-rx@lists.oasis-open.org
> > Subject: [ws-rx] i0019 - a proposal
> >
> >
> > For issue 19 we're really dealing with the communication of the state
of
> the sequence between the
> > RMD and the RMS. I think there are two situation we need to think
> about:
> > 1 - a sequence w/o gaps
> > 2 - a sequence with gaps
> >
> > #1 is easy, when the RMS receives an Ack for the full range of
messages
> that it has sent then it
> > knows that the sequence is complete and it can send a Terminate
knowing
> no new messages will be
> > accepted by the RMD. In the absence of an ACK the RMS can always ask
> for one using an
> > AckRequested thereby determine the RMD's state.
> >
> > #2 seems to be the problem child. Lost (or delayed) Acks and Messages
> can play havoc with the
> > RMS's perception of what the final state of the sequence is. For
> example, it may believe that
> > message #3 (out of 6) was lost and doesn't care any more (for some
> reason), so it sends a
> > TerminateSequence.
> >
> > <JD> I thought TerminateSequence can't be sent out unless RMS get all
> messages acknowledged ?
> > (hey, I am not the only one reading the spec in a "lax" way !! ;-)
> Let us assume that for purposes of discussion, #2 is taken in the
context
> of an RMS generated
> fault that results in premature termination of the Sequence by the RMS,
> yet it wants an accurate
> accounting of the final state as perceived by the RMD and it wants to
> ensure that no further messages
> are processed.
> >
> > However, if message #3 is just slow, and arrives at the RMD after the
> sending of the Terminate
> > but before it arrives then the RMD's sequence state will differ from
the
> RMS's. Sending a final
> > Ack back to the RMS might not be sufficient since that might be lost
as
> well.
> >
> > <JD> In fact, the termination case for i019 is more of a SequenceFault
> that, at the time it occurs
> > on RMD, leaves the RMS without an idea whether some missing messages
> were received since it got
> > its last SequenceAck. But the solution is the same.
> >
> >
> > So, I'd like to propose the following:
> >
> > Add a "Final" marker to the SequenceAck header (per Dan's
suggestions).
> The inclusion of this
> > element in the Ack is the RMD's way of telling the RMS that no new
> messages will be accepted into
> > this sequence. This is true regardless of there being gaps in it or
> not.
> > Define a new operation: "Close". The RMS can send a "Close" to the
RMD
> indicating that it would
> > like to shutdown the sequence and request that no new messages be
> accepted. Notice that this is
> > similar to a TerminateSequence in that they both shutdown the sequence
> but unlike a TerminateSeq,
> > the "Close" will not do any resource reclamation - it just halts the
> delivery/processing of any
> > new messages.
> >
> > <JD> semantics of Close is: sequence will reject any future message
(in
> effect freezing its state)
> > except "operation" messages such as Close and TerminateSequence, to
> which it should respond as appropriate.
> I think more correctly, the RMD, upon receipt of a Close() message MUST
> NOT process any subsequent
> messages received for that Sequence that have a wsrm:Sequence header
block
> belonging to the closed
> Sequence.
> >
> >
> > So, going back to situation #2, the RMS wants to close down the
sequence
> despite there being gaps.
> > It will send a "Close" to the RMD, which in turn responds with
"Closed"
> plus an Ack. Note that
> > the Ack will include the "Final" marker.
> >
> > <JD> if the Closed is always accompanied by the SeqAck, then this Ack
> can be considered as final
> > ("Final" marker is only cosmetic).
> I disagree, I think that it would be preferable that the
> SequenceAcknowledgement MUST be marked
> as "final" to ensure that there is no ambiguity... the SequenceAck
*could*
> technically just be
> piggy-backed by the implementation and represent state that is not, in
> fact, final. I believe that
> we would be better served leaving no doubt by making it a requirement
that
> the SeqAck be marked
> "final".
> >
> > If this message (or the Close) is lost the RMS is free to send it
over
> and over until it gets an
> > Ack+Final since processing multiple ones has no negative impact. Upon
> receipt of the Ack+Final
> > the RMS can then safely send a TerminateSequence without fear of any
new
> messages arriving and
> > changing its perception of the gaps in the sequence.
> > <JD> that means we change the rule of usage for TerminateSequence too.
> I don't quite understand. What rule? To the best of my knowledge, there
is
> nothing in the spec
> that says that the TerminateSequence for a given Sequence MUST NOT be
sent
> more than once by the
> RMS. However, I could see utility in making it clear that both Close()
and
> TerminateSequence()
> are idempotent operations and MUST be implemented as such.
> >
> >
> > Note that sending a "Close" for a sequence that doesn't have gaps
> doesn't cause any harm either -
> > its an optional message that _can_ flow right before a
> TerminateSequence.
> > Thoughts? If people like this I'll write up a more formal proposal
> (spec changes).
> >
> > <JD> I'm OK with this.
> > -Jacques
> >
> >
> > thanks
> > -Doug
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]