IoT Physical Servers

and Cloud Offerings

UNIT 5
 Introduction to Cloud Storage models
and communication APIs
•Cloud storage models and communication APIs are related to how data is stored and accessed in the
cloud.

•Cloud storage is a service that allows users to store and retrieve data from remote servers over the
internet.

•Communication APIs are interfaces that enable web applications to interact with cloud storage
services.

•There are different types of cloud storage models and communication APIs, depending on the needs
and preferences of the users and developers.
common cloud storage models
•Object storage:
• This model stores data as discrete units called objects, which have a unique identifier, metadata, and data
payload.

• Object storage is suitable for storing unstructured or semi-structured data, such as images, videos,
documents, etc.

• Object storage services often provide RESTful APIs that use HTTP methods to perform operations on
objects.

• Some examples of object storage services are Amazon S3, Google Cloud Storage, and Microsoft Azure
Blob Storage.
•Block storage:
• This model stores data as fixed-sized blocks, which are assigned a unique address.

• Block storage is suitable for storing structured or transactional data, such as databases, files, etc.

• Block storage services often provide low-level APIs that use SCSI commands to perform operations on
blocks.

• Some examples of block storage services are Amazon EBS, Google Cloud Persistent Disk, and Microsoft
Azure Disk Storage.
•File storage:
• This model stores data as files and folders, which are organized in a hierarchical structure.

• File storage is suitable for storing data that needs to be accessed by multiple users or applications, such as
shared documents, media, etc.

• File storage services often provide high-level APIs that use protocols such as NFS, SMB, or FTP to
perform operations on files and folders.

• Some examples of file storage services are Amazon EFS, Google Cloud File store, and Microsoft Azure
Files.
common communication APIs
•WAMP:
• Web Application Messaging Protocol is a subprotocol of WebSocket that provides publish-subscribe and
remote procedure call messaging patterns.

• WAMP enables distributed application architectures that can communicate in real-time. WAMP has four roles:
publisher, subscriber, caller, and callee.

• WAMP also has two components: router and client. The router is responsible for routing messages between
publishers and subscribers, and between callers and callees.

• The client is the application code that runs on the peers and performs one or more roles. WAMP can be
implemented using AutoBahn, which is a framework for creating WAMP applications in Python, JavaScript,
and other languages.
•Xively:
• Xively is a cloud platform for the Internet of Things (IoT), which provides a communication API for
connecting devices, applications, and users.

• Xively uses MQTT, which is a lightweight publish-subscribe protocol for IoT.

• Xively also provides data storage, analytics, security, and management features for IoT applications.
•Django:
• Django is a Python web application framework that follows the model-view-template (MVT) pattern.

• Django provides a communication API for creating RESTful web services, which use HTTP methods to
perform operations on resources.

• Django also provides features such as authentication, authorization, caching, database access, templating,
etc. for web development.
•Amazon Web Services (AWS):
• AWS is a cloud computing platform that provides a variety of services for storage, computing,
networking, analytics, etc.

• AWS provides a communication API for each service, which can be accessed using SDKs, CLI, or web
console.

• AWS also provides services for IoT, such as AWS IoT Core, AWS IoT Device Management, AWS IoT
Analytics, etc
•SkyNet:
• SkyNet is an open source IoT messaging platform that provides a communication API for connecting
devices, applications, and users.

• SkyNet uses WebSocket and RESTful protocols for real-time and asynchronous communication.

• SkyNet also provides features such as device discovery, authentication, encryption, etc. for IoT
applications.
Web server for IoT
•WAMP for IoT
• Web Application Messaging Protocol (WAMP) is a sub-protocol of Websocket which provides publish-
subscribe and remote procedure call (RPC) messaging patterns.
WAMP – Key Concepts
•Transport:
• Transport is channel that connects two peers. The default transport for WAMP is Websocket. WAMP can run
over other transports as well which supports message-based reliable bi-directional communication.

