Protocols are for Interop

I had a quick back and forth with Clemens Vasters via twitter about his views concerning MQTT. I definitely understand his frustrations at the way the protocol is being marketed, but my view as a newcomer to the “IoT” environment was that MQTT is a perimeter protocol to make it easier to get a message into your system from a simple device. The only thing an MQTT endpoint should be doing in my eyes is handing off the message to an internal bus so that it can be further processed.

Clemens mentioned to me that is not how it’s being sold and we both agree that it does have its place as a perimeter protocol. This brings me to my big point. Your infrastructure should not adhere to an external protocol. Protocols are for interop, and as such are limited to what a committee of implementors can agree on. Internally, you should be using a much more efficient and targeted means of communication. Take for instance the OBD-II protocol. Automakers are required to support it by law, but internally, they use their own messaging layer that is much more efficient and of course supports more functionality.

Too often I have seen projects pick up the next big buzzword and adopt it without concern as to its best application. SOAP/WSDL is one example. When I hear people asking if they should implement their internal services using SOAP when internally they’re using a homogenous environment it makes me want to pull my hair out (of course this is not as frequent because SOAP isn’t en vogue anymore. Now everyone wants to be RESTful although some of the very things that the RESTafarians were railing against (bloated protocol) are making their way into RESTful frameworks. It’s as if they’re realizing that Metadata for automatic discovery of an API might be a good thing (go figure).

But I digress. I once worked on a project for a major player in the financial sector and their entire application used FIX internally to communicate between components. Gone were the concepts of Object-orientation, if you wanted a property of a particular message, you had to query it from the message structure. To make it simple, it was not the most efficient process (and this was for a realtime system for Forex trading where milliseconds in delay can be the difference in making a profit and eating a loss).

If someone is selling you a protocol as a solution to build your product around, you should ask yourself what’s in it for them. Better yet, tell them “I’ll get back to you on that.” If you want to support a protocol in order to simplify integration with other products make sure that the protocol stays where it belongs, on the outside of your system.