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

Just to beat the dead horse to illustrate my point...

Even the notification messages are synchronous (unless you provide a
mechanism to queue them up). i.e., if the application isn't running, it
won't receive the notifications. The retrival of the information associated
with the notification is asynchronous (assuming that the information is
maintained in a queue -- rather than implemented using a callback).

The point is IIOP is a synchronous protocol, as is HTTP. MQ is an
asynchronous protocol, as is SMTP. A SOAP runtime system can support
asynchronous behavior over any protocol if it provides a mechanism to
persist messages for later delivery.

Anne

> -----Original Message-----
> From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com]
> Sent: Sunday, March 16, 2003 11:47 AM
> To: Anne Thomas Manes; Www-Ws-Arch@W3. Org
> Subject: 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 12:05:22 UTC