INTRODUCTION

In the Internet of Things (IoT) domain real-world objects such as

sensors, actuators, wearable devices, smartphones, and appliances are made
available over the Internet to provide data or to be controlled remotely. One
of the most interesting directions of investigation in IoT aims at defining
interaction paradigms and communication protocols for smart object (SO)
integration. An SO is a physical object that provides data and/or undertakes
actions under the control of a driver/agent who exposes the SO features over
a network . The concept of integration is often expressed through the term
orchestration, which conveys the idea of coordination and in some ways
assumes the existence of a director. The success of IoT depends on the
existence of tools for application design, deployment, management, and
execution. This focus on such tools and platforms, i.e., on the IoT
application layer, which mainly involves distributed software architecture
and technology, interaction paradigms among software components, and
service orchestration. This assume that an effective transport layer is
available and works appropriately, i.e., that the things to be connected are
equipped with appropriate hardware controllers and are connected to a
network infrastructure. The first objective toward creating an IoT horizontal
platform hosting distributed applications that orchestrate SOs is to establish
of a uniform software interface. Such an interface can be obtained by
wrapping the SOs in virtual blocks (VBs) that expose SO functions in the
form of services.In addition to the services corresponding to the SO
functions, which are distinctive of each SO (e.g., a thermometer provides a
temperature, and a video camera provides a video stream), VBs provide a
number of SO-independent services: object creation and deployment,
session control, dynamic binding, authentication, and authorization.
Presentation of SO functions in the form of services enables modeling IoT
applications as composite applications (CAs), i.e., as services obtained
through the coordinated action of the atomic services provided by VBs.
Coordination of VBs is provided by a software platform called Orchestrator.
AEP, a platform for executing applications that interact with and/or control
SOs. The core of the platform is a scalable service composition execution
engine extended with a set of additional elements and software components
designed to fulfill requirements typical of the IoT domain. Such
requirements have been derived from the analysis of some service scenarios
in the domains of smart car, smart home, and smart city. The result is an
original platform able to coherently cover a set of requirements covered only
partially or in a fragmented way by other IoT application platforms. AEP
executes IoT distributed applications as CAs, orchestrating virtualized views
of SOs. AEP is also equipped with features (e.g., late binding) and functional
elements (e.g., dynamic registry) aimed at flexibly executing applications in
a context where SOs dynamically change their availability conditions.

 SYSTEM REQUIREMENTS
AEP was designed to satisfy a set of requirements; this is identified by
analyzing the functional features and the nonfunctional characteristics of the
service scenarios in some of our previous works in the domains of smart
home ,smart car, and smart city.

Object Coordination (RQ1)

A service logic coordinates one or more SOs. The service logic and
the SOs interact according to an event/command paradigm. The service logic
must be able to receive and process asynchronous messages sent by the SOs,
to notify events (e.g. new measures and detection of state changes), and to
send commands to the SOs. The system must be able to manage dynamic
relationships between service logic and SO events and to provide aggregated
views of multiple SOs, both of the same type and of different types.

2.2. Object Virtualization (RQ2)

The system must be able to support a vast number of heterogeneous
devices adopting different communication protocols to invoke functions
and/or access real-time status and configuration parameters. In order to tame
such heterogeneity, SOs must offer an abstract view so as to allow the
platform and service logic to interact with them in a uniform way. This
abstraction level must rely on a common formalism to define and invoke
interfaces and on a common interaction model(e.g., based on
event/command paradigm). An abstraction level associates a common and
extensible set of functional primitives with similar devices. Extensibility,
e.g., according to an object-oriented model, enables the possibility to take
advantage of the peculiarities of different SOs belonging to the same
category.

2.3. Dynamic SO Joining and Leaving (RQ3)

The system must cope with the dynamic entrance of new SOs in a
service area (SA): an SA can be associated with either a physical
environment (e.g., a car) or a virtual environment (e.g., a subset of rooms in
a house). The system must be able to consider several (possibly overlapping)
SAs: each SA is under the control of a specific administration domain and is
characterized by a set of service logics. The system must verify that only
authorized SOs can join a specific SA. An SO can dynamically enter a
SA when its state fulfills certain conditions, e.g., the deployment of a new
SO, the reactivation of an existing SO after a failure or, in case of a mobile

