Thoughts on Architecture for the Internet of Things Group Name: Working Group 2 - Architecture Source: Nicolas Damour, Sierra Wireless (ndamour@sierrawireless.com) Meeting Date: 2013-10-14 Agenda Item: tbd

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

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

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

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)

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)

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

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.

Richardson Maturity Model Model developed by Leonard Richardson Author of “RESTful Web Services” (ISBN 978-0596529260) 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

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