Architecture OSGi

La partie centrale d'OSGi Service Platform définit une plateforme de services sécurisée et gérée qui s'appuie sur Java™. Cette plateforme prend en charge le déploiement d'applications extensibles et téléchargeables appelées bundles. La spécification définit un modèle de sécurité, un modèle de gestion du cycle de vie des applications, un registre de services, un environnement d'exécution et des modules.

OSGi définit un système de modules dynamiques pour Java. La plateforme centrale OSGi Service Platform possède une architecture en couches et a été conçue pour s'exécuter sur différents profils Java standard. OSGi introduit la notion de bundle comme unité modulaire et l'architecture de la plateforme repose sur des bundles constituant l'unité de déploiement. L'architecture OSGi possède les couches suivantes :
Couche d'environnement d'exécution
Couche de modules
Couche de cycle de vie
Couche de registre de services
Pour plus d'informations sur l'architecture OSGi, voir la spécification de la plateforme centrale OSGi Service Platform.

Couche d'environnement d'exécution

La couche d'environnement d'exécution spécifie l'environnement Java (par exemple Java EE ou Java SE) dans lequel s'exécute un bundle. Pour les applications OSGi qui s'exécutent dans WebSphere® Application Server, il n'est pas nécessaire de spécifier l'environnement d'exécution.

Couche de modules

La couche de modules correspond à l'emplacement où l'infrastructure OSGi traite les aspects modulaires d'un bundle. Les métadonnées qui permettent àl'infrastructure OSGi de traiter le bundle sont définies dans un fichier manifeste de bundle.

L'un des avantages principaux d'OSGi est son modèle de chargeur de classe, qui utilise les métadonnées du fichier manifeste. OSGi ne possède pas de chemin d'accès aux classes global. Lorsque des bundles sont installés dans l'infrastructure OSGi, les métadonnées sont traitées par la couche de modules et les dépendances externes déclarées sont synchronisées avec les exportations versionnées déclarées par d'autres modules installés. L'infrastructure OSGi détermine les dépendances en utilisant le manifeste et calcule le chemin d'accès aux classes requis indépendant pour chaque bundle. Cette approche résout les problèmes de chargement de classe Java en s'assurant que les exigences suivantes sont respectées :
  • Seuls les packages qui sont exportés explicitement par un bundle particulier, par le biais des métadonnées, sont visibles des autres bundles pour l'importation.
  • Chaque package peut être résolu dans des versions spécifiques.
  • Plusieurs versions d'un package peuvent être disponibles en même temps que différents clients.

Couche de cycle de vie

La couche de gestion du cycle de vie des bundles dans OSGi élimine le problème lié au chargement des classes Java ainsi que l'exception signalant que la classe est introuvable lors de l'exécution, selon laquelle les classes dépendantes ne peuvent pas être chargées car elles sont introuvables. Lorsqu'un bundle installé est déployé dans l'infrastructure, cette dernière résout d'abord toutes ses dépendances déclarées. S'il existe des dépendances non résolues, l'infrastructure les signale et ne démarre pas le bundle.

Au cours du cycle de vie des bundles :
  • Les bundles sont dynamiques et peuvent être démarrés et arrêtés indépendamment du reste de l'infrastructure.
  • Chaque bundle peut fournir un activateur de bundle que l'infrastructure appelle lors des événements de démarrage et d'arrêt. L'activateur de bundle est déclaré dans le manifeste du bundle.

En général, les applications n'ont pas besoin de fournir un activateur de bundle. Toutefois, si l'initialisation est requise lorsque le bundle démarre ou s'arrête, un activateur de bundle peut être créé.

Couche de registre de services

La couche de registre de services dans OSGi prend en charge l'architecture orientée services (SOA) intrinsèquement. Les bundles publient les services dans le registre de services et d'autres bundles peuvent détecter ces services à partir du registre de services.

Ces services constituent la principale méthode collaboration entre les bundles. Un service OSGi est un objet POJO (Plain Old Java Object), publié dans le registre de services sous un ou plusieurs noms d'interface Java, avec des métadonnées facultatives stockées sous forme de propriétés personnalisées (paires nom-valeur). Un bundle de reconnaissance recherche un service dans le registre de services en fonction d'un nom d'interface, puis peut potentiellement filtrer les services à l'aide des propriétés personnalisées.

Les services sont intégralement dynamiques et ont généralement le même cycle de vie que le bundle qui les met à disposition.

Icône indiquant le type de rubrique Rubrique
Dispositions pour les centres de documentation | Commentaires en retour

Icône d'horodatage Dernière mise à jour: May 29, 2014 10:11

Nom de fichier : cosgiarchitecture.html