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

3.1 Acquisition Nodes and Normalization Nodes Implementation

The system needs an input block capable to handle external incoming raw data,
through different application-layer protocols. Data must then be processed and
structured, in order to be managed by the graph processes.

AcquisitionNodes. Considering the main and most widespread IoT application-
layer protocols, the implementation supports: (i) HTTP [ 10 ]; (ii) CoAP [ 11 ]; and
(iii) MQTT [ 12 ].
For the sake of scalability and eciency, an instance of NGINX [ 13 ] has been
adopted as HTTP acquisition node reachable via the default HTTP port. As a pro-
cessing module, a dedicated PHP page has been configured to forward incoming
data to the inner queue server. NGINX has been selected instead of the prevail-
ing and well-known open source Apache HTTP Server Project [ 14 ] because it uses
an event-driven asynchronous architecture to improve scalability and specifically
aims to reach high-performances even in case of critical number of request.
CoAP acquisition node has been implemented using a Java process, based
on a mjCoAP [ 15 ] server instance connected to the RabbitMQ queue server.
MQTT acquisition node is realized by implementing an ActiveMQ [ 16 ] server
through a Java process, listening for incoming data over a specific input topic
( mqtt.input ). This solution has been preferred over other existing solution (e.g.,
the C-based server Mosquitto [ 17 ]), because it provides a dedicated API that
allows a custom development of the component. The MQTT acquisition node
is also connected to the architecture's queue server. In order to avoid poten-
tial bottlenecks and collision points, each acquisition protocol has a dedicated
Exchange and a dedicated queue (managed by RabbitMQ), linked together with
a protocol related routing key, ensuring the ecient management of incoming
streams and their availability to the normalization nodes.

Normalization Nodes. Incoming raw data from the acquisition nodes may
require a first optimization process, aiming at structuring them into a com-
mon and easily manageable format. Normalization processes extract raw data
from dedicated incoming queues, leaving the routing key, which identifies the
originator smart object protocol, unchanged. Each normalization node is imple-
mented as a Java process, which processes incoming raw data extracted from a
queue identified through a protocol-like routing key (e.g., .event.in ).

Received data are fragmented and encapsulated in a new JSON structure, which
provides an easy-to-manage format. At the end of the processing chain,
each normalization node forwards the new data chunk to its next Exchange,
which connects the normalization block to the first Graph layer Exchange (Fig. 5 ).

< protocol >

3.2 Graph Management Implementation

Incoming messages are stored into active queues, connected to each Graph
Layer's Exchange. Queues can be placed into the Core Graph , for basic com-
putation, or into Application Graph , for enhanced data treatment. Layers are