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 agree with your clarifications. I was making broad brush statements
which you have appropriately qualified.

Is all we are relying on is message integrity preservation in the 
transport layer?

It seems that flow control would be another thing to rely on the 
transport protocol for.

Anyway, we need to get our requirements sorted out in this area.

Tom Rutt
Doug Bunting wrote:
> Tom,
> 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.
> thanx,
>     doug

Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

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