IoT Architecture

Unit - II
Basic Building blocks of IoT system
• Four things form basic building blocks of the IoT
system –sensors, processors, gateways, applications.
• Each of these nodes has to have its own
characteristics in order to form an useful IoT system.
Basic Building blocks of IoT system
• Sensors:
• These form the front end of the IoT devices. These are the so-called
“Things” of the system. Their main purpose is to collect data from its
surroundings (sensors) or give out data to its surrounding (actuators).
• These have to be uniquely identifiable devices with a unique IP address so
that they can be easily identifiable over a large network.
• These have to be active in nature which means that they should be able to
collect real-time data. These can either work on their own (autonomous in
nature) or can be made to work by the user depending on their needs
(user-controlled).
• Examples of sensors are gas sensor, water quality sensor, moisture sensor,
etc.
Basic Building blocks of IoT system
• Processors:
• Processors are the brain of the IoT system. Their main function is to
process the data captured by the sensors, so as to extract the valuable
data from the enormous amount of raw data collected. In a word, we can
say that it gives intelligence to the data.
• Processors mostly work on real-time basis and can be easily controlled by
applications. These are also responsible for securing the data – that is
performing encryption and decryption of data.
• Embedded hardware devices, microcontroller, etc. are the ones that
process the data because they have processors attached to it.
Basic Building blocks of IoT system
• Gateways:
• Gateways are responsible for routing the processed data and send it to
proper locations for its (data) proper utilization.
• In other words, we can say that gateway helps in to and from
communication of the data. It provides network connectivity to the data.
Network connectivity is essential for any IoT system to communicate.
• LAN, WAN, PAN, etc are examples of network gateways.
Basic Building blocks of IoT system
• Applications:
• Applications form another end of an IoT system. Applications are
essential for proper utilization of all the data collected.
• These cloud-based applications which are responsible for rendering the
effective meaning to the data collected. Applications are controlled by
users and are a delivery point of particular services.
• Examples of applications are home automation apps, security systems,
industrial control hub, etc.
Basic Building blocks of IoT system
Sensors
• One of the very essential components of internet of things is sensors and the
other one is actuators whereas, the sensors basically sense the physical
phenomena that are occurring around them and the actuators basically based on
the sensed information.
• The actuators, they actuate. That means, they perform some actions on the
physical environment. So, they take some actions based on what has been sensed.
Sensors

• This is a PIR sensor passive infrared sensors.

So, this passive infrared sensor here can be
used for detecting if there is any obstacle.
• So, this is an example of a PIR or obstacle
based sensor.
Sensors
• We have another sensor this is the ultrasonic sensor.
• This basically detects that how far that obstacle is.
• These ultrasonic sensors may send ultrasound waves. So, these
ultrasound waves are sent and then, that sound wave is going to get
reflected back.
• We already know what velocity is and then, depending on how much
time has elapsed from the point sound wave was sensed and the
deflection is received back, based on that the distance is calculated.
• So, this sensor helps in basically getting an idea or sensing how far
an obstacle is from a particular point where the sensor is.
Sensors
Sensor Features
• It is only sensitive to the measured property.
• It is insensitive to any other property likely to be encountered in
its application.
• It does not influence the measured property.
Sensor Resolution
• The resolution of a sensor is basically defined as the smallest
change that it can detect in the quantity that is being measured.
• The resolution of a sensor with digital output is usually the
smallest resolution the digital output it is capable of processing.
• The more the resolution of the sensor, the more accurate is its
precision.
• A sensor’s accuracy does not depend upon its resolution.
Sensor Classes

Based on output
• Analog
• Digital

Based on Data Type

