RE: Issue: Synch/Asynch Web services

Yes, indeed, I certainly agree that understanding s-a/s depends strongly -- very strongly -- on understanding the context.  Having said that, it seems to me that the question of what is necessary at the SOAP level needs to be sorted out.  But Mike has already chided me for trying to leap ahead into discussing the followon questions, and I think that this is inviting ... Well, just one comment ... If you think about labelling some WS's as asynchronous and others as synchronous, based on something that is visible at the discription level, then what about when the underlying protocol level starts supplying related features?  Well, the underlying protocol cannot make a response that takes weeks into one that takes seconds, but I suppose it could go the other way.

I think that this stuff needs to be sorted out, and I agree that it sounds tricky.  But that's why they pay us the big bucks, right???

-----Original Message-----
From: Martin Chapman [mailto:martin.chapman@oracle.com] 
Sent: Monday, August 04, 2003 1:53 PM
To: Cutler, Roger (RogerCutler); 'Francis McCabe'
Cc: www-ws-arch@w3.org
Subject: 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 15:01:24 UTC