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 12:33:32 UTC