•Session:
• Session is a conversation between two peers that runs over a transport.

•Client:
• Clients are peers that can have one or more roles. In publish-subscribe model client can have following roles:
• Publisher: Publisher publishes events (including payload) to the topic maintained by the Broker.
• Subscriber: Subscriber subscribes to the topics and receives the events including the payload.
 • In RPC model client can have following roles:

• Caller: Caller issues calls to the remote procedures along with call arguments.

• Callee: Callee executes the procedures to which the calls are issued by the caller and returns the results
back to the caller.

•Router: Routers are peers that perform generic call and event routing.
• In publish-subscribe model Router has the role of a Broker:

• Broker: Broker acts as a router and routes messages published to a topic to all subscribers subscribed to
the topic.
 • In RPC model Router has the role of a Dealer:

• Dealer: Dealer acts a router and routes RPC calls from the Caller to the Callee and routes results from
Callee to Caller.

•Application Code: Application code runs on the Clients (Publisher, Subscriber, Callee or Caller).
Peer to Peer Communication
WAMP Implementation
•Here we use the AutoBahn framework which provides open-source implementations of the WebSocket
and WAMP protocols.

•Communication between various components of a typical WAMP-AutoBahn deployment:

• The Client (in Publisher role) runs a WAMP application component that publishes messages to the Router.

• The Router (in Broker role) runs on the Server and routes the messages to the Subscribers.

• The Router (in Broker role) decouples the Publisher from the Subscribers.

• The communication between Publisher - Broker and Broker - Subscribers happens over a WAMP-WebSocket
session.
commands for installing AutoBahn-
Python
•Create a WAMP publisher component. The publisher component publishes a message containing
the current time-stamp to a topic named 'test-topic’.

•Create a WAMP subscriber component. The subscriber component that subscribes to the "test-
topic’.
WAMP Publisher Component
WAMP Subscriber Component
•Run the application router on a WebSocket transport server as follows:
Xively Cloud for loT
•Xively is a commercial Platform-as-a-Service that can be used for creating solutions for Internet
of Things.

•With Xively cloud, IoT developers can focus on the front-end infrastructure and devices for IoT
(that generate the data), while the backend data collection infrastructure is managed by Xively.

•Xively platform comprises of a message bus for real-time message management and routing, data
services for time series archiving, directory services that provides a search-able directory of
objects and business services for device provisioning and management.
•Xively provides an extensive support for various languages and platforms, The Xively libraries
leverage standards-based API over HTTP, Sockets and MQTT for connecting IoT devices to the Xively
cloud.

•To start using Xively, you have to register for a developer account. You can then create development
devices on Xively. When you create a device, Xively automatically creates a Feed-ID and an API Key
to connect to the device. Each device has a unique Feed-ID.

•Feed-ID is a collection of channels or data streams defined for a device and the associated meta-data.
API keys are used to provide different levels of permissions. The default API key has read, update,
create and delete permissions.
•Xively devices have one or more channels. Each channel enables bi-directional communication
between the IoT devices and the Xively cloud. IoT devices can send data to a channel using the
Xively APIs. For each channel, you can create one or more triggers.

•A trigger specification includes a channel to which the trigger corresponds, trigger condition (e.g.
channel value less than or greater than a certain value) and an HTTP POST URL to which the
request is sent when the trigger fires.

•Triggers are used for integration with third-party applications.

Creating a new device
Connecting to device
•Example of using Xively cloud for an IoT system that monitors temperature and sends the
measurements to a Xively channel.
• The temperature monitoring device can be built with the Raspberry Pi board and a temperature sensor
connected to the board.

• The Raspberry Pi runs a controller program that reads the sensor values every few seconds and sends the
measurements to a Xively channel.

• This example uses the Xively Python library. To keep the program simple and without going into the
details of the temperature sensor we use synthetic data (generated randomly in readTempSensor()
function).
• In this controller program, a feed object is created by providing the API key and Feed-ID. Then a channel
named temperature is created (if not existing) or retrieved.

