Soutenance mémoire
Télécharger le fichier pdf d’un mémoire de fin d’études
Applications coopératives sur le Web
Nous avons effectué une recherche bibliographique dans le but de prendre connaissance de différentes approches, qui proposent d’une manière ou d’une autre, d’étendre les capacités du Web pour qu’il puisse être utilisé en tant qu’outil coopératif. Dans le cadre de cette recherche nous avons identifié plusieurs propositions qui abordent ce problème en fonction de différents points de vue. Nous les avons classées en deux grandes catégories : (i) des systèmes offrant des solutions coopératives spécifiques et (ii) des systèmes offrant des environnements de travail intégrés, et qui permettent à des utilisateurs de synchroniser leur navigation sur le Web. D’autres produits académiques existent également que nous ne développerons pas ici comme Platine [Platine], Isabel [Isabel], VRVS [VRVS].
Solutions spécifiques de navigation coopérative
Parmi les propositions que nous avons analysées nous avons trouvé entre autres des mécanismes de synchronisation de la navigation, des mécanismes d’annotation des pages Web visitées et des mécanismes de création de voisinages virtuels. En fait plusieurs des caractéristiques de ces propositions nous ont servi de source d’inspiration dans la conception et la définition de certains aspects de la proposition que nous développons dans ce mémoire de thèse.
Nous présentons dans ce paragraphe, quelques uns des projets qui on été les plus significatifs en fonction de nos objectifs de recherche, expliquons leurs caractéristiques et fonctionnalités principales et faisons quelques commentaires pour chacun d’entre eux.
CoBrow
Le projet CoBrow [Sidler-97] a pour but de créer de nouvelles formes de coopération sur l’Internet. Les auteurs proposent d’élargir le modèle actuel de fonctionnement du Web en ajoutant le concept de « lieux de rencontre » (meeting places), où des utilisateurs peuvent se rencontrer, partager de l’information et coopérer à des projets communs. L’approche choisie consiste à associer les utilisateurs à un emplacement sur le Web. Cette association s’appuie sur le document en cours de visualisation par un utilisateur dans son navigateur. Différents attributs, tels que l’intérêt, la langue, le temps de présence entre autres peuvent être associés aux utilisateurs. À partir de ces emplacements et de leurs attributs, CoBrow crée des voisinages virtuels, dans lesquels les utilisateurs peuvent avoir conscience de la présence des uns et des autres, et où des relations de collaboration peuvent être crées au moyen de différents outils disponibles.
L’idée générale proposée par ce projet est très intéressante, puisque la formation des voisinages virtuels semble être une bonne approche pour faciliter le « hasard heureux » (serendipity en anglais) et permettre à chaque utilisateur d’obtenir des informations pertinentes en tenant compte des intérêts similaires d’autres utilisateurs.
Nous pensons que la création de voisinages virtuels devrait tenir compte d’autres données que le simple URL visité ou le profil des utilisateurs. Pour qu’un tel voisinage soit plus effectif il faudrait tenir compte de l’information contenue dans les pages visitées, de manière à créer des groupes de travail potentiels à partir de sujets similaires. Évidemment l’implantation d’un tel mécanisme serait beaucoup plus complexe puisqu’il faudrait faire une analyse sémantique du contenu des documents, au moyen par exemple de techniques de l’intelligence artificielle.
À partir du concept de voisinage, il serait également désirable de disposer de facilités pour que des utilisateurs, appartenant au même voisinage, puissent synchroniser leur activité de navigation.
E-CoBrowse
E-CoBrowse [Chong-00] est un cadre de travail extensible de co-navigation. Les auteurs proposent le développement d’un système permettant d’ajouter des extensions multi utilisateurs aux navigateurs Web, principalement MicroSoft® Internet Explorer® et Netscape Navigator®. Ceci comprend des « chatpointers », qui permettent aux utilisateurs d’annoter simultanément la page Web qu’ils visitent.
Trois modes de fonctionnement sont proposés dans cette approche : « leader », « follower » et « standalone ». Le premier mode correspond à l’implémentation d’un maître, le second à l’implémentation d’un esclave, et le troisième à un utilisateur qui n’influence pas le système et qui ne subit aucune influence du système (aucune synchronisation n’est réalisée).
La proposition est par elle-même très intéressante. Cependant, un détail attire notre attention, à savoir qu’il est strictement nécessaire, pour implémenter les extensions proposées, d’utiliser des pages codés en DHTML, ce qui réduit la généralité de la proposition, puisque restent exclues les pages codées en HTML de base et celles codées avec d’autres variantes de ce langage. En fait la proposition va au-delà puisque l’implémentation d’E-CoBrowse nécessite un codage spécifique au navigateur utilisé, ce qui réduit encore la flexibilité de la proposition.
Un détail qui reste encore un peu obscur à la lecture de la documentation disponible est de savoir si la synchronisation de la navigation Web est effective, c’est à dire si suite à une navigation d’un utilisateur « leader », la même ressource est chargée et affichée immédiatement dans les navigateurs des utilisateurs « follower », ou si ces ressources ne sont chargées que périodiquement (la page des « followers » est actualisée sur la base d’une période de temps), comme le laisse entrevoir la documentation.
Let’s Browse
Les auteurs de ce projet [Lieberman-99] partent de l’hypothèse qu’il existe probablement souvent de nombreux utilisateurs dans le monde qui recherchent des informations similaires. À partir de cette hypothèse, ils proposent qu’à un instant donné le système puisse aider à faciliter des rencontres entre personnes partageant des intérêts de navigation similaires. Ils proposent donc la création d’un agent pour assister un groupe d’utilisateurs qui naviguent. Le but de l’agent est de proposer des pages Web aux utilisateurs en fonction de la navigation des utilisateurs ayant des domaines d’intérêt commun.
Ce projet est construit comme une extension de l’agent de navigation Web appelé Letizia. Cet agent effectue une recherche en largeur (« breadht first ») en temps réel de ressources associées à la page courante de l’utilisateur, en filtrant des pages candidates selon un profil appris de l’observation des actions de navigation de l’utilisateur.
Ce projet ressemble au projet CoBrow introduit auparavant et présente une problématique similaire en termes d’implémentation.
PROOF
Ce modèle [Cabri-99] a été proposé par Giacomo Cabri et al. à l’Université de Modena, en Italie. Il consiste en un système qui permet la synchronisation de la navigation sur le Web. Son architecture s’appuie sur l’existence d’un serveur Proxy, qui traite les requêtes des utilisateurs. Du côté utilisateur, nous avons un applet qui permet au navigateur d’un client de rester en communication avec le serveur Proxy, et d’échanger avec lui des messages de contrôle. La synchronisation de la navigation Web est réalisée par modification des ressources rapatriées avant de les envoyer au client.
Deux modes de navigation coopérative sont permis : faiblement couplé et fortement couplé. Dans le mode faiblement couplé, chaque utilisateur navigue de sa propre initiative, mais il peut consulter à tout moment les URLs récemment visités par les autres utilisateurs connectés à la même session. Le mode fortement couplé s’appuie sur un schéma maître esclave, de telle façon que dans les navigateurs de tous les esclaves sont présentées les mêmes pages Web que celles visitées par le maître. Toute navigation indépendante de la part des esclaves reste interdite tout au long d’une session.
Les utilisateurs peuvent enrichir leurs interactions et communiquer entre eux par l’utilisation de deux outils intégrés à la plate-forme : un système de messagerie instantanée (chat) et un tableau blanc. D’autres outils peuvent être intégrés à la plate-forme de base, qui est programmée en Java.
Cette proposition nous a semblé dès le début de nos travaux très intéressante et a été une de nos sources d’inspiration principales. Deux points nous paraissent cependant un peu contraignants concernant le fonctionnement de cette plate-forme. Le premier est que le mécanisme de synchronisation proposé est très rigide, puisque, une fois qu’un maître a été défini, il reste maître tout au long de la durée de la session. Le second est que l’architecture proposée est très centralisée, ce qui peut poser des problèmes de passage à l’échelle.
À partir de ce modèle de navigation coopérative sur le Web, M. Cabri et son équipe ont proposé toute une série d’expériences s’appuyant sur cette technologie, démontrant ainsi tout son intérêt.
WABX
Ce projet [WABX] a été proposé par l’EISTI (École Internationale des Sciences du Traitement de l’Information) à Cergy-Pontoise (France). Il consiste en la création d’un ensemble d’outils pour la coopération à distance en ligne, dont un outil de navigation coopérative sur le Web au cœur de cette proposition. Apparemment faute de financement, ce projet a été arrêté il y a environ 2 ans. Peu d’informations restent disponibles aujourd’hui et plusieurs liens disponibles auparavant sur le Web ne le sont plus.
Au niveau de la navigation coopérative, les concepteurs de WABX proposent un outil qui permet la synchronisation de la navigation Web à un niveau très fin, incluant, par exemple, la synchronisation de la barre de défilement du navigateur. Dans ce but, l’implémentation s’appuie sur l’utilisation d’un Plug-in et d’applets signés, ce qui, à priori, pose un certain nombre de problèmes.
En ce qui concerne l’utilisation d’un Plug-in, le principal inconvénient est que son implantation dépend de l’outil logiciel de navigation que l’on l’utilise. Ainsi, par exemple, il devrait exister un Plug-in différent pour chaque type de navigateur présent sur le marché, et pour chaque version de chacun d’eux, ce qui rend difficile une utilisation à grande échelle d’une telle plate-forme.
Par ailleurs, l’utilisation d’applets signés peut représenter des risques de sécurité au niveau des utilisateurs, et pour cette raison tous les utilisateurs ne sont pas prêts à autoriser leur exécution dans leurs propres navigateurs. Habituellement les applets sont exécutés dans un environnement sûr d’exécution puisque aucun accès aux ressources de la machine hôte ne leur est accessible. Il existe toutefois la possibilité d’autoriser un applet à avoir un accès illimité aux ressources de la machine, et qui consiste à la signer. Le problème est qu’un applet signé dispose de tous les droits, ce qui représente un risque potentiel pour les utilisateurs.
Nous pensons également que le niveau de synchronisation proposé par WABX n’est pas réellement adapté à un système de navigation coopérative. Il nous paraît ainsi plus intéressant de synchroniser l’accès à des pages que de synchroniser la présentation de chacune de ces pages par un navigateur, ce dernier type de fonctionnalité pouvant être proposé, avec certaines contraintes il est vrai, par un système de partage d’applications.
WebSplitter
Ce modèle [Han-00] offre un cadre de travail XML unifié qui offre des moyens pour faire de la navigation Web multi-dispositifs et multi-utilisateurs. La principale contribution de cette proposition est la capacité de créer, à la volée, des vues partielles et personnalisées de la même page Web en fonction des droits d’accès des utilisateurs et des capacités techniques de l’équipement dont les utilisateurs disposent.
Du côté client, il existe une un applet dans le navigateur de chaque utilisateur, ce qui permet à ce dernier de garder une ligne de communication avec le serveur et d’échanger avec lui des messages de contrôle.
Chaque page Web est accompagnée d’un fichier de politiques (« policy file »), qui contient des règles permettant de mettre en correspondance des balises d’hypertexte à des groupes de privilèges. Un seul fichier de politiques peut définir plusieurs groupes de privilèges pour une seule page Web. Un groupe de privilège peut être conceptualisé comme étant un rôle, de telle façon, que lorsqu’un utilisateur s’identifie comme appartenant à un certain groupe de privilèges, il acquiert les droits correspondants.
Un service de découverte a été implémenté au niveau « middleware », permettant à WebSplitter de découvrir les dispositifs que les utilisateurs ont à leur disposition, de manière à adapter les présentations des pages Web. Ainsi, par exemple, un utilisateur ayant accès à une page Web par l’intermédiaire d’un PDA recevra une version allégée de cette ressource.
Cette proposition présente selon nous deux intérêts. Le premier intérêt est le concept de groupe de privilèges, qui permet de définir des droits d’accès et des besoins d’adaptabilité, au niveau de groupes d’utilisateurs et non pas d’utilisateurs individuels. Ce concept fait partie des définitions de RBAC (Role-Based Access Control – contrôle d’accès s’appuyant sur des rôles) [Wang-99].
Le second intérêt est l’adaptation des présentations, ce qui offre une grande flexibilité garantissant que jamais un utilisateur ne recevra une page Web que son dispositif d’accès ne pourra présenter. Cette adaptabilité devrait également tenir compte de la bande passante de la liaison d’accès de l’utilisateur (liaison Ethernet haut débit, liaison WiFi, liaison GPRS, etc.).
Un inconvénient de cette proposition est que les politiques sont définies au niveau d’un fichier associée au fichier principal de la ressource, ce qui introduit un certain degré de complexité au niveau de la spécification des politiques d’accès et d’adaptabilité.
Wiki Wiki Web
Ce projet [WikiWikiWeb] met en place un système coopératif pour créer des pages sur le Web. Cela signifie que n’importe quel utilisateur enregistré peut, depuis n’importe quel endroit du monde, et à n’importe quel moment, ajouter des nouvelles pages Web au système, et il peut également, s’il dispose des privilèges nécessaires, modifier et éliminer des pages existantes. Ce projet ouvre des possibilités très intéressantes puisqu’il permet de créer de manière coopérative des bases d’information qui sont mis à jour régulièrement et qui sont consultables sur le Web. Ce projet a donné naissance à la WikiPédia [WikiPedia] qui est une encyclopédie créée dynamiquement par ses propres utilisateurs.
Environnements Web intégrés de travail coopératif
Nous présentons maintenant des systèmes proposant des solutions intégrées pour gérer la coopération entre plusieurs utilisateurs raccordés sur le Web. Les deux caractéristiques communes de ces systèmes sont : (i) ils sont constitués de plusieurs composants de communication permettant aux utilisateurs d’interagir entre eux, (ii) ils sont accessibles depuis un simple navigateur Web.
Parmi les systèmes les plus représentatifs que nous avons identifiés dans cette catégorie nous pouvons citer NetDive, Microsoft Office Live Meeting (autrefois connu sous le nom de PlaceWare) et WebEx, qui sont tous des produits commerciaux.
NetDIVE
Ce système [NetDive] est un environnement intégré de collaboration, destiné à des activités commerciales, qui est composé de quatre applications principales :
• WeMeeting : une messagerie instantanée permettant à des utilisateurs de rester en contact les uns avec les autres, tout en gardant conscience de leur présence (notion exprimée par le terme awareness en anglais).
• eAuditorium : un outil permettant d’établir des facilités de téléconférence via le Web avec jusqu’à 3000 participants. Il permet l’organisation de réunions s’appuyant sur le Web, les utilisateurs étant catégorisés en modérateurs, audience et orateurs en fonction de leur nom et mot de passe. Les échanges entre participants peuvent être réalisés en VoIP, par des messages textuels, par un outil de partage d’applications (navigation Web synchronisée ou présentation synchronisée de transparents PowerPoint) et un outil de tableau blanc partagé. Il est également possible de mettre en place des votes et des enchères.
• CallSite : un système s’appuyant sur le Web capable de permettre à des utilisateurs de communiquer entre eux tout en visitant un site Web. Le principe de fonctionnement est simple : un utilisateur ayant besoin de contacter quelqu’un de l’entreprise dont la page Web est actuellement affichée dans son navigateur, peut cliquer sur un bouton particulier, action par laquelle il entre en contact direct avec la personne désirée.
• SiteSticky : un serveur de chat capable de gérer des communications vocales, des discussions immersives par l’utilisation d’avatars, etc.
Toutes ces applications ont certains éléments en commun, et d’autres sont spécifiques à la solution du problème posé. Dans le but de donner un aperçu général des capacités techniques de ces applications, nous présentons, dans le tableau de la Figure 1, une synthèse des principales caractéristiques de chacun de ces éléments.
Positionnement de notre proposition
Parmi les différentes solutions que nous venons d’analyser nous avons identifié différentes approches permettant, d’une manière ou d’une autre, de gérer des interactions entre utilisateurs navigant sur le Web. Le concept de synchronisation de la navigation Web de plusieurs utilisateurs nous semble cependant avoir été traité d’une manière plutôt limitée et trop rigide, s’appuyant en général uniquement sur un schéma maître-esclave.
Dans les chapitres suivants où nous allons développer notre approche selon différents aspects comprenant la formalisation du modèle de synchronisation, la définition de l’architecture, l’implémentation et l’évaluation de l’outil réalise CoLab, nous proposons une approche permettant de créer et de supprimer de manière complètement dynamique et répartie des relations de synchronisation entre utilisateurs appartenant à une même session de navigation coopérative.
Avant d’aborder ces chapitres, nous allons rappeler dans le paragraphe suivant le fonctionnement d’un Proxy Web, ainsi que les briques de base du Web, à savoir le langage HTML et le protocole HTTP.
HTML et HTTP : les briques de construction du Web
Le Web, également connu sous l’acronyme WWW (World Wide Web – toile d’araignée mondiale), est un moyen de communication fonctionnant selon le paradigme client-serveur. D’un côté, nous disposons de machines serveurs, qui exécutent un logiciel serveur capable d’accepter des requêtes et, éventuellement, de les satisfaire grâce à un ensemble de ressources, principalement des pages Web, disponibles localement au niveau de ces serveurs. D’un autre côté, nous disposons de clients, dans lesquels a été installé un logiciel (appelé en général un navigateur) capable d’envoyer des requêtes vers un serveur, et de présenter sur un écran l’information obtenue en réponse à une requête. Cette idée, aujourd’hui tout à fait classique, est illustrée dans la Figure 4.
Les paramètres de destination des fenêtres de navigation
Habituellement lorsqu’un utilisateur clique sur un hyperlien, la ressource rapatriée est présentée dans la même fenêtre du navigateur ou, le cas échéant, dans le même cadre. Cependant il existe la possibilité de spécifier un comportement différent au moyen d’un attribut « TARGET » présent dans les éléments <A> et <FORM>. Les valeurs possibles acceptées par cet attribut sont les suivantes :
• _blank : pour ouvrir la ressource indiquée dans une nouvelle fenêtre du navigateur.
• _parent : pour ouvrir la ressource indiquée dans le cadre de niveau immédiatement supérieur de celui où l’hyperlien est spécifié; cette valeur est normalement utilisée dans le cas de cadres imbriqués à plusieurs niveaux.
• _self : pour ouvrir la ressource indiquée exactement dans la même fenêtre ou cadre où se trouve l’hyperlien, ce qui équivalent à ne pas utiliser l’attribut « TARGET ».
• _top : pour ouvrir la ressource indiquée dans le cadre de plus haut niveau, c’est-à-dire au niveau de la fenêtre principale de navigation, éliminant ainsi toute structure de cadre existant.
• nom-de-cadre : pour ouvrir la ressource dans le cadre spécifié par « nom-de-cadre ».
Le protocole HTTP
Le protocole de communication HTTP (Hyper Text Transfer Protocol) [HTTP] est le protocole utilisé par définition pour le rapatriement de ressources dans le Web. Un client, tel qu’un navigateur Web, envoie une requête à un serveur qui retourne une réponse terminant ainsi la transaction. La version actuelle du protocole, HTTP 1.1, est décrite dans le RFC 2616 [RFC2616], mais la version 1.0, décrite dans la RFC 1945 [RFC1945] est encore très utilisée notamment pour des serveurs Proxy. Ce protocole s’appuie sur des connexions TCP et le serveur est associé par défaut au port 80 (d’autres ports libres peuvent cependant être utilisés). Une caractéristique importante de HTTP est qu’il est un protocole en mode texte, et donc lisible par un humain, et facile à déboguer.
Le mode de fonctionnement général du protocole HTTP
Le protocole HTTP est un protocole sans état, ce qui signifie que lorsqu’un utilisateur envoie une requête à un serveur, et que ce serveur a satisfait cette requête, ou a le cas échéant retourné un message d’erreur, la connexion est terminée et il ne reste plus aucune trace de cette opération lors de l’envoi d’une prochaine requête.
Dans la définition de la version 1.0, il est établi que, par défaut, pour chaque ressource principale (par exemple, chaque page Web), ainsi que pour chaque composant inclus dans une ressource principale (par exemple une image), il faut ouvrir une connexion TCP spécifique. Ainsi, dans le cas d’une page Web contenant quatre cadres et cinq images par cadre, le client devrait ouvrir 21 connexions TCP, ce qui crée une surcharge évidente liée à la création et la fermeture de ces connexions TCP et peut ainsi provoquer un ralentissement de la transmission des ressources associées à cette page Web. Nous présentons dans la Figure 21 une illustration de ce mode de fonctionnement.
|
Table des matières
Chapitre I Introduction générale
I.1. Contexte général
I.2. Problématique abordée
I.3. Principales contributions de la thèse
I.4. Plan de thèse
Chapitre II État de l’art
II.1. Introduction
II.2. Applications coopératives sur le Web
II.2.1. Solutions spécifiques de navigation coopérative
II.2.1.1. CoBrow
II.2.1.2. E-CoBrowse
II.2.1.3. Let’s Browse
II.2.1.4. PROOF
II.2.1.5. WABX
II.2.1.6. WebSplitter
II.2.1.7. Wiki Wiki Web
II.2.2. Environnements Web intégrés de travail coopératif
II.2.2.1. NetDIVE
II.2.2.2. Microsoft Office Live Meeting (autrefois connu comme PlaceWare)
II.2.2.3. WebEx
II.2.3. Positionnement de notre proposition
II.3. HTML et HTTP : les briques de construction du Web
II.3.1. Le langage HTML
II.3.1.1. Les URL
II.3.1.2. Les hyperliens
II.3.1.3. Les formulaires
II.3.1.4. Les cadres
II.3.1.5. Les paramètres de destination des fenêtres de navigation
II.3.2. Le protocole HTTP
II.3.2.1. Le mode de fonctionnement général du protocole HTTP
II.3.2.2. Les en-têtes HTTP
II.3.2.3. Les types MIME
II.3.2.4. Les requêtes HTTP
II.3.2.4.1. Les méthodes de requête
II.3.2.5. Les réponses HTTP
Chapitre III Spécification et vérification formelle du modèle de synchronisation
III.1. Introduction
III.2. Le modèle de synchronisation de base
III.2.1. Le SDT
III.2.2. Création de relations de synchronisation
III.2.3. Suppression de relations de synchronisation
III.2.4. Synchronisation de la navigation
III.3. Formalisation du modèle de synchronisation de base
III.3.1. Formalisation par des automates étendus
III.3.2. Formalisation par des réseaux de Petri
III.3.2.1. Modélisation des SDTs
III.3.2.2. Modélisation de la création de relations de synchronisation
III.3.2.3. Modélisation de la suppression de relations de synchronisation
III.3.2.4. Modélisation du processus de navigation
III.3.2.5. Tout ensemble
III.4. Vérification formelle du modèle de synchronisation de base
III.4.1. Modèle complet avec deux utilisateurs
III.4.2. Modèle complet avec trois utilisateurs
III.4.3. Modèles partiels avec trois, quatre et cinq utilisateurs
III.4.3.1. Scénario 1 : trois utilisateurs asynchrones, « Follow_2_1 », « Leave_2_1 » et « Browse »
III.4.3.2. Scénario 2 : trois utilisateurs appartenant à un même SDT, « Leave_2_1 » et « Browse »
III.4.3.3. Scénario 3 : quatre utilisateurs appartenant à un même SDT, « Leave_2_1 » et « Browse »
III.4.3.4. Scénario 4: cinq utilisateurs appartenant à deux SDTs, « Follow_2_1 » et « Browse »
III.5. Le modèle de synchronisation étendu
III.5.1. L’action de synchronisation « I_Spy_You »
III.5.2. L’action de synchronisation « You_Join_Me »
III.5.3. Formalisation du modèle de synchronisation étendu
III.6. Conclusion
Chapitre IV Architecture du système de navigation coopérative
IV.1. Introduction
IV.2. Vue générale du système de navigation coopérative
IV.3. Modélisation dans le profil UML/SDL
IV.3.1. Introduction au profil UML/SDL
IV.3.2. Modélisation et validation de l’architecture du système de navigation coopérative
IV.4. Modélisation en UML de l’architecture du système de navigation coopérative
IV.4.1. Cas d’utilisation de CoLab
IV.4.2. Définition des scénarios d’utilisation de CoLab
IV.4.2.1. Entrée dans une session de navigation coopérative
IV.4.2.2. Sortie d’une session de navigation coopérative
IV.4.2.3. Création de relations de synchronisation
IV.4.2.4. Suppression de relations de synchronisation
IV.4.2.5. Navigation sur le Web
IV.4.3. Diagramme de classes de CoLab
IV.4.3.1. La classe System
IV.4.3.2. La classe Dispatcher
IV.4.3.3. La classe Session
IV.4.3.4. La classe Broker
IV.4.3.5. La classe SessionMgr
IV.4.3.6. La classe SynchronizationMod
IV.4.3.7. La classe BrowsingMgr
IV.4.3.8. Les modules RetrievalMod, CacheMod et de TranslationMod
IV.4.3.9. La classe UserApplet
IV.5. Validation de la modélisation de l’architecture
IV.5.1. Machines à états décrivant le comportement des classes
IV.5.1.1. L’action « Login »
IV.5.1.2. L’action « I_Follow_You »
IV.5.1.3. L’action « Browse »
IV.5.2. Comparaison des scénarios engendrés par Tau G2 à ceux initialement proposés
IV.6. Conclusion
Chapitre V Implémentation et déploiement de CoLab
V.1. Introduction
V.2. L’implémentation de CoLab
V.2.1. Le processus de traduction des ressources
V.2.1.1. Le traitement des hyperliens
V.2.1.1.1. Les hyperliens classiques
V.2.1.1.2. Les hyperliens vers des points d’ancrage à l’intérieur d’une page Web
V.2.1.1.3. Autres cas de traduction
V.2.1.2. Le traitement des formulaires
V.2.1.3. Le traitement des cadres
V.2.1.4. Le traitement des en-têtes HTTP
V.2.1.4.1. Les en-têtes de requête
V.2.1.4.2. Les en-têtes de réponse
V.2.2. Le protocole de synchronisation des utilisateurs
V.2.2.1. Gestion de la concurrence des actions de synchronisation
V.2.3. Fonctionnement du serveur Proxy
V.2.3.1. Le fichier de configuration automatique du Proxy
V.2.3.2. Le fichier de configuration de session
V.2.4. L’accès à une session de navigation coopérative
V.2.4.1. La Configuration du navigateur
V.2.4.2. Sélection et entrée dans une session de navigation coopérative
V.2.4.3. L’interface utilisateur de CoLab
V.2.4.4. Synchronisation des utilisateurs
V.3. Evaluation des performances de CoLab
V.3.1. Evaluation du coût de la synchronisation
V.3.2. Mesures réalisées sur CoLab
V.4. Mise en oeuvre de CoLab en tant que service Web
V.5. Evolution vers une architecture répartie comprenant plusieurs serveurs Proxy
V.6. Conclusion
Chapitre VI Conclusion générale
Références bibliographiques
Télécharger le rapport complet
