IOT Architecture ii

H.M.H.T.Hikkaduwa
Complex systems.

 Complex systems are become dynamic systems rather than static systems.
ea. Financial market systems, social network.
 Complex systems are constantly change and change is the norm.
 It is no longer static structural properties and space define the systems.
 Also increase the system relation in time that define how system function.
Event driven architecture.

 Event driven architecture is a design pattern built around the production, detection and
reaction to event that takes time.
 IS a methodology use for designing and implementing applications where events transmit
among decouples software services and components.
 Critical piece of a hybrid integration platform.
What is event?

 Event is a significant change in the “state”.

 Event is a notable thing that happens inside or outside of business or system.
 Event signifies a problem or impending problem, opportunity or deviation.
 According to the specification and occurrence term event used interchangeably to refer to
both the specification (definition of the event) and each individual occurrence of the event.
 According to the business terms event to be meaningful to down stream subscribers.
What is an event?

 Event consist with two parts.

1.Event header.
Header contains the elements describe by the occurrence. Such as event specification ID, event type, event name,
event time stamp.
2. Event body.
Event body contain the information to communicate which product fell below the available threshold.
Event body must be fully described. So any interested party used the information without having go back to the
source system.
Event driven architecture.

 Event driven architecture consist of

1. Event creators.
2. Event managers.
3. Event consumer.
 Event creator.
Event creator is the source of the event. Source might be a sensor, transmitter, collaboration
tool, service or data store. Event creator only knows that the event has occurred. Broad cast the
signals that indicate the event.
Event driven architecture.

 Event manager.
Event manager function as a intermediary managing events. Manager receive a
notification from a event and if need apply rule to process the event. Events are pass to down
stream event consumers.
 Event consumer are entity that need to know occurrence of the event. Subscribe for the
type of event manager.
Event processing styles.

 Basically three general style of event processing's are there.

1. Simple event processing.
2. Stream event processing.
3. Complex event processing.

 Simple event processing.

Events that are related to the specific, measurable changes of condition. The arrival of the event
immediately triggers and action within the consumer. These actions are typically either stateless an
perform all of there logic base on the event contents only or state full and can retain information
across invocations in order to perform slightly more logics. Commonly use to drive the real time
workflow. There by reducing the lag time and cost.
Event processing styles.

 Event stream processing.

Used for both ordinary and notable events happen. Commonly used to drive the real time flow
of information in and around the enterprise which enables in time decision making.
 Complex event processing.
Consumer process series of events and perform much more sophisticated pattern analysis for
the purpose of identifying meaning full patterns or relationship detects event correlation,
causality or timing.
ea. Fraud detection, cyber security.
Why we need event driven SOA?

 SOA has few draw backs according to the its work.

1. SOA based communication may limit enterprise ability to be effectively adaptive and
effective.
2. SOA architecture insufficient in real time response.
3. SOA architecture insufficient in parallel process of service execution.
IOT system unique characteristic from the
traditional information system service.
 Perceptibility of the environment.
Perceived service system interact with the environment to support dynamic adaptive
computing based on scenarios. Sense device service system perceives the environment
surrounding temperature, humidity, light. Sensory data constantly transfer to the service
system and it handles real time to support intelligent calculations based on situation.
 The service execution driven by events.
Business event define by users. The sensing service systems analyze and collect real time
data. Get the business event and do real time processing and response to event. Traditional
information service generally uses the request and response model.
IOT system unique characteristic from the
traditional information system service.
 Service has the characteristics of collaborative work.
Expansion of sensing service and application scope service may need to work with
multiple application forms. Perceive service system commands many components actively.
 Sensing service has long life time.
Configuring operations perceive system running in the longer period, instead of the traditional
service execution by system calls.
 The sensing is predictive and proactive.
The sensing service system predicts business events and actives service in advance according
to the sensory data and context scenarios.
Event driven SOA.

 Form of Service oriented architecture and combining the intelligence and the pro
activeness of the architecture with organization capabilities found in service offerings.
 Also a methodology use for design and implementing applications where events transmit
among decoupled software components and the services.
 Software architecture pattern promoting the production, detection, consumption of an
reaction to events.
 EDA is an event driven process execution component model. Event can be transmitted
through components and services.
 The generation of an event can trigger one or more services to be invoked.
Event driven SOA.

 Not like sequential procedural systems, event driven SOA allow to run systems and
component to respond dynamically in real time as event occurs.
 Long running processing capabilities enable architecture to collect various asynchronous
events over a long period of time and correlate these events in to the casual relationship.
 Event driven programming is structured around the concept of decoupled relationships
between event producers and event handlers.
 Event consumer doesn’t care why event occur and it concerned that it will be invoked
when the event has occurred.
 Different characteristics of event driven SOA.

Characteristics SOA EDA

Coupling degree. Loosely coupled interaction Decoupled interaction

Communication mode. One to one communication Many to many

communication

Response mode. Synchronous Asynchronous

