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

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

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.

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

10. Cette techno est maintenant utilisée comme socle technique interne de la plupart des serveurs d'applications ou d'IDE comme Eclipse

13. Leurs mises en oeuvre avec dm Server

14. OSGi et les applications de gestion ?

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

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

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]"

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

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

33. spécification Declarative Services

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

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 >

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

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 …

44. Les dépendances peuvent exprimer des contraintes sur les versions nécessaires

46. Il exporte un package en version 2.1

47. Il importe le package org.apache.log4j avec une contrainte sur la version : minimum 1.2.15 et strictement inférieure à 1.3 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;

50. SpringSource dm Server Mise en oeuvre OSGI avec SpringSource dm Server

52. Premier serveur d'applications java dont le but est de proposer les fonctionnalités de OSGi aux applications hébergées

54. La création du projet a été « approuvée » hier (24/02)

57. Sans être obligatoire, le développement avec ces deux frameworks est facilité

60. L'url est : http://www.springsource.com/repository/app/

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 )

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. War consommateur de services : idem avec utilisation de services exposées via OSGi Schéma extrait de http://static.springsource.org/s2-dmserver/2.0.x/programmer-guide/html/ch05.html#migrating-to-osgi-web

70. Cela pourra peut-être inciter les serveurs d'application commerciaux à faire de même et promouvoir ce modèle de développement

71. Démo Démonstration : Déploiement de quelques bundles sous dm Server Et mise en oeuvre des concepts de base de OSGi

72. OSGi et les applications de gestion ?

74. Utilisant un grand nombre de librairies Open Source et en particulier Spring Framework

75. Méthodologies SOA et Agile

76. Organisation : un ou plusieurs équipes de dev avec plus ou moins de débutants

77. Une équipe de production qui installe et gère l'application

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

85. Intéressant surtout si plusieurs équipes interagissent

87. ils réduisent voire éliminent la complexité de gestion de dépendance

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

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.

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

95. Des approches classiques de type Proxy dynamique permettent de gérer ce use case (côté client)

100. Leurs utilisations nécessitent parfois des adaptations ou sont soumises à certaines contraintes

101. Elles ne sont pas pré-packagés

107. La plupart du temps, c'est souvent un détail transparent pour les développeurs

108. Mais les cas aux limites seront difficiles à comprendre/gérer pour des développeurs non aguerris

111. Difficile d'avoir de la visibilité sur l'utilisation d'OSGi sur des projets avec un minimum d'envergure

112. Le plus gros point est le manque d'expertise et de support pour des projets critiques

115. Sensibiliser les équipes de dev et de prod à cette alternative grandissante