Solution architecture overview

Introduction

In the following, an overall description of the structure of the Orchestration component is given, where the primary perspective is the internal structure of the component, including the internal functions , as well as the interfaces for display clients and data sources. Furthermore the underlying infrastructure is briefly described.

The description is divided into a section that focus on the Orchestration component's primary functionality and interfaces, as well as a section that describes the Index functionality offered for data sources.

Diagrams are in the ArchiMate notation supplemented with more in-depth text. Diagrams are in danish.

Architecture of the Orchestration component

Figure text: Services and functions of the Orchestration component (blue color) and the supporting technologies (green color). Gray elements are external to the Orchestration component, e.g. http://borger.dk as display client..

The Overbliksliste/Overview List service uses the Udvælg datakilde/Select Data Sources function for each overview request from the display client based on the information in the Index, as well as which Aftaler/Agreements that are between the individual data sources and display clients. The Sammenstilling/Compile function calls the appropriate data sources simultaneously and waits for responses from data sources up to a time limit defined in Konfiguration/Configuration.

The Detalje/Detail service uses the Viderestil/Forward function to call detail service at a single data source and waits for a response up to a time limit defined in Konfiguration/Configuration.

The two services Overblik/Overview and Detalje/Detail are implemented generically for all types of business objects and share a number of common functions:

• Adgangskontrol/Access control is autorisation for calls to Overview and Detail services respectively, and is enforced for each individual data model; based on information about Agreements as well as authentication of the Display client using certificates.

• Validering/Validation, if a data source does not respond within the configured period or responds with an invalid response, it is handled as an error and is forwarded in the common error structure to the Display client together with the responses from the other data sources.

• Fejlfinding/Debugging translates error messages from orchestration, forwarding, or from the individual data source into a common model and error messages that can be used by Display clients directly in the UI.

• The Circuit Breaker works by the monitoring calls to data sources and when x-number of consecutive failed calls have been observed for a certain data source, the data source is deactivated. Deactivation means that the Orchestration component, on subsequent calls to either List or Detail, does not attempt to call a given data source. The data source is not permanently disabled, but is only disabled for a configurable amount of time. When this time period has expired, the Orchestration component tries to call the data source again.

The Orchestration component uses the common platform service Logging to persist log-information about individual calls from Display clients as well as related calls to Data sources. The log entries are designed so that they clearly reflect which components and functions contribute to the overall perceived response time for the end user. No element from the service calls body elements is logged.

The Orchestration component is implemented as a Java application using theJava Spring framework. The majority of the functionality of the Orchestration component is realized through the Apache Camel integration framework and its built-in functions. Since Java does not include standard functionality for validating JSON data structures, a third-party library is used here for this specific functionality.

The Index functions

Figure text: Services and functions of the Index component (blue color) and the supporting technologies (green color). Gray elements are external to the Index component e.g. Datakilde.

The Index component is an integrated part of the Orchestration component, but is implemented at a component itself. The following services are implemented by the Index component.

• Indeksopslag/ndex lookups are used by Orkestrering/Orchestration and will be called for each Overview list call and therefore have a large impact on the response time experienced. The function is therefore implemented as a single service call that collects all information necessary for Data source selection.

• Indeksopdatering/Index Update is one of two services where Data sources can update the Binary Index. The service support that Data sources can add or remove a single CPR number so that the Orchestration component only calls the Data source for Overview/Details when the Data source actually has data for the CPR number.

• Indeksoverskrivning/Index Overwrite is the second service for Data source to update Indeks data. The service support a full replace of the content in the index for the Data source.

Storage of CPR numbers is storing of personal data and therefore requires extra protection. The Orchestration component protects the contents of the Index by a pseudonymizing algortime that uses a hashing function.

The overall technical solution is deployed at two separate physical locations. The Index component is the Orchestration component's only data-bearing component, and the need for synchronizing data across the two locations is solved by using database technology that support low level replication.

The index component is realized based on the standard open source database PostgreSQL with associated web services that are implemented in Java Spring.