1. Thoughts on Architecture for the Internet of Things
Group Name: Working Group 2 - Architecture
Source: Nicolas Damour, Sierra Wireless
Meeting Date:
Agenda Item: tbd

2. Goals of OneM2M M2M System for the Internet of Things Many Diverse
Machines

3. The Internet of Things Many Diverse Machines
Ten to hundreds of billions
Probably a lot more
Diverse
Very different things
Things that have not been imagined yet
Machines
No human intelligence
But other superhuman capabilities

4. Architecture for the IoT
Many Scalability
Ten to hundreds of billions
Probably a lot more
Diverse Extensibility
Very different things
Things that have not been imagined yet
Machines Computability
No human intelligence
But other superhuman capabilities

5. Communication Architectures
Two complementary approaches
Call Based (RPC) – Information in the Nodes
Topology defined by the processing nodes
Data history stored in nodes (easier for “big data”)
Message Based – Information in the Messages
Topology defined by the pipes (buses or brokers)
Little message persistence (events)

6. Architectural Styles Object-Oriented System Architecture
Comm. between stateful object instances
Comes from OO software arch., unfit for dist. systems
Service-Oriented System Architecture
Comm. betw. stateless service providers / consumers
Introduced statelessness and loose coupling
Resource-Oriented System Architecture
Comm. betw. stateless resource servers and clients
Little message persistence (events)

7. REST Architecture style 1/2
REST = Representational State Transfer Dissertation by Thomas Roy Fielding, 2000
Clients/servers, separated by an interface, can evolve separately
Stateless communication (for servers)
Cacheable responses can be cached between clients and servers
Layered system using proxies invisible to clients and servers
Uniform interface between clients and servers (cf. next slide)
Code on demand (optional) can extend client capabilities

8. REST Architecture style 2/2
The Uniform Interface as “Central Feature” (Fielding, §5.1.5):
Resource identification Individual resources identified in requests (eg. by URIs). A resource is not the same at its representation.
Resource manipulation A representation of a resource (including metadata) is enough to manipulate (create, modify or delete) the resource.
Self-descriptive messages: A message carries enough information (incl. metadata) to describe how to process the message.
Hypermedia as the engine of application state (HATEOAS): Transitions made through actions identified within the hypermedia. All possible actions accessible and identifiable from a fixed entry point (/). No predefined resource structure or list of available actions for a resource.

9. Richardson Maturity Model
Model developed by Leonard Richardson Author of “RESTful Web Services” (ISBN )
Level 0 – The Swamp of POX (eg. SOAP, XML-RPC) HTTP (or like) as a transport, Single service URI Examples: SOAP, XML-RPC
Level 1 – Resources Multiple resource URIs, single verb (usually POST and/or GET) Examples: old-schools RoA systems
Level 2 – Verbs Multiple verbs (POST/GET/PUT/DELETE/PATCH), predefined resources tree Examples: Amazon S3, Twitter, ETSI M2M
Level 3 – Hypermedia Controls ATEOAS Resources and actions linked by hypermedia, discoverability and evolvability

10. Pros/Cons of REST Architecture style of the Internet (of Things)
Reliability
Scalability
Extensibility
Does not quite address the “Things” side
Communication efficiency
Computability