Fog computing architecture.

 Fog computing is the concept of network fabric that stretches form the outer edges where
data is created to where it will eventually stored.
 Fog is a another layer in the distributed environment and is closely associate with cloud
environment and the internet of things.
 Fog computing or fogging is an architecture that use edge devices to carry out a substantial
amount of computation, storage, communicate locally and routed over the internet
backbone.
Fog computing architecture.

 Goal of fog computing is to bring basic analytics services to the network edge, improving
performance by positioning computing resources closer to the where they are needed.
 This is used to reduce the distance that data needed to be transport on the network and
improve the overall network performance and the efficiency.
 Fog computing implies distribution of communication, computation and storage resources
and services on or close to devises and systems in the control of end users.
Real world applications use in fog computing.

 Fog computing is used for the smart electrical grids. Electrical grids are dynamical and
responsible for increased electrical consumption and lowering production when it is no
need to be economical. In order to run efficiently, a smart grid relies heavily on real time
data of electrical consumption and production.
 The data is not from an isolation sensor. But rather from a group of sensors.
Advantages of the Fog computing.

 Reducing cloud workload.

Using the IOT field gateway part of the work is done in the fog. At the edge of the our complex
solution reduce the cloud work load.
Data centers and the clouds are really powerful high end devices. But recourses are not unlimited.
Many more multiple devises when connected to the cloud it is not easy to control the cloud. So that
reducing the number is a good solution to the cloud.
 Real time reaction.
IOT solutions need a near real time reaction time. Connected to the cloud introduces latency. To
control a devise, the data is sending to the cloud through the “big net” the server process it an replies
with a command to start an action on device itself. There is not a negligible round trip related to the
connection and to the server work load too.
Advantages of the Fog computing.

 Offline Handling.
Without an internet connection, an IOT solution which is entirely based on an online
platform cannot work. With the fog computing, we have a local node and we have to deal with
local network connection only. And also scenarios like cloud platform is available but the
connection isn’t reliable or the bandwidth also low.
 Security and Privacy.
Protecting the data is a must situation. Even if all cloud connections are encrypted and
based on SSL/TSSL protocols Also IOT solution prefer to have data on their private server to
protect themselves and their customers. Using field gateway we can filter data to avoid
sending all of them to the cloud. We can hold sensible data in our network and send the no
sensible ones to the public servers.
Advantages of the Fog computing.

 Reducing price.
IOT cloud platforms are not free. They have a cost which is related to a number of
connected devises and the number of messages exchanged per hour or a day. Using the
preprocessing we can reduce and filter the amount of data to send.
Applications of Fog computing.

 In industrial environment all devises use protocol like OPC-UA and need near real time
reaction time. (Robots in a production line)

 Smart home is a another example made of ZIgBee, Z wave devises and connected to the
internet through a central router.
IOT and API.

 API work as a data pipes to send the data off to the cloud and retrieve the metrics and
suggestion back
 Assume that sensors collecting the information. And those devises connected to your
mobile phone via Bluetooth and mobile phone connected to the internet and send data to
the provider.
 The connection between these app to the provider usually done via APIs.
 IOT and API.
 Devises asked to provide wireless access to get internet.
 Devises directly communicate with the provider and send data to the providers back end
which is often running in the cloud.
 Sensors do this using API calls based on REST, Web sockets or even proprietary protocols.
 Protocols like MQTT become more and more popular to connect power and constrained
devices to the back end.
Why we use API based architectures.

 The big split between the back end and front end.
This is also called as split stack development. API driven architecture allow to decouple the back
end and front end of the application. Instead having the dependency each end communicate via
API. This is extremely beneficial like each end can be build in completely different tools.
 Sensibility and scalability.
API is the key or foundation of the application. It enable the organization to scale the app by
simply plugin in services as and when needed.
 Parallel development and agility.
Different teams and the persons work with the back end and front end applications there is
no need to teams to work together. Only they have to concern and agree with the API structure.
Why we use API based architectures.

 Hiding underline complexity.

All the components that are connected to the API are modular. Exit on there own and
communication via the API. Modular nature of application make is easier to test and maintain.
Also we are dealing with the some other third party API, do not need to learn or decipher the
entire working code. Just plugging the API and use it.
 Business logic come first.
Rather than having worrying about the structure focus on the business logic. The initial
API structure needed to be planed out and after that developed the individual APIs by
developers. This would be course to reduces the development time.
Why we use API based architectures.

 APIs and Devops are collaborate and working together.

API follow more streamline deployment pipeline. While also eliminating the production of
duplicates assets by development teams. The merge of Devops and API driven architecture
increasing the efficiency and reducing the cost by a greater deal. Deployment can reach
production a lot fast through these slick pipelines.
API architecture make great way to build IOT applications. API base architectures enhance the
scalability and easily connected to the main application.
References.

 https://www.techradar.com/news/what-is-fog-computing
 https://apifriends.com/api-management/iot-api/
 https://dzone.com/articles/the-hybrid-internet-of-things-1
Thank You.