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: On behalf of Mark Little: FYI: synch/asynch def from WSRM TC


Mark Little asked me to forward this to the list...

 Just though people might be interested in what the W3C architecture
 group think of the async/sync definitions.
 
 Mark.
 
> ===== Original Message From Christopher B Ferris
> <chrisfer@us.ibm.com> 
> =====
 I'm not convinced that it is a valid definition. It makes an
 assumption about
 the blocking nature of the HTTP protocol, which is simply not the
 case for all usages.
 
> From sect 8.1.1 of RFC2616:
 
      - HTTP requests and responses can be pipelined on a connection.
         Pipelining allows a client to make multiple requests without
         waiting for each response, allowing a single TCP connection
         to be used much more efficiently, with much lower elapsed
 time. 
 
 and
 
 8.1.2.2 Pipelining
 
    A client that supports persistent connections MAY "pipeline" its
    requests (i.e., send multiple requests without waiting for each
    response). A server MUST send its responses to those requests in
    the same order that the requests were received.
 
 While it is true that there is a caveat against using non-idempotent
 methods, it is only a SHOULD
 and not a MUST. Hence, HTTP pipelining could be leveraged and their
 definition would be just plain
 wrong.
 
 IMO, they would have been better served to give their patterns names
 that did not
 use the terms synchronous or asynchronous, but rather something like:
 
         HTTP Response Acknowledgement Pattern
         Callback Acknowledgement Pattern
 
 Note that there are really only two patterns. Their "polling" pattern
 is no different than their "synchronous" HTTP binding other than the
 fact that the request in the second case is an explicit request for
 an acknowledgement
 as opposed to a reliable message delivery request message (which
 could carry an acknowledgement request, making it identical to the
 former). 
 
 Cheers,
 
 Christopher Ferris
 STSM, Emerging e-business Industry Architecture
 email: chrisfer@us.ibm.com
 phone: +1 508 234 3624
 
 www-ws-arch-request@w3.org wrote on 05/24/2003 03:14:03 AM:
 
> Maybe so, but it looks like a perfectly valid definition and it
> covers very common and important usage cases.  Our document
> currently, without qualification, recommends that the terms not be
> used in normative specs.  It appears that this group is perfectly
> happy to do so and I see no reason in the world for them not to. 
> 
> -----Original Message-----
> From: Geoff Arnold [mailto:Geoff.Arnold@sun.com]
> Sent: Friday, May 23, 2003 8:12 PM
> To: Ugo Corda
> Cc: www-ws-arch@w3.org
> Subject: Re: FYI: synch/asynch def from WSRM TC
 
> 
 
> On Friday, May 23, 2003, at 09:02 PM, Ugo Corda wrote:
> 
> I thought somebody might be interested in that group's definition
> at [1]. (The definition is limited to the SOAP HTTP binding case).
> 
> Ugo
> 
> [1] http://lists.oasis-open.org/archives/wsrm/200305/msg00062.html
> 
> Well, yes, as you say: it's limited to HTTP. It doesn't apply to
> MEPs; 
 can't address multiparty (obviously)
> or composite interactions.....



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