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


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

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

Subject: Re: [wsrm] Assumptions of the Transport Protocol Layer


I slightly disagree in a few of the details you provided.  Please see 
below, most of which is additional food for thought.

On 11-04-2003 13:13, Tom Rutt wrote:
> At the last WSRM TC meeting we initiated discussion on the assumptions 
> the requirements should make on the Transport Protocol capabilities.
> It was stated that the Co-sponsors assumed TCP under HTTP.
I think it was stated that we assumed a protocol at least that good, not 
necessarily exactly that configuration.

> There were some statements that TCP connections give flow control, and 
> sequencing capabilties already.
> However, we need to address reliability at the app to app level.
Or, in a message and not packet granularity.

> Even if the http layer implements use of Persistent TCP connections, the 
> sending app does not know if the receiving app received the message 
> successfuly, when the TCP layer signals a connection failure.
In some cases, this is a toolkit problem.  Most HTTP toolkits hide TCP 
level detail, such as where in the outbound or inbound stream the system 
encountered an error, from the application.  The other part of this 
issue comes back to the intermediates expected in future SOAP 
deployments.  TCP reliability gets packets from one point to another but 
does not help with end to end assurances except as it reduces the 
frequency of problems.

> Another concern is that the WS-RM sender may use more than one TCP 
> connection for its  outgoing message sequences.   Thus, when sequences 
> of sent messages span multiple transport connections, the messages can 
> arrive out of sequence, or succeeding on one message while failing on a 
> subsequent message.
Issues with ordering dependencies also arise with unpredictable 
store-and-forward intermediaries.  On the other hand, we need a clear 
use case for handling multiple outstanding (unacknowledged) requests in 
parallel.  This use case doesn't exist in the WS-Reliability starting 
point though we did do technical work on a solution.


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