• Scaler
• Vector/ Multimedia
Analog Sensors
• Analog Sensors produce a continuous output signal or voltage
which is generally proportional to the quantity being measured.
• Physical quantities such as Temperature, speed, pressure,
displacement, , strain etc. are all analog quantities as they tend to
be continuous in nature.
Digital Sensors
• Digital sensors produce discrete digital output signals or voltages
that are a digital representation of the quantity being measured.
• Digital sensors produce a Binary output signal in the form 1 or 0.
Scalar Sensors
• Scalar sensors produce output signal or voltage which is generally
proportional to the magnitude of the quantity being measured.
• Physical quantities such as Temperature, speed, pressure,
displacement, , strain etc. are all scaler quantities as only their
magnitude is sufficient to convey an information.
Vector Sensors
• vector sensors produce output signal of the voltage which is
generally proportional to the magnitude as well as the direction
and orientation of the quantity that is being measured.
• physical quantities such as the sound, image, velocity, acceleration
orientation, these are all vector quantities and their measurement
is not just dependent on the magnitude, but also on the direction.
• For example, accelerometer sensor, they give outputs in three dimensions
x, y and z coordinate axis.
Sensor Types
Sensor Types
Physical Design of IoT
Things in IoT
• The "Things" in IoT usually refers to IoT devices which have unique
identities and can perform remote sensing, actuating and monitoring
capabilities.
• IoT devices can
• Exchange data with other connected devices and applications (directly or
indirectly),
• Or collect data from other devices and process the data either locally or
• Send the data to centralized servers or cloud-based application back-ends
for processing the data, or
• Perform some tasks locally and other tasks within the IoT infrastructure,
based on temporal and space constraints (i.e., memory, processing
capabilities, communication latencies and speeds, and deadlines).
Physical Design of IoT
Things in IoT
• An IoT device may consist of several interfaces for connections to other devices, both
wired and wireless.
• These include
1. I/O interfaces for sensors,
2. interfaces for Internet connectivity,
3. Memory and storage interfaces and
4. Audio/video interfaces.
• An IoT device can collect various types of data from the on-board or attached sensors,
such as temperature, humidity, light intensity.
• The sensed data can be communicated either to other devices or cloud-based
servers/storage.
• IoT devices can be connected to actuators that allow them to interact with other physical
entities (including non-IoT devices and systems) in the vicinity of the device.
• For example, a relay switch connected to an IoT device can turn an appliance on/off
Physical Design of IoT
Things in IoT
• IoT devices can also be of varied types, for instance,
wearable sensors, smart watches, LED lights,
automobiles and industrial machines.
• Almost all IoT devices generate data in some form
or the other which when processed by data
analytics systems leads to useful information to
guide further actions locally or remotely.
• For instance, sensor data generated by a soil
moisture monitoring device in a garden, when
processed can help, in determining the optimum
watering schedules.
Physical Design of IoT
IoT Protocols
Physical Design of IoT
IoT Protocols
• Link Layer
• Link layer protocols determine how the data is physically sent over the
network's physical layer or medium (e.g., copper wire, coaxial cable, or a
radio wave).
• The scope of the link layer is the local network connection to which host
is attached.
• Hosts on the same link exchange data packets over the link layer using
link layer protocols.
• Link layer determines how the packets are coded and signaled by the
hardware device over the medium to which the host is attached (such as
a coaxial cable).
Physical Design of IoT
IoT Protocols
• Link Layer
• 802.3 – Ethernet
• IEEE802.3 is a collection of wired Ethernet standards for the link layer.
• For example,
• 802.3 is the standard for 10BASE5 Ethernet that uses coaxial cable as a shared medium,
• 802.3.i is the standard for 1OBASE-T Ethernet over copper twisted-pair connections,
• 802.3.j is the standard for 1OBASE-F Ethernet over fiber optic connections,
• 802.3ae is. the standard for 10Gbit/s Ethernet over fiber, and so on.
• These standards provide data rates from IO Mb/s to 40Gb/s and higher.
• The shared medium in Ethernet can be a coaxial cable, twisted-pair wire or an optical
fiber.
• The shared medium (i.e., broadcast medium) carries the communication for all the
devices on the network, thus data sent by one device can received by all devices
subject to propagation conditions and transceiver capabilities.
• The specifications of the 802.3 standards are available on the IEEE802.3 working
group website
Physical Design of IoT
IoT Protocols
• Link Layer
• 802.11 - WiFi
• IEEE 802.11 is a collection of wireless local area network (WLAN)
communication standards, including extensive description of the link layer.
• For example,
• 802.11a operates in the 5 GHz band,
• 802.11b and 802.11g operate in the 2.4GHz band,
• 802.11n operates in the 2.4/5 GHz bands,
• 802.11ac operates in the 5 GHz band and
• 802.11ad operates in the 60 GHz band.
• These standards provide data rates from I Mb/s to up to 6.75 Gb/s.
• The specifications of the 802.11 standards are available on the IEEE·802.11
working group website.
Physical Design of IoT
IoT Protocols
• Link Layer
• 802.16 - WIMax
• IEEE 802.16 is a collection of wireless broadband standards, including
extensive descriptions for the link layer (also called WiMax).
• WiMax standards provide data rates from 1.5 Mb/s to 1 Gb/s.
• The recent update (802.16m) provides data rates of 100 Mbit/s for
mobile stations and 1 Gbit/s for fixed stations.
• The specifications of the 802.16 standards are readily available on the
IEEE 802.16 working group website.
Physical Design of IoT
IoT Protocols
• Link Layer
• 802.15.4 – LR-WPAN
• IEEE 802.15.4 is a collection of standards for low-rate wireless personal
area networks (LR-WPANs).
• These standards form the basis of specifications for high level
communication such as Zigbee.
• LR-WPN standard provides data rates from 40Kb/s to 250 Kb/s.
• These standards provide low cost and low speed communication for
power constrained devices.
• The specifications of the 802.15.4 standards are available on the IEEE
802.15 working group website.
Physical Design of IoT
IoT Protocols
• Link Layer
• 2G/3G/4G – Mobile Communication
• There are different generation of mobile communication standards
including second generation (2G including GSM and CDMA), Third
generation(3G including UMTS and CDMA2000) and Fourth generation
(4G including LTE).
• IoT devices based on these standards can communicate over cellular
networks.
• Data rates for these standards range from 9.6Kb/s (for 2G) up to 100
Mb/s (for 4G) and are available from 3GPP websites.
Physical Design of IoT
IoT Protocols
• Network Layer
• The network layers are responsible for sending of IP datagrams
from the source network to the destination network.
• This layer performs the host addressing and packet routing.
• The datagrams contain the source and destination addresses
which are used to route them from the source to destination
across multiple networks.
• Host identification is done using hierarchical IP addressing
schemes such as 1Pv4 or IPv6.
Physical Design of IoT
IoT Protocols
• Network Layer
• IPv4
• Internet Protocol version 4 (IPv4) is the most deployed Internet protocol that
is used to identify the devices on a network using a hierarchical addressing
scheme.
• IPv4 uses a 32-bit address scheme that allows total of 232 or 4,294,967,296
addresses.
• As more and more devices got connected to the Intemet, these addresses got
exhausted in the year 2011.
• IPv4 bas been succeeded by 1Pv6.
• The IP protocols establish connections on packet networks, but do not
guarantee delivery of packets.
• Guaranteed delivery and data integrity are handled by the upper layer
protocols (such as TCP).
Physical Design of IoT
IoT Protocols
• Network Layer
• IPv6 :
• Internet Protocol version 6 (1Pv6) is the newest version of Internet
protocol and successor to IPv4.
• IPv6 uses 128-bit address scheme that allows total of 2128 or 3.4 x 1038
addresses.
• IPv4 is formally described in RFC2460.
Physical Design of IoT
IoT Protocols
• Network Layer
• 6LoWPAN
• 6LoWPAN (IPv6 over Low power Wireless Personal Area Networks)
brings IP protocol to the low-power devices which have limited
processing capability.
• 6LoWPAN operates in the 2.4 GHz frequency range and provides data
transfer rates of 250 Kb/s.
• 6LoWPAN works with the 802.15.4 link layer protocol and defines
compression mechanisms for 1Pv6 datagrams over IEEE 802.15.4-based
networks.
Physical Design of IoT
IoT Protocols
• Transport Layer
• The transport layer protocols provide end-to-end message
transfer capability independent of the underlying network.
• The message transfer capability can be set upon connections,
either using handshakes (as in TCP) or without
handshakes/acknowledgements (as in UDP).
• The transport layer provides functions such as error control,
segmentation, flow control and congestion control
Physical Design of IoT
IoT Protocols
• Transport Layer
• TCP
• Transmission Control Protocol (TCP) is the most widely used transport layer
protocol, that is used by web browsers (along with H'ITP, HTTPS application layer
protocols), email programs (SMTP application layer protocols) and file transfer
(FTP).
• TCP is a connection oriented and stateful protocol.
• While IP protocol deals with sending packets, TCP ensures reliable transmission of
packets in-order.
• TCP also provides error detection capability so that duplicate packets can be
discarded and lost packets are retransmitted.
• The flow control capability of TCP ensures that rate at which the sender sends the
data is not too high for the receiver to process.
• The congestion control capability of TCP helps in avoiding network congestion and
congestion collapse which can lead to degradation of network performance.
Physical Design of IoT
IoT Protocols
• Transport Layer
• UDP
• Unlike TCP. which requires carrying out an initial setup procedure, UDP
is a connectionless protocol.
• UDP is useful for time-sensitive applications that have very small data
units to exchange and do not want the overhead of connection setup.
• UDP is a transaction oriented and stateless protocol.
• UDP does not provide guaranteed delivery, ordering of messages and
duplicate elimination.
• Higher levels of protocols can ensure reliable delivery or ensuring
connections created are reliable.
• UDP is described in RFC 768.
Physical Design of IoT
IoT Protocols
• Application Layer
• Application layer protocols define how the applications interface with
the lower layer protocols to send the data over the network.
• The application data, typically in files, is encoded by the application
layer protocol and encapsulated in the transport layer protocol which
provides connection or transaction oriented communication over the
network.
• Port numbers are used for application addressing (for example port 80
for HTTP, port22 for SSH etc.).
• Application layer protocols enable process-to-process connections using
ports.
Physical Design of IoT
IoT Protocols
• Application Layer
• HTTP
• Hypertext Transfer Protocol (HTTP) is the application layer protocol that forms
the foundation of the World Wide Web (WWW).
• HTTP includes commands such as GET, PUT, POST, DELETE, HEAD,
TRACE,OPTIONS, etc.
• The protocol follows a request-response model where a client sends requests to
a server using the HTTP commands.
• HTTP is a stateless protocol and each HTTP request is independent of the other
requests.
• An HTTP client can be a browser or an application running on the client (e.g., an
application running on an IoT device, a mobile application or other software).
• HTTP protocol uses Universal Resource identifiers (URIs) to identify HTTP
resources.
Physical Design of IoT
IoT Protocols
• Application Layer
• CoAP
• Constrained Application Protocol (CoAP) is an application layer protocol
for machine-to-machine(M2M) applications, meant for constrained
environments with constrained devices and constrained networks.
• Like HTTP, CoAP is a web transfer protocol and uses a request-response
model, however it runs on top of UDP instead of TCP.
• CoAP uses a client-server architecture where clients communicate with
servers using connectionless datagrams, CoAP is designed to easily
interface with HTTP.
• Like HTTP, CoAP supports methods such as GET, PUT, POST, and DELETE.
• CoAP draft specifications are available on IEFT Constrained environments
(CoRE) Working Group website.
Physical Design of IoT
IoT Protocols
• Application Layer
• Web Socket
• WebSocket protocol allow full-duplex communication over a single
socket connection for sending message, between client and server.
• WebSocket is based on TCP and allows streams of messages to be sent
back and forth between the client and server while keeping the TCP
connection open.
• The client can be a browser, a mobile application or an loT device.
• WebSocket is described in RFC 6455.
Physical Design of IoT
IoT Protocols
• Application Layer
• MQTT
• Message Queue Telemetry Transport (MQTT) is a light-weight
messaging protocol based on the publish-subscribe model.
• MQTT uses a client server architecture where the client (such as an IoT
device) connects, to the server (also called MQTT Broker) and publishes
messages to topics on the server.
• The broker forwards the messages to the clients subscribed to topics.
• MQTT is well suited for constrained environments where the devices
have limited processing and memory resources and the network
bandwidth is low.
• MQTT specifications are available on IBM developerWorks.
Physical Design of IoT
IoT Protocols
• Application Layer
• XMPP
• Extensible Messaging and Presence Protocol (XMPP) is a protocol for real-
time communication and streaming XML data between network entities.
• XMPP powers wide range of applications including messaging, presence,
data syndication, gaming, multi party chat and voice/video calls.
• XMPP allows sending small chunks of XML data from one network entity to
another in near real time.
• XMPP is a decentralized protocol and uses a client server architecture.
• XMPP supports both client to server and server to server communication
paths.
• ln the Context of IoT, XMPP allows real-time communication between IoT
devices.
• XMPP is described in RFC 6120.
Physical Design of IoT
IoT Protocols
• Application Layer
• DDS
• Data distribution service (DDS) is a data centric middleware standard
for device to device or machine to machine communication.
• DDS uses a Publish Subscribe model where publishers(e.g., devices that
generate data) create topics to which subscribers(e.g., devices that want
to consume data) can subscribe data.
• Publisher is an object responsible for data distribution and subscriber is
responsible for receiving published data.
• DDS is described in Object Management Group (OMG) DDS specification.
Physical Design of IoT
IoT Protocols
• Application Layer
• AMQP
• Advanced Message Queuing Protocol (AMQP) is an open application layer
protocol for business messaging.
• AMQP supports both point-to-point and publish/subscriber models routing
and queuing.
• AMQP brokers receive messages from publishers (e.g. device or applications
that generate data) and route them over connections to consumers
(applications that process data).
• Publisher publish the messages to exchanges which then distribute message
copies to queues.
• Messages are either delivered by the broker to the consumers which have
subscribed to the queues or the consumers can pull the messages from the
queue.
Logical Design of IoT
• Logical design of an IoT system refers to an abstract
representation of the entities and processes without going into
the low-level specifics of the implementation.
Logical Design of IoT
IoT Functional Blocks

