RE: FYI: synch/asynch def from WSRM TC

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.....

Received on Saturday, 24 May 2003 08:58:21 UTC