Not to be confused with the Joomla JApplication message queue which merely stores and retrieves text strings between requests and is used to show error or status messages following a redirect, the message queues being referred to here involve moving payload data from one application component to another, either on the same or different servers. Message queues are a key component in building scalable, resilient and available applications. Further information can be found here: wikipedia:Message queue
Traditionally, message queue software has been associated with enterprise systems that support queued communication between disparate large-scale applications. It provides the essential glue to support classical middleware applications. Payload data is encapsulated in a message that is placed on a message queue for some other application to pick up and process in some way. Message queues allow systems to be resilient in the face of server failure or load spikes and allow for flexible deployment of services via standardised interfaces. Systems can typically be reconfigured dynamically with no loss of data flowing through the system.
Various levels of service are typically supported, from "best effort" support where loss or duplication of messages is of no consequence, through to guaranteed once-and-once-only message delivery that would be required in, for example, financial transactions.
The two most common messaging models will be supported. Firstly, a simple request-reply model where a single message is delivered to a single endpoint with an optional reply message following the reverse route. Secondly, a publish-subscribe model where a single message may be copied to multiple destinations. Subscribers to a message source may opt to have messages either queued or discarded during periods when they are not actively connected to the service.