Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Binary file added images/wot-use-cases/use-case-summary.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file modified images/wot-use-cases/wot-use-cases-large.pptx
Binary file not shown.
86 changes: 54 additions & 32 deletions index.html
Original file line number Diff line number Diff line change
Expand Up @@ -238,6 +238,7 @@
Security Testing Plan</em> [[WOT-SECURITY-TESTING-PLAN]].
</li>
</ul>
</p>
<p>Overall, the goal is to preserve and support existing
security mechanisms and properties. In general, W3C WoT is
designed to describe what exists rather than to prescribe
Expand Down Expand Up @@ -301,6 +302,7 @@ <h1>Introduction</h1>
</li>
<li>a description of the high level architecture in
chapter <a href="#sec-wot-architecture"></a>
</li>
<li>an overview of the WoT building blocks being
standardized and their interplay in chapter <a
href="#sec-building-blocks"></a>,
Expand All @@ -311,6 +313,7 @@ <h1>Introduction</h1>
</li>
<li>deployment scenarios in chapter <a
href="#sec-deployment-scenario"></a>,
</li>
<li>and security considerations to be aware of when
implementing WoT building blocks in chapter <a
href="#sec-security-considerations"></a>.
Expand All @@ -324,7 +327,6 @@ <h1>Terminology</h1>
<em>This section is normative.</em>
</p>

<p>
<p>This document uses the following terms as defined here.
The WoT prefix is used to avoid ambiguity for terms that are
defined specifically for Web of Things concepts.</p>
Expand Down Expand Up @@ -393,7 +395,7 @@ <h1>Terminology</h1>
enterprise or service provider core networks. Examples
include gateways, routers, switches, multiplexers, and a
variety of other access devices.</dd>
<dt>

<dt>
<dfn>Event</dfn>
</dt>
Expand Down Expand Up @@ -846,13 +848,17 @@ <h4 id="connectedcar-example">Connected Car

<section id="sec-common-usecase-patterns">
<h1>Common Patterns</h1>
<section>

This section introduces common use case patterns that
illustrate how devices/things interact with controllers,
other devices, agents and servers.

<h3 id="device-controllers">Device Controllers</h3>
<p>
This section introduces common use case patterns that
illustrate how devices/things interact with controllers,
other devices, agents and servers.
In this section, we use the term 'client roles' as an
initiator of a transport protocol, and the term 'server roles'
as a passive component of a transport protocol.
</p>

