ReadWriteHack

Fifty billion Internet-capable devices - if that indeed is the number - capable of communicating sensor data through the networks we use today, probably won't have Ethernet plugs. And if they're mobile by nature, they won't rely on Wi-Fi routers. If soon there are more devices communicating over the Internet than there are people, states the general presumption since the 50 billion projection was first quoted last year, there simply isn't that much wireless spectrum to cover it all.

This is where this story would end if we all put our faith in presumptions instead of technology. Last January, the Organization for Economic Cooperation and Development (OECD) published a report (PDF available here) that foresaw a world of intercommunicating devices as a critical component of a healthy global economy. It noted the term "Internet of Things," but settled upon the more industrial term for the concept, machine-to-machine communication (M2M). The report created use cases for M2M devices that were as simple as automotive speedometers registering relative speed, perhaps to other devices within the same car, to brake monitoring systems that communicate a car's relative ability to stop to insurance companies. But the system that could make M2M both ubiquitous and inexpensive, the report made clear, is ironically the same system that carriers like AT&T are begging to decommission: the 2G network.

There's a public relations brochure template someplace that reads, "________ is changing the way the world does business." If this were a Mad-Lib, you could insert the proper noun of your choice. Historically, evolutionary changes in both business and the economy that supports it, have mandated the need for subsequent changes in technology. There are certain very notable exceptions (thank you, Tim Cook), but let's be honest and admit that databases didn't spring up from gardens like daisies and change the landscape of business from winter into spring. There was a need for relational databases that went far beyond keeping up with the competition.

So when companies say that big data will change the way you work... really? Is that the best value proposition that vendors can come up with - "It's coming like a thunderstorm, so you'd better be prepared?" In the final part of ReadWriteWeb's conversation with IBM Vice President for Big Data Anjul Bhambhri, which continues from part 2, I told her a true story about a customer on a vendor webcast that was set in its ways and resisted the change that the PR folks were saying was inevitable.

The picture recently painted of a network of ubiquitous connectivity for each and every class of processor-endowed device on the planet goes so far as to suggest that things such as shipping tags, pacemakers, pipeline stress sensors, thermometers, and nuclear radiation monitors expose their methods to the world - perhaps with a RESTful state. Only through such openness could the spark of ingenuity for a standardized, all-purpose API be generated.

As KORE Telematics President and COO Alex Brisbourne told us in Part 1 of this three-part discussion with ReadWriteWeb, the engineering of such specialized devices may actually work against the creation of such an API. But commonality and generalization of functions are what drive costs down for device manufacturers - the more specialized something is, the smaller its potential market. Is there anything that "intelligent device" managers could learn from the design of existing, specialized, narrowcast (to use Brisbourne's term) devices that developers may apply to the architecture of the devices that real-world apps will remotely monitor and manage?

It is no surprise to anyone who has covered either the computing or telecommunications markets for any length of time that manufacturers' visions of the future are centered around the ubiquity of the products they create. The 2007 vision of ubiquitous communications among carriers revolved around a kind of flip-phone with a detachable antenna you might wear on your head or in your pocket. When the iPhone happened, it was called "disruption," but really in the sense that a bad dream was disrupted by a better reality.

The 1995 vision of ubiquitous computing from Microsoft revolved around a universal acceptance of the role of packaged software; the word "Internet" was surgically inserted into a later draft of Bill Gates' The Road Ahead. So when you look carefully at concepts of an "Internet of Things" (IoT), if you're a veteran, you might want to focus on what these things are supposed to be. KORE Telematics President and COO Alex Brisbourne (whose business is machine-to-machine communication, or M2M) has done precisely that, and shares his thoughts with us in part 2 of his three-part discussion with ReadWriteWeb.

The way IBM sells the concept of the "Internet of Things" is as a new, fully functional, and perhaps even separate Web for the exchange of data between devices. "It makes it possible, potentially, for every device on the network to communicate and share information with every other device," reads an IBM blog post last month. As ReadWriteWeb's conversation with IBM software architect Andy Piper discovered, that marketing characterization may not be entirely in alignment with the actual MQTT architecture - and for good, solid reasons.

Some types of real-world communications that IBM claims requires a new Web that's the stuff of dreams, are already happening on a practical level without such a Web. This is what we've learned from Alex Brisbourne, the president and COO of KORE Telematics. Since 2003, KORE has been developing wireless connectivity systems for devices that need to share data with other devices, often over limited distances, in the machine-to-machine (M2M) market space. Brisbourne is an outspoken advocate of inter-device communication, though he warns that the scale of the systems on which this communication is, and should perhaps continue to be, limited.

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.

Although we've described it as a separate Web for devices, not people, Andy Piper of IBM's WebSphere MQ messaging team emphatically describes MQTT protocol in ways that are not at all analogous to the HTTP protocol we're accustomed to. Endpoint devices with low battery power and extremely limited networking - the kind embedded in sewer pipes whose purpose may be to send a signal meaning, "I'm not broken" - do not need a browser. And besides, they couldn't handle one if you tried.

It makes MQTT a very limited wire protocol, one whose only purposes are to let a device send a very short message one hop up the chain to an MQ broker, and to receive push-button-like commands from that broker. So what's to stop someone from building a similar device, planting it in the vicinity of the broker, and making it send the signal instead? Or to have a process impersonate a device through the Web - the one you and I use - that the MQ broker may mistakenly interpret to be from the device... say, from an ATM machine? ReadWriteWeb raised that issue with IBM's Andy Piper, in a continuation of our interview from last Friday.

He is officially called the "Messaging Community Lead" for IBM's WebSphere message queue (MQ) architecture, which is a title that grants some modicum of honor without claiming too much authority. Andy Piper has become IBM's point man for the concept of a planet enmeshed in billions, perhaps trillions, of signal-sending, communicating devices. The case may be made that anything that can be "on" could be made to send a signal on a network - perhaps something as simple as "on" itself, periodically. The possibilities for a world where the operating status of any electronic device may be measured from any point on the globe, are astounding.

One of the early promises of HTML5 was that it would become an enabler, giving smaller developers some of the power they needed to produce bigger tools on a broader platform. In recent months, however, it's become a common channel for driving developers and users towards native platforms. Whereas last year, developers criticized Microsoft for invoking the phrase "native HTML5" with respect to Internet Explorer, today you can't look anywhere in the HTML5 landscape without seeing some major provider's native interests looming on the horizon.

And Facebook is among those with an interest in HTML5. Last week, Charles Jolley, a popular developer whose dream since his time at Apple was for a JavaScript library called Strobe.js to enable and then to distribute cross-platform apps, found himself and his colleagues working for Facebook. It's difficult for anyone, including Jolley, to say exactly whether Facebook will be able to advance his original dream. But there were some things Jolley did want to say for the record, as soon as he was permitted to, and so he found himself speaking to ReadWriteWeb.

The cloud is a very different order of machine than the computer. It's less like a telephone switchboard and more like one of those automat cafeterias you'd find all over New York City in the 1940s, like the Horn & Hardart. It's a long wall full of desirable resources accessible by way of simple tokens. Imagine instead of selecting already prepared food from one of these walls, you had to schedule the ordering and cooking as well, dish by dish.

You'd need something that the cafeteria -- or rather, that the cloud didn't provide for itself. Java started something with the incorporation of a middleware layer. Python has Django, and Ruby is so well defined by Rails now that HR managers think the language itself is called "Ruby on Rails." But every middleware layer is vastly different, designed according to the requirements of its language. For Scala -- and its new cloud environment of choice, Heroku -- there's Akka.