Zweck

Die Runtime Architecture beschreibt den vollständigen Laufzeitbetrieb der ORLENE Platform.

Zweck

Sie definiert, wie sämtliche Komponenten während des laufenden Betriebs zusammenarbeiten, ohne ihre fachlichen Verantwortlichkeiten zu vermischen.

Zweck

Dieses Dokument beschreibt weder den Bootstrap-Prozess noch die interne Umsetzung einzelner Provider. Es ist die übergreifende Laufzeitreferenz für deren kontrolliertes Zusammenspiel mit allen weiteren Platform-Komponenten.

Grundsatz

Jede Runtime-Komponente besitzt eine klar abgegrenzte Verantwortung.

Grundsatz

Keine Komponente übernimmt Aufgaben einer anderen.

Grundsatz

Alle Kommunikation, Entscheidungen, Zustände und Ergebnisse erfolgen nachvollziehbar und bleiben einer eindeutigen Runtime-Operation zugeordnet.

Gesamtarchitektur

```text Benutzer ↓ ORLENE Platform ↓ Platform Core ↓ Capabilities ↓ Provider ↓ Host ```

Gesamtarchitektur

Parallel angebundene Platform-Komponenten:

Gesamtarchitektur

```text ┌──────────────────── Platform Register ├──────────────────── Documentation Space ├──────────────────── Development Space Benutzer → Platform Core ├──────────────────── Reading Space ├──────────────────── Review Workspace ├──────────────────── Build & Release ├──────────────────── Policies ├──────────────────── Provider Registry ├──────────────────── Audit └──────────────────── Report ↓ Capability ↓ Provider ↓ Host ```

Gesamtarchitektur

Der Platform Core koordiniert die Beziehungen. Register, Dokumentation, Review, Build, Audit und Reports bleiben eigenständige Komponenten mit klaren Schnittstellen.

Platform Core

Der Platform Core koordiniert ausschließlich. Er enthält:

Platform Core

- Entscheidungen - Autorisierung - Capability-Auswahl - Policy-Auswahl - Workflowsteuerung - Runtime Context

Platform Core

Der Platform Core führt keine technischen Hostoperationen aus. Er wählt anhand der autorisierten Operation, der benötigten Capability, der Policies und der Provider Registry einen geeigneten Provider aus.

Runtime Context

Während jeder Operation existiert genau ein gemeinsamer Runtime Context. Er enthält mindestens:

Runtime Context

- Operation-ID - Platform Instance - Benutzer - Capability - Provider - Policy - Status - Beginn - Ende - Warnings - Fehler - Audit-ID - Report-ID

Runtime Context

Der Runtime Context ist die eindeutige Klammer für Entscheidung, Ausführung, Verifikation, Report, Audit, Recovery und Antwort. Er darf nicht zwischen parallelen Operationen geteilt werden.

Runtime Workflow

Der Standardablauf lautet:

Runtime Workflow

```text Anfrage ↓ Platform Core ↓ Capability ↓ Provider-Auswahl ↓ Provider ↓ Host ↓ Verifikation ↓ Report ↓ Audit ↓ Antwort ```

Runtime Workflow

Jeder Übergang aktualisiert den Runtime Context und erzeugt bei relevanten Zustands- oder Entscheidungsänderungen ein Runtime-Ereignis.

Runtime-Komponenten

Die Runtime umfasst mindestens:

Runtime-Komponenten

- Platform Core – Entscheidung, Autorisierung und Koordination - Bootstrap – initialisiert eine Platform Instance vor ihrem regulären Betrieb - Provider – führt eine autorisierte technische Operation aus - Platform Register – bewahrt Instanzen, Status und technische Zuordnungen - Documentation Space – verwaltet nachvollziehbares Platform-Wissen - Development Space – stellt Entwicklungszusammenhänge bereit - Reading Space – stellt freigegebenes und prüfbares Wissen lesbar dar - Review Workspace – führt fachliche und technische Reviews - Build & Release – koordiniert Build-, Release- und Deploymentabläufe - Audit – bewahrt unveränderbare Ereignis- und Entscheidungsspuren - Report – dokumentiert Ergebnis und Verifikation einer Operation - Policies – bestimmen zulässige Auswahl- und Ausführungsregeln - Provider Registry – verzeichnet Provider, Freigaben und Kompatibilität - Runtime Context – trennt und verbindet alle Daten einer Operation

Runtime-Komponenten

Bootstrap bleibt ein eigener Lebenszyklusbaustein. Die Runtime Architecture beschreibt nur seine Einbindung und die Übergabe einer betriebsbereiten Platform Instance an den laufenden Betrieb.

Kommunikation

Keine Komponente kommuniziert direkt mit fremden Komponenten, wenn der Platform Core für Entscheidung, Autorisierung oder Koordination zuständig ist.

Kommunikation

Zulässig:

Kommunikation

```text Documentation Space ↓ Platform Core ↓ Provider ```

Kommunikation

Nicht zulässig:

Kommunikation

```text Documentation Space ↓ Provider ```

Kommunikation

Direkte technische Kommunikation ist nur erlaubt, wenn sie durch einen ausdrücklich definierten Vertrag autorisiert ist und keine Entscheidung des Platform Core umgeht.

