Spécification de conteneur Blueprint OSGi

La spécification de conteneur Blueprint OSGi définit une infrastructure d'injection de dépendance pour OSGi, dérivée du projet de modules dynamiques Spring. Elle définit un modèle de composant pour OSGi reposant sur l'infrastructure Spring de base dans laquelle un bundle OSGi est étendu par un plan directeur de module. Un plan directeur de module est un fichier de configuration qui décrit comment les composants à granularité fine sont connectés dans le bundle. Pour plus d'informations sur la spécification de conteneur Blueprint OSGi, voir la spécification Compendium sur le site Web OSGi Alliance.

Les composants de module sont gérés par un conteneur de contexte de module, qui est un équivalent direct du conteneur de contexte d'application String qui injecte des dépendances configurés dans les composants et gère leur cycle de vie. Le format du plan directeur de module repose sur le fichier de configuration d'application Spring. La plus grande différence avec l'infrastructure Spring est l'unité de déploiement, appelée bundle OSGi, et l'intégration au registre de services OSGi via le plan directeur de module. Les services OSGi qui sont exposés aux clients du bundle et les services OSGi qui sont consommés par le bundle sont déclarés dans le blueprint du module et enregistrés auprès du registre de services OSGi ou extraits du registre de services OSGi par le conteneur de contexte de module d'exécution.

Dans une application Blueprint, un composant de module est un composant Java™ dont le cycle de vie est géré par un conteneur de contexte de module. La configuration du composant de module inclut des références à des ressources et à des composants desquels il dépend. Le conteneur de contexte de module injecte la configuration dans le composant de module. L'injection de la configuration dans le composant, plutôt que la dépendance du composant à des services et des fabriques externes, facilite le test du composant isolé.

Un conteneur de contexte de module est un ensemble de composants gérés qui sont assemblés dans un bundle OSGi. Le contexte de module est en charge de la gestion du cycle de vie du composant géré qu'il contient et de l'injection des configurations de composant.

En savoir plus sur les concepts Blueprint OSGi :
La spécification de conteneur Blueprint OSGi définit les concepts suivants :
Composant géré
Un composant géré est un composant Java dont le cycle de vie est géré par un conteneur et dont la configuration, notamment les références aux ressources et les autres composants dont il dépend, est injectée par le conteneur. L'injection de la configuration dans le composant, plutôt que la dépendance du composant à des services et des fabriques externes, facilite le test du composant isolé.
Contexte de module
Un contexte de module est le conteneur d'un ensemble de composants gérés assemblés dans un bundle OSGi. Il est en charge de la gestion du cycle de vie de ses composants gérés et de l'injection de la configuration des composants. Cette terminologie est dérivée du conteneur de “contexte d'application” de l'infrastructure Spring et est un peu maladroite, notamment parce que la spécification Blueprint utilise le terme “contexte de module” comme raccourci aussi bien pour le “conteneur de contexte de module” que pour le “fichier de configuration de contexte de module”. Dans le modèle de programmation EBA, le terme de conteneur EBA est introduit et a le même sens que le conteneur de contexte de module.
Blueprint de module
Un blueprint de module est la configuration déclarative qui est associée à l'ensemble de composants gérés dans un bundle OSGi qui est traité par le conteneur de contexte de module. Dans la spécification Blueprint, un blueprint de module prend la forme d'un ou de plusieurs fichiers de configuration de contexte de module XML pour lesquels la spécification Blueprint définit un schéma XML extensible.
Bundle géré
Un bundle géré est un bundle OSGi qui contient un blueprint de module décrivant l'ensemble de composants gérés dans le bundle géré.

La configuration déclarative dans le blueprint de module peut aussi spécifier que certains composants gérés du bundle doivent être exportés comme services dans le registre de services OSGi. De plus, il est possible de déclarer que le composant géré d'un bundle dépend d'un service ou d'un ensemble de services qui sont obtenus par le biais du registre de services, et que ces services sont injectés dans le composant géré.

Globalement, la spécification de conteneur Blueprint OSGi décrit une architecture d'application dans laquelle des modules d'application sont implémentés en tant que bundles OSGi avec un blueprint de module (les informations de configuration) et un contexte d'exécution qui est créé à partir de ce blueprint. Les modules sont des homologues qui interagissent via le registre de services.

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 : cosgiblueprint.html