device, the establishment of a Bluetooth connection with another SO in the

SA. Analogously, the system has to cope with an SO leaving a SA, either
because it is explicitly removed or switched-OFF(e.g., due to a failure), or
because it closes a communication connection. The system must keep track
of all the SOs in a given SA, and must provide functions for the dynamic
selection and retrieval of SOs, which are relevant for the execution of a
service in a given SA.

2.4. Dynamic Change of SOs State (RQ4)

SOs are characterized by a state, which may include their internal
status (e.g., active, power-saving, and stand-by mode), some nonfunctional
(e.g., QoS levels), and context parameters(e.g., location). When an SO
changes its state, the system must be able to trigger or inform the relevant
service logic. In addition, a service logic must be able to retrieve the state of
the SOs that it coordinates, e.g., to react to (temporary) unavailability of
some of them.

2.5. Coordination of External SOs and Services (RQ5)

In addition to SOs in its SA, a service logic can also interact with SOs
in other SAs, according to access policies defined by domain administrators
(e.g., the local smart-city administrator can authorize that any service logic
can interact with the SOs in a public SA). In addition to SO coordination,
service logic must support the orchestration of generic services, to take
advantages of reusable features available over the Internet or a Telco
network (e.g., the control of a video stream).

2.6. Object Description (RQ6)

In order to enable dynamic management and retrieval of SOs, the
system must use a formalism able to (semantically) describe the SO
functional features and nonfunctional characteristics. The descriptions must
enable representing similarities among SOs, according to some ontological
representation ; therefore, a service logic is able to select the SOs which
better match the required characteristics.

2.7. Scalability (RQ7)

The system must be scalable according to two dimensions:1) the
number of service logics, where each service logic can have a large and
dynamic set of concurrent instances (a.k.a., sessions) performing longrunning transactions and 2) the number of SOs registered in the system.

2.8. Security (RQ8)

In addition to the security issues related to communication, the system

must be able to cope with issues related to identification and authorization of
service logics and SOs. The system must be able to identify and authorize an
SO when it is attempting to register in an SA, and a service logic when it
attempts to interwork with an SO

SYSTEM DESIGN
Fig. 3.1 shows the architecture of AEP, a software platform supporting
the execution of composite applications (CAs): each CA is specified and
executed through the coordinated action of a set of VBs. VBs are atomic,
modular, and reusable software components wrapping/abstracting SOs but
alsoWeb APIs,and data sources to make these functionalities composable
into CAs.

Fig. 3.1. AEPs architecture

Virtual Block (VB)

VBs are very important because they are used for the virtualization of
SOs (see RQ2). As shown in Fig.3.1.1., each VB includes a front-end part
exposing well-defined primitives and a back-end part, which interacts with
external resources by means of a transport layer (Bluetooth and 3G/4G
connections). Virtualization is crucial because it enables combining different
services and SOs in an easy way by hiding the heterogeneity of the involved
technologies to CAs. While little can be said on the back-end, as it depends
on the specific characteristics of an SO and/or API, on the contrary the
behavior of the VB front-end can be analyzed in detail. Graphically, a VB,
which supports the event-command paradigm (see RQ3) by means of the
VBRequest and VBDone primitives, can be depicted as a block with one
input port and one output port as shown in Fig. 3.1.1. More specifically: 1)
the input port is associated to the Request primitive (VBRequest): such a

primitive includes an input property set representing configuration

parameters and 2) the output port is associated to the Done primitive
(VBDone): the output properties in such a primitive include the contents
generated by the VB, if it is supposed to generate content, or simply the
indication that the request was positively/negatively executed.

Fig. 3.1.1. VB interface

3.2. Orchestrator

This Orchestrator component is in charge of executing the CAs by

