MQTT: An Overview
MQTT (MQ Telemetry Transport), is a publish/subscribe, simple and lightweight messaging protocol, designed for constrained devices and low-bandwidth by IBM / Eurotech on 1999. The simplicity and low overhead of the protocol make it ideal for the emerging "machine-to-machine" (M2M) or "Internet of Things" world of connected devices, and for mobile applications where bandwidth and battery power are at a premium. The protocol is openly published with a royalty-free license and a variety of client libraries have been developed especially on popular embedded hardware platforms such as arduino/netduino, mbed and Nanode.
In addition to Universal Messaging's own protocol, NSP interfaces are capable of also accepting MQTT connections over TCP sockets, while NSPS interfaces can accept MQTT connections over SSL/TLS for client implementations that support it.
Connecting
In order to connect to a Universal Messaging server using MQTT, you application needs to use a tcp://host:port URL (NSP Interfaces) or ssl://host:port URL (NSPS Interfaces). MQTT connections are treated the same way as any other connections by the Universal Messaging realm. The MQTT client ID value is combined with the optional username (or anonymous if no username is specified) in order to define a nirvana subject as follows:
Client ID_Username@hostname
Figure 1: Connection List with an MQTT connection
This way you can define realm and channel / queue ACLs as you would for any Universal Messaging connection. For example using the IBM WMQTT sample application with a client identifier of MQTT_Utility and no username/password to connect to tcp://localhost:1883 will result in a mqtt_utility_anonymous@localhost Universal Messaging subject.
Publishing
MQTT applications can publish events to channels or queues that have already been created in the Universal Messaging realm. These are regular Universal Messaging channels / queues that can utilise different reliability types (transient, simple, reliable, persistent, mixed) to enforce a persistence policy on all events. Events published via MQTT only contain a byte[] payload and are tagged MQTT. They are fully interoperable with any Universal Messaging subscriber on any client platform supported and can be snooped using the Universal Messaging Enterprise Manager:
Figure 2: Snooping an MQTT message
Subscribing
MQTT applications can subscribe to channels or queues that have already been created in the Universal Messaging realm. These are regular Universal Messaging channels / queues of any reliability type offered and can contain messages published by either MQTT or Universal Messaging applications. Please note that if subscribed to a queue, the pop operation is destructive so each subscriber will get a single event in round robin while channels offer regular pub/sub behavior.
Quality of Service
Universal Messaging supports all three QOS levels defined by the MQTT standard. This is driven by the MQTT client connection and describes the effort the server and client will make to ensure that a message is received as follows:
1. QOS 0: The Universal Messaging realm will deliver the message once with no confirmation
2. QOS 1: The Universal Messaging realm will deliver the message at least once, with confirmation required.
3. QOS 2: The Universal Messaging realm will deliver the message exactly once, using a 4 phase approach as defined by the standard.
Will
Universal Messaging fully supports connections with Will settings, which indicate messages that need to be published automatically if the MQTT application disconnects unexpectedly.
Virtual Payload Types
Universal Messaging now provides MQTT users with the ability to define namespace roots where advanced namespace semantics can be applied. Specifically, the last part of the full topic namespace address can be used to indicate your preferred virtual payload type when publishing or subscribing to a topic. The currently supported types are:
-1: UnspecifiedType (default), binary, equivalent to no type indicator
0: BaseMessageType, Unsupported
1: MapMessageType, UTF-8 JSON on MQTT, JMS MapMessage on native UM
2: BytesMessageType, binary, but identified as JMS BytesMessage
3: ObjectMessageType, java serialized bytes identified as JMS ObjectMessage
4: StreamMessageType, binary on MQTT, JMS StreamMessage on native UM
5: TextMessageType, UTF-8 string on MQTT, JMS TextMessage on native UM