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
>=====================================================================
>