ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ws-rx] i0019 - a proposal: (more complete)
- From: Doug Davis <dug@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Mon, 29 Aug 2005 20:44:09 -0400
In some ways its really just a syntax
difference. And there's part of me that doesn't really care
which way we go. But there's another
part of me that puts Close on par with CreateSequence
and Terminate as something more 'serious'
than these informational ACKs that flow around.
So for now I'm in the 'new operation'
camp. But if the majority of the TC wants to go the other
route I can be swayed. Hmmm, it
should probably be CloseSequence and not Close to
be consistent.
thanks
-Doug
Shivajee Samdarshi <shivajee@tibco.com> wrote
on 08/29/2005 08:14:05 PM:
> Jacques,
> Anytime you can reduce the number of message types,
it is always a good thing :-)
>
> More specifically,
> - In its current usage AckRequested may change the state at the RMD
anyway, e.g.,
> it may cause the RMD to start generating NAKs. So, I don't see the
fact that it
> affects the sequence state to be a big issue.
> - The purpose of Close is to make sure that the RMS and RMD are reconciled
i.e.
> messages and corresponding acks are delivered. Using AckRequested
seems to be
> appropriate for that.
> - I don't see an issue with processing order between headers and body
because both
> Sequence and the AckRequested are carried as headers. There may be
an issue with
> the order in which Sequence and AckRequested headers get processed
but this is an
> issue that already exists independent of this proposal.
>
> Regards
> Shivajee.
>
> Jacques Durand wrote:
> Shivajee:
> I had considered something like this, and I know
Doug had too. That would work, but
> I guess the tradeoff is a design that is a bit less consistent:
> - AckRequested would then do much more than what
it is supposed to do (would affect
> sequence state).
> - Closing is a significant sequence operation,
that normally should be designed the
> same way as CreateSequence, TerminateSequence were.
> - the AckRequest can be bundled. The semantics
of the processing order between
> headers and body becomes now important.
>
> Regards,
> jacques
>
>
> From: Shivajee Samdarshi [mailto:shivajee@tibco.com]
> Sent: Wednesday, August 24, 2005 5:53 PM
> To: ws-rx@lists.oasis-open.org
> Cc: Dan Leshchiner
> Subject: [LIKELY JUNK]Re: [ws-rx] i0019 - a proposal: (more complete)
>
> Here is a modification to this proposal that
avoids having to add a new "Close" message.
>
> As I understand it, the purpose of the "Close" message is
two fold - one, is to
> notify the destination that there will be no more new messages on
this sequence and
> two, is to solicit a final set of acks from the destination.
>
> There is already an "AckRequested" message that allows the
sender to solicit acks
> from the destination. By adding a "Final" element with an
optional "Complete"
> attribute to the "AckRequested" message we should be able
to achieve what is
> proposed via the "Close" message.
>
> <wsrm:AckRequested ...>
> <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier>
> <wsrm:MessageNumber> xs:unsignedLong </wsrm:MessageNumber>
?
> <wsrm:Final Complete=xs:boolean?.. /> ?
> </wsrm:AckRequested/>
>
> Doug Davis wrote:
>
> Jacque (et al),
> I'd like to hear your feedback on my formal proposal: http://www.oasis-open.
> org/apps/org/workgroup/ws-rx/email/archives/200508/msg00160.html
> thanks
> -Doug
>
>
> Jacques Durand <JDurand@us.fujitsu.com>
> 08/23/2005 08:19 PM
>
> To
>
> Christopher B Ferris/Waltham/IBM@IBMUS, ws-rx@lists.oasis-open.org
>
> cc
>
>
>
> Subject
>
> RE: [ws-rx] i0019 - a proposal: (more complete)
>
>
>
>
>
>
>
>
>
>
> Updating the M.O.U. for resolution of i019 and i028, based on feedback
from Chris:
> NOTE: I personally think the closing option <wsrm:Truncate/>?
(remnant of
> "LastMessage") (proposed renamed wsrm:Complete/> here,
see (e)) has little value
> and makes implementation more complex. But maybe I just miss a use
case.
> (a) [for i019 and i028] A new SeqAck boolean
attribute @final is defined, and set
> to "true" by RMD only when sending Acks for a closed sequence.
> (b) [for i019 and i028] The "Closed"
state for a sequence, is defined as:
> - the sequence will not accept anymore any message with a wsrm:Sequence
header
> block for this sequence.
> - the RMD will still respond to other sequence-level operations for
this sequence
> (Ack requests, close op, terminate op)
> - any SeqAck sent back for such a sequence is
tagged "final" (see (a)). Regardless
> of how the closing occurred (fault, request..) the RMS may query to
get this final
> Ack again (e.g. by sending a "naked" AckRequested - no SOAP
body, and wsa:
> Action=".../AckRequested". Or by sending a Close operation
which is idempotent.)
> (c) [for i019] When a sequence fault is
raised by RMD, the RMD may close the
> sequence (depending on the fault), but will never directly terminate
the sequence.
> Along with a fault that just closed a sequence, a final SeqAck (see
(a)) is sent
> back. The closing that takes place due to a fault is same as without
<wsrm:
> Complete> option in <wsrm:Close> (see (e)).
> (d) [for i028] A new "Close" operation
(idempotent) for the RMS to close a sequence
> at any time. A final Ack is returned as response to the operation.
> Request message will contain:
> <wsrm:Close ...>
> <wsrm:Sequence ...>
> [as specified with MessageNumber = highest message number
sent]
> ...
> </wsrm:Sequence>
> <wsrm:Complete/>?
> <!-- indicates whether the RMD should close gracefully (absent)
or
> "truncate" the Sequence -->
> ...
> </wsrm:Close>Response will contain:
> <wsrm:Closed ...>
> <wsrm:SequenceAcknowledgement final="true|false"?
...>
> [as specified]
> ...
> </wsrm:SequenceAcknowledgement>
> ...
> </wsrm:Close>
> (e) removing LastMessage feature, as it is kind
of subsumed by the new Close
> operation. The presence of <wsrm:Complete/>? element (which
is the Boolean opposite
> of <wsrm:Truncate/>? element Chris introduced) in <wsrm:Close>
will cause the
> closing to be effective only when no message is missing below the
greatest seqnum
> received so far at the time the closing request is received (meaning
the sequence
> is complete). If <wsrm:Complete/>? Is absent in <wsrm:Close>,
the sequence would
> be closed immediately by RMD (no laggard message accepted.)
> ---- remaining to be discussed later, possibly
as another issue or predicated to
> pending discussions and use cases:
> (f) [improving fault termination case] Sequence
Faulted by RMD to never terminate
> directly a sequence, and 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 the
faulty message is just
> ignored (but faulted). RMS has always the choice of closing or not
a Faulted sequence.
> (g) [just a resource mgt issue for special case]
Use of
> TerminateSequence by RMS authorized even on non-complete sequences,
assuming they
> have been Closed.
> Regards,
> Jacques
>
> -----Original Message-----
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> Sent: Thursday, August 18, 2005 4:34 PM
> To: ws-rx@lists.oasis-open.org
> 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]