Architecture of the interoperability section of the EWP network

This section contains diagrams depicting the overall architecture of the interoperability section of the EWP network and its central components.

Some technical insides of these components are also given.

Architecture

The architecture of the EWP network is described in GitHub.

The EWP Network is strictly a middle-layer solution where no information exchanged among the parties is ever stored. It follows a hub and spoke design, where the only centralised services are:

• the Registration Portal, which enables the providers to register their manifest files. The list of the manifest files is then exported to the Registry via the manifest sources file.

• the Registry, which periodically reads the manifest files to collect this information about the nodes in the network and the list of APIs (the connectors) implemented at each node.

An institution node wishing to initiate a data transaction consults the identification data of the concerned partner in the Registry and sends a data package directly to the receiving node via the relevant API. The data package is encrypted according to EWP defined standards, ensuring the communication cannot be accessed by other parties; this guarantees high levels of security and privacy. Each node takes care of the authentication and user rights of its own users. 

Figure 1 and Figure 2 show the general overview of the architecture of the EWP network. More figures are available on GitHub.

Open

Figure 1: Architecture of the EWP network (EWP projects)

Open

Figure 2: Architecture of the EWP network (EDSSI project)

Registration process and the task of the EWP Registry

Registration Portal

From the technical point of view, the aim of the registration process is to deliver information to be added to the manifest sources file, which contains a list of URLs of the manifest files and SCHAC codes of the institutions they cover. The manifest sources file for the PROD EWP Network is created by the PROD Registration Portal. Each <source> element describes one manifest file location and contains the regular expression <hei-regex>, which filters the SCHAC code of the covered institution. If there are more SCHAC codes in the manifest file than the regular expression enables, the extra ones are omitted. In this way, we make sure that only formally approved SCHACs covered by the registered manifest files will be added by the registry to the catalogue file.

The registration process of new institutions is covered in the Registration Portal section.

Registry

The whole service can be divided into two groups of processes:

• Polling for individual manifests and the assembly of the catalogue file.

• Downloading of the catalogue file by institutions in the network upon request.

These activities are carried out independently.

Manifest files are validated in the XML Schema Validator. When reading the content of the manifest file, the registry accepts only these covered institutions which are listed in the manifest sources file. This way, only services of the authorized covered institutions show up in the network.

Every 15 minutes, the Registry rebuilds the catalogue. It has to read manifest files using the Discovery API. It takes, on the average, 80 seconds, but is done in the background.

More information on the EWP registry is given in the section describing GitHub repositories related to the Registry.

APIs

There are many repositories in GitHub with API specifications. The APIs (and their versions) are listed and shortly introduced on a separate page, and links to the respective repositories in GitHub are given there.