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:
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.
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:
- What is The Object Network again?
- IoT Rules: Event->Action versus State->State
- Links between Thing Objects
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.
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.