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

Actually CORBA has two asynchronous messaging modes, one is Notification, which is a straight pub/sub architecture and the other is Asynchronous Method Invocation (AMI) in which the request is "pickled" for later invocation as an RPC.  Some vendors (including IONA) provide a mapping of JMS to Notification for asynch messaging.

Eric

-----Original Message-----
From: Anne Thomas Manes [mailto:anne@manes.net]
Sent: Sunday, March 16, 2003 11:30 AM
To: Www-Ws-Arch@W3. Org
Subject: RE: Friendly amendment #2c [Re: Straw poll on "synchronous"
definitions]



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:47:11 UTC