coordinating the VBs (see RQ1). The way the VB actions are combined can
be expressed graphically as a directed graph, where the nodes denote the
VBs and the edges describe the action flow. A CA is a static definition of a
service logic and is used by an execution engine, the Orchestrator, as a
template to start many sessions at run-time. Each CA is associated to a set
of configuration properties called initial properties. Each link of the graph
goes from a VB_Done primitive to a VB_Request to express the fact that a
state change in a VB triggers the execution of another VB. For each CA
execution, there is a property set representing the state of the application.
Connecting of an edge to the input of a VB is associated with an action
aimed at configuring the VB input properties. The way the VB input
properties are to be configured can be specified graphically by linking the
VB input properties either to the output properties of some of the previously
executed VBs or to the CA initial properties assigned at session start. At
execution time, a session executing an instance of a CA is created. The
property set (a.k.a., session state) is appropriately initialized and is
progressively enriched with the output properties generated by the VBs once
they complete execution. When a node originates multiple paths, each path
receives a copy of the property set and proceeds autonomously, enriched
with the properties generated by the VBs that it meets. As a consequence, the
property set is not to be regarded as a set of global properties since at any
given point it includes the CA initial session properties and the execution
state, consisting on the properties generated by the VBs already executed.
The session properties comply with the single assignment paradigm as they
are assigned unique names (generated at session creation time) and values at
the time they are created, and maintain such values up to session
termination. The single assignment property is very important in the
presence of multiple branches in the CA specification because parallel
branches can be executed concurrently, disregarding shared variable
management.
Session
properties
are
stored
as

<PropertyName,PropertyValue> pairs where the variable type is implicitly

detected; the property set is expanded at run-time by adding new pairs.

3.3. SOs Type Description

The VBs in the system are grouped in types, where each type is
associated with a set of elements, e.g., the VB state and the VB properties,
both functional and nonfunctional (see RQ6). The VB type attribute is
certainly necessary to allow the Orchestrator to execute the CA
appropriately, but more than that it is necessary to support the selection of
the VBs. In AEP, such a selection is performed both at the activation stage,
when a service instance is configured, and during execution, to support late
binding and replacement of VBs . In fact, flexible VB selection can be
achieved only by means of a mechanism that support VB selection at run
time based on a dynamic matching between the required VB and the set of
possible VB. It follows that VBs should be semantically described through
appropriate ontologies previously defined . We thus adopted a semantic
description formalism which extends existing ontologies and semantic
descriptions of objects with additional elements required for self-managed
IoT solutions. We assume that SOs are semantically described by traditional
semantic protocols such as resource description framework (RDF) and Web
ontology language (OWL) but in this paper, we do not analyze this aspect in
depth.

3.4. Dynamic Registry

The dynamic registry (the key element for RQ3, RQ4,RQ5, and RQ8)
collects the run-time information on the VBs coordinated through the CA
executed by the Orchestrator. It consists of two elements, namely a presence
server (PS), in charge of handling VB dynamic aspects, and the VB List, that
associates the VBs to their types. The PS manages the inventory of the
available VBs dynamically joining/leaving the system. Each VB is
associated with the information about its state (active/stand-by/temporary
not available, battery level, and available connectivity) and its current SA(s).
The PS tracks the VB state changes. Due to security reasons, only the VBs
previously authorized/ configured can register in the PS and be associated
with a specific SA. Therefore, the PS includes authentication and
authorization functions to identify VBs and enforce registration policies. For
example, when a mobile phone establishes a Bluetooth connection with an
object O in a car, it contacts the PS through the associated VB and requests
to register in the SA of O (i.e., the SA associated with the car). The PS
identifies requestors and grants/denies registration. The PS natively provides
a set of primitives compliant to a publishsubscribe interaction model (such
as subscribe, publish,and notify) which can be used by VBs to notify the PS
about their presence in a specific SA and their state changes. In order to cope

with the possibility that VBs become unavailable for unexpected reasons,
each VB must periodically refresh its state. The same set of primitives
offered by the PS is used by other components of the platform to monitor the
evolution of the VB set in a given SA and their state changes. For instance,
in the architecture depicted in Fig. 1, an Orchestrator interacts with the PS to
receive events on availability and state changes of the VBs involved in the
execution of a specific service: in this way, the Orchestrator is constantly
aware of the current state of each VB; it can, therefore, recognize whether a
VB needed during service execution is currently available, in compliance
with the late binding feature . In addition, the PS has to check whether the
Orchestrator is allowed to monitor the state of a given VB. The second
element of the dynamic registry, the VB List, is in charge of associating the
VBs available in the system with their static characteristics, such as the
location of fixed objects and nonfunctional properties, including the VB
type, i.e., the (semantic) description of its behavior and of its service request
and done primitives. The VB list supports service configuration and late
binding by enabling the retrieval of the VBs that fulfill specific
characteristics (e.g., location, supported functional, and nonfunctional
properties). This is performed by applying (semantic) match between the
characteristics of the requested VB and the characteristics of the objects
registered in the system. The list of selected VBs is constantly updated by
the PS by considering availability and state.

