RE: Issue: Synch/Asynch Web services

> -----Original Message-----
> From: www-ws-arch-request@w3.org 
> [mailto:www-ws-arch-request@w3.org] On Behalf Of Cutler, 
> Roger (RogerCutler)
> Sent: Monday, August 04, 2003 10:52 AM
> To: Francis McCabe
> Cc: www-ws-arch@w3.org
> Subject: RE: Issue: Synch/Asynch Web services
> 
> 
> 
> Well, whether I misunderstood it or not, it seems to me to be 
> an interesting insight that at least certain classes of 
> asynchronous operations (probably the more common ones) 
> REQUIRE information to be passed that will allow a response 
> to be identified properly when it gets back (or wherever it 
> is going).  The simplest SOAP message, I think, just has a 
> body, no ID's or anything.  If you are doing synchronous 
> stuff, you can send a REAL simple SOAP message to a Web 
> service and get a REAL simple one back -- because you are 
> waiting and, essentially, "the next message is the one I am 
> interested in".  If, however, you are doing this 
> asynchronously, I think that some extra information must be 
> passed to the Web service and the Web service must properly 
> pass it back so the requestor can recognize the message coming back.

Heres the tricky part and why I think there is push back. Where is the
waiting happening?
For SOAP it depends on the binding - if the underlying transport can have
multiple oustanding requests and will do  the correlation there is no need
for the soap layer to be involved. If on the other hadd the transport
doesn’t support pipelining/multiplexing then you can either do correlation
at the soap level or at the application level. Independent of where it
happens (and whether the underlying protocols suppprot it) it can still be a
sync request response i.e. at one level it looks async but on another it can
be synchronous. 

> 
> I think that this means that not only the requestor but the 
> Web service itself needs to be aware that the operation may 
> be asynchronous.  Or, put another way, there are some WS's 
> that CANNOT be used asynchronously because they do not handle 
> the messaging in such a way that the requestor can recognize 
> the result.
> 
> Of course, I could be wrong here because I'm not expert on 
> all the ins and outs of SOAP and WSDL -- so please correct me 
> if I'm confused.
> 
> Incidentally, I would also think that there are some WS's 
> that CANNOT be used synchronously -- for example if the WS 
> accepts the request and then goes off for some time that 
> might be a week or a month before returning the answer.  
> Probably a grey area here, but this example seems pretty clear.
> 
> And then, I would think, there are WS's that can be used BOTH 
> s and a/s.  
> 
> So does a WS declare itself somehow in one of these classes 
> or is the requestor just supposed to find out by examining 
> the WSDL for suitable identifiers and trial and error on the 
> response time?  If you're thinking in terms of late binding 
> that seems a bit ... Less than optimal.
> 
> -----Original Message-----
> From: Francis McCabe [mailto:fgm@fla.fujitsu.com] 
> Sent: Monday, August 04, 2003 12:26 PM
> To: Cutler, Roger (RogerCutler)
> Cc: www-ws-arch@w3.org; www-wsa-comments@w3.org
> Subject: Re: Issue: Synch/Asynch Web services
> 
> 
> Roger:
>    Some clarifications may be in order:
> 
> On Monday, August 4, 2003, at 07:29  AM, Cutler, Roger (RogerCutler) 
> wrote:
> 
> > I emphasize above that I have mostly concentrated my 
> personal efforts 
> > on the concept of synchronous, and although I have some hope that 
> > asynchronous may come along fairly easily as the complement of 
> > synchronous, nonetheless Frank's introduction of the concept of 
> > rendezvous as a necessary component of asynchronous 
> operations gives 
> > me a bit of pause.  Is this a requirement that asynchronous 
> messages 
> > carry information not required in synchronous messaging in order to 
> > support a later rendezvous?  If so such a requirement might well be 
> > discussed more explicitly in the WSA.
> 
> The term rendezvous was coined (I believe) by Tony Hoare, in his work 
> on Communicating Sequential Processes, from the early 80's. 
> It is not a 
> component of asynchronous operations. Put simply, rendezvous 
> means `at 
> the same time'; which, for me at any rate, is the core of the meaning 
> in synchronous.
> 
> I use the phrase `application rendezvous' to mean that two 
> applications 
> are `at the same place, at the same time' as a kind of generalization 
> of message communication. (This doesn't mean that they are doing the 
> same thing of course!) Hoare uses the notion of a rendezvous event.
> 
> Frank
> 
> 
> 
> 
> 
> 
> 
>

Received on Monday, 4 August 2003 14:52:28 UTC