M.

Sc – INTERNET OF THINGS
SEMESTER-I

INTRODUCTION TO INTERNET OF
THINGS

MSC-IOT-103
All rights reserved. No Part of this book may be reproduced or transmitted, in any form or by
any means, without permission in writing from Mizoram University. Any person who does
any unauthorized act in relation to this book may be liable to criminal prosecution and civil
claims for damages. This book is meant for educational and learning purposes. The authors of
the book has/have taken all reasonable care to ensure that the contents of the book do not
violate any existing copyright or other intellectual property rights of any person in any
manner whatsoever. In the event the Authors has/ have been unable to track any source and if
any copyright has been inadvertently infringed, please notify the publisher in writing for
corrective action.

© Team Lease Edtech Pvt. Ltd.

All rights reserved. No Part of this book may be reproduced in any form without permission
in writing from Team Lease Edtech Pvt. Ltd.
Unit 4 – Web of Things 120
UNIT 4 – WEB OF THINGS

Structure
4.1 Learning Objectives
4.2 Introduction
4.3 Web of Things versus Internet of Things
4.4 Two Pillars of the Web
4.5 Architecture Standardization for WoT
4.5.1 WoT Architecture
4.5.2 Platform Middleware
4.5.3 Standards for M2M
4.5.4 Frameworks for WSN
4.5.5 Standards for SCADA
4.5.6 Extensions on RFID Standards
4.6 Unified Multitier WOT Architecture
4.6.1 SOA/EAI versus SODA/MAI
4.6.2 OSGi: The Universal Middleware
4.7 WoT Portals and Business Intelligence
4.8 Summary
4.9 Self-assessment questions
4.10 Suggested readings

4.1 OBJECTIVES

After studying this unit students will be able to:

 Analyze the Difference between the web of things and the internet of things
 Evaluate two pillars of the web
 Outline Architecture Standardization for WoT
 Describe Platform Middleware for WoT
 Analyze Unified Multitier WoT Architecture
 Outline WoT Portals and Business Intelligence(BI)
4.2 INTRODUCTION

The Internet is the name that has been used to identify the enormous interconnection of
computer networks around the world. It refers to the physical connection of the paths
between computers (two or more). The World Wide Web is the typical name using
HTTP(Hypertext Transfer Protocol) for accessing the Internet, thus
www.anything.something. It is just one of the connection protocols hence it is available on
the Internet, and not the only one. Simply, the Internet is a large container, and the web is a
part of that container. For instance, consider restaurant is an Internet, and the web is the most
popular dish on the menu. Nevertheless, the web is the dish that makes the Internet popular,
useful to everyone, and powerful.

4.3 WEB OF THINGS VERSUS INTERNET OF THINGS

Web

The World Wide Web, shortened as WWW or the Web, is a system of interlinked documents
accessed through the Internet. The Web was established around the 1990s by Tim Berners-
Lee. The Web, such as Email, is one of the services that run on the Internet. World Wide
Web, which is also known as a Web, is a group of websites or web pages stored in web
servers and connected to local computers using the internet. These websites hold text pages,
digital images, audio, videos, etc. Users may be able to access the content of specific pages
via the internet from anywhere in the world using devices such as computers, notebooks, and
mobile phones. The WWW, as well as the internet, providing the display and retrieval of text
and media to your device.

Things

"Thing" is an abstraction of a virtual or physical entity that allows interactions to and

participates in the Web of Things. Things are simply an object or an entity, an idea, quality
perceived, thought to have its existence. Everyday Things/Objects are used in human's life in
terms of Inner Things such as mind, directly insensible things, or physical things, such as
digital things, real/virtual things.

Enter the web of things

The shortcomings of the Internet of Things became apparent as soon as it became necessary
to incorporate products from different vendors into a single program or system. Let's use the
life of the owner of a well-known hotel chain in many cities around the world to demonstrate
how the Web of Things will cope with these constraints. The owner wants to digitally link all
of the equipment in all of his hotels' rooms so that he can track, operate, and enhance the
management of his properties from a single location using a single control center program, as
depicted in Figure 4.1

Figure 4.1

Since there are many incompatible protocols in the Internet of Things, integrating data and
applications from various platforms is more difficult and expensive. Any computer in the
Web of Things can be reached using normal web protocols. As seen in Figure 4.2, connecting
heterogeneous devices to the network makes machine and program connectivity much easier
and simpler.

Figure 4.2
The Web of Things is the next logical step in this IoT evolution toward global networks of
sensors and actuators, allowing new applications and providing new opportunities. The Web
of Things explores the top layer of connectivity with things and addresses issues like fast
prototyping, data integration, and interaction with objects. Since the web is infinite and
flexible enough, it has become an excellent protocol for interacting with embedded devices,
and the Web of Things is a vision where things become consistently integrated into the web,
not only just via web-based user interfaces of custom applications, but also by reusing the
architectural principles of the web for interacting with the rapidly expanding ecosystem of
devices or embedded devices which built into everyday smart objects. To access the
functionality of the smart objects, well-accepted and well-understood standards and
blueprints (like uniform resource identifier [URI], HTTP, RESTful API, Atom Syndication
Format) have been used.

Even though legislative and regulatory investigations must be considered locally, regionally,
globally, and globally, the IoT is by definition global and should be treated as such. Truly,
lots of IoT work has automatically been in the WoT domain; however, it’s still important to
make the distinction between IoT and WoT.

There are also many WoT applications available over the world. Just like the portals on
Internet (public websites e.g Yahoo), WoT portals also started to appear, and so in the early
days of the Internet era. Some of the WoT applications are listed here.

