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.
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.
How we made it
The first step was server-side – extending the WMQ server to include support for WebSockets. For our proof-of-concept, we wrote our own implementation of the WebSockets protocol from the specification, building it into the WMQ engine.
It’s still a work-in-progress, but even now, without any gzipping this library is only 20KB and has no dependencies on any additional libraries or frameworks. So it’s already looking pretty good for use in mobile web apps.
Finally, we wrote a few web apps to demo how the JS client library can be used, and how MQTT can work over the web. This included a few mobile web apps, showing how you could push this to browsers in smartphones on the edge of the network.
What this means
This is pretty cool. I’ve wanted to talk about this since January, but it’s one of the things being demonstrated at our Impact conference in Las Vegas so I’ve had to be patient. But Impact starts today, so I can finally share.
It’s another way web apps could be a part of an overall enterprise messaging ecosystem. (To be fair, it’s not the first way – we’ve had REST HTTP support for years, and I’ve seen more than one web page using Java applets to receive MQTT messages).
But, for many web apps, I think this is nicer. No applets, mobile friendly, and no AJAX polling.
Let me pick one simple, trivial example.
Imagine a web page with the latest score from a Wimbledon tennis match.
Tennis scores change so frequently and rapidly that you will either show scores that are out of date (bad for the user) or have to poll very frequently (bad for the server).
A push-based approach is much more efficient – each web page tells the server which match it is interested in, and when a new score is available, the server pushes it to the browser where the page can be updated instantly.
Up to the second updates. A mobile web app for the real-time web.
Without needing large numbers of clients to hammer the server with polls. And all backed by server technology with over a decades experience in doing ultra secure, massively scalable, bullet-proof reliable messaging.
Where it works
To be fair, not all mobile web browsers support WebSockets out-of-the-box. But iPhone and BlackBerry do, which was enough for a proof-of-concept.
On the desktop, Chrome and Safari come with WebSockets support, and you can enable WebSockets in Firefox and Opera, too.
Where to find it
Don’t know, just yet. Sorry. It’s an unreleased technology preview. Something that shows you the sort of stuff we’re thinking about and playing with.
Legal types would likely want me to stress that you can’t treat my blog like a product announcement or guaranteed release commitment, but that’s obvious, right?
Who is “we”?
I didn’t do all of this myself, so I should add a few names in here. First and foremost, a massive amount of work was done by Andrew Banks in WMQ Development and James Thomas in Emerging Tech.
And when I ran into problems getting to grips with the nuances of implementing the WebSockets protocol, a bunch of other colleagues also took time to help me, including Rob Smart, Ben Hardill and Patrick Mueller so a grateful thanks to them, too.