Zum Inhalt

Architektur – Übersicht Staging

Die Open Data Infrastruktur (ODI) ist als modulare Microservice-Plattform aufgebaut. Jeder fachliche Baustein ist ein eigenständig deploybarer Dienst mit klar umrissener Verantwortung; das Zusammenspiel der Dienste deckt den vollständigen Lebenszyklus eines Open-Data-Datensatzes ab – von der strukturellen Beschreibung über Qualitätssicherung und Konvertierung bis zur Veröffentlichung im Datenkatalog und der Bereitstellung als Linked Open Data, Geodaten und Visualisierung.

Dieses Kapitel beschreibt das Gesamtbild der Architektur: die Schichten, die beteiligten Dienste, ihre Verantwortlichkeiten und ihr Zusammenspiel. Den detaillierten fachlichen Ablauf eines Kernprozesses zeigt das Kapitel Prozess: Datensatz hochladen. Eine vollständige Schnittstellenbeschreibung findet sich in der API-Referenz.

Das große Bild

Architekturübersicht der Open Data Infrastruktur

Die Architektur ist in vier horizontale Schichten gegliedert. Quer dazu liegt Keycloak als plattformweiter Identity Provider, der jeden schreibenden Zugriff absichert.

Schicht Aufgabe Bausteine
1 · Zugang & Präsentation Einstiegspunkte für Menschen und Maschinen Frontend (Backend-for-Frontend), externe API-Clients
2 · Orchestrierungsdienste Gleichrangige Kernmodule, die je einen Veröffentlichungsweg steuern Staging-Backend, Geodaten-Dienst, Semantic-Data-Dienst
3 · Fachdienste Klar abgegrenzte fachliche Fähigkeiten (Capabilities), die das Staging nutzt Schema-Repository, Metadata-Service, Frictionless-Backend, CKAN-Service
4 · Plattform & Datenhaltung Persistenz und Bereitstellung – je Orchestrierungsdienst eine Backing-Schicht CKAN/Piveau-Datenkatalog, Geo-Stack (GeoServer/PostGIS/UDP-Manager, Masterportal), Triple Store

Mehrere gleichrangige Orchestrierungsdienste

Das Staging-Backend ist nicht der einzige Orchestrierungsdienst, sondern eines von mehreren gleichrangigen Kernmodulen. Neben ihm stehen u. a. der Geodaten-Dienst und der Semantic-Data-Dienst (Triple Store / RDF). Jeder dieser Dienste orchestriert seinen eigenen Veröffentlichungsweg und besitzt eine eigene Backing-Schicht in der Plattform-Ebene. Diese Übersicht stellt das Staging-Backend in den Mittelpunkt; die übrigen Kernmodule sind als gleichrangige Nachbarn dargestellt.

Architekturprinzipien

Die Plattform folgt einigen durchgängigen Leitlinien. Sie erklären, warum die Dienste so zugeschnitten sind, wie sie sind.

  • Microservice-Architektur, capability-basiert. Jeder Dienst kapselt genau eine fachliche Fähigkeit (z. B. „Schemas verwalten“ oder „Daten validieren“). Dienste sind unabhängig entwickel- und deploybar und kommunizieren ausschließlich über HTTP-APIs.
  • Frontend-for-Backend (BFF). Das Frontend hat ein eigenes, auf die Oberfläche zugeschnittenes Backend, das Aufrufe an die Fachdienste bündelt. Die Oberfläche kennt nicht die internen Dienste, sondern nur ihr BFF.
  • Hexagonale Architektur. Innerhalb der Dienste ist die fachliche Logik von technischen Adaptern (HTTP-Clients, Persistenz, externe Systeme) getrennt. Externe Systeme werden über austauschbare Client-Adapter angebunden (z. B. der CKAN-Service als Fassade vor dem Datenkatalog).
  • Cloud-Native nach 12-Factor. Konfiguration erfolgt über Umgebungsvariablen, Dienste sind zustandslos und containerisiert. Lokal lässt sich die gesamte Plattform über Docker Compose starten.
  • Stabilität über Referenzen. Datensätze referenzieren Schemas, Lizenzen, Publisher, Kategorien und Raumbezüge über stabile IDs statt über eingebettete Kopien. So bleiben Verweise auch bei Weiterentwicklung gültig.
  • Abwärtskompatible APIs. Schnittstellen werden versioniert und so weiterentwickelt, dass bestehende Integrationen funktionsfähig bleiben.
  • Permissions statt Rollen. Zugriffe werden über feingranulare Berechtigungen im JWT gesteuert, nicht über grobe Rollen. Das macht die Autorisierung flexibel und nachvollziehbar.

Die Schichten im Detail

1 · Zugang & Präsentation

Es gibt zwei gleichwertige Zugangswege:

  • Frontend (odi-schema-staging-frontend) – die grafische Oberfläche für interaktive Nutzung. Sie ist als Backend-for-Frontend umgesetzt und ruft die Fachdienste über das Staging-Backend auf.
  • Externe API-Clients – Skripte, CI-Pipelines oder Drittsysteme, die dieselben REST-APIs direkt ansprechen. Der programmatische Zugriff ist gleichwertig dokumentiert (siehe API-Guides).

2 · Orchestrierungsdienste (Kernmodule)

