| Table of contents |
|
2 Usage 3 Synchronous vs. Asynchronous |
Message queues provide an asynchronous communications protocol, meaning that the sender and receiver of the message to not need to be connected to the message queue at the same time. Messages placed onto the queue are stored there until the recipient retrieves them.
Many implementations of message queues are internal to an operating system or application and are used for the purposes of that system only.
Other implementations allow messages to be passed between different computer systems, potentially connecting multiple applications and multiple operating systems. These message queueing systems typically provide enhanced resiliance functionality to ensure that messages do not get "lost" in the event of a system failure. Examples of commercial implementations of this kind of message queueing software (also known as Message Oriented Middleware) include IBM's MQ Series and Microsoft's MSMQ.
In a typical message queueing implementation, a system administrator would install and configure off-the-shelf message queueing software (a queue manager), and define a named message queue.
One application would then register a software routine that would "listen" for messages placed onto the queue.
A second application would then connect to the queue and transfer a message onto it.
The queue manager software would store the message until the receiving application is connected, and then call the registered software routine. The application would then process the message in an appropriate manner.
Many of the more widely known communications protocols in use in recent times are synchronous in nature. The most obvious example is the HTTP protocol used in the world-wide-web and in web services.
In a synchronous model, one system makes a connection to another, sends a request and waits for a reply.
In many situations this makes perfect sense; for example, a user sends a request for a web page and then waits for a reply.
However, there are other situations in which this is not appropriate. For example, if an application wishes to notify another that an event has occurred, but does not want to wait for a response. Another example is in publish/subscribe systems, where an application "publishes" information for any number of clients to read. In both these 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.
It is in these situations that a message queuing (or alternatively broadcast messaging) system is appropriate.Overview
Usage
Synchronous vs. Asynchronous