Difference between revisions of "IoT/M2MIWG/M2M-Interface"

Latest revision as of 10:18, 4 February 2014

This section has been started to move from the scenarios to architecture proposal. A key interface point based on a proposal started by James Branigan that starts by mapping topic spaces form into commonly used programming models like SOAP or REST that run over HTTP.

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.