How to determine if an operation is synchronous

Let's assume two nodes, A and B, that exchange a message through some
protocol(s) of unknown latency L.


Asynchronous:

A sends a message M1 at time T1, B receives the message M1 at time T2. T2 =
T1+L.

Since neither A nor B know what L is, A cannot determine when B received the
message, nor can B determine when A sent the message.

(The message may contain a time stamp equal to T1, but it's possible that
A's clock is off compared to B's clock, and so the time reading is not
reliable)


Synchronous:

A sends a message M1 at time T1, B receives the message M1 at time T2. Again
T2 = T1+L. B processes the message, the processing time P is unknown as
well. B sends back the message M2 at time T3. T3 = T2+P = T1+L+P. A receives
the message M2 at time T4. T4 = T3+L = T1+2*L+P.

Since A and B do not know L, A cannot determine when B received M1 or sent
M2, nor can B determine when A send M1 or received M2.

A knows that its operation occurred around the time instant Ta. Ta is
calculated from the mean time of the operation. Ta =
(T1+T4)/2.

B knows that its operation occurred around the time instant Tb. Tb is
calculated from the mean time of the operation. Tb = (T2+T3)/2.

Ta = (T1+T4)/2 = (T1+T1+2*L+P)/2 = T1+L+P/2 =(T1+L+T1+L+P)/2 = (T2+T3)/2 =
Tb

So, whatever L and P are, both operations occur at the same time instant. We
say that A and B are synchronized.

Now, if A included a time stamp in the message M1 (T1), and B included two
time stamps in the message M2 (T2, T3), then A could synchronize it's clock
against B. A can't just use the values T2 or T3, because A's clock can be
off compared to B's.

But A knows that it's operation occurred at Ta (it's clock), and knows that
Ta=Tb+offset, and knows that Tb=(T2+T3)/2 (T2,T3 given from B's clock), so
it knows the offset is Ta-(T2+T3)/2. A can now synchronize it's clock with
B's.

arkin




I still don't see how a WSDL Input-Output Operation description tells me
anything about the synchronous/asynchronous nature of the interaction.

Ugo

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Tuesday, October 22, 2002 10:53 AM
To: Ugo Corda
Cc: www-ws-arch@w3.org
Subject: RE: Definition of Choreography


I am not assuming that the protocol is synchronous. I perfectly accept the
case that the request-response operation will occur over an asynchronous
protocol.

If you are using an asynchronous protocol, then you can perform two
interactions:

1) Service X can start both interactions one after the other, but not expect
one interaction to end before the second one begins. In this case, service X
can receive the response of the second interaction before the response of
the first interaction.

2) Service X can start the second interaction after it receives the response
to the first interaction, in which case it knows that the first operation
has completed before the second one starts.

However, if service X performs the interactions in the second manner, if can
deduct the order in which operations are performed by service Y. That means
that if service X orders the interactions to occur sequentially, waiting for
one to complete (response received) before beginning the second one, it
observes a synchronous pattern.

You can also deduct that by performing two asynchronous operations, e.g.
service X performs one-way interaction followed by notification interaction.
In this case, you use to asynchronous operations to compose a synchronous
pattern.

To be more precise, the synchronous nature of the operation from the
perspective of the service is a matter of whether the operation involves
two-way message exchange, or one-way message exchange. The synchronous
nature of the operation from the perspective of the protocol (e.g. SOAP), is
a matter of whether the operation is composed into a single two-way
communication, or performed over two one-way communications.

Two asynchronous communications (message exchange at wire level) can be used
to create a synchronous operation (interaction at service level). To add
even more confusion, a synchronous communication (message exchange at wire
level) can be used to create an asynchronous operation (interaction at
service level).

arkin

Received on Tuesday, 22 October 2002 19:24:30 UTC