An Open-Source Cloud Architecture for Big Stream IoT Applications - Interoperability and Open-Source Solutions for the Internet of Things - page 78

performs the following operations: (i) attach new nodes or consumer applica-
tions interested in some of the streams provided by the system; (ii) detach nodes
of the graph that are no more interested in streaming flows and eventually re-
attach them; (iii) handle nodes that are publishers of new streams; (iv) maintain
information regarding topics of data, in order to correctly generate the routing-
keys and to compose data flows between nodes in different graph levels. In order
to accomplish all these functionalities, the Application Register Module is com-
posed by two main components, as shown in Fig. 4 . The first one is the Graph
State Database , which is dedicated to store all the information about active graph
nodes, such as their state, level, and whether they are publishers. The second one
is the Node Registration and Queue Manager (NRQM), which handles requests
from graph nodes or external process, and handles the management of queues
and the routing in the system. When a new process joins the graph as a listener,
it sends an attach request to the Application Register Module, specifying the
kind of data to which it is interested. The NRQM module stores the information
about a new process in the Graph State Database and creates a new dedicated
input queue for the process, according to its preferences. Finally, the NRQM
sends a reference of the queue to the process, which becomes a new listener of
the graph and can read the incoming stream from the input queue. After this
registration phase, the node can perform new requests (e.g., publish, detach, get
status), which are detailed next.
The designed graph-based architecture allows to optimize resource allocation
in terms of eciency , by switching off processing units that have no listeners reg-
istered to them (enabling cost-effectiveness), and scalability , by replicating those
processing units which have a large number of registered listeners. The combi-
nation of these two functionalities and the concept of listener allow the platform
and the overall system to adapt itself to dynamic and heterogeneous scenarios
by properly routing data streams to the consumers and add new processing unit
and functionalities on demand. In Fig. 4 , all the architecture modules with the
complete flow of information through all steps described above are presented in
detail.

3 Implementation

Three main modules concur in forming the entire system: (i) acquisition and
normalization of the incoming raw data; (ii) graph management; (iii) applica-
tion register entity. In this section, the details of the implementation of the
proposed architecture by using standard protocols and open-source components
are presented. The implementation has been carried out by deploying an Ora-
cle VirtualBox R

VM, equipped with Linux Ubuntu 12.04 64-bit, 2GB RAM,
2 CPU, 10GB HDD. Since the architecture is based on a queue-communication
paradigm, an instance of RabbitMQ [ 8 ], an open-source queue server implement-
ing the standard Advanced Message Queuing Protocol (AMQP) [ 9 ], was used.
RabbitMQ provides a multi-language (Java, PHP, Python, C, ...) and platform-
indipendent API. Next, the implementation of each fundamental building block
is described in detail.