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 Monday, 5 May 2003 21:43:54 UTC