Transcript oneM2M-ARC-2013-0466R01

Thoughts on Architecture
for the Internet of Things
Group Name: Working Group 2 - Architecture
Source: Nicolas Damour, Sierra Wireless ([email protected])
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
– 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
RMM Level 0
HTTP (or like) as a transport, single service URI
Request: 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 1
Multiple 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 2
Multiple verbs (POST/GET/PUT/DELETE/PATCH), predefined tree
Request: 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 3
Resources and actions linked by hypermedia
Request: 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