W3C home > Mailing lists > Public > www-ws-arch@w3.org > August 2003

RE: Issue: Synch/Asynch Web services

From: Cutler, Roger (RogerCutler) <RogerCutler@chevrontexaco.com>
Date: Thu, 7 Aug 2003 12:29:06 -0500
Message-ID: <7FCB5A9F010AAE419A79A54B44F3718E01817F37@bocnte2k3.boc.chevrontexaco.net>
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


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
or for someone with an attention span like mine"
is suggestive of a human making a request. While it is true that one
imagine that Web services
might be invoked by a "client" that also exposes a human interface (with
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

However, again, none of this has anything to do with "synchronous" or 
"asynchronous" in my mind.


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

"ECKERT,ZULAH (HP-Cupertino,ex1)" <zulah_eckert@hp.com>, 
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
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
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
The major application of asynchronous messaging is for events that are 
sent between a resource and a manager.
Received on Thursday, 7 August 2003 13:29:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:08 UTC