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

RE: Issue: Synch/Asynch Web services

From: Cutler, Roger (RogerCutler) <RogerCutler@chevrontexaco.com>
Date: Mon, 11 Aug 2003 19:45:30 -0500
Message-ID: <7FCB5A9F010AAE419A79A54B44F3718E026EFA62@bocnte2k3.boc.chevrontexaco.net>
To: "He, Hao" <Hao.He@thomson.com.au>
cc: www-ws-arch@w3.org

My personal opinion is that your analysis hits the high points --
probably the 80-20 -- but probably not all the crevices and

-----Original Message-----
From: He, Hao [mailto:Hao.He@thomson.com.au] 
Sent: Monday, August 11, 2003 6:28 PM
To: Cutler, Roger (RogerCutler)
Cc: www-ws-arch@w3.org
Subject: RE: Issue: Synch/Asynch Web services

Hi, Roger,
Here is my understanding about Synch/Asynch Web services.  Is it over
Suppose we have two agents in a well-controlled environment (super fast,
reliable network). Agent A sends a message m1 to Agent B and expects
Agent B to return a message m2, however long it may take. This scenario
seems to me, is a typical case of sync Web services. The essences of
this process are: 1. that Agent A can relate m1 and m2 by sequence
(sending m1 to B is prior to receiving m2 from B). 
2. that there can be no other messages between two related messages.
If we remove those two constraints, the process becomes async. Agent A
can send a number of messages to Agent B after sending m1.  When it
receives m2 from Agent B, it can relate m1 and m2 together using other
mechanism, however that mechanism may be.
Interestingly, a process can be sync at the infrastructure level but be
async at the application level. For example, m2 can be a receipt rather
than final results an application intends to get. 
Received on Monday, 11 August 2003 20:45:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:08 UTC