5 · Bausteinsicht¶
Die Bausteinsicht zerlegt die ODI in ihre wesentlichen Bausteine und zeigt, wie sie zusammenwirken. Kapitel 5.1 zeigt das Gesamtsystem (Ebene 1); Kapitel 5.2 öffnet den Staging-Stack als Whitebox (Ebene 2).
5.1 · Ebene 1: Das Gesamtsystem¶
Das folgende Diagramm zeigt alle Stacks der ODI, die Plattformschicht darunter und den quer liegenden Identity Provider.
Das Diagramm gliedert das System in vier horizontale Schichten. Keycloak liegt quer zu allen Schichten, da jeder Stack schreibende Zugriffe über Keycloak absichert.
Schicht 1 – Zugang & Präsentation¶
| Baustein | Repository | Aufgabe |
|---|---|---|
| API-Gateway (Traefik) | (geplant, noch im Aufbau) | Zentraler Eintrittspunkt für alle externen API-Aufrufe; Routing, TLS-Terminierung, Rate-Limiting |
| Schema-Staging-Frontend / BFF | odi-schema-staging-frontend |
Grafische Oberfläche für Datenbereitsteller; Vue 3 + Vuetify; spricht ausschließlich mit dem Staging-Backend (BFF-Muster) |
| ODW-Frontend | open-data-web |
Neues Portal für Datennutzer; Microfrontend-Architektur (Vue 3 + Module Federation) mit mehreren NestJS-Backends; noch im Aufbau |
Schicht 2 – Orchestrierungsdienste¶
| Baustein | Repository | Aufgabe |
|---|---|---|
| Staging-Backend | odi-staging-backend |
Nimmt Datensätze entgegen, orchestriert Validierung, Kataloganlage und Repräsentationserzeugung; NestJS |
| Geodaten-Dienst | (UDP-Manager-Integration, odi-masterportal-service) |
Orchestriert die Veröffentlichung und Visualisierung von Geodaten im Geo-Stack |
| Semantic-Data-Dienst | triple-converter-worker |
Konvertiert Datensätze in RDF-Triples und überführt sie in den Triple Store; Python/FastAPI |
Alle drei Orchestrierungsdienste stehen gleichrangig nebeneinander – keiner ist dem anderen übergeordnet. Jeder verantwortet seinen Veröffentlichungsweg vollständig.
Schicht 3 – Fachdienste¶
| Baustein | Repository | Endpunkt (Produktion) | Aufgabe |
|---|---|---|---|
| Schema-Repository | odi-schema-backend |
schema-repo-backend.odi.schleswig-holstein.de |
Versionierte Verwaltung von Frictionless Table Schemas; NestJS; Redis-Caching; Schemas liegen in GitLab |
| Metadata-Service | odi-metadata-service |
metadata-service.odi.schleswig-holstein.de |
DCAT-AP-Referenzdaten: Lizenzen, Publisher, Kategorien, Raumbezüge; Node.js |
| Frictionless-Backend | odi-frictionless-backend |
frictionless.odi.schleswig-holstein.de |
Inhaltliche Validierung von CSV-Daten gegen ein Schema; Extraktion und Formatkonvertierung; Python/FastAPI |
| CKAN-Service | odi-ckan-service |
ckan-service.odi.schleswig-holstein.de |
Adapter/Fassade vor dem Datenkatalog; NestJS; kapselt CKAN- oder Piveau-spezifische API-Aufrufe |
Schicht 4 – Plattform & Datenhaltung¶
| Baustein | Namespace | Wesentliche Komponenten | Backing für |
|---|---|---|---|
| Datenkatalog | odi-ckan |
CKAN (oder Piveau) | Staging-Backend (über CKAN-Service) |
| Geo-Stack | odi-udp |
GeoServer, PostGIS, UDP-Manager, Masterportal (odi-masterportal-docker-image) |
Geodaten-Dienst |
| Triple Store | odi-triple-* |
Apache Jena Fuseki (odi-triple-jena-fuseki-docker-image), SPARQL-Frontend (odi-sparql-frontend) |
Semantic-Data-Dienst |
| Dynamic-Data / IoT | odi-dynamic-data |
FROST-Server, FROST-Proxy (odi-frost-proxy), sensorthings-backend/-webapp (odi-sensorthings), MQTT-Broker |
IoT-Echtzeitdaten |
| Visualization | odi-visualization |
odi-visualization-backend (Express/Node.js), odi-visualization-frontend (Vue 3); Vega-Lite-Diagramme als Iframes in S3 |
Datenkatalog-Daten |
Querliegende Bausteine¶
| Baustein | Namespace | Aufgabe |
|---|---|---|
| Keycloak (Identity Provider) | keycloak |
OAuth 2.0 / OIDC; Realm open-data-infrastruktur; Federated Identity zu Dataport-IdP |
| CKAN-Harvester | odi-staging |
Synchronisiert CKAN-Datensätze mit dem Staging-Backend; NestJS |
5.2 · Ebene 2: Whitebox Staging-Stack¶
Der Staging-Stack enthält die meisten der in Kapitel 6 beschriebenen Kernprozesse. Das folgende Diagramm öffnet ihn als Whitebox.
Das Diagramm zeigt den Staging-Stack mit dem odi-staging-backend im Zentrum. Nach dem Prinzip der hexagonalen Architektur ist die Fachlogik des Backends von seinen Adaptern getrennt: Eingehend nimmt ein HTTP-Adapter REST-Anfragen entgegen und prüft das JWT. Ausgehend kommuniziert das Backend über je einen Client-Adapter mit dem Schema-Repository, dem Metadata-Service, dem Frictionless-Backend und dem CKAN-Service.
Dienste im Staging-Stack¶
| Dienst | Deployment | Tech-Stack | Verantwortung im Stack |
|---|---|---|---|
| staging-backend | odi-staging-backend |
NestJS (Node.js) | Orchestrierung: JWT prüfen, Schema laden, Validierung anstoßen, Datensatz anlegen, Repräsentationen ablegen, veröffentlichen |
| frictionless-backend | odi-frictionless-backend |
Python, FastAPI | Inhaltliche CSV-Validierung gegen Frictionless Schema; Extraktion nach Parquet, JSON |
| metadata-service | odi-metadata-service |
Node.js | DCAT-AP-Referenzdaten liefern (Lizenzen, Publisher, Kategorien, Raumbezüge) |
| ckan-service | odi-ckan-service |
NestJS (Node.js) | Katalog-Fassade: Dataset anlegen, Distributionen hochladen, Datensatz veröffentlichen |
| ckan-harvester | odi-ckan-harvester |
NestJS (Node.js) | Metadaten-Abgleich zwischen CKAN-Katalog und Staging-Backend per Cronjob |
Konfiguration¶
Alle Dienste beziehen ihre Konfiguration ausschließlich aus Umgebungsvariablen. Hostname, Port, Keycloak-URL und -Realm, Registry-Zugangsdaten und Datenbank-Verbindungen sind nie im Code, sondern in den Kubernetes-Manifesten (odi-kubernetes-stage / odi-kubernetes-prod) als ConfigMaps und Secrets hinterlegt. Secrets werden out-of-band per kubectl erzeugt, nicht im Git geführt.