OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ws-rx] AS need for ordered delivery?


Gilbert:

I did infer that from Jacques email and my response, while focused on the RMD->AD is also applicable to the AS->RMS.  There is no requirement for a message to be delivered between the AS and RMS "in order", only that the RMS has the ability to understand how to order the messages for subsequent delivery to the RMD.  

I do not think that the AS-RMS mechanism/methodology should be specified.  Mandating specific implementation scenarios or even patterns between the AS and RMS should be out of scope IMO.  

Implementers of the source stack should be responsible for ensuring that when a "message" leaves an RMS, it is correctly formed with the proper sequence number (period - end of story).  

It is no different that the responsibility to ensure the correct wsa:to, SOAP:header etc.. are all formed correctly.  The communication between the AS and RMS may be in any form that effectively works to ensure that when things are on the wire, they are formatted correctly.  If the RMS knows that the messages have to be in a specific order, the WS-RX has the mechanisms to allow these declarations to be made on the wire.  Feeding the RMS is not something we should do IMO.

Anyways, that is only my lone opinion. Moving forward:

The spec does state:

"The RM Source MUST assign each reliable message a sequence number (defined below) beginning at 1 and increasing by exactly 1 for each subsequent reliable message."

This needs to remain as is IMO since it clearly removes ambiguity as to values for sequence markers and how to interpret them on the RMD.

I think adding a statement that says:

"It is presumed that the RMS always assigns message numbers corresponding to the order in which the AS intends the messages to be ordered.  The exact mechanisms for ensuring such are outside the scope of this specification."

would clarify the issue.

This still leaves open the exact semantics of what "in order delivery" means.  Does it mean processed by some entity behind the service?  Again, I find this confusing as do others.

Duane



-----Original Message-----
From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com] 
Sent: Thursday, October 27, 2005 10:40 AM
To: Duane Nickull
Cc: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] AS need for ordered delivery?

Duane,

I think you missed Jacques' point about the role of the RMS in inorder delivery. The RMS can send the messages in any order it wants (and/or the RMD can receive them out of order and/or the RMD can deliver them to the AD out of order) *provided* the messages are correctly numbered in the first place. However, if the AS sends the RMS messages A, B, and C (in that order) and the RMS (for some reason) numbers them A-1, B-3, C-2 there is *nothing* the RMD or AD will ever be able to do to restore the original A, B, C order. It is clear that the AS->RMS contract is therefore a part of inorder delivery and it is *not* true that all DAs are solely a matter of the RMD->AD contract.

This whole issue can be sidestepped if you) but that's not what the spec currently says. The spec says:

The RM Source MUST assign each reliable message a sequence number (defined below)
beginning at 1 and increasing by exactly 1 for each subsequent reliable message.

Which is sort of close, but not really specific about whether the "subsequent" part applies to the messages coming in from the AS or going out to the RMD (it also makes use of the phrase "reliable message" which, as Chris asserts, is a non-existent entity).

- g

> -----Original Message-----
> From: Duane Nickull [mailto:dnickull@adobe.com] 
> Sent: Wednesday, October 26, 2005 1:47 PM
> Cc: ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] AS need for ordered delivery?
> 
> 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?  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.
> 
> 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.
> 
> 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?
> 
> Duane
> 
> 
> 
> ________________________________________
> From: Jacques Durand [mailto:JDurand@us.fujitsu.com]
> Sent: Wednesday, October 26, 2005 1:17 PM
> To: 'Marc Goodner'; ashok.malhotra@oracle.com; Gilbert Pilz; 
> Duane Nickull; Anish Karmarkar
> 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]