Publish/subscribe
The publish/subscribe model proves effective in various applications, such as smart homes, industrial automation and control, fleet management, environmental monitoring, and smart energy management.
Figure 2. The broker acts as an intermediary and decouples publishers from subscribers.
In smart homes, devices like sensors, actuators, and smart appliances need to communicate with each other and centralised systems. The publish/subscribe model allows different devices to publish sensor data or events, such as motion detection or temperature changes, to specific topics. Subscribers, such as automation controllers or mobile apps, can receive these updates and trigger appropriate actions accordingly.
In industrial settings, IoT systems are employed for monitoring and controlling equipment, processes, and environmental conditions. Field devices, including sensors and actuators, publish data and events related to machine performance, production metrics, or equipment status. Subscribers, such as control systems or analytics platforms, can subscribe to relevant topics and receive real-time updates for monitoring, analysis, and decision-making purposes.
In fleet management and logistics applications, vehicles equipped with IoT devices can publish telemetry data, such as location data and vehicle health information, to relevant topics. Subscribers, which may include dispatch systems, logistics platforms, mobile applications, or others, can subscribe to this data to track vehicle locations, monitor performance, and optimise fleet operations.
The publish/subscribe architecture facilitates efficient and scalable communication between devices and applications. Publishers and subscribers rely on a message broker, serving as an intermediary. When a new message is published on a subscribed topic, the broker forwards it to the appropriate subscribers. The presence of the broker in the publish/subscribe architecture enables efficient information sharing without requiring direct point-to-point connections. It also decouples the publishers and subscribers, allowing for easy scaling, dynamic addition or removal of endpoints, and differentiation of quality of service (QoS) to ensure reliable message delivery.
Exchanging publish/subscribe messages
Figure 2 illustrates how IoT devices interact with a message broker using the MQTT protocol, which is widely used for publish/subscribe exchanges. The broker can be hosted on a cloud-based server, virtual server, or it can be self-hosted on local hardware. Alternatively, a managed broker service like AWS IoT Core can be utilised.
To communicate with the message broker, each endpoint requires a client library or Software Development Kit (SDK). These libraries provide APIs and functions, including the protocol stack necessary to establish a connection with the messaging broker, publish messages, and subscribe to topics. The libraries handle the underlying protocol details, message serialisation/deserialization, and communication with the broker. Security mechanisms such as Transport Layer Security (TLS) or Secure Sockets Layer (SSL) are also essential to establish encrypted connections and ensure that only authorised devices can publish or subscribe to specific topics.
Event streaming
Event streaming may be a preferable choice over publish/subscribe in certain IoT applications, particularly those that require real-time performance. However, the suitability of publish/subscribe should be assessed based on factors such as data volume, frequency, and the need for guaranteed message delivery.
In event streaming, data is ingested, analysed, and acted upon immediately upon arrival, enabling fast response times and decision-making. Data flows continuously, which is advantageous in time-critical applications where immediate actions or alerts are necessary based on incoming data. Conversely, in the publish/subscribe model, messages may not be processed in real-time.
For event streaming, an event streaming platform such as Apache Kafka is required. Kafka is capable of handling large-scale event ingestion and processing, providing high throughput, fault tolerance, and scalability. Event streaming is particularly suitable for IoT applications that deal with a substantial influx of data from numerous devices. Frameworks like Kafka Connect can be utilised to stream large data sets into and out of Kafka. Additionally, streaming platforms often offer data storage capabilities, whereas in the publish/subscribe model, the responsibility of data storage lies with the subscribers.
Due to these characteristics, event streaming is frequently chosen for applications like real-time industrial control, energy management in smart grids, traffic monitoring, congestion detection, and adaptive signal control in smart cities. Other applications include fleet management and logistics, where real-time tracking of vehicles enables efficient route optimisation, proactive maintenance, and timely response to incidents or delays.
To communicate with the event-streaming platform, typically hosted in the cloud, IoT devices can utilise device-to-cloud protocols like MQTT or CoAP. However, these protocols are designed for low-power devices and may not be suitable for handling large data sets. For Big Data deployments, platforms like Kafka are often employed. Additional management tools and APIs may be necessary to facilitate large-scale interactions with the streaming platform and assist with device management and distribution of authentication credentials.
Conclusion
Implementing an IoT deployment can vary in scale, ranging from a small number of sensors within a home or small building to thousands of sensors spread across a vast geographical area. Various protocols and data-ingestion models are available and selected based on criteria such as data volume, endpoint message-processing capability, real-time response requirements, and the types of cloud applications utilised. The software-developer community offers a plethora of products, including message brokers and data-handling platforms, in different variations to cater to this diversity.
Whatever the choice made between Event streaming and publish/subscribe, the security (authentication, integrity and confidentiality) must be ensured by the appropriate methodology.
