RE: Snapshot of Web Services Glossary

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Walden Mathews
> Sent: Monday, February 24, 2003 11:45 AM
> To: Ugo Corda; [email protected]
> Subject: Re: Snapshot of Web Services Glossary
>
>
>
>
> ----- Original Message -----
> From: "Ugo Corda" <[email protected]>
> To: "Walden Mathews" <[email protected]>; <[email protected]>
> 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
> interaction.
>
> "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.

What you are describing is the use of a synchronous protocol (HTTP) to
synchronously transfer the state (you know it was received) for asynchronous
processing (later).

I assume that later on you will receive a message indicating whether the
request was processed. So at the higher-level (say choreography) the
interaction involving request/response is synchronous, but each individual
operation is consider asynchronous, yet using a synchronous protocol to
ensure receipt.

arkin

>
> 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.
>
> Walden