Web of Things scripting API
W3C’s vision for the Web of Things focuses on the role of Web technologies for a platform of platforms as a basis for services spanning IoT platforms from microcontrollers to cloud-based server farms. Things are considered to be virtual representations (software objects) for physical or abstract entities. Things are defined as having events, properties and actions, as a basis for easy application scripting. This assumes a clean separation between the application and transport layers, which simplifies scripting by decoupling the details of protocols and message formats, allowing servers to use the protocols that best fit the particular context. Communications metadata allows servers to identify how to communicate with other servers.
The approach is based upon the fundamentals of Web architecture:
- URIs for identifying things
- A variety of protocols for accessing things, since no one protocol will be appropriate in all contexts
- Linked Data for describing things as a basis for interoperability and discovery, playing an analogous role to HTML for web pages
URIs can be used to access machine interpretable descriptions of things. These descriptions enable the automatic generation of scriptable objects whose events, properties and actions correspond to those of the thing the object stands for. An object on one server can act as a proxy for an object on another server. Web developers are shielded from the implementation details of how objects are coupled, allowing system designers to choose the transport protocols best suited to the given context. Servers can be provided at a wide range of scales from microcontrollers to cloud-based server farms.
The diagram shows a thing on server A that acts as a proxy for a thing on server B which is coupled to a sensor and actuator. The script on server A can set listeners for events associated with things, read and update the properties of things, and invoke actions exposed by things and handle the corresponding results (if any). If a script updates a property the server will translate this into a message that it sends to the server hosting the corresponding thing. That server will in turn notify all of its other proxies with the update. The metadata allows the server to optimise the transport layer, e.g. to ensure efficient use of protocols and to cater for battery devices which spend most of their time asleep to extend battery life.
The proxy on server A could be set up by a script on that server, or by a script on server B. The latter is useful when server A is on the public Internet and server B is behind a firewall, and you want to provide public access to the thing from server A.
Web page scripts can create local proxies for things on servers, subject to the protocols supported by Web browsers and the single origin security policy. There are many possible applications across a wide range of domains, e.g. homes, offices, lifecare, cities, electrical grids, retail and manufacturing.
Web page access to things
Web pages running on browsers can access things on Web of Things servers (aka servients), subject to which protocols are exposed to web page scripts, and the browser security policy. This includes HTTP and WebSockets as protocols. By default, the same origin security policy limits the use of scripts with protocols to the same origin that was used to load the web page. This policy can be relaxed using cross origin resource policies (CORS). A web page may even host things for local sensors and actuators, and expose these things on a publicly accessible server.
Common API for scripting things
Servers are free to choose which dynamic or static programming languages they support. Having a common API across these languages (at least at the abstract level) will reduce the effort needed to port applications from one server platform to another, thereby helping to enable an open market of services.
This proposed work item focuses on defining a common API for scripting things, e.g.
- Registering (and unregistering) things along with their descriptions and implementation
- Registering event listeners for events that occur for things, as defined in their data model
- Registering and unregistering proxies for things on other servers.
- Registering a proxy on a remote server for a thing on this server
This API will be defined in an abstract way along with bindings to specific programming languages, e.g. JavaScript.
The latter is used when a server hosting a thing is behind a firewall or NAT boundary, and wants to expose this thing on a server that is accessible on the public Internet.