• An IoT system comprises of a number of functional blocks that

provide the system the capabilities for identification, sensing,
actuation, communication, and management.
Logical Design of IoT
IoT Functional Blocks

• Device: An IoT system comprises of devices that provide sensing,

actuation, monitoring and control functions.
• Communication: The communication block handles the
communication for the IoT system.
• Services: An IoT system uses various types of IoT services such
as services for device monitoring, device control services, data
publishing services and services for device discovery.
Logical Design of IoT
IoT Functional Blocks

• Management: Management functional block provides various

functions to govern the IoT system.
• Security: Security functional block secures the IoT system and
by providing functions such as authentication, authorization,
message and content integrity, and data security.
• Application: IoT applications provide an interface that the users
can use to control and monitor various aspects of the IoT system.
Applications also allow users to view the system status and view
or analyze the processed data.
Logical Design of IoT
IoT Communication Models
• Request-Response:
• Request-Response is a communication model in which the client sends
requests to the server and the server responds to the requests.
• When the server receives a request, it decides how to respond, fetches
the data, retrieves resource representations, prepares the response, and
then sends the response to the client.
• Request-Response model is a stateless communication model and each
request-response pair is independent of others.
Logical Design of IoT
IoT Communication Models
• Publish-Subscribe communication model
• Publish-Subscribe is a communication model that involves publishers,
brokers and consumers.
• Publishers are the source of data. Publishers send the data to the topics
which are managed by the broker.
• Publishers are not aware of the consumers.
• Consumers subscribe to the topics which are managed by the broker.
• When the broker receives data for a topic from the publisher, it sends
the data to all the subscribed consumers.
Logical Design of IoT
IoT Communication Models
• Push-Pull communication model
• Push-Pull is a communication model in which the data producers push the
data to queues and the consumers pull the data from the queues.
• Producers do not need to be aware of the consumers.
• Queues help in decoupling the messaging between the producers and
consumers.
• Queues also act as a buffer which helps in situations when there is a
mismatch between the rate at which the producers push data and the rate
at which the consumers pull data.
Logical Design of IoT
IoT Communication Models
• Exclusive Pair communication
model
• Exclusive Pair is a bidirectional, fully
duplex communication model that uses
a persistent connection between the
client and server.
• Once the connection is setup it remains
open until the client sends a request to
close the connection.
• Client and server can send messages to
each other after connection setup.
Logical Design of IoT
IoT Communication APIs
• API stands for Application Programming Interface.
• APIs are mechanisms that enable two software components to
communicate with each other using a set of definitions and protocols.
• For example, the weather bureau’s software system contains daily weather
data. The weather app on your phone “talks” to this system via APIs and shows
you daily weather updates on your phone.
• In the context of APIs, the word Application refers to any software with
a distinct function.
• Interface can be thought of as a contract of service between two
applications.
• This contract defines how the two communicate with each other using
requests and responses.
• Their API documentation contains information on how developers are
Logical Design of IoT
IoT Communication APIs
• REST-based Communication APIs
• Representational State Transfer (REST) is a set of architectural
principles by which you can design web services and web APIs that
focus on a system’s resources and how resource states are addressed
and transferred.
• REST APIs follow the request response communication model.
• The REST architectural constraints apply to the components,
connectors, and data elements, within a distributed hypermedia system.
Logical Design of IoT
IoT Communication APIs
• REST-based Communication APIs – Architectural Constraints
• Client-Server:
• The principle behind the client-server constraint is the separation of concerns.
• For example, clients should not be concerned with the storage of data which is a
concern of the server. Similarly, the server should not been concerned about the
user interface, which is a concern of the client.
• Separation allows client and server to be independently developed and updated.
• Stateless:
• Each request from client to server must contain all the information necessary to
understand the request, and cannot take advantage of any stored context on the
server.
• The session state is kept entirely on the client.
Logical Design of IoT
IoT Communication APIs
• REST-based Communication APIs
• Cache-able:
• Cache constraint requires that the data within a response to a request be implicitly
or explicitly labeled as cache-able or non-cache-able.
• If a response is cache-able, then a client cache is given the right to reuse that
response data for later, equivalent requests.
• Caching can partially or completely eliminate some interactions and improve
efficiency and scalability.
• Layered System:
• Layered system constraint, constrains the behavior of components such that each
component cannot see beyond the immediate layer with which they are
interacting.
• For example, a client cannot tell whether it is connected directly to the end server,
or to an intermediary along the way.
• System scalability can be improved by allowing intermediaries to respond to
requests instead of the end server, without the client having to do anything
Logical Design of IoT
IoT Communication APIs
• REST-based Communication APIs
• Uniform Interface:
• Uniform Interface constraint requires that the method of communication between a
client and a server must be uniform.
• Resources reidentified in the requests (by URIs in web based systems) and are
themselves separate from the representations of the resources that are returned to
the client.
• When a client bolds a representation of a resource it has all the information required
to update or delete the resource (provided the client has required permissions).
• Each message includes enough information to describe how to process the message.
• Code on demand:
• Servers can provide executable code or scripts for clients to execute in their context.
• This constraint is the only one that is optional.
 Logical Design of IoT
