Synchronous Vs. Asynchronous
Many of the more widely-known communications protocols in use operate synchronously. The HTTP protocol – used in the World Wide Web and in web services – offers an obvious example where a user sends a request for a web page and then waits for a reply.
However, scenarios exist in which synchronous behaviour is not appropriate. For example, AJAX (Asynchronous Javascript and XML) can be used to asynchronously send text or XML messages to update part of a web page with more relevant information. Google uses this approach for their Google Suggest, a search feature which sends the user's partially typed queries to Google's servers and returns a list of possible full queries the user might be in the process of typing. This list is asynchronously updated as the user types.
Other asynchronous examples exist in event notification systems and publish/subscribe systems.
- An application may need to notify another that an event has occurred, but does not need to wait for a response.
- In publish/subscribe systems, an application "publishes" information for any number of clients to read.
In both of the above examples it would not make sense for the sender of the information to have to wait if, for example, one of the recipients had crashed.
Applications need not be exclusively synchronous or asynchronous. An interactive application may need to respond to certain parts of a request immediately (such as telling a customer that a sales request has been accepted, and handling the promise to draw on inventory), but may queue other parts (such as completing calculation of billing, forwarding data to the central accounting system, and calling on all sorts of other services) to be done some time later.
In all these sorts of situations, having a subsystem which performs message-queuing (or alternatively, a broadcast messaging system) can help improve the behaviour of the overall system.
Read more about this topic: Message Queue