Every addressable resource on the Web has what W3C now calls a Uniform Resource Identifier (not URL, but URI). Anything that can provide information to a client in response to a request, may be addressed using this syntax. It takes care the what, where, and how.
How will the Internet of Things make everything addressable by every other thing, as explicitly promised by IBM – which is proposing one candidate for an IoT protocol in the form of MQTT? In the concluding part of ReadWriteWeb’s discussion with MQTT engineer and WebSphere MQ community lead Andy Piper (continued from part 2 last Tuesday), we learned how IBM is actually now in its second decade of working out a kind of “thing taxonomy” – a way for its messaging queue protocol to resolve the where and how of contacting a small, MQTT-enabled device by first sorting through what it is.
Directory assistance
The Domain Name System, such as we have come to understand it, divides the global pool of addressable resources into domains and subdomains. This system does not get replaced in the IBM scheme. Brokers – the arbiters of connectivity between MQ servers and MQTT-enabled devices – may still be addressable through URIs, or whatever else may come along. IBM leaves this part open. But the devices inside the “local loops” of each broker will be further subdivided by a system of topics, the categories and subcategories of which may be determined by the developer on a per-application basis.
“The way that publish-and-subscribe works is that you publish on a topic. The classic example is stock prices. So you have something like ‘Stocks / Tech / IBM’ or ‘Stocks / Tech / someone else,’ Piper explains to us. “And you say, ‘I’m either interested in Stocks / Tech / one individual company’ or you say, ‘I’m interested in everything that comes through the Stocks / Tech’ line, or, ‘I’m interested in all stocks.’ You actually do already have, within the topic space, that kind of limitation of devices. Then you can add things like location, and so on.”
Inside a spare bedroom in Andy Piper’s house in Guildford, UK, is an MQTT broker to which several controllable devices are attached, including a few thermometers. One other device is a home energy meter, which he’s rigged to transmit current wattage consumed periodically. His colleagues’ homes are rigged similarly. Their data sets are transmitted via WebSphere MQ to another broker at IBM’s Hurlsley Development Labs. The result is a little contest: Who uses the least energy over certain times of the day?
Conceivably, higher levels in the MQ topics taxonomy could apply to similar devices worldwide, whose brokers would be connected via the Web or another protocol. So at the levels above the individual brokers, imagine “super-topics” that may apply to entire industries, or to geographies at the provincial, country, and regional levels.
“We have this customer in America, an energy company called Concert who already does smart metering with their customers, measuring their customers’ energy usage across a region,” relates Piper. “When they see an energy spike occurring, they’re actually using our technology to send messages over Verizon’s network down to the home energy meters, and having them switch off the pool heater or the air conditioning or whatever the customer has designated that can be modified, in order to manage those energy spikes. It’s a real, smarter energy story. Rather than just giving people a simple LCD display that shows them how much energy they’re using inside the home, they’re actually doing adaptive behavior through their energy network.”
I’ll let you see my thermometer if you let me see yours…
If the topical network corresponds to a language that any human can readily interpret and understand, then what’s to prevent a malicious user to access data to which he’s not entitled, or to set someone’s thermostat to 90 degrees in the dead of winter just to spite?
IBM’s Piper responds, “It comes back to this idea of topology. I can’t access your home PC because it belongs to you, it’s behind your home router, and that router’s connected to your ISP and I have no relationship with it. But if you tell me your IP address and it’s fully open, then I can attach to it. It’s the same way; I can’t just go and get information from a sensor I don’t know about or haven’t got any access to. It’s in an all-enclosed subnetwork that I don’t see.”
The Web was designed and implemented before there was any rational understanding of the inherent dangers of such a technologically open, permissive architecture. What security there is on the Web has had to be attached, retrofitted. Are there lessons we’ve learned with securing the Web that we can apply to securing the MQTT topics network? Andy Piper believes that at some levels, including sociological and economic ones, MQTT will need to learn its own lessons through practice and implementation, just as the Web did. How an organization – be it a company or a city or a country – chooses to expose data from devices, and to whom, will be for that organization to decide, he tells us.
At lower levels – such as Piper’s own outdoor thermometer – security in and of itself, he believes, may be overkill. “My home weather station sits outside, and I have an MQTT server which relays that information which was, at one point, tweeting the weather (it doesn’t do that anymore, just a pure and simple scripting interface). That’s not a mission-critical system. I wouldn’t really mind if someone did send it a message. It wouldn’t actually respond to it, because it’s not programmed to do so.”
An MQTT cloud?
We’ve discussed here in RWW the possibility of a scenario where small devices that would otherwise need to be controlled by operating systems inside embedded firmware, could instead be operated remotely in a kind of “virtualized device” scenario. Imagine a really, really thin client whose operating system exists on a server. It then communicates what commands the device needs to run through a network. That way, you really could have an Android-powered shipping crate.
It’s the kind of fantasy that IBM considers, we discovered, still fantasy.
“IBM’s own strategy and vision for messaging is, we have this very solid, stable, secure, reliable, well-adopted technology WebSphere MQ for enterprise messaging, but that does not scale down and that does not work well in unreliable networks that run on the tiniest of devices,” said Piper, after a moment’s pause to brush off my silly ideas. “So that’s why we have MQTT for that space. If you want to go really, really fast and run in memory… IBM has a technology called WebSphere MQ Low Latency Messaging, over [IP or] over a protocol called UDP. And it’s designed to be as fast as possible.
“All of our messaging protocols in this space interoperate with one another,” Piper continues. “So you can connect your low-latency environment, if you wanted to (given the impedance match between the two, it’s certainly an interesting question) to your enterprise messaging WebSphere MQ. And you can, if you want to, publish messages from WebSphere MQ applications out to MQ telemetry, MQTT clients. But the point of IBM making this specification open [and] royalty-free, taking it to a standards body, joining an industry working group, open-sourcing our client code, is that we recognize that this is a broader story than just about IBM.”
