web of things framework implementation challenges

I have been happily hacking on a node.js implementation of the framework as presented in Munich

    http://www.w3.org/2015/04/w3c-wot-framework-munich-2015.pdf <http://www.w3.org/2015/04/w3c-wot-framework-munich-2015.pdf>

This implementation relies on HTTP to retrieve thing descriptions in JSON-LD and WebSockets for communication between proxies and the things that they depend upon. Courtesy of node.js, the scripts are all in JavaScript.

The starting point is when some server script wants to register a new thing for this server:

      register_thing(uri, implementation)

Note that uri must be a URI on this server that resolves to the thing’s description. The implementation is an object that must provide start and stop methods.  The above call retrieves the thing description and binds it to the implementation and calls the start method when all dependencies have been resolved.  As an example consider:

     register_thing(‘/wot/agent.json, {…});

where the agent, has the following description:

// agent.json

{
  "@dependencies" : {
    "door" : "/wot/door.json",
    "light" : "/wot/light.json"
  }
}

The framework then retrieves the descriptions for the dependent things, which are:

// door.jon

{
    "@events" : {
        "bell": null,
        "key": {
            "valid" : "boolean"
        }
    },
    "@properties" : {
        "is_open" : "boolean"
    },
    "@actions" : {
        "unlock" : null
   }
}

// light.son

{
    "@properties" : {
        "on" : {
           "type" : "boolean",
           "writeable" : true
        }
    }
}

If the dependencies are hosted on the same server, we can bind the agent’s thing.door and thing.light to the corresponding objects.  Otherwise we need to create proxies for dependencies hosted on other servers.

One challenge is where a thing is created before the things that it depends upon. We could be treat this as an error, or we could defer calling the new thing's start method until the dependencies have all been resolved.  This involves some book keeping on which things are pending on other things.

Another challenge is the possibility of circular dependencies between things, and a deadlock where things are waiting on each other to be ready. In principle, this could be resolved by a flooding algorithm that traces the dependencies. This algorithm is otherwise known as a topological sort. A similar challenge is tidying up when things are stopped.

My implementation is just an experiment, and a question for the security task force is whether servers need to execute each thing in its own sandbox.  That would complicate the implementation and I would be interested in chatting with people about potential solutions. JavaScript’s getters and setters provides a way to hide the security machinery that would be involved.

Yet another challenge is how to expose the distinction between data and metadata for things. For now, I have made a simple convention of using underscore as a prefix for the names of metadata properties. This is strictly speaking a platform issue as it isn’t exposed externally by web of things servers.

I’ve implemented bindings to WebSockets for the proxy to thing communication and it works nicely for events, property updates and action invocation. I have been able to demonstrate this for accessing things on the same server, and for accessing things from a web page script, although that requires the things to have the same origin and the web page (ignoring CORS for now). 

Here are a couple of examples of the experimental bindings to Web Sockets:

If an event is fired on the thing, the thing server sends to all proxies:

{
  uri: thing's uri
  event: event name
  data: event data
}

If the proxy invokes an action on the thing it sends the following:

{
  uri: thing's uri
  call: call id
  action: action name
  data: action data
}

The implementation provided for a new thing allows you to define an agent that controls other things. It also allows you to interface to sensors and actuators. Node.js provides a suite of modules for Bluetooth, ZigBee and so forth. I am therefore planning on demoing a thing that acts as a proxy for a Bluetooth Smart heart rate monitor.

Although node.js is a great way to explore ideas for the web of things, it is not the only solution, and I expect that servers will vary considerably in their implementation, and the scripting languages that the support. 

A good test of this will be working on a server for a microcontroller e.g. the 8 bit ATMega328 processor as used in the Arduino Uno. This has a 16 MHz clock, 32 KB flash memory, 2KB SRAM and 1 KB EEPROM. There are several implementations of CoAP for the Uno, so a lot of the work has already been done.

A related challenge is managing the communications metadata, given that IoT devices may spend most of their time in deep sleep to save power, and only wake up at scheduled intervals. A server with a proxy for a thing hosted on such a device will have to accommodate this schedule. Further study is needed to understand how this metadata is communicated. It sits at a lower level of abstraction than the metadata describing a thing’s events, properties and actions.

One more challenge is provided by sensors where we need to log a time sequence of sensor values. These may be buffered and merged with data from other sensors for greater efficiency in the communications path. Does anyone have some good real world use cases for this?

I plan to move my code to GitHub as soon as it stabilises, and make it available as an open source project.  Taking an experimental approach to the Web of Things, is a lot of fun, and helps to ground discussions in concrete examples.

—
   Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>