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

That's very thorough ;-)

Let me say again that I do agree with you that defining things in terms 
of channels is more interesting than connections. I know I'm in a 
minority group here, most people prefer to write definitions in terms of 
HTTP connections. It's easier and you don't need to figure out how a 
channel translates into an HTTP connection. Unfortunately it does not 
apply to other interesting technologies, and so is protocol dependent. 
But enough about ranting ;-)

Let's say I have a request-response operation. It may use a synchronous 
channel like an HTTP connection. It may also use two synchronous 
channels, for example, use one HTTP connection to send the request and 
another one to receive the response. Or it may use an asynchronous 
channel using some other protocl that can multiplex multiple 
request/responses on the same connection. So that tells me how I could 
use the channels, and that there are many ways in which a MEP can use 
different types of channels. But it doesn't tell me anything useful 
about the MEP itself unless we assume the MEP is married to the channel 
type. Is that a fair assumption?

arkin

Damodaran, Suresh wrote:

>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 16:28:06 UTC