RE: Snapshot of Web Services Glossary

> -----Original Message-----
> From: Walden Mathews [mailto:waldenm@optonline.net]
> Sent: Monday, February 24, 2003 4:01 PM
> To: Assaf Arkin; www-ws-arch@w3.org
> Subject: Re: Snapshot of Web Services Glossary
>
>
> > > I understand your explanation, but I don't think this advances the
> > > effort, because the meaning of "synchronous protocol" is not clear,
> > > at least not to me.
> >
> > How about:
> >
> > synchronous protocol - one which allows a request followed by a response
>
> What protocol doesn't?

This protocol:

send

And also this protocol:

receive

(e.g. IP, UDP, IP multicast)

As opposed to this protocol:

(send/receive)*

(e.g. TCP)

or this protocol:

(send,receive)*

(e.g. HTTP)

Of course you can build a protocol on top of a protocol, e.g. TCP on top of
IP, or virtual synchronisity on top of IP multicast.


> > synchronous only protocol - one which mandates a request be
> followed by a
> > response
>
> What protocol can 'mandate' a response?  And now you're introducing
> yet another term: 'synchronous only protocol'.  Is that necessary?

TCP for example does not mandate a response. So on top of TCP I can build
protocols that only send or only receive. TCP is a duplex protocol, like a
telephone, so it allows two people to talk at the same time, but it also
allows one of them to be quiet (e.g. an information hot-line).

On the other hand, HTTP mandates a response. All the HTTP methods I am aware
of include one request and one response. So HTTP is synchronous only.


> BTW, I think "synchronous protocol" is unnecessary verbiage, no more
> descriptive than "synchronous exchange", which need not apply to the
> whole protocol.  Do you "agree" that what makes TCP "synchronous" is
> the fact that each transmitted segment cannot be cleared from the send
> buffer until it has been acknowledged?  If so, why are we calling that
> "synchronous" instead of "mandatory acknowledgement" or some other
> obvious choice?

Actually, no. The fact that each transmitted segment cannot be cleared until
it has been acknowledge doesn't really say much. For example, I can send you
three segments, all three get acknowledge, I know you have received them, we
close the connection. Then you go about and do something with the message,
but I can't tell when you completed processing the message.

So my interaction in the scope of transmitting message is synchronous (as
opposed to UDP), but in the scope of performing an operation is
asynchronous.

I introduced the term protocol since I am thinking in more generic terms
than protocols X, Y and Z. I could devise a business protocol for managing a
purchase order, built on top of HTTP (e.g. PIP 3A4), in which case my
business protocol may have different attributes than all the lower-level
protocols.

arkin

>
> WM
>
>

Received on Monday, 24 February 2003 21:55:10 UTC