ORLENE Platform Provider Architecture 1.0
Zweck
Provider bilden die Brücke zwischen der technologieunabhängigen ORLENE Platform Architektur und konkreten technischen Systemen.
Die ORLENE Platform kennt ausschließlich Fähigkeiten. Provider setzen diese Fähigkeiten mit konkreten Technologien um.
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.
Provider führen diese Entscheidungen aus.
Die Platform kennt niemals konkrete Betriebssysteme oder Programme als Bestandteil ihrer Kernarchitektur.
Architektur
ORLENE Platform
↓
Capability
↓
Provider
↓
Technologie
↓
HostProvider 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:
- Containerverwaltung
- Relationale Datenhaltung
- Benutzerverwaltung
- Backup
- Updates
- HTTP
- Reverse Proxy
- Dateisystem
- Audit
- Benachrichtigung
- Zeit
- Netzwerk
- Druck
- Storage
- Monitoring
- Logging
Jede benötigte Capability besitzt mindestens einen freigegebenen oder im Review befindlichen Provider.
Provider
Jeder Provider besitzt mindestens:
- Provider-ID
- Name
- Version
- Capability
- Status
- Priorität
- unterstützte Plattformen
- Voraussetzungen
- Verifikation
- Rollback
- Recovery
- Dokumentation
Diese Angaben bilden den nachvollziehbaren technischen Pass eines Providers.
Provider-Lebenszyklus
Entwurf
↓
Implementierung
↓
Review
↓
Freigabe
↓
Produktiv
↓
Ersetzt
↓
ArchivNur 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:
probe()
decide()
execute()
verify()
rollback()
recover()
report()
audit()Kein Provider darf diesen Vertrag verletzen.
- `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:
- welche Capability benötigt wird
- welcher freigegebene Provider verwendet wird
- welche konkrete Operation autorisiert ist
- wann eine Operation abgebrochen oder zurückgesetzt werden muss
Der Provider entscheidet niemals selbstständig über fachliche Ziele, andere Capabilities oder die Auswahl anderer Provider.
Beispiele
Capability: Containerverwaltung
↓
Provider: Docker oder Podman
Capability: Relationale Datenhaltung
↓
Provider: PostgreSQL oder MariaDB
Capability: HTTP
↓
Provider: Nginx oder Caddy oder ApacheBeim Austausch eines Providers bleibt die ORLENE Platform Architektur unverändert.
Providerregeln
Ein Provider darf:
- 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
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-ID
- Version
- Capability
- Status
- Freigabe
- Installationen
- Kompatibilität
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.
Beispiele für auswählende Policies:
- Ubuntu Policy
- Windows Policy
- Container Policy
- Security Policy
- Deployment Policy
- Backup Policy
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:
- 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.
Sie führen ausschließlich technische Operationen innerhalb ihrer Capability und der von der Platform erteilten Autorisierung aus.
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:
- ORLENE Platform Bootstrap
- Build & Release
- Deployment
- Platform Services
- zukünftige ORLENE-Produkte, soweit sie Platform Capabilities verwenden
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:
- ORLENE Platform Bootstrap 1.0
- ORLENE Platform – Systemarchitektur 1.0
- ORLENE Platform Register 1.0
- Build & Release
- Documentation Space
Architekturgrundsätze
- Die Platform beschreibt Fähigkeiten, keine Produkte.
- Die Platform entscheidet; Provider führen aus.
- Jeder Provider bleibt auf genau definierte Capabilities begrenzt.
- Der Provider-Vertrag ist für alle Technologien gleich.
- Provider werden durch Policies und Registry ausgewählt, nicht durch Hardcoding.
- Ausführung, Verifikation, Rollback, Recovery, Report und Audit bleiben nachvollziehbar.
- Neue Technologien verändern weder Bootstrap Core noch ORLENE Platform Kernarchitektur.
- Provider enthalten keine Geschäftslogik.
- Produktiver Status setzt Tests, Review und geprüfte Wiederherstellbarkeit voraus.
- 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.