Jérôme Molière - Fnacmultimedia.fnac.com/multimedia/editorial/pdf/9782212133288.pdfBaird-Smith, est un Français de Grenoble. S’il a quitté le projet quelques mois après, il

J é r ô m e M o l i è r e

Préface de Peter Kriens

OSGiConception d’applications

modulaires en Java

© Groupe Eyrolles, 2012, ISBN : 978-2-212-13328-8

Pour nous, qui venons du Nord, la France méridionale a bien des attraits. La douceur duclimat, la bonne chère et le bon vin, les jolies femmes et les interactions sociales riches...Bref, tout un art de vivre ! Mon poste de Directeur technique chez OSGi m’a conduit àparcourir toute la planète, sans me laisser le loisir de séjourner trop longtemps en Suède.Malgré l’envie de températures plus douces, quitter la Suède n’a pas été un choix facileparce qu’elle est étrangement attachante, pour un pays si froid. Pourtant, en 2003, nousavons franchi le pas et emménagé dans un endroit magnifique, Beaulieu, dans la cam-pagne environnant Montpellier.

Parmi les choses qui m’ont manqué, les échanges avec mes collègues d’Ericsson et lesdéjeuners rituels dont je garde un très bon souvenir. En effet, toute attrayante que soit lacôte méditerranéenne, on n’y trouve que très peu de développeurs OSGi... Aussi fus-jestupéfait d’apprendre que l’un des conférenciers acceptés en 2009 à la conférence OSGiDevCon à Jazoon habitait à moins de 12 kilomètres de chez moi ! Je lui ai écrit pourproposer un déjeuner – quel rêve en effet que de tenir une discussion approfondie sur lesClassLoaders Java tout en jouissant des fruits de « La Campagne » ! C’est ainsi que j’airencontré Jérôme, qui m’a non seulement fait découvrir les meilleures frites du monde (àLansargues), mais est devenu un compagnon régulier du Bon Coin.

J’ai ainsi pu mesurer les efforts titanesques que demande l’écriture d’un livre. Au coursdes dix dernières années, j’ai été sollicité de nombreuses fois pour rédiger des ouvragessur la création logicielle, mais le travail est infernal, peu rémunéré et tout à fait sous-estimé. Je tire mon chapeau à tous les auteurs qui sont capables d’aller au bout d’une telleentreprise. En effet, il suffit au lecteur d’une minute sans effort pour parcourir un textequi a nécessité des heures muettes de dur labeur. Le processus de rédaction a confirmél’idée que je me faisais de ce travail ; je suis maintenant admiratif qu’il soit terminé.

Enfin un ouvrage en français sur OSGi ! Il était temps, après la parution d’un ouvrageen allemand, un en chinois et plusieurs en anglais, quand on sait que les racines d’OSGise situent en France et que cette norme y est assez populaire. J’y vois une sorte dereconnaissance !

Préface

OSGi.book Page V Wednesday, December 21, 2011 12:51 PM

OSGi – Conception d’applications modulaires en JavaVI

Lorsque nous avons démarré OSGi, nous sommes partis du JES (Java Embedded Server)de Sun comme structure de base pour nos spécifications. L’auteur de ce produit, AnselmBaird-Smith, est un Français de Grenoble. S’il a quitté le projet quelques mois après, iln’en demeure pas moins pour moi l’auteur original du cœur de la norme. Après dixannées passées à travailler sur son modèle, je reste béat d’admiration pour la simplicité etl’élégance du modèle OSGi original, et plus encore à présent que je réalise combien lespurs programmeurs Java ont de mal à appréhender la modularité et comme ils tendent àcréer un monstre dès qu’ils en ont la possibilité.

Certains lecteurs seront surpris qu’on puisse voir en OSGi une solution simple et élé-gante car des développeurs se plaisent à le dénigrer sur le Web en critiquant sa com-plexité. Mais quand on analyse ces attaques verbales, on se rend compte qu’ils repro-chent à l’outil de ne pas faire... ce pour quoi il n’est pas fait ! C’est que la modularité nes’utilise pas comme une bibliothèque qu’il n’y aurait qu’à ajouter dans son classpath... Lamodularité est une qualité de la structure de base de votre code. OSGi, lui, n’est qu’unmessager donnant l’alerte, lorsque votre code n’est pas modulaire.

Les mécontents d’OSGi ne se plaignent au fond que du fait que leurs hacks non modu-laires échouent dans un environnement OSGi !

Malheureusement, la plupart des bibliothèques les plus utilisées ne sont pas modulairesdans leur conception. Il faudrait, pour jouir des avantages de la modularité, un remanie-ment en profondeur (refactoring) afin d’aménager la communication entre modules.C’est ce que propose OSGi avec son modèle par micro-services et ses dépendances parpaquets : la solution la plus simple pour étendre Java de façon modulaire, sans toutefoisperdre une sûreté de typage à laquelle les développeurs Java sont attachés.

Pour comprendre OSGi, il faut être prêt à changer de paradigme, à penser différem-ment. Or, un tel changement est toujours mystérieux : avant l’épiphanie, tout sembleinutilement complexe et bruité. Mais une fois de l’autre côté, tout s’éclaire comme parmagie et la cause des problèmes entrevus auparavant devient péniblement évidente. J’enai fait l’expérience plusieurs fois dans ma vie, avec la programmation objet, la program-mation fonctionnelle (avec Prolog !), l’inversion de contrôle... non sans peiner à chaquefois. Pour pimenter le tout, impossible de franchir la distance sur de simples explica-tions, puisqu’on ne peut comprendre qu’à partir de ce qu’on sait déjà.

Voilà pourquoi ce livre est aussi important. Il offre une introduction pratique à OSGiavec de nombreux exemples, sans oublier d’en approfondir les aspects fondamentaux, àsavoir les dépendances de paquets et les micro-services. Lorsque vous en lirez les expli-cations, et en testerez les exemples, le chemin vous semblera ardu. Mais les leçons envalent la peine car elles vous donneront un précieux recul sur votre code, ainsi que sur lamanière de l’optimiser et de le rendre plus modulaire.

Peter Kriens

OSGi.book Page VI Wednesday, December 21, 2011 12:51 PM

