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

Yeesh -- ok, when notification messages are persisted they are asynchronous, and CORBA notification gives that option, despite the fact it uses IIOP.  Sychronous transports can be used to implement asynchronous protocols and vice versa.  After a while in this debate you get down to the silicon level, where everything is asynchronous, yet synchronous behaviors are implemented using acks.  It's all a question of how many acks you put in, and where ;-).

Anyway, HTTP may be synchronous, but not in the same way as IIOP.  IIOP has been defined to support RPC, whereas HTTP was not.  

The difference is clear when thinking about the application's view of RPC, since the definition of RPC means the application doesn't see the difference between a local and a remote procedure call.  IIOP supports that notion but HTTP does not.  

SOAP is built on a peer-to-peer messaging paradigm.  RPCs can be layered on peer-to-peer, but to implement the paradigm persistent sessions or "conversations" are necessary, and these don't exist in HTTP (for all the good reasons often mentioned on this list).

The SOAP authors say that other qualities of service may be inherited from the transport, but without including such things as correlation it's very hard to make the argument that RPCs can be supported transparently -- meaning if you add IDs to the SOAP header to support correlation then the implementation is by definition non-standard.

SOAP messages are XML documents and can easily be stored in queues for queue-based communication, but describing this as asychronous is not as useful as describing the properties of queue based communications from the application point of view (i.e. there's an "intermediate" object between sender and receiver in which the message is persisted).

So overall I'd say it would help if we could raise the discussion up a level and describe things from the application or program (i.e. agent) point of view rather than the transport point of view, since the transport can be "synchronous" while the agent's view may well be "asynchronous."

Eric

-----Original Message-----
From: Anne Thomas Manes [mailto:anne@manes.net]
Sent: Sunday, March 16, 2003 12:06 PM
To: Www-Ws-Arch@W3. Org
Subject: 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 14:01:16 UTC