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 à

Transcription

1 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).

2 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é.

3 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.

4 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é

5 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.

6 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.

7 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é.

8 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.

9 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.

10 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

11 l interface org.osgi.service.log.logservice et peut avoir des propriétés de type fournisseur=ibm. 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 DSL Powerline Wireless Service delivery OSGi Local Network HomeRF JINI Bluetooth CEBus UPnP Home Plug HAVi

12 Les réseaux domestiques intelligents 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 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.

13 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 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 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.

14 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

15 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