Table des matières

Avant-propos ................................................................................. 1

CHAPITRE 1OSGi pour une conception modulaire.......................................... 3

OSGi, pour quelles applications ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Cas d’une automobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Cas d’un environnement de développement (IDE) . . . . . . . . . . . . . . . . . . . . . . 5Cas d’un serveur d’applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Problèmes liés au paquetage des applications J2EE . . . . . . . . . . . . . . . . . . . . . . . . 8Regrouper des bibliothèques au sein d’un conteneur OSGi . . . . . . . . . . . . . . . . . . 8Vers les architectures orientées services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Dépasser les limitations dues aux ClassLoader Java . . . . . . . . . . . . . . . . . . . . . . . 10Tour d’horizon de la norme OSGi et de ses services . . . . . . . . . . . . . . . . . . . . . . 14

Couplage et injection de dépendances ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Les bundles OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Les spécifications OSGi en détail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Implémentations OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

CHAPITRE 2Exemples d’applications modulaires basées sur OSGi ............. 19

OSGi comme socle architectural de serveur : JOnAS 5 . . . . . . . . . . . . . . . . . . . . 21Le shell OSGi sous JOnAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Un bref survol du code source de JOnAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

OSGi pour les applications embarquées : serve@home . . . . . . . . . . . . . . . . . . . . 29Le projet domotique serve@home de Siemens . . . . . . . . . . . . . . . . . . . . . . . . . 29OSGi dans les automobiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

CHAPITRE 3Mettre en place son premier bundle OSGi ................................ 31

Installation de bndtools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Création du projet et développement du bundle . . . . . . . . . . . . . . . . . . . . . . . . . 32

OSGi.book Page VII Wednesday, December 21, 2011 12:51 PM

OSGi – Conception d’applications modulaires en JavaVIII

Création du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Méta-informations nécessaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Bundles et bibliothèques Java utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39OSGi et chargement de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Encapsulation de la bibliothèque Commons Lang . . . . . . . . . . . . . . . . . . . . . . 40

Services OSGi par défaut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Publier son premier service OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Gestion du dynamisme avec le tracking de services . . . . . . . . . . . . . . . . . . . . . 50S’appuyer sur les services standards de la plate-forme . . . . . . . . . . . . . . . . . . . . 51

CHAPITRE 4Travailler avec OSGi : environnement et outils ........................ 55

Conteneurs OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Apache Felix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Le projet Knopflerfish . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56La console OSGi d’Eclipse : Equinox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Choisir sa console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Nécessité d’un référentiel de bundles : OBR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58OSGi et bundles : limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Vers un entrepôt commun de bundles avec OBR . . . . . . . . . . . . . . . . . . . . . . . 60Premier contact avec OBR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Architecture et dynamique d’appels avec OBR . . . . . . . . . . . . . . . . . . . . . . . . 63

Les plug-ins de développement Eclipse pour OSGi . . . . . . . . . . . . . . . . . . . . . . . 64Simplifier la création de bundles avec bnd . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Travailler avec bnd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Utiliser bndtools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66iPOJO : une autre approche du développement OSGi . . . . . . . . . . . . . . . . . . . 67PDE : l’environnement standard de développement de plug-in d’Eclipse . . . . . 67

CHAPITRE 5Le moteur d’injection de dépendances : la spécification Declarative Services.......................................... 69

Introduction à la déclaration de services dans OSGi . . . . . . . . . . . . . . . . . . . . . . 70Le SCR (Service Component Runtime) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Fonctionnalités proposées par le SCR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Activation immédiate ou retardée ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Principes pour la mise en œuvre de SCR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Exemple complet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Descriptif du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Entités en présence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

OSGi.book Page VIII Wednesday, December 21, 2011 12:51 PM

Table des matières IX

Application en utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77L’exemple vu du côté technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Code source et descripteurs de déploiement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Précisions sur le Declarative Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

CHAPITRE 6Services OSGi pour le développeur : LogService, EventAdmin, HttpService et ConfigAdmin................................ 87

Gestion des traces avec le LogService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Communication par messages avec l’EventAdmin . . . . . . . . . . . . . . . . . . . . . . . . 92

Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Fonctionnalités et limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Principales entités mises en jeu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Exemple de mise en œuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Exposer ses ressources sur le Web avec l’HttpService . . . . . . . . . . . . . . . . . . . . . . 98Service de configuration : le ConfigAdmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

CHAPITRE 7Modularité et tests unitaires.................................................... 109

Retour sur la notion de modularité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Du point de vue du chef de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Du point de vue du programmeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Du point de vue de l’architecte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Modularité et tests en environnement OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Les commandes du shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Tests en environnement OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Principe du test unitaire en environnement OSGi . . . . . . . . . . . . . . . . . . . . . 119Création de l’environnement d’exécution des tests unitaires . . . . . . . . . . . . . . 120

Mise en pratique : création d’un test case pour un service OSGi simple . . . . . 121Considérations avancées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Gestion des versions de composants en environnement OSGi . . . . . . . . . . . . . 125Qu’est-ce qu’une version d’un composant et d’une application ? . . . . . . . . . . 125La vision offerte par OSGi en matière de gestion de versions . . . . . . . . . . . . 126Adopter une numérotation cohérente et en tirer parti . . . . . . . . . . . . . . . . . . 127Gestion de la politique de numérotation des versions en pratique . . . . . . . . . 128

Ce qu’il faut retenir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

OSGi.book Page IX Wednesday, December 21, 2011 12:51 PM

OSGi – Conception d’applications modulaires en JavaX

CHAPITRE 8Design patterns OSGi et bonnes pratiques ............................. 129

Gabarits de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Séparation entre API et implémentations . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Le design pattern Factory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Le design pattern du tableau blanc ou Whiteboard . . . . . . . . . . . . . . . . . . . . 130

Comment fonctionne le WhiteBoard ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133Invocation dynamique de code dans le contexte OSGi . . . . . . . . . . . . . . . . . . 137

Exemple de situation : sérialisation/désérialisation de données avec Castor XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Mise en place pratique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Conseils et pièges à éviter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Shells OSGi et niveaux de démarrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Gestion de la problématique des versions . . . . . . . . . . . . . . . . . . . . . . . . . . . 146Injection de dépendances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146Maîtrise de la méta-information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

