Application Platforms for the Web of Things

The Web of Things depends upon applications for its value. In the Interest Group. we’ve talked a lot about thing descriptions and APIs, but very little about applications, and I think this is holding us back.

A microcontroller may be dedicated to a single application. This is the model for the Arduino framework where each device is limited to one application sketch. For home hubs and cloud platforms we need to enable multiple applications to be installed and run. Some apps run in the background without a human machine interface, e.g. a data logger that stores sensor data onto a memory card or which uploads the data to the cloud. Other apps run in the foreground and require a human machine interface.

Imagine using a smart phone to access apps on your home hub. One of these will allow you to manage the installed apps. It will allow you to review the existing apps, to run them, to delete them, and even to install new ones. One way for this to work is for the home hub to act as a web server. At the minimum the hub will need to support HTTP, but it would be better if it can also support WebSockets for asynchronous bidirectional messaging. The hub would also need to support the protocols and communications technologies to access IoT devices.

When it comes to finding new apps to install, you would visit a website on the Internet that is trusted by your home hub. By this I mean that the hub provides the CORS headers that enable a script on web page loaded from an Internet site to communicate with the hub. The CORS header might enable any domain, with the hub requiring a certificate to be provided by the website. I can imagine the web page passing the URI for the app to the hub for it to download, subject to your approval. An app could be delivered as a zipped collection of files. The hub would verify their integrity and install them on local storage. The files would include the human machine interface for the apps, i.e. the HTML and related resources for the web page for accessing the app. The files would also include the scripts for accessing the things hosted by the hub as proxies for the connected IoT devices.

There are challenges for the smart phone to find the home hub, but I am confident that this would soon be overcome as the use of home hubs for smart homes becomes commonplace. Likewise, IoT devices need to be able to discover the hub and register themselves. Alternatively, the hub could discover the devices, but that doesn’t work so well for sleepy battery operated devices that aren’t listening for discovery probes.

Thing descriptions are metadata that describes how applications interact with things, and what protocols and communications patterns, platforms should use to access other platforms. If apps know about classes of devices and the protocols to access them with, then thing descriptions aren’t needed as the information is embedded in the app’s code. So what are the benefits for thing descriptions? They enable gateways to operate without needing to install apps for the given IoT devices, more generally they enable proxy chains, e.g. from an IoT device to a gateway to the cloud and finally to a web page on your browser. They enable services that combine data from different cloud platforms. They enable search and composition of services. They enable simpler applications which can interact with local software objects without needing to know about the communication patterns and protocols.

I am enjoying the slow process of implementing this as open source software, since being able to show people working examples is much more compelling than a slide presentation. My hope is that we can enable a thriving market of apps and services based upon open standards that lower the costs for integration across platforms and in doing so greatly expand the market potential.