- From: Damodaran, Suresh <Suresh_Damodaran@stercomm.com>
- Date: Thu, 1 May 2003 17:08:38 -0500
- To: "'Champion, Mike'" <Mike.Champion@SoftwareAG-USA.com>, www-ws-arch@w3.org
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 Thursday, 1 May 2003 18:09:15 UTC