CHAPITRE 9Application exemple ................................................................. 149

L’application exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150Vue d’ensemble de l’architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150Notes relatives à la conception de l’application . . . . . . . . . . . . . . . . . . . . . . . 152

Création des PDF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152Planification de tâches en Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Quelques images du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154Notes relatives à l’implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Encapsulation d’une bibliothèque Java standard. . . . . . . . . . . . . . . . . . . . . . . 154Commandes du shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155Utilisation de Cron4J . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155Finalisation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Le code source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Planification de tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Encapsulation de SQLite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158Le DAO SQLite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159Descripteur de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Ce qu’il faut en retenir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

ANNEXE Mettre en place un bundle OSGi avec PDE .............................. 169

Index........................................................................................... 175

OSGi.book Page X Wednesday, December 21, 2011 12:51 PM

Depuis environ deux ans, de nombreux produits voient leurs architectures complète-ment modifiées pour adopter une conception conforme à la norme OSGi. Que peutapporter cette norme au développeur et concepteur ? Que propose-t-elle ? Quelmodèle et quels outils utiliser ?

Pourquoi ce livre ?Ce livre cherche à présenter en douceur la plate-forme OSGi, ainsi que l’environne-ment gravitant autour. Il comporte une section dédiée à l’outillage, ainsi qu’une sec-tion, plus rare en comparaison des ouvrages existants, consacrée aux aspects de con-ception en environnement OSGi.

Cet ouvrage ne tente pas d’entrer dans les arcanes d’un conteneur OSGi ni dedétailler chacun des aspects de la norme ; il se veut une introduction cohérente àcette technologie.

Pour aller plus loin dans la technique, l’auteur ne peut que chaudement conseiller lalecture de l’indispensable OSGi in Action paru chez Manning et cosigné parRichard S. Hall, un des meilleurs spécialistes d’OSGi.

Avant-propos

R Richard S. Hall, Karl Pauls et Stuart McCulloch, OSGi in Action, Manning, 2011

OSGi.book Page 1 Wednesday, December 21, 2011 12:51 PM

OSGi – Conception d’applications modulaires en Java2

À qui s’adresse ce livre ?Cet ouvrage s’adresse aux étudiants, ingénieurs, architectes et chefs de projets expéri-mentés en Java et qui s’intéressent aux problématiques de modularité, ou qui doivents’adapter à des contraintes liées au déploiement en environnement embarqué : déve-loppeurs JEE, développeurs RCP…

Structure du livreAprès avoir esquissé le contexte architectural actuel, nous présenterons la notion deservices propre au monde OSGi, puis nous aborderons la façon de travailler et depenser une application pour cette technologie. Enfin, nous illustrerons les conceptsévoqués sur un cas pratique simple.

RemerciementsL’auteur tient à remercier chaleureusement Peter Kriens, qui a toujours été à son écouteet a apporté des solutions sages et le plus souvent élégantes, tout en enrichissant sesréponses d’anecdotes croustillantes sur la face cachée d’une norme telle qu’OSGi. Il leremercie pour ses relectures précieuses, ainsi que Vincent Beretti et Christophe Peigné.

Il est naturel de remercier Karine Joly, Muriel Shan Sei Fan et Anne Bougnoux, letrio d’éditrices de choc ayant participé à la gestation puis à la finalisation de ce livre,ainsi que Sophie Hincelin, Anne-Lise Banéath et Gaël Thomas, qui ont œuvré avecminutie et efficacité lors des dernières étapes.

De plus, cet ouvrage n’aurait pas été possible sans la mission effectuée au sein deTelintrans.

Enfin, merci à ceux ayant subi les affres de la mauvaise humeur de l’auteur.

BIBLIOGRAPHIE

R R. S. Hall, K. Paul, S. McCullogh, OSGi in Action, Manning, 2011R E. Gamma et al., Design Patterns: Elements of Reusable Software Components, Addison Wesley, 1994R C. Beust, H. Suleiman, Next Generation Java Testing, Addison Wesley, 2007


OSGi, pour quelles applications ?Cette section examine quelques types d’applications contemporaines (automobile,environnement de développement, serveur d’applications) pour en extraire desbesoins techniques communs. Cette collecte nous amènera naturellement vers unevue d’ensemble de la plate-forme OSGi.

1OSGi

pour une conception modulaire

OSGi (autrefois Open Services Gateway Initiative) est le nom d’une plate-forme orientée,à l’origine, vers l’embarqué, et dédiée à la gestion d’applications extrêmement configurableset dynamiques dans un environnement à une seule machine virtuelle Java. Ce premierchapitre a pour but de placer la plate-forme OSGi dans le contexte des applicationsmodernes, de manière à justifier son utilisation dans des conditions a priori opposées : del’application embarquée jusqu’au serveur d’applications. Il présente enfin les spécificationsd’OSGi et les services qu’elle prévoit.



Cas d’une automobileObjet de la vie de tous les jours, une voiture récente est un véritable écosystèmed’applications informatiques, pour peu qu’elle dispose d’équipements du type :• ABS (antiblocage de sécurité, système empêchant le blocage des roues en cas de

freinage violent), dispositif nécessitant un logiciel à même de contrôler diversparamètres comme l’intensité du freinage, la vitesse, éventuellement le type derevêtement, etc. ;

• ESP (Electronic Stability Program, système de lutte contre le patinage, qui réduitle couple moteur dans certaines conditions de circulation où l’adhérence est pro-blématique), dispositif qui requiert une application contrôlant le régime moteuren fonction d’un algorithme collectant ses entrées par le biais de capteurs ;

• lecteur CD ou MP3/DivX ;• gestionnaire d’air conditionné ;• etc.

Il existe ainsi des dizaines d’applications disséminées dans une automobile. Cetexemple nous donne l’occasion de formuler quelques remarques.

Tout d’abord, ces applications sont nombreuses et doivent cohabiter dans le mêmeenvironnement, même si elles ne sont pas toutes du même niveau de criticité.