IoT Communication APIs
• WebSocket based
Communication APIs
• WebSocket APIs allow bi-directional,
full duplex communication between
clients and servers.
• WebSocket APIs follow the exclusive
pair communication model.
• Unlike request-response APIs such as
REST, the WebSocket APIs allow full
duplex communication and do not
require a new connection to be setup
for each message to be sent
Logical Design of IoT
IoT Communication APIs
• WebSocket based Communication APIs
• WebSocket communication begins with a connection setup request sent
by the client to the server.
• This request (called a WebSocket handshake) is sent over HTTP and the
server interprets it as an upgrade request.
• If the server supports WebSocket protocol, the server responds to the
WebSocket handshake response.
• After the connection is setup, the client and server can send
data/messages to each other in full-duplex mode.
• WebSocket APIs reduce the network traffic and latency as there is no
overhead for connection setup and termination requests for each
message.
• WebSocket is suitable for IoT applications that have low latency or high
throughput requirements.
IoT ARCHITECTURES
• The building blocks of IoT are sensory devices, remote service
invocation, communication networks, and context-aware
processing of events; these have been around for many years.
• However, what IoT tries to picture is a unified network of smart
objects and human beings responsible for operating them (if
needed), who are capable of universally and ubiquitously
communicating with each other.
IoT ARCHITECTURES
• When talking about a distributed environment, interconnectivity
among entities is a critical requirement, and IoT is a good example.
• A holistic system architecture for IoT needs to guarantee flawless
operation of its components (reliability is considered as the most
import design factor in IoT) and link the physical and virtual
realms together.
• To achieve this, careful consideration is needed in designing failure
recovery and scalability.
• Additionally, since mobility and dynamic change of location has
become an integral part of IoT systems with the widespread use of
smartphones, state-of-the-art architectures need to have a certain
level of adaptability to properly handle dynamic interactions
within the whole ecosystem.
 IoT ARCHITECTURES
