RE: Snapshot of Web Services Glossary

> -----Original Message-----
> From: Walden Mathews [mailto:waldenm@optonline.net]
> Sent: Monday, February 24, 2003 4:45 PM
> To: Assaf Arkin; www-ws-arch@w3.org
> Subject: Re: Snapshot of Web Services Glossary
>
>
>
> ----- Original Message -----
> From: "Assaf Arkin" <arkin@intalio.com>
> To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>;
> <www-ws-arch@w3.org>
> Sent: Monday, February 24, 2003 5:50 PM
> Subject: RE: Snapshot of Web Services Glossary
>
>
> >
> > How about:
> >
> > An operation is synchronous if both service requester and
> service provider
> > engage will alway engage in that operation at the same time.
>
> Not bad.  "Synchronous operation" ~= "synchronous exchage".  What
> about saying something about how strictly to interpret "at the same
> time", or some model that permits such?  Clearly, if I wait ten minutes
> for your response, I'm participating in synchrony, and we're not
> requesting and responding at the same time.

The activity you perform as defined in the operation involves sending a
request and receiving a response. The activity I am performing as defined in
the operation involves receiving that request and sending that response. The
activity I am performing will start after the activity you are performing
and complete before it. But they will overlap, there is some time span
(which may be nanoseconds compared to the ten minutes you wait for a
response) in which we both perform activities as defined in that operation.
So that's one definition of 'same time'.


> > Or:
> >
> > An interaction is synchronous if activities demarcated by that
> interaction
> > will always be performed at the same time.
>
> It seems to call for an awful lot of stuff happening "at the same time",
> a concept difficult to conceive of unless you take that to mean within
> the same time interval.  If you do that, then there's the length of the
> interval to look at.

There are two formal models. One looks at a time instant, but with some
resolution that is determined by the protocol. The simpler explanation is
actually based on logical clocks so it's not riddled by issues like time
spans, latencies, etc (though easily extended to physical clocks).

The other looks at a time span rather than a time instant. This one is
easier to grasp. It says something like:

- requester sends request at time T1 receives response at time T2
- the request performs its part of the operation between T1 and T2
- the provider performs its part of the operation between T1 and T2


> What do you think about, simply:
>
> Synchronous operations may fail by "timing out" i.e., taking too long.
> For asynchronous operations, "timing out" is undefined.

This is probably correct, but I think it defines the symptom rather than the
cause.

arkin

>
> WM

Received on Monday, 24 February 2003 22:01:26 UTC