Zweck

Provider bilden die Brücke zwischen der technologieunabhängigen ORLENE Platform Architektur und konkreten technischen Systemen.

Zweck

Die ORLENE Platform kennt ausschließlich Fähigkeiten. Provider setzen diese Fähigkeiten mit konkreten Technologien um.

Zweck

Dieses Dokument beschreibt keine Ubuntu-Installation. Es definiert das allgemeine Architekturmodell für alle gegenwärtigen und zukünftigen Provider der ORLENE Platform.

Grundsatz

Die ORLENE Platform trifft Entscheidungen.

Grundsatz

Provider führen diese Entscheidungen aus.

Grundsatz

Die Platform kennt niemals konkrete Betriebssysteme oder Programme als Bestandteil ihrer Kernarchitektur.

Architektur

```text ORLENE Platform ↓ Capability ↓ Provider ↓ Technologie ↓ Host ```

Architektur

Provider bilden ausschließlich die technische Umsetzung. Sie verändern weder die fachliche Entscheidung noch die Kernarchitektur der Platform.

Capabilities

Capabilities beschreiben technische Fähigkeiten unabhängig von einem konkreten Produkt. Beispiele sind:

Capabilities

- Containerverwaltung - Relationale Datenhaltung - Benutzerverwaltung - Backup - Updates - HTTP - Reverse Proxy - Dateisystem - Audit - Benachrichtigung - Zeit - Netzwerk - Druck - Storage - Monitoring - Logging

Capabilities

Jede benötigte Capability besitzt mindestens einen freigegebenen oder im Review befindlichen Provider.

Provider

Jeder Provider besitzt mindestens:

Provider

- Provider-ID - Name - Version - Capability - Status - Priorität - unterstützte Plattformen - Voraussetzungen - Verifikation - Rollback - Recovery - Dokumentation

Provider

Diese Angaben bilden den nachvollziehbaren technischen Pass eines Providers.

Provider-Lebenszyklus

```text Entwurf ↓ Implementierung ↓ Review ↓ Freigabe ↓ Produktiv ↓ Ersetzt ↓ Archiv ```

Provider-Lebenszyklus

Nur freigegebene Provider dürfen produktiv ausgewählt werden. Ersetzte und archivierte Provider bleiben für Audit, Recovery und historische Installationen nachvollziehbar.

Provider-Vertrag

Jeder Provider implementiert dieselben Grundoperationen:

Provider-Vertrag

```text probe() decide() execute() verify() rollback() recover() report() audit() ```

Provider-Vertrag

Kein Provider darf diesen Vertrag verletzen.

Provider-Vertrag

- `probe()` ermittelt den aktuellen technischen Zustand ohne Veränderung. - `decide()` übernimmt ausschließlich die von der Platform autorisierte Entscheidung und bereitet ihre technische Ausführung vor. - `execute()` führt nur die autorisierte Operation aus. - `verify()` bestätigt das tatsächliche Ergebnis unabhängig von der Ausführung. - `rollback()` führt eine begonnene Änderung in einen dokumentierten sicheren Zustand zurück. - `recover()` setzt eine unterbrochene Operation anhand des gespeicherten Zustands fort. - `report()` liefert strukturierte Ausführungs- und Verifikationsergebnisse. - `audit()` protokolliert Entscheidung, Ausführung und Ergebnis nachvollziehbar.

Platform entscheidet

Die Platform entscheidet:

Platform entscheidet

- welche Capability benötigt wird - welcher freigegebene Provider verwendet wird - welche konkrete Operation autorisiert ist - wann eine Operation abgebrochen oder zurückgesetzt werden muss

Platform entscheidet

Der Provider entscheidet niemals selbstständig über fachliche Ziele, andere Capabilities oder die Auswahl anderer Provider.

Beispiele

```text Capability: Containerverwaltung ↓ Provider: Docker oder Podman

Beispiele

Capability: Relationale Datenhaltung ↓ Provider: PostgreSQL oder MariaDB

Beispiele

Capability: HTTP ↓ Provider: Nginx oder Caddy oder Apache ```

Beispiele

Beim Austausch eines Providers bleibt die ORLENE Platform Architektur unverändert.

Providerregeln

Ein Provider darf:

Providerregeln

