Architekturüberblick #

Diese Seite ist die Landkarte einer Exponential-Installation für Ingenieure: welche Schicht was tut, wo sie auf der Festplatte liegt und welche Architekturentscheidungen alles andere prägen. Die maßgebliche Beschreibung, mit einer Regel für jeden Baustein, ist Kernel-Architektur; diese Seite fasst sie zusammen und ergänzt die Begründungen.

Inhalt #

1. Die Schichten
2. Der Verzeichnisaufbau
3. Fünf Architekturentscheidungen
4. Wo Zustand liegt
5. Was die Architektur nicht hat

Die Schichten #

 Browser / CLI / cron
        |
 Server: Apache or nginx + PHP-FPM  |  Velocity (qbix)  |  FrankenPHP
        |
 Entry points: index.php  /  bin/php/console  /  runcronjobs.php
        |
 Kernel: ezpKernel -> ezpKernelWeb   settings -> extensions -> siteaccess -> session -> module
        |
 Modules and views: eZModule::run() -> view class  (kernel/<module>/, extensions)
        |
 Domain: kernel/classes  (content, users, roles, datatypes, workflows, caches)
        |
 Libraries: lib/ezdb (eZDB), lib/eztemplate (eZTemplate), lib/ezutils (eZINI, eZSys, ...)

Der Verzeichnisaufbau #

Aus dem Installationsbuch (1.2 Die Teile einer Installation):

kernel/, lib/      the kernel: modules, classes, the template engine, the database layer
autoload/          the kernel's class map (autoload/ezp_kernel.php)
extension/         extensions: your application lives here
design/            designs: templates, stylesheets, images
settings/          shipped settings; settings/siteaccess/ and settings/override/ hold yours
var/               runtime: caches, logs, storage, the SQLite database
bin/php/console    one entry point for every command
cronjobs/          the scripts runcronjobs.php runs
index.php          the front controller

Fünf Architekturentscheidungen #

1. Ein Front-Controller, eine Weiterleitungsschleife. Jede Webanfrage läuft über index.php und ezpKernelWeb::run(); für normale Seiten gibt es keinen zweiten Web-Einstiegspunkt. Besondere Einstiegspunkte gibt es für REST (index_rest.php), das Baummenü (index_treemenu.php) und die Auslieferung von Dateien im Cluster (index_cluster.php).
2. Der Siteaccess ist die Einheit der Konfiguration. Ein Siteaccess ist eine benannte Konfiguration, die je Anfrage gewählt wird (eine Website, die Administration, eine Sprache); die meisten Verhaltensunterschiede sind Einstellungen, kein Code (Siteaccesses und Konfiguration).
3. Alles Austauschbare wird in Einstellungen benannt. Module, Datentypen, Workflow-Events, Template-Operatoren, Cronjob-Teile, Benachrichtigungs-Handler, Login-Handler und Cluster-Datei-Handler werden über INI-Listen gefunden; eine Erweiterung klinkt sich also ein, indem sie eine Klasse und eine Datei .ini.append.php mitliefert (Events, Erweiterungspunkte und Plugins).
4. Ein zur Laufzeit festgelegtes Inhaltsmodell. Inhaltsklassen sind Daten, kein Code: Administratoren fügen Klassen und Attribute ohne Bereitstellung hinzu, und Datentypen geben jedem Attribut Speicherung, Prüfung und Templates (Das Inhaltsmodell für Ingenieure).
5. Alle Cache-Dateien über den Cluster-Datei-Handler. Caches werden über eZClusterFileHandler geschrieben, sodass derselbe Code auf einer Festplatte oder auf gemeinsamem Speicher für mehrere Webknoten läuft (Skalierung und Clustering).

Wo Zustand liegt #

Was die Architektur nicht hat #

• Keinen eigenen Dependency-Injection-Container. Klassen werden über die Klassenzuordnung und Einstellungen gefunden; Singletons wie eZINI::instance() und eZDB::instance() sind die Regel. Läuft der Kernel innerhalb von Symfony, geben ezpKernel::hasServiceContainer() und getServiceContainer() Zugriff auf den Container von Symfony.
• Upgrade-Schritte und Migrationen, von der Konsole. Datenbankaktualisierungen des Kernels und der Erweiterungen sind Upgrade-Schritte, die exp:upgrade anwendet und festhält; die eigenen Änderungen einer Site sind Migrationen, die exp:migration:migrate der Reihe nach ausführt und in exp_migration festhält (Schemaänderungen und Migrationen, Migrationen).
• Keinen Message-Broker im Kernel. Hintergrundarbeit läuft als Cronjob-Teile, Inhaltsjobs und über die Erweiterung expqueue (Konsole, Cronjobs und Hintergrundarbeit).
• Kein Symfony im Kernel. Die Produkte der Symfony-Plattform betten den Kernel über die Legacy Bridge ein (Symfony und die Legacy Bridge).

Verwandte Seiten #

• Der Lebenszyklus einer Anfrage
• Kernel, lib und Erweiterungen: die Schichtung
• Architektur für Anwendungsentwickler
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.