Les plateformes d'exécution intéressantes sont celles qui définissent ou du moins permettent le déploiement et l'exécution de modules applicatifs. Cette section décrit les plateformes OSGi [OSGi05], Java MIDP version 2 [MIDP02] et 3, Linux, Microsoft .NET, SCOMO [SCOM08] avec la grille des définitions de la section 3.1.5.
3.3.1 Bundles OSGi
La technologie OSGi définit une plateforme de déploiement d'application modulaire avancée au-dessus de Java. Loin de la cible initiale des passerelles Internet lors de la fondation du consortium en 1999, la définition de la technologie par l'Alliance OSGi elle-même a évoluée vers un objectif plus général : le système modulaire dynamique de Java ("OSGi technology is the dynamic module system for Java" est écrit sur la page d'accueil du site www.osgi.org). La technologie définit des mécanismes de partage et d'isolation de code à grain fin entre modules logiciels, appelés bundles. Grace à ces mécanismes et à un ensemble de bonnes pratiques, il est possible d'envisager des applications constituées de multiples bundles qui coexistent et partagent du code selon leurs affinités.
Voici les caractéristiques du cycle de vie logiciel des entités de la plateforme OSGi version 4.1 [OSGi05] :
• Paquetage de déploiement : un Deployment Package est défini dans le chapitre Deployment de la Spécification Mobile de l'Alliance OSGi ou JSR 232. Il représente un ficher jar contenant un manifest listant différentes ressources pouvant comprendre des bundles OSGi. Il permet de garantir l'installation, la mise à jour et la désinstallation atomique de ressources interdépendantes.
• Unité de déploiement : le bundle OSGi est un ficher JAR qui peut contenir des fichiers Java, d'autres fichiers JAR, un fichier Manifest décrivant les métadonnées du bundle. Il peut aussi contenir d'autres fichiers non spécifiques à OSGi.
• Unité d'exécution : tout bundle OSGi déclarant un fichier appelé "Activator" peut être démarré ou arrêté sur la plateforme. Les autres bundles sont des librairies de ressources inertes.
• Dépendances : le cœur de la spécification OSGi définit la déclaration de packages versionnés de code privés, publics, requis. La plateforme OSGi est responsable du diagnostic de résolution des dépendances de packages entre bundles. Un bundle non résolu ne peut pas démarrer. Des modèles à composants plus sophistiqués (e.g., OSGi Declarative Services) permettent la définition de composants intérieurs aux bundles et de dépendances de services.
• Métadonnées : les propriétés suivantes sont définies pour les bundles OSGi. On peut distinguer :
o Des propriétés génériques optionnelles décrivant la provenance du bundle : Category, ContactAddress, Copyright,
Description, DocURL, Localization, Name, Bundle-Vendor, Bundle-Version.
o Des propriétés spécifiques à la plateforme OSGi utiles au déploiement et à l'exécution du bundle : ActivationPolicy, Activator, Bundle-Classpath, Bundle-ManifestVersion, Bundle-NativeCode, Bundle-RequiredExecutionEnvironment, Bundle-SymbolicName, Bundle-UpdateLocation, DynamicImport-Package, Export-Package, Export-Service, Fragment-Host, Import-Package, Import-Service, Require-Bundle.
• Opérations de gestion de cycle de vie : tout bundle peut être installé, désinstallé, mis à jour, démarré, stoppé : Install, Uninstall, Update, Start, Stop. Toutefois, le démarrage et l'arrêt d'un bundle ne possédant pas d'activateur n'ont aucun effet. La spécification ne définit pas d'opération de résolution, les mécanismes de résolution sont donc déclenchés par la plateforme elle-même.
• Etats des unités de déploiement et des unités d'exécution : Installed, Resolved, Uninstalled, Active. L'état "Resolved" indique que le diagnostic de résolution de dépendance a été effectué et que les dépendances sont effectivement résolues. Les bundles OSGi passent par des états transitoires définis : Starting, Stopping (cf. Figure 34).
Figure 34 Cycle de vie du bundle OSGi
• Evénements : ils sont conséquents aux changements d'états : "Installed", "Uninstalled". L'activité d'un bundle est visible aussi par la notification des états des services fournis : "Registered", "Modified", "Unregistered".
• Répertoires d'unités de déploiement locaux et distants : bien que le format ne soit pas spécifié officiellement, un standard de facto décrit les répertoires de bundles : OSGi Bundle Repository. Ce format peut aussi être utilisé autant pour un répertoire distant que pour un répertoire co-localisé avec la plateforme OSGi.
• Répertoires d'unités d'exécution locaux : les plateformes OSGi répandues offrent un outil listant les bundles OSGi avec leur état et leurs métadonnées. L'originalité de la spécification OSGi est par ailleurs la définition d'un répertoire de services.
3.3.2 MIDlets Java
Le profil Java MIDP (Mobile Information Device Profile) définit des entités logicielles, pouvant se déployer sur une plateforme de déploiement contrainte, la machine virtuelle embarqué de la configuration Java CLDC (Connected Limited Device Configuration). MIDP a été l'objet de 3 versions successives. Ce qui est indiqué ici est vérifié par MIDP2 [MIDP02] et par MIDP3. Plus restrictif que le modèle OSGi, CLDC/MIDP spécifie un mode tout ou rien pour le partage de code entre entités logicielles. Ce mode est appelé modèle de bac à sable ("sandbox"). A l'intérieur d'une MIDlet Suite, unité de
déploiement MIDP, toute partie du code a visibilité sur le code de la plateforme et sur celui de toutes les autres parties. En revanche, aucune partie n'a de visibilité sur le contenu des autres MIDlet Suites. Si MIDP3 apporte la notion de partage de librairies de code (LIBlets) entre MIDlet Suites, elle respecte le modèle de bac à sable en ne permettant aucun partage d'objets à l'exécution (la librairie "partagée" est chargée en mémoire séparément par chaque MIDlet Suite). Seuls les appels interprocessus (IPC) sont permis entre MIDlet Suites à l'exécution. Chaque MIDlet Suite peut contenir plusieurs unités d'exécution appelées MIDlets. Le cycle de vie de chacune des 2 entités est décrit par la Figure 35.
Voici les caractéristiques de la plateforme CLDC/MIDP [MIDP02] :
• Paquetage de déploiement : aucune entité ne correspond exactement à ce concept. Une MIDlet Suite définissant avec ses LIBlets une application auto-contenue et la MIDlet Suite ayant peu d'interférences avec les autres MIDlet Suite, le paquetage de déploiement peut être confondu avec l'unité de déploiement. MIDP3 spécifie simplement que l'installation d'une MIDlet Suite implique l'installation des LIBlets dont elle dépend.
• Unité de déploiement : une MIDlet Suite est un fichier JAR contenant le code d'une ou plusieurs MIDlets, un fichier JAD (Java Application Descriptor) les décrivant et d'autres ressources non spécifiques à Java MIDP. Le fichier JAD définit aussi les dépendances à des LIBlets, autres unités de déploiement spécifiées.
• Unité d'exécution : une ou plusieurs MIDlets peuvent être contenues dans une MIDlet Suite.
• Dépendances : une MIDlet Suite peut contenir une ou plusieurs MIDlets. Avec MIDP3, toute MIDlet peut requérir des librairies qui se trouvent à l'extérieur de la MIDlet Suite.
Figure 35 Cycles de vie d'une MIDlet Suite et de ses MIDlets
• Métadonnées : les métadonnées sont écrites dans le fichier JAD.
o Des propriétés génériques optionnelles décrivant la provenance de la MIDlet Suite : MIDlet-Name, MIDlet-Version, MIDlet-Vendor, MIDlet-Jar-URL, MIDlet-Jar-Size, MIDlet-Description, MIDlet-Icon, MIDlet-Info-URL, MIDlet-Data-Size.
o Des propriétés spécifiques à la plateforme Java MIDP utiles au déploiement de la MIDlet Suite et à l'exécution de ses MIDlets : MicroEdition-Profile, MicroEdition-Configuration, n, Install-Notify, MIDlet-Delete-Notify, MIDlet-Permissions, MIDlet-Permissions-Opt, MIDlet-Push-n, MIDlet-specific attributes, MIDlet-Jar-RSA-SHA1
• Opérations de gestion de cycle de vie (cf. Figure 35)
o des unités de déploiement : Install, Remove, Update.
o des unités d'exécution : StartApp, StopApp. Les 2 premières versions de MIDP ajoutaient l'opération de mise en pause (PauseApp). Cette opération est rendue obsolète dans la 3ème version.
• Etats (cf. Figure 35)
o des unités de déploiement : Installed, Removed.
o des unités d'exécution : Destroyed, Active. L'état "Paused" est obsolète depuis la version 3. Les MIDlets apparaissent avec l'état "Destroyed" lorsque la MIDlet Suite associée est installée (cf. partie droite de la Figure 35).
• Evénements : seul le gestionnaire d'application global, appelé JAM (Java Application Manager), est conscient des transitions d'état des MIDlets.
• Répertoires d'unités de déploiement locaux ou distants : il est possible de créer un répertoire de MIDlet Suite avec les informations des descripteurs d'applications.
• Répertoires d'unités d'exécution locaux : les plateformes MIDP offrent généralement un outil listant les MIDlets disponibles et leurs états.
3.3.3 Packages Linux
Linux est certainement l'environnement d'exécution le plus répandu sur les équipements embarqués du réseau domestique. Linux pourrait être érigé en tant que standard de facto s'il ne possédait pas tant de variantes. Les distributions Slackware, Debian et Red-Hat sont les principales distributions dont dérivent les autres avec plus ou moins de succès : Ubuntu, Mepis, Zenwalk, Mandriva, Suze, etc. La structure et le cycle de vie des entités logicielles définies par ces variantes diffèrent de l'une à l'autre. Certains travaux montrent pourtant qu'un système modulaire aux dépendances déclaratives 'à la OSGi' pourrait être aisément normalisé au-dessus d'une distribution Linux. Le prototype nommé Home Gateway Linux [Roy07] a été élaboré au-dessus d'une distribution Slackware. Les dépendances entre paquetages, unités de déploiement des distributions Linux, sont spécifiées par des dépendances vers des noms de paquetages. Ces déclarations de dépendances ne sont toutefois pas de grain aussi fin que les déclarations de paquetage de code Java entre bundles OSGi.
Malgré les variantes offertes par les distributions Linux, une carte d'identité générique peut être tentée :
• Paquetage de déploiement : aucune entité ne correspond exactement à ce concept. Le paquetage Linux peut toutefois être considéré en tant que tel puisqu'il peut être téléchargé sans être installé.
• Unité de déploiement : le paquetage ou package commun aux 3 familles Linux.
• Unité d'exécution : le script RC commun lui aussi à la plupart des distributions. Le processus init montre aussi d'autres variantes d'unités exécutables. [RoF07] énumère quelques systemes Linux importants et comparent la gestion du cycle de vie de telles unités.
• Dépendances : les dépendances entre paquetages sont explicites dans certaines distributions comme celles de la famille Debian où le gestionnaire de paquetages est capable de rapatrier toutes les dépendances d'un paquetage demandé. Entre les paquetages et les scripts RC, les métadonnées manquent afin de lier les scripts aux paquetages requis. C'est ce que palie le prototype de [Roy07].
• Métadonnées : un script RC n'est décrit par aucune métadonnée. Les packages RedHat et les packages Debian possèdent en revanche des métadonnées afin de décrire les dépendances entre eux. Voici la liste des propriétés Debian :
o Des propriétés génériques optionnelles décrivant la provenance du package : Package, Version, Section, Installed-Size, Maintainer, Description.
o Des propriétés spécifiques à la plateforme Debian et utiles au déploiement : Priority, Architecture, Essential, Depends, Pre-Depends, Recommends, Suggests, Conflicts, Replaces, Provides.
• Opérations de gestion de cycle de vie (cf. Figure 36)
o des unités de déploiement : Install, Remove, Upgrade1.
o des unités d'exécution : Start, Stop. Ce sont les opérations les plus communément supportées par les scripts RC et autres processus init. [RoF07] montre des listes d'opérations différentes disponibles sur quelques distributions en supplément de start et stop (e.g., restart, respawn, init, kill).
Figure 36 Vision simple des diagrammes d'états des entités logicielles Linux
• Etats (cf. Figure 36)
o des unités de déploiement : Installed, Removed, Resolved. Comme les mécanismes de résolution de dépendances existent sur les plateformes Debian et RedHat, l'état "Resolved" pourrait être un état pour les packages de la plateforme. De nombreux états intermédiaires existent selon les distributions mais ne sont pas représentés ici.
o des unités d'exécution : Inactive, Active. Les scripts RC peuvent être defines alors que les packages utiles ne sont pas encore disponibles. Toutefois, il ne peuvent être activés que lorsque ces packages sont présents.
• Evénements : [Roy07] utilise les signaux POSIX associé à l'arrêt, la pause et la continuation de démons init. Pour les scripts RC, il est possible de suivre l'activité de ceux-ci grâce à la table des processus.
• Répertoires d'unités de déploiement locaux ou distants : des répertoires de packages Debian, appelés Debian Repositories, existent sur Internet.
1 Même si le manuel Debian montre que le détail des opérations est beaucoup plus compliqué à grain fin, la finalité des ensembles d'opérations est bien l'installation, la mise à jour et la désinstallation : http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-mscriptsinstact
• Répertoires d'unités d'exécution locaux : la liste des processus offre le moyen de suivre l'état des processus en cours d'exécution.
3.3.4 Assemblies .NET
.NET est un environnement d'exécution innovant spécifié par Microsoft. Son originalité tient principalement dans la définition d'une machine virtuelle interprétant un code binaire commun à la compilation de plusieurs langages de programmation (e.g., C#, VB#, J#). .NET est né dans les mêmes années que la plateforme OSGi. Certaines caractéristiques rendent ces deux technologies similaires : machine virtuelle, chargement dynamique de modules logiciels appelés "assembly", résolution de dépendances par la plateforme par utilisation de métadonnées. Certains travaux [EDH06] montrent les limites d'une approche OSGi sur la plateforme .NET. Le partage et l'isolation de code sont définis au niveau des types. Les niveaux de visibilité appelés "public" et "internal" distinguent les types qui sont visibles à l'extérieur de l'assembly des types qui demeurent privés au code interne de l'assembly. Le code public d'une assembly est visible par les autres assembly d'un même domaine tandis que des assemblies de Domaines différents ne peuvent communiquer que par communication inter-processus (IPC). Un assembly peut être chargé à l'exécution par un ou plusieurs Domaines. En revanche, les assemblys sont chargées séparément par les AppDomain (pas de partage d'objets) et un assembly ne peut être déchargé dans un Domaine sans décharger tout le Domaine. Ces limites placent la modularité de la plateforme .NET entre la flexibilité OSGi et le mode tout-ou-rien du modèle de bac à sable de MIDP3.
Voici les caractéristiques des entités logicielles sur la plateforme .NET :
• Paquetage de déploiement : non défini. Les installeurs d'applications Windows peuvent être considérés comme le Paquetage de déploiement .NET. Ces installeurs sont téléchargeables et permettent l'installation directe de plusieurs ressources interdépendantes. Après installation, l'installeur peut être supprimé ou gardé pour une réinstallation.
• Unité de déploiement : l'assembly est un ensemble de ressources décrit par un fichier manifest. Il peut être chargé dynamiquement par un ou plusieurs Domaines d'Applications.
• Unité d'exécution : tout assembly propose une méthode générique d'invocation avec un tableau de paramètres (équivalent à la méthode Java main()).
• Dépendances : chaque assembly déclare les types qu'il exporte et les assemblies qu'il requiert.
• Métadonnées : les propriétés suivantes sont définies par chaque assembly dans son manifeste. Les propriétés suivantes se voient attachées un préfixe "Assembly" dans la spécification. On peut distinguer :
o Des propriétés génériques optionnelles décrivant la provenance de l'assembly : Culture, Flags, Version, Company, Copyright, FileVersion, InformationalVersion, Product, Trademark, DefaultAlias, Description, Title.
o Des propriétés spécifiques à la plateforme .NET utiles au déploiement et à l'exécution des assemblies : Name, FileList, TypeReference, ReferencedAssemblies, EntryPoint, Configuration, DelaySign, KeyFile, KeyName.
• Opérations de gestion de cycle de vie (cf. Figure 37) : tout assembly peut être téléchargé et supprimée dans le cache local appelé "Global Assembly Cache" ou dans des caches particuliers à chaque Domaine. Puis, l'assembly peut être chargé (Assemly.Load()), invoqué (Assembly.EntryPoint.invoke(Object[]
optionalParams) ou AppDomain.ExecuteAssembly(Assembly a)). La spécification ne définit pas d'opération de résolution, les mécanismes de résolution sont donc déclenchés par la plateforme elle-même.
• Etats des unités de déploiement et des unités d'exécution (cf. Figure 37) : Downloaded, Loaded, Unloaded. La détermination de l'activité d'un assembly n'est pas spécifiée. Et bien que les mécanismes de résolution existent, ils ne sont pas utilisés avant l'exécution de l'assembly.
Figure 37 Diagramme d'état d'un assembly .NET
• Evénements : ils sont conséquents aux changements d'états : "AssemblyLoad", "AppDomainUnload", "AssemblyResolve" (lorsqu'un type requis n'est pas présent à l'exécution).
• Répertoires d'unités de déploiement locaux et distants : un cache global à la machine, appelé Global Assembly Cache est un répertoire où puisent les Domaines d'Applications.
• Répertoires d'unités d'exécution locaux : la plateforme .NET est livrée sur Windows avec un outil (.Net Framework Configuration) listant les assemblies installées et permettant la désinstallation de chacun avec leurs métadonnées. 3.3.5 Composants SCOMO : une tentative de généralisation
SCOMO [SCOM08] est un standard en cours de spécification par l'Open Mobile Alliance. A la différence des autres plateformes présentées, SCOMO est un protocole, qui lié à OMA DM (cf. section 3.2.2), permet de gérer le cycle de vie des entités logicielles de plateformes embarquées. Il n'est donc lié à aucun langage de programmation et suit une approche généraliste similaire à la spécification UPnP Device Management, c'est-à-dire la définition d'un protocole pouvant s'adapter au contrôle de toute technologie de plateforme logicielle.
Voici les caractéristiques des entités décrites par SCOMO :
• Paquetage de déploiement : le Delivery Package (DP). Celui-ci permet l'installation des unités de déploiement contenues. Le DP peut être retiré de la plateforme sans désinstaller les unités de déploiement.
• Unité de déploiement : le Deployment Component (DC) qui est défini en tant que représentation administrable du composant logiciel (Software Component).
• Unité d'exécution : non définie.
• Métadonnées : chacune des entités est décrite par des métadonnées qui sont répertoriées dans l'arbre de données de l'équipement. Plusieurs données sont les mêmes entre un DP et un DC :
o Des propriétés génériques optionnelles décrivant la provenance du package : name, description, version, PkgType.
o Des propriétés spécifiques à la gestion SCOMO et utiles au déploiement : PkgID (DP), PkgURL, ID (DC), data.
Figure 38 Diagramme d'état du Delivery Package SCOMO
• Opérations de gestion de cycle de vie :
o des paquetages de déploiement (cf. Figure 38) : Download, DownloadInstall, DownloadInstallInactive, Install, InstallInactive, Remove. Des actions composées sont spécifiées : DownloadInstall, DownloadInstallInactive. La raison pourrait être a priori la possibilité de s'adapter au mieux aux différentes opérations spécifiées dans les différentes plateformes logicielles existantes. Elle pourrait être aussi de rendre les opérations plus rapides et assurer leur cohérence en les groupant. La citation suivante, qui indique qu'une action composée est effectuée par réalisation des deux actions correspondantes, semble en faveur de la seconde raison : "When a Composed Primitive is executed, two state transitions happen in the Device. For example if DownloadInstall is executed, a Deployment Component transits from Not Downloaded State to Delivered State after successful download procedure. It transits to Active State after successful installation procedure. If the latter processing fails it remains in previous state and the second state transition does not happen."
o des unités de déploiement (cf. Figure 39) : Activate, Deactivate, Remove. Les unités de déploiement sont explicitement activables et dés-activables. L'état "Inactive" correspond à un état où aucune application ne peut utiliser l'unité. L'activation permet l'accessibilité des applications dépendantes à l'utilisateur. Cette activation semble correspondre à la demande de résolution des dépendances de l'unité. Les applications n'apparaissent à l'utilisateur que lorsque tous les DUs correspondants sont actifs.
• Etats :
o des paquetages de déploiement (cf. Figure 38) : Not Downloaded, Delivered, Installed, Removed.
o des unités de déploiement (cf. Figure 39) : Inactive, Active, Removed.
• Répertoires de paquetages de déploiement locaux ou distants : l'inventaire des DPs dans l'état "Not Downloaded" permet de répertorier localement les unités disponibles pour le téléchargement. L'inventaire des DPs dans l'état "Delivered" est aussi maintenu et permet de lister les éléments disponibles pour l'installation.
• Répertoires d'unités de déploiement locaux : l'inventaire des DCs est aussi maintenu dans l'arbre de données de l'équipement.
Figure 39 Diagramme d'état du Deployment Component (execution unit) SCOMO
3.3.6 Autres plateformes aux applications modulaires
D'autres plateformes d'exécution de modules logiciels existent. Les navigateurs tels que Mozilla Firefox montrent un système de plugins, les plateformes Java EE montraient jusqu'à l'adoption générale d'OSGi des systèmes modulaires variés, Qualcomm BREW est un système répandu de chargement d'applications sur les téléphones mobiles, etc.
4 SYNTHESE
Le réseau domestique est un réseau pervasif par nature. Il est ouvert à la connexion dynamique d'équipements distribués hétérogènes. Cet environnement est l'objet de nombreuses applications en gestation dans les laboratoires de recherche des fabricants et des fournisseurs de services de télécommunications. Pour ces raisons, il est le terrain choisi pour