Service onboarding procedure

From NI4OS wiki
Revision as of 19:10, 26 March 2020 by Anastas Mishev (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Within the NI4OS-Europe project, the generic rules defined by EOSC WGs will be adopted according to the project requirements ensuring continuous compliance. In particular, amongst others, the landscape activities and high-level rules of participation are covered by WP2 of NI4OS-Europe, FAIR data principles by WP4, technical architecture and corresponding technical rules of participation by WP3, sustainability issues by WP7, while WP5 will manage the practical on-boarding of the resources following the rules of the previously listed WPs. Of course, these rules and technical architecture of the EOSC federation evolve dynamically, and close monitoring of improvements in these areas is required. Therefore, NI4OS-Europe nominated delegates in all EOSC WGs, and in addition to this, the project signed the Collaboration Agreement between all INFRAEOSC-05 projects to share information, results, and to collaborate in order to avoid the duplication of efforts.

In general, resource on-boarding includes five main steps illustrated in Figure below:

  • a request is sent by the service provider via e-mail or submitted via a dedicated form that officially initiates the on-boarding process;
  • relevant information is gathered using a service description template or a corresponding online form, which could be incorporated in the service catalogue/portfolio system;
  • the resource is integrated with the existing EOSC tools and federated core, such that it is compatible with the defined rules of participation;
  • the resource is validated using tools from the federated core;
  • the resource is published in the EOSC catalogue.


The information gathering process process is based on the EOSC Service Catalogue Template Specification (SCTS) In the first phase of the project, SCTS will be implemented as an Excel document, to be filled out by a service provider with support of the WP5 team, and manually or semi-automatically transferred to the project's service portfolio/catalogue system. Later on, it will be implemented as an online form within the portfolio/catalogue system. Our portfolio/catalogue management tool, AGORA, must strictly follow the proposed template.

The information-gathering process fully describes a service and its previously achieved development and management stage, as well as the desired level of EOSC integration to be delivered within the framework of NI4OS-Europe. The integration will be done following the technical rules defined by WP3 in the form of a matrix, based on recommendations provided by EOSC WGs, WP2, WP4, WP6, and WP7. Rows in such a RoP matrix of packages, illustrated in Figure below, are service type-specific, while the columns are federating core-specific or generic service-specific. It means that we will create a set of rules per particular type of service and per particular service from the pre-production environment or generic service pool. Similarly, the integration with a particular generic service will be followed by the corresponding set of rules defined for it. The operational tools provided by WP3 and WP4 will dynamically verify implementation of these rules.


Once NI4OS-Europe verifies the service or repository, it will be published within the project catalogue, and the WP5 team will proceed with its EOSC registration. This should go smoothly since our procedures and rules will be compatible with the EOSC ones. For service registration, we will use the EOSC portal Join as a provider form, while for repositories, we will use the Open AIRE content provider dashboard.