Architecture of EUCAIM
  • Architecture of the EUCAIM Platform
  • 1. Introduction
  • 2. High-level User Stories
  • 3. High-level Architecture
  • 4. Detailed Architecture
  • 5. MM2 Early Prototype
Powered by GitBook
On this page

3. High-level Architecture

Previous2. High-level User StoriesNext4. Detailed Architecture

Last updated 11 months ago

The high-level architecture aims at identifying the main components and interactions. It serves as an overall view of the system and to understand the implications of each component.

Figure 1 depicts the architecture overview, using the following colour coding: Blue for data providers (WP2 and WP7), Pink for central hub services (WP4), Orange for data modelling and matching (WP5) and Green for data processing (WP6).

Figure 2: High-level view of the architecture.

In a nutshell, data providers can join the federation (blue) or upload anonymised data to the central storage (pink). Technically, the central storage acts as any other node of the federation. The data providers push their collections’ metadata to the central services of the federated catalogue, which will display it to the data requesters. The data could be further explored through a federated search, which will forward the query to the providers, following a Common Data Model (CDM) schema. Providers that do not have their data ready following the agreed CDM schema will use a mediator to match the terms in the query. All the services are coherently authenticated and authorised through a Federated AAI.

The users will request access to the collections through the Access Negotiator, which will manage the access request process. Access request is not a trivial task and will require extensive documentation. The user will be able to explore and to process the access-granted collections in the User’s Area using the Processing Services. Data can be browsed through the Case Explorer, which will give access to different tools and functionalities. Furthermore, Data and Tool providers will be able to get traceability information through the Tracing service, which will also provide high-level provenance information to the users in the Federated Catalogue (such as the datasets used to train a tool or the popularity of a tool or a dataset). Finally, other services complement the functionality, with a Helpdesk for support management, and a Data Transfer Services to temporarily copy data on the Processing Node services.

The components of the architecture will implement the User Stories described in section 2. A summary of the components involved to implement each of the User Stories is provided in table 2.

#

Dashb.

AAI

Public Catalogue

Fed Query

Collection Explorer

Access Negotiator

Process

Central Repository

Local Services

usDP1

X

X

usDP2

X

usDP3

X

X

X

usDP4

X

X

X

usDP5

X

X

X

X

X

usDP6

X

X

X

X

usDP7

X

X

X

usTP1

X

X

usTP2

X

X

X

usDU1

X

X

usDU2

X

X

X

X

usDU3

X

X

X

X

X

usDU4

X

X

X

X

usDU5

X

X

X

X

usDU6

X

X

X

usDU7

X

X

X

usDU8

X

X

X

usDU9

X

X

X

usDU10

X

X

X

usDU11

X

X

X

usDP1

X

X

X

usGB1

X

X

usGB2

X

X

usGB3

X

X

X

usPM1

X

X

X

X

usPM2

X

X

X

X

X

X

X

X

Table 2: User Stories and components involved.