La plateforme OSGi

L'Alliance OSGi™ a été fondée en mars 1999. Elle propose des standards pour les services internet à destination des maisons, voitures, téléphones mobiles, ordinateurs de bureau, PMI-PME et d'autres environnements. Ses propositions sont concrétisées sous la forme de spécifications ouvertes pour la livraison de services sur des réseaux locaux, ces services peuvent être gérés et délivrés à distance via l'utilisation de tout type de réseau.

La spécification de la plateforme OSGi [OSGi 2009] propose une architecture commune et ouverte pour les fournisseurs de services, les développeurs, les éditeurs de logiciels, les opérateurs de passerelles (par exemple, les décodeurs satellites) et les fabricants de telles passerelles, afin que tous puissent développer, déployer et gérer des services de manière cohérente.

L'environnement d'exécution (c'est-à-dire le framework) est le noyau de la spécification de la plateforme OSGi. Cet environnement d'exécution est destiné à un usage général. Il a pour caractéristiques d'être basé sur la technologie Java, ainsi que d'être géré et sécurisé. Il supporte aussi le déploiement (local et à distance) de bundles.

Les bundles peuvent avoir deux types de dépendances, des dépendances au niveau package (au sens package Java) et des dépendances de services via la spécification d'un ou plusieurs services requis (par le biais d'une ou plusieurs interfaces Java). La plateforme OSGi offre des mécanismes qui permettent de connaitre l'état de résolution (satisfaction) de ces dépendances. De plus, la spécification OSGi présente les bundles comme des applications extensibles.

La plateforme OSGi offre, au développeur de bundle, les ressources et les points d'entrée suffisants pour tirer parti, d'une part, de l'indépendance qui est donnée vis-à-vis de la plateforme Java (JVM) et, d'autre part, de la capacité de chargement dynamique de code (c'est-à-dire de classes) de la plateforme OSGi. Ces deux propriétés permettent de développer des services pour des passerelles relevant du domaine de l'embarqué/réactif. De telles passerelles sont massivement répandues, par exemple, les décodeurs satellites dans les maisons, ou les ordinateurs de bords dans des voitures, typiquement, le 4x4 X5 de BMW embarque une plateforme OSGi.

Les fonctionnalités de la plateforme OSGi sont réparties selon plusieurs couches: • la couche sécurité (Security Layer),

• la couche bundle (Module Layer),

• la couche concernant le cycle de vie des bundles (Life Cycle Layer) • et enfin, la couche service (Service Layer).

Une vue globale de la plateforme à service OSGi sur une passerelle générique est présentée dans la figure ci-dessous.

742 2

5.2.2 La plateforme OSGi

La couche sécurité est une couche qui est transverse aux différentes couches de la plateforme OSGi et qui est optionnelle. Elle est basée sur l'architecture Java 2 Security. Elle offre une infrastructure pour déployer et gérer des bundles OSGi qui doivent s'exécuter dans des environnements sécurisés à grain-fin. Les possibilités concernant la sécurité vont jusqu'au niveau applicatif.

La couche bundle définit son propre modèle de modularisation au-dessus de la technologie Java. Cette couche possède des règles strictes concernant le partage de packages Java entre bundles et la mise à disposition de packages Java internes à un bundle.

La couche cycle de vie définit le cycle de vie des bundles. Elle offre aussi une API permettant de gérer effectivement le cycle de vie de chaque bundle. Cette API définit un modèle d'exécution pour les bundles. Ce modèle d'exécution définit le déploiement des bundles. Les activités de déploiement qui sont couvertes sont l'installation, l'activation, la désactivation, la mise à jour statique et la désinstallation. Ces activités correspondent respectivement aux commandes: install, start, stop, update et uninstall.

Enfin, la couche service d'OSGi fournit les mécanismes liés à l'approche à service. Elle définit un modèle de programmation dynamique pour les développeurs de bundle. Ce modèle simplifie le développement et le déploiement de bundles orientés service en découplant le contrat des services de leur implémentation. Dans OSGi, le contrat d'un service est un contrat de niveau 1 (concrètement, c'est une interface Java), l'implémentation d'un service est, quant à elle, enfouie dans le bundle. Ce modèle permet aux développeurs de bundles de définir des fournisseurs de services et des demandeurs de services. Les demandeurs définissent implicitement des dépendances sur des contrats de services. Lors de son activation, chaque bundle cherche à résoudre ces dépendances de contrats de services, cette résolution se fait dans le cadre fixé par le patron SOA. Une fois qu'une dépendance est résolue, le demandeur et le fournisseur du contrat de service entrent en interaction. Il est intéressant de noter qu'un demandeur de service qui s'est lié avec un fournisseur de service pourra tout à fait en changer tout au long de son exécution et cela selon sa propre politique, par exemple, lors de l'apparition d'un nouveau fournisseur de service ou encore si le fournisseur actuellement choisit vient à ne plus être disponible. Enfin, il faut noter que lorsqu'un bundle requérant un service vient à être activé et qu'il cherche un fournisseur pour ce service (afin de satisfaire son requis de service), il ne sait pas par avance avec quel fournisseur de service (c'est-à-dire bundle, ou plus précisément, implémentation de service) il

