RE: Issue: Synch/Asynch Web services

What I tried to do is to define a really simple situation, as simple as a
request-response. No, Agent B cannot hold any number of m1 messages, it can
only hold one because of restriction 2.  Agent A cannot send next request
neither because of restriction 2. 
 
Hao

-----Original Message-----
From: Sai Surya Kiran Evani [mailto:evani@informatik.uni-freiburg.de]
Sent: Tuesday, August 12, 2003 5:35 PM
To: He, Hao
Cc: 'Cutler, Roger (RogerCutler)'; www-ws-arch@w3.org
Subject: Re: Issue: Synch/Asynch Web services


Hi,

Comments inline...

He, Hao wrote:


Hi, Roger,
 
Here is my understanding about Synch/Asynch Web services.  Is it over
simplified?
 
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.

I guess the above sequence of messages - say, a sequence of "n"(n>=1) m1s
are sent first to Agent B and then all the replies of "n" m2s are processed
later  by Agent A  - is possible because

1. Agent B can hold any number of m1 messages
2. There is no restriction on Agent A from the above description that he
should send the next request i.e. m1 "depending" on the requests and
responses that he has already made and received. If there exists such a
restriction, then the service is synchronous because for every action taken
by one agent there is an "immediate"  matching action taken by the other
agent. Otherwise, the service becomes asynchronous where the matching action
is taken "eventually".

As you point out, there should be a way to "relate" messages in the above
asynchronous case. Above that, it seems to me that there should be a way of
expressing dependencies among sequences of messages based on which the
service and the invoker may behave synchornously or asynchronously with
above meaning. In the above case, the restriction is that a request m1 is
either the first request or dependent on the requests(m1s) and
responses(m2s) that have already transited. 





 
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. 
 
Hao
 
 



  _____  


========================================================================
WARNING- This e-mail including any attachments, is for the 
personal use of the recipient(s) only.
Republication and re-dissemination, including posting to news
groups or web pages, is strictly prohibited without the express
prior consent of Thomson legal & Regulatory Limited
ABN 64 058 914 668
=====================================================================