I think one of the most heated areas of debate in the IoT right now are around standards.   There are two major camps.   The proponents are generally Messaging Oriented Middleware (MOM) oriented or HTTP oriented.   I fall generally into the the MOM camp.   There are instances where HTTP works perfectly fine. It is well understood, easily routable, etc.

There are many other instances where bandwidth availability (DIL* use cases), asynchronous connections, bandwidth cost (e.g., smart metering),  applications requiring complex routing patterns, etc mean you need a MOM solution.

That brings up an even thornier question.  Which MOM-style protocol to you choose.   AMQP, MQTT, CoAP, DDS, XMPP, etc are an a Z away from being a full scrabble set.   There are some proponents that say that there should be one MOM oriented solution for all IoT use cases.  I understand this impulse, but I think it is wrong.

Each standard protocol has it’s own area it shines in, and it’s own deficiencies.   If you take MQTT for example, it is extremely lightweight.  It was designed to use pub/sub to move telemetry from field sensors and devices into mid-tier systems or data centers for processing.   It is not a full MOM solution with complex message handling.   It is designed to move small repetitive bits of data as quickly and cheaply as possible.   It would be a mistake to try to fit MQTT or another protocol into a niche it doesn’t fit into.

It is up to software vendors to support as many of the different protocols as reasonably possible.   I am proud that my employer Red Hat’s A-MQ messaging product supports a huge variety of protocols including OpenWire, AMQP, MQTT, XMPP, STOMP, etc.

If you look at IBM’s laudable commitment to standards based IoT work with MQTT, it is quickly undone by forcing MQTT to bridge into WebsphereMQ.   I am interested in seeing what IBM does with MQ Light and how this fits into their over all vision.

There is a good article I found on this topic that expounds further.  It is called Ending the IoT Protocol Wars.  I don’t agree with all of the author’s conclusions, but it is thought provoking.

I will be talking further about the main areas for standardization over the next few weeks.   These areas are:

  • Network transport standards
  • Protocol standards
  • API standards
  • Data format standards
  • Identity & security standards
  • Management standards

I am sure there are other types of required standards I have missed.  Especially standards that are industry specific.   Please comment on the blog or via twitter (@thingscast) and lets get a lively discussion going.

EDIT:  It was brought to my attention that I didn’t deal adequately with HTTP in this post.   I will discuss that further in a future follow up post.

EDIT 2: I added security standards per suggestion of @paulmadsen. Great feedback. That caused me to add management standards as well.

 

* DIL = Disconnected Intermittent Limited

4026 Total Views 2 Views Today