- Mon Sep 28, 2020 7:34 pm
#88941
Regardless of whether the broker is in the cloud or not, and in fact regardless of whether you're even using MQTT specifically, pub/sub is an architectural pattern that offers a number of capabilities:
- standard connect and disconnect to brokers based on the protocol, not the specific implementation
- receiving only the information you want, through subscription to named topics
- topic subscription filtering so you can subscribe to the same topic with multiple filters that route info different ways
- topics are persistent at the broker, making the protocol fault tolerant (subscribers can retrieve message backlogs if desired)
- different Quality of Service (QoS) levels for your messages, both sending and receiving. QoS0 is send once with receipt not guaranteed (aka "at most once"), QoS1 is send and guarantee receipt by sending multiple times if you aren't acknowledged (aka "at least once"), and QoS2 is send it once and make sure they got it, do not repeat unless you have to (aka "exactly once")
The one thing that all pub/sub architectures do not specify is the nature and format of the payload. They can sometimes specify whether it's compressed or not, but basically it's like sending snail mail to a PO box at a post office (the broker is the postal worker)
- they don't care who sends the mail, they just put it where they're told
- they don't care who collects the mail, as long as they have the right PO box number
- they can redirect the mail to other PO boxes based on rules and the address on the front, but they won't open your mail
- they guarantee that whatever you put in the envelope will be delivered to the PO Box as is and they don't look at the content - if the content's in Eskimo it's up to you to find a translator
So when you decide to use pub/sub as an architectural pattern, the first thing you need to do is define the message content and structure and publish that for someone to use. It's exactly the same as I2C in many ways - you publish or fetch from registers and you use the spec to understand the data.
Cloud platforms have been developed in the same way - they provide an MQTT broker, and they provide management systems that are simply MQTT clients. Then they give you their spec sheet that says what topics they will publish command messages to, and the format for their commands, and also how you can tell them what topics to listen for, and how to read your messages. They typically also provide a generic JSON reader that will turn JSON into objects that their platform can then use to put on graphs and dashboards etc. However, you can choose to build your own application client completely yourself and ignore theirs - the MQTT broker doesn't care.
If you are interested, I would be very happy to web call with you and show you through my set up in the IBM Cloud sometime