i) Arduino can detect the environment by collecting feedback from various sensors and
control motors, lamps, and other actuators to influence its surroundings.
ii) Japan Geiger Map this map visualizes crowd-sourced radiation Geiger counter
readings from across Japan.
iii) Nanode: Nanode is an open-source Arduino-like board that has built-in web
connectivity. It is a platform with a low-cost for the creative development of web-
connected ideas.
iv) The National Weather Study Project( NWSP )is a large-scale environmental study
project deploying several mini weather stations in schools throughout Singapore.
v) AgSphere: At low cost a new platform that takes the complexity and pain out of
connecting agricultural technology products to the web quickly. Manufacturers of
agricultural equipment can build web-connected solutions that increase margins,
improve efficiencies and reduce the risk for farmers by harvesting information from
the farm.
 Figure 4.3

For computers and software to communicate with one another, the Internet of Things needs a
single universal application layer protocol. Instead of starting from scratch, the Web of
Things should use anything that is already commonly used for designing flexible and
immersive applications (WoT). WoT makes use of and supports widely used Web protocols,
specifications, and blueprints to make data and services provided by objects more visible to a
wider group of (Web) developers. Figure 4.3 – Only the highest OSI Layer (7), which
manages programs, utilities, and records, is used by the Web of Things. Working at such a
high degree of abstraction allows data and resources from a variety of devices to be linked,
independent of the transport protocols used. The Internet of Things, on the other hand,
typically focuses on the OSI stack's lower layers and does not argue for a particular
application- level protocol.

Many benefits can be gained from combining the elegance and diversity of lower-level
protocols behind the basic Web model. The Web of Things offers the convergence of all
types of devices and the software that communicates with them, just as the Web has become
the global integration portal for distributed applications across the Internet. Simply put, the
Web of Things hides the complexities and inconsistencies between various IoT transport
protocols, allowing developers to concentrate on the logic of their implementations without
having to understand how the protocol or devices operate.

Small-scale, locked, and disconnected implementations where computers are not readily
available or reprogrammable were the subject of most IoT projects. Any transition to an
internal implementation is complex and costly due to the personalized coupling of systems
and equipment. Since considerable resources such as time, capital, and technological
expertise are needed each time a new feature is introduced, the Internet of Things' upkeep and
development is limited. The web, on the other hand, has grown in popularity over the last two
decades due to its ease of learning and use, as well as its emphasis on loose coupling between
servers, browsers, and applications. Because of HTTP's basic and well-defined programming
model, anybody can modify individual parts of the code without destroying or altering the
whole system. As a result, developing innovative web technologies has been increasingly
affordable and open to a much wider audience of technology enthusiasts.

4.4 TWO PILLARS OF THE WEB

As seen in Figure 4.4 the two most important pillars of the Web of Things are
1. HTTPs Universe Resource Locator
2. Web browsers, multi-tiered architecture application servers.

Figure 4.4

HTTPs Universe Resource Locator

Hyperlinks play a major role when comes to WoT. Require hyperlink protocols such as
HTTP to connect the webserver to the browser effectively. Between the web server and the
browser, HTTP may transfer data in the form of hypertext, as well as HTTPs, which transfer
data in the encrypted format. Hence, HTTPs prevent the information or data from the hackers
from modifying and reading the data during the transfer between the web server and the
browser. Even if the hackers obtained the data, they were unable to use it because it was
encrypted. HTTPS uses the Transport Layer Security (TLS) or Secure Socket Layer (SSL)
protocols to establish an encrypted connection or link between the web server and the
browser. TLS is simply the updated version of SSL.

Web browsers, Multi-tiered Architecture, Application servers

In recent years, everyone started using web browsers, and all know how it works and what
are its uses. There is no point in discussing web browsers. So moving toward the Multi-tiered
architecture application servers.

Figure 4.5

As seen in Figure 4.5,there are three tiers-

i) client,
ii) application servers, and
iii) database server.

Client Tier which will have User Interface(UI) and Connectivity. Since it makes the first
impact on a customer, UI is the most important consideration for businesses. Discussing
connectivity is the primary part when it comes to IoT, which means it should possess better
connectivity among the devices to provide users a better and seamless experience.

Application Server
The Second-tier is for application servers. the application server became the basis for
building widely spreading web-based applications. An application server is a software
framework or middleware that provides an environment in that applications can run, it lies in
the middle-tier of a server-centric architecture.

It provides middleware services for security and state maintenance, inclusive of persistence
and data access. This server has been designed to install, operate, and host-associated services
and applications for the IT services, end-users, and organizations.

WoT works on Java-Based application servers. This is the logic part of the WoT inclusive of
business logic and presentation logic. This tier allows for logical decisions and analyses, as
well as measurements and application coordination, as well as method orders. Figure 4.6
depicts the Java-based program servers.

Figure 4.6

A WebLogic Server application building includes creating and assembling components, using
the service of APIs when necessary. Components are executed in the WebLogic Server Web
container. Containers simplify the life cycle support and resources specified by the J2EE
requirements, removing the need for building components to deal with underlying data. For
browser-based J2EE applications, web components have enabled presentation logic. J2EE
framework services such as JDBC, JMS (Java Messaging Service), and JTA are used to
create web applications (Java Transaction API).

The presentation logic layer

