Hi Everyone,
I am working on a web adapter for MQTT, and in general to the whole Internet of Things and M2M worlds. My preliminary work is available at:
http://qest.me/.
It seems everyone is working on this problem, however there is not a shared effort on it, and it is time to reignite the discussion.
I am identifying the requirements for a general solution to this problem:
1) Web-tunnelling of MQTT to achieve compatibility with web apps..
2) REST interface that must enable to read and write the last message from a topic.
3) REST interface to read the history of the messages on a topic/query.
4) No modification to MQTT and pluggable to any MQTT server.
5) Security & Access Control Systems.
6) Support for webhooks, to ease the integration in other server-side systems.
In order to clarify more, I will expand some points.
1) The websocket tunneling issue is longstanding in this community. Some previous attempt has been done, and there was even a proposal for routing binary MQTT inside a websocket tunnel.
I believe that the best approach to make this work is to map MQTT to JSON in a standard way, and then route it inside websocket & polyfills (es.
socket.io or sock.js and the like)
This will simplify implementations and diffusion.
2) While creating an interface for publishing messages is easy, the core issue is on reading them.
For example, ActiveMQ uses a DELETE to read a message, which can timeout if no message is published in a given period of time. This approach is not really web-compatible, so QEST adopt a standard GET approach, exposing to the web every published message (here you can find is my home temperature:
http://qest.me/topics/temp). Every message is stored on a Redis database.
However, exposing the last message on the web is extremely similar to the retained message behavior. In QEST, I did assimilate the two concepts stating that every message is retained, even on MQTT.
At the moment, I am revising this decision to be MQTT-compliant. Still, the web behavior needs to be clear. One possible solution is to expose on the web only retained messages, or ignore the 'retained' flag at the web level and expose everything.
3) An History interface has to be provided. The best work done in that area is Cosm.
However, a standard representation of message meta-data has to be defined.
5) There is much discussion on how to expose M2M and IoT to end users. Exposing it to the web is a key point, and doing it a safe way for both users and devices is extremely important.
In particular, both the provisioning of devices and the pairing between users and devices must be addressed.
This will necessarily lead to a paring protocol on top of both MQTT and HTTP, and might include an OAuth step.
Have you got some suggestions on these topics?
Cheers,
Matteo
