Extending WebSphere MQ to include support for WebSockets, allowing messaging to web browsers, including mobile browsers, without any additional client software
I’ve talked about MQTT before – a lightweight messaging protocol that I’ve used both on personal projects and my day job.
It is useful for connections with remote locations where a small code footprint is required and/or network bandwidth is at a premium.
I’ve used it in CurrentCost projects, mobile apps and with small and embedded computers like my Slug.
But in all cases, I’ve needed MQTT client software to talk to the messaging server. Whether writing in C, C#, Java or Python, I’ve needed a client library to get me started, something that knows the sequence of packets that make up the MQTT protocol.
It’d be useful to have a zero-install MQTT client: an MQTT client app delivered over the web, without the user needing to install any additional client libraries, or resort to Java applets.
What this does
One possible way to do this could be WebSockets. Part of HTML5, this is a protocol that describes how to do two-way messaging between web servers and web browsers. And I mean proper two-way communication, including push-notification from the server to the browser, without resorting to hacks or kludges like long polling or hidden iframes.
It’s an emerging protocol, still in draft form, but there are a few implementations around so there are already a few browsers that know how to manage WebSockets.
We’ve been exploring recently how this could work with MQTT – the aim was to build in support for WebSockets into an MQTT messaging server: IBM WebSphere MQ (WMQ).
I’ve mentioned WebSphere MQ before, as back in the dim-and-distant past (well, five or six years ago) I used to be a developer of it.
It’s one of the server implementations that support the MQTT protocol.
By adding support for WebSockets to it, it means that WMQ could send and receive messages to web browsers. It means a web app could be a fully-fledged MQTT client.