You are on page 1of 20

Introduction to Cloud Storage Models & Communication APIs:

• Cloud computing is a transformative computing paradigm that


involves delivering applications and services over the internet.
• Cloud computing is a model for enabling ubiquitous, convenient, on
demand network access to a shared pool of configurable computing
resources, that can be rapidly provisioned and released with minimal
management effort or service provider interaction.
• WAMP, Xively’s PaaS which provides tools and services for developing
IoT solutions.
• And About AWS and their applications for IoT.
WAMP-AutoBahn for IoT:
• WAMP : Web Application Messaging Protocol
• Mainly used in cloud storage model for IoT & other messaging
services •
• WAMP is a routed protocol, with all components connecting to a
WAMP Router, where the WAMP Router performs message routing
between the component
• It is protocol for Web Socket (PUBSUB based protocol) : uses RPC
Messaging Pattern •
• Some Important Key Terminologies
• Transport
• Session
• Clients (Publisher & Subscriber)
• Router
• Broker •
• Dealer •
• Application Code
Web Application Messaging Protocol (WAMP) is a sub-protocol of WebSocket which provides publish–
subscribe and remote procedure call (RPC) messaging patterns.
• Transport: Transport is a channel that connects two peers.
• 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 the publish–subscribe model, the Client can have the 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 the RPC model, the Client can have the 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 to the Caller.
• Router: Routers are peers that perform generic call and event routing.
• In the publish–subscribe model, the Router has the role of a Broker.
– Broker: Broker acts as a Router and routes messages published to a topic to all
the subscribers subscribed to the topic.
• In the RPC model, the 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 the Callee to the Caller.
• Application code: Application code runs on the Clients (Publisher, Subscriber, Callee or
Caller).
Example of a WAMP Publisher implemented using AutoBahn framework –
publisherApp.py
from twisted.internet import reactor
from autobahn.twisted.util import sleep
from autobahn.twisted.wamp import ApplicationSession
import time, datetime
def getData():
#Generate message
timestamp = datetime.fromtimestamp(time.time()).strftime(‘%Y-%m-%d%H:%M%S’)
data = “Messageat time-stamp: “ + str(timestamp)
return data
#An Application component that publishes an event every second
Class Component(ApplicationSession):
@inlineCallbacks
def on Join(self, details):
while True:
data= getData()
self.publish(‘test-topic’, data)
yield sleep(1)
Example of a WAMP Subscriber implemented using
AutoBahn frame work-subscriberApp.py

from twisted.internet import reactor


from twisted.internet.defer import inlineCallbacks
from autobahn.twisted.wamp import ApplicationSession

#An Application component that subscribes and receives events


Class Component(ApplicationSession):
@inlineCallbacks
def onJoin(self, details):
  self.received=0
def on_event(data):
print “Received message: “ + data
yield self.subscribe(on_event, ‘test-topic)
def onDisconnect(self):
reactor.stop()
Xively Cloud for IoT:
• Xively is a commercial PaaS that can be used for creating solutions for
IoT.
• 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.
• It provides an extensive support for various languages and platforms.
• The Xively libraries are:
• Standards-base API over HTTP
• Sockets
• MQTT
• To use Xively, first we need to register for a developer account.
Then create development devices on Xively.
• The below figure shows how to create a new device from the Xively
dashboard.
• When you create a device, Xively automatically creates a Feed-ID and
an API key to connect to the device as shown below:
• Each device a has a unique Feed-ID. Feed-ID is a collection of channels or
datastreams 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, we can create one or more triggers. A trigger
specification includes a channel to which the trigger corresponds, trigger
condition and an HTTP POST URL to which the request is sent when the
trigger fires.
• Triggers are used for integration with third party applications.
#!/usr/bin/env python
import xively
import time
import datetime
import requests
FEED_ID = "YOURFEEDID"
API_KEY = "YOURAPIKEY"
# initialize api client
api = xively.XivelyAPIClient(API_KEY)
# function to read the temperature from ds18b20 temperature sensor on i2cdef read_temperature():
tempfile = open("/sys/bus/w1/devices/YOURTEMPERATURESENSORID/w1_slave")
thetext = tempfile.read()
tempfile.close()
tempdata = thetext.split("\n")[1].split(" ")[9]
temperature = float(tempdata[2:])
temperature = temperature / 1000
return temperature
# function to return a datastream object. This either creates a new
datastream,
# or returns an existing one
def get_datastream(feed):
try:
datastream = feed.datastreams.get("TemperatureSensor")
return datastream
except:
datastream = feed.datastreams.create("TemperatureSensor",
tags="temperature")
return datastream
# main program entry point - runs continuously updating our datastream with the
# latest temperature reading
def run():
feed = api.feeds.get(FEED_ID)
datastream = get_datastream(feed)
datastream.max_value = None
datastream.min_value = None
while True:
degreesCelcius = read_temperature()
datastream.current_value = degreesCelcius
datastream.at = datetime.datetime.utcnow()
try:
datastream.update()
except requests.HTTPError as e:
print "HTTPError({0}): {1}".format(e.errno, e.strerror)
time.sleep(10)
run()

You might also like