Differentiating features

A unique and valuable feature of the FairCom MQTT broker is that it automatically persists every message to its embedded database. This makes FairCom DB, a mission-critical, self-managing enterprise database. 

Other brokers immediately forget the messages they publish. FairCom MQ remembers each message so you can view, find, and query previously sent messages. 

Imagine troubleshooting issues by viewing the history of messages sent weeks or months ago. You can verify when a publisher sent a message or prove it didn't. You can verify the timing of previously sent messages. You can look at the data in a previously sent message to confirm it is complete and formatted correctly. You can resend past messages that were not processed correctly by subscribers. You can easily comply with company and government regulations for tracking quality, recall, and processed data.

The FairCom Edge IoT platform uses the persistence of FairCom MQ messages to automatically deliver the data in MQTT messages to other protocols, such as REST, Thingworx, and cloud services.

Another unique value proposition of the FairCom MQTT broker is that it decouples publishers and subscribers. Subscribers cannot affect publishers and vice-versa. Decoupling increases the scalability by allowing publishers to publish as fast as they desire without being affected by slow subscribers or large numbers of subscribers.

Decoupling publishers and subscribers is an essential purpose of a message broker. A publisher should be free to publish messages as fast as it can no matter how many subscribers subscribe to its topics and no matter how slow those subscribers are.

Other MQTT brokers tightly couple publishers and subscribers. The result is that a single slow subscriber or a large number of subscribers delays the MQTT broker from acknowledging publisher requests. Because publishers must wait for the broker to acknowledge QoS 1 and QoS 2 messages, an MQTT broker that couples publishers and subscribers slows down the message publishing process to match the speed of the slowest subscriber. While a publisher waits for the broker to respond, it can fill up its in-memory queue of outgoing messages. When a publisher's outgoing queue is full, it can no longer send messages and must discard messages. If the publisher has an outage, all messages cached in its outgoing queue are lost. When a broker couples publishers and subscribers, critical messages can be lost.

Coupling publishers and subscribers prevents scalability. For example, a slow monitoring application may monitor a topic. In other MQTT brokers, this slow application slows down the publishing process, which can prevent the publisher from publishing critical data.

A mission-critical MQTT broker, such as FairCom MQ, decouples publishers and subscribers. It never loses a message. It supports guaranteed message delivery (QoS 1 messages) without allowing subscribers to slow down publishers. Likewise, a mission-critical broker supports guaranteed delivery of messages only once (QoS 2 messages) without slowing down publishers. Decoupling increases the scalability and reliability of your solution.

Another benefit of the unique ability of FairCom MQ to decouple publishers and subscribers is that it enables the broker to upgrade the quality of service. It enables publishers to publish messages at lower QoS levels and subscribers to subscribe at higher levels. For example, a subscriber that requires the broker to deliver each message only once will receive each message only once.

Other brokers downgrade the QoS of subscribers to match the QoS of a publisher. Downgrading occurs when a broker tightly couples publishers and subscribers. It is a problem because a subscriber needs to receive the requested quality of service. For example — when a publisher delivers a message at QoS 0, this causes a broker to downgrade all subscribers to QoS 0 and breaks QoS 2 subscribers that cannot handle a message delivered more than once. It also breaks QoS 1 subscribers that cannot afford to miss a message.

Some devices, sensors, and equipment publish messages at a fixed quality of service, such as QoS 1. Other devices allow you to change the QoS, but the process can be complex and error-prone. You also need to remember to change the quality of service of all devices when a new subscriber requires a higher quality of service.

A mission-critical broker, such as FairCom MQ, automatically upgrades the QoS of each message to provide subscribers with the guarantees they need to be successful.

FairCom MQ can apply a different transformation process to each message sent to each topic. A transformation process is optional and can have as many or as few steps as you desire. The payload can have data added, reformatted, reshaped, validated, looked up to add to the payload, and more. Transforms can be chained together so the output of one transform becomes the input of another. A message published to one topic can be transformed and delivered to another topic.

When a payload does not conform to your expectations, transformations may not work as expected. The broker logs each issue to the message record stored in the FairCom MQ embedded database so you can see what went wrong with that specific message. Regardless of any transform issue, FairCom MQ stores each incoming message and delivers it to subscribers based on your configuration.

FairCom provides a variety of built-in transforms that can be used to transform JSON payloads. Third-party transforms can also be used to process any MQTT payload, such as images, XML, and Sparkplug B.