En outre, elles ont des cycles de vie fort distincts, puisque certaines sont résidentes(du démarrage jusqu’à l’arrêt du véhicule), alors que d’autres peuvent n’être effectivesque pour quelques secondes.

Quant à l’environnement d’exécution, il est nécessairement cloisonné, de manière àne pas voir une application critique tomber sous prétexte qu’une application d’impor-tance moindre a provoqué des erreurs.

Enfin, ces applications forment un véritable microcosme et interagissent. En effet, plu-sieurs applications peuvent demander une modification du régime moteur, sans pourautant que le code correspondant soit dupliqué. Elles vont donc toutes s’adresser à unemême application fournissant le service d’augmentation ou diminution du régime.

Pour citer Peter Kriens, le chantre d’OSGi, il est amusant de noter qu’un simple lecteur DivX représente lemême nombre de lignes de code que l’informatique d’un programme spatial des années 1960, tandis quel’on constate que le volume du code à l’échelle planétaire double tous les 7 ans.


OSGi pour une conception modulaireCHAPITRE 1

5

Cas d’un environnement de développement (IDE)Quels sont les services attendus par un utilisateur d’IDE (Integrated DevelopmentEnvironment) ? Ils sont fort variés, même si en premier lieu, on s’attend à trouver desfacilités pour :• l’édition du code dans un langage donné ;• le débogage de code ;• le pilotage de l’exécution et du déploiement de nos applications.

Outre ces besoins courants, on peut rechercher une intégration avec des serveursd’applications dans le monde Java, avec Apache dans le monde PHP. On peut avoirbesoin d’outils de visualisation de traces, de consoles permettant un accès SSH(Secure Shell) vers un serveur, etc.

Comme il est impossible de dresser une liste exhaustive de ces besoins, l’architecturede tels produits doit donc prévoir un socle générique offrant diverses facilités trans-verses. En enrichissant les fonctionnalités de ce socle par l’ajout de greffons, onaboutit à l’idée de plug-ins présente dans Eclipse, ou encore à celle de modules dans lecadre de l’architecture NetBeans. Un IDE récent doit donc offrir un large éventaild’extensions et un cadre de développement de ces extensions de manière à couvrir denombreux besoins distincts.

Les figures 1-1 à 1-4 montrent les contenus des répertoires d’extensions fournis avecles deux environnements majeurs de développement du monde Java : NetBeans etEclipse. Ce dernier ne comporte pas moins de 583 plug-ins, alors que NetBeanscouvre sensiblement le même spectre de fonctionnalités avec tout de même

Figure 1–1Contenu du répertoire plugins pour Eclipse/Ganymede orienté J2EE



40 modules (la granularité des modules NetBeans n’est pas exactement comparable àcelle d’un plug-in ou bundle dans Eclipse) !

Évidemment, une telle profusion de besoins s’accompagne, parfois pour ces produits,de la nécessité de fonctionner sur des machines n’étant pas des bêtes de course. Il estdonc impératif que l’architecture des IDE récents permette un chargement à lademande des extensions, afin de laisser disponible un volume maximal de mémoirepour un fonctionnement raisonnable du programme.

Figure 1–2Contenu du répertoire modules de NetBeans 6.5

Figure 1–3Nombre de modules dans un NetBeans 6.5/All

Figure 1–4Nombre de plug-ins dans Eclipse Ganymede JEE5 sous Linux



7

Cas d’un serveur d’applicationsUn tel serveur est un hôte pour vos applications ; il met à leur disposition diversesressources : • pool de connexions JDBC par le biais de DataSource JDBC ;• annuaires LDAP par le biais de JNDI ;• autres ERP par le biais de connecteurs JCA…

Le serveur fournit également des services techniques :• sécurité avec JAAS ;• persistance avec JPA ;• transactions par JTA.

Les applications ainsi hébergées vont utiliser des bibliothèques Java et se doivent dedisposer d’un taux de disponibilité maximal. Rationaliser leur utilisation, en évitantun chargement multiple de la même bibliothèque au gré des humeurs des déve-loppeurs créant les paquetages, rend plus robuste l’ensemble des applications.

Enfin, une autre fonctionnalité est souvent désirée concernant un serveurd’applications : le fait de pouvoir exposer diverses versions de la même application –chose impossible jusque récemment.

DÉFINITION Lazy loading : le chargement à la demande

Cette stratégie de chargement est opposée à une politique plus brutale, consistant à charger tout audémarrage. On retrouve ces noms de politiques dans des produits comme Hibernate. Il est logique dedésactiver les ressources requises pour travailler en PHP quand on se prépare à travailler sur un serveurde sources Subversion, par exemple. Évidemment, cette stratégie impose de nombreux accès au disque ;tout avantage a sa contrepartie.

EN CLAIR

JDBC Java DataBase Connectivity

LDAP Lightweight Directory Access Protocol : protocole de gestion d’annuaires de réseau

JNDI Java Naming and Directory Interface : extension Java pour l’accès aux services d’annuaire

ERP Enterprise Resources Planning : progiciel de gestion d’entreprise

JCA J2EE Connector Architecture : interface d’accès aux applications Java

JAAS Java Authentification and Authorization Service

JPA Java Persistence API

JTA Java Transaction API



Problèmes liés au paquetage des applications J2EEAprès avoir effectué des dizaines d’audits d’applications J2EE déployées sousTomcat, JBoss, JOnAS ou WebLogic, il m’est possible de désigner la mise en paque-tage d’une application comme un facteur de fortes perturbations pour la stabilité d’unserveur. Ainsi, du bytecode inutile empaqueté en archives .jar influera sur la taillede la zone de la mémoire Java connue sous le nom de PermGen, zone contenantprincipalement le bytecode Java (mais aussi les interns propres aux instances dejava.lang.String pour les JVM antérieures à la version 1.7).

Fréquemment négligé, cet aspect induit de nombreux problèmes liés au paramétragedu ramasse-miettes (garbage collector) si l’on déploie des archives ( JAR) contenantbeaucoup de bibliothèques inutiles. La zone dénommée PermGen se trouvant favoriséepar nécessité, les zones destinées aux objets à durée de vie moindre sont donc réduites.Cela induit de sévères risques lors de la phase d’exécution de l’application en forçantdes promotions non désirables et en entraînant la multiplication de passages plus labo-rieux du ramasse-miettes en mode full (avec scan des zones de la hcap).