3.5. Late Binding and Missing Object Management

In order to deal with the dynamicity of IoT applications where VBs
can change their status very quickly, AEP supports two mechanisms that
make its runtime behavior very flexible (see RQ3 and RQ4). The first one is
VB late-binding: it basically means that the blocks that appear in the
graphical specification of a CA represent a VB class (i.e., a type) instead of a
specific VB (i.e., static-binding) while the Orchestrator component is in
charge of choosing the right VB at run-time on the basis of criteria such as
location, energy efficiency, and battery level. In this way, the AEP may end
up orchestrating different objects during the execution of the same CA
depending on the context in which the application is running. The second
mechanism enables an AEP to manage cases in which no VB is available for
a specific VB type (perhaps due to several reasons such as battery
exhaustion and connectivity problems).We then defined a policy
enforcement mechanism to manage the cases in which no VB is available for
a specific CA. In particular, thanks to the dynamic registry, the Orchestrator
is constantly aware of the current state of all the VBs and can recognize
whether an SO requested during a CA execution can find an appropriate
match among the available VBs. If no appropriate VB is available, then the
Orchestrator applies some policies defined at service creation time to
manage the exception appropriately,for instance, as follows.

1) It skips the interaction with the unavailable SO. For example, a CA

might coordinate gathering a set of pictures from three different cameras
aiming at displaying the collected images on a TV-set. In this example, the
skip policy might be used if one of the three cameras is missing or turned
OFF because the absence of one SO is not critical for the execution of the
CA.
2) It may abort the execution of the CA and send an alarm to the
appropriate users. For example, the system might choose to abort the
execution of the surveillance CA involving some sensors and cameras if a
motion detector device is not working properly.Moreover, the users might
specify a notification channel (e.g., SMS and e-mail) in order to be informed
about execution failure.
3) It may delay the progress of the CA until a suitable VB becomes
available/active. For example, a CA might coordinate the printing of some
pictures stored in a camera by means of a smart printer. If the printer is not
available when the service is executed (e.g., because it is OFF), the system
might freeze and delay the execution of that session and restore it as
soon as the printer becomes available again.

IMPLEMENTATION
4.1. Concurrency
The core of the AEP consists of an Orchestrator that interacts with a
set of VBs. The Orchestrator is implemented by a software component called
Orchestration manager (OM), whereas VBs are implemented by software
components called VB managers (VBM). While the OM and the VBMs
interact in a local environment where latencies are negligible, the VBMs
typically interact with real objects on wide area connections, often over the
Internet, where network latency is a critical issue. The presence of a huge
number of connections in a wait state forces the adoption of a concurrency
model based on asynchronous I/O which decouples network connections
from threads. VBM was so implemented using Java NIO technology (i.e.,
the Java library for asynchronous I/O management) and appears as a single
thread implementing a forever loop the iteration of which consists of the
nonblocking event handlers associated to the different network events such
as CONNECT (TCP connection established) and READ (new data
available on the socket). The Orchestrator manager (OM) never performs
blocking operations as it only has to select the next VBs to be activated at
the termination of each VB. As a consequence VBM does not need a
dedicated thread but, on the contrary, it can be implemented as a plain
software component, i.e., using Java terminology, as a plain old Java object
(POJO). The technical issues concerned with the development of the event-

driven OM. The results of a set of performance evaluation tests performed

on our prototype that show that the event-driven model outperforms the
thread-based model.