• The temperature data is sent to this channel in the runController() function every 10 seconds.

• In this example we created a single Xively device with one channel.

• In real-world scenario each Xively device can have multiple channels and you can have multiple devices
in a production batch.
 Python Web Application Framework -
Django
•We have learned about the Xively Cloud for collecting and processing data from IoT systems in
the cloud. Also learned how to use the Xively Python library.

•To build IoT applications that are a backed by Xively cloud or any other data collection systems,
we would require some type of web application framework.

•Here you will learn about a Python-based web application framework called Django.
Django
•Django is an open source web application framework for developing web applications in Python.

•A web application framework in general is a collection of solutions, packages and best practices
that allows development of web applications and dynamic websites.

•Django is based on the Model-Template-View architecture and provides a separation of the data
model from the business rules and the user interface.

•Django provides a unified API to a database backend.

•Thus web applications built with Django can work with different databases without requiring any
code changes.

•With this flexibility in web application design combined with the powerful capabilities of the
Python language and the Python ecosystem, Django is best suited for cloud applications.

•Django consists of an object-relational mapper, a web templating system and a regular-expression

based URL dispatcher.
Django Architecture
•Django is Model-Template-View (MTV) framework.

•Model
• The model acts as a definition of some stored data and handles the interactions with the database.

• In a web application, the data can be stored in a relational database, non-relational database, an XML file,
etc.

• A Django model is a Python class that outlines the variables and methods for a particular type of data.
•Template
• In a typical Django web application, the template is simply an HTML page with a few extra placeholders.

• Django’s template language can be used to create various forms of text files (XML, email, CSS, Java script,
CSV, etc.)

•View
• The view ties the model to the template. The view is where you write the code that actually generates the web
pages.

• View determines what data is to be displayed, retrieves the data from the database and passes the data to the
template.
Creating a Django Project and App
•When we create a new django project a number of files are created:
• __init__.py : This file tells Python that this folder is a Python package.

• manage.py: This file contains an array of functions for managing the site.

• settings.py: This file contains the website's settings

• urls.py: This file contains the URL patterns that map URLS to pages.

•A Django project can have multiple applications ("apps"). Apps are where you write the code that
makes your website function. Each project can have multiple apps and each app can be part of
multiple projects.
•When a new application is created a new directory for the application is also created which has a
number of files including:
• model.py: This file contains the description of the models for the application.

• views.py: This file contains the application views.

•Django comes with a built-in, lightweight Web server that can be used for development purposes.
When the Django development server is started the default project can be viewed at the URL:
http://localhost:8000.
Configuring a Database
•Most web applications have a database backend. Developers have a wide choice of databases that
can be used for web applications including both relational and non-relational databases.

•Django provides a unified API for database backends thus giving the freedom to choose the
database.

•Django supports various relational database engines including MySQL, PostgreSQL, Oracle and
SQLite3.

•Support for non-relational databases such as MongoDB can be added by installing additional
engines (e.g. Django-MongoDB engine for MongoDB).
•Example of setting up a relational and a non-relational database with a Django project.

•The first step in setting up a database is to install and configure a database server.

•After installing the database, the next step is to specify the database settings in the setting.py file
in the Django project.
commands to setup MySQL
database setting to use MySQL with a
Django project
commands to setup MongoDB and the
associated Django-MongoDB engine
database setting to use MongoDB within
a Django project
Defining a Model
•A Model acts as a definition of the data in the database. Here we will explain Django with the
help of a weather station application that displays the temperature data collected by an IoT device.

•The TemperatureData table in the database is defined as a Class in the Django model.

•Each class that represents a database table is a subclass of django.db.models.Model which

contains all the functionality that allows the models to interact with the database.

•The TemperatureData class has fields timestamp, temperature, lat and lon all of which are
CharField.
•To sync the models with the database simply run the following command:

•>python manage.py syncdb

