W3C home > Mailing lists > Public > www-ws-arch@w3.org > May 2003

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

From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
Date: Fri, 2 May 2003 09:37:39 -0400
Message-ID: <9A4FC925410C024792B85198DF1E97E4059850E7@usmsg03.sagus.com>
To: www-ws-arch@w3.org

I kindof like Suresh's idea of including a taxonomy of MEP's, as long as we
don't claim that it is the One True, Canonical Ontology of them.  Is this a
trout pond?  

As for the definition of synch/asynch MEPs, there's something to be said for
Suresh's proposed wording.  We were working with:

"MEPs which describe closely coupled in time, or lock-step 
interactions are frequently referred to as "synchronous"."

I for one would be happy to substitute something like:

MEP's involving that require a response from the responder back to the
initiator before the initator can initiate another communication that
responder using the same communication  channel are frequently referred to a
"synchronous." 

I see that as a friendly amendment that defines "closely coupled in time"
more rigorously.

> -----Original Message-----
> From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com]
> Sent: Thursday, May 01, 2003 6:09 PM
> To: 'Champion, Mike'; www-ws-arch@w3.org
> Subject: RE: Draft language on MEPs, synchronous, and asynchronous.
> 
> 
> As promised in the call, here is my proposal:
> 
> This propasl is based on the assumption that Web Service 
> Architecture, as
> defined by WSA WG,
> is meant to support "business requirements" - may be WSA requirements
> document has something to this effect.
> Else, feel free to ignore this message.
> 
> I do not think it makes sense to call synchronous and asynchrnous as
> instances
> of MEPs, because it doesn't reflect real business messaging 
> practices that
> require non-repudiation, for example.
> Feel free to do necessary massaging to suit teh rest of the 
> architecture.
> 
> I suggest the following as instances of MEPs.
> 
> - Request/Response: The Requesting message results in a 
> Response message
> that contains response to a query within the Requesting 
> message. Only 2
> partners involved. Requires acknowledgement signal from the 
> partner for both
> Requesting and Responding messages.
> 
> -Notification: The Notification message is sent from one 
> partner to another.
> There is no responding message. Requires an acknowledgement 
> signal from the
> receiving partner.
> 
> - Information Distribution: Information distribution messages 
> are sent from
> one partner to one or more partners. No acknowldgements required.
> 
> - Query/Response: Query message is sent from one partner to 
> another, which
> responds with a Response message. No acknowledgement.
> 
> Note the distinction between message vs. signal. Messages 
> carry business
> information, whereas signals can be acknowledgements or exceptions.
> 
> It does make sense to qualify the some or all of teh MEPs below as
> synchronous or asynchronous. Any of the above can be synchronous or
> asynchronous depending on whether either the message and/or 
> signals are
> synchronous or asynchronous.
> 
> My definition of Synchronous/Asynchronous from a messaging 
> point of view is
> below FWIW
> (I know you have been many times over it):
> 
> 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.
> 
> Asynchronous: When A communicates with B  asynchronously, A 
> does not always
> require a response back from B. Irrespective of whether A  requires a
> response or not, A may initiate another communication to B on the same
> communication channel.
> 
> *"communication" can be a message or a signal.
> 
> 
> 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: Thursday, May 01, 2003 12:48 PM
> To: www-ws-arch@w3.org
> Subject: RE: Draft language on MEPs, synchronous, and asynchronous.
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Geoff Arnold [mailto:Geoff.Arnold@Sun.COM]
> > Sent: Thursday, May 01, 2003 1:30 PM
> > To: www-ws-arch@w3.org
> > Subject: Draft language on MEPs, synchronous, and asynchronous.
> > 
> 
> +1 Overall, especially to combining   this with the MEP 
> concept.  Without
> that, we risk complicating the definition to exclude 
> irrelevant senses of
> these terms.
> 
> > MEPs which describe closely coupled, or lock-step 
> > interactions are frequently referred to as "synchronous".
> 
> How about "time-coupled" or "closely coupled in time"?  
> "Coupling" has a lot
> of other meanings and I think we want to explicitly talk about
> timing-related coupling.... One wants to say "synchronized" 
> of course, but
> that doesn't add any information!
>  
> 
Received on Friday, 2 May 2003 09:37:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:18 GMT