4.2.Parallelization Models
Two alternative parallelization models to support executing an
increasing number of sessions and both exploit the replication of AEP
nodes . The first approach is to replicate the VBM and the OM components
separately on different physical nodes and to provide a message-based
interaction system supporting communication among components(see
Fig.4.2.1) . In such an environment, the VB_Request and the VB_Done
primitives travel in messages are queued at destination and are processed
one at a time, typically in a first-come-first-served order. As far as session
management is concerned, sessions might be tied statically to a specific OM
node (i.e., all the VB_Request/VB_Done messages are managed by the same
OM for the entire session execution), but such a choice might limit the
scalability of the system because it does not allow dynamic distribution of
the workload on all the available OM nodes. The time needed to perform
one orchestration step (i.e., the time spent between one VB_Done primitive
and the following VB_Request primitive) is:
TOTOT = TN + TFW + To (1)
where:
TN is the latency introduced by the network, as the OM and the VBM
components run on different nodes;
TFW is the time employed by the message oriented communication system
to manage message exchange. This value includes both a constant
component (e.g., the parsing of the incoming messages) and a variable
component (e.g., the time spent by the messages in the queue, which
depends on their number);
To is the time needed by OM to discover the next VB(s). As shown in [11],
TN + TFW >> To, which means that thetime spent for the actual
orchestration phase is much lower than the time spent for network
communication and framework management operations. It follows that
improved system performance requires a reduction of management
operations. The method described in the next paragraph solves this problem.
Fig. 4.2.1.Parallel session execution over a distributed memory computation
model

The second approach is called Compact AEP where Compact

means that on each node both the OM and the VBM run together (e.g., in the
same JVM as POJOs in case of a Java-based solution) without relying on
any underlying framework. Each OM can interact only with the VBM
running on the same machine and vice-versa(see Fig.4.2.2.). In this case,
session execution can be parallelized at a coarser granularity level by
associating each session with a specific computational node and distributing
the sessions over the available computational nodes. A session starting its
execution on a specific machine is completely executed on that node, with
the consequence that load balancing must be applied at session start time. In
this latter approach, the fact that both the OM and the VBM run in the same
machine leads to the possibility for the VB_Request primitive and the
VB_Done primitive to be implemented as regular method invocations (i.e.,
they do not require distributed component interaction). In this case, the time
needed to perform an orchestration step is
TOTOT = TNIO + To (2)
where TNIO is the time needed to manage the nonblocking I/O, which is
constant and, thanks to its asynchronous nature, independent from the actual
duration of the connection-oriented interaction with the external service and
To is the time needed by OM to discover the next VB(s).

Fig. 4.2.2. Parallel session execution over a shared memory computation

model.

5. SMART CAR USE CASE

5.1. Use Case Description
Bob is driving around with his car but at a certain point he needs a
parking spot, possibly the closest to his current position. He pushes a button
on his steering wheel and he obtains the parking spots information (address
and available spots) on the cars screen. The AEP supports this use case
because it allows the creation of a CA integrating cars sensors (i.e., the GPS
device), cars actuators (i.e., the screen), and Web information

5.2. Prototype Setup

The deployed AEP, on a laptop located in the car (in a production
environment the platform might be deployed directly on the cars on-board
unit). The laptop communicates with the cars sensors and actuators by

means of the Bluetooth protocol while it communicates with the parking

