The EOSC-hub proposal for the EOSC technical architecture

Diego Scardaci outlines EOSC-hub’s recommendation for the EOSC technical architecture

Back in June 2019, EOSC-hub organised a  “Technical Workshop” to gather input onto the design of the EOSC technical architecture. The discussion was around the technical capabilities that EOSC services should provide and related EOSC use cases, taking into consideration the main recommendations from the EOSC pilot scientific demonstrators and other EOSC-hub use cases, notably the PanCancer initiative, the Photon and Neutron experiments, the ELIXIR and EPOS research infrastructures. 

The workshop gathered around 40 participants from EOSC-hub and collaborating projects such as OpenAIRE-Advance and GNT4-3. After an introductory session where user requirements were presented and the overall strategy to define a technical architecture was discussed, participants worked on identifying key features EOSC should deliver for the technical area.

Finally, the workshop led to a proposal of an EOSC Technical Architecture.

The envisaged Technical Architecture for EOSC would facilitate access to services, lower barriers to address complex digital needs, integrate data and services from multiple suppliers, support FAIR data and enable cross-infrastructure interoperability. The architecture includes functions, interfaces, APIs and standards as technical concepts, with the final aim of fostering interoperability and, ultimately, service composability. It is based on a hierarchical structure with three levels:

• Service categories.

• Functional categories within the main category.

• Individual building blocks usable in fulfilling these functions.

The subdivision in categories allows differentiating services according to their function within EOSC:

• Federation & Access Enabling: services to support the EOSC Operations (e.g. the EOSC Portal, AAI, the monitoring or the accounting).

• Common: generic services that offer add-value features on top of EOSC resources (computing, storage, data, etc).

• Thematic: implement discipline specific features.

The second level of the hierarchy introduces the functional categories that groups technical functions to facilitate their identification. Beneath this, we see the individual building blocks that implement technical functions. Examples or function categories are Authentication and Authorisation or Monitoring, while an example of building block is the AAI.

EOSC-hub is working on implementing this reference architecture following a common approach that foresees the identification of key building blocks in each service category and, for each of those, the definition of a technical and interoperability specification that includes a series of distinguishing information, notably an high-level architecture, suggested EOSC standards and APIs and interoperability guidelines. In this way, EOSC ‘compliant’ services will offer documented interfaces for usage and integration, based on well-known standard or APIs, facilitating:

• their exploitation from user communities willing to create new scientific services.

• the combined usage of EOSC services: the adoption of well-known standards and interfaces will very likely reduce the cost to integrate services.

• the support of FAIR data: technical specifications will provide clear instructions for service providers for the use of FAIR data in support of open research.

The proposal was put forward for discussion in the wider EOSC environment. A webinar was organised during the summer to present it to a large set of user communities, feedback collection was launched in September and the work was discussed within the EOSC Architecture WG for its adoption. Initial feedback was positive and the official results from the survey will be presented at the EOSC Symposium in Budapest.

Diego Scardaci is Senior User Community Support and Outreach Officer at the EGI Foundation and part of the EOSC-hub Technical Coordination Team.