The message queue paradigm is a sibling of the publisher/subscriber pattern, and is typically one part of a larger message-oriented middleware system.
[2] Many implementations of message queues function internally within an operating system or within an application.
Examples of commercial implementations of this kind of message queuing software (also known as message-oriented middleware) include IBM MQ (formerly MQ Series) and Oracle Advanced Queuing (AQ).
Real-time operating systems (RTOSes) such as VxWorks and QNX encourage the use of message queuing as the primary inter-process or inter-thread communication mechanism.
Examples on hardware-based messaging middleware vendors are Solace, Apigee, and IBM MQ.
An application then registers a software routine that "listens" for messages placed onto the queue.
Historically, message queuing has used proprietary, closed protocols, restricting the ability for different operating systems or programming languages to interact in a heterogeneous set of environments.
An early attempt to make message queuing more ubiquitous was Sun Microsystems' JMS specification, which provided a Java-only abstraction of a client API.
This is because it is always possible to layer asynchronous behaviour (which is what is required for message queuing) over a synchronous protocol using request-response semantics.
However, such implementations are constrained by the underlying protocol in this case and may not be able to offer the full fidelity or set of options required in message passing above.
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.
The unix man page mq_overview(7) provides an overview of POSIX message queues.