Extension scenarios

User story I want to get all the extension to the INSPIRE theme register
Input

Query: get the INSPIRE theme register including all of the extension

 

EXAMPLE: http://inspire.ec.europa.eu/RoR/extension/reg1/theme

Expected result

A list of reference to the register item.

EXAMPLE: For the example content, will return the list of register items:

  • reg2/theme/msa
  • reg3/theme/logistics

 

Components
  • Register of Registers (RoR)
  • Local registries

Figures legend:  Requests;   Responses;   Extension information store;


1. Decentralized extension scenario

Description

  • The information on the extension are kept at the local registries level;
  • The RoR is responsible for gateting all the extension information for a given query and aggregate the results.

Workflow (Figure 1)

  1. The federated registries have to keep the extension information at a local level;
  2. The user ask to the RoR the request (get all the extension to the the INSPIRE theme) passing as input the register (reg1/theme);
  3. The RoR forward the request to the federated registries;
  4. The federated registries return the results (if available) to the RoR;
  5. The RoR aggregates the results;
  6. The RoR returns the results to the user.

Figure 1 - Decentralized extension scenario workflow

 

Implications

  • A common exchange format (query encoding and result encoding) has to be supported by all the federated registries.
  • The federated registries shall provide the API for gatering the extension informations. The entry point related to the API has to be provided during the registration to the RoR.

 

2. Centralized extension scenario

Description

  • The information on the extensions are kept at the RoR level.
  • Each federated registry shall register the extension using the RoR's API.
  • The RoR uses the centralized extension information to find the results and return them to the user.

Workflow (Figure 2)

  1. The federated registries has to registries their extension using the RoR's API;
  2. The user ask to the RoR the request (get all the extension to the the INSPIRE theme) passing as input the register (reg1/theme);
  3. The RoR search in the central extension informations to find the results;
  4. The RoR returns the results to the user.

Figure 2 - Centralized extension scenario workflow

 

Implications

  • The RoR shall provide the extension registration API.
  • The federated registries shall register the extension using the RoR's API.

Pros and cons

  PRO CONS
1. Decentralized extension scenario
  • The extension information are kept at the local registries level (the registries don't have to register the extensions to the RoR);
  • Possible request delay due to a distributed query (the query response time depends on network, local registries performances);
  • The federated registries shall provide the API for gatering the extension informations.
2. Centralized extension scenario
  • Fastest response (single query point);
  • No big effort on the federated registries side to get federated (they only need to call the RoR's API to register their extensions).
  • All the workload is on the RoR side;
  • The federated tegistries have to register their extension using the RoR's API