Un utilisateur peut exploiter les services exposés par l'application, en utilisant simplement un navigateur Web. A la première requête interceptée (connexion), le servlet retourne la page principale de l'application. Cette page permet de sélectionner les services voulus (Figure 73).
Figure 73. Page principale du portail
L'utilisateur peut ensuite visualiser des vidéos, faire des achats ou faire des jeux. Sa requête est envoyée au servlet. Ce dernier la redirige vers le composant concerné, récupère la réponse (sous forme de page HTML), et la retourne, enfin, à l'utilisateur.
L'architecture de l'application en termes d'instances et de connexions, peut être suivie à tout moment grâce à l'interface graphique de contrôle de DYVA. La Figure 74 illustre l'architecture de l'application portail. La convention que nous avons adoptée pour nommer les instances de composants est très simple. Chaque instance porte le nom de son composant, suivi de l'ordre de création de cette instance. A titre d'exemple, la première instance du composant "MySQLDBManager" (gestionnaire de la base de données MySQL [MySQL] du portail) est nommée "MySQLDBManager_0". Si on crée une autre instance, elle sera nommée "MySQLDBManager_1" et ainsi de suite.
Figure 74. Architecture de l'application portail
La partie gauche de l'interface comporte deux onglets. Le premier (Components) présente la liste des composants, le deuxième (Instances) montre la liste des instances formant l'application. La partie droite de l'interface décrit l'architecture de l'application, en termes d'instances et de connexions entre elles. Chaque connexion entre deux ports de deux instances est matérialisée par un arc étiqueté. L'étiquette décrit le nom du port source et son type (le nom du port cible, dans le cadre d'OSGi, coïncide simplement avec le type de ce port).
Il est possible d'utiliser les menus pour reconfigurer l'application. Il est aussi possible d'utiliser des menus contextuels, attachés aux différents éléments de l'interface. Dans la partie droite par exemple, il est possible de créer de nouvelles instances, et il est possible d'afficher des informations d'un composant particulier (Figure 75).
Figure 75. Affichage de la description d'un composant
Dans la suite, nous discutons l'un des scénarios de reconfiguration dynamique de l'application portail.
6.3.1 Scénario de reconfiguration
Le scénario de reconfiguration, que nous illustrons dans cette section, concerne la visualisation des vidéos exposées à travers le portail. Les vidéos qui peuvent être visualisées existent en double version : haute et basse qualité. L'application comporte deux composants pour diffuser les vidéos. Le premier diffuse des vidéos de haute qualité. Il nécessite une bonne bande passante pour fonctionner normalement (bande passante requise > 600 KB/S). Le deuxième, quant-à-lui, permet de diffuser les vidéos de basse qualité. En revanche, il n'est pas gourmand en bande passante (fonctionne avec une bande passante même inférieur à 400 KB/S).
On souhaite passer d'un composant à l'autre, en fonction de la bande passante du réseau. Ce passage doit évidemment se faire dynamiquement, car on ne peut pas s'amuser à arrêter et à redémarrer tout le portail à chaque fois que le passage d'une version à l'autre est nécessaire. La dynamicité est encore plus justifiée si la bande passante change de façon fréquente.
Nous avons développé un outil qui simule les variations de la bande passante, et qui envoie périodiquement des événements au système de reconfiguration. Chaque événement décrit la dernière valeur notifiée (si elle existe), et la nouvelle valeur de la bande passante. La Figure 76 illustre cet outil de simulation.
Figure 76. Simulation des variations de la bande passante
Pour automatiser le passage d'une version à l'autre, des règles de reconfiguration sont nécessaires. Les deux règles suivantes correspondent aux hypothèses que nous avons citées auparavant :
[RULE]
ON: BANDWIDTH_EVENT
IF: ( (NEWBW = 400) AND (NEWBW < OLDBW) )
THEN: replace VideoServer-High_0 VideoServer-Low_0 [RULE]
ON: BANDWIDTH_EVENT
IF: ( (NEWBW = 600) AND (NEWBW > OLDBW) )
THEN: replace VideoServer-Low_0 VideoServer-High_0
La première règle exprime que si la nouvelle valeur de la bande passante vaut 400KB/S, et que cette valeur est inférieure à l'ancienne (la bande passante est en train de chuter), il faut passer de la version haute qualité vers la version basse qualité du serveur de vidéos. La deuxième règle exprime que si la nouvelle valeur de la bande passante vaut 600KB/S, et que cette valeur est supérieure à l'ancienne (la bande passante est en train d'augmenter), il faut passer de la version basse qualité vers la version haute qualité du serveur de vidéos. Entre les deux seuils 400KB/S et 600KB/S, la configuration de l'application doit rester la même pour éviter des reconfigurations très fréquentes et probablement inutiles.
Lorsque la reconfiguration est lancée, l'une des versions est connectée à la place de l'autre. Le problème le plus délicat reste autour du transfert d'état. En effet, dans notre exemple, un simple transfert d'état n'est pas suffisant. Au moment de la reconfiguration, des clients peuvent être connectés et être en train de jouer des vidéos. Il faut que ces clients prennent en compte instantanément la reconfiguration, et se synchronisent avec la nouvelle version du serveur vidéo (Figure 77).
La difficulté réside dans le fait que la connexion entre le serveur et les clients (navigateurs) n'est pas permanente. Dès qu'un client envoie une requête HTML au serveur, et reçoit une réponse, la connexion est directement rompue. Cependant, dans notre application, il faut trouver une solution qui permet au serveur de connaître les clients connectés à un moment donné, pour pouvoir leur demander de se synchroniser en cas de reconfiguration. Plusieurs solutions sont possibles pour maintenir la connexion entre le serveur et les clients :
Mettre au point une communication "Serveur Push" [HC98] : peut être réalisé en incorporant dans la page HTML, envoyée au client, la directive "multipart/x-mixed-replace". Cette directive permet de garder une connexion permanente avec les clients. Elle indique que tout nouveau bloc de données, envoyé au client, doit remplacer l'ancien. Dans un premier lieu, nous avons adopté cette solution; cependant, les résultats que nous avons obtenus étaient aléatoires, surtout si la page envoyée au client est complexe. Ceci vient probablement du fait que le protocole est juste expérimental (la lettre "x" dans la directive).
Intégrer une applet Java dans la page envoyée au client : le rôle de l'applet se limite à maintenir la connexion avec le serveur. Elle se charge de vérifier périodiquement auprès du serveur s'il faut se synchroniser (si une reconfiguration a eu lieu). C'est cette deuxième solution que nous avons implantée.
Dans tous les cas de figure, le serveur est responsable de gérer l'ensemble des clients connectés. Il doit être capable de reconnaître, par exemple, la vidéo (ou les vidéos) jouée (s) par un client donné, et l'heure à laquelle cette vidéo a commencé à être jouée. Cette dernière information permet de continuer la vidéo au bon point en cas de reconfiguration (Figure 77).
Avant la reconfiguration Après la reconfiguration Figure 77. Remplacement du composant de diffusion vidéo
Il est également possible d'agir manuellement sur l'application pour la reconfigurer. Ceci peut être fait à l'aide de l'interface textuelle de contrôle d'OSGi, présentée par la Figure 68 (section 3). L'interface de contrôle graphique de DYVA peut être aussi utilisée pour lancer les opérations de reconfiguration. Ceci est illustré par la figure suivante :
D'autres scénarios de reconfiguration peuvent également être réalisés dans notre application de portail. Ces scénarios concernent les composants qui gèrent les achats ("Shopping-Vi"), et ceux qui implantent le jeu de mémoire ("Memory-Vi").
7
7 CC
OONNCCLLUUSSIIOONNLe système de reconfiguration que nous avons spécifié et développé dans cette thèse, comporte une partie générale, développée autour d'un modèle d'applications abstrait. Pour l'exploitation de ce système dans le cadre d'un modèle de composants spécifique, une phase de personnalisation est nécessaire. Cette phase permet de compléter le système de reconfiguration et de prendre en compte les spécificités du modèle en question. Nous avons montré, à travers ce chapitre, un exemple de processus de personnalisation. Cet exemple concerne le modèle OSGi. Il illustre comment créer les interfaces de notification et de reconfiguration. Il donne aussi une idée sur la mise en œuvre des plugins de projection et des outils d'instrumentation.
La dernière partie de ce chapitre a présenté une application développée pour valider la personnalisation que nous avons réalisée. Nous avons également montré, à travers un scénario, le fonctionnement de l'auto-reconfiguration et mis en évidence quelques difficultés techniques, rencontrées durant la réalisation.
C
CHAHAPPIITTRREE 88
Chapitre 8 :