Ereignismodell

Jede relevante Runtime-Aktion erzeugt ein strukturiertes Ereignis. Beispiele:

Ereignismodell

- Bootstrap gestartet - Provider ausgewählt - Policy ausgewertet - Hostoperation abgeschlossen - Verifikation abgeschlossen - Audit erzeugt - Review abgeschlossen - Build gestartet - Deployment abgeschlossen - Recovery gestartet - Rollback abgeschlossen

Ereignismodell

Ein Runtime-Ereignis besitzt mindestens Ereignis-ID, Operation-ID, Platform Instance, Typ, Status, Zeitpunkt, Quelle und Referenzen auf Audit und Report. Ereignisse ersetzen nicht den Runtime Context, sondern dokumentieren seine relevanten Änderungen.

Runtime Status

Runtime-Operationen besitzen mindestens folgende Zustände:

Runtime Status

```text Pending Running Waiting Recovery Rollback Failed Completed ```

Runtime Status

Jede Operation besitzt jederzeit genau einen offiziellen Status. Statusübergänge werden durch den Platform Core kontrolliert und auditiert. `Waiting` bezeichnet eine nachvollziehbare Wartebedingung und niemals einen versteckten Zustand.

Fehlermodell

Fehler entstehen niemals still.

Fehlermodell

Jeder Fehler erzeugt beziehungsweise aktualisiert:

Fehlermodell

- Report - Audit - Runtime Status - Recovery-Möglichkeit

Fehlermodell

Fehler bleiben dem Runtime Context, der Operation und der betroffenen Platform Instance zugeordnet. Eine fehlgeschlagene Verifikation darf nicht als `Completed` erscheinen.

Parallelität

Mehrere Runtime-Operationen dürfen gleichzeitig laufen.

Parallelität

Jeder Runtime Context trennt Operation-ID, Status, Benutzer, Capability, Provider, Policy, Audit und Report eindeutig. Gemeinsame Ressourcen dürfen nur über definierte Koordinations- und Sperrmechanismen verändert werden.

Parallelität

Parallelität darf weder Auditspuren vermischen noch Entscheidungen, Recovery oder Rollback einer anderen Operation beeinflussen.

Sicherheit

Keine Runtime-Komponente darf:

Sicherheit

- Geschäftslogik verändern - Provider umgehen - Audit umgehen - Policies umgehen - den Runtime Context einer fremden Operation verändern - nicht autorisierte Hostoperationen ausführen - versteckte Seiteneffekte erzeugen

Sicherheit

Autorisierung wird vor der Provider-Ausführung geprüft. Verifikation erfolgt nach der technischen Operation und unabhängig von deren Erfolgsmeldung.

Monitoring

Die Runtime liefert jederzeit nachvollziehbare Informationen über:

Monitoring

- laufende Operationen - wartende Operationen - fehlgeschlagene Operationen - Recovery - Rollback - Platform Ready - Providerstatus

Monitoring

Monitoring liest offizielle Runtime-Zustände, Register-, Report- und Auditdaten. Es erzeugt keine eigenen fachlichen Zustände und verändert keine laufenden Operationen.

Architekturgrundsätze

1. Platform Core entscheidet. 2. Provider führen aus. 3. Capabilities bleiben dauerhaft. 4. Provider bleiben austauschbar. 5. Runtime ist vollständig nachvollziehbar. 6. Jede relevante Aktion erzeugt Audit. 7. Es gibt keine verdeckten Seiteneffekte. 8. Alle Entscheidungen bleiben reproduzierbar. 9. Keine direkte Providerkommunikation umgeht den Platform Core. 10. Runtime besitzt keine versteckten Zustände. 11. Jede Operation besitzt einen eigenen Runtime Context. 12. Verifikation bleibt von der technischen Ausführung getrennt. 13. Fehler, Recovery und Rollback bleiben einer Operation eindeutig zugeordnet. 14. Parallelität darf weder Zustände noch Auditspuren vermischen.

Beziehungen

Dieses Dokument steht in direkter Beziehung zu:

Beziehungen

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

Rolle als Laufzeitreferenz

Die Runtime Architecture vervollständigt die erste ORLENE Platform Architektur-Generation. Systemarchitektur, Bootstrap, Provider Architecture und Platform Register definieren einzelne Bausteine; dieses Dokument beschreibt deren Zusammenarbeit während des Betriebs.

Rolle als Laufzeitreferenz

Alle zukünftigen technischen Runtime-Komponenten müssen ihre Verantwortlichkeit, Kommunikation, Zustände, Ereignisse, Audit- und Reportbeziehungen gegen diese Referenz prüfen. Neue Komponenten dürfen ergänzt werden, ohne die festgelegte Trennung zwischen Platform Core, Capability, Provider und Host aufzulösen.

Offene Umsetzungspunkte

Dieses Dokument definiert Architektur, keine konkrete Runtime-Implementierung. Nach fachlicher Freigabe folgen getrennte Spezifikationen für Runtime Context, Ereignismodell, Statusautomat, Kommunikationsverträge, Parallelitätskontrolle, Monitoring und die Integration der bestehenden Platform Spaces.