•When the syncdb command is run for the first time, it creates all the tables defined in the Django
model in the configured database.
Django Admin Site
•Django provides an administration system that allows you to manage the website without writing
additional code. This "admin" system reads the Django model and provides an interface that can
be used to add content to the site.

•The Django admin site is enabled by adding django.contrib.admin and

django.contrib.admindocs to the INSTALLED_APPS section in the settings.py file.

•The admin site also requires URL pattern definitions in the urls.py file.

•To define which of your application models should be editable in the admin interface, a new file
named admin.py is created in the application folder.
Defining a View
•The View contains the logic that glues the model to the template. The view determines the data to
be displayed in the template, retrieves the data from the database and passes it to the template.

•Conversely, the view also extracts the data posted in a form in the template and inserts it in the
database.

•Typically, each page in the website has a separate view, which is basically a Python function in
the views.py file.

•Views can also perform additional tasks such as authentication, sending emails, etc.
•Example of a Django view for the Weather Station app.

•This view corresponds to the webpage that displays latest entry in the TemperatureData table. In
this view the Django’s built in object-relational mapping API is used to retrieve the data from the
TemperatureData table.

•The object-relational mapping API allows the developers to write generic code for interacting
with the database without worrying about the underlying database engine. So the same code for
database interactions works with different database backends.
•You can optionally choose to use a Python library specific to the database backend used (e.g.
MySQLdb for MYSQL, PyMongo for MongoDB, etc.) to write database backed specific code.

•In the view shown in Box 8.12, the TemperatureData.objects.order_by('—id') [0] query returns
the latest entry in the table. To retrieve all entries, you can use table.objects.all().

•To retrieve specific entries, you can use table.objects.filter(s » kwargs) to filter out queries that
match the specified condition.
•To render the retrieved entries in the template, the render_to_response function is used. This
function renders a given template with a given context dictionary and returns an HttpResponse
object with that rendered text.
Defining a Template
•A Django template is typically an HTML file (though it can be any sort of text file such as XML,
email, CSS, Javascript, CSV, etc.). Django templates allow separation of the presentation of data
from the actual data by using placeholders and associated logic (using template tags).

•A template receives a context from the view and presents the data in context variables in the
placeholders. In the previous section you learned how the data is retrieved from the database in
the view and passed to the template in the form of a context dictionary.

•In the example, the variables containing the retrieved temperature, latitude and longitude are
passed to the template.
Defining the URL Patterns
•URL Patterns are a way of mapping the URLS to the views that should handle the URL requests.

•The URLS requested by the user are matched with the URL patterns and the view corresponding
to the pattern that matches the URL is used to handle the request.

•Box 8.15 shows an example of the URL patterns for the Weather Station project. As seen in this
example, the URL patterns are constructed using regular expressions.

•The simplest regular expression (r’ ^ $') corresponds to the root of the website or the home page.
Designing a RESTful Web API
•To design a RESTful Web API, we need install Django REST framework.
•The REST API described here allows you to create, view, update and delete a collection of
resources where each resource represents a sensor data reading from a weather monitoring
station.

•Box 8.17 shows the Django model for such a station. The station model contains four fields -
station name, timestamp, temperature, latitude and longitude.

•Box 8.18 shows the Django views for the REST API. ViewSets are used for the views that allow
you to combine the logic for a set of related views in a single class.
•Box 8.19 shows the serializers for the REST API. Serializers allow complex data (such as
querysets and model instances) to be converted to native Python datatypes that can then be easily
rendered into JSON, XML or other content types.

•Serializers also provide de-serialization, allowing parsed data to be converted back into complex
types, after first validating the incoming data.

•Box 8.20 shows the URL patterns for the REST APL Since ViewSets are used instead of views,
we can automatically generate the URL conf for our API, by simply registering the viewsets with
a router class.
•Routers automatically determining how the URLs for an application should be mapped to the
logic that deals with handling incoming requests.

•Box 8.21 shows the settings for the REST API Django project.