This led to a first refinement of the originally proposed architecture (see Figure 2). A core idea is to establish well-defined interfaces for all database components in our system, while the processing components are free in what they are doing as long as they adapt to the database components.
Figure 2: Revised version of the initial FLARECAST architecture. The Management Infrastructure and step 1 are under the responsibility of WP4, step 2 will be managed by WP2, Step 3 by WP3 and Step 4 by WP5.
The rectangular boxes in the diagram denote exchangeable software components. The system will provide multiple implementations of a data loader or a feature property extractor. It is even possible that external persons can write their own components and plug them into the system.
The database symbols in the diagram denote individual parts of the data model. They will not necessarily be implemented as individual physical databases. Each database part will define a common interface to read, create, update and delete data. The read methods include a query language to do simple queries. Figure xxx illustrates this process for an exemplatory feature property extraction algorithm (SMART). The actual interfaces are further detailed in the Data model deliverable (ref).
Figure 3: Illustration of the integration process of components into the FLARECAST system. The white boxes with black border contain the interfaces for the components.
The actual infrastructure is built on Docker containers, a collection of lightweight, linux-based computing containers, each either holding an algorithm or a database component. These containers can be deployed to any development system.
The fact that the original architecture has driven the division of the project into work packages is still visible. Figure 3 shows the association between the work packages and the corresponding components.
Figure: 4 Assignment of work packages to the architecture components