{"id":655,"date":"2011-01-13T11:42:01","date_gmt":"2011-01-13T10:42:01","guid":{"rendered":"http:\/\/www.alpesjug.fr\/?p=655"},"modified":"2011-01-13T16:38:17","modified_gmt":"2011-01-13T15:38:17","slug":"compte-rendu-soiree-osgi-par-clement-escoffier","status":"publish","type":"post","link":"https:\/\/www.alpesjug.fr\/?p=655","title":{"rendered":"Compte-rendu soir\u00e9e OSGi par Cl\u00e9ment Escoffier"},"content":{"rendered":"<p>Cl\u00e9ment Escoffier (<a href=\"http:\/\/twitter.com\/clementplop\">Twitter<\/a>, <a href=\"http:\/\/www.linkedin.com\/in\/clementescoffier\">LinkedIn<\/a>), architecte chez Akquinet et PMD sur le projet Apache Felix, est venu nous pr\u00e9senter OSGi mardi dernier.<\/p>\n<p>Il a commenc\u00e9 par expliquer rapidement ce qu&rsquo;est OSGi et \u00e0 qui ce framework est destin\u00e9.\u00a0Pour r\u00e9sumer ses propos, OSGi est une sp\u00e9cification d&rsquo;un framework qui a pour but de concevoir et d&rsquo;ex\u00e9cuter des applications hautement dynamiques. Ce qui a pour\u00a0 cons\u00e9quence de les modulariser fortement. Ceci permet d&rsquo;all\u00e9ger la maintenance et l&rsquo;exploitation de syst\u00e8mes relativement complexes (plus d&rsquo;un millions de lignes de code d&rsquo;apr\u00e8s cl\u00e9ment).<\/p>\n<p>Dans la suite de sa pr\u00e9sentation, Cl\u00e9ment a pass\u00e9 en revue les diff\u00e9rentes couches qui composent le framework :<\/p>\n<ul>\n<li>La couche <strong>Module<\/strong> : qui impl\u00e9mente les concepts de base d&rsquo;OSGi (bundle, r\u00e9solution de d\u00e9pendances, &#8230;)<\/li>\n<li>La couche <strong>Lifecylce<\/strong> : qui d\u00e9finit le cycle de vie des diff\u00e9rentes entit\u00e9s du framework \u00e0 commencer par les bundle pr\u00e9sents sur une plateforme et le tout totalement \u00e0 chaud (sans red\u00e9marrage de la machine virtuelle)<\/li>\n<li>La couche <strong>Service<\/strong> : qui fournit et permet de d\u00e9finir des service de haut niveau se basant sur les couches\u00a0pr\u00e9c\u00e9dentes. C&rsquo;est cette couche qui permet la haute dynamicit\u00e9 des applications.<\/li>\n<\/ul>\n<p>Selon Cl\u00e9ment, OSGi prend tout son sens avec la couche service. S&rsquo;arr\u00eater dans la conception de son application \u00e0 l&rsquo;une des deux autres couches, c&rsquo;est de ne pas profiter de ce qui fait la force du framework, <strong>l&rsquo;utiliser uniquement afin de modulariser son application est une grossi\u00e8re erreur<\/strong> et ouvre la porte \u00e0 de fortes d\u00e9ceptions et potentiellement \u00e0 de gros probl\u00e8mes.<\/p>\n<h3>La couche Module<\/h3>\n<p>Cl\u00e9ment nous a d\u00e9crit le concept de bundle qu&rsquo;il pr\u00e9sente comme une sorte de jar \u00e9tendu. En effet, le format jar n&rsquo;est pas r\u00e9ellement boulevers\u00e9 pour cr\u00e9er un bundle \u00e0 deux diff\u00e9rences majeures : le fichier MANIFEST contient plus d&rsquo;informations (description\u00a0des d\u00e9pendances entre bundles, de visibilit\u00e9 du code interne) et la possibilit\u00e9 de ne publier qu&rsquo;une sous partie du bundle vers l&rsquo;ext\u00e9rieur (export) rendant ainsi invisible aux yeux des autres bundles le code non sp\u00e9cifi\u00e9 comme export\u00e9.<\/p>\n<p><em>Pr\u00e9cisions importantes<\/em> : il est obligatoire de pr\u00e9ciser dans un bundle l&rsquo;ensemble des d\u00e9pendances (import) dont il d\u00e9pend et OSGi se base sur les packages pour son syst\u00e8me d&rsquo;import\/export de code entre bundles, ainsi il est impossible de n&rsquo;exporter qu&rsquo;une seule classe d&rsquo;un package Java donn\u00e9 (il faudra organiser son code en fonction).<\/p>\n<h3>La couche Lifecycle<\/h3>\n<p>C&rsquo;est durant cette partie que l&rsquo;on a commenc\u00e9 \u00e0 voir du code (du vrai !), en effet, la sp\u00e9cification d\u00e9finit des API d&rsquo;administration \u00e0 impl\u00e9menter par les plateforme OSGi permettant de g\u00e9rer le cycle de vie des bundles (chargement\/d\u00e9chargement\/d\u00e9marrage\/arr\u00eat\/mise \u00e0 jour).<\/p>\n<p>Le framework permet aussi de d\u00e9finir des <strong><a href=\"http:\/\/www.osgi.org\/javadoc\/r4v42\/org\/osgi\/framework\/BundleActivator.html\">Activator<\/a><\/strong> qui sont utilis\u00e9s par le bundle pour s&rsquo;initialiser lors des phases de d\u00e9marrage ou encore des <strong><a href=\"http:\/\/www.osgi.org\/javadoc\/r4v42\/org\/osgi\/framework\/BundleListener.html\">BundleListener<\/a><\/strong> qui \u00e9coutent l&rsquo;arriv\u00e9e d&rsquo;\u00e9v\u00e8nements pr\u00e9cis li\u00e9s au cycle de vie d&rsquo;un bundle dans le syst\u00e8me OSGi. Puisqu&rsquo;il est possible d&rsquo;ajouter\/retirer\/activer ou\u00a0d\u00e9sactiver\u00a0des bundles \u00e0 chaud il devient n\u00e9cessaire de pouvoir r\u00e9agir dans les autres bundles \u00e0 ces \u00e9v\u00e8nements.<\/p>\n<p>Ce sont ces m\u00e9canismes \u00e9v\u00e8nementiels du cycle de vie d&rsquo;un bundle qui permettent de cr\u00e9er via OSGi une <strong>extensibilit\u00e9 dynamique<\/strong>. Cl\u00e9ment nous a d&rsquo;ailleurs pr\u00e9sent\u00e9 un pattern de conception OSGi permettant de g\u00e9rer clairement ces \u00e9v\u00e8nements : l&rsquo;<strong><a href=\"http:\/\/felix.apache.org\/site\/extender-pattern-handler.html#ExtenderPatternHandler-TheExtenderpattern\" target=\"_blank\">Extender Pattern<\/a><\/strong><\/p>\n<h3>La couche Service<\/h3>\n<p>D&rsquo;apr\u00e8s Cl\u00e9ment,<strong> les d\u00e9veloppeurs OSGi doivent se focaliser sur cette couche <\/strong>et d\u00e9l\u00e9guer les\u00a0pr\u00e9c\u00e9dentes\u00a0aux plateformes sur lesquelles ils feront tourner leur applications. OSGi permet de d\u00e9clarer des services qui sont publi\u00e9s dans un <strong>Service Registry<\/strong>, les consommateurs de service pourront\u00a0requ\u00eater cet annuaire pour r\u00e9cup\u00e9rer le service et se lier \u00e0 lui de mani\u00e8re directe (pas de proxy, pas d&rsquo;interm\u00e9diaire quelconque comme dans Spring par exemple : simple, efficace).<\/p>\n<p>La cr\u00e9ation et la publication de services OSGi implique g\u00e9n\u00e9ralement un d\u00e9couplage de l&rsquo;interface de l&rsquo;impl\u00e9mentation permettant de masquer aux bundles consommateurs la\u00a0complexit\u00e9\u00a0de r\u00e9alisation et les contraintes techniques (r\u00e9seau, base de donn\u00e9es, &#8230;).\u00a0Les bundles publient des services via le <strong><a href=\"http:\/\/www.osgi.org\/javadoc\/r4v42\/org\/osgi\/framework\/BundleContext.html\">BundleContext<\/a><\/strong> et le font g\u00e9n\u00e9ralement par le biais des <strong>Activator<\/strong> dont on a parl\u00e9 juste au-dessus.<\/p>\n<h3>Et apr\u00e8s ? On y passe comment ?<\/h3>\n<p>Jusqu&rsquo;\u00e0 ce point, OSGi para\u00eet tout beau, tout gentil mais attention ! Ce n&rsquo;est pas pour rien que de gros projet on fait machine arri\u00e8re (Mule ESB par exemple). En effet, le passage \u00e0 OSGi n\u00e9cessite de prendre en compte ce qu&rsquo;habituellement on laisse faire \u00e0 nos plateformes : classloading avanc\u00e9, synchronisation et gestion des acc\u00e8s concurrents, et le packaging.<\/p>\n<p>Heureusement, Cl\u00e9ment souligne qu&rsquo;il existe d\u00e9j\u00e0 plusieurs moyens de se faciliter la t\u00e2ches, les IDEs, \u00a0les outils de builds et de packaging (plugins eclipse et maven, &#8230;) . Il a plus particuli\u00e8rement insist\u00e9 sur <a href=\"http:\/\/felix.apache.org\/site\/apache-felix-ipojo.html\">iPOJO<\/a> qui permet de simplifier la cr\u00e9ation de services OSGi en manipulant des annotations Java (le XML c&rsquo;est sale !) sur de simples POJO (ou interfaces). \u00a0Cet outil, qu&rsquo;il a utilis\u00e9 dans ses d\u00e9monstrations, propose aussi une console d&rsquo;administration web qui permet de parcourir l&rsquo;\u00e9tat de la plateforme OSGi (bundles pr\u00e9sents, services avec leur \u00e9tat, &#8230;).<\/p>\n<p>Pour conclure, on retiendra qu&rsquo;OSGi est puissant, pas encore utilis\u00e9 \u00e0 sa juste valeur (par exemple, l&rsquo;IDE Eclipse qui l&rsquo;utilise partout n&rsquo;exploite pas la couche Service) et poss\u00e8de de nombreux outils qui r\u00e9duisent grandement la complexit\u00e9 inh\u00e9rent \u00e0 la nature d&rsquo;OSGi. Cependant, on retiendra aussi que celui-ci se destine essentiellement \u00e0 des applications n\u00e9cessitant de la modularit\u00e9 et de la dynamicit\u00e9 et que ces besoins doivent \u00eatre clairement identifi\u00e9s avant d&rsquo;engager un &#8211; co\u00fbteux &#8211; passage \u00e0 OSGi. C&rsquo;est aussi pour ces raisons que des IDE et des serveurs d&rsquo;applications JEE ont choisi OSGi comme socle.<\/p>\n<p>Merci Cl\u00e9ment.<\/p>\n<p><strong><br \/>\n<a href=\"http:\/\/www.alpesjug.fr\/wp-content\/uploads\/2011\/01\/osgi-beyond-the-myth-LQ.pdf.zip\">T\u00e9l\u00e9charger les slides : OSGI  &#8211; Beyond the Myth<\/a><\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Cl\u00e9ment Escoffier (Twitter, LinkedIn), architecte chez Akquinet et PMD sur le projet Apache Felix, est venu nous pr\u00e9senter OSGi mardi dernier. Il a commenc\u00e9 par expliquer rapidement ce qu&rsquo;est OSGi et \u00e0 qui ce&#46;&#46;&#46;<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[15,18],"tags":[4,40,11],"class_list":["post-655","post","type-post","status-publish","format-standard","hentry","category-compte-rendu","category-slides","tag-jug","tag-osgi","tag-soiree"],"_links":{"self":[{"href":"https:\/\/www.alpesjug.fr\/index.php?rest_route=\/wp\/v2\/posts\/655","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.alpesjug.fr\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.alpesjug.fr\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.alpesjug.fr\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.alpesjug.fr\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=655"}],"version-history":[{"count":32,"href":"https:\/\/www.alpesjug.fr\/index.php?rest_route=\/wp\/v2\/posts\/655\/revisions"}],"predecessor-version":[{"id":689,"href":"https:\/\/www.alpesjug.fr\/index.php?rest_route=\/wp\/v2\/posts\/655\/revisions\/689"}],"wp:attachment":[{"href":"https:\/\/www.alpesjug.fr\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=655"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.alpesjug.fr\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=655"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.alpesjug.fr\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=655"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}