EOSC Service Architecture Sergio Andreozzi EGI Foundation sergio

EOSC Service Architecture Sergio Andreozzi EGI Foundation sergio. andreozzi@egi. eu 2 nd EOSCpilot Governance Development Forum workshop, 3 October 2017, Tallinn (Estonia)

Outline What does the EOSC needs to support Roles involved in using/managing the EOSC services Architecture Types of services Next steps 2

What: Open Science A systemic change in the modus operandi of science and research Affecting the whole research cycle and its stakeholders Commissioner Carlos Moedas Open Science Presidency Conference Amsterdam, 4 April 2016 EOSC as an evolving system serving a multitude of actors 3

Open Science “Open Science represents a new approach to the scientific process based on cooperative work and new ways of diffusing knowledge by using digital technologies and new collaborative tools. The idea captures a systemic change to the way science and research have been carried out for the last fifty years: shifting from the standard practices of publishing research results in scientific publications towards sharing and using all available knowledge at an earlier stage in the research process. ” “Open Science has an impact on the entire research cycle, from the inception of research to its publication, and on how this cycle is organised. ” EOSC supporting collaboration & sharing 4

EOSC “users” Open Science opens up the entire research enterprise…. . Open Science opens up the entire research enterprise (inner circle) by using a variety of means and digital tools (outer circle) [EC - DG R&I 2016, p. 36] EOSC as a facilitator of new scholarly and scientific processes 5

EOSC “users” Use functions and tools to perform their domain specific research activities and to collaborate Develop new analytical models, new processes and tools to analyse data and derive knowledge Develop services for scientists by understanding their requirements and the Open Science vision Scientists Data scientists Managers Service developer Infras provider Service provider Facilitate the operation, assistance and quality assurance of the EOSC system and the coordination among its different stakeholders Provide access to computational, storage and network resources, according to declared SLAs Operate and provide access to their own portfolio of services according to declared SLAs 6

EOSC “users” (cont. ) These users • operate with different types of resources and • demand different services and working environments Scientists Data scientists Managers Service developer Infras provider Service provider Scientists and developer scientists need services to produce research artifacts (including methods and tools) and need virtual research environments to support their multidisciplinary collaboration Developers of services often demand for access to appropriate platforms, including those providing facilitated access to computational and storage resources 7

EOSC “users” & “resources” Research asset / artifacts inclusive of papers, datasets, scientific software, scientific workflows, notebooks, compound “research objects” virtual research environment specifically set up for supporting any research question / endeavor / goal Scientific software that is almost daily produced, usually developed in the form of scripts / small programs and nonnecessarily following strong software engineering practices, likely developed by nonprofessional computer scientists Software that is produced, published, and managed according the FAIR principles EOSC is expected to deliver Service that includes all the functions exploited to deliver, monitor, and orchestrate the EOSC system Scientists Data scientists Managers Policies and Procedures defined to govern the EOSC system SLA used to define the level of service expected from the service provider Service developer Infras provider Service provider Computational and storage resources that are made accessible according to the policies and SLA EOSC is expected to deliver Scientific service that is made accessible according to the policies and SLA EOSC is expected to deliver 8

An abstract scenario Provides server “S” INFRASTRUCTURE PROVIDER SERVICE PROVIDER Server “S” gets result D Publishes Service X on Service Catalogue Service “X” runs on “S” SCIENTIST Executes the service on his data Finds the Service D DATA Catalogue Service Catalogue Dataset D Service X was developed by DATA SCIENTIST Finds D and use it in a Scientific paper Publishes result (e. g. dataset) In the Data Catalogue SERVICE Developer Collaborate 9

A Real-World Scenario: Pan. Cancer (Science Demonstrator funded in EOSCpilot) Cancer researchers and the end users of BUTLER platform The data experts who produce the data and are aware of the application requirements of it BUTLER and Onedata software developers Scientists Data scientists Managers Service developer Infras provider Service provider Provisioning services Ensuring SLAs are delivered Supporting users Cloud and data storage resource providers Service providers running: - Onedata-based service - Cloud compute and Offering storage + computing capacity 10

