Zum Hauptinhalt springen
Version: In Entwicklung
Kontext & IoT

Context Hoster

Stellt versionierte JSON-LD-Kontexte für Datenmodelle bereit.

  • Standardkomponente

Der Context Hoster ist ein schlanker Webdienst zur Veröffentlichung von JSON-LD-Kontexten. Ein solcher Kontext ordnet kurze, in Fachdaten verwendete Begriffe eindeutigen internationalen Bezeichnern zu. Dadurch können unterschiedliche Systeme dieselben Begriffe konsistent interpretieren, ohne in jedem Datensatz vollständige URLs wiederholen zu müssen.

Ein Kontext wird über eine stabile HTTPS-Adresse referenziert und bei der Verarbeitung eines JSON-LD-Dokuments aufgelöst. Änderungen an bereits verwendeten Kontexten müssen deshalb kompatibel bleiben oder unter einer neuen versionierten URL veröffentlicht werden.

Context Hoster in der UDSP

Die UDSP stellt mit dem Context Hoster die JSON-LD-Kontexte ihrer NGSI-LD-Datenmodelle zentral bereit. Stellio, Node-RED und externe API-Verbraucher können dadurch dieselben Begriffe und Modellerweiterungen verwenden. Der Dienst wird gemeinsam mit dem Stellio-Pfad mandantenbezogen ausgerollt und ist über context.<DOMAIN> erreichbar.

Der Context Hoster speichert keine NGSI-LD-Entitäten, erzeugt keine Historie und prüft nicht automatisch die fachliche Qualität eines Datenmodells. Verantwortliche stellen freigegebene Kontextdateien als Container-Image bereit; der laufende Dienst liefert diese Dateien unverändert über HTTPS aus.

Konfiguration und Deployment

Der Dienst wird im Stellio-Block des Mandanten mit context_hoster.enable aktiviert. image_project und image_tag bestimmen das auszurollende Container-Image. Für ein privates Registry-Projekt werden git_user und git_token als Lesezugang benötigt; sie berechtigen nicht zur Änderung der veröffentlichten Inhalte.

Die vollständige Konfiguration ist unter Mandanten konfigurieren: Context Hoster beschrieben.

Rollen und Rechte

Zugriffsmodell

Öffentlich lesbar

Der Dienst erzeugt keine Keycloak-Rollen. Veröffentlichte JSON-LD-Kontexte werden über HTTPS gelesen.

Änderungen erfolgen nicht über eine Administrationsoberfläche oder Schreib-API. Neue oder angepasste Kontexte werden geprüft, als neues Image veröffentlicht und anschließend über das Inventory ausgerollt. Der Registry-Zugang gehört ausschließlich zum Deployment-Prozess.

Referenzen