Liberty:Architektur

Liberty ist eine dynamische Laufzeitumgebung, die zahlreiche Kompositionsmöglichkeiten bietet. OSGi-Services werden verwendet, um die Lebenszyklen von Komponenten sowie die Injektion von Abhängigkeiten und Konfigurationen zu verwalten. Der Serverprozess setzt sich aus einer einzelnen JVM, dem Liberty-Kernel und einer beliebigen Anzahl optionaler Features zusammen. Der Feature-Code und der Großteil des Kernel-Codes werden als OSGi-Bundles in einem OSGi-Framework ausgeführt. Features stellen die Programmiermodelle und Services bereit, die von den Anwendungen benötigt werden.

Abbildung 1. Liberty-Architektur
die Laufzeitumgebung ist ein OSGi-Framework, das einen Kernel, eine JVM und eine beliebige Anzahl von Liberty-Features enthält.

Das Startprogramm des Kernels bootet das System und startet das OSGi-Framework. Die Konfiguration wird geparst und anschließend werden die konfigurierten Features vom Feature-Manager geladen. Zur Bereitstellung einer Laufzeitumgebung mit hoher Dynamik werden die OSGi-Services vom Kernel intensiv genutzt. Die Systemkonfiguration wird vom OSGi-Configuration-Admin-Service verwaltet und zur Verwaltung des Lebenszyklus von Systemservices wird die Komponente "OSGi Declarative Services" verwendet. Der Dateiüberwachungsservice erkennt Änderungen in Anwendungs- und Konfigurationsdateien und der Protokollierungsservice schreibt Nachrichten und Debuginformationen in das lokale Dateisystem.

Abbildung 2. Liberty-Kernel
Der Kernel enthält einen Feature-Manager, einen Dateimonitor, einen Protokollierungsservice und OSGi-Ressourcen für die Konfigurationsverwaltung und für die Arbeit mit deklarativen Services.

Features werden in den Systemkonfigurationsdateien, d. h. in der Datei server.xml und anderen eingeschlossenen Dateien, angegeben. Die Serverkonfigurationsdateien werden in den OSGi-Configuration-Admin-Service eingefügt, der dann die Injektion der Featurekonfiguration in den Feature-Manager-Service durchführt. Der Feature-Manager ordnet jeden Featurenamen einer Liste von Bundles zu, die das Feature bereitstellen. Die Bundles werden im OSGi-Framework installiert und gestartet. Der Feature-Manager reagiert auf Konfigurationsänderungen, indem er während der Ausführung des Servers Features dynamisch hinzufügt und entfernt.

Abbildung 3. Featureverwaltung
Der "OSGi Configuration Admin"-Service liest die Konfiguration aus der Datei "server.xml" und fügt die Featurekonfiguration in den Feature-Manager ein. Der Feature-Manager liest die Bundlelisten aus den Bundles, die jedes einzelne Feature bereitstellen, und installiert und startet diese Bundles dann im OSGi-Framework.

Laufzeitservices stellen Konfigurationsstandardeinstellungen bereit, sodass sich die Konfigurationsdaten, die Sie angeben müssen, auf ein Minimum beschränken. Sie geben die benötigten Features zusammen mit allen Zusatz- und Korrekturwerten für die Systemstandardeinstellungen in einer Datei mit dem Namen server.xml an. Sie können Ihre Konfiguration in mehrere separate Dateien aufteilen, die mit einer "include"-Syntax mit der übergeordneten Datei server.xml verknüpft werden. Beim Serverstart oder bei Änderung der Benutzerkonfigurationsdateien parst ie Kernelkonfigurationsverwaltung Ihre Konfiguration und überschreibt damit die Systemstandardeinstellungen. Der Satz von Konfigurationseigenschaften, der zu jedem Service gehört, wird bei jeder Aktualisierung der Konfiguration in den Service eingefügt.

Abbildung 4. Konfigurationsverwaltung
Der Konfigurationsadministrator liest die Standardkonfiguration aus Bundles im Kernel, überschreibt diese Standardkonfiguration mit der benutzerdefinierten Konfiguration und fügt dann die zusammengeführte Konfiguration in Feature-Bundles ein.

Die Komponente "OSGi Declarative Services" wird verwendet, damit Funktionen in diskrete Services zerlegt werden können, die nur bei Bedarf aktiviert werden. Auf diese Weise kann die Laufzeitumgebung "spät und träge" reagieren, was zu einem geringen Ressourcenverbrauch und schnellen Startzeiten führt. Deklarierte Services werden der OSGi-Service-Registry hinzugefügt und Abhängigkeiten zwischen Services können aufgelöst werden, ohne Implementierungsklassen zu laden. Die Serviceaktivierung kann so lange verzögert werden, bis ein Service wirklich verwendet wird, d. h., wenn die Servicereferenz aufgelöst wird. Die Konfiguration für jeden Service wird bei Aktivierung des Service eingefügt und bei späterer Änderung der Konfiguration erneut eingefügt.


Symbol das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 01.12.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwlp_arch
Dateiname: cwlp_arch.html