Synthése

Poussé par le succès énorme et grandissant des services payants dans la téléphonie mobile,
l’idée de proposer des services à forte valeur ajoutée à la demande sur les équipements
communicants comme les plateformes télématiques dans l’automobile ou les points d’accès à
la maison trouve plusieurs demandeurs.
Afin de maîtriser la complexité logicielle de telles plateformes, l’industrie a favorisé la
définition d’un environnement standard d’exécution, appelé OSGI (Open Services Gateway
Initiative).
Modèles à base de composants :
Les modèles à base de composants assurent un développement modulaire et une maintenance
plus aisée des applications. Parmi les principaux modèles, on peut citer JavaBeans, EJB,
CCM, .NET de Microsoft.
Un composant est un module logiciel décrit par des contrats (définis par des interfaces et des
événements) proposés, requis, des propriétés configurables et par des contraintes techniques.
Par le biais de l’assemblage de composants configurés on obtient des applications.
L’exécution de l’application est démarrée lorsque ses composants sont déployés sur la plateforme à composants (qui peut être distribuée sur plusieurs hôtes). Chaque composant est pris
en charge par un conteneur dont le rôle consiste à isoler le composant de l’environnement et
de prendre en charge les contraintes techniques liées aux aspects non fonctionnels
(distribution, persistance, fiabilité, sécurité, …).
Traditionnellement, le cycle de vie de l’application suit les phases strictement successives de
développement, assemblage, configuration, déploiement et exécution.
La maintenance de l’application comporte généralement des opérations de reconfiguration et
d’adaptation de composants, elle est due généralement à un dysfonctionnement du composant,
ou pour doter le composant de nouvelles fonctionnalités. L’adaptation revient à déconnecter le
composant de l’application, à transférer son état courant vers un nouveau composant et à
connecter ce dernier à l’application. Cependant elle doit aussi répondre à plusieurs contraintes
comme la sécurité, la complétude et la possibilité de retour en arrière au cas où l'adaptation ne
peut se terminer avec succès.
Traditionnellement, l’opération d’adaptation requiert généralement l’arrêt de l’application et
oblige à reprendre le cycle de vie à partir de la phase d’assemblage.
L’adaptation dynamique consiste à introduire des modifications dans l’application au cours de
son exécution contrairement à l’approche traditionnelle qui nécessite l’arrêt total de
l’application.
Définition de la plateforme OSGI :
Open Services Gateway Initiative (OSGI) est une spécification ouverte qui définit un
environnement standardisé orienté composants pour les périphériques réseau, elle a pour but
de définir et de promouvoir des spécifications ouvertes pour la livraison de services
administrables dans des réseaux résidentiels, véhiculaires, le domaine de la santé et autres
types d'environnements. Les API de serveurs embarqués destinés à héberger des services qui
peuvent être installés, activés, mis à jour, désactivés et désinstallés sans interruption de
service du serveur embarqué.
OSGI définit principalement le conditionnement (bundle) des services, leur hébergement, la
gestion de leurs cycles de vie, les mécanismes de résolution des dépendances de code, le
courtage des services actifs et l’activation de nouveaux services.
2.1 Vue d’ensemble de la plate-forme
La plate-forme de service OSGI comprend:
1. Le framework OSGI qui définit un environnement hôte pour administrer les
Bundles (archive JAVA)
2. Des services standards (http, Jini, device, …)
La plate-forme de services OSGI se divise en deux parties : le framework OSGI d’une part et
les services standards OSGI d’autre part. Dans cet exposé, nous nous intéresserons plus au
framework qu’aux services standard, tels que le service HTTP. Dans le contexte de cet
exposé, les services OSGI sont simplement des définitions d'interfaces Java avec une
sémantique précise et tout objet qui implémente une interface de service est supposé obéir à
son contrat.
Le framework OSGI définit un environnement hôte pour administrer des bundles ainsi que les
services qu'ils fournissent. Un bundle est une unité physique de livraison ainsi qu'un concept
logique employé par le framework pour organiser son état interne. Concrètement, un bundle
est une archive Java qui contient un manifeste et un ensemble de classes, des bibliothèques de
code natif et d’autres ressources associées. Un bundle installé est identifiable de manière
unique et il est important de noter qu'il n'est pas possible d'installer deux bundles à partir du
même emplacement.
Les mécanismes d'administration fournis par le framework permettent l'installation,
l’activation, la désactivation, la mise à jour et le retrait d'un bundle. Un bundle installé dans le
framework peut avoir l’un des états suivants : installé, résolu, actif, en démarrage, arrêté ou
désinstallé. L'état des bundles actifs est persistant tout au long des activations du framework,
autrement dit, les bundles actifs préservent leur état après le redémarrage du framework.
Les métas donnés d’un bundle sont décrits dans un fichier associé au JAR du bundle appelé
manifeste. Le manifeste contient un ensemble de paires attribut valeur.
Certains attributs sont standardisés par la spécification OSGI. Ils décrivent le chemin des
classes (classpath) du bundle, les packages Java exportés ou importés par le bundle, les
besoins par rapport aux bibliothèques de code natif et l'information intelligible par l’
administrateur du framework (e.g. nom du bundle, description).
Le manifeste peut également contenir un attribut qui spécifie une classe d'activation du bundle
appelée « activateur » (Activator). L'activateur joue un rôle important car il permet au bundle
d’obtenir un contexte pour accéder aux fonctionnalités du framework. Le contexte permet aux
bundles de rechercher des services dans le registre de services du framework, d’enregistrer
leurs propres services, d’accéder à d'autres bundles et d’installer des bundles additionnels. La
classe activateur enregistre chaque service avec au minimum le nom de l’interface qu’il
implémente, et éventuellement des propriétés supplémentaires (version,…). La recherche de
services se fait au moyen d’une requête LDAP simple qui peut limiter la recherche à
l’ensemble des services qui ont des propriétés spécifiques (e.g. version>2.0). Une requête peut
retourner zéro ou plusieurs références de services.
Le bundle ne requiert pas obligatoirement une classe activatrice. Il peut être simplement une
bibliothèque de packages Java qui ne nécessitent pas l’accès au framework.
Vous trouverez toutes les informations nécessaires contenant les bundles et le manifeste en
annexe.
Fonctionnalités clé de la plateforme OSGI :
• Gestion des composants logiciels : Gestion du cycle de vie des composants et
application grâces au notions de bundles (archives java "JAR"), installation,
démarrage/ arrêt, mise à jour et désinstallation d’un bundle
•
Administration à distance : la plateforme OSGI permet d’administrer les composants
et ce par n’importe quel protocole ce qui montre son extrême flexibilité
•
Environnement d’exécution sécurisé : Exécuter du code dans un périphérique réseau
ne peut se faire que si celui-ci est proprement protégé, toutefois les spécifications
OSGI offrent un modèle de sécurité étendu et global qui fonctionne sous différents
niveaux :
¾ Niveau 1 : Le premier niveau de sécurité est la machine virtuelle qui pose
plusieurs restrictions sur le code Java. Les manipulations dangereuses sur les
pointeurs, ou les accès non examinés aux tableaux sont enlevées du
vocabulaire du programmeur. Cela rend impossible les attaques du type
"Buffer Overruns" (Mémoire tampon dépassée) qui sont utilisé par plusieurs
virus comme Melissa, ou MSblaster.
¾ Niveau 2 : Les fonctionnalités du code Java en ce qui concerne l’accès aux
classes et aux méthodes, puisque le code Java permet des déclarations de type
Public, Private, Protected… Ces mécanismes de contrôle d’accès permettent à
plusieurs applications de tourner et coopérer au sein de la même machine
virtuelle tout en protégeant le code qui doit être "Privé".
¾ Niveau 3 (optionnel) : La capacité de limité les capacités de chaque Bundle à
accéder aux ressources en ne lui attribuant que les permissions qui lui sont
nécessaires.
¾ Niveau 4 : Le dernier niveau de défense est la framework (cadre) OSGI qui
sépare les Bundles entre eux, puisque les Bundles ont besoin de permissions
même pour détecter d’autres bundles dans la plateforme OSGI.
•
Coopération entre les applications : Plusieurs serveurs d’application Java sont
disponibles tel que : MIDP, J2EE, JMX, Avalon, … tout ces modèles fournissent pour
chaque application un container isolé ou s’exécuter, ce qui n’est pas le cas de la
plateforme OSGI qui permet aux Bundles de partager du code ou des services avec
son environnement. Partager le code est important puisqu’il permet aux librairies avec
des fonctionnalités partagées d’être téléchargées ce qui rend les applications plus
petites en terme de taille, à l’instar du modèle classique à base de containers dans
lequel chaque application a son propre code même s’il est déjà présent dans le réseau.
•
Commercialisation : L’avantage d’un environnement standardisé est que différentes
parties peuvent y contribuer à moindre coût. Les compagnies membres d’OSGI
comme IBM, Gatespace Telematics, Atinav… ont déjà fournis plusieurs blocks
élémentaires que toute la communauté utilise.
Le marché du logiciel OSGI (COTS : Commercial Off The Shelf) est petit
aujourd’hui mais ne cesse de grandir, ce qui attraira plusieurs développeurs à l’avenir.
•
Déploiement simple : Installer une application dans un environnement est souvent un
problème sous estimé. Les application Java sont plus difficiles à installer car le
langage tente de s’extraire de l’environnement le plus possible ce qui induit à savoir
quelle machine virtuelle est utilisée, comment configurer correctement l’application
pour qu’elle fonctionne sur tel ou tel environnement, comment assurer le démarrage,
l’arrêt de le contrôle de celle-ci.
Les technologies apportées par L’OSGI alliance simplifient considérablement le
processus de déploiement, quand une plateforme OSGI est installée dans un
environnement, déployer des applications est simple grâce a plateforme standardisée
qu’apporte OSGI et qui inhibe les différences entre les environnements sous jacents.
• Interopérabilité entre les industriels : L’OSGI alliance fournit des efforts
considérables en créant des spécifications qui permettent l’interopérabilité entre
différentes implémentations des spécifications OSGI.
La prochaine génération de téléphones portables contiendra un cadre de travail OSGI,
des librairies et applications développées pour un téléphone Nokia peuvent fonctionner
sans aucune modification dans des téléphones Motorola.
•
Nature dynamique : Installer un nouveau Bundle, enregistrer un nouveau service ou
mettre à jour un composant ne nécessitent pas un redémarrage de la machine virtuelle.
Les composants concernés sont informés du nouvel état et s’adaptent
automatiquement.
Par exemple quand un Bundle avec un sevlet est mis à jour, le servlet est
automatiquement désenregsitré et la nouvelle version est immédiatement disponible
via le serveur Web.
•
Politique libre : La plateforme OSGI fournit plusieurs mécanismes mais ne dicte pas
comment utiliser ces mécanismes, ce qui permet à l’opérateur d’établir sa propre
politique en utilisant les mécanismes fournis par OSGI. La plateforme OSGI peut être
utilisé dans un environnement administré a 100% comme les téléphones mobiles, ou
tourner sur des ordinateurs de bureau sans aucune supervision.
•
Certification : L’OSGI alliance à crée un programme de certification qui assure la
conformité avec le standard. Les implémentation certifiée ne peuvent se faire que par
des membres de l’OSGI, ils peuvent facturer des frais pour cette implémentation afin
d’amortir leurs investissements.
La certification permet aux développeurs d’aller au dessus d’un industriel qui tarde
dans son processus de développement, elle permet la conformité qui sert à
promouvoir la compétitivité et baisser les prix tout en augmentant la qualité des
services.
2.2 Architecture d’OSGI
La pile OSGI peut être définie par un nombre de couches qu’on peut considérer comme suit :
La plateforme de services OSGI fournit un
environnement pour les applications appelées Bundles
qui s’exécutent ensemble dans la même machine
virtuelle JAVA
La section suivante décris les couches nécessaires pour le fonctionnement de OSGI.
1. JVM
Les spécifications OSGI sont basées sur la machine virtuelle Java, cela est été logique puisque
l’environnement Java pourvoit tout les fonctionnalités requises pour un environnement
sécurisé, ouvert, fiable, développable, riche et portatif.
Aujourd’hui le seul candidat probable de la JVM est Microsoft.NET, mais Java a encore
l’avantage puisque .NET n’est disponible que d’une seule source.
2. OSGI Framework
Exécuter plusieurs applications dans la même machine virtuelle crée plusieurs résultats qui
peuvent être partagés et doivent être adressés. L’OSGI Framework est le composant
responsable de l’adressage de ces résultats, il a plusieurs responsabilités qu’on verra dans les
sections suivantes de cet exposé.
3. Class Loading
L e contenu d’un Bundle est une archiver JAR qui contient des classes, celles-ci sont les
éléments exécutables du Bundle. Le problème qui se pose est : comment traiter ces Classes
par rapport à celles des autres bundles, doivent elles être privées ou partagées avec les autres
Bundles ?
Restreindre l’accès aux classes en local (Bundle Private) est la solution la plus facile, ceci est
utilisé dans des applications de type J2EE et MIDP (Mobile Information Device Profile).
Cependant partager les Classes permet aux Bundles d’obtenir des classes et librairies d’autres
Bundles, c’est un avantage de taille puisqu’il permet de minimiser la mémoire occupée par
ces applications ce qui les rends plus flexibles.
Chaque Bundle importe ou exporte des classes. Exporter des classes signifie que ce Bundle
rend disponible plusieurs packages pour les autres. Importer signifie que le Bundle a besoin
de packages (à exporter) d’autres Bundles.
Si plusieurs Bundles exportent le même package, la framework en élira un qui sera utilisé par
tout les packages qui importent ou exportent ce package.
Les packages sont exportés et importés avec un numéro de version, dans les spécification
OSGI plateforme Release 3 (en téléchargement) il y a une règle qui dit que les packages avec
une version égale ou supérieure sont compatibles avec les versions précédentes, ce qui atténue
le problème de la gestion de versions.
Si un Bundle qui exporte un package est par la suite désinstallé, alors le framework OSGI
s’assure que les importateurs redémarrent pour qu’ils puissent être reliés à un autre
exportateur. Ce processus est transparent pour les Bundles car il s’exécute quand ils sont
arrêtés.
4. Gestion du cycle de vie
Installer un nouveau Bundle dans la JVM fournit les bases des services réseau, l’accès aux
fonctions d’installation d’un Bundle se fait via une API qui est disponible pour tout les
bundles. Cela peut sembler aléatoire et singulier puisque ça implique que seul un Bundle peut
installer un autre Bundle. Cela introduit le problème de l’auto référencement, celui-ci est
résolu grâce l’installation initiale et par l’utilisation de lignes de commande à l’implantation
de la framework OSGI.
L’API de la framework OSGI est définie dans l’objet "BundleContext" qui contient plusieurs
méthodes pour installer des nouveaux Bundles ou pour lister ceux qui existent, il est fournit
au Bundle à son démarrage.
La méthode "InstallBundle" prend un URL ou un InputStream comme paramètre, la
framework examine les données et installe le Bundle, après l’installation le Bundle doit être
d’abord résolu pour qu’il puisse être démarré.
Un bundle peut avoir plusieurs pré requis (ex : s’il a besoin d’importer des packages), le
framework analyse ses dépendances et les relie avec les dépendants avant que le Bundle ne
soit démarré, la résolution d’un Bundle peut donc mener à la résolution d’autres bundles.
La main est donnée au nouveau Bundle par l’instanciation d’une classe qui implémente
l’interface "BundleActivator" qui contient les méthodes start(BundleContext) et
stop(BundleContext). Le nom de la classe instanciée est fournit par l’entête du manifeste
Bundle-Activator.
Durant le cycle de vie d’un Bundle, plusieurs événements peuvent avoir lieu dans la JVM tel
que la désinstallation d’un Bundle qui exporte des classes à celui-ci, cela n’affecte pas le
Bundle importateur directement puisque les packages exportés par le Bundle désinstallé
demeurent disponibles tant que des Bundles en dépendent.
La figure suivante nous montre les différents états du cycle de vie d’un Bundle.
5. Registre des services
Les Bundles actifs peuvent utiliser tout les mécanisme Java standard pour implémenter leurs
fonctionnalités comme n’importe quel environnement Java, cependant l’avantage qu’a OSGI
est sa nature dynamique (ex un Bundle peut soudainement devenir actif est fournir ainsi de
nouvelles fonctionnalités ou coopérer avec d’autres Bundles).
Une autre différence de taille entre OSGI et les environnements Java standard, est que OSGI
n’a pas besoin de structure ou d’environnement statique pour construire de nouvelles
applications, mais il est aussi possible d’enlever des parties du système sans que cela ne
dérange l’environnement en général.
Cette dynamique nécessite que tout les registres d’écoute doivent attentifs aux changements
d’états des Bundles, par exemple si un Bundle est arrêté il doit être enlevé de tout les registres
qui l’écoutaient, et vice versa.
Le registre de services OSGI a été construit pour pallier à tous ces problèmes en facilitant leur
gestion puisqu’il lie dynamiquement les différents Bundles au moment ou il vérifie leur état et
leurs dépendances.
Grâce au registre de services les Bundles peuvent :
• Enregistrer des objets avec le registre des services,
• Consulter le registre de services pour des objets qu’il recherche,
• Recevoir des notifications quand un service devient enregistré ou supprimé.
Un service est un objet enregistré dans le registre des services, les services sont enregistrés
avec un nom d’interface (usage attendu du service) et plusieurs propriétés (description du
service aux autres). Par exemple le service de journal "LogService" va être enregistré avec
l’interface org.osgi.service.log.logservice
fournisseur=IBM.
et
peut
avoir
des
propriétés
de
type
La découverte de nouveaux services ou la suppression d’anciens services par les autres
Bundles est fait par des notifications ou en activant une recherche de services avec des
propriétés spécifiques.
Le registre de services permet aux développeurs de programmer des petites applications
généralement couplée à d’autres pour construire de grands système, tout en s’adaptant à son
environnement dynamique en temps réel.
6. Sécurité
Un des buts principaux de la plateforme OSGI est d’exécuter des applications issues de
différentes sources sous le contrôle du système d’administration, la plateforme utilise les
mécanismes suivants :
• Sécurité du code Java2 : Permissions qui protégent les ressources, comme les
permissions sur les classes…
• Minimiser l’exposition du contenu des Bundles : un Bundle possède plusieurs
permissions qui peuvent être changée à la volée, elles sont attribuée de manière
efficace, par exemple si A appelle B et B accède à une ressource protégée, A et B ont
besoin d’avoir accès à cette ressource. C’est une stratégie qui permet d’éviter les
désordres.
• Communications contrôlées entre les Bundles : par les Services Permissions qui
permettent au Bundle d’avoir ou d’enregistrer un service à partir du registre de
services.
2.3 La plateforme OSGI dans les réseaux domestiques :
OSGI est une plateforme de choix pour développer des réseaux domestiques,puisque grâce à
la dynamique et aux différentes fonctionnalités d’OSGI on peut facilement gérer et
administrer un réseau domestique qu’il soit informatique (Wifi) ou électrique (contrôle du
réfrigérateur, air conditionné…) ou les deux à la fois. Comme nous le savons OSGI peut
opérer avec plusieurs standards, la figure suivante nous montre un exemple de standards avec
lesquelles OSGI peut opérer :
Broadband
Network
Câble
Service
delivery
Local
Network
DSL
Powerline
Wireless
OSGi
802.11
HomeRF
JINI
Home Plug
Bluetooth
CEBus
UPnP
HAVi
Les réseaux domestiques intelligents (Smart@Home: développée par BSH Bosh and Siemens
Hausgerate) suivent un système simple de "Plug&Use" brancher/utiliser dans lequel
l’utilisateur final peut gérer et administrer tout ces produits et services via un simple
téléphone mobile, PDA ou un ordinateur de bureau.
Pour expliquer le principe de fonctionnement de ce type de réseau, il y a une démo disponible
sur le Web http:// demo.echelon.com, ou en consultant le document osgi.pdf disponible en
téléchargement sur ce site.
Dans ce document la figure suivante suffira pour introduire les concepts de base qui régissent
le fonctionnement de ce type d’implémentation de la plateforme OSGI.
Les différents services en interaction avec la passerelle résidentielle sont dans cet exemple des
services de sécurité et gardiennage (Security firm), des services hospitalier et des services
électriques. Ils sont tous déployés dans passerelle résidentielle qui peut être soit gérée par un
administrateur en local ou par l’utilisateur final à distance.
La passerelle résidentielle est à son tour déployée dans la plateforme OSGI qui gère le réseau
domestique.
L’opérateur historique français France Telecom en association avec Thomson Multimédia
dans le cadre d’un partenariat de recherche et développement, ont développés une plateforme
domestique de service à large distance, cette passerelle résidentielle fournit un accès au
réseaux locaux de la maison en incluant un module d’administration à distance de tout les
périphériques connectés. Plusieurs middlewares ont été ajoutés pour permettre le plug&play à
la volée des périphériques, dans le réseau sans fil 802.11 Corba, Jini, et UPnP on été utilisés,
tandis que pour le réseau à haute fréquence IEEE 1394 (ILink, Firewire) plusieurs
périphériques audiovisuels communiquent à travers le middleware HAVI (Home Audio Video
Interoperability), un premier prototype de démonstration à été présenté dans le salon
NET@HOME en novembre 2001.
2.4 Services standard d’OSGI
Dans cette section nous verrons une brève description de l’OSGI Release 3 services, pour plus
d’information reportez vous au fichier r3.book.pdf disponible en téléchargement.
A) Framework Services :
Ces services sont optionnels et dirigent les opérations du framework
• Permission Admin : Manipuler les permissions des Bundles présents ou futurs,
• Package Admin : Recalculer les dépendances entre les Bundles pour rafraîchir les
Bundles partagés par exemple,
• Start Level : Un ensemble de Bundles qui doivent s’initialiser et s’exécuter avant les
autres.
• URL Handlers : Permet aux Bundles de contribuer avec des nouveaux schémas ou
Handlers à la class URL.
B) Services Système :
Fournissent des fonctions horizontales qui sont primordiales pour quelques systèmes, j’en
citerais quelques exemples
• Log Service : Journaliser les traces ou se mettre à l’écoute de traces,
• Configuration Admin : Fournit un modèle dynamique pour configurer et avoir des
informations de configuration,
• Device Access : Mécanisme qui permet de correspondre automatiquement un driver
avec un nouveau périphérique, et de télécharger le Bundle qui implémente ce driver,
• User Admin : Utilise une Base de données avec les informations sur les utilisateurs
pour l’authentification et tout ce qui concerne les autorisations,
• IO Conector : Permet aux Bundles de fournir des protocoles alternatifs pour le J2ME
javax.microedition.io package,
• Preferences Service : Fournit un accès à une base de données hiérarchique de
propriétés comme le système de registres de Windows.
C) Services de Protocole :
L’alliance OSGI a décris quelque services qui décrivent des protocoles externes au sein de la
plateforme OSGI.
• http Service : Exécute les Servlets que peuvent fournir les Bundles,
• UPnP : Universal Plug and Play est un nouveau standard en électronique.
D’autres types de services sont aussi disponibles dans la plateforme comme le "XML Parser"
qui permet à un Bundle de localiser un parseur avec les propriétés et la compatibilité avec
JAXP, ainsi qu’un service "Wire Admin" qui sert à expliciter les relations entre les Bundles et
la manière avec laquelle ils trouvent de nouveaux services, le tout dans un fichier de
configuration.
2.5 Limitations dans OSGI
Dans OSGI, les bundles sont utilisés pour conditionner et livrer les services avec leurs
implémentations et leurs ressources. Les services sont les unités principales de construction
d'applications dans le framework OSGI, et la plupart des services OSGI sont construits en
séparant l'interface de son implémentation. Ceci a comme résultat que les applications OSGI
sont construites exclusivement à partir de ces interfaces et qu’elles n'ont aucune connaissance
de leurs implémentations. De plus, les applications sont construites de façon dynamique, au
moment où de nouveaux services apparaissent ou disparaissent.
Bien que OSGI introduise un modèle différent de programmation, c’est à dire au moyen de
services, ceci peut se révéler complexe pour plusieurs raisons :
™ Il n’ y a pas de moyens pour décrire une architecture comme un ensemble d’instances
de composants connectées les unes aux autres.
™ Les services sont essentiellement différents des instances de composants communes
aux modèles ‘classiques’ dans le sens qu’ils s’agissent d’objets partagés qui, de
préférence ne possèdent pas d’état (du fait que le changement de cet état par un des
clients affecte tous les autres clients).
™ Les dépendances entre services ne sont pas gérées par le framework OSGI.
Il est possible qu’un service nécessite un autre pour fonctionner, et de plus cette dépendance
peut être statique (au démarrage du service) ou dynamique (le service a déjà été enregistré).
Ceci doit être programmé dans l’activateur du bundle, ce qui peut être une tâche complexe à
réaliser et difficile à changer.
Bien que OSGI fournisse des mécanismes très efficaces pour gérer le déploiement des unités
de livraison de services, il ne peut être considéré comme un modèle à composants ‘complet’
car plusieurs concepts communs aux modèles à composants ne sont pas présents dans celui-ci.
Nous pouvons citer en particulier le concept de type de composant, à partir duquel des
instances sont créées. Mais heureusement que plusieurs composants peuvent se greffer au
dessus de la plateforme OSGI et qui enrichissent celui-ci avec les concepts qui lui manquent
tel que le modèle Beanome.
Et j’espère que cet exposé serait le point de départ pour un autre sujet qui pourrait être les
composants au dessus de la plateforme OSGI.
Conclusion :
OSGI est un bon point de départ pour construire et déployer des applications dynamiques.
Cependant, OSGI possède plusieurs inconvénients. De manière générale, la programmation de
l'enregistrement des services et de la prise en compte de leur retrait restent des tâches
fastidieuses pour le développeur.
De plus, il n'est pas possible d'exprimer la structure d'une application en exprimant les
dépendances statiques ou dynamiques entre les services qui composent celle-ci.
Un autre inconvénient majeur d'OSGI concerne le démarrage des bundles. D'un part, un
bundle installé ne peut démarrer et activer ses services que si les packages qu'il requiert sont
déjà installés.
C’est pour cela que plusieurs composants ont été proposés pour fonctionner au dessus de
OSGI tel que beanome ou ServiceBinder qui permettent de pallier à ces problèmes et qui
seront sans aucun doute nos prochains sujets d’étude.
. OSGI constitue un bon point de départ pour développer des applications flexibles et
facilement gérables.
. Cependant, OSGI ne décrit pas l’architecture des applications ce qui rend difficile la vision
globale d’applications constituées de plusieurs composants.
Partenaires le l’OSGI Alliance :
Alpine Electronics Europe Gmbh
AMI-C
Aplix Corporation
Atinav Inc. *
Belgacom
BMW Group
Cablevision Systems
Deutsche Telekom
Echelon Corporation
Electricité de France (EDF)
Esmertec
Espial Group, Inc. *
ETRI Electronics and
Telecommunications Research Institute
France Telecom
Fraunhofer Institute for Integrated
Circuits IIS *
Gatespace Telematics AB *
Gemplus
IBM Corporation
Insignia Solutions *
Institute for Infocomm Research *
KDDI R&D Laboratories, Inc.
Mitsubishi Electric Corporation
Motorola, Inc.
NEC Corporation
Nokia Corporation
NTT
Oracle Corporation
Panasonic Technologies, Inc.
Philips Consumer Electronics
ProSyst Software AG
Robert Bosch Gmbh
Samsung Electronics Co., Ltd.
SavaJe Technologies, Inc. *
Sharp Corporation
Siemens AG
Sun Microsystems, Inc.
Telcordia Technologies, Inc.
Telefonica I+D
TeliaSonera
Texas Instruments, Inc.
Toshiba Corporation