These days I seem to mainly use this blog for once-a-year announcements of what I'm up to, which is useful as record for myself when I need to reflect.
So here's where I'm at, as 2015 begins.. ...
These days I seem to mainly use this blog for once-a-year announcements of what I'm up to, which is useful as record for myself when I need to reflect.
So here's where I'm at, as 2015 begins..
Some time ago, in summer 2012, I announced that I was focusing on end-user programming of virtual worlds in Android.
I called the language Cyrus at the start of 2013 and swore I'd stick to it. Well, that was obviously a dumb choice, since she got in the news that August, doing all kinds of embarrassing things.
I spent the second half of 2013 playing with Minecraft modding in Cyrus, followed by a year-long exploration through 2014 of using Augmented Reality to interact with the Internet of Things.
Core Goal
So now I'm back to that core goal: end-user programming of virtual worlds in Android, but now with a splash of Minecraft, a sprinkling of Augmented Reality and a pinch of the Internet of Things.
Of course, any virtual world today feels like it came from the last century if it refuses to acknowledge the tactile accessibility that was discovered by Notch in his world-sweeping game.
Android is an ideal platform for all this, because it is clearly AR-native, plus it can be used as a Thing - especially with sensor-packed, Bluetooth-enabled Android tablets and phones becoming such a cheap commodity.
I want to make the language more accessible to normal people by bumping up the number of dimensions used to access it: from my one-dimensional text format (which I still think is pretty clean and nice to read) to a two-dimensional graphical or visual interface.
Names
So, while I wait to see if "Cyrus" is actually viable in the longer term to name the language, this year's names are back to the Object Network and NetMash. I'm also still using "FOREST" and "Functional Observer" to describe the architectural style and programming model, respectively, if anyone asks.
But since I'm focusing my energies on end users not technical folk, I'm not expecting anyone to ask..
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.
This article first appeared on the ThoughtWorks Insights pages. ...
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.
This article first appeared on the ThoughtWorks Insights pages.
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.
After filling up that other blog recently with 61 pages of content, one page a day, I was challenged by my ThoughtWorks colleague, Andy McWilliams, to help him get in more easily to my explanations of the Object Network applied to Augmented Reality and the Internet of Things, especially around how my approach differs and is better than other approaches. ...
After filling up that other blog recently with 61 pages of content, one page a day, I was challenged by my ThoughtWorks colleague, Andy McWilliams, to help him get in more easily to my explanations of the Object Network applied to Augmented Reality and the Internet of Things, especially around how my approach differs and is better than other approaches.
Here's the short overview I came up with:
Other Approaches
Broadly-speaking, existing approaches to unifying the IoT (AllJoyn, OpenHAB, The Thing System, Nitrogen, Argot, ..) are built around event and action messages. Messages are often managed through a message bus and/or an API that gives message construction and a function-call and callback interface, perhaps through socket connections.
Programming is offered through "event-action" (or "callback-call") rule programming, perhaps in Javascript or via a visual programming interface like If This Then That.
The Object Network Approach
The Object Network, on the other hand, is built like the Web, using URLs. These URLs point not to Web pages but to JSON state objects. Any peer can publish state objects on URLs - e.g. sensors, controllers, mobile devices, servers, etc - and that state can be pulled or pushed at any time between peers using HTTP GET and POST (or CoAP!).
Object Network programming is based, not on events and messages, but on state and state transfer. So instead of event-action rules, it has "state-to-state" rules, which are simpler and more powerful. Actions, if needed, are handled by creating "intent objects", but peer objects are very much more empowered and independent, so can run their own rules to set their own state in the face of surrounding state objects observed through their links.
Three Object Net Posts
I then pointed Andy at one of the posts on that other blog, but here are three posts there that are relevant:
Benefits of The Object Net Approach
These posts give more elaboration around the benefits of this approach, but briefly:
Using URLs is a force towards harmonisation of the formats they are contained in - each end of the link will tend to come from the same family of formats. So simply putting URLs in JSON is itself a massive benefit, if it leads to common formats for the same data. Further, these links and shared formats, when used across multiple systems, form a "fabric" of data that can be used to serendipitously create whole new applications and mash-ups.
It's a simple and powerful distributed systems model, as the Web itself has demonstrated. When it becomes peer-to-peer and asynchronous through CoAP, IPv6 and the IoT, its power increases further through timeliness and interactivity, decentralisation and the removal of intermediaries - and puts that power in the hands of users in their intimate daily lives.
To this the Object Net adds the simple and powerful programming model of setting object state as a function of surrounding neighbour, environmental or public object states, observed through links. The key aspect is the autonomy of each object in the network to determine its own state evolution in a decentralised, loosely-coupled mesh.
CoAP-based Alternatives
Now, merely using the CoAP stack buys you most of the above approach, being chartered from the start with REST in mind, plus adding asynchronous resource observation and having great peer-to-peer potential through IPv6 and UDP.
So really, it all depends on the code that uses it - does it build the observation model into the programming model like the Object Network does? Does it simply let you describe how the state of your object can be set according to the states of objects you link to and observe? Does it talk about common data formats? I've yet to track down a framework or platform that does this.
The nearest I've seen to an approach that has many of the elements of this, including observation through CoAP and a model layer above, is the Open Source Internet of Things (and see here also). This project seems to be much more complex, partly due to its being based on the Semantic Web.
I'll be exploring how the Object Net compares to it and the overall CoRE approach, and maybe also see how the IPSO Alliance and other initiatives fit in to all that.