RE: Draft language on MEPs, synchronous, and asynchronous.

Brief response:

Synchronous Channel:
In a synchronous channel, an attempt to send another message when a message
is in transit will result in an error. [To avoid deadlock, a fairness rule
such as the following may be helpful: when an expected response message to a
message does not arrive in a specified time, that will also result in an
error.][You might add an example of a common MEP such as  synchronous
request-response, and explain the details, etc.]

Asynchronous Channel:
In an asynchronous  channel, multiple messages may transit through the
channel simultaneously.
(I think this is the fundamental difference).

Below are the rationale, defs of channel, etc.

-------------------------------------------------------------
Detailed response:

Actually, your question prompted some thinking, and as a result, I may have
simplified
the definitions much more.
Generally speaking, the notion of a channel is quite similar to that of a
connection.
s/channel/connection will possibly result in not much damage below.

A (communication) channel is a virtual circuit established between two
communicating entities.

I would like to assume couple of properties for a channel
  - messages take a finite time to transit through a channel (allows for
activities while
messages are in transit, such as sending the same message again when the
first is in transit)
  - a channel has associated with it at least two communicating entities,
and exactly one of them is a sender of a message. ["multiple receivers" case
covers the broadcast case - I may tighten this to exactly one receiver also
to allow for partially successful synchronous broadcast - see synch def
below]

[just for the heck of it, here is http 1.1 defs as in rfc 2616:

connection
      A transport layer virtual circuit established between two programs
      for the purpose of communication.

   message
      The basic unit of HTTP communication, consisting of a structured
      sequence of octets matching the syntax defined in section 4 and
      transmitted via the connection.
]


Synchronous Channel:
In a synchronous channel, an attempt to send another message when a message
is in transit will result in an error. [To avoid deadlock, a fairness rule
such as the following may be helpful: when an expected response message to a
message does not arrive in a specified time, that will also result in an
error.][You might add an example of a common MEP such as  synchronous
request-response, and explain the details, etc.]

Asynchronous Channel:
In an asynchronous  channel, multiple messages may transit through the
channel simultaneously.
(I think this is the fundamental difference).

This is why any "multiplexing" is possible only over an asynchronous
channel.
Multiplexing assumes a context for each communication (sequence) is saved
(within the channel or elsewhere). You can get zillion emails because SMTP
is aynchronous.
You can respond to this email because the context of communication is stored
in your email tool. [test question: do you need the synchronous property to
"cc" several people simultaneously? No.]

You may try modeling another way, assuming another property:  "channel has
no memory (of message transit occurrrence)"
In this case, synchronous/asynchronous peoperties are no longer properties
of
a channel, but that of the USE of the channel. Slightly different, but may
suit some.


My definitions in an earlier message assumes "channel has no memory." I am
rewriting those here:

Synchronous: In a synchronous use of a channel, an attempt to send another
message
in the channel when a message is in transit will result in an error. [To
avoid deadlock, a fairness rule such as the following may be helpful: when
an expected response message to a message does not arrive in a specified
time, that will also result in an error.]

[My old def:. Descriptive, but combines request-response MEP with the
definition which is not necessary - Synchronous: An entity A communicates
with entity B synchronously over a
communication channel if and only if A requires a response back from B
and A does not initiate another communication to B using the same
communication channel before it receives that response or the
communication has failed.  Entity A may consider the communication to
have failed if it does not receive a response back in some length of
time.]

Asynchronous: In an asynchrnous use of a channel, multiple messages may be
in transit 
in the channel at the same time.

