Plateformes applicatives

L’Open Cable Application Platform (OCAP) est une plateforme logicielle, basée sur le standard Globally Executable Multimedia Home Platform (GEM-MHP) [61], permettant de gérer et de livrer des services télévisuels chez des clients de télévision câblée. Conçu par le

Cable Television Laboratories, un consortium de recherche en câblodistribution, OCAP est à

la fois un système d’exploitation pour passerelle d’accès à la télévision câblée et un intergiciel pour la gestion des services chez les clients.

Développé à partir du langage orienté objet Java version Micro Édition(J2ME), OCAP est un intergiciel pouvant être déployé sur plusieurs types de passerelle, pourvu qu’il y ait une machine virtuelle J2ME fonctionnelle correspondante au matériel. À l’aide du câble télévisuel, il est possible d’envoyer des requêtes de gestion ou de mise à jour de composantes logicielles vers les passerelles OCAP. Cet intergiciel permet un contrôle total du cycle de vie des applica- tions par l’installation, le démarrage, l’arrêt, la désinstallation et la mise à jour des applications. OCAP utilise majoritairement la méthode Push pour acheminer les requêtes de gestion, i.e. que les requêtes sont envoyées par les gestionnaires vers les passerelles. Il est d’ailleurs important de noter qu’il est possible de gérer indépendamment chaque passerelle ou bien de les gérer globalement. De plus, la stratégie de gestion adoptée est l’orchestration, i.e. que ce sont les gestionnaires qui gèrent le contenu et la synchronisation des passerelles. Il n’y a d’ailleurs au- cune communication directe entre les passerelles, ce qui empêche l’utilisation d’une stratégie de chorégraphie. Enfin, en plus de la gestion des logiciels, la plateforme OCAP intègre des mécanismes de facturation de services et offre des fonctionnalités permettant de récolter des statistiques d’utilisation.

L’intergiciel OCAP permet de gérer à distance le cycle de vie complet des applications déployées sur des passerelles d’accès à la télévision câblée. Il offre également des outils in- téressants de journalisation et de surveillance des applications déployées. Toutefois, à l’image d’OSCAR, cette solution a été conçue pour un type de système précis, les passerelles télévi- suelles, et convient plus ou moins bien au contexte hétérogène des espaces intelligents. Toute- fois, son architecture et ses fonctionnalités permettant de gérer aisément plusieurs passerelles et leurs applications à la fois doivent être retenue.

OSGi

L’OSGi Alliance1_{, anciennement connu sous le nom de l’Open Services Gateway initia-} tive, est un regroupement d’entreprises qui se sont unies en 1999 pour créer des standards ouverts de plateformes logicielles. On compte parmi ses membres les compagnies Ericsson, Nokia, Siemens, IBM et biens d’autres. Ainsi, l’OSGi Alliance propose des spécifications [42] de plateformes Java appliquant l’approche orientée service. Ces spécifications ont adopté dès le départ des mécanismes permettant de gérer tous les aspects du cycle de vie des modules, incluant un mécanisme de mise à jour, téléchargeant les nouvelles versions des modules via des serveurs d’applications.

Les spécifications OSGi reflètent les besoins des entreprises membres du consortium de pouvoir déployer et gérer facilement des logiciels dans leurs produits commerciaux. Ainsi, des entreprises telles que Volvo, Ericsson et Philips utilisent OSGi comme plateforme de dé- ploiement de services dans leurs produits (voitures, téléphone portable, système multimédia), permettant ainsi une gestion logicielle plus efficace. Fait important à noter, l’IDE Eclipse est également basé sur la plateforme OSGi et son concept de plug-in est une extension de la mé- canique modulaire d’OSGi.