open data Web service through a 3G connection. Four VBs are available in
the AEP (namely a speed VB, a GPS VB, a parking VB, and a display VB) .
The CAs logic is as follows:
1) when the CA is started, retrieve the car speed through the speed VB;
2) retrieve the car GPS position;
3) invoke the parking service VB;
4) show a message on the car display.
It is worth noting that the parking block shown in Fig. 5.2.1.
represents a generic service instead of a specific service. As a consequence,
the AEP will perform a late binding operation that will invoke the closest
available parking service. That means that depending on the current location
of the driver, the parking block will query the best service among a set of
parking VBs (e.g., it invokes the open data service provided by the city of
Turin . Location aware CA execution is supported by the interaction between
the Orchestrator and the dynamic registry. Different parking services are
registered in the dynamic registry providing a set of information such as
type, longitude, and latitude

Fig. 5.2.1 Example of a workflow CA specified through a graphical tool

Session Properties
All the properties have a unique name given by the concatenation of a
VB unique name and a property unique name. For instance, in the property
ParkingService.0.userLongitude, ParkingService.0 is the VB unique name
(the number is needed to distinguish other ParkingService VBs in the same
CA), whereas userLongitude is the property unique name. The CAs logic
specifies how the properties are updated

EXPERIMENT
We now describe the experiments performed to analyze the
performances of the concurrency model described. In order to provide an
evaluation of the AEP, we developed two versions of a CA comprising a
chain of 5 and 10 VBs, which is the typical CA size. Each VB is a parking
service VB, which interacts with aWeb service simulating the real open data
API (i.e., we are simulating what we called the back-end service ). In

particular, the simulated back-end service was implemented to provide a

response after 180 ms.1 We then calculated the execution time as the
difference between T_finish and T_start (see Fig. 6.1.).

Fig. 6.1. CA used for the experiments (5 VBs).

We finally stressed the AEP by injecting execution requests at
different rates. We repeated the experiments with four different
configurations.
Config_1: CA with 5 VBs running on the event-driven AEP.
Config_2: CA with 5 VBs running on the thread-based AEP.
Config_3: CA with 10 VBs running on the event-driven AEP.
Config_4: CA with 10 VBs running on the thread-based AEP.
Fig. 6.2. Comparison event driven versus thread models when the CA has 5
VBs.

Fig. 6.3. Comparison event driven versus thread models when the CA has 10
VBs.
We measured the average execution time for the CA to see how the
threading model affects this important value. Figs. 6.2 and 6.3 show how the
event-driven model outperforms the thread-based model since the CA
execution time is always lower regardless the number of VBs belonging to
the CA. In particular, the benefit of the event-driven model increases with
the input rate. This is mainly due to the fact that the number of threads that
are active in the system concurrently increases considerably for the threadbased AEP, whereas the same parameter is constant (and low) for the eventdriven AEP. Figs. 6.4.6.6. show the empirical cumulative distribution
function (cdf) of the execution times of the 5 VB CA using an event driven
concurrency model (Fig. 6.4.) and a thread-based concurrency model (Fig.
6.5.).
Fig. 6.4. CDF for the event driven/async model.
Fig. 6.5. CDF for the thread model.
We observe that while in the event driven case the service execution
times follow a normal distribution, on the contrary in the thread-based model

they follow an irregular pattern. This is due to thread management, which

introduces significant and irregular processing overhead. In Fig. 6.6., we
overlap the two graphs using the same scale. We observe that the event
driven model significantly outperforms the thread-based model. The event
driven curve rapidly reaches 100%, meaning that almost all the sessions last
less than 1176 s (remember that the expected duration is 900 ms), whereas
the thread-based curve shows session durations distributed over a longer
interval, up to 4 s. Although the experiment was done with many sessions of
the same CA, the comparison in Fig.6.6. can be generalized to a more realist
case in which many CAs of different size exist. This is due to the fact that
the analysis only refers to the event processing overhead introduced by the
OM.

Fig. 6.6. Empirical CDF of the execution time of a 5-VB CA.

CONCLUSION
AEP is a possible contribution to some of the research challenges in
the IoT domain. In particular, it proposes an open framework for the
definition, deployment, and execution of IoT applications. This propose a set
of requirements for software platforms that host CAs combining
heterogeneous SOs. The dynamicity of the IoT application scenario poses
many challenges: we describe an architecture and a related implementation
of an IoT service platform that addresses most of the identified
requirements. In particular, the VB concept cope with device heterogeneity
and to support the orchestration of smart objects in complex IoT
applications. A late binding mechanism, using a semantic description of
smart objects, is proposed as a basic mechanism for implementing a context
aware and self-adapting platform. Such a mechanism requires a universally
accepted ontology for smart object description. Finally focus on some
implementation details including concurrency and scalability, and describe
and compare two different deployment models, one based on smart object
distribution and one based on complex application distribution.

REFERENCES
[1]

Michele Stecca, Corrado Moiso, Martino Fornasa, Pierpao Baglietto,

and Massimo Maresca, A Platform for Smart Object Virtualization
and Composition, ieee Internet of Things , December 2015

[2]

J.Jin, J.Gubbi, S.Marusic, and M.Palaniswami, An

framework for creating a smart city through Internet
ieee Internet Things , April 2014

[3]

K. Li and L. Jiang, The research of web services composition based

on context in Internet of Things, in Proc. ieee Int Comput. Sci.
Autom. Eng. (CSAE), 2012

[4]

S. Abdelwahab et al., Enabling smart cloud services through remote

sensing: An Internet of Everything enabler, ieee Internet Things
Jun. 2014.

[5]

http://www.slideshare.com

information
of Things,