RE: Issue: Synch/Asynch Web services

It seems to me that communication over a queue could be modeled either as a particular type of SOAP binding (e.g. binding to a transport that support queuing, e.g. a MOM protocol), or as a SOAP Intermediary with store-and-forward capability.
 
Ugo

-----Original Message-----
From: Cutler, Roger (RogerCutler) [mailto:RogerCutler@chevrontexaco.com]
Sent: Monday, August 11, 2003 7:42 AM
To: Sai Surya Kiran Evani
Cc: www-ws-arch@w3.org
Subject: RE: Issue: Synch/Asynch Web services


I think that the answer to your original question is, "No" -- I have not seen any discussion of these concepts in this group.  However, speaking personally this looks very interesting.  If you're willing to keep talking about this, I have some questions:
 
What is a bounded length queue?  Is this a reasonable model for practical systems on the Web?
 
Granting that Web services can be viewed in this context, what is the potential gain?  Do these theories provide logical foundations of some sort that we might be able to lean on somehow?  Or do they draw distinctions or derive results that might constrain or guide Web services architecture?
 
I'm reaching here because I really don't know much about the theoretical background.  I have heard of pi-calculus, but in a context that seems to me a bit different.  I seem to recall Microsoft people claiming that their XLang language, which I believe is something like a lower level BPEL, or perhaps a precursor to BPEL, used (I think) as a basis for the logic underlying their EAI product, Biztalk Server -- I think that they claimed that XLANG has some sort of completeness because it is a representation of Pi calculus.  This may be a bit confused, but it at least gives you a hint where my personal knowledge level sits.  However, based on this scanty knowledge I would have sort of expected things like Pi calculus to come up in the Choreography group.  So that's what motivates me to ask how you see this stuff applying to the architecture of the Web services (other than through choreography)?
 
-----Original Message-----
From: Sai Surya Kiran Evani [mailto:evani@informatik.uni-freiburg.de] 
Sent: Monday, August 11, 2003 3:22 AM
To: Cutler, Roger (RogerCutler)
Cc: www-ws-arch@w3.org
Subject: Re: Issue: Synch/Asynch Web services


Hi,

What I meant was that each WSDL port could be thought of as a queue and a service which communicates using these ports as a process.

The two important theories dealing with communicating processes - Communicating Sequential processes(Hoare), Calculus of Communicating Systems(Pi-Calculus etc - Robin Milner) assume that message passing is immediate or based on bounded length queues.

On the other hand, communication among processes with unbounded FIFO queues has been studied using an abstraction called "Network of Communicating Finite State Machines" to my knowledge. 

-Kiran.

Cutler, Roger (RogerCutler) wrote:


I would personally appreciate it if you would explain this a little more
fully.

-----Original Message-----
From: Sai Surya Kiran Evani [ mailto:evani@informatik.uni-freiburg.de] 
Sent: Saturday, August 09, 2003 10:44 AM
To:  www-ws-arch@w3.org
Subject: Re: Issue: Synch/Asynch Web services



Hi,

Just curious if there would be anything defined regarding the queueing 
behaviour of a web service. I guess the analysis of the systems involved

- the provider or the invoker would be different in the cases of 
unbounded queues and bounded queues..

Thanks,
Kiran.


Geoff Arnold wrote:


Bottom line: From my point of view async/sync is a question of 
blocking or not, and completely separated from the underlying 
protocol. It just has to provide sufficient ways to handle the 
message exchange in the way desired by the application.


If it were the case that sync/async were merely a question of blocking



or non-blocking, WSA (and SOAP, and.....) would have nothing to say on



the subject, since our specifications are silent on the question of 
implementation.

However there is an alternative viewpoint (that sync/async is a 
property of message exchange patterns), and this has nothing 
whatsoever to do with implementation, blocking, threading and so 
forth.

Geoff