Database Reference
In-Depth Information
Fig. 5.
Acquisition and normalization blocks.
connected with one-way links with their own successor Exchange by using the
binding rules allowed by queue manager, ensuring proper propagation of data
flows and avoiding loops. Each graph layer is composed by Java-based Graph
Nodes dedicated to process data provided by the Graph layer's Exchange. Such
processes can either be
Core Nodes
, if they are dedicated to simple and primitive
data processing, or
Application Nodes
, if they are oriented to a more complex
and specific data management. Messages, identified by a routing key, are first
retrieved from the layer's Exchange, then processed, and finally sent to the tar-
get Exchange, with a new work-related routing key, as depicted in Fig.
6
.Ifthe
outgoing routing key belongs to the same incoming graph layer, data object or
stream stay within the same Exchange and becomes available for other local
processes. If the outgoing routing key belongs to an outer graph layer, then data
are forwarded to the corresponding Exchange, and finally forwarded by following
a binding rule and assuring data flow. Each graph node, upon becoming part of
the system, can specify if it acts as a data publisher, capable of handling and for-
warding data to its layer's Exchange, or if it acts as data consumer only. A data
flow continues until it reaches the last layer's Exchange, responsible to manage
the notification to the external entities that are interested in final processed data
(ex. Data Warehouse, browsers, smart entities, other cloud graph processes, ...).
3.3 Application Register Implementation
The overall architecture is managed by a Java process (
Application Register
),
that has the role to coordinates the interactions between graph nodes and exter-
nal services, like the RabbitMQ queue server and the MySQL [
18
] database.
It maintains and updates all information and parameters related to processing
Search WWH ::
Custom Search