Interoperability in

IoT
 Minimal
energy
consumption
Limited Size

Limited
computational
power

Limitation of IoT Devices

Light processing load

Lightweight protocols
2
The Vertical Cloud Based Solutions

3
Issues Related to the Vertical Cloud Based (2)

◎ Scalability: The number of IoT devices is expected to

reach 50 billion by 2020. At present, with the order of
hundreds of millions of things, everything works, but
are networks and services ready to handle the traffic
generated by billions of things?
◎ Availability: What happens if an Internet connection
becomes temporarily or permanently unavailable?
Relying on the cloud would just make the service
unavailable.
4
Issues Related to the Vertical Cloud Based (2)

◎ Interoperability: All device-to-cloud applications do not allow

direct interactions among things made by different manufacturers.
Interoperability can occur only at the cloud level, through system
integration of the data itself, if such data are made available to
external applications.
◎ Security: Even though secure and authorized access to cloud
services can be implemented in traditional ways, attackers could
exploit a breach in the cloud to access a huge amount of private
data or implement a DoS attack to prevent users from accessing
their data.

5
Issues Related to the Vertical Cloud Based (3)

◎ Evolution of systems: Device-to-cloud applications

typically need to hard code information into things
(which act as clients), thus making them less robust to
changes on the server side. Any update or upgrade in the
server functionality might have a destructive effect on
the operations of things, which may then require a
software/firmware upgrade to change how they operate
(say, the endpoint they target or the data format they
use).
6
 REST Architecture
REST Architecture as the Web of Things.

◎ One promising approach that is being brought to the IoT is the idea that
it should be built in a similar way to the Internet.
◎ The web has been around for decades and lots of experience has been
gained.
◎ The web was designed to be easy to use, distributed, and loosely
coupled (see below) system for sharing documents.
◎ The architecture of the web is simple enough to make it easy to build
applications and manage content.
7
 REST
REpresentational State
Transfer (REST) is the
architectural style behind the
web. Defined in 2000 by Roy
Fielding.
8
Representation of Resources

◎ Resources are never exchanged directly by endpoints.

Instead, representations of resources are exchanged
between endpoints. A representation is a view of the
state of the resource at a given time.
◎ This view can be encoded in one or more transferable
formats, such as XHTML, Atom, XML, JSON, plain text,
comma-separated values, MP3, or JPEG.

9
Representation of Resources

10
Loosely Coupled means:

◎ The endpoints should contain as little information about each other

as needed to work.
◎ All necessary missing information should be collected while
interacting.
◎ The client must know very few things a-priori.
◎ The server will drive the client and pass in the information required
to progress and to perform the intended operations.
◎ In a highly dynamic, evolving, and gigantic environment such as
the IoT, design principles that lead to create robust applications
must be adopted.
11
Resource Identifiers (1)

◎ A Uniform Resource Iidentifier (URI) identifies a resource

univocally. A URI can be used to address a resource, so that
it can be located, retrieved, and manipulated. URI points
exactly to one resource. URIs can be of two kinds:
○ A uniform resource name (URN) specifies the name of a
resource (e.g., urn:ietf:rfc:2616);
○ A uniform resource locator (URL) specifies how to
locate the resource, (e.g.,
http://example.com/books/123).
12
Resource Identifiers (2)

◎ Generic URI structure

13
Statelessness

◎ An important principle of REST is statelessness.

◎ Statelessness implies that no state information must be
kept on the client and server sides, thus avoiding the
need to use cookies or to introduce the concept of
sessions, which demand a stricter coupling between the
endpoints.
◎ All requests must therefore be stateless. In order to
preserve statelessness, each message must be self-
descriptive.
14
Resource Oriented Architecture (ROA)

REST is based on the concept of a resource.

◎ A resource can be defined as any relevant entity in an
application’s domain that is exposed on the network. A
webpage, a video, and an order on an e-commerce
website can all be considered web resources.
◎ A resource is anything with which a user interacts while
progressing toward some goal.

15
What is a Web Service?

◎ Piece of software that makes itself available over the Internet.

◎ Collection of protocols and standards used for exchanging data
between applications or systems.
◎ The exchange of the data is preferable in standard format like
JCON or XML.
◎ The important aspect of web service is to provide a service not
necessarily an UI for humans.
◎ The web services area meant mostly for other applications or
systems.
◎ Type of web services: SOAP or REST.
16
Websites and Web Services

17
Practical Used of Web Services

◎ Retrieve information about books from Amazon.

◎ Submit an order to Amazon.
◎ Update phone number on Amazon.
◎ Create your own web services to allow operations on
your own website.
◎ For example, mobile apps for Facebook or Amazon.

18
SOAP vs REST (1)

SOAP REST
SOAP stands for Simple Object Access REST stands for Representational State
Protocol Transfer
SOAP is a protocol. SOAP was designed REST is an Architectural style in which a web
with a specification. It includes a WSDL file service can only be treated as a RESTful
which has the required information on what service if it follows the constraints of being
the web service does in addition to the 1. Client Server
location of the web service. 2. Stateless
3. Cacheable
4. Layered System
5. Uniform Interface
SOAP cannot make use of REST since REST can make use of SOAP as the
SOAP is a protocol and REST is an underlying protocol for web services,
architectural pattern. because in the end it is just an architectural
pattern.
19
SOAP vs REST (2)
SOAP
SOAP uses service interfaces to expose its
functionality to client applications. In SOAP,
the WSDL file provides the client with the
necessary information which can be used to
understand what services the web service
can offer.
SOAP requires more bandwidth for its usage.
Since SOAP Messages contain a lot of
information inside of it, the amount of data
transfer using SOAP is generally a lot.
REST
REST use Uniform Service locators to
access to the components on the hardware
device. For example, if there is an object
which represents the data of an employee
hosted on a URL as http://demo.guru99 , the
below are some of URI that can exist to
access them
http://demo.guru99.com/Employee
http://demo.guru99.com/Employee/1
REST does not need much bandwidth when
requests are sent to the server. REST
messages mostly just consist of JSON
messages. Below is an example of a JSON
message passed to a web server. You can
see that the size of the message is
comparatively smaller to SOAP.
20
SOAP vs REST (3)

SOAP
SOAP can only work with XML format. As
seen from SOAP messages, all data passed
is in XML format.
REST
REST permits different data format such as
Plain text, HTML, XML, JSON, etc. But the
most preferred format for transferring data is
JSON.

Source: https://www.guru99.com/comparison-between-web-services.html

21
REST Architecture

A REST architecture builds on:

◎ Clients (or user agents, such as browsers), which are the
application interface and initiate the interactions
◎ Servers (origin servers) host resources and serve client
requests.

22
REST Architecture (2)

A REST architecture is characterized by uniform interfaces: all

connectors within the system must conform to this interface’s
constraints.
Collectively, REST defines the following principles:
◎ Identification of resources
◎ Manipulation of resources through representations
◎ Self-descriptive messages
◎ Hypermedia as the engine of application states.
An application that follows the above principles is termed
RESTful.
23
REST Methods (1)

24
REST Methods (2)

25
26
Thanks!
Any questions?
You can find me at:
@username & user@mail.me

27