- nur seine eigene Capability verändern - keine fremden Provider beeinflussen - ausschließlich autorisierte technische Operationen ausführen - jede Änderung dokumentieren - jede Änderung verifizieren - Rollback unterstützen - Recovery unterstützen - Audit erzeugen

Providerregeln

Bestehende Daten und Konfigurationen dürfen nicht ohne vorherige Sicherung verändert werden.

Provider Registry

Die Provider Registry ist das zentrale Verzeichnis aller bekannten Provider. Sie speichert mindestens:

Provider Registry

- Provider-ID - Version - Capability - Status - Freigabe - Installationen - Kompatibilität

Provider Registry

Die Registry bewahrt die Zuordnung zwischen Capability, Provider-Version, Platform-Version und konkreten Installationen. Sie ersetzt weder das Platform Register noch den Provider selbst.

Provider-Auswahl

Provider werden ausschließlich anhand von Platform Policies ausgewählt, niemals durch Hardcoding im Platform Core.

Provider-Auswahl

Beispiele für auswählende Policies:

Provider-Auswahl

- Ubuntu Policy - Windows Policy - Container Policy - Security Policy - Deployment Policy - Backup Policy

Provider-Auswahl

Policies bewerten Freigabestatus, Plattformkompatibilität, Priorität und Voraussetzungen. Der ausgewählte Provider erhält anschließend eine eindeutige autorisierte Operation.

Provider-Qualität

Ein Provider gilt erst dann als produktiv, wenn:

Provider-Qualität

- alle vorgesehenen Tests erfolgreich sind - das Review abgeschlossen ist - Rollback geprüft ist - Recovery geprüft ist - Audit geprüft ist - Bootstrap-Kompatibilität bestätigt ist - Voraussetzungen und unterstützte Plattformen dokumentiert sind - die Provider Registry den Freigabestatus ausweist

Sicherheit

Provider besitzen niemals eigene Geschäftslogik.

Sicherheit

Sie führen ausschließlich technische Operationen innerhalb ihrer Capability und der von der Platform erteilten Autorisierung aus.

Sicherheit

Provider dürfen keine verdeckten Seiteneffekte, keine stillen Fremdänderungen und keine ungeprüfte Ausweitung ihrer Berechtigungen erzeugen.

Verwendung in der ORLENE Platform

Die Provider-Architektur ist eine gemeinsame technische Grundlage für:

Verwendung in der ORLENE Platform

- ORLENE Platform Bootstrap - Build & Release - Deployment - Platform Services - zukünftige ORLENE-Produkte, soweit sie Platform Capabilities verwenden

Verwendung in der ORLENE Platform

Bootstrap prüft und entscheidet weiterhin im Platform Core. Ein ausgewählter Provider führt nur die autorisierte Hostoperation aus und liefert Verifikation, Report und Audit zurück.

Beziehungen

Dieses Dokument steht in direkter Beziehung zu:

Beziehungen

- ORLENE Platform Bootstrap 1.0 - ORLENE Platform – Systemarchitektur 1.0 - ORLENE Platform Register 1.0 - Build & Release - Documentation Space

Architekturgrundsätze

1. Die Platform beschreibt Fähigkeiten, keine Produkte. 2. Die Platform entscheidet; Provider führen aus. 3. Jeder Provider bleibt auf genau definierte Capabilities begrenzt. 4. Der Provider-Vertrag ist für alle Technologien gleich. 5. Provider werden durch Policies und Registry ausgewählt, nicht durch Hardcoding. 6. Ausführung, Verifikation, Rollback, Recovery, Report und Audit bleiben nachvollziehbar. 7. Neue Technologien verändern weder Bootstrap Core noch ORLENE Platform Kernarchitektur. 8. Provider enthalten keine Geschäftslogik. 9. Produktiver Status setzt Tests, Review und geprüfte Wiederherstellbarkeit voraus. 10. Bestehende Daten werden vor Veränderungen gesichert.

Offene Umsetzungspunkte

Dieses Architekturmodell implementiert noch keine konkreten Provider. Nach fachlicher Freigabe folgen getrennte Spezifikationen und Implementierungen für Provider Registry, Provider-Vertrag und erste Hostprovider. Ubuntu, Windows, Docker, Podman, PostgreSQL oder andere Technologien werden dabei als austauschbare Provider umgesetzt, nicht als Bestandteil des Platform Core.