thoughts on architecture for the internet of things group name: working group 2 - architecture...

Thoughts on Architecturefor the Internet of Things

Group Name: Working Group 2 - ArchitectureSource: Nicolas Damour, Sierra Wireless (ndamour@sierrawireless.com)Meeting Date: 2013-10-14Agenda Item: tbd

Goals of OneM2MM2M System

for the

Many Diverse Machines

Internet of Things

The Internet of Things

• Many– 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/2REST = Representational State TransferDissertation 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/2The Uniform Interface as “Central Feature” (Fielding, §5.1.5):•Resource identificationIndividual resources identified in requests (eg. by URIs).A resource is not the same at its representation.•Resource manipulationA 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 ModelModel developed by Leonard RichardsonAuthor 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 URIExamples: SOAP, XML-RPC

•Level 1 – ResourcesMultiple resource URIs, single verb (usually POST and/or GET)Examples: old-schools RoA systems

•Level 2 – VerbsMultiple verbs (POST/GET/PUT/DELETE/PATCH), predefined resources treeExamples: Amazon S3, Twitter, ETSI M2M

•Level 3 – Hypermedia Controls ATEOASResources and actions linked by hypermedia, discoverability and evolvability

RMM Level 0HTTP (or like) as a transport, single service URIRequest: POST http://webshop.mycompany.com/webshop

<create-order xmlns="http://webshop.mycompany.com/webshop">

<items>

<book>

<name>Harry Potter and the Deathly Hallows</name>

<isbn>978-0545139700</isbn>

</book>

</items>

</create-order>

Reply: HTTP/1.1 200 OK

<response>

<code>Success</code>

<order xmlns="http://webshop.mycompany.com/webshop">

<id>6fa-789bcd31-809febb41</id>

</order>

</response>

RMM Level 1Multiple resource URIs, single verb (usually POST and/or GET)Request: POST http://webshop.mycompany.com/webshop/orders

<create-order xmlns="http://webshop.mycompany.com/webshop">

<items>

<book>

<name>Harry Potter and the Deathly Hallows</name>

<isbn>978-0545139700</isbn>

</book>

</items>

</create-order>

Reply: HTTP/1.1 200 OK

<response>

<code>Success</code>

<order xmlns="http://webshop.mycompany.com/webshop">

<id>6fa-789bcd31-809febb41</id>

</order>

</response>

RMM Level 2Multiple verbs (POST/GET/PUT/DELETE/PATCH), predefined treeRequest: PUT http://webshop.mycompany.com/webshop/orders

<order xmlns="http://webshop.mycompany.com/webshop">

<items>

<book>

<name>Harry Potter and the Deathly Hallows</name>

<isbn>978-0545139700</isbn>

</book>

</items>

</order>

Reply: HTTP/1.1 200 OK

<order xmlns="http://webshop.mycompany.com/webshop">

<id>6fa-789bcd31-809febb41</id>

</order>

RMM Level 3Resources and actions linked by hypermediaRequest: POST http://webshop.mycompany.com/webshop/orders

<order xmlns="http://webshop.mycompany.com/webshop">

<items>

<book>

<name>Harry Potter and the Deathly Hallows</name>

<isbn>978-0545139700</isbn>

</book>

</items>

</order>

Reply: HTTP/1.1 200 OK

<order xmlns="http://webshop.mycompany.com/webshop">

<id>6fa-789bcd31-809febb41</id>

</order>

<links>

<link type="content" url="/webshop/books/978-0545139700" />

<link type="status" url="/webshop/orders/6fa-789bcd31-809febb41/status" />

</links>

Pros/Cons of REST

• Architecture style of the Internet (of Things)– Reliability– Scalability– Extensibility

• Does not quite address the “Things” side– Communication efficiency– Computability