- From: Cutler, Roger (RogerCutler) <RogerCutler@chevrontexaco.com>
- Date: Thu, 7 Aug 2003 12:29:06 -0500
- To: "Christopher B Ferris" <chrisfer@us.ibm.com>
- cc: www-ws-arch@w3.org, www-ws-arch-request@w3.org, www-wsa-comments@w3.org, "ECKERT,ZULAH (HP-Cupertino,ex1)" <zulah_eckert@hp.com>
Ummm -- this is really a confusing response. You are referring here to comments I made about a specific followon issue, not about the issue of synchronous and asynchronous itself. I originally made a specific and tentative suggestion that a reasonable followon topic might have something to do with management functions and metrics, and Zulah asked me to elaborate what I thought this might be. You are correct, that has nothing to do with the fundamental issue. I threw out my ideas just for what they might be worth in the management context, and ONLY in the management context in this case. I am not claiming that "response time" is equivalent to "synchronous". I am just saying that a management function might want to expose some metrics about response time that could be of interest to clients that want to use the Web service synchronously. And maybe they wouldn't want to ... What do I know? As you say, that has nothing to do with the issue of "synchronous" itself. -----Original Message----- From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] Sent: Thursday, August 07, 2003 11:33 AM To: Cutler, Roger (RogerCutler) Cc: www-ws-arch@w3.org; www-ws-arch-request@w3.org; www-wsa-comments@w3.org; ECKERT,ZULAH (HP-Cupertino,ex1) Subject: RE: Issue: Synch/Asynch Web services Roger, I don't think that response time and "synchronous" necessarily have anything to do with one another. It would seem to me that what you are looking for is something along the lines of quality of service characteristics, one of which might be the average response time for a request to be satisfied. Of course, that would have to be added to the time it takes to transmit both the request message and the response message which would typically be dependent upon network topology and distance in addition to any intermediary processing that might be interposed on either the request or the response. Note also that your characterization of "someone willing to wait an hour, or for someone with an attention span like mine" is suggestive of a human making a request. While it is true that one might imagine that Web services might be invoked by a "client" that also exposes a human interface (with a human at the controls), I thought that we had established that Web services were primarily addressed at machine-to-machine interaction. Machines have infinitely more patience than you or I (although you are correct in observing that there might still be valid reasons why a requestor might place time constraints on any responses it might receive and it might even be interested in automatically selecting a service provider based upon its responsiveness characteristics. However, again, none of this has anything to do with "synchronous" or "asynchronous" in my mind. Cheers, Christopher Ferris STSM, Emerging e-business Industry Architecture email: chrisfer@us.ibm.com phone: +1 508 234 3624 "Cutler, Roger (RogerCutler)" <RogerCutler@chevrontexaco.com> Sent by: www-ws-arch-request@w3.org 08/06/2003 10:29 PM To "ECKERT,ZULAH (HP-Cupertino,ex1)" <zulah_eckert@hp.com>, www-ws-arch@w3.org cc www-wsa-comments@w3.org Subject RE: Issue: Synch/Asynch Web services Well, it's not something that I have thought through very clearly. It just seems to me that if I were a potential user of a Web service that performed the X function, and if I wanted to do the X function synchronously (that is, waiting for the answer to come back) -- well, I might like to have some idea that a Web service could perform the X function in some time that I would be willing to wait. How long I am willing to wait is kind of up to me. Some people have shorter attention spans than others. So it seems to me that it might not be so hot if a Web service advertised, somehow, "I am available for synchronous access". Well, is that synchronous access for someone willing to wait an hour, or for someone with an attention span like mine? So it seems to me that it would be better if a Web service were able to advertise, "This is the response time I have typically given in the past. If that meets your needs, go for it ..." -----Original Message----- From: ECKERT,ZULAH (HP-Cupertino,ex1) [mailto:zulah_eckert@hp.com] Sent: Wednesday, August 06, 2003 6:31 PM To: Cutler, Roger (RogerCutler); www-ws-arch@w3.org Cc: www-wsa-comments@w3.org Subject: RE: Issue: Synch/Asynch Web services Hi Roger, Access to past performance metrics, etc. will be dealt with with logging. I'm not sure how this relates to asynchronous messaging - can you clarify the question below. > -Could/should a management interface expose information to potential users of a WS about past performance metrics and/or expectations of > relevance to the issue of s/sa usage? (e.g. expected/observed > response times)? The major application of asynchronous messaging is for events that are sent between a resource and a manager. Zulah
Received on Thursday, 7 August 2003 13:29:25 UTC