RE: Friendly amendment #2c [Re: Straw poll on "synchronous" definitions]

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Walden Mathews
Sent: Sunday, March 16, 2003 10:13 AM
To: Christopher B Ferris; www-ws-arch@w3.org
Subject: Re: Friendly amendment #2c [Re: Straw poll on "synchronous"
definitions]


>I think that Arkin responded on this point. We call them MEPs or Message
>Exchenge Patterns for a reason:-) I am fairly certain that the XMLP group
>had oneway message exchanges in mind when it coined the "MEP" phrase since
I >was there at the time:)

<wm>
In which case, it's message "exchange" patterns.  Which is fine
once it's been explained, but may not be all that obvious to
people who weren't "there".  Especially when you're trying to
incorporate it into the definition of sync/async, a subject plagued
by scope issues IMO.
</wm>

<atm>
Even in one-way messages, the sender and receiver are still "exchanging" a
message. I don't believe that "exchange" necessarily implies a reciprocal
exchange.

The point that I was making is that synch/asynch is not a function of the
type of MEP. It is purely a function of whether or not there is a mechanism
to store the message for later delivery. A message is synchronous if such a
facility does not exist. If the receiver is not available to receive the
message at the time that the sender sends the message, the transmission
fails. A message is asynchronous if such a facility does exist. If the
receiver is not available to receive the message at the time that the sender
sends the message, the message will be persisted and delivered at a later
time.

Many people use the term "asynchronous" to also refer to blocking versus
non-blocking, but technically, this is a separate issue, and a source of
confusion for the use of the term "asynchronous". For example, using the
CORBA "asynchronous" invocation feature, your can send a request, go perform
other functions while the request is being processed, and when you're ready
to get the results, use a callback feature to retrieve the results. In this
situation the request is synchronous (the service must be available to
receive the request when the client sends it) and the response is
asynchronous (the client can retrieve the response at a later time).

Compare this to a blocking invocation using an asynchronous transport such
as an MQ system. MQ systems are by default asynchronous. The sender sends
the message to a persistent queue. The receiver retrieves the message from
the persistent queue. There is no requirement that the receiver be available
at the time the sender sends the message. Even so, an MQ application can
send a message and then wait idly for a response (simulating synchronous
behavior).
</atm>

>> Can you elaborate on why the definitions should not be complementary?

>Because as Roger has so eloquently pointed out, his Aunt Mary is not
>synchronous, so she must be asynchronous by our definition? I think we can
do
>better.

<wm>
I think this is an instance of the scope problem, mainly, not an
argument against complement.  When you say Aunt Mary is not synchronous,
you've already lost me.  Could we have an in-scope example to make
this point, please?
</wm>

<atm>
The point is that is you describe something (A) as not something else (b),
then you are saying that anything that doesn't qualify as B must be A. So if
B is an apple, then A is anything that isn't an apple.
</atm>

<wm>
Also, is it now fairly well established that the sync/async definitions
being worked on for the glossary are bounded to qualifying MEPs?  If
so, I'd like to resurrect an earlier suggestion, which is to change the
definition headings to "Synchronous Message Exchange", etc.  The broader
the task, it seems, the harder to get some consensus.
</wm>

<atm>
The sync/asynch definitions are orthogonal from MEPs, although I'd say that
it would be appropriate to define each MEP in terms of sync and async.
</atm>

Regards,
Walden

Received on Sunday, 16 March 2003 11:13:31 UTC