In contrast with publish/subscribe messaging, which allows a publisher to send a message to multiple subscribers, point-to-point messaging is designed to allow communication from one message producer to one message consumer.
Note that this is at the individual message level. A single producer can send messages to multiple consumers and a consumer can receive messages from many producers. However, a particular message will be sent from one producer to just one consumer.
Queues provide the underlying mechanism by which messages sent by producers are held by the micro broker until a consuming application is ready to receive and process them. Queuing allows you to:
- Communicate between programs (which might each be running in different environments) without having to write the communication code.
- Select the order in which a program processes messages.
- Balance loads on a system by arranging for more than one program to service a queue when the number of messages exceeds a threshold.
- Increase the availability of your applications by arranging for an alternative system to service the queues if your primary system is unavailable.
In message queuing terminology, a message
is a collection of data sent by one program and intended for another program. A queue manager
is a system program that provides queuing services to applications. It provides an application programming interface so that programs can put messages onto, and get messages from, the queues it manages. A queue manager also provides additional functions so that administrators can create new queues, alter the properties of existing queues, and control the operation of the queue manager.
Message queuing is a technique for indirect program-to-program communication. It can be used within any application where programs communicate with each other. Communication occurs by one program putting messages onto a queue (owned by a queue manager – the micro broker in this case) and another program getting the messages from the queue. There are no physical connections between programs that communicate using message queues. This process is illustrated in the figure below.
Figure 1. Point-to-point messaging
As already mentioned, the point-to-point messaging paradigm provides one-to-one messaging. Programs requesting others to do work do not have to wait for the reply to a request. They can do other work, and process the reply either when it arrives or at a later time. When writing a messaging application, you need not know (or be concerned about) when a program sends a message, or when the target is able to receive the message. The message is not lost; it is retained by the queue manager until the target is ready to process it. The message stays on the queue until it is removed by a program.
A program can assign a priority to a message when it puts the message onto a queue. This determines the position in the queue at which the new message is added. Programs can get messages from a queue either in the order in which the messages appear in the queue, or by getting a specific message. (A program might want to get a specific message if it is looking for the reply to a request that it sent earlier.)
The physical nature of a queue depends on the operating system on which the queue manager is running. A queue can either be a volatile buffer area in the memory of a computer, or a data set on a permanent storage device, such as a disk. The physical management of queues is the responsibility of the queue manager and is not made apparent to the participating application programs. Programs access queues only through the external services of the queue manager. Typical operations include opening a queue, putting messages on it, getting messages from it, and closing the queue. An administrative interface provides the ability to set and inquire about the attributes of queues.
The micro broker incorporates a queue manager that supports point-to-point messaging and queues as described above.
When you enable the option to create queues dynamically (the default setting), the micro broker creates a queue automatically if a message consumer or producer is created for a previously unknown queue. Dynamic queues have the benefit that administration is unnecessary unless you want to change the default values for settings, such as maximum queue depth. A dynamic queue will automatically expire and be deleted if it sits empty and is not used for a defined amount of time. See Configuring the broker for more information.
Parent topic: Understanding messaging applications