Le document traite d'OSGi, une spécification pour un système modulaire et dynamique en Java, en abordant ses concepts, son cycle de vie, et la gestion des dépendances entre les composants. Il présente également les implémentations d'OSGi, notamment le 'SpringSource DM Server', et discute de leur utilisation dans des environnements d'application. Enfin, il présente des alternatives et des méthodologies de développement, notamment en lien avec des frameworks comme Spring, tout en soulignant la gestion des versions et la dynamique des services.

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. Cette présentation vous est fournie sous licence Creative Commons Attribution Share Alike

3. Vous êtes libres : De reproduire, distribuer et communiquer cette création au public Selon les conditions suivantes : 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. 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. Chacune de ces conditions peut être levée si vous obtenez l'autorisation du titulaire des droits sur cette œuvre.

6. Rien dans ce contrat ne diminue ou ne restreint le droit moral de l'auteur ou des auteurs.

7. Introduction OSGi : OSGi est une spécification définissant un système modulaire et dynamique pour Java

8. Il est défini par l'OSGi Alliance, consortium d'industriels fondé en 1999

9. Introduction Les utilisations de OSGi : 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. Cette techno est maintenant utilisée comme socle technique interne de la plupart des serveurs d'applications ou d'IDE comme Eclipse

11. Introduction Les implémentations de OSGi : 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 Plusieurs implémentations sont disponibles dont plusieurs OpenSource comme Equinox, Felix ou Knopflerfish

12. Sommaire Les concepts de OSGi

13. Leurs mises en oeuvre avec dm Server

14. OSGi et les applications de gestion ?

15. Les concepts de OSGi Les concepts de OSGi http://www.osgi.org/About/WhatIsOSGi

16. Bundles Les bundles sont les composants à la base de la modularité de OSGi

17. Ce sont de archives java classiques (JARs) pour lesquelles le manifest contient des méta-données supplémentaires : 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. Bundle Lifecycle Le framework OSGi gère le cycle de vie de chaque bundle : http://static.springsource.org/osgi/docs/current/reference/html/bnd-app-ctx.html#bnd-app-ctx:bnd-lifecycle

19. Dépendance Statique Les dépendances statiques entre bundle doivent être explicitement déclarées par chaque bundle : Un bundle peut exporter les packages java qu'il définit pour les rendre disponible aux autres bundles

20. Un bundle doit importer les packages java externes dont il a besoin Imports package com.B Exports package com.B Imports package com.C Exports package com.C

21. Dépendance Statique Cela s'effectue via des entêtes du manifest : Export-Package

22. Import-Package 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 ="[1.2.15,1.2.15]"

23. Dépendance Statique Classloading : Le runtime OSGi charge les classes de chaque bundle via un classloader qui lui est dédié

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é : Cette délégation est donc bien plus riche (et bien plus complexe) que le mécanisme de classloading classique parent / enfant 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. Dépendance Dynamique Chaque bundle peut aussi définir des « services » qui sont à disposition des autres bundles. Un service est une instance d'une classe exposée sous une ou plusieurs interfaces.

26. Le « Service Registry » permet aux bundles d'exposer ou de rechercher puis utiliser des services http://www.osgi.org/About/WhatIsOSGi

27. Dépendance Dynamique Les services peuvent apparaître ou disparaître de manière dynamique : Les bundles « actifs » peuvent proposer et retirer un service quand ils le souhaitent

28. Lorsqu'un bundle est arrêté, les services qu'ils exposent sont automatiquement retirés. Les bundles consommateurs doivent donc tracker la disponibilité des services qu'ils utilisent

29. Dépendance Dynamique Caractéristique d'un service : Service interfaces

30. Service property Sélection d'un service : Elle se fait avant tout sur une « Service Interface »

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

32. Focus : Components Models Un certain nombre de frameworks/spec facilitent l'utilisation de OSGi en proposant des modèles de composants particuliers : Spring DM ( & spec. Blueprint Container )

33. spécification Declarative Services

34. Apache iPojo Spring Dynamic Modules for OSGi Service Platforms Framework dont le but est d'apporter la philosophie de Spring aux développements ciblant OSGi

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

36. Dépendance Dynamique Exemple d'utilisation de Spring DM : Export d'un bean sous forme d'un service OSGi :

37. Import d'un service dans le contexte Spring : < 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. Dépendance statique vs. dynamique Dépendance statique : La dépendance s'utilise comme une librairie classique

39. Réutilisation d'une implémentation : couplage assez fort

40. Mais OSGi permet de limiter le couplage aux apis publics de l'implémentation Dépendance dynamique : On est sur une vraie approche orientée-service (SOA)

41. On ne partage pas une implémentation, on obtient la référence à un objet avec lequel collaborer

42. Permet un remplacement dynamique du service : nouvelle implémentation ou nouvelle configuration, etc …

43. Versioning Chaque bundle, chaque package est versionné.