Architecture

Liberty est un environnement d'exécution dynamique et extrêmement modulable. Des services OSGi sont utilisés pour gérer le cycle de vie des composants ainsi que l'injection de dépendances et la configuration. Le processus du serveur comprend une machine virtuelle Java unique, le noyau Liberty et un certain nombre de fonctions facultatives. Le code de ces fonctions, ainsi que l'essentiel du code du noyau, sont exécutés en tant que bundles OSGi à l'intérieur d'une infrastructure OSGi. Les fonctions fournissent les modèles de programmation et les services requis par les applications.

Figure 1. Architecture Liberty
L'environnement d'exécution est une infrastructure OSGi qui contient un noyau, une machine virtuelle Java (JVM) et un certain nombre de fonctions Liberty.

Le lanceur du noyau amorce le système et démarre l'infrastructure OSGi. La configuration est analysée, puis les fonctions configurées sont chargées par le gestionnaire de fonctions. Le noyau utilise les services OSGi de façon intensive afin de mettre à disposition un environnement d'exécution très dynamique. Le service d'administration de la configuration OSGi gère la configuration du système et le composant Services déclaratifs OSGi gère le cycle de vie des services du système. Le service de surveillance des fichiers détecte les modifications apportées au fichier de configuration et à l'application, et le service de journalisation écrit des messages et des informations de débogage dans le système de fichiers local.

Figure 2. Noyau Liberty
Le noyau inclut un gestionnaire de dispositifs, un moniteur de fichiers, un service de journalisation et des ressources OSGi (administration de configuration et services déclaratifs).

Les fonctions sont spécifiées dans les fichiers de configuration du système, notamment le fichier server.xml et tout autre fichier inclus. Les fichiers de configuration du serveur alimentent le service d'administration de la configuration OSGi, qui injecte la configuration des fonctions dans le service de gestion des fonctions. Le gestionnaire de fonctions consulte la liste des bundles qui fournissent les fonctions proprement dites et la croise avec le nom de chaque fonction figurant dans la configuration. Les bundles résultants sont alors installés dans l'infrastructure OSGi et démarrés. Le gestionnaire de fonctions répond dynamiquement aux changements apportés à la configuration en ajoutant et en supprimant les fonctions adéquates alors même que le serveur est en cours d'exécution.

Figure 3. Gestion des fonctions
Le service d'administration de configuration OSGi lit le fichier server.xml et injecte la configuration des dispositifs dans le gestionnaire de dispositifs. Ce dernier compare les fonctions configurées à la liste des bundles qui fournissent les différentes fonctions, puis il installe et démarre les bundles requis dans l'infrastructure OSGi.

Les services d'exécution fournissent les paramètres de configuration par défaut pour que la configuration à spécifier soit minimale. Vous spécifiez les fonctions dont vous avez besoin ainsi que tout ajout ou remplacement concernant les paramètres par défaut du système dans un fichier server.xml. Vous pouvez choisir de structurer votre configuration en plusieurs fichiers distincts que vous liez au fichier parent server.xml avec une syntaxe "include". Au démarrage du serveur, ou lorsque vous modifiez les fichiers de configuration, la gestion de configuration du noyau analyse votre configuration et l'applique en remplaçant les paramètres par défaut du système. Le jeu de propriétés de configuration appartenant à chaque service est injecté dans le service en question chaque fois que la configuration est mise à jour.

Figure 4. Gestion de la configuration
Le service d'administration de configuration lit la configuration par défaut des bundles installés dans le noyau, applique la configuration spécifique de l'utilisateur par-dessus cette configuration par défaut et injecte la configuration résultante dans les bundles des fonctions

L'utilisation du composant Services déclaratifs (DS) OSGi a pour but de décomposer la fonctionnalité globale fournie par le serveur en services discrets, activés uniquement lorsqu'ils sont nécessaires. Ce comportement permet à l'environnement d'exécution d'être "tardif et différé", afin de conserver un encombrement réduit et d'assurer un démarrage rapide. Les services déclarés sont ajoutés au registre des services OSGi et les dépendances entre services peuvent être résolues sans charger les classes d'implémentation. L'activation d'un serveur peut être différée jusqu'à son utilisation, c'est-à-dire lorsque la référence de service est résolue. La configuration de chaque service est injectée au moment où le service est activé et elle est réinjectée si, plus tard, elle est modifiée.


Icône indiquant le type de rubrique Rubrique de concept

Nom du fichier : cwlp_arch.html