Let’s think about what we can consider some weaknesses of the MQTT protocol …
- it provides native publish/subscribe pattern only; having request/reply is quite cumbersome with “correlation injection” inside topics and payload messages;
- it doesn’t provide flow control;
- it doesn’t have metadata information inside messages (i.e. content type);
- it’s fully broker centric;
but there are some unique features that we have to consider as strengths for this protocol as well …
- retain message also known as “last well known” message;
- last will testament (LWT);
- session handling;
Now, let’s think about the main features that fill the gap for the MQTT protocol but provided by AMQP …
- native support for both publish/subscribe and request/reply patterns (correlation for free);
- flow control at different levels (with max window size and message credits);
- a full type system and metadata information on each message;
- peer-to-peer model (the broker is just a peer);
but it lacks of the above three MQTT features !
So how greater could be AMQP protocol having such features on top of it ?
Under the open source EnMasse project, I have been working on having a design (so a kind of “specification”) for having retain message, last will testament and session handling over AMQP. At same time I have been developing an MQTT “gateway” in order to allow remote MQTT clients to connect to an AMQP based “Message as a Service” like EnMasse.
Having such a design means that not only an MQTT client can leverage on receiving retain message after subscribing to a topic, sending its LWT on connection or receiving messages for a topic when it was offline; it means having the above features for native AMQP clients as well.
Each feature is made by a well defined AMQP message using specific subject, annotations and payload in order to bring all MQTT related information like retain flag, will QoS, will topic and so on but using AMQP semantic.
This sort of “specification” doesn’t force to use a specific implementation; the EnMasse project leverages on the Qpid Dispatch Router for connections and Apache Artemis brokers where state is needed (but other implementations could use something different like a simple file system or a database). Of course, some additional services are needed in order to handle LWT and subscriptions (we called them just “Will Service” and “Subscription Service”).
If you are so curious and want to give some feedback on that, you can find all the open source stuff on GitHub in the MQTT over AMQP documentation section.
Feel free to enjoy the related EnMasse implementation ! 😉