It includes the user interface and displaying logic for a program. Since it is much simpler to
deploy a client program on each user's device, most J2EE implementations use a Web
browser on the client machine. The WebLogic Server's Web container serves as the
presentation logic in this situation. The Client programs may be written in any language, but
they must have either HTML rendering logic or their presentation logic. A client who wishes
to use a Web service must create a SOAP message that explains the Web service it wants to
use and includes the necessary data in the message's body.

Session Beans

A session bean is a one-time EJB object that is only used by one recipient. Session beans are
primarily used to execute procedural logic; they also provide behaviors in addition to data.
The EJB container generates a session bean in response to a client's order. It keeps the bean
alive as long as the customer keeps the attachment to it alive. While session beans are not
permanent, they will save data to a persistent store if necessary. The state of a session bean
may be either stateful or stateless.

Stateless session beans don't keep track of any device-specific information between calls and
can be used by any client. They can be used to provide access to programs that are not
dependent on the context of a session, such as printing a document or retrieving read-only
data into a program.

A stateful session bean keeps track of data on behalf of a single client. The session beans
have been used to manage processes such as order assembly and paper routing via a
workflow framework. Session beans are often the controlling objects in an application so they
can capture and preserve state over many encounters with a client. Since session beans are
not continuous, they must finish their work in a single session and use JDBC, JMS, or entity
beans to archive the work indefinitely. This was implemented in the EJB 2.0 specification.
These beans manage asynchronous messages sent from JMS Message Queues and are
business beans. JMS routes messages to a message-driven bean, which selects an object from
a pool to process the message.

Message-driven beans The WebLogic Server EJB container has been used to handle
message-driven beans. They cannot be reached from an application using an EJB home since
they are not named explicitly by user-driven apps. However, by sending a message to the
bean's JMS Queue, a user-driven program can implicitly instantiate a message-driven bean.

Application Services Layer:

WebLogic Server provides the core services provided by components, allowing them to focus
on business logic rather than low-level implementation specifics. For EJBs and servlets, it
manages networking, authorization, authentication, replication, and remote object control.
Standard Java APIs have made it possible for applications to access other features, such as
database and messaging services, from anywhere.

Database server

Finally, a database server is the third tier. In this tier, whole data is saved and the data access
layer facilitates a platform (API) to the client which helps them by showing the possible
methods of managing the data independently.

4.5 ARCHITECTURE STANDARDIZATION FOR WOT

4.5.1 WoT Architecture

Each layer in the WoT architecture helps to integrate the Thing into the web more closely and
making those devices more accessible (Figure 4.7).

Figure 4.7

Layer 1: Access

This layer has been responsible for turning any Thing into a Web Thing which can be
interacted with by using HTTP requests. A Web Thing is a REST API that helps you to
communicate with things in the physical world, like opening a door or reading a temperature
sensor halfway around the world.

Layer 2: Find

While having information available through HTTP and WebSocket APIs is awesome, it
doesn't mean that apps can really "understand" what the Thing is, what data or services it
provides. This is where the second layer's Find feature comes into play. This layer ensures
that the Thing is not only findable and immediately accessible by other HTTP clients, but
also by other WoT applications. Its aims to make use of web semantic principles to define
objects and services. This allows for the automated generation of user interfaces or tools to
communicate with Things, as well as searching for things through search engines and other
web indexes. At this level technologies like JSON-LD are in use: a language for semantically
annotating JSON.

Layer 3:Share

The Internet of Things will only flourish if and only if Things can safely exchange data
across services. The Sharing layer is in charge of defining how the data provided by Things
can be exchanged over the network in an effective and safe manner. At this stage, a number
of Web protocols, such as TLS, the secure Web transaction protocol, can be useful. Then
there was OAuth, which assigned web authentication mechanisms that could be built into the
Things APIs. Finally, to build a Social Web of Things, use social networks to exchange
Things and their tools!

Layer 4:Compose

Finally, things are on the Web (layer 1), where humans and computers will find them (layer
2), and their services can be easily exchanged with others (layer 3), so it's time to think of
how to create large-scale, practical Web of Things applications. In other words, the
convergence of data and resources from heterogeneous Things into a vast network of network
tools such as analytics applications and mashup platforms is critical.

Figure 4.8
4.5.2 Platform Middleware

In recent markets, a broad collection of vertical WoT/IoT solutions have been designed
independently and separately for various applications, which certainly impacts or even slows
down large-scale WoT deployment. A unified, horizontal, standards-based platform is the key
to integrate the fragmentation. One main aim of platform middleware is to bring IoT
applications to the World Wide Web.

Long before many software architectures and technologies have used the terminology called
object in many modeling methodologies such as the well-known object-oriented design,
object-oriented software engineering and programming, POJO (plain old Java object),
SOAP (simple object access protocol), COM (component object model), DOM (document
object model), CORBA (common object request broker architecture), and DCOM
(distributed COM), OPC (object linking and embedding for process control), OID (object
identification), JSON (JavaScript object notation), and so on. The complete software
industry is already an object-oriented world, as shown in Figure 4.9. The representation and
programming of objects has an extreme supporting base in the software world

Figure 4.9

4.5.3 Standards for M2M

The European Telecommunications Standards Institute (ETSI’s) Global Standards

