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

Re: Snapshot of Web Services Glossary

From: Walden Mathews <waldenm@optonline.net>
Date: Mon, 24 Feb 2003 14:45:21 -0500
To: Ugo Corda <UCorda@SeeBeyond.com>, www-ws-arch@w3.org
Message-id: <004101c2dc3d$474f72a0$1702a8c0@WorkGroup>

----- Original Message -----
From: "Ugo Corda" <UCorda@SeeBeyond.com>
To: "Walden Mathews" <waldenm@optonline.net>; <www-ws-arch@w3.org>
Sent: Monday, February 24, 2003 1:29 PM
Subject: RE: Snapshot of Web Services Glossary

> >Then there's a reference to a "synchronous HTTP POST".
> >Not sure if "synchronous" adds any meaning there.
> I think that "synchronous" in that context refers to the fact that the
HTTP POST is expected to carry the response back on the same HTTP

"Same interaction" is a problem to generalize, although I get your
meaning fine here.  It would also be on the same connection, but again
generalizing, a connection is just an agreement of connected parties,
nicely recursive.  But, perhaps more significantly, the "same interaction"
signifies a time frame within to succeed or fail?

> It's probably qualified as "synchronous" to distinguish it from an
"asynchronous" HTTP POST, where the HTTP response (which will come back just
because HTTP is a synchronous protocol) might be viewed by the client as
just an ack from the server, or might be ignored. The "real" SOAP response
would in that case come on a separate interaction and not via the initial
HTTP response.

Okay, I understand the explanation, but I have issues with the
language still.  If I say my client "does a synchronous HTTP POST",
I'm implying that my client can control whether the server processes
the posted data now or defers processing until later, in which case
the responses will be different as you describe above.  Meanwhile,
there's an HTTP status code that means "I got it, but haven't processed
it yet.", so there's no additional protocol needed for a client to
know whether it got a post-processing representation or just an
ack.  Using "synchronous" or "asynchronous" in this setting is mis-
leading, and so should be avoided.  Surely better terms can be
found; not so surely, perhaps no such terms are really needed.

I agree that request/response in HTTP can be regarded as
"synchronous", due to almost universal although vague assumptions
about how long the whole transaction ought to take.

Received on Monday, 24 February 2003 14:45:35 UTC

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