W3C home > Mailing lists > Public > www-ws-arch@w3.org > March 2003

RE: Friendly amendment #2c [Re: Straw poll on "synchronous" definitions]

From: Anne Thomas Manes <anne@manes.net>
Date: Sun, 16 Mar 2003 11:29:30 -0500
To: "Www-Ws-Arch@W3. Org" <www-ws-arch@w3.org>
Message-ID: <ECEDLFLFGIEENIPIEJJPAEFBDMAA.anne@manes.net>

Further thoughts on the CORBA "asynchronous" example:

Actually, even the callback is a synchronous exchange. The service must be
available at the time that the client requests the callback. A more accurate
way to describe the interaction is that the CORBA "asynchronous" invocation
breaks one synchronous request/response interaction into two synchronous
request/response interactions. The first is submit request/receive callback
key. The second is submit callback key/receive response.

Anne

> <atm>
> Even in one-way messages, the sender and receiver are still
> "exchanging" a message. I don't believe that "exchange"
> necessarily implies a reciprocal exchange.
>
> The point that I was making is that synch/asynch is not a
> function of the type of MEP. It is purely a function of whether
> or not there is a mechanism to store the message for later
> delivery. A message is synchronous if such a facility does not
> exist. If the receiver is not available to receive the message at
> the time that the sender sends the message, the transmission
> fails. A message is asynchronous if such a facility does exist.
> If the receiver is not available to receive the message at the
> time that the sender sends the message, the message will be
> persisted and delivered at a later time.
>
> Many people use the term "asynchronous" to also refer to blocking
> versus non-blocking, but technically, this is a separate issue,
> and a source of confusion for the use of the term "asynchronous".
> For example, using the CORBA "asynchronous" invocation feature,
> your can send a request, go perform other functions while the
> request is being processed, and when you're ready to get the
> results, use a callback feature to retrieve the results. In this
> situation the request is synchronous (the service must be
> available to receive the request when the client sends it) and
> the response is asynchronous (the client can retrieve the
> response at a later time).
>
> Compare this to a blocking invocation using an asynchronous
> transport such as an MQ system. MQ systems are by default
> asynchronous. The sender sends the message to a persistent queue.
> The receiver retrieves the message from the persistent queue.
> There is no requirement that the receiver be available at the
> time the sender sends the message. Even so, an MQ application can
> send a message and then wait idly for a response (simulating
> synchronous behavior).
> </atm>
Received on Sunday, 16 March 2003 11:28:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:16 GMT