Collaboration (GSC) M2M Standardization Task Force (MSTF) considers as M2M with or
without minimal human interaction, it allows for many automatic data transfers between
computers, including virtual machines such as web applications. The Technical Committee's
ultimate aim is to develop open M2M connectivity standards to aid in the development of a
potential network of artifacts and services, allowing current and rapidly increasing M2M
businesses focused on vertical applications to be transformed into interoperable M2M
services and networked businesses using a variety of technical solutions and standards. A
schematic of the ETSI M2M architecture. All device elements must be interoperable in an
M2M system defined by specifically organized and stated network transformations,
protocols, software and hardware interfaces, frameworks, and so on. The Technical
Committee’s work is based on the basic guideline of using existing standardized systems and
elements. It evaluates them according to M2M requirements, filling gaps as necessary by
either enhancing existing standards or producing supplemental ones. The ETSI M2M
architecture key elements are described below:

M2M device: A device able to reply to the requests or transmitting data contained within
those devices independently.

M2M area network (MAN): Connectivity between M2M devices and gateways has been
provided by a network. IEEE 802.15, short-range devices (SRD), UWB, ZigBee, Bluetooth,
and others are examples of M2M area networks, as are (wired) CanBus, Modbus, KNX,
LonWorks, PLC (Power Line Communication), and others.

M2M gateway: The use of M2M capabilities to ensure that M2M systems can communicate
and collaborate with one another.

M2M communications networks: M2M gateways and M2M application servers

communicate across networks. They can also be divided into connectivity, transportation, and
core networks. xDSL, PLC, satellite, LTE, GERAN, UTRAN, W-LAN, WiMAX, and other
technologies are examples.

M2M application server: Data passes through the middleware layer and is used by basic
business-processing engines after passing through various application providers.

The layers from the M2M portal to the M2M application server are normally covered by
M2M platform middleware. Actility (Active Utility), for example, provides key infrastructure
components and software that enable mass-scale, mission-critical Internet of Things
applications, with an emphasis on smart grid applications. Actility is a hosting platform and
marketplace for M2M/IoT applications that manage data flow using open architectures
including ETSI M2M. Realizing the IoT was still missing an architectural framework capable
of handling such scale and truly enabling interoperability, Actility became a contributor to the
ETSI M2M architecture- level standard and decided to develop an open-source
implementation for IoT gateway developers, embedding all major existing M2M, sensors,
and automation protocols. All referenced hardware platforms support OSGi (Open Services
Gateway initiative framework).
The existing OMA (Open Mobile Alliance) and its M2M Task Force are producing a white
paper that identifies M2M standards gaps and recommendations for OMA actions. Several
OMA standards provide building blocks that map into the ETSI M2M framework:

i) Device management may be provided ETSI’s remote entity management service

ii) Gateway management object fulfills some ETSI gateway service requirements
iii) Firmware updates, software updates, diagnostics, provisioning, and monitoring
iv) Converged personal network services maps into ETSI M2M area network
v) Reachability, address mapping, inter/intra-area-network messaging, service
publication, and discovery
vi) Some OMA enablers (e.g., location) provide services that can be used in M2M
applications

4.5.4 Frameworks for WSN

The Open Geospatial Consortium's Sensor Web Enablement (OGC SWE) standardization
initiative is designed to be a game-changing solution to using web-connected sensors such as
flood gauges, air quality detectors, satellite-borne earth-imaging cameras, and more. SWE's
main goal is to build web-based sensor networks that make all sensors and sensor data
repositories discoverable, accessible, and, where appropriate, controllable through the
Internet (Figure 4.10).
 Figure 4.10

OGC participants who serve in the OGC Technical Committee's SWE Working Group
build and uphold SWE standards. SWE is a set of common encodings and web services
that lets you do things like:

i) Sensors, systems, and findings are discovered.

ii) Sensor or model assignment
iii) Observation streams and access to findings
iv) Method descriptions and a robust sensor infrastructure
v) publishing and subscription capabilities for alert

The following web service specifications have been entitled by the OGC SWE Working
Group

i) Sensor observation service—standard web interface for accessing observations

ii) Sensor planning service—standard web interface for tasking sensor systems and
model and requesting acquisitions
iii) Sensor alert service—standard web interface for publishing and subscribing to sensor
alerts
iv) Web notification service—standard web interface for asynchronous notification
The USN (Ubiquitous Sensor Networks) standardization of ITU-T is another effort that can
be carried out under the controlled Next-Generation Network Global Standards Initiative
(NGN-GSI). USN is a framework or network that uses sensed data to provide knowledge
services and is built on top of existing physical networks.

The following are the main components:

USN applications and services platform: technology framework to allows the effective
use of a USN in a given application or service
USN middleware: including functionalities for sensor network management and
connectivity, event processing, sensor data mining, and so on
Network infrastructure: mainly based on NGNs, USN is not a physical network but
rather a conceptual network making use of existing networks
USN gateway: A node that interconnects sensor networks with other networks
 Sensor network: Network of interconnected sensor nodes

4.5.5 Standards for SCADA

ISO 16100-1:2009:
one of the main components of ISO 16100 standard. It is primarily used in industrial
automation systems and controls IT convergence integration, describes a framework for the
interoperability of a group of software products that are used in the manufacturing domain
and, to facilitates its integration into a manufacturing application. Information exchange
models, software object models, interfaces, services, protocols, capability profiles, and
conformance test methods are all possible with this framework.
ANSI/ISA-95:
This is an international specification that specifies how to create an automated interface
between organization and control systems. This quality could be created for international
producers. It will be used in a variety of industries and processes, including batch,
continuous, and routine processes, with the goal of lowering the cost, risk, and errors
associated with integrating interfaces between business and production control systems. It
continues to be developed and refined by the Instrumentation, Systems, and Automation
Society (IAS) in association with major vendors of ERP and MES solutions around the
world.

