Actualités

01netPro

Le framework OSGI

Conçu pour l'embarqué, le modèle de composants OSGI s'impose aussi dans les domaines applicatifs exigeant dynamisme et autonomie.

Philippe Davy

01 Informatique

le 05/01/2007 à 00h00

envoyer
par mail

imprimer
l'article

Jusqu'à la version 3.1 d'Eclipse, intégrer des modules ou les modifier obligeait à relancer l'application. Grâce à l'utilisation du framework OSGI (Open Ser-vices Gateway Initiative), Eclipse accepte désormais des modules “ à chaud ”, sans réinitialisation. Au départ, OSGI a été conçu pour des systèmes embarqués - par natu-re limités en termes de capacité mémoire ou de traitement - dans l'automobile, l'aé-ronautique, ou encore la téléphonie mobile. Mais ce framework dynamique open source a également montré ses qualités dans d'autres domaines exigeant un mécanisme d'intégration de composants fiable et auto-nome, comme les outils de développement ou les interfaces “ client riche ” (Eclipse, Eclipse RCP). Il sert aussi de fondement aux derniers développements à base de microservices des logiciels d'infrastructure de BEA, ou encore de JonAS, d'Objectweb.

Une évolution vers Java SE

Ces objectifs ont présidé à la création de la JSR 8, l'un des premiers groupe de travail du JCP (Java Community Process). Ils ont ensuite été transférés, en 1999, à l'OSGI, un consortium comprenant une qua-rantaine de membres originels (Sun, IBM, et Ericsson) ou plus récents (Oracle, Nokia, NTT, Intel, etc.). Aujourd'hui en version 4, les spécifications définissent les services de base du framework, son annuaire de services, ainsi que les règles de gestion du cycle de vie des applications, ou “ bundles ”. Il existe plusieurs implémen-tations libres (Knoplerfish, Equinox, Apache Felix). A terme, ces spécifications seront utilisées au sein de la plate-forme Java SE (Standard Edition) pour définir le modèle de composants dynamiques (JSR 291).

p.davy@01informatique.presse.fr

Une gestion dynamique des composants

OSGI inclut un grand nombre de services destinés à l'administrateur (interface d'ad-ministration des applications, gestion de configurations, d'événements, du déploie-ment, etc.). Ces services ciblent aussi les modules eux-mêmes (gestion des préférences, entrées/sorties, journalisation, etc.) ou la détection d'équipements (fonctions plug and play). Des interfaces vers des systèmes extérieurs sont également prévues : HTTP (avec un moteur de servlets), Universal Plug and Play, et DMT (Device Management Tree).

Le choix de Java remonte à la création d'OSGI, en 1999. La JVM et les caractéristiques du langage interdisent certaines pratiques dangereuses en termes de programmation de systèmes dynamiques (pointeurs, dépassement de buffer, etc.). Mais, aujourd'hui,. Net propose des attributs similaires. Donc, bien qu'il ne soit pas le fruit d'un processus ouvert, il apparaît comme un candidat possible.

L'annuaire rend les services et leur état “ visibles ” pour les applications. Il sert aussi à gérer les dépendances lors de l'initialisation ou de l'arrêt d'une application. Par ce biais, les composants sont notifiés à la volée du changement d'état d'un composant et du système, ou de la mise à disposition d'un nouveau service par une application qui démarre.

Les applications sont des archives Java (JAR) qui accèdent aux services du conteneur OSGI. Elles sont partagées pour garantir le maximum de dynamisme et une gestion optimum de la mémoire. Leurs services sont donc utilisables par des composants de la plate-forme, mais aussi à l'extérieur. C'est le framework qui gère de façon déterministe les conflits de dépendance et de gestion des versions (plusieurs “ bundles ” pouvant nécessiter plusieurs versions d'une même archive).