Conception d`applications modulaires en Java

OSGi
Conception d’applications
modulaires en Java
Jérôme Molière
Préface de Peter Kriens
© Groupe Eyrolles, 2012, ISBN : 978-2-212-13328-8
OSGi.book Page V Wednesday, December 21, 2011 12:51 PM
Préface
Pour nous, qui venons du Nord, la France méridionale a bien des attraits. La douceur du
climat, 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 facile
parce qu’elle est étrangement attachante, pour un pays si froid. Pourtant, en 2003, nous
avons franchi le pas et emménagé dans un endroit magnifique, Beaulieu, dans la campagne environnant Montpellier.
Parmi les choses qui m’ont manqué, les échanges avec mes collègues d’Ericsson et les
déjeuners rituels dont je garde un très bon souvenir. En effet, toute attrayante que soit la
côte méditerranéenne, on n’y trouve que très peu de développeurs OSGi... Aussi fus-je
stupéfait d’apprendre que l’un des conférenciers acceptés en 2009 à la conférence OSGi
DevCon à Jazoon habitait à moins de 12 kilomètres de chez moi ! Je lui ai écrit pour
proposer un déjeuner – quel rêve en effet que de tenir une discussion approfondie sur les
ClassLoaders Java tout en jouissant des fruits de « La Campagne » ! C’est ainsi que j’ai
rencontré 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 cours
des dix dernières années, j’ai été sollicité de nombreuses fois pour rédiger des ouvrages
sur la création logicielle, mais le travail est infernal, peu rémunéré et tout à fait sousestimé. Je tire mon chapeau à tous les auteurs qui sont capables d’aller au bout d’une telle
entreprise. En effet, il suffit au lecteur d’une minute sans effort pour parcourir un texte
qui 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 ouvrage
en allemand, un en chinois et plusieurs en anglais, quand on sait que les racines d’OSGi
se situent en France et que cette norme y est assez populaire. J’y vois une sorte de
reconnaissance !
OSGi.book Page VI Wednesday, December 21, 2011 12:51 PM
VI
OSGi – Conception d’applications modulaires en Java
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, Anselm
Baird-Smith, est un Français de Grenoble. S’il a quitté le projet quelques mois après, il
n’en demeure pas moins pour moi l’auteur original du cœur de la norme. Après dix
années passées à travailler sur son modèle, je reste béat d’admiration pour la simplicité et
l’élégance du modèle OSGi original, et plus encore à présent que je réalise combien les
purs 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 complexité. Mais quand on analyse ces attaques verbales, on se rend compte qu’ils reprochent à l’outil de ne pas faire... ce pour quoi il n’est pas fait ! C’est que la modularité ne
s’utilise pas comme une bibliothèque qu’il n’y aurait qu’à ajouter dans son classpath... La
modularité est une qualité de la structure de base de votre code. OSGi, lui, n’est qu’un
messager 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 modulaires échouent dans un environnement OSGi !
Malheureusement, la plupart des bibliothèques les plus utilisées ne sont pas modulaires
dans leur conception. Il faudrait, pour jouir des avantages de la modularité, un remaniement 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 par
paquets : la solution la plus simple pour étendre Java de façon modulaire, sans toutefois
perdre 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éremment. Or, un tel changement est toujours mystérieux : avant l’épiphanie, tout semble
inutilement complexe et bruité. Mais une fois de l’autre côté, tout s’éclaire comme par
magie et la cause des problèmes entrevus auparavant devient péniblement évidente. J’en
ai fait l’expérience plusieurs fois dans ma vie, avec la programmation objet, la programmation fonctionnelle (avec Prolog !), l’inversion de contrôle... non sans peiner à chaque
fois. Pour pimenter le tout, impossible de franchir la distance sur de simples explications, 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 à OSGi
avec 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 explications, et en testerez les exemples, le chemin vous semblera ardu. Mais les leçons en
valent la peine car elles vous donneront un précieux recul sur votre code, ainsi que sur la
manière de l’optimiser et de le rendre plus modulaire.
Peter Kriens
OSGi.book Page VII Wednesday, December 21, 2011 12:51 PM
Table des matières
Avant-propos ................................................................................. 1
CHAPITRE 1
OSGi pour une conception modulaire.......................................... 3
OSGi, pour quelles applications ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Cas d’une automobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Cas d’un environnement de développement (IDE) . . . . . . . . . . . . . . . . . . . . . . 5
Cas d’un serveur d’applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Problèmes liés au paquetage des applications J2EE . . . . . . . . . . . . . . . . . . . . . . . . 8
Regrouper des bibliothèques au sein d’un conteneur OSGi . . . . . . . . . . . . . . . . . . 8
Vers les architectures orientées services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Dépasser les limitations dues aux ClassLoader Java . . . . . . . . . . . . . . . . . . . . . . . 10
Tour d’horizon de la norme OSGi et de ses services . . . . . . . . . . . . . . . . . . . . . . 14
Couplage et injection de dépendances ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Les bundles OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Les spécifications OSGi en détail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Implémentations OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
CHAPITRE 2
Exemples d’applications modulaires basées sur OSGi ............. 19
OSGi comme socle architectural de serveur : JOnAS 5 . . . . . . . . . . . . . . . . . . . . 21
Le shell OSGi sous JOnAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Un bref survol du code source de JOnAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
OSGi pour les applications embarquées : serve@home . . . . . . . . . . . . . . . . . . . . 29
Le projet domotique serve@home de Siemens . . . . . . . . . . . . . . . . . . . . . . . . . 29
OSGi dans les automobiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
CHAPITRE 3
Mettre en place son premier bundle OSGi ................................ 31
Installation de bndtools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Création du projet et développement du bundle . . . . . . . . . . . . . . . . . . . . . . . . . 32
OSGi.book Page VIII Wednesday, December 21, 2011 12:51 PM
VIII
OSGi – Conception d’applications modulaires en Java
Création du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Méta-informations nécessaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Bundles et bibliothèques Java utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
OSGi et chargement de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Encapsulation de la bibliothèque Commons Lang . . . . . . . . . . . . . . . . . . . . . . 40
Services OSGi par défaut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Publier son premier service OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Gestion du dynamisme avec le tracking de services . . . . . . . . . . . . . . . . . . . . . 50
S’appuyer sur les services standards de la plate-forme . . . . . . . . . . . . . . . . . . . . 51
CHAPITRE 4
Travailler avec OSGi : environnement et outils ........................ 55
Conteneurs OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Apache Felix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Le projet Knopflerfish . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
La console OSGi d’Eclipse : Equinox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Choisir sa console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Nécessité d’un référentiel de bundles : OBR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
OSGi et bundles : limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Vers un entrepôt commun de bundles avec OBR . . . . . . . . . . . . . . . . . . . . . . . 60
Premier contact avec OBR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Architecture et dynamique d’appels avec OBR . . . . . . . . . . . . . . . . . . . . . . . . 63
Les plug-ins de développement Eclipse pour OSGi . . . . . . . . . . . . . . . . . . . . . . . 64
Simplifier la création de bundles avec bnd . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Travailler avec bnd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Utiliser bndtools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
iPOJO : une autre approche du développement OSGi . . . . . . . . . . . . . . . . . . . 67
PDE : l’environnement standard de développement de plug-in d’Eclipse . . . . . 67
CHAPITRE 5
Le moteur d’injection de dépendances :
la spécification Declarative Services.......................................... 69
Introduction à la déclaration de services dans OSGi . . . . . . . . . . . . . . . . . . . . . . 70
Le SCR (Service Component Runtime) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Fonctionnalités proposées par le SCR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Activation immédiate ou retardée ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Principes pour la mise en œuvre de SCR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Exemple complet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Descriptif du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Entités en présence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
OSGi.book Page IX Wednesday, December 21, 2011 12:51 PM
Table des matières
Application en utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
L’exemple vu du côté technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Code source et descripteurs de déploiement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Précisions sur le Declarative Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
CHAPITRE 6
Services OSGi pour le développeur : LogService,
EventAdmin, HttpService et ConfigAdmin................................ 87
Gestion des traces avec le LogService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Communication par messages avec l’EventAdmin . . . . . . . . . . . . . . . . . . . . . . . . 92
Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Fonctionnalités et limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Principales entités mises en jeu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Exemple de mise en œuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Exposer ses ressources sur le Web avec l’HttpService . . . . . . . . . . . . . . . . . . . . . . 98
Service de configuration : le ConfigAdmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
CHAPITRE 7
Modularité et tests unitaires.................................................... 109
Retour sur la notion de modularité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Du point de vue du chef de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Du point de vue du programmeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Du point de vue de l’architecte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Modularité et tests en environnement OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Les commandes du shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Tests en environnement OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Principe du test unitaire en environnement OSGi . . . . . . . . . . . . . . . . . . . . . 119
Cré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 . . . . . 121
Considérations avancées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Gestion des versions de composants en environnement OSGi . . . . . . . . . . . . . 125
Qu’est-ce qu’une version d’un composant et d’une application ? . . . . . . . . . . 125
La vision offerte par OSGi en matière de gestion de versions . . . . . . . . . . . . 126
Adopter une numérotation cohérente et en tirer parti . . . . . . . . . . . . . . . . . . 127
Gestion de la politique de numérotation des versions en pratique . . . . . . . . . 128
Ce qu’il faut retenir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
IX
OSGi.book Page X Wednesday, December 21, 2011 12:51 PM
X
OSGi – Conception d’applications modulaires en Java
CHAPITRE 8
Design patterns OSGi et bonnes pratiques ............................. 129
Gabarits de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Séparation entre API et implémentations . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Le design pattern Factory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Le design pattern du tableau blanc ou Whiteboard . . . . . . . . . . . . . . . . . . . . 130
Comment fonctionne le WhiteBoard ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Invocation dynamique de code dans le contexte OSGi . . . . . . . . . . . . . . . . . . 137
Exemple de situation : sérialisation/désérialisation de données
avec Castor XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Mise en place pratique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Conseils et pièges à éviter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Shells OSGi et niveaux de démarrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Gestion de la problématique des versions . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Injection de dépendances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Maîtrise de la méta-information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
CHAPITRE 9
Application exemple ................................................................. 149
L’application exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Vue d’ensemble de l’architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Notes relatives à la conception de l’application . . . . . . . . . . . . . . . . . . . . . . . 152
Création des PDF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Planification de tâches en Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Quelques images du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Notes relatives à l’implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Encapsulation d’une bibliothèque Java standard. . . . . . . . . . . . . . . . . . . . . . . 154
Commandes du shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Utilisation de Cron4J . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Finalisation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Le code source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Planification de tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Encapsulation de SQLite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Le DAO SQLite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Descripteur 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 1 Wednesday, December 21, 2011 12:51 PM
Avant-propos
Depuis environ deux ans, de nombreux produits voient leurs architectures complètement modifiées pour adopter une conception conforme à la norme OSGi. Que peut
apporter cette norme au développeur et concepteur ? Que propose-t-elle ? Quel
modèle et quels outils utiliser ?
Pourquoi ce livre ?
Ce livre cherche à présenter en douceur la plate-forme OSGi, ainsi que l’environnement gravitant autour. Il comporte une section dédiée à l’outillage, ainsi qu’une section, plus rare en comparaison des ouvrages existants, consacrée aux aspects de conception en environnement OSGi.
Cet ouvrage ne tente pas d’entrer dans les arcanes d’un conteneur OSGi ni de
dé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 la
lecture de l’indispensable OSGi in Action paru chez Manning et cosigné par
Richard S. Hall, un des meilleurs spécialistes d’OSGi.
R Richard S. Hall, Karl Pauls et Stuart McCulloch, OSGi in Action, Manning, 2011
OSGi.book Page 2 Wednesday, December 21, 2011 12:51 PM
2
OSGi – Conception d’applications modulaires en Java
À qui s’adresse ce livre ?
Cet ouvrage s’adresse aux étudiants, ingénieurs, architectes et chefs de projets expérimentés en Java et qui s’intéressent aux problématiques de modularité, ou qui doivent
s’adapter à des contraintes liées au déploiement en environnement embarqué : développeurs JEE, développeurs RCP…
Structure du livre
Après avoir esquissé le contexte architectural actuel, nous présenterons la notion de
services propre au monde OSGi, puis nous aborderons la façon de travailler et de
penser une application pour cette technologie. Enfin, nous illustrerons les concepts
évoqués sur un cas pratique simple.
Remerciements
L’auteur tient à remercier chaleureusement Peter Kriens, qui a toujours été à son écoute
et a apporté des solutions sages et le plus souvent élégantes, tout en enrichissant ses
réponses d’anecdotes croustillantes sur la face cachée d’une norme telle qu’OSGi. Il le
remercie 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, le
trio 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é avec
minutie et efficacité lors des dernières étapes.
De plus, cet ouvrage n’aurait pas été possible sans la mission effectuée au sein de
Telintrans.
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, 2011
R E. Gamma et al., Design Patterns: Elements of Reusable Software Components, Addison Wesley, 1994
R C. Beust, H. Suleiman, Next Generation Java Testing, Addison Wesley, 2007
OSGi.book Page 3 Wednesday, December 21, 2011 12:51 PM
1
OSGi
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 configurables
et dynamiques dans un environnement à une seule machine virtuelle Java. Ce premier
chapitre a pour but de placer la plate-forme OSGi dans le contexte des applications
modernes, de manière à justifier son utilisation dans des conditions a priori opposées : de
l’application embarquée jusqu’au serveur d’applications. Il présente enfin les spécifications
d’OSGi et les services qu’elle prévoit.
OSGi, pour quelles applications ?
Cette section examine quelques types d’applications contemporaines (automobile,
environnement de développement, serveur d’applications) pour en extraire des
besoins techniques communs. Cette collecte nous amènera naturellement vers une
vue d’ensemble de la plate-forme OSGi.
OSGi.book Page 4 Wednesday, December 21, 2011 12:51 PM
4
OSGi – Conception d’applications modulaires en Java
Cas d’une automobile
Objet de la vie de tous les jours, une voiture récente est un véritable écosystème
d’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 divers
paramètres comme l’intensité du freinage, la vitesse, éventuellement le type de
revêtement, etc. ;
• ESP (Electronic Stability Program, système de lutte contre le patinage, qui réduit
le couple moteur dans certaines conditions de circulation où l’adhérence est problématique), dispositif qui requiert une application contrôlant le régime moteur
en 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. Cet
exemple nous donne l’occasion de formuler quelques remarques.
Tout d’abord, ces applications sont nombreuses et doivent cohabiter dans le même
environnement, 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 effectives
que 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’importance moindre a provoqué des erreurs.
Enfin, ces applications forment un véritable microcosme et interagissent. En effet, plusieurs applications peuvent demander une modification du régime moteur, sans pour
autant que le code correspondant soit dupliqué. Elles vont donc toutes s’adresser à une
mê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 le
même nombre de lignes de code que l’informatique d’un programme spatial des années 1960, tandis que
l’on constate que le volume du code à l’échelle planétaire double tous les 7 ans.
OSGi.book Page 5 Wednesday, December 21, 2011 12:51 PM
OSGi pour une conception modulaire
CHAPITRE 1
Cas d’un environnement de développement (IDE)
Quels sont les services attendus par un utilisateur d’IDE (Integrated Development
Environment) ? Ils sont fort variés, même si en premier lieu, on s’attend à trouver des
facilité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 serveurs
d’applications dans le monde Java, avec Apache dans le monde PHP. On peut avoir
besoin 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’architecture
de tels produits doit donc prévoir un socle générique offrant diverses facilités transverses. En enrichissant les fonctionnalités de ce socle par l’ajout de greffons, on
aboutit à l’idée de plug-ins présente dans Eclipse, ou encore à celle de modules dans le
cadre de l’architecture NetBeans. Un IDE récent doit donc offrir un large éventail
d’extensions et un cadre de développement de ces extensions de manière à couvrir de
nombreux besoins distincts.
Figure 1–1
Contenu du répertoire plugins
pour Eclipse/Ganymede
orienté J2EE
Les figures 1-1 à 1-4 montrent les contenus des répertoires d’extensions fournis avec
les deux environnements majeurs de développement du monde Java : NetBeans et
Eclipse. Ce dernier ne comporte pas moins de 583 plug-ins, alors que NetBeans
couvre sensiblement le même spectre de fonctionnalités avec tout de même
5
OSGi.book Page 6 Wednesday, December 21, 2011 12:51 PM
6
OSGi – Conception d’applications modulaires en Java
40 modules (la granularité des modules NetBeans n’est pas exactement comparable à
celle d’un plug-in ou bundle dans Eclipse) !
Figure 1–2
Contenu du répertoire modules
de NetBeans 6.5
Figure 1–3
Nombre de modules dans un
NetBeans 6.5/All
Figure 1–4
Nombre de plug-ins dans
Eclipse Ganymede JEE5
sous Linux
É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 est
donc impératif que l’architecture des IDE récents permette un chargement à la
demande des extensions, afin de laisser disponible un volume maximal de mémoire
pour un fonctionnement raisonnable du programme.
OSGi.book Page 7 Wednesday, December 21, 2011 12:51 PM
OSGi pour une conception modulaire
CHAPITRE 1
DÉFINITION Lazy loading : le chargement à la demande
Cette stratégie de chargement est opposée à une politique plus brutale, consistant à charger tout au
démarrage. On retrouve ces noms de politiques dans des produits comme Hibernate. Il est logique de
désactiver les ressources requises pour travailler en PHP quand on se prépare à travailler sur un serveur
de sources Subversion, par exemple. Évidemment, cette stratégie impose de nombreux accès au disque ;
tout avantage a sa contrepartie.
Cas d’un serveur d’applications
Un tel serveur est un hôte pour vos applications ; il met à leur disposition diverses
ressources :
• 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 de
disposer d’un taux de disponibilité maximal. Rationaliser leur utilisation, en évitant
un chargement multiple de la même bibliothèque au gré des humeurs des développeurs créant les paquetages, rend plus robuste l’ensemble des applications.
Enfin, une autre fonctionnalité est souvent désirée concernant un serveur
d’applications : le fait de pouvoir exposer diverses versions de la même application –
chose impossible jusque récemment.
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
7
OSGi.book Page 8 Wednesday, December 21, 2011 12:51 PM
8
OSGi – Conception d’applications modulaires en Java
Problèmes liés au paquetage des applications J2EE
Après avoir effectué des dizaines d’audits d’applications J2EE déployées sous
Tomcat, JBoss, JOnAS ou WebLogic, il m’est possible de désigner la mise en paquetage d’une application comme un facteur de fortes perturbations pour la stabilité d’un
serveur. Ainsi, du bytecode inutile empaqueté en archives .jar influera sur la taille
de la zone de la mémoire Java connue sous le nom de PermGen, zone contenant
principalement le bytecode Java (mais aussi les interns propres aux instances de
java.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étrage
du ramasse-miettes (garbage collector) si l’on déploie des archives ( JAR) contenant
beaucoup de bibliothèques inutiles. La zone dénommée PermGen se trouvant favorisée
par 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çant
des promotions non désirables et en entraînant la multiplication de passages plus laborieux du ramasse-miettes en mode full (avec scan des zones de la hcap).
EN CLAIR
JVM
Java Virtual Machine
JAR
Java ARchive
Regrouper des bibliothèques au sein d’un conteneur OSGi
Si vous encapsulez vos bibliothèques en tant que bundles OSGi (donc versionnés) et si
vous énoncez vos dépendances sous forme de clauses import-paquetage, vous permettrez au conteneur OSGi de réellement partager les dépendances usuelles et donc d’économiser des ressources. En même temps, cela permet de gérer aisément le cas où deux
bundles utilisent deux versions différentes de la même bibliothèque – puisque chaque
bundle OSGi se voit isolé dans son propre ClassLoader.
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-informations, est donc un module au sein de votre application.
OSGi.book Page 9 Wednesday, December 21, 2011 12:51 PM
OSGi pour une conception modulaire
CHAPITRE 1
L’informatique d’aujourd’hui est complexe, s’appuie sur de nombreux composants
qui doivent interagir sans pour autant être trop couplés, au risque de voir la maintenance évolutive des applications se transformer en cauchemar. Il est crucial d’envisager les relations entre composants comme un véritable dialogue client/serveur ou
encore client/fournisseur.
Cette approche nous oblige à nous centrer sur les services requis pour le fonctionnement d’un composant, ainsi que sur les services qu’il offre à l’extérieur. Nous nous
plaçons dans une optique résolument tournée vers le SOA (Services Oriented Architecture, architecture orientée service), où l’important est de voir notre demande de service aboutir, sans s’occuper de qui l’a honorée, ni de comment (par quelle implémentation ou quel code) cette requête a abouti.
Vers les architectures orientées services
La SOA véhicule l’idée que le seul moyen de maîtriser une application le long de son
cycle de vie est de faire en sorte d’en maîtriser le couplage. Cela demande d’attendre
de nos applications qu’elles présument le minimum de choses possibles quant aux
composants externes utilisés. Ainsi, éviter un couplage fort avec une version spécifique de Log4J ou avec un parseur XML permet d’intégrer facilement les bénéfices
apportés par une version ultérieure de ce produit.
Comment arriver à un tel découplage ? En manipulant des API (versionnées) et en
réclamant pour nos composants que leur environnement d’exécution leur fournisse
une version compatible avec nos exigences.
N’entrons pas pour l’instant dans la mise en pratique concrète – il faudra pour cela
attendre le chapitre 3 – mais concentrons-nous sur les concepts. À ce stade, nous
devons 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 les
symboles 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 composant.
9
OSGi.book Page 10 Wednesday, December 21, 2011 12:51 PM
10
OSGi – Conception d’applications modulaires en Java
La figure 1-5 montre comment un composant A propose un service utilisé par un
composant B, tout en utilisant un service offert par un composant C.
Figure 1–5
Un 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, en
s’appuyant sur des briques logicielles orchestrant les dialogues entre applications (EAI, Enterprise Application 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 (microservices), 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 peut
lé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 version
du paquetage correspondant à ce service). Le chapitre 6 sera dédié à cette notion de services dans la
norme OSGi, donc n’anticipons pas trop...
EN CLAIR
SOA
Service Oriented Architecture
EAI
Enterprise Application Integration
JBI
Java Business Integration
Dépasser les limitations dues aux ClassLoader Java
Java s’appuie sur la notion de chargeur de classes (ClassLoader), de manière à rendre
possible le chargement de classes par le réseau, en base de données ou par n’importe
quel autre flux. Il n’y a pas, au sens strict du terme, un seul ClassLoader, mais plutôt
OSGi.book Page 11 Wednesday, December 21, 2011 12:51 PM
OSGi pour une conception modulaire
CHAPITRE 1
une hiérarchie de ClassLoaders, chacun responsable du chargement d’une partie des
classes nécessaires à une application.
Il est possible de développer ses propres chargeurs de classes répondant à tel ou tel
besoin précis. Des applications comme JBoss ou Tomcat, avec leurs besoins de redéploiement à chaud, utilisent évidemment cette possibilité. Ainsi, dans JBoss, c’est par
le biais de la création d’un tel ClassLoader (UnifiedClassLoader) que des possibilité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 par
le parent en premier a un certain nombre d’avantages, mais présente aussi son lot de
désagréments.
Figure 1–6
Organisation des ClassLoaders
dans une application standard
La figure 1-7 détaille la séquence propre à toute implémentation d’un
spécifique.
ClassLoader
On peut imaginer différents moyens de stocker le code compilé correspondant à des
classes 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.
11
OSGi.book Page 12 Wednesday, December 21, 2011 12:51 PM
12
OSGi – Conception d’applications modulaires en Java
Figure 1–7
Séquence propre à toute
implémentation d’un
ClassLoader spécifique
Exemple simpliste d’un ClassLoader chargeant des classes depuis un système de fichiers
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 {
OSGi.book Page 13 Wednesday, December 21, 2011 12:51 PM
OSGi pour une conception modulaire
CHAPITRE 1
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 chargement des classes en Java :
B http://www.javaworld.com/javaworld/jw-10-1996/jw-10-indepth.html
B 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, 1999
R Li Gong, Gary Ellison, Mary Dageforde, Inside Java™ 2 Platform Security: Architecture, API Design and
Implementation, 2e edition, Prentice Hall, 2003
13
OSGi.book Page 14 Wednesday, December 21, 2011 12:51 PM
14
OSGi – Conception d’applications modulaires en Java
Ainsi, OSGi permet d’implémenter de belles architectures orientées service au sein
d’une machine virtuelle, à condition de définir clairement les services exposés publiquement et ceux consommés par chaque composant – et ce, en définissant de réels
modules 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, mais
nous pouvons déjà dire qu’OSGi s’appuie sur le format de paquetage standard en
Java (fichiers .jar) pour déployer ces modules (bundles) et qu’ils piocheront les
méta-informations nécessaires dans le fichier META-INF/MANIFEST.MF. Nous le préciserons dans les chapitres ultérieurs.
Tour d’horizon de la norme OSGi et de ses services
OSGi est une norme qui spécifie comment écrire des applications déployables dans
tout conteneur OSGi (conforme à la norme) en tirant parti de différents services
normalisé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émentations
d’un même service.
Cet ensemble de spécifications s’attache à fournir une solution à la fois légère et efficiente, 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 Component Architecture) en réduisant le spectre au seul langage Java et focalisée sur une implémentation
mono-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érogènes communiquant par le biais de protocoles standardisés, afin de rendre l’ensemble indépendant des
choix technologiques (plates-formes matérielles, langages d’implémentation mis en œuvre…). C’est la
plus aboutie des mises en œuvre des principes de la SOA.
OSGi.book Page 15 Wednesday, December 21, 2011 12:51 PM
OSGi pour une conception modulaire
CHAPITRE 1
EN CLAIR
SCA
Software Component Architecture
SOA
Service Oriented Architecture
Depuis sa conception (1998), OSGi visait à résoudre les problèmes liés aux applications embarquées, un monde dans lequel toute ressource se doit d’être exploitée pleinement et toute dépense justifiée. C’est ainsi qu’un environnement OSGi complet
tel que Felix (l’implémentation du projet Apache) ne réclame que un ou
deux mégaoctets de RAM. Cet environnement constitue le socle pour accueillir
toute application, quel que soit son cadre de développement.
L’accent est mis sur la possibilité d’obtenir un système extrêmement dynamique, au
sein 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écouplage
entre composants.
Qu’en est-il cependant de la modularité promise ? Nous reviendrons sur le sujet plus
loin ; 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, la
plate-forme OSGi va permettre de remplacer n’importe quelle brique (bundle) par une
autre, 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é de
dépendance d’un composant envers l’autre. Dès lors qu’il y a couplage important
entre deux composants, il y a une plus grande difficulté en cas de changement et cela
influe sur la gestion des deux composants. Un couplage fort induit des modifications
dans le composant utilisateur, dès que l’on modifie le composant qu’il utilise.
Notez qu’on retrouve le même type d’effets lors de l’utilisation d’attributs en programmation orientée
objet classique et en cas de non-respect du principe fondamental de l’encapsulation.
Quant à l’injection de dépendances, elle est nécessaire lorsque l’implémentation d’un
composant peut requérir des services offerts par un autre composant en utilisant un
pattern de délégation. Le choix, au moment de la compilation, du composant qui va
réaliser ce service est un frein à l’évolution du produit car tout changement futur va
ré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
15
OSGi.book Page 16 Wednesday, December 21, 2011 12:51 PM
16
OSGi – Conception d’applications modulaires en Java
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 une
version dynamique de l’injection.
Les bundles OSGi
Dans le vocabulaire spécifique OSGi, un module déployé au sein de la plate-forme
OSGi est appelé un bundle. Par extension, dans le cas de la programmation RCP, on
devrait remplacer la notion de plug-ins par celle de bundles, mais les traditions restent. 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 le
fichier META-INF/MANIFEST.MF.
VOCABULAIRE RCP
RCP, pour Rich Client Platform, désigne un mode de déploiement et de programmation fournissant une
alternative aux interfaces web (et donc à leurs limitations) en autorisant des interfaces graphiques riches
en fonctionnalités. C’est l’option opposée aux clients dits légers puisqu’il s’agit là de déployer des applications s’appuyant sur l’environnement développé pour Eclipse (SWT et autres bibliothèques) ou autour
de 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’infrastructure
NetBeans RCP.
Les spécifications OSGi en détail
OSGi découle des travaux d’industriels et de spécialistes du logiciel regroupés au sein
d’une association : l’OSGi Alliance. Celle-ci gère des versions de spécifications qui
sont 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. Nous
verrons 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ées
aux 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 Eclipse
Libra. D’autres initiatives moins connues émanent de l’OSGi Alliance et ne sont
OSGi.book Page 17 Wednesday, December 21, 2011 12:51 PM
OSGi pour une conception modulaire
CHAPITRE 1
plus forcément d’actualité avec des projets autour de l’automobile notamment (VEG
pour Vehicule Expert Group).
Enfin, nous l’avons évoqué, l’architecture OSGi se rapproche de l’architecture SCA
avec les travaux menés sur Distributed OSGi visant à offrir une extension multiJVM des concepts offerts par OSGi. Parmi les différents produits sur le marché, on
peut citer Nimbus et Fabric de la société Paremus (http://www.paremus.com).
Implémentations OSGi
OSGI 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érence
basique fournie sur le site officiel, on peut citer :
• Equinox : l’implémentation OSGi du consortium Eclipse, la véritable moelle épiniè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é.
Nous reparlerons des conteneurs OSGi en fin de chapitre 4.
Eclipse n’est pas le seul produit à tirer bénéfice de cette plate-forme. On compte également 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 couplage), s’impose donc même sur ces environnements fort éloignés des cas d’utilisations
ciblés au départ qu’étaient les environnements légers pour applications embarquées.
17
OSGi.book Page 175 Wednesday, December 21, 2011 12:51 PM
Index
A
activate() 48
ANT 65–67
build-file 66
Ant 122
AOP - Aspect Oriented Programming 109, 157
Apache Ace 145
Apache Aries 16
Apache Celix 44
Apache Felix 15, 17, 22–23, 38–39, 56, 58, 60,
62, 66–67, 71, 91, 98, 105, 114, 133, 145,
150, 155
API 119
commande du shell 117
felix-scr 75
File-Install 121, 145
WebConsole 87
Apache Maven 60
API - Application Programming Interface 138
application
embarquée 4, 15, 29
J2EE 8
application embarquée 29
architecture orientée services 9
B
bibliothèque
Java 39
Java standard 154
bnd 32, 34–35, 41, 64–65, 75, 88, 90, 96, 98, 128,
154, 158
bndtools 113
description de bundle 49
bnd.bnd 36
bndtools 31, 33–34, 66, 75–76, 90–91
créer un projet 33
installation 32
broker de messages 93
bundle OSGi 8, 16, 31, 39, 50, 76, 88, 110
couplage/découplage 93
création 32, 34, 67
dépendance 59
déploiement 36, 43, 65, 67
descripteur 35–36, 46, 59, 66–67, 78, 85, 144,
158, 166
encapsulation 40–41, 59
gestion des versions 73, 126
Import-Package 35
méta-information 34, 65, 67–68
méthode main() 34
Private-Package 35
référentiel 58
Service-Component 35
test unitaire 119, 121
tester la conformité avec la norme 58
Bundle-Version 41
C
cardinalité 85
Castor XML 140
classe Java standard 34, 67
ClassLoader Java 10, 12
commande du shell 155
ConfigAdmin 100, 130
propriétaire de la configuration 103
conteneur OSGi 8, 14, 19, 34, 50, 56, 88
couplage/découplage d’application 9, 15, 31, 44,
49, 51, 53, 100, 110
couplage/découplage de composants 151
Cron4J 153, 155–156
D
DBC - Design By Contract 109, 128
OSGi.book Page 176 Wednesday, December 21, 2011 12:51 PM
OSGi – Conception d’applications modulaires en Java
176
Declarative Services 76, 85, 114, 130
dépendance 8, 48, 59, 68, 71
circulaire 137–138
Distributed OSGi 17
E
EAI - Enterprise Application Integration 10
EasyMock 111
Eclipse 17, 19, 21, 32–33, 40, 42, 52, 57–58,
65–68, 76, 91, 113, 122, 127, 158
bndtools 75, 154
Market Place 32
PDE 31, 56, 147
plug-in 5–6
Eclipse Libra 16
EJB - Enterprise Java Beans 138, 147
encapsulation 149
Enterprise OSGi 16
entrepôt de composants 60
environnement de développement 19
Equinox 17, 19, 36, 38–39, 52, 57–58, 62, 66, 145
API 119
ERP - Enterprise Resources Planning 7
Event Service 74
EventAdmin 92–93, 98
EventHandler 93
Export-Package 41, 45, 137
F
Fabric 17
File-Install 155
G
gabarit de conception 129
Factory 130
Whiteboard 130, 133, 137, 149
gestion
des périphériques 14
des préférences 14, 101
des traces 14, 88
des versions 125, 127–128, 146–147
getServiceReference() 48
GlassFish 17, 19–20, 56
Google GUICE 70
H
Hibernate 137
HttpService 98, 100, 130
whiteBoard 98
HttpService Whiteboard 134
I
IDE - Integrated Development Environment 5
implémentation OSGi 17
Import-Package 40, 59, 112
Include-Resource 158
injection de dépendance 14–15, 49, 69–71, 75, 81,
85, 105, 112, 115, 130, 138, 146, 149,
158–159
dynamique 72
invocation dynamique de code 137
IoC - Inversion of Control 70
iPOJO 67
iText 150, 153–155
Ivy 127, 138
J
JAAS - Java Authentication and Authorization
Service 7
JAR - Java ARchive 8, 35, 40, 64–65, 75, 154, 158
java.lang 140
java.lang.reflect 140
JBI - Java Business Integration 10
JBoss 17, 19
JCA - J2EE Connector Architecture 7
JDBC - Java DataBase Connectivity 7, 158
JDK - Java Development Kit 20
Jetty 98, 100, 130
JMS - Java Message Service 92–93, 138
JNDI - Java Naming and Directory Interface 7,
65, 138
JOnAS 17, 19, 21, 56, 65
classe de lancement 26
classe JOnAS 25
code source 24
script de lancement 22
shell OSGi 22
JPA - Java Persistence API 7, 16, 157
JTA - Java Transaction API 7
OSGi.book Page 177 Wednesday, December 21, 2011 12:51 PM
Index
JUnit 120
JVM - Java Virtual Machine 8, 28, 56, 58, 92
K
Karaf
API 119
Knopflerfish 17, 56, 58, 62
L
LDAP - Lightweight Directory Access
Protocol 7
LogService 51, 92, 95, 103
P
paquetage 35, 41
PDE - Plug-in Development Environment
66–67, 113, 169
planification de tâche 153, 156
POJO - Plain Old Java Object 67, 146–147
Posh 119
Private-Package 47
propriétaire de la configuration 103, 108
publication dynamique via HTTP 14
Q
M
Quartz 153, 156
MANIFEST.MF 28, 35, 40–41, 45, 48, 59,
64–65, 75, 112, 126, 128, 137, 147
Maven 65, 122, 126–127, 138, 147
META-INF/MANIFEST.MF 14, 16, 35, 50
méta-information 67, 70, 73, 112, 137, 147
micronoyau 22
modularité 110
MOM - Message Oriented Middleware 53, 93
R
N
NetBeans 58, 60
module 6
Nimbus 17
norme OSGi 14, 16
O
objet mock 111
OBR - OSGi Bundle Repository 56, 60
architecture 63
Oscar 56, 60
OSGi
chargement de classe 40
Declarative Services 67
environnement 55
plug-in de développement Eclipse 64
service 67
service de lancement d’un conteneur 27
OSGi Alliance 16, 58
OSGI-INF 85, 112
OSGI-OPT 73
RCP - Rich Client Platform 16, 68
S
SCA - Software Component Architecture 15, 17
SCR - Service Component Runtime 70–71, 75,
84, 88, 96, 105, 108, 114, 145
exemple d’utilisation 76
fonctionnalité 71
mise en œuvre 73
sérialisation/désérialisation de données 137, 140
serve@home 29
serveur d’applications 7
serveur J2EE 17
service OSGi 14, 35, 44, 51, 74, 114, 156
cardinalité 72
ConfigAdmin 88, 159
déclaration 70
Declarative Services 108, 151, 158–159
disponibilité 119–120
EventAdmin 72, 150–151
EventService 95, 149
HttpService 98, 133, 136, 150
LogReaderService 88
LogService 72, 87, 149
Metatype 87
par défaut 43
publier 44
test unitaire 121
Service-Component 47
ServiceReference 95, 98
177
OSGi.book Page 178 Wednesday, December 21, 2011 12:51 PM
178
OSGi – Conception d’applications modulaires en Java
ServiceTracker 50, 133
ServletTracker 135
shell OSGi 117, 145
ShutdowHookThread 28
ShutdownHookThread 27
SOA - Service Oriented Application 128
SOA - Services Oriented Architecture 9–10, 15,
68, 110, 136, 152
spécifications OSGi
Compendium 16
Core 16
SPOF - Single Point Of Failure 116
Spring 15, 71, 75, 157
Spring IOC 70
Spring-DM 73, 130, 146
SpringSource 127
SQLite 150, 154, 158–159
SRC 50
stratégie de bouchonnage 110
Swing 22–23, 101, 108, 150, 155
SWT 101
synchronized 81
T
test unitaire 109, 111
durée 124
environnement d’exécution 120
initialisation 120
TestNG 120–121, 124
Tomcat 100, 130
topic 93, 95
W
WebConsole 71, 88
Websphere 17
X
Xerial 158
OSGi.book Page 18 Wednesday, December 21, 2011 12:51 PM
Spécifications
Implémentations
Outils de
développement
Outils
d’administration
Core
BundleContext Bundle
Compendium
httpService LogService
Equinox
Knopflerfish
bnd
bndTools
gogo
Felix-stall
Felix
iPojo
Webconsole
spring