Tout comme OCAP, la spécification OSGi repose sur la technologie Java, une machine vir- tuelle Java doit donc être présente sur l’appareil accueillant la plateforme. Dans la spécification OSGi, les différentes applications déployées sont divisées en modules, contenus dans des fi- chiers de type jar, nommés bundles. Ces modules s’échangent entre eux des services et du code afin de former les fonctionnalités de l’application : interface homme-machine, gestion de la persistance des données, communication externe, etc. Un service, dans la plateforme OSGi, est un objet offrant des méthodes pouvant être exécutées par les autres modules. L’intérêt de l’ap- proche orientée service permet un dynamisme plus important entre les modules, par exemple en intégrant dynamiquement de nouveaux modules aux applications existantes, et une gestion indépendante des modules, permettant la mise à jour de parties précises des applications, tout en réduisant les effets de bord des actions de gestion sur la continuité de service des appli- cations. L’exécution et l’échange des données entre modules sont régis par plusieurs couches définies dans la spécification. Ainsi, OSGi divise son architecture en quatre couches :

– la couche Sécurité : gérant la validité du code des modules ;

– la couche Module : gérant le chargement du code et l’exécution de celui-ci ; – la couche Cycle de vie : permettant de gérer l’état des divers modules ;

– la couche Service : permettant l’échange de services entre les divers modules.

Dans la version quatre de la spécification OSGi, aucun mécanisme de gestion à distance des modules n’est intégré. Toutefois, il est relativement aisé d’en développer et quelques modules permettant la gestion via une interface web, par Telnet et par SOAP ont été développés par la communauté de développeur OSGi. En considérant la spécification de base et sa fonctionnalité de mise à jour, on peut affirmer qu’OSGi utilise la méthode Pull. Toutefois, l’utilisation des modules de gestion à distance permet le mode Push. Enfin, puisque les mécanismes de gestion d’OSGi concernent les applications déployées localement sur la plateforme et non entre plate- formes, il n’y a donc pas de stratégie de gestion. En utilisant les modules de gestion à distance cités plus haut, on tend alors vers une stratégie d’orchestration, où le gestionnaire coordonne et commande la gestion des plateformes OSGi.

Plusieurs spécifications additionnelles à OSGi existent. Deux de ces spécifications sont particulièrement intéressantes face à notre problématique : l’OSGi Bundle Repository (OBR) et

distributed OSGI(dOSGi). La première spécification définit une mécanique permettant de défi- nir les dépendances fonctionnelles de modules OSGi envers d’autres modules. Un mécanisme de résolution des dépendances est également spécifié permettant de gérer automatiquement l’installation et le démarrage, si nécessaire, des dépendances d’une application. Sans être aussi complet que les Debian Package, OBR offre donc des fonctionnalités permettant de réduire de façon significative la difficulté de la gestion des dépendances fonctionnelles. La spécification dOSGi quant à elle définie la mécanique permettant à des modules OSGi d’offrir des services aux plateformes OSGi déployées sur d’autres matériels via des web services. De plus, la créa- tion des web services et des stubs2 _{chez les plateformes clientes est automatisée par dOSGi.} Les fonctionnalités de dOSGi permettent, entre autres, le développement de services offrant les fonctionnalités de gestion du cycle de vie des modules déployés sur la plateforme OSGi

La plateforme à service OSGi offre des fonctionnalités permettant de contrôler entière- ment le cycle de vie des applications qui y sont déployées. Ses capacités orientées services et la possibilité de modulariser les applications offrent des possibilités très intéressantes pour la continuité de service. OSGi permet également un dynamisme dans l’intégration des nouvelles applications qui est inégalé par les solutions précédentes, en permettant l’ajout de compo- santes logicielles à la plateforme en cours d’exécution du système. À la fois un avantage et un inconvénient, l’utilisation du langage Java permet à OSGi d’être utilisé sur un nombre impor- tant d’appareils, ce qui est important dans le contexte hétérogène des espaces intelligents. Par

2_{Un stub est un objet permettant de représenter les fonctionnalités d’un service distant chez un système client} et d’abstraire la mécanique de communication avec le système distant

contre, quoi qu’il soit possible d’utiliser des bibliothèques natives via le Java Native Interface (JNI), OSGi est plutôt cantonné aux applications utilisant la technologie Java. Pour les sys- tèmes embarqués de faible puissance, la disponibilité de machine virtuelle Java est faible (via les JVM Squawk ou Dalvik d’Android si le matériel est supporté).