Regrouper des bibliothèques au sein d’un conteneur OSGiSi vous encapsulez vos bibliothèques en tant que bundles OSGi (donc versionnés) et sivous énoncez vos dépendances sous forme de clauses import-paquetage, vous permet-trez au conteneur OSGi de réellement partager les dépendances usuelles et donc d’éco-nomiser des ressources. En même temps, cela permet de gérer aisément le cas où deuxbundles utilisent deux versions différentes de la même bibliothèque – puisque chaquebundle OSGi se voit isolé dans son propre ClassLoader.

EN CLAIR

JVM Java Virtual Machine

JAR Java ARchive

VOCABULAIRE Première définition du « bundle »

Ce terme sera expliqué longuement par la suite ; il suffit pour l’instant de présenter un bundle commeétant l’unité de déploiement atomique au sein d’OSGi. Un bundle, archive .jar enrichie de méta-infor-mations, est donc un module au sein de votre application.



9

L’informatique d’aujourd’hui est complexe, s’appuie sur de nombreux composantsqui doivent interagir sans pour autant être trop couplés, au risque de voir la mainte-nance évolutive des applications se transformer en cauchemar. Il est crucial d’envi-sager les relations entre composants comme un véritable dialogue client/serveur ouencore client/fournisseur.

Cette approche nous oblige à nous centrer sur les services requis pour le fonctionne-ment d’un composant, ainsi que sur les services qu’il offre à l’extérieur. Nous nousplaçons dans une optique résolument tournée vers le SOA (Services Oriented Architec-ture, architecture orientée service), où l’important est de voir notre demande de ser-vice aboutir, sans s’occuper de qui l’a honorée, ni de comment (par quelle implémen-tation ou quel code) cette requête a abouti.

Vers les architectures orientées servicesLa SOA véhicule l’idée que le seul moyen de maîtriser une application le long de soncycle de vie est de faire en sorte d’en maîtriser le couplage. Cela demande d’attendrede nos applications qu’elles présument le minimum de choses possibles quant auxcomposants externes utilisés. Ainsi, éviter un couplage fort avec une version spéci-fique de Log4J ou avec un parseur XML permet d’intégrer facilement les bénéficesapportés par une version ultérieure de ce produit.

Comment arriver à un tel découplage ? En manipulant des API (versionnées) et enréclamant pour nos composants que leur environnement d’exécution leur fournisseune version compatible avec nos exigences.

N’entrons pas pour l’instant dans la mise en pratique concrète – il faudra pour celaattendre le chapitre 3 – mais concentrons-nous sur les concepts. À ce stade, nousdevons repenser nos composants de manière à isoler clairement, pour chacun d’eux,trois parties :• l’API publique exposée aux autres, à savoir ce que les autres pourront utiliser ;• les API externes utilisées ;• l’implémentation, devant rester totalement opaque vis-à-vis du monde extérieur.

Ceci va se traduire formellement par une représentation du composant utilisant lessymboles suivants :• un arc de cercle pour désigner un service proposé à l’extérieur (aux autres

composants) ;• un trait terminé par un point pour désigner un service extérieur requis par le com-

posant.



La figure 1-5 montre comment un composant A propose un service utilisé par uncomposant B, tout en utilisant un service offert par un composant C.

Dépasser les limitations dues aux ClassLoader JavaJava s’appuie sur la notion de chargeur de classes (ClassLoader), de manière à rendrepossible le chargement de classes par le réseau, en base de données ou par n’importequel autre flux. Il n’y a pas, au sens strict du terme, un seul ClassLoader, mais plutôt

Figure 1–5Un composant A propose un service utilisé par le composant B tout en utilisant un service proposé par le composant C.

SOA XML et déploiement

Dans la littérature, on parle de SOA en sous-entendant l’utilisation de flux XML et de services web, ens’appuyant sur des briques logicielles orchestrant les dialogues entre applications (EAI, Enterprise Appli-cation Integration) comme ceux proposés par la norme JBI (Java Business Integration). Ici, on s’intéresse plutôt à l’idée architecturale de découplage, de responsabilités de tâches (microservi-ces), en faisant fi de l’aspect déploiement sur des machines, middleware et protocolaire. Notez qu’il n’y a pas d’équivalence stricte entre bundle et service (microservice). En effet, un bundle peutlégitimement fournir plusieurs services à la plate-forme tandis qu’un même service pourra être déployéplusieurs fois (en diverses versions ou en diverses implémentations fournissant toutes la même versiondu paquetage correspondant à ce service). Le chapitre 6 sera dédié à cette notion de services dans lanorme OSGi, donc n’anticipons pas trop...

EN CLAIR

SOA Service Oriented Architecture

EAI Enterprise Application Integration

JBI Java Business Integration



11

une hiérarchie de ClassLoaders, chacun responsable du chargement d’une partie desclasses nécessaires à une application.

Il est possible de développer ses propres chargeurs de classes répondant à tel ou telbesoin précis. Des applications comme JBoss ou Tomcat, avec leurs besoins de redé-ploiement à chaud, utilisent évidemment cette possibilité. Ainsi, dans JBoss, c’est parle biais de la création d’un tel ClassLoader (UnifiedClassLoader) que des possibi-lités comme le démarrage par le réseau étaient possibles.

La figure 1-6 montre l’organisation des ClassLoaders dans une application standard,en associant pour chaque niveau les classes concernées. La stratégie de délégation parle parent en premier a un certain nombre d’avantages, mais présente aussi son lot dedésagréments.

La figure 1-7 détaille la séquence propre à toute implémentation d’un ClassLoaderspécifique.

On peut imaginer différents moyens de stocker le code compilé correspondant à desclasses Java avec notamment les cas de figure suivants :• un serveur TCP type serveur web ou FTP ;• une base de données qui permet avec des champs de type BLOB de stocker du

binaire pur ;• un système de fichiers.

Figure 1–6Organisation des ClassLoaders dans une application standard



Exemple simpliste d’un ClassLoader chargeant des classes depuis un système de fichiers

Figure 1–7Séquence propre à toute implémentation d’un ClassLoader spécifique

