Getting started with publish-subscribe messaging systems

December 11, 2017

SMUNNINGS-December 11, 2017

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.

Forever loop:

    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

Forever loop:

    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

Forever loop:

   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)

Continue reading on page two >>


< Previous
Page 1 of 2
Next >

Loading comments...