[ Old def: descriptive but combines an example MEP with def - Asynchronous:
When A communicates with B  asynchronously, A may not
require a response back from B. Whether A  requires a response or not, A
may initiate another communication to B on the same communication
channel at any time.
--------------------------------------------------------------------
The "channel has memory" property slightly changes the definitions: so I can
simply say a "synchronous channel" instead of the "synchronous use of a
channel."

I believe these are a lot tighter and simpler than the previous and quite
broadly applicable.

Feel free to point out anything I may have missed and improve.
I hate to think these definitions are new. 
Given the talent pool in WSA, somebody must have presented something
close...

Regards, 
-Suresh 
Sterling Commerce (on loan to RosettaNet) 
469 524 2676 (O), 469 323 0234 (Cell) 



-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Monday, May 05, 2003 8:42 PM
To: Damodaran, Suresh
Cc: 'Champion, Mike'; www-ws-arch@w3.org
Subject: Re: Draft language on MEPs, synchronous, and asynchronous.


+1 on the use of channels

Generally speaking, I would prefer any definition that talks about 
channels and not connections. Then you figure out how to implement the 
channel using connections (multiplexing channels on the same connection, 
multiple connections per channel, etc).

Example for a synchronous communication is one in which you open a 
channel, send a request, receive a response, close the channel. But 
that's not saying much to distinguish it from an asynchronous 
connection. What would be the difference between the two?

arkin

Damodaran, Suresh wrote:

>Hi Mike,
>
>I have to disagree in substance (and even the process which you are
>proposing), 
>if the proposal is to ignore defining key concepts
>in web architecture, and instead declare victory by making an attempt. 
>
>I know this group has tried again and again to nail down some of these
>concepts,
>and many WSA members are at "whatever" point. 
>However, other communities look towards W3C and WSA to tackle such hard
>issues, and provide definitions and directions.
>Fudging in this responsibility would be another sure fire way to make WSA
>irrelevant
>to real world. I apologize if this sounds like a sermon. I have no desire
to
>increase the frustration and stress on the well meaning folks. Just
pointing
>out a reality.
>
>A little discussion on communication channel by people who put in some
>thought
>on the subject: http://niap.nist.gov/cc-scheme/PUBLIC/0066.html
>The idea of a communication channel is not tied to any protocol.
>May be we can tackle the issue by generalizing some of the protocol ideas
>(say http?)
>from the well written RFCs or thesis.
>
>I don't know what to say at this point. If we want to say "we give up!" so
>be it.
>Sorry to say, I will be disappointed and so would many otherss like me.
>
>Regards, 
>-Suresh 
>Sterling Commerce (on loan to RosettaNet) 
>469 524 2676 (O), 469 323 0234 (Cell) 
>
>
>
>-----Original Message-----
>From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com]
>Sent: Monday, May 05, 2003 12:02 PM
>To: www-ws-arch@w3.org
>Subject: RE: Draft language on MEPs, synchronous, and asynchronous.
>
>
>
>
>
>  
>
>>I'm sorry, I still think this is just giving up and that in fact the
>>terms have a domain of validity in which they can be 
>>rigorously defined.
>>
>>    
>>
>
>Perhaps, and I also find some good food for thought in Suresh's
proposal(s).
>On the other hand, we need to focus on the questions that people are
looking
>for answers to, and I don't think this is one of them.  Geoff's rejoinder
to
>my attempt over the weekend to extract a "friendly amendment" was a good
>one:  by getting "rigorous" we start bringing in dependencies on
>implementation-specific notions such as "communications channel,"   which
>then have to be defined.
>
>Procedurally, we were at the point of agreeing to whatever way Chris and
>Geoff came up with of resolving their different perspectives.  They have
>done that, Geoff has accepted some suggested tweaks, and I think it's time
>incorporate them and look for new fish to fry.  
>
>Unless there is a substantial body of opinion that says "we MUST resolve
>this better before we can move on" I'd suggest we move on.  Dissenters are
>welcome to record an issue so that we are more or less required to revisit
>the matter before leaving Last Call.
>  
>


-- 
"Those who can, do; those who can't, make screenshots"

----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
Intalio Inc.                                           www.intalio.com
The Business Process Management Company                 (650) 577 4700


This message is intended only for the use of the Addressee and
may contain information that is PRIVILEGED and CONFIDENTIAL.
If you are not the intended recipient, dissemination of this
communication is prohibited. If you have received this communication
in error, please erase all copies of the message and its attachments
and notify us immediately.

Received on Tuesday, 6 May 2003 00:35:36 UTC