 | This articleneeds additional citations forverification. Please helpimprove this article byadding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Message queue" – news ·newspapers ·books ·scholar ·JSTOR(May 2009) (Learn how and when to remove this message) |
Incomputer science,message queues andmailboxes aresoftware-engineeringcomponents typically used forinter-process communication (IPC), or for inter-thread communication within the same process. They use aqueue formessaging – the passing of control or of content.Group communication systems provide similar kinds of functionality.
The message queue paradigm is a sibling of thepublisher/subscriber pattern, and is typically one part of a largermessage-oriented middleware system. Most messaging systems support both the publisher/subscriber and message queue models in theirAPI, e.g.Java Message Service (JMS).
Competing Consumers pattern enables multiple concurrent consumers to process messages on the same message queue.[1]
Message queues implement anasynchronous communication pattern between two or more processes/threads whereby the sending and receiving party do not need to interact with the message queue at the same time. Messages placed onto the queue are stored until the recipient retrieves them. Message queues have implicit or explicit limits on the size of data that may be transmitted in a single message and the number of messages that may remain outstanding on the queue.[2]
Many implementations of message queues function internally within anoperating system or within anapplication. Such queues exist for the purposes of thatsystem only.[3][4][5]
Other implementations allow the passing of messages between different computer systems, potentially connecting multiple applications and multiple operating systems.[6] These message queuing systems typically provideresilience 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 queuingsoftware (also known asmessage-oriented middleware) includeIBM MQ (formerly MQ Series) and Oracle Advanced Queuing (AQ). There is aJava standard calledJava Message Service, which has severalproprietary andfree software implementations.
Real-time operating systems (RTOSes) such asVxWorks andQNX encourage the use of message queuing as the primary inter-process or inter-thread communication mechanism. This can result in integration between message passing and CPU scheduling. Early examples of commercial RTOSes that encouraged a message-queue basis to inter-thread communication also includeVRTX andpSOS+, both of which date to the early 1980s. TheErlang programming language usesprocesses to provide concurrency; these processes communicate asynchronously using message queuing.
The message queue software can be either proprietary, open source or a mix of both. It is then run either on premise in private servers or on external cloud servers (message queuing service).
Examples on hardware-basedmessaging middleware vendors areSolace,Apigee, andIBM MQ.
In a typical message-queueing implementation, asystem administrator installs and configures message-queueing software (aqueue manager or broker), and defines a named message queue. Or they register with amessage queuing service.
An application then registers a software routine that "listens" for messages placed onto the queue.
Second and subsequent applications may connect to the queue and transfer a message onto it.
The queue-manager software stores the messages until a receiving application connects and then calls the registered software routine. The receiving application then processes the message in an appropriate manner.
There are often numerous options as to the exact semantics of message passing, including:
These are all considerations that can have substantial effects on transaction semantics, system reliability, and system efficiency.
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 wasSun Microsystems'JMS specification, which provided aJava-only abstraction of a clientAPI. This allowed Java developers to switch between providers of message queuing in a fashion similar to that of developers usingSQL databases. In practice, given the diversity of message queuing techniques and scenarios, this wasn't always as practical as it could be.
Three standards have emerged which are used in open source message queue implementations:
These protocols are at different stages of standardization and adoption. The first two operate at the same level asHTTP, MQTT at the level ofTCP/IP.
Some proprietary implementations also use HTTP to provide message queuing by some implementations, such asAmazon'sSQS. 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.
Many of the more widely knowncommunications protocols in use operatesynchronously. The HTTP protocol – used in theWorld Wide Web and inweb 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 (AsynchronousJavaScript andXML) can be used to asynchronously send text, JSON 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 interested in the process of typing. This list is asynchronously updated as the user types.
Other asynchronous examples exist in event notification systems andpublish/subscribe systems.
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 behavior of the overall system.
There are two common message queue implementations inUNIX. One is part of the SYS V API, the other one is part ofPOSIX.
UNIX SYS V implements message passing by keeping an array of linked lists as message queues. Each message queue is identified by its index in the array, and has a unique descriptor. A given index can have multiple possible descriptors. UNIX gives standard functions to access the message passing feature.[7]
msgget()IPC_CREAT flag is set, it makes a new message queue with the given key and returns its descriptor.msgrcv()msgctl()IPC_RMID flag. A message queue can be deleted only by its creator, owner, or the superuser.The POSIX.1-2001 message queue API is the later of the two UNIX message queue APIs. It is distinct from the SYS V API, but provides similar function. The unix man pagemq_overview(7) provides an overview of POSIX message queues.
Graphical user interfaces (GUIs) employ a message queue, also called anevent queue orinput queue, to passgraphical input actions, such asmouse clicks, keyboard events, or other user inputs, to theapplication program.[9] The windowing system places messages indicating user or other events, such as timer ticks or messages sent by other threads, into the message queue. The GUI application removes these events one at a time by calling a routine calledgetNextEvent() or similar in anevent loop, and then calling the appropriate application routine to process that event.[10]