[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] AS need for ordered delivery?
Duane: -----Original Message----- Jacques et al: Is it really true that it has to be "received" by the AD in
the order in which it is sent and that your two conditions are required? <JD> that is the DA definition as
written in the core specification, and also how defined in our charter, so
little doubt on this. I am just reporting that sometimes we seem to forget what
these definitions imply :-) as I keep hearing that DAs are just a matter of
RMD/AD. But I do not think that has to be an issue as far as the protocol is
concerned (which is why I don't understand the fuss on "DA = RMD/AD
and no more"...) Why couldn't they be delivered out of order with the order
sequence numbers intact and let the AD (any ultimate destination for that
matter) reconstruct the original message batch and figure out which ones to process
first? I really think the issue of DA's is not relevant to our
specification. We specify a marker than allows any destination to
understand the order of the messages and whether or not some are missing.
Let them figure it out. Where does it stop? Will we start putting
ordering of the SQL statements in reliable messages to ensure certain SQL
inserts are done in order? I say not. <JD> I won't argue with the
details of how DAs should be interpreted (should the App destination do its
part of the reordering or not, etc.) My point I that the InOrder DA, as defined
today, is a contract that involves both AS and AD, and that will remain true regardless
of the interpretation. I think the real goal we are trying to accomplish is to allow the RMD
to reassemble an exact copy of the streams that the RMS transmitted and
understand if it has missed anything (period). Once it has done that, it
can sort out what to do with it when it has satisfactorily ascertained whether
or not it has an accurate stream. Look at TCP for comparison. What we are trying to do at the WS
level is conceptually similar to the patterns and methods specified in
TCP. TCP destinations have the task of "recreating an exact copy of
the data stream generated at the source, at the destination". This
must encompass that the stream be re-created in the same order and with no gaps
or duplicates. The mechanisms used to accomplish this assign a
"unique" sequence number to each byte of data at its source, and to
sort the bytes at the destination according to the sequence number. The
sorting operation corrects any disordering. An acknowledgement, timeout,
and retransmission scheme corrects for data loss. The uniqueness of the
sequence number corrects for data duplication. <JD> I notice though that TCP is
designed - or implemented at least - so that the upper layer does not
have to worry about packet reordering or numbering: so in effect TCP stacks interpret
InOrder the same way we do so far in WS-RM: it is a black-box. Don't you
prefer that to letting the upper layer "figuring it out" with
packets numbers on its hand...? Note that nowhere does it get into what TCP clients or destinations do
with all of this. It is merely an underlying assumption that TCP nodes owners
have taken the appropriate precautions to ensure that the benefits of TCP are
not unceremoniously discarded by poor handling of content once the stream is
recreated. Accordingly, DA's between TCP nodes and what lies beyond are
not really relevant to that specification. If you sent an HTTP get() to a
server and get nothing back or a timeout error, you may guess that there is a
network layer error; if the TCP layer succeeds, and you get back an HTTP error
code, you know the error is higher up. TCP itself does not care about the
HTTP error codes nor should it. The communications are a layered stack
with upper layers depending on lower ones. Likewise, some critical business
functionality that demands an ERP system, a data base and an accounting system
all get 3 messages, in order is probably not something that the WS-RX layer
should see and understand. It is only concerned with the fact that the
outgoing stream can be either 100% accurately reproduced at the destination OR
an error (fault) is thrown to notify participants something did not work. I would argue that we should focus on ensuring WS-RX has all the
mechanics to allow an exact copy of all bytes being transmitted by the RMS to
be received and assembled correctly by the RMD OR, in the alternative, that the
RMD can understand something went wrong and it is missing something.
Mechanisms, contracts etc between the RMD and AD are not something to be judged
by a wire protocol, we just have to ensure that the protocol supports the
things required (which it does). Comments? <JD> I think you should direct
this to the thread on the issue XYZ (don't remember the number) that deals
with deciding what to do with the DA defs w/r to core spec. That's a
deeper issue than what was argued here - namely what place should the DA
have in this TC's workplan, as after all DAs are in our charter. Cheers, Jacques Duane ________________________________________ From: Sent: Wednesday, October 26, 2005 1:17 PM To: 'Marc Goodner'; Cc: ws-rx@lists.oasis-open.org Subject: RE: [ws-rx] AS need for ordered delivery? Fact is, regardless if some agreement is needed about the DA to be
used, InOrder is one of those DAs that actually *always* requires *both*
parties to do a bit more than just using the protocol, meaning both AS/RMS and
RMD/AD contracts. Here is why: For a "message to be delivered in the order it was sent", two
conditions are required: 1-the message must be transmitted (by RMS) in the order it was sent (by
AS) (or at least, must be "sequence-numbered" in this order
)--> contract RMS/AS 2- the message must be delivered (to AD) in the order it was
received (by RMD) --> contract RMD/AD. So far the focus has been on the Destination side, which is the one
doing most of the legwork to achieve this. But the Source side must also do its
part in supporting InOrder. Now I believe that a specification only concerned with protocol RMS-RMD
does not have to worry about this, but a spec detailing the DAs will have to. Jacques |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]