Le composant XWootApp

XWootApp

Description générale

Objectifs

L'application XWoot à pour objectif l'ajout d'une fonction de réplication de données par P2P à l'application XWiki, dans un contexte d'édition collaborative. En effet, l'association des deux applications XWoot / XWiki permet de faire évoluer chaque serveur XWiki en un nœud d'un réseau P2P de travail collaboratif. Chaque nœud peut alors synchroniser ses données à travers le réseau, afin de partager un contenu commun répliqué. L'algorithme utilisé (WOOT) garanti la convergence des différents répliquas vers un état identique.

Pour ce faire, XWoot utilise l'interface XML-RPC Swizzle fournie par XWiki, afin d'agir sur les données à répliquer.

Encore au stade de prototype, il est déjà possible de répliquer le contenu des pages, ainsi qu'une partie des métadonnées liées.

L'application se présente sous la forme d'un fichier WAR (Web Archive) contenant une application Web à déployer à l'aide d'un conteneur de Servlet (Ex : Tomcat). Elle doit être configurée par le biais de 2 fichiers de propriétés (par exemple, il faut fournir l'adresse d'accès à l'interface XML-RPC de l'application XWiki à laquelle on veut se connecter).

Architecture par composant

L'application XWoot est basé sur le composant XWootApp, lui même client de plusieurs composants :

• WikiContentManager : composant d'accès au données de l'éditeur Wiki (XWiki)
• WootEngine : composant d'intégration de données linéaire, répliquées dans un contexte d'édition collaborative.
• ClockEngine : composant fournissant un compteur persistant.
• JLibDiff : librairie utilisée pour générer la différence entre deux contenus.
• ThomasRuleEngine : composant d'intégration de métadonnées utilisant la règle du "First Writter Win".
• LPBCast : composant de gestion du réseau P2P (implémente l'algorithme Lightweight Probabilistic broadcast).
• AntiEntropy : composant de gestion de l'anti-entropie.

Le composant XWootApp

Le composant XWootApp intègre l'application Web, permettant de gérer l'application, à travers plusieurs servlets :

• Bootstrap : servlet de démarrage de l'application, charge les propriétés et met en place les différentes instances des composants.
• Synchronize : servlet de gestion de la synchronisation des données entre la vue et le modèle.
• PageManagement : servlet de gestion du choix des pages à synchroniser.
• ReceiveMessage : servlet utilisé par le module LPBCast pour recevoir les messages des voisins.
• GetState : servlet utilisé par le module LPBCast pour charger le modèle interne d'un voisin lors du bootstrap.

Dans la version actuelle du prototype, le composant XWootApp fourni un service de gestion des pages à synchroniser ; à terme, il faudra synchroniser l'ensemble des pages du Wiki, car c'est une condition pour rendre effective la convergence des données répliquée. Ainsi, il est possible d'accéder à une liste des espaces et de leurs pages, permettant de choisir celles que l'on souhaite répliquer.

L'interface Web permet aussi d'ajouter les voisins du nœud, ainsi que de lancer une synchronisation entre le wiki et le modèle de données. A terme, un seul voisin suffira pour le bootstrap et la synchronisation des données se fera soit par demande de l'application Wiki, soit par l'intermédiaire d'un scheduler.

Ces différentes interfaces Web sont donc vouées à disparaitre, pour être remplacées par une gestion avancée des fichiers de propriétés.

La synchronisation des données

L'application XWoot, à travers le composant WootEngine, crée un modèle des données répliquées ; c'est pourquoi, il est nécessaire de garder synchronisées les données de la vue, avec celles du modèle interne au WootEngine. Le modèle interne du WootEngine permet de recevoir les patchs dans un ordre aléatoire, en revanche, il faut modifier la vue en tenant compte de toutes les modifications (locales et distantes) sans écrasement.

Le composant XWootApp fourni donc un service de synchronisation qui va, pour chaque page sélectionnée pour la synchronisation, vérifier si les données n'ont pas été modifiées soit par des utilisateurs locaux de l'interface Wiki, soit par la réception et l'application au modèle de patchs distants.

Le problème de la synchronisation vue/modèle

Lorsque le modèle interne du WootEngine est modifié par l'application de patchs (modifications faites par des utilisateurs sur des applications distantes), le composant XWootApp doit pouvoir mettre à jour les données de la vue (i.e. contenues par l'application XWiki locale) sans écraser d'éventuels modifications (i.e. faites sur la vue) n'ayant pas encore été prises en compte par le WootEngine (i.e. le modèle). Pour ce faire, le composant XWootApp doit garder une copie de l'état de la vue tel qu'il était lors de la dernière synchronisation. Ainsi, lorsque le composant XWootApp veut modifier la vue, il doit vérifier que l'état courant de la vue est bien le même que l'état copié lors de la dernière synchronisation.

La solution proposée n'est d'ailleurs pas parfaite, puisque l'application XWoot étant externe à l'application XWiki, il est impossible de rendre atomique la zone critique de vérification de l'état courant de la vue ; il existe donc un risque mineur de modification de la vue à la suite de la vérification mais avant l'écrasement des données (cette modification ne serait alors pas prise en compte).

La synchronisation des métadonnées

Cette fonction est en cours de développement et n'est pas complètement fonctionnelle.

La solution utilisée pour les métadonnées est fournie par le composant ThomasRuleEngine. L'algorithme implémente la solution du "Last Writter Win", sachant que dans le cas de l'architecture de l'application XWoot, la solution réellement implantée est plutôt un "Last Synchronizer Win" (les métadonnées n'ont d'existence pour le ThomasRuleEngine que lorsqu'elles ont été synchronisées : les métadonnées ne sont décorée par le modèle du ThomasRuleEngine qu'à ce moment là). Ainsi, entre le moment de la dernière synchronisation sur l'ensemble du réseau et l'application du patch en résultant, toute les modifications effectuées sur les vues, mais non synchronisées, sont écrasées.

Entrées / Sorties du composant

Entrées

• L'ensemble des méthodes de gestion des pages à synchoriser (addPageManagement, addAllPageManagement, removeManagedPage, removeAllManagedPage,isPageManaged).
• Le constructeur qui reçoit les instances des composants à utiliser.
• setState : charger un état donné.

Sorties

• doAntiEntropy : effectuer une anti-entropie avec un voisin.
• synchronize : lancer une synchronisation vue/modèle.
• receive : appliquer un patch au modèle.
• getState : récupérer l'état du modèle courant.

Diagramme de classe