• Save
20100225 Ippon Osgi Are You Ready
Upcoming SlideShare
Loading in...5
×
 

20100225 Ippon Osgi Are You Ready

on

  • 1,476 views

Présentation Ippon Technologies Open-REX du 25/02

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

Statistics

Views

Total Views
1,476
Views on SlideShare
1,467
Embed Views
9

Actions

Likes
0
Downloads
0
Comments
0

2 Embeds 9

http://blog.ippon.fr 8
http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    20100225 Ippon Osgi Are You Ready 20100225 Ippon Osgi Are You Ready Presentation Transcript

    • 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
      • Cette présentation vous est fournie sous licence Creative Commons Attribution Share Alike
      • 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.
        • 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.
        • Chacune de ces conditions peut être levée si vous obtenez l'autorisation du titulaire des droits sur cette œuvre.
        • Rien dans ce contrat ne diminue ou ne restreint le droit moral de l'auteur ou des auteurs.
    • Introduction
      • OSGi :
        • OSGi est une spécification définissant un système modulaire et dynamique pour Java
        • Il est défini par l'OSGi Alliance, consortium d'industriels fondé en 1999
    • 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.
        • Cette techno est maintenant utilisée comme socle technique interne de la plupart des serveurs d'applications ou d'IDE comme Eclipse
    • 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
    • Sommaire
      • Les concepts de OSGi
      • Leurs mises en oeuvre avec dm Server
      • OSGi et les applications de gestion ?
      • Les concepts de OSGi
      Les concepts de OSGi http://www.osgi.org/About/WhatIsOSGi
    • Bundles
      • Les bundles sont les composants à la base de la modularité de OSGi
      • 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
    • 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
    • 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
        • 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
    • Dépendance Statique
      • Cela s'effectue via des entêtes du manifest :
        • Export-Package
        • 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]"
    • Dépendance Statique
      • Classloading :
        • Le runtime OSGi charge les classes de chaque bundle via un classloader qui lui est dédié
        • 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
    • 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.
        • Le « Service Registry » permet aux bundles d'exposer ou de rechercher puis utiliser des services
      http://www.osgi.org/About/WhatIsOSGi
    • 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
        • 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
    • Dépendance Dynamique
      • Caractéristique d'un service :
        • Service interfaces
        • Service property
      • Sélection d'un service :
        • Elle se fait avant tout sur une « Service Interface »
        • 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
    • 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 )
        • spécification Declarative Services
        • 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
        • 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
    • Dépendance Dynamique
      • Exemple d'utilisation de Spring DM :
        • Export d'un bean sous forme d'un service OSGi :
        • 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 >
    • Dépendance statique vs. dynamique
      • Dépendance statique :
        • La dépendance s'utilise comme une librairie classique
        • Réutilisation d'une implémentation : couplage assez fort
        • 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)
        • On ne partage pas une implémentation, on obtient la référence à un objet avec lequel collaborer
        • Permet un remplacement dynamique du service : nouvelle implémentation ou nouvelle configuration, etc …
    • Versioning
      • Chaque bundle, chaque package est versionné.
      • Les dépendances peuvent exprimer des contraintes sur les versions nécessaires
      • Dans le manifest ci-dessous :
        • Le bundle est en version 2.1.6
        • Il exporte un package en version 2.1
        • 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;
    • Versioning
      • OSGi supporte le déploiement simultané de plusieurs versions d'un bundle
      • La situation suivante, bien qu'impossible à gérer avec un classloading basique, est ainsi supportée :
        • ( 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)
      Import-Package Import-Package Import-Package
    • SpringSource dm Server Mise en oeuvre OSGI avec SpringSource dm Server
    • SpringSource dm Server
      • SpringSource Dm Server
        • Première version dévoilée par SpringSource à la mi-2008
        • Premier serveur d'applications java dont le but est de proposer les fonctionnalités de OSGi aux applications hébergées
        • La version 2.0 est sortie le 12 janvier 2010
      • Projet Virgo
        • Lors de la sortie de la V2, SpringSource a proposé de donner dm Server à la fondation Eclipse sous le nom de Virgo
        • La création du projet a été « approuvée » hier (24/02)
    • SpringSource dm Server
      • SpringSource dm Server est basée sur :
        • Equinox : l'implémentation OSGi de la fondation Eclipse
        • Tomcat : pour gérer les applications Web servlet/jsp …
          • En particulier les War classiques sont gérés par dm Server sans modification
        • Il intégre les frameworks Spring et Spring DM.
        • Sans être obligatoire, le développement avec ces deux frameworks est facilité
    • Bundle provisioning
      • dm Server permet de placer les bundles utilisés par les applications dans un repository local
        • dm Server utilise ces bundles à la demande suivant les besoins des applications déployées
        • Mais il est nécessaire d'y placer des librairies correctement osgi-ifiées.
      • SpringSource Enterprise Bundle Repository contient de telles librairies
        • SpringSource y a mis un ensemble de librairies open-source contenant les méta-données OSGi nécessaires
        • L'url est : http://www.springsource.com/repository/app/
        • Attention, le repository est ouvert mais le packaging des librairies est toutefois spécifique à SpringSource ( et pas forcément compatible avec d'autres repository )
    • Gestion des dépendances
      • dm Server introduit des extensions à OSGi :
        • Directive Import-Bundle :
          • permet d'importer tous les packages exportés par un bundle donné (légèrement différent de Require-Bundle présent dans OSGi)
        • Directive Import-Library :
          • 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)
      • Leur utilisation permet de faciliter la déclaration des dépendances lorsqu'on n'a pas besoin de contrôler finement les packages accessibles
    • Apports de Dm Server & Spring DM
      • dm Server et Spring DM apporte des améliorations par rapport à un environnement OSGi nu :
        • Possibilité de gérer le Thread Context ClassLoader :
          • Spring DM : peut le positionner avec le classloader du bundle appelant un service ou du bundle implémentant le service
          • dm Server crée un TCL global pour les PAR
        • Gestion du classpath scanning :
          • 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 …
          • dm Server a adapté Equinox pour permettre cela (exposition des jars sur le filesystem dans les URLs renvoyés par les classloaders)
        • Load time weaving :
          • 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.
    • Typologie de déploiement
      • SpringSource propose une adoption graduelle de OSGi :
        • War classique, contenant les librairies nécessaires dans WEB-INF/lib
        • 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.
        • 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
    • Quelques alternatives
      • Notons que d'autres approches existent sur les serveurs d'application OSGi :
        • 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
        • Cela pourra peut-être inciter les serveurs d'application commerciaux à faire de même et promouvoir ce modèle de développement
    • Démo Démonstration : Déploiement de quelques bundles sous dm Server Et mise en oeuvre des concepts de base de OSGi
    • OSGi et les applications de gestion ?
    • Contexte
      • Prenons comme contexte une application de gestion classique :
        • Application décomposée en couche, potentiellement distribuée avec un front end web
        • Utilisant un grand nombre de librairies Open Source et en particulier Spring Framework
        • Méthodologies SOA et Agile
        • Organisation : un ou plusieurs équipes de dev avec plus ou moins de débutants
        • Une équipe de production qui installe et gère l'application
        • Un client exigeant
      • OSGi nous aide-t-il ?
    • Librairies
      • Gestion des librairies
        • OSGi capable de gérer beaucoup de librairies disparates :
          • partage des librairies entre applications => gain de mémoire potentiellement significatif ( mais des serveurs J2EE classiques le proposent aussi )
          • capable de gérer sans problème les conflits entre dépendance de différentes librairies
        • Attention toutefois, dans certains cas, il est nécessaire d'avoir un arbre de dépendance consistant :
          • L'utilisation d'un repository de bundles (tel que l'EBR de SpringSource) simplifie fortement les choses.
          • 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
    • Librairies
      • Utilisation de Spring Framework :
        • Spring dm est particulièrement attractif dans ce contexte :
          • bootstrap automatique du context Spring de chaque module
          • chaque module restant indépendant
        • « Garantie » (?) d'interopérabilité avec OSGi, étant donné l'investissement de SpringSource
    • Librairies
      • Gestion des dépendances entre modules :
        • Leur gestion explicite dans OSGi apporte de la complexité mais aussi plus de contrôle :
          • Contrôle au niveau package (limité auparavant au niveau des membres d'une classe)
          • Intéressant surtout si plusieurs équipes interagissent
          • 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)
        • A relativiser toutefois :
          • les outils de génération de manifest (bnd, bundlor, ...) seront certainement adoptés par la majorité des utilisateurs
          • ils réduisent voire éliminent la complexité de gestion de dépendance
          • 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
    • SOA
      • Approche SOA
        • OSGi partage la même philosophie que les démarches SOA
        • Un service OSGi a les même caractéristiques qu'un service au sens SOA
          • On peut envisager un mapping 1-1 entre implémentation et conception
        • La gestion du versioning dans OSGi prend tout son sens dans le cadre de SOA :
          • Le versioning des services est souvent nécessaire dans une telle approche.
          • 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.
    • Dynamicité
      • Dynamicité de OSGi pour le déploiement
        • surtout utile en phase développement
        • 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
        • le besoin n'est pas forcément là.
      • Dynamicité de OSGi au niveau des services :
        • Besoin assez rare au sein même d'une même application
        • Des approches classiques de type Proxy dynamique permettent de gérer ce use case (côté client)
    • J2EE like
      • Gestion des application distribuées :
        • La spécification OSGi « Remote Services » est récente : elle fait partie de OSGi 4.2 datant de Sept 2009
        • Les implémentations existent :
          • Apache CXF
          • Eclipse Communication Framework (ECF)
        • D'autres solutions non « standard » existent :
          • r-OSGi
        • 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
    • J2EE like
      • Les apis j2ee : JDBC, JTA, JMS, JPA ...
        • Dans le cas de dm Server ou d'un framework OSGi nu :
          • Ces apis sont disponibles via l'utilisation de librairies open-source spécialisées
          • Leurs utilisations nécessitent parfois des adaptations ou sont soumises à certaines contraintes
          • Elles ne sont pas pré-packagés
          • Assez simple à mettre en oeuvre sur des cas simples mais l'intégration entre toutes ces technologies n'est pas immédiate
        • GlassFish et JOnAS sont sûrement de meilleurs candidats par rapport à ces aspects
    • Mise en prod ?
      • Comment livrer une application OSGi ?
        • 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
        • Nécessité de gérer le provisionning de l'environnement d'exécution :
          • avoir les bons bundles dans les bonnes versions pour satisfaire les dépendances des applications déployées
          • rq : dm Server V2 est capable d'aller chercher ces dépendances dans un remote repository
        • 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 ?
    • Maturité des intervenants
      • Les développeurs sont/seront-ils prêts ?
        • OSGi manipule des concepts assez pointus de Java, en particulier en terme de classloading
        • La plupart du temps, c'est souvent un détail transparent pour les développeurs
        • Mais les cas aux limites seront difficiles à comprendre/gérer pour des développeurs non aguerris
    • Conclusion
      • OSGi propose beaucoup de fonctionnalités intéressantes :
        • Très bonnes fondations techniques adaptables à des situations aux limites
        • Approche fortement orientée service très attractive
      • Mais :
        • 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
        • Difficile d'avoir de la visibilité sur l'utilisation d'OSGi sur des projets avec un minimum d'envergure
        • Le plus gros point est le manque d'expertise et de support pour des projets critiques
    • Conclusion
      • Toutefois ses qualités appellent à :
        • Suivre de prêt l'évolution des implémentations
          • Standardisation (en particulier dans l'intégration OSGi / J2EE)
          • Maturation (dmServer devenu Virgo, Apache Aries, ...)
        • Identifier les opportunités de mise en place sur des projets peu critiques ou des prototypes afin de gagner en visibilité
        • Sensibiliser les équipes de dev et de prod à cette alternative grandissante
    • Ressources
        • OSGi Alliance :
          • http://www.osgi.org/
          • http://www.osgi.org/blog/
        • SpringSource dm Server :
          • http://www.springsource.org/dmserver
        • Spring Dynamic Modules for OSGi Service Platforms :
          • http://www.springsource.org/osgi
        • Une pres. de Rod Johnson très sympa :
          • http://www.infoq.com/presentations/dm-Server-Rod-Johnson
        • Les posts OSGi du Blog de SpringSource :
          • http://blog.springsource.com/category/osgi/
        • Apache Aries :
          • http://incubator.apache.org/aries/
        • Apache CXF – Distributed OSGi :
          • http://cxf.apache.org/distributed-osgi.html