ISA-95:
The key aim of this specification is to provide standardized language that serves as a
foundation for coordination between manufacturers and suppliers, as well as consistent
information models and an operations model that serves as a foundation for clarifying device
capabilities and how information is to be used. The five sections of the ISA-95 specification
are listed below:

• ANSI/ISA-95.00.01-2000, Enterprise-Control System Integration, Part 1: Models and

Terminology
• ANSI/ISA-95.00.02-2001, Enterprise-Control System Integration, Part 2: Object Model
Attributes
• ANSI/ISA-95.00.03-2005, Enterprise-Control System Integration, Part 3: Models of
Manufacturing Operations Management
• ISA-95.04, Object Models & Attributes, Part 4: Object models and attributes for
Manufacturing Operations Management
• ISA-95.05, B2M Transactions, Part 5: Business to Manufacturing Transactions
OPC Unified Architecture brings two elementary innovations into the OPC world (Figure
4.11). perhaps, the Microsoft Windows-specific protocol DCOM has been replaced by open,
platform-independent protocols with embedded security mechanisms. On the other hand, the
proven OPC features, like data access, historical data access, and alarms and events are
summarized in an object-oriented model and supplemented by new and powerful features,
like methods and type systems. As a result, not only can the OPC interface be specifically
implemented into applications on any device using any programming language, but arbitrary
complex systems can also be entirely represented using OPC UA. It can be implemented with
JavaEE, Microsoft.NET, or C, eliminating the need to use a Microsoft Windows-based
platform of earlier OPC versions. UA merging the functionality of the existing OPC
interfaces with new technologies like XML (extensible markup language) and web services
to deliver higher-level MES and ERP support. In 2010, the OPC Foundation and the
MTConnect Institute declared that they will work together to ensure interoperability and
compatibility between the two specifications.

Figure 4.11
the SmartProducts companies focused on demonstrating practical research that resulted in a
platform that supports stand-alone or integrated, context-aware products for a variety of
application scenarios. It developed a scientific and technological foundation for building
smart products with embedded ―proactive knowledge.‖ the following categories details the
different components of the middleware platform :
• Interaction: supporting the interaction between user and smart products
• Communication: supporting the information exchange and cooperation between different
smart products
• Context: components for sensing, processing, and distributing context information
• Proactive knowledge base: components for managing a smart product's intelligence
• Secure distributed storage: components for securely storing and distributing smart
product information
• Tools: for developing smart products, such as for automatically extracting relevant
information from manuals, editors

4.5.6 Extensions on RFID Standards

The EPCglobal-defined (RFID) architecture and frameworks are likely the most
comprehensive and complete standards.
CASAGRAS
The aim of CASAGRAS (Coordination and Support Action for Global RFID-related
Activities and Standardization) was to include a system of foundation studies to assist the
European Commission and the global community in identifying and accommodating
international problems and trends relating to RFID, with a focus on the developing Internet
of Things. It seems that nothing specifically useful or better than EPCglobal was generated
by this effort.
CASAGRAS2 started in June 2010 and ended in June 2012. The organization consists of
partners from Europe, the United States, China, Japan, Brazil, and Korea. The stated goal is
to address the crucial international issues that are important in providing the foundations and
cooperation necessary for realizing the Internet of Things as a global initiative.
BRIDGE (Building Radio-frequency IDentification solutions for the Global
Environment)
is a European Union-funded three-year integrated project addressing several ways to resolve
the barriers to the implementation of RFID in Europe, based upon GS1 EPCglobal standards,
by extending the EPC network architecture. The Discovery Service, which handles the
sharing of RFID and aggregated information between nodes, is one of the key aspects of
BRIDGE relevant to IOT-A.
The Cross UBiQuitous Platform (CUBIQ):
This project, in which nine organizations in Japan participate, focused on developing a
common platform that facilitates the development of context-aware applications. The idea is
to provide an integrated horizontal platform that offers unified data access, processing, and
service federation on top of existing, heterogeneous IoT-architecture-based ubiquitous
services. A unified data model was defined using USDL (universal service definition
language). The CUBIQ architecture having three layers (and serverless real-time location
search with RFID tags is an application example of the CUBIQ project)
• Mobile terminals with RFID tag reader collect RFID tag info and record location.
• The CUBIQ infrastructure connects the mobile terminals, which exchange RFID tag
information.
• Observers may use RFID tag information to approximate the target person's position.

4.6 UNIFIED MULTITIER WOT ARCHITECTURE

4.6.1 SOA/EAI versus SODA/MAI

The WoT/IoT applications might be inheriting and enhancing the existing data formats and
protocols, and the matching software frameworks to build platform middleware for WoT
applications.

The successor of XML-RPC, SOAP (simple object access protocol), is a protocol interface
specification for sharing structured data in the application of web services in computer
networks. Its message format is XML, and it relies on other application layer protocols in
general. For message negotiation and delivery, the most common protocols are hypertext
transfer protocol (HTTP), simple mail transfer protocol (SMTP), and Java messaging services
(JMS). SOAP, which unified the CORBA, JavaEE, and .NET camps under one umbrella, can
form the base layer of a web services protocol stack, providing a basic messaging framework
upon which web services can be built. SOAP can be a good generic WoT data exchange
protocol considering it can tunnel easily over firewalls and proxies of existing infrastructure,
among other advantages. Because of the verbose XML format, SOAP can be considerably
slower than other competing middleware technologies such as CORBA; however, this may
not be an issue when only small messages are sent, which are for machine-type
communication (MTC) of WoT.

The REST (Representational State Transfer Interface) architecture was created

