Architecture of the Interoperability section of EWP network

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

Technical insides of these components are also described.

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 service is the Registry, which contains the identification info of the various members’ servers and the list of APIs (the connectors) implemented at each member’s server. An institution server 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 server 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 server 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.

Registration process and the task of the EWP Registry

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 Joining the EWP network section.

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

• EWP node 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.

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.