CoAP and a Web of Things Watching Things

With the expansion of the Internet of Things (IoT), and the diversity of products and technologies, the one thing that everyone agrees on is that it's time to start agreeing: the Internet of Things needs standards. Many agree that it needs open standards, like those that underpin the Web.

Obviously, a Web of Things is going to be quite different from the Web of Documents and Applications: it'll be much more fine-grained and much more "buzzy," with many sensors and actuators working together with many hubs and services. It's more likely to be at home with the next generation of the Internet Protocol: IPv6.

To meet the fine-grained and buzzy nature of the IoT, the Constrained Application Protocol, or CoAP, was created. CoAP is an open Internet standard for the Web of Things. It's based on the Web's core pipe: HTTP, but has many differences to allow it to be used by very resource-constrained devices and local radio networks.

CoAP can be used in many different ways, but there's a danger that a lack of clarity in exactly how it's used means it doesn't achieve its full potential to link up the world's embedded devices.

This article proposes a simple and clear way that CoAP could be used to build a uniform, global, decentralised Web of interacting and discoverable Things.

CoAP's Interaction Model

In simple terms, CoAP says you should send an Internet packet (UDP) to request a device's data - a GET on a device URL - and then expect back a packet with that data, perhaps a sensor value. You can also push a packet of data to a device - a POST to its URL.

An extension to CoAP for observation allows you to keep on receiving back data packets following a GET as the device state at its URL changes.

Ways of Interacting and Programming

This simple protocol is actually quite unique in the IoT world. Most IoT approaches work through events and messages - sensors and actuators may be connected to an event stream or message bus. The model used to program Things reflects this: events and messages tend to lead to actions and commands, and thence to central control, either in a central server in the house or a service in the cloud. Central control tends towards silos and proprietary formats and application protocols.

CoAP's Web-based model of devices with their own URLs is quite different. The Web that CoAP belongs to works through decentralisation - empowering everyone to publish and link up to anyone else. These links encourage everyone to use the same formats for their data, leading to re-use and "mashability." The lack of centralisation and greater interoperability leads to greater freedom to quickly innovate and build on top of each other's data.

But since the event/action or message/command model is so familiar in the IoT world, many people will inevitably try to use CoAP in this way, and miss out on all the benefits that have been proven by the unprecedented scale of the Web.

And even if they do embrace the CoAP and Web model, there's still sufficient flexibility in there to allow various groups of people to go their own way and lose many of the benefits. For example, people still don't have to use links between their worlds and don't have to share the same formats. They don't have to use POST in exactly the same way to achieve dynamic interaction with devices. The way Web APIs have gone - to create thousands of isolated silos - is strong evidence of this risk.

Peer-to-Peer Programming of Things

So what way should everyone use CoAP? Well, like I said, people should at least link up in a Web and use the same formats for lights and dimmers and locks and temperature. And use the definition of those formats to guide the POST-side interaction models.

However, unlike the Web of large-scale documents and applications, of browsers and Webservers and client-server asymmetry, the Internet of Things is an Internet of sensors and actuators and hubs; interacting devices which work as symmetric peers in a, potentially IPv6, mesh.

This symmetry and peer-to-peer interaction are embraced in the CoAP model and can lead to an interesting, simple and powerful approach to the Internet of Things, and to the evolution of the Web itself. There's an opportunity here to go one step further than the Web, through a simple and powerful programming model based on peer observation.

The Light Depends On The Light Level Sensor

For example, consider possibly the simplest IoT interaction imaginable: a light that reacts to a sensor measuring the ambient light level and colour temperature, by adjusting its brightness and colour accordingly, either to match or to compensate.

There are two peers - and we don't need a central controller. The light depends on the sensor. They both have URLs, so the light can link to the sensor. We are using CoAP, so the light can observe the sensor itself:

The light depends on the light level sensor. That's the simple, powerful interaction and programming model that CoAP allows us to use - if we allow Things themselves to be the observing client. The state of a Thing depends on the states of the other Things that it links to. You can also have other abstract, non-real Things interacting in the peer mesh, which we can still call Objects.

I won't go into detail here about exactly how CoAP would be used to achieve this: the URLs and payload formats and the use of GET, observe and POST that enables Things to be client observers. I'll document that elsewhere, but it'll be based on my FOREST architectural style and the Object Network.

Things Watching Things

The Internet of Things can be a mashable Web of Things. If we're going to use CoAP to build that fine-grained, "buzzy", decentralised Web, then we should use it like the Web: we should agree on the formats for device data, and link up all of our Things and non-Thing Object data via their URLs. The common formats should also define how POST is to be used. That's the basic requirement.

We can then take a bold step further by exploiting CoAP's observation mechanism, to build a symmetric peer mesh of Things and Objects that link to, watch and depend on each others state: simply by allowing Things and Objects themselves to be the observing clients. That's all I'm proposing - that Things just watch each other instead of being observed by invisible processes.

This is a peer-to-peer model, where every player in the IoT is autonomous: empowered to control itself and to evolve its own published state independently and concurrently. That can create a global, visible, loosely-coupled peer mesh of mutually-observing, interoperating and co-operating Things and Objects.

Programs to animate these peer Things and Objects can be extremely simple: you only need to describe how their new state should be set as a function of the states around. This is similar to programming a spreadsheet. It's also an inherently concurrent and distributable programming model. My Cyrus programming language is designed to express this kind of program. 

Duncan is a principal consultant with our Thoughtworks London office. Read more of his thinking on IoT on his blog or follow him @duncancragg.