concurrently with HTTP/1.1 and is based on the existing HTTP/1.0 concept, although it is not
limited to HTTP. Other application layer protocols that already have a rich and standardized
vocabulary for applications dependent on the transition of meaningful representational state
can be used in RESTful architectures. (Figure 4.12). REST is a lightweight SOAP. RESTful
applications maximize the use of the established, well-defined interface and other built-in
capabilities provided by the chosen network protocol, and minimize the addition of new
application-specific features on top of it. REST further aims to reduce latency and network
connectivity while increasing the independence and scalability of component
implementations. REST's simplistic concept and widespread popularity aided in the provision
of services that have been reused in other contexts, such as mobile apps. As a result, for
MTC-based WoT/IoT implementations, REST is a safer system protocol.

Figure 4.12

For resource-constrained devices, CoAP (constrained application protocol)is a specialized

RESTful transfer protocol for use with constrained networks and nodes for M2M applications
like smart energy and building automation. These constrained nodes often have 8-bit
microcontrollers with a smaller quantity of ROM and RAM, while networks like 6LoWPAN
often have high packet error rates and throughput of tens of kbit/s.

CoAP, similar to SENSEI, enables the REST method/response interaction model between
application endpoints, provides built-in resource discovery, as well as key web concepts like
URIs and content types. CoAP quickly converts to HTTP for network integration while
satisfying specialised specifications including multicast support, low latency, and simplicity
in restricted environments. The Internet Engineering Task Force (IETF) recently approved a
new working group named Constrained RESTful Environments (CoRE) based on CoAP’s
work. This new group focusing on specifying a RESTful web service protocol for even the
most constrained embedded devices and networks. The standard technologies such as SOAP,
REST, and CoAP are for B2B-like integration of systems on the Internet at the M2M/IoT
communication networks layer, which could be part of the unified application framework
data standards that work over the Internet. There are other standardized technologies such as
ESB (enterprise service bus, Figure 4.13) based on MQ (message queue, and MQ_TT for
resource-constrained networks) and JMS for internal enterprise application integration (EAI)
within intranet and extranet. Those technologies have been used for IoT application
integration within an intranet or extranet, as well as used or extended to work over the
Internet.
 Figure 4.13

The JCA (Java Connector Architecture) is another acceptable approach for WoT data
collection and integration based on connectors or adaptors. JCA is also for internal
EAI(Enterprise Application Integration)applications similar to OPC for SCADA (supervisory
control and data acquisition). JCA-like architecture can be used at the M2M/IoT gateway
layer. Efforts should be required more on making JCA-like architecture work over the
Internet.

EAI and B2B appear to be related but they vary radically in their details. The first is totally
within a single administrative domain. If a new protocol does not work perfectly, it can be
removed and replaced. In the cross-business environment, ripping it out affects consumers,
who may have no incentive to upgrade to the new protocol and will be vexed if it changes
continuously. Inside a business, demand for a service can be reasonably easily assessed. The
demand for a service can spike if it turns out to be more popular with customers via the
external interface. security can be maintained within a business, by firing people who abuse
it. On the external interface, a much lower level of trust should be extended. Those principles
apply to WoT applications too.

A service-oriented architecture (SOA) is a collection of standards and methodologies for

designing and implementing applications in the form of interoperable services and is typically
delivered over the Internet. Services are closely connected, unrelated units of functionality
that do not have any calls to each other. SOA has required metadata in adequate depth to
explain not just the characteristics of the promised services but also the data that powers them
(unified WoT architecture also includes metadata). The SOAP protocol defines the
correspondence protocols, while the web services definition language describes the services.
Any service-based infrastructure, such as REST, CORBA, or Jini, and any programming
language can be used to incorporate SOA. Web services make functional building blocks can
be accessible over standard Internet protocols independent of programming languages and
platforms. These services represented either new applications or wrappers around existing
traditional systems to make them network-enabled. The Web Services Business Process
Execution Language is an XML-based execution language that can be used to compose the
coarse-grained services into broader services or complete applications. These powerful
services are usually organized into processes. The Universal Description Discovery and
Integration specification define a way to publish and discover information about web services
as shown in Figure 4.14, which is also a function that WoT applications need.

Figure 4.14

The mixer of the EAI (intranet) and existing SOA (across Internet and extranet) technologies
is a better foundation for WoT/IoT applications. EAI can be extended further for MAI (M2M
application integration) within an intranet. SOA can be used for WoT/IoT integration over the
Internet and extranet. Indeed, a service-oriented device architecture (SODA) is proposed to
enable device connected to an SOA (Figure 4.15). The SODA Alliance is an open, customer-
driven, broad community chartered to promote consistent integration of the physical world
into an SOA network. A developers have connected enterprise services to an ESB using the
different web service standards. With SODA, which can be based on the OSGi framework
(described in the next section), developers can connect devices to the ESB, and users are able
to access devices in exactly the same manner that they would access any other web service.
 Figure 4.15

The main concept of SODA standard is the DDL (device description language) based on
XML encodings. DDL distributes devices into three categories: sensors, actuators, and
complex devices. Figure 4.16 illustrates the DDL device model and a sample DDL file of an
analog sensor.

Figure 4.16

4.6.2 OSGi: The Universal Middleware

