Pub/Sub

In software architecture, publish–subscribe is a messaging pattern where senders of messages, called publishers, do not send those messages directly to receivers, called subscribers, but instead characterize published messages to topics without knowledge of any subscribers. Similarly, subscribers express interest in one or more topics and only receive messages that are of interest, without knowledge of which publishers created the messages.

Message Filtering

In the publish–subscribe model, subscribers typically receive only a subset of the all messages published. The process of selecting messages for reception and processing is called filtering. There are two common forms of filtering: topic-based and content-based.

In a topic-based system, messages are published to “topics” or named logical channels. Subscribers in a topic-based system will receive all messages published to the topics to which they subscribe, and all subscribers to a topic will receive the same messages. The publisher is responsible for defining the classes of messages to which subscribers can subscribe.

In a content-based system, messages are only delivered to a subscriber if the attributes or content of those messages match constraints defined by the subscriber. The subscriber is responsible for classifying the messages.

Topologies

In the pub/sub solution for RAILS, publishers post messages to a message broker and subscribers register subscriptions with that broker, letting the broker perform the filtering. The broker also performs a store and forward function to route messages from publishers to subscribers.

The Eclipse-Mosquitto open source software supports MQTT protocol and functions as a message broker. The following table shows some of the sensors used, now and in the future, in RAILS as well as the topics published and subscribed with the JSON message formats.