Getting started with publish-subscribe messaging systems
Note: In this article we are using "publish-subscribe" in the context of software architecture.
What is Publish-Subscribe?
Publish-subscribe is a messaging facility. It describes a particular form of communication between software modules or components. The name is chosen to reflect the most significant characteristics of this communication paradigm.
In simple communications, software modules communicate directly with each other using structures and media that are understood by all parties. As the communications needs have become more complex or demanding, other communications architectures have evolved. Publish-subscribe is one of these and only one of many.
The Central Ideas of Publish-Subscribe
- Software components do not necessarily know who they are communicating with.
- Producers of data publish that data to the system as a whole.
- Consumers of data subscribe to and receive data from the system as a whole.
- Information is labelled so that software modules can identify the available information. This label is often referred to as the topic.
Figure 1: An example of a publish-subscribe system. (Source: Nuvation Engineering)
Other Common Publish-Subscribe Ideas
Note: Not all publish-subscribe systems make use of these concepts.
A central software module takes care of managing and matching all the data, the publishing, and the subscribing. This is commonly termed the “broker”. Brokers may sometimes be a network of cooperating software modules, and the software modules that use the services of the broker are referred to as clients.
Clients that publish and subscribe often “register” with the broker in order to manage communication paths, authenticate clients, and to facilitate other housekeeping tasks.
Message delivery to subscribers filtered by content as opposed to topic. This can be used instead of or in conjunction with the topic. This is only implemented by a few Publish-Subscribe systems.
Data can be “persistent”, meaning that the last published data for a particular topic will be available to subscribers that register on the system after the publisher last published the data.
Example: Home Heating System
Here is a small example of a system that could be built using publish-subscribe. It is a home heating system. It has a temperature sensor, a heating unit, and a central control unit.
The data (topics) are:
- Temperature in the house. Published by the temperature sensor and subscribed to by the central control unit. Has the value of the current in-house temperature.
- Heating Request. Published by the control unit and subscribed to by the heating unit. Has the value of either “On” or “Off”.
Pseudo-code for the temperature sensor:
Register as a client.
Read the temperature
Publish the “Temperature in the house” value
Wait for a time interval
Pseudo-code for the heating unit:
Register as a client
Subscribe to the “Heating Request” topic
Turn off Heating
Wait for a “Heating Request” datum to be published
Turn the Heat on or off in accordance to the published value
Pseudo-code for the control unit:
Register as a client
Subscribe for the “Temperature in the house” topic
Wait for a “Temperature in the house” datum to be published
or for a change to the minimum temperature that is desired
Compare temperature with desired minimum
Publish a “Heating Request” datum with the appropriate value (On or Off)