The OSGi (Open Services Gateway initiative framework) is a Java programming language
module system and application platform that implements a complete and dynamic component
model. The OSGi Alliance is an open standards organization that was established in 1999 and
is responsible for defining and maintaining the OSGi specification. OSGi can be used to
remotely load, resume, interrupt, upgrade, and uninstall applications or modules without
needing a reboot. Java package/class management is defined in great detail. Application life
cycle management, such as start, end, and install, is handled by APIs that enable management
policies to be downloaded remotely. The service register offers packages to detect and
respond to the inclusion of new services or the elimination of existing services. OSGi has a
limited footprint and can run on ARM-oriented computers, such as ProSyst OSGi middleware
and operating systems like Wind River, Android (which is also based on a JVM), and so on.

The OSGi standards have expanded beyond their initial emphasis on service gateways, and
are now found in a wide range of applications, including smartphones and the open-source
Eclipse IDE (which dominates the IDE market). Automobiles, factory robotics, PDAs, grid
computing, building automation, gaming, fleet management, and application servers are
examples of other application fields. It seems that it is specifically built for IoT/M2M
applications considering it can fit in many places in the DCM value chain from device agents
to cloud servers. OSGi is a universal middleware and is going to play a major role, as a
unified multitiered middleware architecture, in building WoT/IoT applications in many
vertical segments (Figure 4.17).

Figure 4.17

4.6.3 WoT Framework Based on Data Standards

Based on the sample middleware platform, a unified multitiered IoT middleware can be
classified as having layers as shown in Figure 4.18. The extra tiers(bold outlined blocks) are
added to the existing three-tiered application server architecture.
 Figure 4.18

The unified horizontal WoT platform middleware will gather data from the M2M/IoT
gateway level and up. Figure 4.19 depicts the unified IoT middleware framework/architecture
proposed by the author as a summarization of the previous chapters.

Figure 4.19

The IoT gateways (that behave as JCA-like IoT adaptors) will be connected to the M2M
communication networks, on which the ESB-like (includes REST/SOAP functionalities)
M2M/IoT communication middleware will reside. The IoT bus will be the IoT integration
middleware similar to the SOA/EAI middleware that gathers data from all the IoT adaptors,
which represent or are the hubs connecting the IoT nodes or subsystems. Finally, the IoT
platform middleware will integrate all the data from the IoT adaptors through the IoT bus.
Figure 7.14 is the unified multitiered WoT application architecture framework based on the
platform middleware. The multitiered architecture is summarized as follows
• Application framework SES (smart enterprise suite)

• The IoT platform middleware based on an application server (container)

• IoT services bus based on ESB (REST/SOAP/MQ/JMS, etc.) and unified XML data
format and protocol

• IoT adaptor based on the JCA-like adaptor technology for M2M/IoT gateway for device
subnet or subsystems

• The back end of IoT hosted by cloud infrastructure and provides IoT cloud (MAI or
XaaS) services

• The different devices or sensors of four pillars are connected through the IoT gateways to
the IoT bus. They could be combined or in small birds-of-a-feather groups.

Recent developments on PaaS and SaaS also adopted the approach of extending the
application server platforms to have multitenant or massive multitenant supports for cloud
computing. Additionally, it is integration middleware, which is the base of EAI. The
application- level integration middleware layer is also called SES by some research firms, and
together with the platform middleware, they become application frameworks for different
vertical applications. Some packaged applications such as ERP, Manufacturing Execution
System (MES), Supply Chain Management (SCM), and others are built on top of those
middleware frameworks. The multitiered WoT architecture can also use the PaaS/SaaS
technology. Rather than reinvent what already exists, the organizations favor identifying and
fill gaps and integrating what already exists into the unified horizontal framework. This
approach recognizes that it is impossible, or at least undesirable, to try to define new physical
layer technologies, networking layer protocols, or platform middleware-based application
frameworks for every current or future potential WoT/M2M application. Various vertical
applications will optimize for individual cost and functionality requirements, while a
standardized service layer will provide cross-vertical application development.

4.7 WOT PORTALS AND BUSINESS INTELLIGENCE

A web portal or links page is a website that functions as a place of accessing data in the
World Wide Web. A portal presents information from various sources in an integrated
manner. Yahoo, AOL, Excite, MSN, and iGoogle are examples of public web portals. Web
portals provide additional services such as e-mail, news, stock prices, documents, databases,
and entertainment in addition to the usual search engine functio nality.
Portals are divided into two categories:

 horizontal portals
Which may cover many areas.
 vertical portals
Which concentrates on a single functional region A vertical portal (also known as a vortal) is
a customized entry point into a particular market or business feature, subject region, or
interest. WoT portals are vertical portals.
By the same token, WoT portals also started to appear; some of the well-known portals are
as follows:
i) Pachube: (―patch-bay‖) (recently renamed Cosm), the ―Plumber‖ of the Internet,
connects people to devices, applications, and the Internet of Things. People can
exchange, communicate, and use knowledge created from the environment around
them thanks to a web-based service designed to handle the world's real-time data.
ii) SensorMap More online live data will be available via the portal and its supporting
resources.
iii) Google PowerMeter, which was discontinued in September 2011, featured core
features such as energy consumption visualizations, the option to exchange statistics
with others, and customized energy-saving tips.
iv) Sun SPOT (small programmable object technology): Programming with Java, the
Oracle-Sun SPOT project explores wireless transducer technologies that allowing the
emerging network of things, building a hardware and software research platform to
overcome the challenges that currently slow down the development of tiny sensing
devices.
Intranets are becoming increasingly large and dynamic, presenting webmasters with more and
more content and user management problems. A comprehensive view of business data was
deemed inadequate. Personalization and customization are expected by the users. After the
public portals, EIPs (enterprise information portals) also became common. EIP solutions are
inclusive of workflow management, a collaboration between workgroups, and policy-
managed content publication. Most can be allowed to access internal and external corporate
information by secure authentication or single sign-on.

