20100225 Ippon Osgi Are You Ready

1,297 views
1,232 views

Published on

Présentation Ippon Technologies Open-REX du 25/02
Speaker : Fabien Arrault
Présentation de l'état de l'art autour de OSGi

Published in: Technology, Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,297
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

20100225 Ippon Osgi Are You Ready

  1. 1. Document confidentiel - Ce document est la propriété exclusive d’Ippon Technologies et il ne peut être reproduit, publi é ou divulgu é sans son autorisation préalable Sommaire Effectifs par agence OSGi Are You Ready ? 25 Février 2010 Arrault Fabien Ippon Technologies
  2. 2. <ul><li>Cette présentation vous est fournie sous licence Creative Commons Attribution Share Alike
  3. 3. Vous êtes libres : </li><ul><li>De reproduire, distribuer et communiquer cette création au public </li></ul><li>Selon les conditions suivantes : </li><ul><li>Paternité. Vous devez citer le nom des auteurs originaux mais pas d'une manière qui suggérerait qu'ils vous soutiennent ou approuvent votre utilisation de l'œuvre.
  4. 4. A chaque réutilisation ou distribution de cette création, vous devez faire apparaître clairement au public les conditions contractuelles de sa mise à disposition sous licence identique Creative Commons Share Alike.
  5. 5. Chacune de ces conditions peut être levée si vous obtenez l'autorisation du titulaire des droits sur cette œuvre.
  6. 6. Rien dans ce contrat ne diminue ou ne restreint le droit moral de l'auteur ou des auteurs. </li></ul></ul>
  7. 7. Introduction <ul><li>OSGi : </li></ul><ul><ul><li>OSGi est une spécification définissant un système modulaire et dynamique pour Java
  8. 8. Il est défini par l'OSGi Alliance, consortium d'industriels fondé en 1999 </li></ul></ul>
  9. 9. Introduction <ul><li>Les utilisations de OSGi : </li></ul><ul><ul><li>Au début la spécification était très axée sur les systèmes embarqués, les applis mobiles, ... qui ont des besoins d'assemblage et de collaboration de composants indépendants avec des contraintes de poids des binaires.
  10. 10. Cette techno est maintenant utilisée comme socle technique interne de la plupart des serveurs d'applications ou d'IDE comme Eclipse </li></ul></ul>
  11. 11. Introduction <ul><li>Les implémentations de OSGi : </li></ul><ul><ul><li>L'implémentation prend la forme d'un framework très léger s'occupant en particulier du cycle de vie et de la mise en collaboration des composants </li></ul></ul><ul><ul><li>Plusieurs implémentations sont disponibles dont plusieurs OpenSource comme Equinox, Felix ou Knopflerfish </li></ul></ul>
  12. 12. Sommaire <ul><li>Les concepts de OSGi
  13. 13. Leurs mises en oeuvre avec dm Server
  14. 14. OSGi et les applications de gestion ? </li></ul>
  15. 15. <ul>Les concepts de OSGi </ul>Les concepts de OSGi http://www.osgi.org/About/WhatIsOSGi
  16. 16. Bundles <ul><li>Les bundles sont les composants à la base de la modularité de OSGi
  17. 17. Ce sont de archives java classiques (JARs) pour lesquelles le manifest contient des méta-données supplémentaires : </li></ul>Manifest-Version : 1.0 Bundle-ManifestVersion : 2 Bundle-Version : 1.0.0 Bundle-Name : Hello_world Bundle Bundle-SymbolicName : hello_world Bundle-Activator : com.ippon.osgi.Activator Import-Package : org.osgi.framework
  18. 18. Bundle Lifecycle <ul><li>Le framework OSGi gère le cycle de vie de chaque bundle : </li></ul>http://static.springsource.org/osgi/docs/current/reference/html/bnd-app-ctx.html#bnd-app-ctx:bnd-lifecycle
  19. 19. Dépendance Statique <ul><li>Les dépendances statiques entre bundle doivent être explicitement déclarées par chaque bundle : </li><ul><li>Un bundle peut exporter les packages java qu'il définit pour les rendre disponible aux autres bundles
  20. 20. Un bundle doit importer les packages java externes dont il a besoin </li></ul></ul>Imports package com.B Exports package com.B Imports package com.C Exports package com.C
  21. 21. Dépendance Statique <ul><li>Cela s'effectue via des entêtes du manifest : </li><ul><li>Export-Package
  22. 22. Import-Package </li></ul></ul>Manifest-Version : 1.0 Bundle-ManifestVersion : 2 Bundle-Version : 2.1.6 Bundle-Name : Logutil Bundle Bundle-SymbolicName : logutil Export-Package : com.ippon.osgi.util; version =2.1 Import-Package : org.apache.log4j; version =&quot;[1.2.15,1.2.15]&quot;
  23. 23. Dépendance Statique <ul><li>Classloading : </li><ul><li>Le runtime OSGi charge les classes de chaque bundle via un classloader qui lui est dédié
  24. 24. Ces classloader reliés entre eux à partir de ces méta-données d'export/import et se délèguent l'un l'autre le chargement des classes dont ils ont la responsabilité : </li></ul></ul><ul><ul><li>Cette délégation est donc bien plus riche (et bien plus complexe) que le mécanisme de classloading classique parent / enfant </li></ul></ul>Classloader A Loads all internal class from bundle Delegates load of class com.B.* Delegates load of class java.* Delegates load of class com.C.* Delegates load of class java.* Bundle A Import-Package: com.B, com.C Classloader B System Classloader Classloader C Bundle B Bundle C Export-Package: com.B Export-Package: com.C
  25. 25. Dépendance Dynamique <ul><li>Chaque bundle peut aussi définir des « services » qui sont à disposition des autres bundles. </li><ul><li>Un service est une instance d'une classe exposée sous une ou plusieurs interfaces.
  26. 26. Le « Service Registry » permet aux bundles d'exposer ou de rechercher puis utiliser des services </li></ul></ul>http://www.osgi.org/About/WhatIsOSGi
  27. 27. Dépendance Dynamique <ul><li>Les services peuvent apparaître ou disparaître de manière dynamique : </li><ul><li>Les bundles « actifs » peuvent proposer et retirer un service quand ils le souhaitent
  28. 28. Lorsqu'un bundle est arrêté, les services qu'ils exposent sont automatiquement retirés. </li></ul><li>Les bundles consommateurs doivent donc tracker la disponibilité des services qu'ils utilisent </li></ul>
  29. 29. Dépendance Dynamique <ul><li>Caractéristique d'un service : </li><ul><li>Service interfaces
  30. 30. Service property </li></ul><li>Sélection d'un service : </li><ul><li>Elle se fait avant tout sur une « Service Interface »
  31. 31. Mais un mécanisme de filtre permet aux bundles clients d'utiliser aussi les property pour sélectionner le ou les services qui les intéressent parmi les différents candidats </li></ul></ul>
  32. 32. Focus : Components Models <ul><li>Un certain nombre de frameworks/spec facilitent l'utilisation de OSGi en proposant des modèles de composants particuliers : </li><ul><li>Spring DM ( & spec. Blueprint Container )
  33. 33. spécification Declarative Services
  34. 34. Apache iPojo </li></ul><li>Spring Dynamic Modules for OSGi Service Platforms </li><ul><li>Framework dont le but est d'apporter la philosophie de Spring aux développements ciblant OSGi
  35. 35. A influencer très fortement la création de la spécification OSGi nommée « Blueprint Container ». La v2 est d'ailleurs son implémentation de référence </li></ul></ul>
  36. 36. Dépendance Dynamique <ul><li>Exemple d'utilisation de Spring DM : </li></ul><ul><ul><li>Export d'un bean sous forme d'un service OSGi :
  37. 37. Import d'un service dans le contexte Spring : </li></ul></ul>< beans xmlns = &quot;http://www.springframework.org/schema/beans&quot; xmlns:osgi = &quot;http://www.springframework.org/schema/osgi&quot; > < bean id = &quot;helloworldservice&quot; class = &quot;com.ippon.osgi.hello.HelloWorldSingleton&quot; /> < osgi:service ref = &quot;helloworldservice&quot; interface = &quot;com.ippon.osgi.publichello.HelloWorldService&quot; /> </ beans > < beans xmlns = &quot;http://www.springframework.org/schema/beans&quot; xmlns:osgi = &quot;http://www.springframework.org/schema/osgi&quot; > < osgi:reference id = &quot;helloworldservice&quot; interface = &quot;com.ippon.osgi.publichello.HelloWorldService&quot; /> < bean id = &quot;consumer&quot; class = &quot; com.ippon.osgi.client.HelloConsumer &quot; > < property name = &quot;service&quot; ref = &quot;helloworldservice&quot; /> </ bean > </ beans >
  38. 38. Dépendance statique vs. dynamique <ul><li>Dépendance statique : </li></ul><ul><ul><li>La dépendance s'utilise comme une librairie classique
  39. 39. Réutilisation d'une implémentation : couplage assez fort
  40. 40. Mais OSGi permet de limiter le couplage aux apis publics de l'implémentation </li></ul></ul><ul><li>Dépendance dynamique : </li><ul><li>On est sur une vraie approche orientée-service (SOA)
  41. 41. On ne partage pas une implémentation, on obtient la référence à un objet avec lequel collaborer
  42. 42. Permet un remplacement dynamique du service : nouvelle implémentation ou nouvelle configuration, etc … </li></ul></ul>
  43. 43. Versioning <ul><li>Chaque bundle, chaque package est versionné.
  44. 44. Les dépendances peuvent exprimer des contraintes sur les versions nécessaires
  45. 45. Dans le manifest ci-dessous : </li></ul><ul><ul><li>Le bundle est en version 2.1.6
  46. 46. Il exporte un package en version 2.1
  47. 47. Il importe le package org.apache.log4j avec une contrainte sur la version : minimum 1.2.15 et strictement inférieure à 1.3 </li></ul></ul>Manifest-Version : 1.0 Bundle-ManifestVersion : 2 Bundle-Version : 2.1.6 Bundle-Name : Logutil Bundle Bundle-SymbolicName : logutil Export-Package : com.ippon.osgi.util; version =2.1 Import-Package : org.apache.log4j; version =&quot;[1.2.15,1.3)&quot;
  48. 48. Versioning <ul><li>OSGi supporte le déploiement simultané de plusieurs versions d'un bundle
  49. 49. La situation suivante, bien qu'impossible à gérer avec un classloading basique, est ainsi supportée : </li><ul><li>( Mais cela ne fonctionnera correctement que si B ne renvoie pas à A des objets de Util v1.0, ce qui induirait des ClassCastException dans A. La directive « uses » de OSGi permet d'exprimer des contraintes interdisant alors cette situation) </li></ul></ul>Import-Package Import-Package Import-Package
  50. 50. SpringSource dm Server Mise en oeuvre OSGI avec SpringSource dm Server
  51. 51. SpringSource dm Server <ul><li>SpringSource Dm Server </li></ul><ul><ul><li>Première version dévoilée par SpringSource à la mi-2008
  52. 52. Premier serveur d'applications java dont le but est de proposer les fonctionnalités de OSGi aux applications hébergées
  53. 53. La version 2.0 est sortie le 12 janvier 2010 </li></ul></ul><ul><li>Projet Virgo </li><ul><li>Lors de la sortie de la V2, SpringSource a proposé de donner dm Server à la fondation Eclipse sous le nom de Virgo
  54. 54. La création du projet a été « approuvée » hier (24/02) </li></ul></ul>
  55. 55. SpringSource dm Server <ul><li>SpringSource dm Server est basée sur : </li></ul><ul><ul><li>Equinox : l'implémentation OSGi de la fondation Eclipse
  56. 56. Tomcat : pour gérer les applications Web servlet/jsp … </li></ul></ul><ul><ul><ul><li>En particulier les War classiques sont gérés par dm Server sans modification </li></ul></ul></ul><ul><ul><li>Il intégre les frameworks Spring et Spring DM.
  57. 57. Sans être obligatoire, le développement avec ces deux frameworks est facilité </li></ul></ul>
  58. 58. Bundle provisioning <ul><li>dm Server permet de placer les bundles utilisés par les applications dans un repository local </li><ul><li>dm Server utilise ces bundles à la demande suivant les besoins des applications déployées
  59. 59. Mais il est nécessaire d'y placer des librairies correctement osgi-ifiées. </li></ul><li>SpringSource Enterprise Bundle Repository contient de telles librairies </li><ul><li>SpringSource y a mis un ensemble de librairies open-source contenant les méta-données OSGi nécessaires
  60. 60. L'url est : http://www.springsource.com/repository/app/
  61. 61. Attention, le repository est ouvert mais le packaging des librairies est toutefois spécifique à SpringSource ( et pas forcément compatible avec d'autres repository ) </li></ul></ul>
  62. 62. Gestion des dépendances <ul><li>dm Server introduit des extensions à OSGi : </li><ul><li>Directive Import-Bundle : </li><ul><li>permet d'importer tous les packages exportés par un bundle donné (légèrement différent de Require-Bundle présent dans OSGi) </li></ul><li>Directive Import-Library : </li><ul><li>permet d'importer plusieurs bundles à la fois (la liste des bundles d'une librairie est décrite dans un fichier spécial .libd à placer dans le repository du serveur) </li></ul></ul><li>Leur utilisation permet de faciliter la déclaration des dépendances lorsqu'on n'a pas besoin de contrôler finement les packages accessibles </li></ul>
  63. 63. Apports de Dm Server & Spring DM <ul><li>dm Server et Spring DM apporte des améliorations par rapport à un environnement OSGi nu : </li><ul><li>Possibilité de gérer le Thread Context ClassLoader : </li><ul><li>Spring DM : peut le positionner avec le classloader du bundle appelant un service ou du bundle implémentant le service
  64. 64. dm Server crée un TCL global pour les PAR </li></ul><li>Gestion du classpath scanning : </li><ul><li>Les ApplicationContext Osgi créés par Spring DM sont capables pour retrouver des ressources dans l'ensemble du Bundle Space : classes annotées, pattern de recherche, etc …
  65. 65. dm Server a adapté Equinox pour permettre cela (exposition des jars sur le filesystem dans les URLs renvoyés par les classloaders) </li></ul><li>Load time weaving : </li><ul><li>Pour charger les bundles, dm Server utilise des classloaders instrumentables individuellement. Ils sont compatibles nativement avec les mécanismes de load time weaving de Spring, permettant sans configuration supplémentaire d'utiliser AspectJ et les implémentations JPA nécessitant du LTW. </li></ul></ul></ul>
  66. 66. Typologie de déploiement <ul><li>SpringSource propose une adoption graduelle de OSGi : </li></ul><ul><ul><li>War classique, contenant les librairies nécessaires dans WEB-INF/lib
  67. 67. War allégé et librairies partagées : le war n'inclue plus les lib, il utilise les mécanismes OSGi pour déclarer ces dépendances. Les librairies sont partagées par toutes les applications.
  68. 68. War consommateur de services : idem avec utilisation de services exposées via OSGi </li></ul></ul>Schéma extrait de http://static.springsource.org/s2-dmserver/2.0.x/programmer-guide/html/ch05.html#migrating-to-osgi-web
  69. 69. Quelques alternatives <ul><li>Notons que d'autres approches existent sur les serveurs d'application OSGi : </li><ul><li>GlassFish V3 et JOnAS 5 proposent tous les deux le déploiement des bundles OSGi avec une intégration avec les composants Jave EE : Servlet et EJB
  70. 70. Cela pourra peut-être inciter les serveurs d'application commerciaux à faire de même et promouvoir ce modèle de développement </li></ul></ul>
  71. 71. Démo Démonstration : Déploiement de quelques bundles sous dm Server Et mise en oeuvre des concepts de base de OSGi
  72. 72. OSGi et les applications de gestion ?
  73. 73. Contexte <ul><li>Prenons comme contexte une application de gestion classique : </li><ul><li>Application décomposée en couche, potentiellement distribuée avec un front end web
  74. 74. Utilisant un grand nombre de librairies Open Source et en particulier Spring Framework
  75. 75. Méthodologies SOA et Agile
  76. 76. Organisation : un ou plusieurs équipes de dev avec plus ou moins de débutants
  77. 77. Une équipe de production qui installe et gère l'application
  78. 78. Un client exigeant </li></ul><li>OSGi nous aide-t-il ? </li></ul>
  79. 79. Librairies <ul><li>Gestion des librairies </li><ul><li>OSGi capable de gérer beaucoup de librairies disparates : </li><ul><li>partage des librairies entre applications => gain de mémoire potentiellement significatif ( mais des serveurs J2EE classiques le proposent aussi )
  80. 80. capable de gérer sans problème les conflits entre dépendance de différentes librairies </li></ul><li>Attention toutefois, dans certains cas, il est nécessaire d'avoir un arbre de dépendance consistant : </li><ul><li>L'utilisation d'un repository de bundles (tel que l'EBR de SpringSource) simplifie fortement les choses.
  81. 81. mais au prix d'un couplage fort avec celui-ci : on devient ainsi dépendant de son cycle de mise à jour et sa complétude </li></ul></ul></ul>
  82. 82. Librairies <ul><li>Utilisation de Spring Framework : </li><ul><li>Spring dm est particulièrement attractif dans ce contexte : </li><ul><li>bootstrap automatique du context Spring de chaque module
  83. 83. chaque module restant indépendant </li></ul><li>« Garantie » (?) d'interopérabilité avec OSGi, étant donné l'investissement de SpringSource </li></ul></ul>
  84. 84. Librairies <ul><li>Gestion des dépendances entre modules : </li><ul><li>Leur gestion explicite dans OSGi apporte de la complexité mais aussi plus de contrôle : </li><ul><li>Contrôle au niveau package (limité auparavant au niveau des membres d'une classe)
  85. 85. Intéressant surtout si plusieurs équipes interagissent
  86. 86. Le JDK 7 devait inclure la notion de module (super-packages /JSR 294) qui répond au même besoin (mais semble être au point mort) </li></ul><li>A relativiser toutefois : </li><ul><li>les outils de génération de manifest (bnd, bundlor, ...) seront certainement adoptés par la majorité des utilisateurs
  87. 87. ils réduisent voire éliminent la complexité de gestion de dépendance
  88. 88. Mais comme par défaut ils exportent tous les packages du bundle et importent tous les packages dont il a besoin, certains pourront ne pas tirer parti du contrôle d'accès </li></ul></ul></ul>
  89. 89. SOA <ul><li>Approche SOA </li><ul><li>OSGi partage la même philosophie que les démarches SOA
  90. 90. Un service OSGi a les même caractéristiques qu'un service au sens SOA </li><ul><li>On peut envisager un mapping 1-1 entre implémentation et conception </li></ul><li>La gestion du versioning dans OSGi prend tout son sens dans le cadre de SOA : </li><ul><li>Le versioning des services est souvent nécessaire dans une telle approche.
  91. 91. Hors exposer simultanément différentes versions d'un service (associé aux versioning de leurs dépendances) est souvent problématique dans une approche classique. </li></ul></ul></ul>
  92. 92. Dynamicité <ul><li>Dynamicité de OSGi pour le déploiement </li><ul><li>surtout utile en phase développement
  93. 93. en production : les processus de livraison sont souvent gérés par des équipes différentes avec passage par une phase de qualification qui rend difficile la livraison d'une partie de l'application
  94. 94. le besoin n'est pas forcément là. </li></ul><li>Dynamicité de OSGi au niveau des services : </li><ul><li>Besoin assez rare au sein même d'une même application
  95. 95. Des approches classiques de type Proxy dynamique permettent de gérer ce use case (côté client) </li></ul></ul>
  96. 96. J2EE like <ul><li>Gestion des application distribuées : </li><ul><li>La spécification OSGi « Remote Services » est récente : elle fait partie de OSGi 4.2 datant de Sept 2009
  97. 97. Les implémentations existent : </li><ul><li>Apache CXF
  98. 98. Eclipse Communication Framework (ECF) </li></ul><li>D'autres solutions non « standard » existent : </li><ul><li>r-OSGi </li></ul><li>Toutefois, on reste dans le monde Java, rien n'empêche d'appeler un Web Service, un EJB, … exposé par un autre système non-OSGi </li></ul></ul>
  99. 99. J2EE like <ul><li>Les apis j2ee : JDBC, JTA, JMS, JPA ... </li><ul><li>Dans le cas de dm Server ou d'un framework OSGi nu : </li><ul><li>Ces apis sont disponibles via l'utilisation de librairies open-source spécialisées
  100. 100. Leurs utilisations nécessitent parfois des adaptations ou sont soumises à certaines contraintes
  101. 101. Elles ne sont pas pré-packagés
  102. 102. Assez simple à mettre en oeuvre sur des cas simples mais l'intégration entre toutes ces technologies n'est pas immédiate </li></ul><li>GlassFish et JOnAS sont sûrement de meilleurs candidats par rapport à ces aspects </li></ul></ul>
  103. 103. Mise en prod ? <ul><li>Comment livrer une application OSGi ? </li><ul><li>Nécessité de modifier les habitudes j2ee, dm Server introduit la notion de PAR, équivalent des EARs j2ee, regroupant les bundles applicatifs. Mais pour profiter de OSGi, il est nécessaire de mettre en place de nouvelles procédures
  104. 104. Nécessité de gérer le provisionning de l'environnement d'exécution : </li><ul><li>avoir les bons bundles dans les bonnes versions pour satisfaire les dépendances des applications déployées
  105. 105. rq : dm Server V2 est capable d'aller chercher ces dépendances dans un remote repository </li></ul><li>De plus, les équipes de QA voudront sûrement s'assurer que ce sont exactement les versions testées qui seront utilisés : comment le garantir ? </li></ul></ul>
  106. 106. Maturité des intervenants <ul><li>Les développeurs sont/seront-ils prêts ? </li><ul><li>OSGi manipule des concepts assez pointus de Java, en particulier en terme de classloading
  107. 107. La plupart du temps, c'est souvent un détail transparent pour les développeurs
  108. 108. Mais les cas aux limites seront difficiles à comprendre/gérer pour des développeurs non aguerris </li></ul></ul>
  109. 109. Conclusion <ul><li>OSGi propose beaucoup de fonctionnalités intéressantes : </li><ul><li>Très bonnes fondations techniques adaptables à des situations aux limites
  110. 110. Approche fortement orientée service très attractive </li></ul><li>Mais : </li><ul><li>Les outils de développement/d'exécution se mettent en place mais tous les besoins &quot;Enterprise&quot; ne sont pas forcément encore packagés
  111. 111. Difficile d'avoir de la visibilité sur l'utilisation d'OSGi sur des projets avec un minimum d'envergure
  112. 112. Le plus gros point est le manque d'expertise et de support pour des projets critiques </li></ul></ul>
  113. 113. Conclusion <ul><li>Toutefois ses qualités appellent à : </li><ul><li>Suivre de prêt l'évolution des implémentations </li><ul><li>Standardisation (en particulier dans l'intégration OSGi / J2EE)
  114. 114. Maturation (dmServer devenu Virgo, Apache Aries, ...) </li></ul><li>Identifier les opportunités de mise en place sur des projets peu critiques ou des prototypes afin de gagner en visibilité
  115. 115. Sensibiliser les équipes de dev et de prod à cette alternative grandissante </li></ul></ul>
  116. 116. Ressources <ul><ul><li>OSGi Alliance : </li><ul><li>http://www.osgi.org/
  117. 117. http://www.osgi.org/blog/ </li></ul><li>SpringSource dm Server : </li><ul><li>http://www.springsource.org/dmserver </li></ul><li>Spring Dynamic Modules for OSGi Service Platforms : </li><ul><li>http://www.springsource.org/osgi </li></ul><li>Une pres. de Rod Johnson très sympa : </li><ul><li>http://www.infoq.com/presentations/dm-Server-Rod-Johnson </li></ul><li>Les posts OSGi du Blog de SpringSource : </li><ul><li>http://blog.springsource.com/category/osgi/ </li></ul><li>Apache Aries : </li><ul><li>http://incubator.apache.org/aries/ </li></ul><li>Apache CXF – Distributed OSGi : </li><ul><li>http://cxf.apache.org/distributed-osgi.html </li></ul></ul></ul>

×