Presentation on theme: "Thoughts on Architecture for the Internet of Things Group Name: Working Group 2 - Architecture Source: Nicolas Damour, Sierra Wireless"— Presentation transcript:
Thoughts on Architecture for the Internet of Things Group Name: Working Group 2 - Architecture Source: Nicolas Damour, Sierra Wireless (email@example.com)firstname.lastname@example.org Meeting Date: 2013-10-14 Agenda Item: tbd
Goals of OneM2M M2M System for the ManyDiverseMachines InternetofThings
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 ManyScalability – Ten to hundreds of billions – Probably a lot more DiverseExtensibility – Very different things – Things that have not been imagined yet MachinesComputability – 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 Dissertation 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)Leonard Richardson 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 Harry Potter and the Deathly Hallows 978-0545139700 Reply: HTTP/1.1 200 OK Success 6fa-789bcd31-809febb41
RMM Level 1 Multiple resource URIs, single verb (usually POST and/or GET) Request: POST http://webshop.mycompany.com/webshop/orders Harry Potter and the Deathly Hallows 978-0545139700 Reply: HTTP/1.1 200 OK Success 6fa-789bcd31-809febb41
RMM Level 2 Multiple verbs (POST/GET/PUT/DELETE/PATCH), predefined tree Request: PUT http://webshop.mycompany.com/webshop/orders Harry Potter and the Deathly Hallows 978-0545139700 Reply: HTTP/1.1 200 OK 6fa-789bcd31-809febb41
RMM Level 3 Resources and actions linked by hypermedia Request: POST http://webshop.mycompany.com/webshop/orders Harry Potter and the Deathly Hallows 978-0545139700 Reply: HTTP/1.1 200 OK 6fa-789bcd31-809febb41
Pros/Cons of REST Architecture style of the Internet (of Things) – Reliability – Scalability – Extensibility Does not quite address the “Things” side – Communication efficiency – Computability
Your consent to our cookies if you continue to use this website.