Hi everyone,
I had a todo from one of the previous M2M IWG calls to write-up some of my experiences with topic space design. I've based the example topics below on our M2M Scenarios that describe a grocery store refrigeration unit.
Please let me know if you have any questions.
Regards,
James
Eclipse M2M IWG Topic Space Design Thoughts
Within an MQTT design space, there are issues related to topic space design. This is not a unique concern for MQTT, in fact HTTP has already been through many of these issues with URL design. One way to think about MQTT and HTTP is as follows: The difference between MQTT and HTTP is directional: MQTT is to HTTP as PUSH is to PULL. SOAP and REST both use very different design styles on top of HTTP. Both styles are also possible in MQTT topic space design. The following topic space is more aligned with a REST style design. It has relatively few verbs and is organized around resources, which provide representations for the sensors, actuators and devices.
Simplistic Topic Space Design Template
/{verb}/{route-to-device}/{unique-sensor-actuator-id}
Example Topics:
A request for the latest temperature value for zone 1 of refrigeration unit 13 at store 123.
/READ/store/123/refrigeration-unit/13/zone-1/temperature
A report of the latest temperature value for zone 1 of refrigeration unit 13 at store 123.
/REPORT/store/123/refrigeration-unit/13/zone-1/temperature
A request to set the set-point for zone 2 of refrigeration unit 2 at store 456.
/WRITE/store/456/refrigeration-unit/2/zone-2/temperature-set-point
A request for all meta-data for zone 2 of refrigeration unit 2 at store 456.
/META/store/456/refrigeration-unit/2/zone-2
A request for all sensor and actuator ids for a refrigeration unit 2 at store 456.
/LIST/store/456/refrigeration-unit/2
One of the first things you notice is that I've added the VERB in all caps as the first segment. This is by convention only. Next I have a multi-segment path that provides addressibility to the device in question. In these examples that is a refrigeration unit. Finally, I have multi-segment path that provides addressibility to the unique sensor and actuator in question. Multiple paths to the same device is a more advanced topic and not shown here. By limiting the verbs in use and defining tight semantics, it is possible to construct processes that bridge brokers and provide additional services(proxy servers, data historian, etc).
Payload Format
The payloads are not shown, although I highly recommend something programming language neutral. Please do not directly serialize Java or C# objects, you will regret it later. XML can be very heavy-weight for embedded devices to process. I often use CSV or JSON for payloads when dealing with embedded systems. A translation client can be used to rebroadcast after turning XML into CSV/JSON and CSV/JSON back into XML if necessary for enterprise integration.
Advanced Topic Space Design
There are many other best practices for multi-reads, multi-write, meta-data update, dynamic sensor and actuator installation/removal, id claiming, admin features(log retrieval, firmware flashing, etc.). These are explicitly left out of this note in order to avoid distracting from the most simple operations.
As I mentioned above, please let me know if you have any questions or comments.
--
James Branigan
jb@xxxxxxxxxxPartner, Band XI International, LLC
http://www.bandxi.com
919 656 4691