va interagir. En effet, les dépendances de service d'un bundle sont définies dès son développement, mais le réel ensemble de bundles interagissant n'apparait que lors de l'exécution effective de chaque bundle, en fonction des bundles déployés dans la même plateforme à service et de la stratégie de sélection qu'il leur applique.

L'environnement d'exécution OSGi autorise un bundle à choisir les implémentations de services correspondant à ses requis de services et cela aussi bien au cours de son activation, qu'à l'exécution (c'est à- dire une fois que le bundle est activé). Ce choix s'effectue en suivant le patron SOA, c'est-à-dire en utilisant le registre de service de l'environnement d'exécution OSGi. Ainsi, les bundles activés peuvent enregistrer leurs propres fournisseurs de services, recevoir des notifications à propos de tous les fournisseurs de services présents dans le registre de services. Ils peuvent aussi chercher des fournisseurs de services dans le registre de service, récupérer ceux qui leur conviennent et relâcher ceux qui ne leur conviennent plus. Cet aspect de l'environnement d'exécution OSGi permet aux bundles déployés de s'adapter au contexte dans lequel ils se trouvent. De plus, cette faculté d'adaptation ne nécessite pas la réactivation (c'est-à-dire la désactivation puis l'activation), ni de l'environnement d'exécution, ni du bundle embarquant les demandeurs de services. Par opposition, la mise à jour statique d'un bundle nécessite, quant à elle, la désactivation du bundle, sa désinstallation, l'installation et optionnellement l'activation du "nouveau" bundle (ces quatre activités peuvent être enchainées dans l'ordre présenté ici, mais aussi selon d'autres ordres).

Comme nous l'avons vu, OSGi introduit le concept de bundle. Un bundle est une entité logicielle qui contient des classes, mais aussi des ressources (par exemple, des fichiers images, des sons), ainsi qu'un ensemble de métadonnées sous la forme d'un fichier nommé manifest.mf. De même, un bundle peut être le fournisseur de zéro, un ou plusieurs services et le demandeur de zéro, un ou plusieurs services. Il est enfin important de noter que le bundle est l'unité de déploiement en OSGi.

762 2

La figure ci-après, présente le méta-modèle des bundles OSGi du point de vue des entités logicielles et non du point de vue descriptif (c'est-à-dire du point de vue des contrats de services, par exemple).

Figure 3.10. Méta-modèle des Bundles OSGi (du point de vue entité logicielle). Le registre de service OSGi peut contenir plusieurs "Services OSGi fournis" implémentant la même "Interface de service fournie". Ainsi, plusieurs bundles OSGi peuvent offrir la même interface par le biais de services qui leur sont propres.