<section id="device-controllers">
<h3>Device Controllers</h3>
<p>
The first use case is a local device controlled by a
user-operated remote controller as depicted in <a
Expand All @@ -869,7 +875,11 @@ <h3 id="device-controllers">Device Controllers</h3>
action. The other device like the remote controller
has a client role that can send a message with a
requests, like to read a sensor value or to turn on
the device.</p>
the device.
Moreover, to emit a current state or event notification of a device,
the device may have a client role that can send a message
to another device, which has server roles.
</p>
<figure id="smart-home-device">
<img
src="images/wot-use-cases/smart-home-device.png"
Expand All @@ -891,7 +901,7 @@ <h3>Thing-to-Thing</h3>
<p>In this case, when two devices that have server
roles are connected, at least one device must have
also a client role that issues a message to the
other to actuate.</p>
other to actuate or notify.</p>
<figure id="smart-home-t2t">
<img src="images/wot-use-cases/smart-home-t2t.png"
style="width: 500px;" />
Expand All @@ -900,7 +910,7 @@ <h3>Thing-to-Thing</h3>
</section>
<section>
<h3>Remote Access</h3>
<P>
<p>
This use case contains a mobile remote controller
(e.g., on a smartphone) as shown in <a
href="#smart-home-multi"></a>. The remote
Expand Down Expand Up @@ -944,9 +954,15 @@ <h3>Smart Home Gateways</h3>
functionality.
</p>
<p>In this pattern, the home gateway has both a
client and a server role. It can connect to the
client and a server role. When the remote controller actuates the electronic appliance,
it can connect to the
electronic appliance in the client role and to the
remote controller with the server role.</p>
remote controller with the server role.
When the electronic appliance emits a message to the
remote controller, the gateway act as server roles
for the electric appliance, and it act as client roles
for the remote controller.
</p>
<figure id="smart-home-gateway">
<img
src="images/wot-use-cases/smart-home-gateway.png"
Expand All @@ -961,7 +977,7 @@ <h3>Edge Devices</h3>
Home gateway. We use the term to indicate additional
tasks that are carried out by the edge gateway.
Whereas the home gateway in <a
href="#smart-home-gateway"></a> primarily just
href="#edge-device"></a> primarily just
bridges between the public and the trusted network,
the edge device has local compute capabilities and
typically bridges between different protocols. Edge
Expand All @@ -970,7 +986,7 @@ <h3>Edge Devices</h3>
aggregation of data provided by connected devices
and sensors.
</p>
<figure id="smart-home-multi">
<figure id="edge-device">
<img src="images/wot-use-cases/edge-device.png"
style="width: 500px;" />
<figcaption>Edge device</figcaption>
Expand Down Expand Up @@ -1123,19 +1139,22 @@ <h2>Summary</h2>
physical locations such as inside building, outside
buildings, and data centers. <a href="#usecase-overview"></a>
is an overview that shows the combinations and
communication paths of these entities. To specify the
different roles of the entities, each entities shown in
the patterns is associated with functional roles such as
a server, a client and a proxy/gateway. That is, the
client corresponds to the application or the controller,
and the server to the device. The proxy/gateway is an
entity that relays the connection between the client and
the server. The gateway is distinguished from the proxy
because it performs protocol converter functionality for
legacy devices that use other (non-web) protocols.
communication paths of these entities.
</p>
<p>
In a transport protocol layer, each entity arbitrarily
selects a suitable role for communications. For example,
a device may act as a server when the device provides a service
to indefinite number of applications. On the other hand,
if a device has limited or intermittent network connectivity,
they may act as a client and actively send message to an application
when network is available. Regardless of this,
in application layer, an application sees that a device provides abstract
interfaces to interact and the application can interact with the device
using their abstract interfaces.
</p>
<figure id="usecase-overview">
<img src="images/arch-use-case-overview.png" />
<img src="images/wot-use-cases/use-case-summary.png" />
<figcaption>Use Case Overview</figcaption>
</figure>
</section>
Expand Down Expand Up @@ -1295,6 +1314,7 @@ <h3>Network</h3>
<li>protocols commonly used in the
local area network</li>
</ol>
</li>
<li>WoT architecture should allow using
multiple web protocols to access to the same
functionality.</li>
Expand Down Expand Up @@ -1349,6 +1369,7 @@ <h3>Legacy adaption</h3>
An IoT device can be either a client or a server,
or both, depending on the system architecture;
the same is true of edge and cloud services.
</li>
</ul>
</section>
</section>
Expand Down Expand Up @@ -1548,6 +1569,7 @@ <h2>Overview</h2>
<a href="#architecture-abstract"></a> shows an overview
of how these WoT concepts can be mapped to various
components and devices in a connected system.
</p>
<figure id="architecture-abstract">
<img src="images/architecture-abstract-new.png"
style="width: 100%;" />
Expand Down Expand Up @@ -1718,7 +1740,7 @@ <h2>Architectural Aspects of a Web Thing</h2>
Thing</figcaption>
</figure>
</section>
<section id=sec-interaction-model>
<section id="sec-interaction-model">
<h2>Interaction Model</h2>
<p>Originally, a Web resource usually represented a
document on the World Wide Web that can simply be
Expand Down Expand Up @@ -2647,7 +2669,7 @@ <h2>System API</h2>
using a <a>WoT Thing Description</a>.
</p>
</section>
<section id="native-impl">
<section id="alt-servient-impl">
<h3>Alternative Servient Implementations</h3>
<p> The <a>WoT Scripting API</a> building block is optional.
Alternative <a>Servient</a> implementations are possible
Expand Down Expand Up @@ -2739,7 +2761,7 @@ <h1>WoT Deployments</h1>
behavior implementation.
</p>

<section id="sec-deployment-app-dev">
<section id="sec-client-server-roles">
<h2>Client and Server Roles</h2>
<p> A <a>WoT Server</a> creates an <a>Exposed Thing</a> abstraction based on a TD.
The TD is published to make it available to
Expand Down Expand Up @@ -3030,7 +3052,7 @@ <h3>Connection Through Thing Directory Synchronization</h3>
Directory Synchronization</figcaption>
</figure>
</section>
<section id="sec-deployment-service-to-service-rm">
<section id="sec-deployment-service-sync-proxy-rm">
<h3>Connection Through Proxy Synchronization</h3>
<p> In <a href="#deployment-service-sync-proxy"></a>, two remote <a>Servients</a>
synchronize device information. When a shadow of <a>WoT Server</a>
Expand Down Expand Up @@ -3106,7 +3128,7 @@ <h2>Definitions</h2>
<dt>Privacy</dt>
<dd>means that the system should maintain the
confidentiality of personally identifiable
information.
information.</dd>
</dl>
</section>
<section id="sec-security-consideration-td-risks">
Expand Down