Spécification de l’algorithme de déploiement
Phases du déploiement sensible au contexte
Perception
La phase de perception sert à récupérer les données nécessaires au déploiement. Elle permet de percevoir le contexte auquel est sensible l’application à déployer. Cette phase peut être activée par des sondes logicielles à différents moments, ou bien de façon périodique. Dans notre cas il s’agit non seulement du contexte local formé par l’environnement d’exécution mais aussi du contexte global c’est-à-dire des applications déployées sur les nœuds voisins. Les données de contexte doivent être fournies sous une forme qui puisse être interprétée par une couche logicielle pour pouvoir être traitées de façon automatique. La phase de collecte d’informations permet finalement de découvrir la liste des applications candidates pour le déploiement.
Analyse
La deuxième phase permet d’analyser les informations recueillies pendant la phase de collecte d’informations. La comparaison entre les ressources exigées par les applications et les ressources offertes par les nœuds de déploiement se fait pendant cette phase.
Décision
Une étape cruciale de l’algorithme de déploiement concerne la phase de prise de décision. En se basant sur les informations récoltées et analysées, l’algorithme de déploiement décide des applications à rapatrier.
Exécution
L’objectif de cette phase est d’appliquer la décision prise pendant la phase précédente. Elle concerne donc le rapatriement des applications choisies vers le nœud de déploiement. Elle peut englober d’autres opérations comme la suppression de certaines applications. Ces phases sont successives et forment le cycle de vie du déploiement. Une fois que la phase d’exécution a été faite, le cycle se répète pour suivre l’évolution du contexte. Afin de supporter ces phases, il faut avoir :
o Des structures de données pour décrire les besoins des utilisateurs, les caractéristiques des applications et des nœuds qui les supporteront ;
o Un ensemble de procédures telles que la vérification de la compatibilité entre l’application et son environnement d’exécution ;
o Une plate-forme pour supporter l’algorithme de déploiement et faciliter les échanges de données (descripteurs et applications) entre les nœuds.
Modèles pour automatiser le déploiement
Pour pouvoir fournir un support automatisé et générique, il est nécessaire de se baser sur une approche orientée modèle. Nous avons défini trois modèles :
o Un modèle d’application qui donne les exigences des applications, c’est-à-dire les ressources requises pour le bon fonctionnement de l’application.
o Un modèle de session qui décrit de façon abstraite la structure de la session ;
o Un modèle du nœud du déploiement qui décrit le contexte local, c’est-à-dire les ressources offertes par le nœud de déploiement ;
Ces modèles génériques permettent d’abstraire les informations de déploiement. Le terme générique se justifie par le fait que ces modèles sont indépendants des applications à déployer, du domaine de la session, et du nœud de déploiement. Les caractéristiques de chacun de ces modèles ont été décrites en utilisant le langage UML [37], universellement utilisé pour spécifier des systèmes. L’implantation de chaque modèle se fait en utilisant le langage XML [38]. Dans la suite, nous allons détailler chaque modèle.
Modèle d’application
Le modèle d’application proposé permet à un service de déploiement de choisir une application plutôt qu’une autre. Trois contraintes influencent ce choix :
o Le rôle d’un participant. Les applications doivent couvrir le rôle du participant. Par exemple, en utilisant un outil de partage de document, l’enseignant diffuse son cours vers les étudiants. En même temps, cet enseignant reçoit les commentaires sous forme textuelle en utilisant un autre outil de dialogue.
o Compatibilité avec l’environnement d’exécution. Le nœud du déploiement doit offrir les ressources nécessaires pour que les applications puissent fonctionner correctement.
o Interopérabilité avec les applications déjà déployées sur les nœuds des voisins. Les membres d’une session collaborative s’échangent des informations. Ainsi, les applications doivent être interopérables pour qu’elles puissent communiquer sans ambiguité et opérer ensemble.
Modèle de session
Un modèle basé sur un graphe étiqueté orienté a été d’abord introduit par T. Villemur [39], puis repris par L. Rodriguez [40] [41] pour représenter les interactions entre les utilisateurs d’une session collaborative. Nous avons étendu ce modèle pour l’adapter au contexte du déploiement collaboratif [42], [43]. Ainsi, les nœuds du graphe représentent les terminaux de déploiement avec leurs utilisateurs connectés. Les relations entre nœuds (traduites par les flèches), expriment les échanges de données entre terminaux. Les étiquettes sur les flèches sont composées de deux champs.
Modèle de nœud de déploiement
Un nœud de déploiement constitue l’environnement d’exécution des applications. Un nœud est défini par un identificateur ID. L’attribut Nom indique la désignation du nœud. L’attribut Type donne la catégorie (PC, PDA, …). Le modèle de nœud de déploiement doit contenir les informations sur (i) les Ressources offertes, qui contiennent les caractéristiques logicielles du nœud comme le système d’exploitation et les caractéristiques matérielles comme la mémoire, (ii) la QdS offerte (Qualité de Service) qui contient la liste des services logiciels de ce nœud. Notre proposition est proche des descriptions de contextes d’exécution faites dans les travaux décrits dans l’état de l’art (RDF, CC/PP, OWL et COACH).
|
Table des matières
Chapitre 1 Introduction
1.1 Motivation et problématique
1.2 Position de notre travail et contributions
1.3 Organisation de la thèse
Chapitre 2 Etat de l’art et synthèse
2.1 Introduction
2.2 Définitions
2.2.1 Session collaborative
2.2.2 Stratégies de déploiement
2.2.3 Catégories de déploiement
2.2.4 Types de déploiement
2.2.5 Contrôle du déploiement
2.2.6 Performance du déploiement
2.2.7 Sensibilité au contexte
2.2.8 Catégorie de reconfiguration
2.3 Systèmes de déploiement
2.3.1 Déploiement automatique indépendant du contexte
2.3.2 Déploiement automatique sensible au contexte
2.4 Eléments descriptifs pour automatiser le déploiement
2.4.1 Description des applications
2.4.2 Description des ressources
2.5 Conclusion
Chapitre 3 Spécification de l’algorithme de déploiement
3.1 Introduction
3.2 Phases du déploiement sensible au contexte
3.3 Modèles pour automatiser le déploiement
3.3.1 Modèle d’application
3.3.2 Modèle de session
3.3.3 Modèle de nœud de déploiement
3.4 Algorithme de déploiement et de reconfiguration
3.4.1 Vue générale
3.4.2 Déploiement initial
3.4.3 Déploiement ultérieur (ou reconfiguration)
3.5 Conclusion
Chapitre 4 Conception de la plate-forme de déploiement et de reconfiguration
4.1 Introduction
4.2 Fonctionnalités requises pour le déploiement
4.2.1 Accès au réseau P2P
4.2.2 Interaction locale
4.2.3 Interaction distribuée
4.2.4 Contrôle du déploiement
4.3 Architecture
4.3.1 Couche Pair-à-Pair
4.3.2 Couche noyau générique
4.3.3 Couche déploiement
4.4 Conclusion
Chapitre 5 Expérimentations
5.1 Introduction
5.2 Utilisation de l’API de déploiement
5.2.1 Simulateur de déploiement
5.2.2 Sessions collaboratives synchrones
5.3 Evaluation de l’algorithme de déploiement
5.3.1 Configuration de l’expérimentation
5.3.2 Vérification de la compatibilité
5.3.3 Vérification de l’interopérabilité
5.3.4 Génération des configurations de déploiement
5.3.5 Validation des configurations de déploiement
5.3.6 Bilan de l’évaluation de déploiement
5.4 Evaluation de la couche noyau générique
5.4.1 Evaluation de la découverte des contenus
5.4.2 Evaluation des capacités de rapatriement des contenus
5.5 Conclusion
Chapitre 6 Conclusion