OSGi, c’est de la balle

disclaimer : Pour les non javaistes qui me lisent, attention, ce post est exceptionnellement techno-technique

Depuis deux semaines, je découvre un nouveau pan des énormes possibilités de l'informatique "d'entreprise" en Java : OSGi.
Bon, comme je n'ai pas l'intention de vous faire un post didactique (le web en est plein), je vais juste commencer par une petite rafale de liens sur le sujet.
Bon, si vous avez lu ces articles, vous aurez compris qu'OSGi est un cadriciel (ou plutôt framework) permettant de créer facilement des applications à base de composant. La différence avec, je sais pas, moi, Spring ou JEE, c'est qu'à cause d'un passé différent, OSGi ne met pas la même chose derrière le terme de composant. Ici, un composant peut être arrêté, redémarré, sans que la plateforme s'arrête. D'ailleurs, dans le cas où un composant s'arrête, ses dépendances seront notifiées et pourront se désactiver automatiquement. Dépendances ?
Oui, dépendances. le secret d'une architecture orientée composant, c'est qu'un composant A peut avoir besoin d'un composant identifé B (ou plutôt, dans le cas d'OSGi, une version d'un composant identifié). Bon, d'habitude, quand on met côte à côte des composants, des dépendances, des version, on pense maven. Et ça tombe bien, parce que grâce au travail d'équipes du monde de l'open-source, il existe des moyens de bien faire travailler ensemble maven et OSGi :
  • maven-bundle-plugin permet de prendre un projet maven et de le packager en tant que bundle osgi. Les dépendances seront correctement déclarées dans le MANIFEST.MF, mais les Export-Package et Private-Package devront encore être définis à la main, mais dans le pom.xml, ce qui est raisonnablement censé. Bon, c'est pratique, mais il faut encore avoir à côté un conteneur OSGi (qui permet de lancer le paquet de bundles) pour tester l'appli
  • pax permet d'embarquer tout ça dans un projet maven d'une manière assez musclée, mais efficace. Celui-là est largement plus costaud que le précédent, mais coup de bol, son utilisation est largement documentée dans le handbook maven de Sonatype.
  • Et pour finir, si vous voulez approcher de l'IoC (ce que OSGi ne permet pas vraiment à la base), iPOJO va vous fournir un paquet d'outils pour développer vos bundles tranquillement (en particulier une tâche maven d'automatisation). Bon, je n'ai pas encore testé l'intégration d'iPOJO à pax, mais à mon avis, tant que les dépendances sont présentes (donc le bundle iPOJO, et deux ou trois autres trucs), tout va bien !
Bon, avec ça, vous avez un rapide tour d'horizon de ma caisse à outils OSGi, dont le but est de développer des applications rapidement, confortablement, et sans être trop embêté par la cuisine interne. Et je suis sûr qu'en vrai, c'est pas ça qui vous intéresse. Ce qui vous intéresse (si vous êtes arrivés jusque là) c'est ce que j'en pense.

Pendant longtemps, j'ai un avis défavorable sur OSGi. je savais qu'Eclipse l'utilisait, mais je savais aussi que c'était le seul cas connu d'utilisation "grand public" d'OSGi. Ces derniers temps, les choses ont changé. Les serveurs d'applications utilisent maintenant presque tous OSGi comme socle technique. Une bibliothèque comme Sling utilise OSGi car ça permet une très forte modularité à un cout assez faible, avec en bonus des fonctionnalités super intéressantes. Et puis finalement, quand on regarde le getting started de Felix, et encore plus quand on le suit pas à pas, OSGi n'est pas plus compliqué que, je sais moi, Guice. En fait, à l'heure actuelle (justement pour faire le parallèle avec Guice) la seule chose qui ne soit pas complètement parfaite, c'est le coté IoC. même si on utilise les très pratiques annotations iPOJO, on doit encore déclarer ses instances séparément (ce qui vide à mon avis l'IoC de son concept). Heureusement, les choses évoluent rapidement dans le monde OSGi (à mon avis grâce à l'adoption massive par les serveurs d'application JEE), et l'équipe Felix me promet que la prochaine version permettra de se passer totalement des fichiers de déclaration XML.

C'est bien simple, je n'envisage maintenant plus mes projets de la même manière (c'est-à-dire sans OSGi), et je crois même que je vais migrer certains de Guice à OSGi si j'arrive à comprendre comment faire pour livrer un JAR exécutable avec pax (le top absolu serait de réussir à lancer une application OSGi via Java Web Start, cela dit, j'ai confiance)
Publicités

2 réflexions sur “OSGi, c’est de la balle

  1. Article qui donne envie de s’y mettre. Cependant dans mes recherches sur ce framework je suis tomb?? sur des vagues bruit de couloir comme quoi OSGI a des probl??mes li??s ?? des fuites m??moire.T’en as entendu parler?

  2. <div>Non.</div><div>Cela dit, les memory leaks, c'est plus souvent li?? ?? une impl??mentation foireuse qu'?? autre chose.</div><div>Autrement dit, ??a peut toucher un fournisseur OSGi (genre <a href="https://jira.springsource.org/browse/OSGI-161?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel">Spring OSGi</a>), mais pas la norme en elle-m??me.</div> <div>Et dans la mesure o??, par exemple, OSGi est ?? la base d'Eclipse, et ??galement tr??s utilis?? dans l'embarqu??, je pense que, si il y avait des probl??mes structurels impliquant des memory leaks, on en aurait entendu parler en long, en large, et en travers, non ?</div>

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s