- From: Cutler, Roger (RogerCutler) <RogerCutler@chevrontexaco.com>
- Date: Mon, 4 Aug 2003 12:52:23 -0500
- To: "Francis McCabe" <fgm@fla.fujitsu.com>
- cc: www-ws-arch@w3.org
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. 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 13:52:42 UTC