Database Reference
In-Depth Information
check system_status
if system_status not satisfactory
then PLAN
The PLAN phase recommends necessary changes required either in the system or
in the infrastructure hosting the system. The PLAN is designed in such a way that it
will look for nearby
it refers to the
(allocated_resource, system_parameters) pair and as described earlier, the user or the
administrator denes ' best ' . PLAN is not executed if the system status is in a good
enough situations. Executing any of the phases takes resources, on the other hand
system should learn from its steps and different situations as well. The system has been
designed to learn only from the steps that it takes or the situations that it was in, but not
from the scenario that it has not faced so far.
During the execution phase, the autonomic agent tune-up the system according to
the data-store tuning parameters [ 16 ]. In this implementation work, the cloud database
[ 17 ] is the main objective where this work has been concentrated on. The performance
of cloud LSM database that the OpenIoT is using has several parameters that needs to
be tuned up to get the best performance from it [ 18 ]: (a) memory and processing
capability (b) indices and statistics (c) locking and threads (d) disk layout (e) query
plans (f) swapping. In the implementation, have been considered the memory and
processing capacity and demonstrated the outcome. The reason behind this narrow
consideration is because the deployment of autonomic framework for IoT test-bed in
general is limited to speci
'
best performance pair
'
.By
'
performance pair
'
c technology rather than broader technologies. The data
store underlying the IoT platform is platform dependent and those parameters can vary
from data store to data store. Regarding what parameter will determine the performance
of the speci
c data store in what dimension and magnitude, it is a separate research area
and it is out of the scope of this paper. The evaluation of parameters via autonomic
con
guration is also possible and this work de
nes a roadmap for those particular
requirements.
5 Experiments
A use case has been created, to explain the functionality of SSC. Figure 3 represents the
use case where data from sensors (left-hand side) needs to be offered as stream data
mashup that is used by web services and to distribute multiple users (right-hand side).
By means of this use case, data from Smart Santander is collected and transformed into
universal open format (RDF) data streams. Then distributed in SSC distributed data
servers hosted by Planet. The cloud-based distributed processing is performed in
BonFIRE and as response of the service request in the form of multiple queries over the
streamed data generated. Finally the SSC visual interface provide access to all the
Smart Santander sensor data distributed in the world by using Virtual Wall API.
The experiment design, depicted in Fig. 4 follows the service lifecycle for IoT, in this
particular experiments the open source open source platform super stream collider, a mash
up builder ( www.superstreamcollider.org ), is used to demonstrate service instantiation.
The agent-based framework analyses the requirements, dependencies and resolves them
Search WWH ::




Custom Search