Perhaps, there is a requirement for a set of systems to combine sensor data and sensing
information with meaning. Semantic sensor networks of the W3C’s working group are
presently developing some definitive examples using the RDF metadata model and related
technologies. Additionally, a real-time semantic sensor web expansion concept is being
developed, named Sensor Wiki. The motivation behind this concept is to provide real-time
browsing of the physical world persistent with the situational awareness goal. Understanding
the physical world through an infinite of sensors is now possible.

In a sensor Wiki, one or more sensors provide real-time information as Wiki pages with
suitable themes and formats useful to approaching Sensor Wiki users. Sensor Wiki users can
discover information about objects, events, or places of interest interactively. They may also
add intelligent representations to what they see, use sensor tasking to add to the material to
increase accuracy, or even create the whole scene to provide constructive scenario evaluation.
Others might need to record such sensor streams and related information as part of a larger
objective like future planning, training, or simply record-keeping for historical purposes, and
make it available to a specific community or an individual.

When a large volume of data is gathered in an IoT system, data mining may be used to gain
business intelligence (BI) and aid in decision support. Data mining is the process of
identifying trends in data that are both meaningful and legitimate according to the user.
Databases, machine learning, analytics, pattern recognition, visualization, and other tools are
needed. The goal of decision support is to create processes that help decision-makers solve
challenges. The goal of decision support is to create processes that help decision-makers
solve challenges. Data analysis, simulation, visualization, modeling methods, and software
resources such as decision support systems, community decision support and mediation
systems, expert systems, libraries, and data warehouses are all available as part of decision
support.

Business intelligence (BI) technologies allow historical, present, and predictive views of
business operations. Extract, convert, load, monitoring, online analytical processing,
analytics, process mining, data mining, dynamic event processing, corporate success tracking,
benchmarking, text mining, predictive analytics, and so on are some of the general functions
of BI technology. For example, in many SCADA applications, BI is broadly used. SCADA
software vendors have given several suitable products like CitectSCADA Reports,
Wonderware Intelligence, Acumence Plant Analytics Server.
4.8 SUMMARY

After learning the complete architecture of IoT and its guiding principles in the previous
chapter, this chapter is the right place to know about the Web of Things. Here, WoT is
compared with IoT in various aspects. The two pillars of the Web of Things concept
introduced and the concept of the architecture standardization for WoT is also defined. The
unified multitier WoT architecture is made in a simple way to understand easily. WoT portals
and business intelligence use and their applications can be used to develop WoT architecture.

4.9 SELF-ASSESSMENT QUESTIONS

A. Descriptive Questions

Short Questions

1. When you say the Internet of Things, what do you mean by the ―thing‖?

2.Difference between Internet of Things(IoT) and Web of Things(WoT)

3.What are the two pillars of WoT?

4. What are Session Beans?

5. List the web service specifications which are entitled by the OGC SWEGroup

Long Questions

1.Outline the Multi-tiered architecture application servers of WoT

2.Explain the Java-Based application servers of WoT
3. Describe in detail the architecture of WoT
4. Write brief notes on SOAP and REST
5. What is OSGi? Explain in detail.

B. Multiple Choice Questions

1. The Web was invented by

a. Peter Waher
b. Tim Berners-Lee
c. Bruce Sinclair
d. d.Kevin Ashton
2. A virtual or physical entity that allows interactions to and participates in the Web of
Things.
a. Web
b. Things
c. Connectivity
d. Device

3. _____________can affect its surroundings by controlling motors, lights, and other

actuators.
a. Arduino
b. Japan Geiger
c. Nanode
d. NWSP

4. TLS stands for

a. Transport Layer Socket
b. Transport Layer Security
c. Transit Layer Server
d. Transport Line Socket

5.___________logic is the Web container of the WebLogic Server.

a. Application Logic
b. Presentation Logic
c. Business Logic
d. None of the above

6. The W3C Web of Things (WoT) was created to enable _______across IoT platforms and
application domains.
a. Flexibility
b. Values
c. interoperability
d. Interactivity
7. Communication middleware and _____middleware are closely related with each other.
a. Platform
b. Strategic
c. Composed
d. Value-added

8.POJO stands for

a. Plain Object Java Oriented
b. Plain Old Java Object
c. Proper Object Java Oriented
d. Program Oriented Java Object

9. ____ is a set of principles and methodologies for designing and developing software in the
form of interoperable services, usually over the Internet.
a. SEI
b. SSI
c. SOA
d. PPS

10. Core of SODA standard is_____

a. DML
b. DDL
c. DCL
d. TCL

Answers

1-b, 2-b, 3-a, 4-b, 5-b, 6-d,7-a, 8-b, 9-c,10-b

4.10 SUGGESTED READING

Reference books

 Cuno Pfister, Getting Started with the Internet of Things, O‟Reilly Media, ISBN: 978-
1-4493- 9357-1
 Internet of Things: A Hands-on Approach
 Book by Arshdeep Bahga and Vijay K. Madisetti
 Building the Internet of Things: Implement New Business Models, Disrupt
Competitors, Transform Your Industry Book by Maciej Kranz

Websites:

 https://www.edureka.co/blog/iot-tutorial/
 https://www.guru99.com/iot-tutorial.html
 https://pluto- men.com/insights/everything- you- need-to-know-about-web-of-things/
 https://webofthings.org/2017/04/08/what- is-the-web-of-things/