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 Anne Thomas Manes
> Sent: Sunday, March 16, 2003 8:14 AM
> To: Www-Ws-Arch@W3. Org
> Subject: 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.

Exchange something for nothing?

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

I beg to differ:

One-way:

The receiver (service) does not implement a queue, the receiver must be
available (online) to receive the message. However, regardless of whichever
protocol is used (say HTTP or IIOP), the sender can always implement a
queue. From the perspective of the actor performing the WSDL operation by
sending the one-way message, it is perceived as delivered asynchronously.
The sender WS stack puts it in a queue, continously polls to deteremine if
the recevier is online and delivers when possible.

In other words, because the sender actor can send at one point in time and
the receiver actor can receive at some other point in time, and there's
nothing that says to the contrary, even though the protocol is synchronous,
the operation semantic is asynchronous.

(Notice that I'm talking about actors from the perspective of WSDL which
talks about the operation being performed, not the actual use of HTTP to
move the messages around)

Two-way

This time we're using MQ and we have queues in between sender and receiver.
The service requester sends a request, it gets queued. Later on it gets
delivered to the service provider. The service provider processes it. Sends
a response which gets queued and later delivered to the requester. All
message transport/delivery happens asynchronously using queues just to make
it more "time independent".

But without a doubt there is some point in time at which both actors are
engaged in the operation together: the requester waiting for request (before
it can complete the operation) and the responder processing the request
(before it can complete the operation). Anyway you tweak the protocol,
implement the queues or add acks/nacks/resends, you still end up with some
some overlap with respect to the actors, which means the actors are
synchonized.


The interesting thing about this definition is that it talks to about it
from the perspective of the WSDL abstract operation and no matter which
protocol you use or how you configure it, the semantics are still the same,
i.e. they define the operation independently of the protocol bindings.


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

We all know that you can be long or short but not both (in the same
context). This permathread is quite long. This sentence is quite short. Is a
WSDL operation long or short? There's always another answer: N/A.

Aunt Mary is not synchronous by virtue of not being asynchronous or the
other way around. Aunt Mary falls under N/A. But she might have a short or
long opinion that matter ;-)

arkin

Received on Sunday, 16 March 2003 15:05:56 UTC