Introduction
+Introduction
+ +Motivation
- The W3C WoT Architecture [[wot-architecture11]] and the WoT - Thing Description [[wot-thing-description11]] - have been developed as a versatile format, that allows - describing the interactions between multiple devices and - protocols. - + The Web of Things (WoT) seeks to + counter the fragmentation of the + Internet of + Things (IoT) by using and extending existing, standardized + web technologies.
- This flexibility permits an easy integration of new device - types and protocols, however it risks interoperability, - since there are no guarantees that two devices - which are formally spec-compliant, will be able to - communicate. + The W3C WoT Thing Description [[wot-thing-description]] specification + defines the first building block of the Web of Things, by defining an + information model and JSON-based representation format for describing the + capabilities of connected devices and the interfaces with which to + communicate with them.
-To increase adoption of the WoT specifications, - interoperability between on premise devices, edge devices - and the cloud is essential. Even if every manufacturer is - implementing the current Thing Description specification in - full flexibility, there is no interoperability guarantee; - many choices are still left to the implementations and there - are very few normative requirements that a device has to - fulfill.
- -Deployment Scenarios
- -A Thing Description can be used in two fundamentally - different deployment scenarios:
--
-
- a "brown-field" scenario, where it is created - to describe the interactions with existing systems. - -
- a "green-field" scenario, where a device model - and a thing description are developed together. -
- For green field deployments, where the implementations - are being carried out and corresponding thing - descriptions are being created, it is easier to achieve - full interoperability by using a small, extensible HTTP Basic - Profile. -
- -In the brown field area, due to the nature of - existing deployments and protocols, a broad spectrum of - variations and potentially high complexity of thing - descriptions inhibits interoperability and will most - likely lead to additional profiles of the WoT Thing Description - and domain-specific thing consumer implementations.
- -- The WoT HTTP Basic Profile can be used by green field - deployments and gives guidance to new implementers of - the WoT specifications. It has already demonstrated in - brown-field scenarios in the Plugfests, where existing - devices that already existed as products, prototypes or - demonstrators, were described with Thing Descriptions - that are constrained to the HTTP Basic Profile. -
-Summary of Use Cases and Requirements
-- A set of over 30 use cases for the Web of Things were contributed by stakeholders - from multiple industries for various application domains. - These have been published in the WoT Use Cases and Requirements document [[wot-usecases]]. -
-- Based on these use cases a set of requirements have been derived which drive the development - of the W3C Web of Things specification family. - Several of these domains require easy integration of devices from multiple vendors, - in other words, out-of-the-box interoperability. - However, the descriptive approach taken by the WoT specifications generally leads - to a large variety of different protocols and data formats, - which can work against out-of-the box interoperability. -
-- For example, a WoT Thing Description (TD) can in theory include a description based on a - networking protocol unknown to a device that wishes to connect to it. - To ensure interoperability without additional customization (e.g. by writing software or - performing complex setup or configuration steps), - the range of such choices needs to be limited to a finite set so that a consumer - of a Thing Description can be sure it will be able to interact with any possible Thing. - A finite set of customization choices is also important for implementing devices with a fixed code base. - Defining such constraints leads to the profile mechanism and the HTTP Basic Profile. -
-- In addition to multiple vertical use cases that will use HTTP(S) for their implementations, - there are horizontal use cases that are addressed by this profile specification. - The primary focus is to enable Multi-Vendor system integration with out of the box interoperability. -
-Multi-Vendor System Integration - Out of the box interoperability
- Users of devices want to process data from all devices that conform to a class of devices in a uniform way. - They need a guarantee that they are able to correctly interact with all affordances of the Thing - that complies with this class of devices. - Different interpretations of the same Thing Description, that lead to different behaviour, should not be - possible. - Users want to integrate devices in existing scenarios out of the box, i.e. with close to zero configuration - tasks. -+ The Thing Description specification is designed to be protocol-agnostic + and flexible enough to describe a wide range of existing ("brownfield") + IoT devices, rather than specifying a fixed protocol or application + programming interface (API) which all devices must implement. The downside + of this open ended flexibility is that it makes ad-hoc interoperability on + the Web of Things very difficult, because it's nearly impossible to create + a single WoT Consumer [[wot-architecture]] + which is guaranteed to be able to communicate with any + Web Thing [[wot-architecture]] out of the box. +
++ This specification is designed to complement the Thing Description + [[wot-thing-description]] specification, by defining a + Profiling Mechanism and a set of + Profiles which enable + out-of-the-box + interoperability between Web Things and their + Consumers. +
++ Profiles are designed specifically for new ("greenfield") implementations + where developers have the freedom to conform to a prescriptive protocol + binding and set of common constraints, in order to benefit from + out-of-the-box interoperability. +
++ Of the Profiles defined in this specification, only the + HTTP Basic Profile is currently + normative. It is planned that future versions of this specification will + normatively define the HTTP SSE Profile + and HTTP Webhook Profile, but + in this version of the specification they are only informative. +
++ Future versions of this specification, or extension specifications, may + define additional Profiles. +
+Profile Example
++ Example 1 shows a Thing Description + instance that follows the HTTP Basic Profile as described in this + sepecification. +
+ +
+ This Thing Description uses the profile term to signalize that the associated Thing
+ supports the HTTP Basic Profile. As a security scheme, this example enforces authentication before access
+ by using basic authentication ("scheme": "basic") via the HTTP header, which is encrypted via TLS
+ (https in base).
+
- Why a Profile? -
+ +Use Cases and Requirements
++ The Web of Things Interest Group collected use cases for + the Web of Things from stakeholders representing various different + industries. This includes both vertical domain-specific use cases and + horizontal use cases which apply to multiple application domains + [[wot-usecases]]. +
++ Several of the + domain-specific + use cases collected refer to the need for easy integration of + devices from multiple vendors. There was also a + cross-domain + use case collected which describes "multi-vendor system + integration" or "out-of-the-box interoperability". +
++ A set of + requirements + for Profiles were derived from these use cases by + the WoT Profile Task Force of the Web of Things Working Group. +
+- During the recent WoT Plugfests there were many - de-facto agreements on the use of a small constrained - subset of interaction patterns and protocol choices. - These de-facto agreements select a common subset of the - WoT Thing Description, based on - proven interoperability among manufacturers. -
-- The aim of this specification is to formalize these - agreements by defining a set of HTTP - Profiles based on the choices that were made by - the implementers of Plugfest devices. -
-- - The HTTP Basic Profile contains additional - normative requirements that MUST be satisfied by devices - to be compliant to the profile. -
-
- - Adoption of the HTTP Basic Profile will - significantly limit the implementation burden of device - and cloud implementors. -
-- The HTTP Basic Profile was defined with the - following main goals: -
--
-
- guarantee interoperability among all - implementations of the profile. -
- limit the implementation complexity. -
It makes choices on the required metadata fields as - well as the supported interactions and protocol - endpoints. It introduces some constraints on data - schemas for properties and actions which are required - for resource constrained devices in real-world - deployments. The format does not forbid the use of - additional elements of the WoT Thing Description for vendor specific - extensions, however this will impact interoperability.
-Out-of-the-box - interoperability
-- Devices, which implement the HTTP Basic Profile, are out-of-the-box - interoperable with other HTTP Basic Profile - compliant devices. Furthermore, the HTTP Basic Profile - simplifies device validation and compliance testing - since a corresponding conformance test suite can be - defined. -
-- The following classification adopts the terminology as described in the - "H2020 – CREATE-IoT Project - Recommendations for commonalities and - interoperability profiles of IoT platforms" [[?H2020-CREATE-IoT]] - report. - The definitions below have been adapted to reflect the scope of the WoT profile. -
-Technical Interoperability
-Technical Interoperability is usually associated with communication protocols and the - infrastructure needed for those protocols to operate. This implies agreeing on a common protocol - (e.g. HTTP / TCP/IP) and providing additional clarifications, where required. -
+Out-of-the-Box Interoperability
++ The definition of out-of-the-box interoperability used in this + specification includes multiple layers. + The following classification adopts terminology from the + "H2020 – CREATE-IoT Project - Recommendations for commonalities and + interoperability profiles of IoT platforms" [[?H2020-CREATE-IoT]] + report. + The definitions below have been adapted to reflect the scope of the WoT profile. +
+Technical Interoperability
+Technical Interoperability is usually associated with communication protocols and the + infrastructure needed for those protocols to operate. This implies agreeing on a common protocol + (e.g. HTTP / TCP/IP) and providing additional clarifications, where required. +
-Syntactic Interoperability
-Syntactic Interoperability is usually associated with data formats and encodings along with - techniques for compressing them. Examples for these formats and encodings in the WoT are JSON, - XML, JSON-LD, UTF-8 payloads. -
-Semantic Interoperability
-- Semantic Interoperability is associated with a common understanding of the behavior of communication - partners. - In the profile context, it includes a common interpretation of (synchronous and asynchronous) action semantics, - a common event model, how to set/get multiple properties, writable properties, - a common error model and error messages. -
-- Domain specific ontologies, e.g. semantic interop of automotive and medical devices exceed the scope of the - profile. -
-Organisational Interoperability
-- Organisational Interoperability in the profile context implies that any consumer, - which conforms with a given profile can interact with any Thing which conforms - with the same profile, without additional customization. -
-- Organisational Interoperability also requires commonly agreed approaches to security, - trust and privacy, i.e. a consumer is provided access to Things only, when these - common terms and conditions are applied. -
-- Devices created by various engineers, vendors and SDOs that satisfy the requirements - of the profile specification can be integrated with compliant consumers without additional customization. - This works across infrastructures, regions and cultures. -
-Structure of this document
-Syntactic Interoperability
+Syntactic Interoperability is usually associated with data formats and encodings along with + techniques for compressing them. Examples for these formats and encodings in the WoT are JSON, + XML, JSON-LD, UTF-8 payloads. +
+Semantic Interoperability
++ Semantic Interoperability is associated with a common understanding of the behavior of communication + partners. + In the profile context, it includes a common interpretation of (synchronous and asynchronous) action semantics, + a common event model, how to set/get multiple properties, writable properties, + a common error model and error messages. +
++ Domain specific ontologies, e.g. semantic interop of automotive and medical devices exceed the scope of the + this specification. +
+Organisational Interoperability
++ Organisational Interoperability in the profile context implies that any Consumer + which conforms with a given profile can interact with any Thing which conforms + with the same profile, without additional customization. +
++ Organisational Interoperability also requires commonly agreed approaches to security, + trust and privacy, i.e. a consumer is provided access to Things only when these + common terms and conditions are applied. +
++ Devices created by various engineers, vendors and SDOs that satisfy the requirements + of the profile specification can be integrated with compliant consumers without additional customization. + This works across infrastructures, regions and cultures. +
A device or consumer implementation complies with this specification if it follows