Auf dieser Ebene liegen mehrere gleichrangige Orchestrierungsdienste. Sie enthalten selbst keine Datenhaltung, sondern orchestrieren nachgelagerte Dienste und Plattformsysteme zu durchgängigen Veröffentlichungswegen.

  • Staging-Backend (odi-staging-backend) – das in dieser Übersicht im Mittelpunkt stehende Kernmodul. Es nimmt Uploads entgegen, lädt Schemas, stößt die Validierung an, legt Datensätze im Katalog an, erzeugt die verschiedenen Repräsentationen und veröffentlicht das Ergebnis. Genau hier ist der beispielhaft beschriebene Kernprozess „Datensatz hochladen (CSV)“ verortet.
  • Geodaten-Dienst – orchestriert die Veröffentlichung und Visualisierung von Geodaten. Das Staging-Backend übergibt enthaltene Geodaten an diesen Dienst, der sie über den Geo-Stack (GeoServer/PostGIS/UDP-Manager) als WFS-/WMS-Dienste bereitstellt und im Masterportal verlinkt.
  • Semantic-Data-Dienst – orchestriert die Überführung in Linked Open Data: Aus Datensatz und Schema entsteht eine RDF-Repräsentation, die in den Triple Store überführt und per SPARQL abfragbar wird.

Gleichrangig, nicht untergeordnet

Geodaten-Dienst und Semantic-Data-Dienst sind keine reinen Datenhaltungs-Komponenten, sondern eigenständige Orchestrierungsdienste auf derselben Ebene wie das Staging-Backend. Im Diagramm stehen sie daher links und rechts neben Staging. Ihre jeweiligen Speicher-/Bereitstellungssysteme liegen in Schicht 4.

3 · Fachdienste

Dienst Verzeichnis Verantwortung
Schema-Repository odi-schema-backend Versionierte Verwaltung der Frictionless-Schemas, die die Struktur von Datensätzen beschreiben (Trennzeichen, Datentypen, Maßeinheiten, Geo-/Koordinatensystem).
Metadata-Service odi-metadata-service DCAT-AP-Referenzdaten für Metadaten: Lizenzen, Publisher, Kategorien (Datenthemen), Raumbezüge. Liefert die stabilen, DCAT-AP-konformen IDs, die ein Upload referenziert.
Frictionless-Backend odi-frictionless-backend Prüft hochgeladene Daten inhaltlich gegen das Schema und unterstützt die Extraktion/Aufbereitung von Daten.
CKAN-Service odi-ckan-service Adapter/Fassade vor dem Datenkatalog. Übersetzt die fachlichen Aufrufe des Staging-Backends in Katalog-Operationen (Datasets und Distributionen anlegen, aktualisieren, veröffentlichen).

CKAN-Service als Katalog-Fassade

Das Staging-Backend spricht den Datenkatalog nicht direkt an, sondern über den CKAN-Service. Dadurch ist die konkrete Katalog-Technologie (CKAN bzw. Piveau) hinter einer stabilen Schnittstelle gekapselt und austauschbar – ein Beispiel für das Prinzip der hexagonalen Architektur.

4 · Plattform & Datenhaltung / Publikation

Diese Schicht enthält die Speicher- und Bereitstellungssysteme, auf die die Orchestrierungsdienste aus Schicht 2 aufsetzen – je Orchestrierungsdienst eine Backing-Schicht.

  • CKAN / Piveau – Datenkatalog (Backing für Staging). Die persistente Heimat der Datensätze. Hier liegen die Datensätze samt ihrer Distributionen (Repräsentationen): die CSV-Originaldatei, eine Tabular Data Resource (TDR), Parquet, JSON und die RDF-Beschreibung. Veröffentlichte Datensätze werden im Portal sichtbar. Das Staging-Backend greift darauf über den CKAN-Service zu.
  • Geo-Stack (Backing für den Geodaten-Dienst). GeoServer, PostGIS und der UDP-Manager stellen die Geodaten als WFS-/WMS-Dienste bereit; das Masterportal zeigt sie als Karte.
  • Triple Store (Backing für den Semantic-Data-Dienst). Speichert die RDF-Daten und macht sie als Linked Open Data über einen SPARQL-Endpunkt abfragbar.

Querschnittsthemen

Identität & Zugriff (Keycloak)

Alle Dienste nutzen Keycloak als zentralen Identity Provider (Realm open-data-infrastruktur). Schreibende Endpunkte erfordern ein gültiges JWT; die enthaltenen Berechtigungen entscheiden über den Zugriff (Prinzip Permissions statt Rollen). Für den programmatischen Zugriff wird ein Service Account per Client-Credentials-Flow genutzt.

Datenformate & Repräsentationen

Ein einmal hochgeladener Datensatz wird bewusst in mehreren Formaten abgelegt, um unterschiedliche Nutzungsszenarien zu bedienen: CSV (Original), Tabular Data Resource (formale Beschreibung der Tabelle), Parquet (analytische Verarbeitung), JSON (programmatische Nutzung), RDF (semantische Vernetzung) und – sofern zutreffend – GeoJSON/GeoParquet bzw. WFS/WMS für Geodaten.

Fehlerbehandlung

Die Dienste unterscheiden zwischen fachlichen Fehlern (z. B. fehlgeschlagene Validierung, fehlende Berechtigung) und technischen Fehlern. Fachliche Validierungsfehler führen früh zum Abbruch, bevor ein Datensatz angelegt wird.

Weiterführend