Here's another view. At the highest design levels, there is no discussion of sync/async. There are these items to consider:
* A sends something to B. * A can expect a response, or not. * If a response is expected, there will be a time limit. Millis. Seconds. Minutes. Hours. Days. Weeks. If a response is not received within the time limit A will stop waiting/looking/expecting one. What action A takes after the time limit depends upon the specifics of what A is doing. There aren't two forms of communication at this level. Just one. In implementation, one will select the appropriate technology/technique to address the time constraint. The scenario below seems more like a state issue between A and B rather than a communication concern. But I may be misunderstanding the example. -Rob --- In [email protected], ashley.mcne...@... wrote: > > Hi > > I haven't followed this thread particularly closely, so this remark may > not be pertinent. But here goes anyway. > > There is a formal difference between synchronous (RPC type) and > asynchronous communication that can be illustrated as follows: > > Suppose that you have two entities A and B, and suppose you require that: > > Either A sends message x to B or B sends message y to A, but not both. > > Then you *must* use synchronous communication between A and B. The > requirement cannot be realized if the communication is asynchronous. > > This makes the two forms of communication logically different, > independently of how they are implemented. > > Rgds > Ashley