import java.io.*; import java.net.*; import java.util.*; public class FileClassLoader extends ClassLoader { private String root; public FileClassLoader (String rootDir) { if (rootDir == null) throw new IllegalArgumentException ("Ne peut charger de classes depuis un répertoire nul !!!"); root = rootDir; } /** implémentation de loadClass() renvoie une instance de java.lang.Class ou lève une ClassNotFoundException */ protected Class loadClass (String name, boolean resolve) throws ClassNotFoundException { Class c = findLoadedClass (name); if (c == null) { try {



13

c = findSystemClass (name); } catch (Exception e) { } } if (c == null) { /** remplace les séparateurs de noms de paquetages par des / pour trouver * le fichier équivalent au nom de classe passé en argument */ String filename = name.replace ('.', File.separatorChar) + ".class"; try { byte data[] = loadClassData(filename); c = defineClass (name, data, 0, data.length); if (c == null) throw new ClassNotFoundException (name); } catch (IOException e) { throw new ClassNotFoundException ("Erreur rencontrée lors de la lecture du fichier : " + filename); } } if (resolve) resolveClass (c); return c; } // charge le bytecode correspondant à la classe private byte[] loadClassData (String filename) throws IOException { File f = new File (root, filename); int size = (int)f.length(); byte buff[] = new byte[size]; FileInputStream fis = new FileInputStream(f); DataInputStream dis = new DataInputStream (fis); dis.readFully (buff); dis.close(); return buff; } }

ALLER PLUS LOIN Ressources sur ce sujet

Divers sites, ouvrages et magazines proposent de très bonnes introductions à cette problématique du charge-ment des classes en Java :

B http://www.javaworld.com/javaworld/jw-10-1996/jw-10-indepth.htmlB http://www.ibm.com/developerworks/java/tutorials/j-classloader/B http://www.javalobby.org/java/forums/t18345.htm

R J. Engel, Programming for the Java Virtual Machine, Addison Wesley, 1999R Li Gong, Gary Ellison, Mary Dageforde, Inside Java™ 2 Platform Security: Architecture, API Design and

Implementation, 2e edition, Prentice Hall, 2003



Ainsi, OSGi permet d’implémenter de belles architectures orientées service au seind’une machine virtuelle, à condition de définir clairement les services exposés publi-quement et ceux consommés par chaque composant – et ce, en définissant de réelsmodules réutilisables à l’infini sous la forme de bundles.

Ces notions n’ont pas encore été présentées et seront développées par la suite, maisnous pouvons déjà dire qu’OSGi s’appuie sur le format de paquetage standard enJava (fichiers .jar) pour déployer ces modules (bundles) et qu’ils piocheront lesméta-informations nécessaires dans le fichier META-INF/MANIFEST.MF. Nous le préci-serons dans les chapitres ultérieurs.

Tour d’horizon de la norme OSGi et de ses servicesOSGi est une norme qui spécifie comment écrire des applications déployables danstout conteneur OSGi (conforme à la norme) en tirant parti de différents servicesnormalisés :• la gestion des traces (LogService) ;• la publication dynamique de ressources ou d’applications via un serveur HTTP

embarqué (HttpService) ;• la gestion de préférences ;• la gestion de périphériques UpnP ;• l’injection de dépendances par le biais du Declarative Services (ou SCR).

Le but est de fournir une API qui découvre des services apparaissant ou disparaissantà la volée, tout en assurant une cohérence entre diverses versions d’implémentationsd’un même service.

Cet ensemble de spécifications s’attache à fournir une solution à la fois légère et effi-ciente, mais aussi élégante, avec une emphase particulière sur la modularité.

CULTURE De la SOA aux architectures SCA

On pourrait voir OSGi comme une plate-forme fortement inspirée des architectures SCA (Software Com-ponent Architecture) en réduisant le spectre au seul langage Java et focalisée sur une implémentationmono-JVM – même si Distributed OSGi vise à élargir cette vision.SCA est une technologie poussée par IBM et Oracle. Elle préconise l’assemblage de composants hétéro-gènes communiquant par le biais de protocoles standardisés, afin de rendre l’ensemble indépendant deschoix technologiques (plates-formes matérielles, langages d’implémentation mis en œuvre…). C’est laplus aboutie des mises en œuvre des principes de la SOA.



15

Depuis sa conception (1998), OSGi visait à résoudre les problèmes liés aux applica-tions embarquées, un monde dans lequel toute ressource se doit d’être exploitée plei-nement et toute dépense justifiée. C’est ainsi qu’un environnement OSGi complettel que Felix (l’implémentation du projet Apache) ne réclame que un oudeux mégaoctets de RAM. Cet environnement constitue le socle pour accueillirtoute application, quel que soit son cadre de développement.

L’accent est mis sur la possibilité d’obtenir un système extrêmement dynamique, ausein duquel la maîtrise du couplage logiciel est essentielle. C’est à ce titre qu’OSGi,par son approche orientée services, est utile, car elle favorise justement le découplageentre composants.

Qu’en est-il cependant de la modularité promise ? Nous reviendrons sur le sujet plusloin ; retenons déjà qu’en découplant les interfaces des implémentations et en veillant àn’utiliser que des interfaces par le biais d’une injection de dépendances du type SCR, laplate-forme OSGi va permettre de remplacer n’importe quelle brique (bundle) par uneautre, tout en fournissant les mêmes services, et ce, dynamiquement.

Couplage et injection de dépendances ?Au sens du génie logiciel, le couplage entre deux composants traduit le degré dedépendance d’un composant envers l’autre. Dès lors qu’il y a couplage importantentre deux composants, il y a une plus grande difficulté en cas de changement et celainflue sur la gestion des deux composants. Un couplage fort induit des modificationsdans le composant utilisateur, dès que l’on modifie le composant qu’il utilise.

Quant à l’injection de dépendances, elle est nécessaire lorsque l’implémentation d’uncomposant peut requérir des services offerts par un autre composant en utilisant unpattern de délégation. Le choix, au moment de la compilation, du composant qui varéaliser ce service est un frein à l’évolution du produit car tout changement futur varéclamer une coûteuse procédure de recompilation, redéploiement et redémarrage.

L’injection de dépendances repousse ce choix à la phase d’exécution. Ce choix peutêtre réalisé par un composant tel que Spring (qui fait de l’injection statique car

EN CLAIR

SCA Software Component Architecture

SOA Service Oriented Architecture

Notez qu’on retrouve le même type d’effets lors de l’utilisation d’attributs en programmation orientéeobjet classique et en cas de non-respect du principe fondamental de l’encapsulation.



guidée par des informations XML ou des annotations positionnées dans le code Java)ou, dans le cas d’OSGi, par un service de gestion des dépendances qui propose uneversion dynamique de l’injection.

Les bundles OSGiDans le vocabulaire spécifique OSGi, un module déployé au sein de la plate-formeOSGi est appelé un bundle. Par extension, dans le cas de la programmation RCP, ondevrait remplacer la notion de plug-ins par celle de bundles, mais les traditions res-tent. Comme nous l’avons déjà dit, un bundle est en fait déployé en tant que fichier.jar avec des méta-informations lues par le conteneur OSGi et fournies par lefichier META-INF/MANIFEST.MF.

Les spécifications OSGi en détailOSGi découle des travaux d’industriels et de spécialistes du logiciel regroupés au seind’une association : l’OSGi Alliance. Celle-ci gère des versions de spécifications quisont organisées de la façon suivante :• Core : le cœur d’OSGi, qui fournit les entités centrales et leurs liens, c’est-à-dire

les classes Bundle et BundleContext. • Compendium : extensions presque indispensables du cœur de la plate-forme

OSGi, avec les différentes interfaces définissant les services standardisés. Nousverrons ces services et comment les utiliser dans les chapitres suivants.

En plus de ces deux spécifications, l’Alliance gère une extension de la plate-forme,appelée Enterprise OSGi, qui propose des fonctionnalités supplémentaires dédiéesaux applications d’entreprises avec notamment :• l’intégration de l’API de gestion de la persistance ( JPA) ;• l’intégration Spring.

Diverses implémentations de ce standard existent, dont Apache Aries et EclipseLibra. D’autres initiatives moins connues émanent de l’OSGi Alliance et ne sont

VOCABULAIRE RCP

RCP, pour Rich Client Platform, désigne un mode de déploiement et de programmation fournissant unealternative aux interfaces web (et donc à leurs limitations) en autorisant des interfaces graphiques richesen fonctionnalités. C’est l’option opposée aux clients dits légers puisqu’il s’agit là de déployer des appli-cations s’appuyant sur l’environnement développé pour Eclipse (SWT et autres bibliothèques) ou autourde NetBeans (Swing, etc.). Les développeurs Java ayant fait de l’analyse d’application ont peut-être déjàutilisé un tel outil avec la célèbre Visual-VM et son plug-in Visual-GC qui se basent sur l’infrastructureNetBeans RCP.



17

plus forcément d’actualité avec des projets autour de l’automobile notamment (VEGpour Vehicule Expert Group).

Enfin, nous l’avons évoqué, l’architecture OSGi se rapproche de l’architecture SCAavec les travaux menés sur Distributed OSGi visant à offrir une extension multi-JVM des concepts offerts par OSGi. Parmi les différents produits sur le marché, onpeut citer Nimbus et Fabric de la société Paremus (http://www.paremus.com).

Implémentations OSGiOSGI est une norme et, à ce titre, elle peut trouver diverses implémentations adhé-rant à divers niveaux de spécifications. En dehors de l’implémentation de référencebasique fournie sur le site officiel, on peut citer :• Equinox : l’implémentation OSGi du consortium Eclipse, la véritable moelle épi-

nière d’Eclipse, mais qui peut être utilisé de manière indépendante ;• Apache Felix : l’implémentation de la fondation Apache ayant bénéficié de

l’expertise de Richard Hall et de dons de la part de la fondation ObjectWeb ;• Knopflerfish : une autre implémentation de qualité.

Eclipse n’est pas le seul produit à tirer bénéfice de cette plate-forme. On compte éga-lement de nombreux serveurs JEE : • JOnAS 5, le serveur J2EE de la fondation OW2, basé sur OSGi (Felix) ;• Glassfish v3 ;• JBoss qui depuis sa version 5 expose une facette de son micronoyau en OSGi ;• Websphere depuis la version 7 propose un service pack d’intégration OSGi.

La plate-forme OSGi, de par ses qualités d’architecture (dynamisme, maîtrise du cou-plage), s’impose donc même sur ces environnements fort éloignés des cas d’utilisationsciblés au départ qu’étaient les environnements légers pour applications embarquées.

Nous reparlerons des conteneurs OSGi en fin de chapitre 4.


IndexAactivate() 48ANT 65–67

build-file 66Ant 122AOP - Aspect Oriented Programming 109, 157Apache Ace 145Apache Aries 16Apache Celix 44Apache Felix 15, 17, 22–23, 38–39, 56, 58, 60,

62, 66–67, 71, 91, 98, 105, 114, 133, 145, 150, 155

API 119commande du shell 117felix-scr 75File-Install 121, 145WebConsole 87

Apache Maven 60API - Application Programming Interface 138application

embarquée 4, 15, 29J2EE 8

application embarquée 29architecture orientée services 9

Bbibliothèque

Java 39Java standard 154

bnd 32, 34–35, 41, 64–65, 75, 88, 90, 96, 98, 128, 154, 158

bndtools 113description de bundle 49

bnd.bnd 36bndtools 31, 33–34, 66, 75–76, 90–91

créer un projet 33

installation 32broker de messages 93bundle OSGi 8, 16, 31, 39, 50, 76, 88, 110

couplage/découplage 93création 32, 34, 67dépendance 59déploiement 36, 43, 65, 67descripteur 35–36, 46, 59, 66–67, 78, 85, 144,

158, 166encapsulation 40–41, 59gestion des versions 73, 126Import-Package 35méta-information 34, 65, 67–68méthode main() 34Private-Package 35référentiel 58Service-Component 35test unitaire 119, 121tester la conformité avec la norme 58

Bundle-Version 41

Ccardinalité 85Castor XML 140classe Java standard 34, 67ClassLoader Java 10, 12commande du shell 155ConfigAdmin 100, 130

propriétaire de la configuration 103conteneur OSGi 8, 14, 19, 34, 50, 56, 88couplage/découplage d’application 9, 15, 31, 44,

49, 51, 53, 100, 110couplage/découplage de composants 151Cron4J 153, 155–156

DDBC - Design By Contract 109, 128



Declarative Services 76, 85, 114, 130dépendance 8, 48, 59, 68, 71

circulaire 137–138Distributed OSGi 17

EEAI - Enterprise Application Integration 10EasyMock 111Eclipse 17, 19, 21, 32–33, 40, 42, 52, 57–58,

65–68, 76, 91, 113, 122, 127, 158bndtools 75, 154Market Place 32PDE 31, 56, 147plug-in 5–6

Eclipse Libra 16EJB - Enterprise Java Beans 138, 147encapsulation 149Enterprise OSGi 16entrepôt de composants 60environnement de développement 19Equinox 17, 19, 36, 38–39, 52, 57–58, 62, 66, 145

API 119ERP - Enterprise Resources Planning 7Event Service 74EventAdmin 92–93, 98EventHandler 93Export-Package 41, 45, 137

FFabric 17File-Install 155

Ggabarit de conception 129

Factory 130Whiteboard 130, 133, 137, 149

gestiondes périphériques 14des préférences 14, 101des traces 14, 88des versions 125, 127–128, 146–147

getServiceReference() 48GlassFish 17, 19–20, 56Google GUICE 70

HHibernate 137HttpService 98, 100, 130

whiteBoard 98HttpService Whiteboard 134

IIDE - Integrated Development Environment 5implémentation OSGi 17Import-Package 40, 59, 112Include-Resource 158injection de dépendance 14–15, 49, 69–71, 75, 81,

85, 105, 112, 115, 130, 138, 146, 149, 158–159

dynamique 72invocation dynamique de code 137IoC - Inversion of Control 70iPOJO 67iText 150, 153–155Ivy 127, 138

JJAAS - Java Authentication and Authorization

Service 7JAR - Java ARchive 8, 35, 40, 64–65, 75, 154, 158java.lang 140java.lang.reflect 140JBI - Java Business Integration 10JBoss 17, 19JCA - J2EE Connector Architecture 7JDBC - Java DataBase Connectivity 7, 158JDK - Java Development Kit 20Jetty 98, 100, 130JMS - Java Message Service 92–93, 138JNDI - Java Naming and Directory Interface 7,

65, 138JOnAS 17, 19, 21, 56, 65

classe de lancement 26classe JOnAS 25code source 24script de lancement 22shell OSGi 22

JPA - Java Persistence API 7, 16, 157JTA - Java Transaction API 7


Index 177

JUnit 120JVM - Java Virtual Machine 8, 28, 56, 58, 92

KKaraf

API 119Knopflerfish 17, 56, 58, 62

LLDAP - Lightweight Directory Access

Protocol 7LogService 51, 92, 95, 103

MMANIFEST.MF 28, 35, 40–41, 45, 48, 59,

64–65, 75, 112, 126, 128, 137, 147Maven 65, 122, 126–127, 138, 147META-INF/MANIFEST.MF 14, 16, 35, 50méta-information 67, 70, 73, 112, 137, 147micronoyau 22modularité 110MOM - Message Oriented Middleware 53, 93

NNetBeans 58, 60

module 6Nimbus 17norme OSGi 14, 16

Oobjet mock 111OBR - OSGi Bundle Repository 56, 60

architecture 63Oscar 56, 60OSGi

chargement de classe 40Declarative Services 67environnement 55plug-in de développement Eclipse 64service 67service de lancement d’un conteneur 27

OSGi Alliance 16, 58OSGI-INF 85, 112OSGI-OPT 73

Ppaquetage 35, 41PDE - Plug-in Development Environment

66–67, 113, 169planification de tâche 153, 156POJO - Plain Old Java Object 67, 146–147Posh 119Private-Package 47propriétaire de la configuration 103, 108publication dynamique via HTTP 14

QQuartz 153, 156

RRCP - Rich Client Platform 16, 68

SSCA - Software Component Architecture 15, 17SCR - Service Component Runtime 70–71, 75,

84, 88, 96, 105, 108, 114, 145exemple d’utilisation 76fonctionnalité 71mise en œuvre 73

sérialisation/désérialisation de données 137, 140serve@home 29serveur d’applications 7serveur J2EE 17service OSGi 14, 35, 44, 51, 74, 114, 156

cardinalité 72ConfigAdmin 88, 159déclaration 70Declarative Services 108, 151, 158–159disponibilité 119–120EventAdmin 72, 150–151EventService 95, 149HttpService 98, 133, 136, 150LogReaderService 88LogService 72, 87, 149Metatype 87par défaut 43publier 44test unitaire 121

Service-Component 47ServiceReference 95, 98



ServiceTracker 50, 133ServletTracker 135shell OSGi 117, 145ShutdowHookThread 28ShutdownHookThread 27SOA - Service Oriented Application 128SOA - Services Oriented Architecture 9–10, 15,

68, 110, 136, 152spécifications OSGi

Compendium 16Core 16

SPOF - Single Point Of Failure 116Spring 15, 71, 75, 157Spring IOC 70Spring-DM 73, 130, 146SpringSource 127SQLite 150, 154, 158–159SRC 50stratégie de bouchonnage 110

Swing 22–23, 101, 108, 150, 155SWT 101synchronized 81

Ttest unitaire 109, 111

durée 124environnement d’exécution 120initialisation 120

TestNG 120–121, 124Tomcat 100, 130topic 93, 95

WWebConsole 71, 88Websphere 17

XXerial 158


Core

BundleContext Bundle

Knopflerfish

Compendium

httpService LogServiceSpécifications

Implémentations

Outils de développement

Outilsd’administration

Equinox Felix

bnd bndTools iPojo spring

gogo WebconsoleFelix-stall


Documents

Jérôme Molière - Fnacmultimedia.fnac.com/multimedia/editorial/pdf/9782212133288.pdfBaird-Smith, est un Français de Grenoble. S’il a quitté le projet quelques mois après, il