This section contains diagrams depicting the overall architecture of the interoperability section of the EWP network (DEV and PROD) and its central components.
Some technical insides of these components are also given.
...
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 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 server 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 server 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 server node takes care of the authentication and user rights of its own users.
...
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
| Panel | ||
|---|---|---|
| ||
The main task of the EWP Registry is to:
|
The whole service can be divided into two groups of processes:
EWP node polling Polling for individual manifests and the assembly of the catalogue file.
Downloading of the catalogue file by institutions in the network upon request.
...
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.
...