• Fig. depicts an outline of our
extended version of a reference
architecture for IoT.
• Different service and
presentation layers are shown in
this architecture.
 IoT ARCHITECTURES
• Service layers include event
processing and analytics, resource
management and service discovery,
as well as message aggregation and
Enterprise Service Bus (ESB) services
built on top of communication and
physical layers.
• API management, which is essential
for defining and sharing system
services and web-based dashboards
(or equivalent smartphone
applications) for managing and
accessing these APIs, are also
included in the architecture.
IoT ARCHITECTURES
SOA-BASED ARCHITECTURE
• Service-oriented architecture (SOA) is a method of software development
that uses software components called services to create business
applications.
• Each service provides a business capability, and services can also
communicate with each other across platforms and languages.
• Developers use SOA to reuse services in different systems or combine
several independent services to perform complex tasks.
• For example, multiple business processes in an organization require the user
authentication functionality.
• Instead of rewriting the authentication code for all business processes, you can
create a single authentication service and reuse it for all applications.
• Similarly, almost all systems across a healthcare organization, such as patient
management systems and electronic health record (EHR) systems, need to register
patients.
• These systems can call a single, common service to perform the patient registration
task.
IoT ARCHITECTURES
SOA-BASED ARCHITECTURE - BENEFITS
Service-oriented architecture (SOA) has several benefits over the traditional
monolithic architectures in which all processes run as a single unit. Some major
benefits of SOA include the following:
• Faster time to market
• Developers reuse services across different business processes to save time and costs.
• They can assemble applications much faster with SOA than by writing code and performing
integrations from scratch.
• Efficient maintenance
• It’s easier to create, update, and debug small services than large code blocks in monolithic
applications.
• Modifying any service in SOA does not impact the overall functionality of the business
process.
• Greater adaptability
• SOA is more adaptable to advances in technology.
• You can modernize your applications efficiently and cost effectively.
• For example, healthcare organizations can use the functionality of older electronic health record systems
in newer cloud-based applications.
IoT ARCHITECTURES
SOA-BASED ARCHITECTURE – BASIC PRINCIPLES
There are no well-defined standard guidelines for implementing service-oriented
architecture (SOA).
However, some basic principles are common across all SOA implementations.
• Interoperability
• Each service in SOA includes description documents that specify the functionality of the
service and the related terms and conditions.
• Any client system can run a service, regardless of the underlying platform or programming
language.
• For instance, business processes can use services written in both C# and Python.
• Since there are no direct interactions, changes in one service do not affect other components using the
service.
• Loose coupling
• Services in SOA should be loosely coupled, having as little dependency as possible on external
resources such as data models or information systems.
• They should also be stateless without retaining any information from past sessions or
transactions.
• This way, if you modify a service, it won’t significantly impact the client applications and other
services using the service.
IoT ARCHITECTURES
SOA-BASED ARCHITECTURE – BASIC PRINCIPLES
• Abstraction
• Clients or service users in SOA need not know the service's code logic or
implementation details.
• To them, services should appear like a black box.
• Clients get the required information about what the service does and how
to use it through service contracts and other service description
documents.
• Granularity
• Services in SOA should have an appropriate size and scope, ideally
packing one discrete business function per service.
• Developers can then use multiple services to create a composite service
for performing complex operations.
IoT ARCHITECTURES
SOA-BASED ARCHITECTURE – LIMITATIONS
• Limited scalability
• System scalability is significantly impacted when services share many resources
and need to coordinate to perform their functionality.
• Increasing interdependencies
• Service-oriented architecture (SOA) systems can become more complex over time
and develop several interdependencies between services.
• They can be hard to modify or debug if several services are calling each other in a
loop.
• Shared resources, such as centralized databases, can also slow down the system.
• Single point of failure
• For SOA implementations with an ESB, the ESB creates a single point of failure.
• It is a centralized service, which goes against the idea of decentralization that SOA
advocates.
• Clients and services cannot communicate with each other at all if the ESB goes
down.
IoT ARCHITECTURES
SOA-BASED ARCHITECTURE
• SOA ensures the interoperability among the heterogeneous
devices.
• To clarify this, let us consider a generic SOA consisting of four
layers, with distinguished functionalities as follows:
• Sensing layer is integrated with available hardware objects to sense the
status of things
• Network layer is the infrastructure to support over wireless or wired
connections among things
• Service layer is to create and manage services required by users or
applications
• Interfaces layer consists of the interaction methods with users or
applications
IoT ARCHITECTURES
SOA-BASED ARCHITECTURE
• Generally, in such architecture a complex system is divided into
subsystems that are loosely coupled and can be reused later
(modular decomposability feature), hence providing an easy way
to maintain the whole system by taking care of its individual
components.
• This can ensure that in the case of a component failure the rest of
the system (components) can still operate normally.
• This is of immense value for effective design of an IoT application
architecture, where reliability is the most significant parameter.
IoT ARCHITECTURES
SOA-BASED ARCHITECTURE
• SOA has been intensively used in WSN, due to its appropriate level of
abstraction and advantages pertaining to its modular design.
• Bringing these benefits to IoT, SOA has the potential to augment the
level of interoperability and scalability among the objects in IoT.
• Moreover, from the user’s perspective, all services are abstracted
into common sets, removing extra complexity for the user to deal
with different layers and protocols.
• Additionally, the ability to build diverse and complex services by
composing different functions of the system (i.e., modular
composability) through service composition suits the heterogeneous
nature of IoT, where accomplishing each task requires a series of
service calls on all different entities spread across multiple locations.
IoT ARCHITECTURES
API-ORIENTED ARCHITECTURE
• Conventional approaches for developing service-oriented solutions use
SOAP and Remote Method Invocation (RMI) as a means for describing,
discovering, and calling services; however, due to overhead and
complexity imposed by these techniques, Web APIs and Representational
State Transfer (REST) - based methods were introduced as promising
alternative solutions.
• The required resources range from network bandwidth to computational
and storage capacity, and are triggered by request–response data
conversions happening regularly during service calls.
• Lightweight data-exchange formats like JSON can reduce the
aforementioned overhead, especially for smart devices and sensors with a
limited amount of resources, by replacing large XML files used to describe
services.
• This helps in using the communication channel and processing the power
of devices more efficiently.
IoT ARCHITECTURES
API-ORIENTED ARCHITECTURE
• Likewise, building APIs for IoT applications helps the service
provider attract more customers while focusing on the
functionality of their products rather than on presentation.
• In addition, it is easier to enable multitenancy by the security
features of modern Web APIs such as OAuth, APIs which indeed
are capable of boosting an organization’s service exposition and
commercialization.
• It also provides more efficient service monitoring and pricing
tools than previous service-oriented approaches
IoT ARCHITECTURES
API-ORIENTED ARCHITECTURE
• To this end, previous research proposed Simurgh, which describes
devices, sensors, humans, and their available services using web API
notation and API definition languages.
• Furthermore, a two-phase discovery approach was proposed in the
framework to find sensors that provide
• desirable services and match certain features, like being in a specific
location.
• Similarly, Elmangoush et al. proposed a service-broker layer (named
FOKUS) that exposes a set of APIs for enabling shared access to the
OpenMTC core.
• Novel approaches for defining and sharing services in distributed and
multiagent environments like IoT can reduce the sophistication of
service discovery in the application development cycle and diminish
service-call overhead in runtime.