Le framework OSGI

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

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 Services 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 nature 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 autonome, 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 quarantaine 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émentations 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).

Une gestion dynamique des composants

1. Le framework
OSGI inclut un grand nombre de services destinés à l'administrateur (interface d'administration 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).

2. La machine virtuelle
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.

3. L'annuaire de services
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.

4. Les composants et leur cycle de vie
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).