Ovum is a firm believer in the premise that there should be no "religion" around specific IoT messaging standards. Message queue telemetry transport (MQTT) is not a new messaging standard and existed well before the rise of IoT. However, with support from major software (including middleware) vendors and the wider IoT ecosystem, it is well placed to continue to enjoy an increasing footprint in enterprise IoT.
While not a silver bullet to IoT interoperability, MQTT has a significant lead over competing standards
Discussions regarding IoT interoperability frequently revolve around how to achieve this without relying on wishful thinking that one day in the very near future all major stakeholders will agree on and promote a specific set of messaging standards. While for several years MQTT was considered to be an IBM-promoted standard, the development of Mosquitto, an open source MQTT broker, helped in removing the misleading “proprietary” tag. However, the most noteworthy acceptance came from OASIS (Organization for the Advancement of Structured Information Standards), which approved MQTT v3.1.1 as an OASIS Standard in October 2015.
MQTT is data format-agnostic and its low bandwidth and minimal packet overhead aligns with the requirements of constrained devices and unreliable networks. MQTT Its used across at gnostic and ould like to exploit existing middleware stacks for IoT messaging and is used across several vertical-specific IoT use cases, and endorsements from Facebook, which exploits MQTT for its messenger, and Amazon (MQTT is a primary transport protocol for AWS IoT platform), have added to its credentials. It is possible to assign a quality-of-service (QoS) level to MQTT messages and this can be used to achieve an optimal balance between performance and reliability.
However, there are some limitations that need to be addressed to mitigate data security-related concerns. MQTT was developed at a time when security was hardly an important aspect. While several enterprises have used security mechanisms, such as the use of transport layer security and network security capabilities as add-ons over MQTT, more mission-critical and sensitive use cases will require baked-in security features. Then there is a need to implement message expiry policies so that old messages do not choke the functioning of a MQTT broker. Moreover, MQTT broker availability could be a make or break factor for the success of MQTT-based IoT messaging.
A few other protocols, such as advanced message queuing protocol (AMQP), constrained application protocol (CoAP), and data distribution service (DDS), are also gaining ground, but their use and endorsement across different segments of the wider IoT ecosystem is significantly lower than that of MQTT. These protocols also have their inherent limitations.
Saurabh Sharma, Senior Analyst, Middleware