Messaging Protocols

An understanding of both the architecture and the message / data sharing requirements of each target system is an important pre-requisite for choosing the most appropriate messaging protocol solution for the Internet of Things IoT and Industrial Internet IIoT. A number of key messaging technologies are emerging that will support the next generation of IoT applications. These messaging technologies include Data Distribution Service DDS, Constrained Application Protocol CoAP, Message Queuing Telemetry Transport MQTT, Advanced Message Queuing Protocol AMQP, Java Message Service JMS, eXtensible Messaging and Presence Protocol XMPP and Representational State Transfer REST, each of which can be used to connect devices in a distributed network. However, their suitability to support the different operational scenarios considered, including Inter and Intra Device communication, Device to Cloud communication and Inter Data Center communication varies, especially when key system requirements such as performance, quality-of-service, interoperability, fault tolerance and security are taken into account.

Messaging Protocol Technologies Internet of Things

AMQP and JMS have been designed to address applications requiring fast and reliable business transactions. JMS is focused on Java-centric systems although there are a number of vendors who have developed proprietary C and C++ JMS API mappings that can be used with a JMS broker. As an API standard, JMS cannot guarantee interoperability between producers and consumers using different JMS implementations.

MQTT provides a simple and lightweight device data collection solution, although only partial interoperability between MQTT publishers and subscribers can be guaranteed. Messages can be exchanged between different MQTT implementations but unless the format of the message body is agreed between peers, the message cannot be un-marshaled.

REST provides a simple client-server (request/reply) style of communications that is useful for systems that need to communicate over the Internet, but it cannot provide asynchronous loosely coupled publish-and-subscribe message exchanges. The stateless model supported by HTTP can simplify server design, however the disadvantage of statelessness is that it may be necessary to include additional information in every request and this extra information will need to be interpreted by the server. This can be very inefficient is terms of request processing time and resources consumed (e.g. number of TCP/IP connections).

CoAP was designed to support the connectivity of simple low power electronic devices (e.g. wireless sensors) with Internet based systems. It can be used for data collection in systems that do not require very high performance, real-time data sharing or real-time device control. In many cases data is collected for subsequent “offline” processing. A CoAP device is connected to a cloud-based system via a HTTP proxy using a standard CoAP-HTTP mapping. Using a proxy/bridge adds an additional communication overhead and increases message latency.

XMPP can support distributed message exchanges between processes on a single node (Intra Device). However XMPP was not designed for high performance message exchanges within the same mode and is more appropriate when used to communicate between nodes or with internet based applications.

Choosing AMQP, MQTT, JMS or REST for systems where a device needs to fan-out messages to perhaps thousands of other networked devices can result in poor performance and much complexity (e.g. requiring a multi broker configuration). CoAP however, supports IP multicast, enabling a single request to be issued to multiple CoAP devices concurrently.

Unlike DDS, which provides support for dynamic discovery, configuring a system that uses AMQP, MQTT or JMS is through the broker. Accessing the broker is usually via a well known network address or a lookup service such as JNDI. If the broker is moved to a different server then clients must be re-configured to use the address of broker’s new location.

Only DDS can provide the real-time, many-to-many, managed connectivity required by high-performance device-to-device applications. DDS is also emerging as a key interoperable messaging protocol for connecting real-time device networks to Cloud based Data Centers. Vendor specific implementations of DDS such as PrismTech’s DDS can also offer exceptional intra-nodal data sharing performance.

Ensuring that a system is fault-tolerant and secure is a key consideration in an IoT world consisting of potentially many thousands of devices all exchanging information. Most of the messaging technologies discussed in this document view security as an orthogonal issue to their core messaging functionality. The leading vendor implementations typically provide proprietary solutions based on tried and tested third party security technologies such as SSL or TLS. AMQP specifies the use of SASL to provide a pluggable message authentication interface and the forthcoming OMG DDS Security Specification will standardize a comprehensive security framework for DDS-based systems.

Finally, it is worth mentioning that in some cases it may make sense (perhaps for legacy reasons) to create a system that uses more than one messaging technology within the same architecture.  In this case, custom mediation schemes or protocol bridges to exchange messages between clients using different protocols are required. This may not provide the optimal solution but is a common scenario particularly as a system evolves and there is need to integrate new and legacy applications.

PrismTech's Vortex is underpinned by the leading (commercial and open source) implementation of the OMG DDS standard to ensure that is is an ideal solution for the data-centric messaging protocol needs of the Internet of Things and Industrial Internet.