How: Experts suggestions • It should “federated, globally accessible, multidisciplinary environment” where researchers, innovators, companies and citizens can publish, find, use and reuse each other's data, tools, publications and other outputs for research, innovation and educational purposes [OSPP EOSC report expanded from HLEG EOSC report, https: //goo. gl/p 6 a 4 kb] • It should “build on existing capacity and expertise where possible” • It is approached as a “federated environment for scientific data sharing and re-use, based on existing and emerging elements in the Member States, with lightweight international guidance and governance and a large degree of freedom regarding practical implementation” • “It should enable trusted access to services, systems and the re-use of shared scientific data across disciplinary, social and geographical borders” Basic “principles” for the implementation of the EOSC system architecture (from the HLEG on EOSC) 11

Excerpts from the EOSC Declaration federation more capacity for more users co-created with users federationenabling services needed EOSC Declaration, 10 Jul 2017 12

EOSC as a System-of-Systems EOSC Components: Exiting and emerging RIs, e-Infras, data repositories, 13 registries, …

EOSC as a System-of-Systems DRz RIj RIx RIt DRs E-Infraa Ra EInfra E-Infrab RIg RIk a Rw Components: Existing and emerging RIs, e-Infras, data 14 repositories, registries, …

System-of-systems: characterising properties Geographical distribution Operational and managerial independence A So. S is distributed over a large geographic extent Each system is independent and it achieves its purposes by itself and for its own objective rather than for the purposes of the So. S Added-Value D R z RIt Evolutionary development A So. S evolves with time and experience RIg s E-Infaa Ra E-Infab D R RIj RIx EIn fa RIk a A So. S has capabilities and properties that do not reside in the component systems R w Heterogeneity of constituent systems The EOSC architecture is designed to satisfy these principles A So. S consists of multiple, heterogeneous, operating systems embedded in networks at multiple levels 15

Need for a federation and access layer EOSC Domain 1 EOSC Domain 2 EOSC Hub EOSC Domain 3 EOSC Domain n 16

Example of hub concept as designed by the EOSC-hub project EOSC-hub is a project successfully evaluated in the H 2020 EINFRA-12 -2017 Call – Planned start 1/1/2018 17

PID Service Alert Service Metadata Enrichment Repository Service Metadata Linking Repository Validation Scientists IDE as_a_service VRE Factory RStudio Data Scientists Validation Environment Transition Environment Service Developers Recommender Service Metadata Citation Service Validation Workflow Service Policy and Semantic Licence Helper Integration Helper Shared Social Networking Workspace Service Mat. Lab Software Repository Validation Environment Assessment Environment Data Catalogue Service Desk Service Catalogue IT Security Environment continuity VRE Factory IT Security Data Catalogue Service Desk Environment operations VRE Factory Service Desk Service Catalogue Operational Service Mgmt Operations bridge Service continuity IT Security Environment operations VRE Factory Operations bridge Service transition 18 Services for EOSC Managers Services for … Abstract Class of Services

Abstract Class of Services (cont. ) Resource Catalogue Service Desk Services for … Service Providers Infrastructure Dashboard Service Desk IT Security Multi-supplier coordination Service continuity Multi-supplier coordination The identification of the EOSC services is intended to be an iterative process that will evolve • through the requirements received from the demonstrators • with the evolution of the other elements that are involved in its development, like rule of engagement, incentives and rewards, policies, and governance For the set of necessary services identified, it is not yet specified who will be the service provider that will operate and delivery these services 19 Services for EOSC Managers Service Catalogue Service Dashboard

Validation and monitoring of EOSC principles of engagement: examples Scientists Data scientists Managers Service developer Infras provider Service provider Scientists exploiting EOSC must have a known identity and profile EOSC Scientists produced artifacts must be deposited and findable Developed software services in EOSC must have an explicit licence associated with them All EOSC services must be registered in the EOSC catalogue of services Infrastructure providers must ensure the established SLA Service Desk operational hours are … 20

EOSCpilot WP 5: Main Delivereables D 5. 1 : Initial EOSC Service Architecture the high-level EOSC (reference) service architecture [12] Initial EOSC Service Architecture the high-level EOSC (reference) service architecture D 5. 4 : Final EOSC Service Architecture [24] Final EOSC Service Architecture describes the high-level EOSC (reference) service architecture updated after input from executed service pilots and WP 6 Interoperability. 21

Summary EOSC Service Architecture System of systems approach Initial actor roles identified Initial service layers identified Initial analysis of types of services per layer performed Service federator role vs. federated system/domain 22

Thank you : -) For feedback: Donatella Castelli EOSCPilot WP 5 Leader donatella. castelli@isti. cnr. it 23