Rapport de Stage dans l équipe ECOO (LORIA) Mise en œuvre d un Wikiwikiweb basé sur l algorithme de réplication optimiste WOOT

Université NANCY 2 IUT Nancy Charlemagne Département INFORMATIQUE Nabil HACHICHA Licence Professionnelle Internet Rapport de Stage dans l équipe ECOO (LORIA) Mise en œuvre d un Wikiwikiweb basé sur l algorithme de réplication optimiste WOOT Tuteur : M. Pascal MOLLI Parrain : M. Gérôme CANALS Du 10 avril au 31 Juillet 2006 Prolongation jusqu au 1 Septembre Année Universitaire 2005 / 2006

TABLE DES MATIERES Liste des illustrations... ii Remerciements... iv Glossaire...v Introduction...1 Chapitre I : Environnement...2 1.1 Le LORIA...3 1.2 L'équipe ECOO...9 Chapitre II :...12 2.1 Réplication de données...13 2.2 WithOut Operational Transformation...15 2.3 L évolution de WOOT...24 2.4 Stockage différentiel (JLibDiff)...25 Chapitre III :...28 3.1 Le système de réplication...29 3.2 La conception du WOOKI...36 3.3 Architecture de l application...50 Conclusion...80 Bibliographie...81 Index...82 i

Liste des illustrations Numéro Page 1. Organigramme du LORIA...3 2. Exemple de relation de dépendance précédence...15 3. Scénario d insertion entre trois sites...22 4. Diagramme de Hasse du scénario...23 5. Scénario de synchronisation entre deux sites...31 6. Use-case...37 7. Use case (Ajouter un nouveau voisin)...38 8. Diagramme de séquence (ajouter un nouveau voisin)...39 9. Use case supprimer un voisin...40 10. Diagramme de séquence, supprimer un voisin...41 11. Use cas consulter une page...42 12. Diagramme de séquence chercher une page...42 13. Use case Edition d une page...43 14. Diagramme de séquence édition d une page...43 15. Use case créer une page...44 16. Diagramme de séquence créer une page...44 17. Use case synchronisation...45 18. Diagramme de classes...46 19. Profiler de l éditeur NetBeans...48 20. Profiler Utilisé sous NetBeans...49 21. Les différents packages de WOOKI...52 22. Package algorithm...53 23. Package WOOT...55 24. Package Op...56 25. Package Clock...57 26. Package Core...58 27. Package Neighbors...61 28. Package test...63 29. Package log...65 ii

30. Package Editor...66 31. Package webapp...67 32. Package HttpUnitTests...68 33. Package Wiki...69 34. Package Servlets (partie 1)...71 35. Package Servlets (partie 2)...75 36. Package Servlets (partie 3)...78 iii

REMERCIEMENTS Tout d abord, je tiens à remercier M. Pascal MOLLI, pour m avoir accueilli dans son équipe de recherche et de m avoir guidé dans mon travail tout au long du stage. Je remercie Messieurs Claude GODART, Pascal URSO, Hala SKAF, François CHAROY, ainsi que tous les autres membres de l'équipe ECOO du Loria pour leur accueil chaleureux. Je souhaite également remercier M. Florent Jouille, ingénieur associé à l équipe, pour le temps qu il m a consacré ainsi que pour les explications qui m ont permis d avancer dans mon travail. Enfin, je remercie Monsieur Gérôme CANALS, mon parrain de stage pour s être assuré du bon déroulement du stage ainsi que pour ses conseils tout au long de ces cinq mois. A l âme de mon cher ami Hacen SIDHOUM A mes parents iv

GLOSSAIRE TTF. Tombstones Transformation Functions, algorithme de réplication qui gère les opération undo, redo. Profiling. Le "profiling" est un moyen de déterminer le temps consommé par chacune des parties d un programme. Pour réaliser ces mesures de manière automatique, on peut ajouter une option de compilation ou bien utiliser un logiciel dédié à ça. Refactoring. La notion de refactoring (raffinement) consiste en une réécriture d'un programme en vue de le rendre plus lisible, extensible et facile à maintenir. Il ne s'agit pas d'une modification fonctionnelle : le programme doit se comporter à l'identique avant et après raffinement. Use case. Cas d'utilisation en modélisation UML. Usenet. Également connu sous le nom Netnews, est un système de forums de discussions qui a été inventé en 1979 pour fonctionner sur des ordinateurs reliés par UUCP. Il a été rapidement adapté à Internet où il reste aujourd'hui en usage. Wikiwikiweb. WikiWikiWeb est le premier wiki, inventé par Ward Cunningham en 1995. WikiWikiWeb n'est pas un site Web complet, mais seulement une fonctionnalité ajoutée aux Portland Pattern Repository, une section du site de Cunningham & Cunningham, Inc. Ward Cunningham a créé cette fonctionnalité pour faciliter l'échange d'informations entre programmeurs. Le terme «wiki», aujourd'hui utilisé pour décrire la technologie mise en œuvre par WikiWikiWeb, vient du nom de ce premier site. Il arrive que le terme «WikiWikiWeb» soit utilisé de manière générique comme synonyme de «wiki». groupware. Le groupware est l ensemble des technologies et des méthodes de travail associées qui, par l intermédiaire de la communication électronique, permettent le partage de l information sur un support numérique à un groupe engagé dans un travail collaboratif et/ou coopératif. JOnAS. Java Open Application Server est un serveur d'application réparti Java OpenSource. Plus précisement c'est un container EJB (Entreprise Java Bean, composant Java réutilisable) qui supporte les normes de configuration, de transactions, et de messagarie applicatif les plus modernes. Il est possible d'utiliser JOnAS avec RMI, JEREMIE ou CORBA.. v

INTRODUCTION Dans le cadre de notre Licence Professionnelle Réseaux et Télécommunications, mention «Concepteur-Intégrateur de systèmes Internet/Intranet», nous avons effectué un stage de fin de formation au LORIA (Laboratoire Lorrain de Recherche en Informatique et ses Applications) ; un laboratoire de recherche se situant sur le campus scientifique de Nancy. Ce stage s est étalé du 4 avril au 1 Septembre 2006 en vue de valider les compétences acquises au cours de la licence. Cette formation professionnelle étant un diplôme de fin d'étude, ce stage a eu aussi pour but de faire une transition vers le monde du travail. Ce rapport présente le stage que nous avons effectué dans l équipe de recherche ECOO. Notre sujet de stage concerne la mise en œuvre d un Wikiwikiweb basé sur un algorithme (WOOT) développé par l équipe ECOO. En effet, l équipe imaginait qu un Wikiwikiweb pourrait être déployé non plus sur une machine centrale mais sur un réseau de type USENET. Cette architecture a de nombreux avantages : la charge peut être distribuée sur le réseau, la panne d un serveur n interrompt pas le service, et enfin, les frais de fonctionnement peuvent être distribués entre les différents hébergeurs. L objectif du projet baptisé «WOOKI» est donc d implanter WOOT pour répliquer un Wikiwikiweb sur un réseau P2P. Ce rapport est organisé comme suit : nous allons commencer par une présentation du laboratoire et de notre environnement de travail. Le deuxième chapitre explique le contexte général et comment donne-il la motivation pour ce travail. Le troisième chapitre est consacré à l étude et l implémentation de l algorithme WOOT au sein du projet WOOKI. Comme prolongement de cette partie, nous allons voir l architecture ainsi que le déploiement et l installation de l application, avant de conclure. 1

C h a p i t r e 1 Dans cette partie, nous présenterons tout ce qui est en rapport avec le laboratoire dans lequel nous avons effectué notre stage. Nous définirons tout d abord le LORIA, puis l équipe de recherche où nous avons travaillé. 2

1.1 Le LORIA 1.1.1 Historique Le Laboratoire Lorrain de Recherche en Informatique et ses Applications (LORIA) est une unité mixte de recherche (UMR 7503) commune au CNRS (Centre National de la Recherche Scientifique), à l'inria (Institut National de Recherche en Informatique et en Automatique), à l'inpl (Institut National Polytechnique de Lorraine), et aux universités Henri Poincaré, Nancy 1 et Nancy 2. Cette unité, dont la création a été officialisée le 19 décembre 1997 par la signature du contrat quadriennal avec le Ministère de l'éducation Nationale, de la Recherche et de la Technologie et par une convention entre les cinq partenaires, succède ainsi au Centre de Recherche en Informatique de Nancy (CRIN), et aux équipes communes entre celui-ci et l'unité de Recherche INRIA de Lorraine. 1.1.2 Organisation du LORIA Figure 1.1 organigramme du LORIA 3

Depuis le 1er janvier 2001, c'est Hélène KIRCHNER qui dirige le LORIA. Actuellement plus de quatre cents cinquante personnes travaillent dans le laboratoire. Ces personnels sont répartis en 25 équipes de recherche et 9 services d'aide à la recherche. Chaque équipe rassemble des chercheurs, des doctorants et des assistants techniques ou administratifs, pour la réalisation d'un projet de recherche. Cinq instances ont été mises en place pour assister le directeur du laboratoire, garantir la cohérence de la politique scientifique et le bon fonctionnement au quotidien : L'Équipe de Direction : composée de plusieurs membres du laboratoire. Elle assiste la Directrice dans ses fonctions. Le Comité de Gestion : composé des chefs de service. Il assiste le directeur dans le fonctionnement journalier du LORIA. Le Comité des Projets : il conseille le Directeur sur la politique scientifique du LORIA, participe à l'évaluation des projets/équipes, et instruit les restructurations nécessaires Le Conseil du LORIA : il émet des avis sur la politique scientifique mise en œuvre par le Comité des Projets. Sa composition est fixée par les statuts d'umr. Le Conseil des Orientations Scientifiques : composé de représentants des équipes de recherche. Il conseille la Direction dans la gestion scientifique du laboratoire. 1.1.3 Ressources et partenariats 1.1.3.1 Etablissements associés 4

LORIA est une "Unité Mixte de Recherche" (UMR 7503) associant les personnels et les moyens des cinq établissements suivants : CNRS : Centre National de la Recherche Scientifique INPL : Institut National Polytechnique de Lorraine INRIA : Institut National de Recherche en Informatique et en Automatique UHP : Université Henri Poincaré, Nancy 1 Nancy 2 : Université Nancy 2 1.1.3.2 Personnels LORIA regroupe plus de 300 personnes dont : Chercheurs permanents : 109 Thésards : 94 ITA : 61 Post-Doc, ingénieurs experts, membres associés : 53 Les chiffres ci-dessus ne comprennent pas les projets Inria Messins et de l'iecn. Ces personnels se répartissent ainsi dans les établissements de rattachement : INRIA : 165 CNRS : 43 5

UHP : 64,5 Nancy 2 : 40 INPL : 24 Divers : 73 1.1.3 Les thématiques de Recherche Dans le secteur des sciences et technologies de l'information et de la communication, le LORIA possède, à travers dix neuf équipes de recherche, cent cinquante chercheurs et une centaine de doctorants, des compétences reconnues dans des secteurs en pleine évolution et porteurs de développement économique potentiel. Les activités de ces équipes sont centrées autour de cinq thématiques principales "transversales" sur lesquelles elles développent des recherches fondamentales et appliquées. Bien entendu, les équipes ont des activités dans plusieurs de ces thématiques. Calculs, réseaux et graphismes à hautes performances Télé-opérations et assistants intelligents Ingénierie des langues, du document et de l'information scientifique et technique Qualité et sûreté des logiciels et systèmes informatiques Bio informatique et applications à la génomique 1.1.4 Valorisation et transfert Le LORIA développe de nombreuses relations industrielles (plus de 200 contrats en cours fin 1999) et a une importante activité de diffusion de logiciels. Six logiciels et une marque ont été déposés en 1998. Fort de près de 6

90 enseignants-chercheurs, le LORIA participe activement à la formation universitaire dans les domaines des sciences et nouvelles technologies. Conscient de la nécessité d'être un élément moteur du contexte socioéconomique régional, le LORIA a décidé de créer le LoriaTech en janvier 1999, club des partenaires du LORIA, qui a pour objectifs : De donner accès plus rapidement aux informations sur les évolutions de la recherche et du secteur ; c'est-à-dire améliorer la veille technologique des entreprises. En particulier, les membres du LoriaTech ont un accès privilégié au centre de documentation du LORIA et de l'inria-lorraine. De monter des partenariats divers. Citons en particulier : 1. dans le cadre des établissements universitaires (ESIAL, ESSTIN, écoles d'ingénieurs de l'inpl, IUT Informatique de Nancy2, IUP-Miage de Nancy), la possibilité de stages de projets industriels. 2. dans le contexte du LORIA, les sujets DRT (Diplôme de Recherche Technologique), des conventions CIFRE. Offrir la possibilité de partenariat LORIA-entreprises en réponse à des appels d'offre français ou européens. Un Espace-transfert a été également créé fin 1999 à proximité du LORIA. Après 3 créations d'entreprises début 2000, 3 autres projets sont en cours de montage. 1.1.6 Le service et le matériel informatique Le LORIA dispose d un parc informatique très important. Celui-ci est géré par le service des «Moyens Informatiques» qui se charge de l installation, de 7

la maintenance et de la gestion des outils informatiques et logiciels. C est à ce service qu il faut s adresser en cas de problème avec un logiciel ou un poste de travail. Chaque bureau du LORIA est équipé de plusieurs stations de travail. Des ordinateurs portables sont également mis à la disposition des employés. Chaque ordinateur est relié au réseau interne du LORIA et dispose d un accès Internet à très haut débit. Ces ordinateurs sont équipés de Windows et aussi de Linux dans certains cas. Des salles machines sont également disponibles en libre accès. De plus, un ensemble d'imprimantes, dont trois imprimantes couleur, vingt-deux imprimantes laser noir et blanc mis à la disposition des utilisateurs, est réparti dans tout le bâtiment. Des scanners (1 par salle console), ainsi que du matériel permettant de faire de l'archivage, sont aussi accessible aux utilisateurs. Une machine de type PC a été mise à notre disposition. Elle est équipée d un processeur rapide (Pentium 4) et de 512 de RAM. Linux (la distribution Ubuntu) est le système d exploitation utilisé. Le projet ne doit utiliser que du code libre en vue de sa diffusion sous licence libre. Par conséquent, la plupart des logiciels utilisés sont issues du monde libre, à coté de ça, nous utilisons comme outils de développement l éditeur NetBeans ainsi qu Eclipse. De plus une plateforme nommé «LibreSoucre» nous accompagnait toute au long du stage. Il s agit d une plate-forme collaborative de seconde génération dédiée au développement logiciel et à l'hébergement de communautés. LibreSource rassemble les fonctionnalités que l'on trouve à la fois dans les plate-formes de développement, telles que les logiciels de forge ou les plates-formes de groupware. Entièrement basé sur la technologie J2EE, un design modulaire utilise la plupart des services offerts par le serveur d'application d'objectweb JOnAS. LibreSource est adapté à des applications professionnelles. 8

1.2 L'équipe ECOO 1.2.1 Motivations L'objectif du projet ECOO est de concevoir et réaliser des services pour l'hébergement d'équipes distribuées et d'entreprises virtuelles sur le Web. Cette recherche s'intéresse plus particulièrement aux applications multisynchrones créatives (co-conception, co-ingénierie, édition coopérative...) distribuées sur Internet. 1.2.2 Champs de recherche Le projet ECOO s'intéresse au développement de services pour l'hébergement d'équipes et d'entreprises distribuées (ou virtuelles) sur Internet. Les services considérés incluent des services de partage d'objets, de communication, de gestion de tâches, de maintien d'une conscience de groupe, d'aide à la prise de décisions. L'équipe s'intéresse plus particulièrement aux applications de co-conception et/ou de co-ingénierie pour des domaines variés (Génie Logiciel, Architecture-Génie Civil, Formation-Apprentissage...). L'approche ECOO se caractérise par le fort accent mis sur l'aide à la coordination d'une équipe distribuée, problème crucial du fait de la perte d'unité de lieu liée à la distribution. La recherche s'organise autour de deux axes principaux: La coordination explicite fondée sur l'hypothèse qu'il est possible de formaliser les procédés de travail et de les contrôler sur le terrain. La coordination implicite basée sur l'idée que si les partenaires reçoivent au bon moment la bonne information sur ce que font les autres, cette information va générer de la communication qui conduira à l'auto coordination de l'équipe. 9

1.2.3 Membres Responsable scientifique : Claude Godart, Professeur à l'université Henri Poincaré Nancy 1, ESSTIN. Responsable permanent : Pascal Molli, Maître de Conférences à l'université Henri Poincaré Nancy 1. Assistante de projet : Antoinette Courrier Personnel Universitaire : 1. Khalid Benali, Maître de Conférences à l'université Nancy 2 2. Nacer Boudjlida, Professeur à l'université Henri Poincaré Nancy 1 3. Gérôme Canals, Maître de Conférences à l'université Nancy 2 4. François Charoy, Maître de Conférences à l'université Nancy 2 5. Olivier Perrin, Maître de Conférences à l'université Nancy 2 6. Hala Skaf, Maître de Conférences à l'université Henri Poincaré Nancy 1 Chercheurs doctorants 1. Sawsan Alshattnawi, bourse franco-jordanienne 2. Dong Cheng, bourse UHP 3. Walid Gaaloul, bourse INRIA 4. Adnene Guabtni, bourse Gvt. tunisien 10

5. Gérald Oster, bourse INRIA Chercheurs post-doctorants 1. Sami Bhiri, DERI Gayway, Ireland 2. Gérald Oster, ETH Zurich, Suisse Ingénieurs experts 1. Florent Jouille Collaborateurs extérieurs 1. Gilles Halin, Université Nancy2, Centre de Recherche en Architecture de Nancy (CRAI) 11

C h a p i t r e 2 Dans ce chapitre, nous allons aborder la problématique de la réplication de données. Nous verrons quelques notions clés qui vont nous permettre d aborder les différentes approches théoriques existantes. C est ce qui nous conduira à l approche WOOT. Enfin, dans ce chapitre sont énoncés le modèle de données de WOOT, ainsi que l étude faite sur la librairie DIFF utilisée pendant le développement. 12

2.1 Réplication de données Pourquoi répliquer (partie 2.4) La réplication consiste à dupliquer des données critiques pour faire face à : 1. Tolérance aux pannes 2. Disponibilité performances Mais il faut gérer la cohérence des données, et de là, il faut distinguer deux concepts différents qui sont la réplication et la copie. La différence consiste en la gestion de la cohérence des répliques donc finalement une réplique est plus qu une copie. Il existe deux sorte de réplication (en fait il en existe trois nous verrons le troisième type plus tard dans cette partie) ; la réplication pessimiste et la réplication optimiste. 2.1.1 La réplication pessimiste Donne l illusion à l utilisateur qu il n existe qu une seule copie. Les protocoles les plus connus sont basés sur le principe ROWA (Read One Write All). Les lectures peuvent être faites sur n importe quelle copie tandis qu une écriture doit être appliquée de manière atomique sur toutes les copies. 2.1.2 La réplication optimiste Est une approche a priori plus adaptée au réseau P2P. Dans le cadre d une réplication optimiste, les copies peuvent diverger. A un instant donné, un utilisateur peut donc observer des copies d un même objet avec des valeurs différentes. Simplement, quand le système sera au repos (i.e. quand toutes les opérations auront été propagées à toutes les copies, alors toutes les copies devront être identiques). La réplication optimiste laisse donc les copies diverger à condition qu elles finissent par converger. 13

Si l on compare avec la réplication pessimiste, la réplication optimiste ne nécessite plus la mise à jour atomique de toutes les copies. La réplication optimiste est donc potentiellement plus performante. Cependant, il faut être capable de réconcilier des copies ayant divergés. 3.1.3 La réplication optimiste (et transformées opérationnelles) Le modèle des transformées opérationnelles a été développé par la communauté des éditeurs collaboratifs synchrones. La préservation de l intention est au centre de la définition du modèle de cohérence de cette approche. L architecture générale du modèle des transformées opérationnelles distingue deux composants. Un algorithme d intégration. Il est responsable de la réception, de la diffusion et de l exécution des opérations. Si nécessaire, il fait appel aux fonctions de transformation. Cet algorithme est indépendant du type des données manipulées (chaîne de caractères, document XML, système de fichiers). Un ensemble de fonctions de transformations. Ces fonctions ont la charge de «fusionner» les mises à jour en sérialisant deux opérations concurrentes. Ces fonctions sont spécifiques à un type de données particulier. L algorithme d intégration est défini comme correct si il assure la causalité, la convergence et la préservation des intentions. Le respect de la causalité garantit que pour les opérations pour lesquelles il existe une relation de causalité, celles-ci seront exécutées dans le même ordre sur toutes les répliques. Par exemple, nous considérons le scénario présenté à la figure 3.1 14

Figure 2.1 Exemple de relation de dépendance précédence Puisque l opération op2 a été générée sur le site 2 après que l opération op1 se soit exécutée, op1 précède op2. Si sur un troisième site, l opération op2 est reçue avant l opération op1 alors pour garantir l exécution de op2, op2 sera différée jusqu à la réception et l exécution de op1. Généralement, cette dépendance est maintenue en utilisant des vecteurs d horloges. Dans un système à n sites, un tel Vecteur V possède n composants. Chaque composante V[i] compte le nombre d opérations issues du site i qui ont été déjà exécutées sur le site. Nous parlerons de préservation de l intention ainsi que de la convergence dans le chapitre concernant WOOT. 2.2 WithOut Operational Transformation 2.2.1 Introduction WOOT est un algorithme de réplication optimiste adapté aux éditeurs collaboratifs. Il assure la convergence des répliques et préserve les intentions. WOOT est plus simple et plus efficace que les approches existantes. WOOT ne nécessite pas de vecteurs d horloge et peut être déployé massivement sur un réseau P2P. 15

2.2.2 Modèle de WOOT WOOT quitte l approche OT (Transformation Opérationnelle). En effet, au lieu de recalculer les relations d ordre a posteriori comme dans OT, WOOT diffuse les relations d ordre avec les opérations. Ainsi, nous sommes déjà sûr de préserver les intentions. Pour expliquer cette approche, nous allons prendre l exemple suivant : quand un utilisateur observe la chaîne de caractères «ABCDE» et qu il insère «12» à la position 2, on peut supposer qu il veut insérer «12» entre «A» et «B». Respecter les effets de cette opération consiste à préserver la relation «A» < «12» < «B» sur tous les futurs états de la chaîne. Nous devons donc adapter le profil des opérations. Plutôt que diffuser l opération insert (2, «12»), nous diffuserons l opération insert («A» < «12» < «B»). Un premier problème se pose : comment exécuter une opération insert («A» < «12» < «B») si nous avons localement supprimé le caractère «A»? Nous choisissons de ne pas détruire les caractères. Nous les marquons seulement comme invisibles. Bien sûr, si nous ne détruisons pas les caractères, cette approche va consommer plus de mémoire et générer des fichiers plus volumineux. Cependant, il a été démontré par les auteurs de l algorithme que la complexité de ce dernier est linéaire en espace et cubique en temps (dans le pire des cas). De plus, la complexité en mémoire de WOOT est inférieure ou égale à celle des algorithmes existants. En effet, nous ne conservons pas le journal des opérations et nous n utilisons pas de vecteurs d horloge. 2.2.3 L Algorithme WOOT a été testé et prouvé en utilisant les chaînes de caractères, mais cette approche peut être adaptée à n importe quelle structure linéaire. Cette structure linéaire peut être complexe comme un document XML, ou bien comme nous allons le voir plus tard (partie 2.3) dans un fichier modélisé sous forme de lignes. 16

2.2.4 Le modèle de données 2.2.4.1 Définitions Définition 1 : WOOT gère des W-caractères. Un W-caractère possède un identifiant unique id, un booléen v indiquant si le caractère est visible ou non ainsi que les identifiants du caractère précédent idcp et du suivant idcn et enfin la valeur alpha. Pour identifier un caractère de manière unique, nous construisons son identifiant avec le numéro du site numsites sur lequel il a été généré et l horloge logique actuelle de ce site Hs. Chaque site possède donc un identifiant unique numsites, une horloge logique Hs, une séquence de W-caractères Strings, et un ensemble d opérations en attente d intégration présent dans la queue d exécution Pools. Définition 2 : Le W-caractère d un W-caractère c est noté CP(c). Le W-caractère suivant d un W-caractère c est noté Cn(c). Définition 3 : L identifiant d un W-caractère id est un couple (ns, ng) où, ns est l identifiant du site (numsite s ) et ng est un entier naturel. Quand un W-caractère est généré sur un site s, ces identifiant sont fixés à (numsite s, H s ). Chaque fois qu un W-caractère est généré sur un site s, l horloge locale H s, est incrémentée. L unicité du couple (numsite s, H s ) forme un identifiant unique au W-caractère. string S est une W-string. Elle contient tous les W-caractères intégrés au site s. 17

Définition 4 : Une W-string est une séquence ordonnée composée de W-caractères C B c1 c2 cn C E où C B et C E sont des W-caractères spéciales (avec un identifiant id spéciale) qui marquent le début et la fin de la séquence. Nous définissons les fonctions suivantes pour une séquence S : S représente la taille de la séquence S. S[p] indique l élément à la position p dans la séquence S. On déclare que le premier élément de la séquence S est à la position 0 et le dernier élément est à la position S -1. pos (S, c) retourne la position de l élément c dans S (comme un entier naturel). insert (S, c, p) insert l élément c dans S à la position p. subseq (S, c, d) retourne la partie de la séquence S entre l élément c et d, les deux caractères ne sont pas inclus. Nous avons aussi besoin des fonctions suivantes pour faire le lien entre la W- string et la chaine de caractères que l utilisateur voie. value (S) est la représentation de S. (i.e. la séquence des caractères visible). ithvisible (S, i) est le i ème caractère visible de S. Il existe deux types d opérations affectant une chaîne de caractère. ins (c) insère le W-caractère c entre ses caractères précédent et suivant. La pré-condition pour réaliser cette opération est l existence des ses deux caractères. 18

del(c) supprime le W-caractère c. la pré-condition de del(c) est que le caractère c soit existant. 2.2.4.2 L ordre Soient a et b deux W-caractères. a < b si et seulement si il existe un ensemble de caractères c0, c1, c ci, tel que, a = c0, b= ci et Cn(cj) = cj+1 ou cj = Cp (Cj+1) pour tous 0<= j <=i. Soit S une séquence, la relation <=S est définie comme : a <=S b si est seulement si pos (S, a) <= pos (S, b) Quand aucune relation d ordre ne peut être établit entre deux caractères, nous devons ordonner ces caractères. Pour arriver à une convergence, l ordonnancement doit être indépendant de l état de site. Pour cela on utilise les identifiant des W-caractères. Soient a et b deux W-caractères avec leur identifiants respectives (nsa, nga) et (nsb, ngb). a < id b si et seulement si : (1) ns A < ns B ou bien (2) ns A = ns B et ng A < ng B 2.2.4.3 Les opérations Quand une réplique est modifiée, une opération correspondante est générée. Cette opération est 1. Immédiatement intégrée localement. 2. Diffusée aux autres sites. 3. Reçue par les autres sites. 4. Intégrées par les autres sites. 19

Génération : Pour une opération op, type(op) indique le type de l opération : del ou bien ins. char(op) indique le caractère manipulé par l opération. Quand un utilisateur interagit avec WOOT, il voit juste value(s). Donc, quand une opération d insertion est générée, l interface utilisateur connaît seulement la position et la valeur du caractère à insérer. Par exemple, ins(2, a) dans «xyz» est transformée en ins (y < a < z) Simultanément, quand une opération suppression est générée, on doit récupérer le W-caractère à cette position Réception : Les sites sont susceptible de recevoir des opérations avec des pré-conditions qui ne sont pas vérifiées. La fonction isexecutable vérifie les pré-conditions d une opération. 20

Pour gérer l emplacement en suspend des opérations (qui ne peuvent pas être exécutée pour le moment), chaque site maintient une queue d opérations (Pool). Par exemple, un site exécute del(c) seulement si c est présent. Si ce n est pas le cas, l intégration de l opération est reportée jusqu à ce que c soit présent. Intégration : Pour intégrer une opération del(c), nous avons besoin de modifier le booléen indiquant si le caractère est visible ou pas, et cela quelque soit la valeur précédente de ce booléen. Pour intégrer une opération ins(s) dans une strings, nous avons besoin de placer c parmi tous les caractères entre cp et cn. Ces caractères peuvent être soit supprimés soit insérés par des opérations concurrentes. Quand une opération ins(c) est exécutée sur un site, la procédure IntegrateIns(c, cp, cn) peut être appelée. 21

Exemple : Soient trois sites : site 1, site 2 et site 3 possédant chacun une réplique d une chaîne vide «CbCe», nous considérons le scénario décrit dans la figure 2.2. Le diagramme de Hasse correspondant est décrit par la figure 2.3. Figure 2.2 : scénario d insertion entre trois sites 22

Figure 2.3 Diagramme de Hasse du scénario La relation < id ordonne les caractères de la manière suivante : 1 < id 2 < id 3 < id 4. Le site 2 reçoit les opérations o1, o3, o4 dans cet ordre. L intégration se déroule de la manière suivante : IntegrateIns(1, c b, c e ) : S = L = 2 et 1 < id 2, WOOT intègre 1 entre c b et 2. Au cours de l appel récursif IntegrateIns(1, c b, 2), nous obtenons S =. Donc, le résultat obtenu est la chaîne c b 12c e. 2. IntegrateIns(3, c b, 1) : S =, WOOT insère 3 entre c b et 1. 3. IntegrateIns(4, 1, c e ) : S = L = 2 et 2 < id 4, WOOT intègre 4 entre 2 et c e. Nous obtenons au final la chaîne c b 3124c e. Sur le site 3, l appel IntegrateIns(2, c b, c e ) est résolu : S = 314 et C N (3) = C P (4) = 1, nous avons L = 1. Comme 1 < id 2, WOOT intègre 2 entre 1 et c e. Au cours de l appel récursif IntegrateIns(2, 1, c e ) : nous avons S = L = 4 et 2 < id 4, WOOT intègre 2 entre 1 et 4. Sur le site 3, nous obtenons la chaîne c b 3124c e comme résultat final. Sur le site 1, quelque soit l ordre d arrivée des opérations o2, o3, o4, nous obtenons la chaîne c b 3124c e. Ainsi tous les sites convergent vers l état final attendu 3124. 23

2.3 L évolution de WOOT Lors de notre arrivée au sein de l équipe, il existait une implémentation sous forme d un éditeur collaboratif en temps réel de l algorithme WOOT. Cette intégration était écrite en grande partie par l ingénieur associé Florent Jouille, avec le langage Java. Cependant, notre tuteur avait déjà programmé une version en C++. Cette version nous a servi comme base de comparaison des temps d exécutions pendant les travaux d optimisation. L éditeur temps réel utilise la technologie de broadcast afin de propager les opérations faites sur la séquence de caractères d un site. Chaque site rejoint une adresse de Multicast pour écouter ensuite ce qui passe à travers le réseau. Cet éditeur simple est pratique, car il a permis de réaliser des tests avec plusieurs sites partageants le même contenu. L équipe a également mis en place un package de tests qui sert à vérifier la convergence, l intention etc Nous avons tout d abord commencé par l étude de l algorithme WOOT en travaillant sur la documentation fournie sur celle-ci, et en particulier sur l article publié par les auteurs de WOOT, (Real-Time Group Editors Without Operational Transformation [1]). Cela nous a permis d avoir une vue globale de l approche. Ensuite, l étude des codes sources et des tests a fait éclaircir le fonctionnement de l éditeur ainsi que le fonctionnement de WOOT. Après que nous nous sommes familiarisés avec WOOT, nous avons commencé le développement d une version qui utilise une nouvelle structure de données. Cette structure de données linéaire était des pages (fichier texte) donc WOOT ne gérait plus une chaîne de caractère par site mais un ensemble de page. Quant à l élément W-caractère, il a était remplacé par une W-ligne, Ce passage a nécessité plusieurs changements dans le cœur de l éditeur ; à noter que le package de tests a été entièrement réécrit en Junit. Il était important de faire passer d abord les tests à chaque grande modification avant d avancer dans le développement. De plus, pour rendre les tests plus conviviaux, nous avons programmé une application en Swing qui simulait un site et qui proposait des opérations de base tels que l édition, la création et la 24

consultation des pages (sans pour autant propager les opérations aux autres sites). Entre temps, l équipe à continuer ses travaux sur l algorithme WOOT. Une nouvelle version plus optimisée venait de sortir. Les modifications concernaient la définition d un W-caractère ainsi que les fonctions d intégration et de génération d une opération. De façon sommaire, la transformation majeure était dans l introduction d un nouveau paramètre degré qui va remplacer le stockage de l identifiant précédent et suivant pour un W-caractère. Par conséquent, nous avons procédé à des changements au niveau du code source de l éditeur ainsi que les tests. Après avoir passé au modèle W-ligne, nous avons entamé l écriture d une nouvelle catégorie de tests visant à s assurer que l application développée jusqu ici est Therad-safe afin de protéger (synchroniser) les blocs d opérations critiques. Nous avons utilisé pour cela la librairie Quartz, qui est une librairie permettant de planifier simplement des tâches en java avec le JDK de manière plus sophistiquée. Nous avons aussi introduit la gestion de la persistance pour les données délicates (tel que le Pool, l Horloge etc ). 2.4 Stockage différentiel (JLibDiff) Cette partie représente l étude effectuée sur la librairie DIFF. Le résultat de cette étude a permis l intégration et l adaptation de la librairie diff au sein du système WOOKI en fonction de nos besoins. La construction d un environnement de travail coopératif est un objectif de l équipe ECOO (Environnement pour la COOpération). Cet environnement doit supporter efficacement la coopération qui s installe, ou qui doit s installer entre les différents acteurs et entre les différentes tâches. L équipe ECOO développe en particulier une approche de coopération indirecte et asynchrone 25

c est à dire une approche où les participants coopèrent en partageant les produits du projet à des moments éventuellement différents. Cette approche correspond à un modèle de type copie / modification / fusion. Différentes activités partagent des objets en possédant des copies de ces objets. Elles peuvent ainsi modifier ces objets en parallèle sans interagir avec les autres tâches. Lorsque cela est nécessaire, les différentes copies peuvent être réconciliées en fusionnant les valeurs divergentes. L équipe ECOO a construit un environnement de travail coopératif à travers le Web qui s appelle «Tuamotu». Le prototype est basé sur une architecture «d égal à égal» pour offrir à des activités distribuées un accès partagé. La coopération dans une telle architecture est rendue possible par le fait que les différentes copies d un même objet peuvent résider sur différents sites. Plusieurs activités distantes peuvent ainsi travailler simultanément sur des objets communs qui sont répliqués dans les sites. Dans ce système, tous les objets (fichiers et répertoires) sont «versionnés». Par conséquent, le stockage des différentes versions d un fichier au sein d un site pose des problèmes : Stocker toutes les versions d un fichier peut prendre beaucoup de place sur le disque. Transférer tout le contenu d un fichier entre les site par Internet peut prendre du temps (baisse de performance et augmentation du coût). Ces problèmes sont derrière la nécessité de réaliser un stockage différentiel des versions. En effet, il est plus judicieux de stocker la version initiale d un fichier et une séquence de modifications qui s y rattache plutôt qu une séquence de toutes les versions d un même fichier. On parle alors de data storage. 26

Le besoin d écrire une librairie qui calcule les modifications s est fait ressentir d où la naissance de librairie JlibDiff. La librairie DIFF est une librairie Java qui va permettre d effectuer un stockage différentiel des versions d un fichier. A chaque version d un fichier initial correspond un fichier de différences qui va être calculé et stocké. Pour retrouver par la suite une version, il suffit d appliquer le fichier de différences correspondant sur la version initiale. 2.4.1 La librairie Diff «in a nutshell» La librairie se base sur un programme de comparaison qui produit une liste de différences entre deux fichiers. Ces différences peuvent être vues en terme de lignes ; c'est-à-dire en précisant les lignes qui doivent être insérées, supprimées ou modifiées pour convertir le premier fichier vers le deuxième. Cependant la liste de différences peut identifier le changement, l insertion ou la suppression en terme de caractères (octets). Ce type de comparaison est utile pour les fichiers non-texte tels que les fichiers compilés qui ne peuvent pas être divisés en lignes. L approche donc est de générer des instructions pour changer, insérer ou supprimer entièrement des lignes qui seront vues comme des objets indivisibles. Une ligne peut être symbolisée par un caractère. Donc un fichier qui contient n-lignes peut être modélisé par une chaîne comprenant n- symboles Cette partie étant terminée, nous pouvions passer à l étape suivante qui concerne la mise en place de WOOT au sein du projet WOOKI. C est cette étape qui va nous mener au chapitre suivant. 27

C h a p i t r e 3 Nous avons déjà vu dans le chapitre précédent la présentation de WOOT en terme d algorithme et structure de données. Nous allons observer plus précisément dans ce chapitre comment les opérations circulent entre les différents sites du réseau. Nous examinerons par la suite l étape de conception du projet WOOKI jusqu à l arrivée au modèle actuel. Nous nous intéresserons également au déploiement et l installation de l application sur le réseau. 28

3.1 Le système de réplication Nous avons déjà vu que pour supporter le travail en parallèle, les données doivent être répliquées d une manière optimiste. Dans ce processus de collaboration, chaque utilisateur travaille sur une copie, produit des opérations (exécution locale) et enfin diffuse aux autres voisins l ensemble de sa coopération. Le projet WOOKI est constitué de deux grandes parties, à savoir l algorithme WOOT plus un système de réplication des données (la partie qui se charge de gérer et de transmettre la coopération entre les pairs). Nous allons donc découvrir dans cette partie les travaux et les recherches qui ont été mené afin de mettre en place un algorithme de gestion de la propagation des messages (coopération) entre les voisins (nœuds) ainsi que la construction de la topologie du réseau pairs à pairs. 3.1.1 Introduction Les réseaux pairs à pairs permettent la communication, le partage simple d'informations des fichiers le plus souvent, mais également des flux multimédia continus (streaming), le calcul réparti, la téléphonie (comme Skype), etc. sur Internet. Le pair-à-pair permet à chaque participant au système de proposer des ressources aux autres participants tout en accédant aux ressources disponibles dans le réseau. Le pair à pair a permis une décentralisation des réseaux en permettant à tous de jouer le rôle de client et serveur. En particulier, les systèmes de partage de fichiers permettent d'avoir des objets d'autant plus disponibles qu'ils sont populaires, et donc répliqués sur des nœuds. Cela permet alors de diminuer la charge imposée aux nœuds partageant les fichiers populaires, ce qui facilite l'augmentation du nombre de nœuds donc de fichiers dans le réseau, aussi appelé passage à l'échelle (Scalability). 29

3.1.2 La diffusion à grande échelle en utilisant les réseaux pairs à pairs La résistance du système global et le maintien en cohérence reposent en fait sur le système de diffusion des mises à jour entre les différentes répliques. Notre système de réplication doit être redondant pour tolérer les pannes de communications Les algorithmes de diffusion «classiques» présentent certaines limites : ils s appliquent à un ensemble bien identifié de processus ; Les contraintes fortes sur leurs spécifications font que ces algorithmes passent très mal à grande échelle. En fait, il existe certains algorithmes, en l occurrence JXTA qui sont obligés de prévenir leur groupe en cas de connexion ou de déconnexion (contraindre à utiliser les fonctionnalités Join et Leave). Or pour notre modèle nous souhaitons utiliser la diffusion pour des applications dans lesquelles : Le nombre de processus (ou sites) est inconnu et variable (par rapport au temps et au nombre) ainsi que la topologie d interconnexion. Le nombre de sites est potentiellement très grand (taille d Internet) ; les sites jouent un rôle symétrique (chacun est client et serveur), de plus la déconnexion et la connexion ne peut pas être anticipée. La première approche choisie était fondée sur un Protocole simple qui est basé sur un mécanisme d anti-entropie. En effet, lorsque la connexion d un appelant vers un appelé est faite, le contenu des deux pairs est mis en commun. Les éventuelles informations obsolètes de l un sont rafraîchies par les informations plus récentes de l autre. A la fin de la mise en relation, le contenu des deux pairs est identique entre l appelant et l appelé. Dans le cas de notre protocole, L appelant envoie un message CONNECT auquel l appelé répond par un RESPONSE en y attachant les informations de sa base de messages local. Il est alors possible pour l appelant de répondre à 30

ce RESPONSE par un autre RESPONSE auquel il attache les informations de sa propre base de messages local. Il faut noter toutefois que le site appelant garde en mémoire une estampille associée au site appelé (un espèce de journal sur les messages échangés) qui va permettre aux prochaines synchronisations de récupérer juste les données qui ont été ajoutés dans la base locale du site appelé depuis la dernière synchronisation ; voir l exemple ci-dessous. Figure 2.4 schémas, scénario de synchronisation entre deux sites Mais cette approche a vite montré ses limites en termes de performances et d efficacité lors des tests. De plus, la construction de la topologie du réseau est assez rudimentaire et ne repose sur aucun algorithme ou spécification prouvée. C est ce qui nous a amené à revoir la façon d aborder ce problème avec notre tuteur. Nous sommes arrivés à la conclusion suivante : il est 31

nécessaire d utiliser la propagation probabiliste. Notre tuteur nous a soumis un certain nombre de papiers qui traitent de ce sujet notamment NEEM Network-Friendly Epedimic Multicast [3], Bimodal Multicast [6], Lightweight Probabilistic Broadcast [8] et enfin Epedimic Algorithms For Replicated Database Maintenance [5]. L étude et l analyse de ces documents nous ont conduit au résultat suivant : Utiliser un algorithme qui se compose de deux sous protocoles structurés. 3.1.2.1 Le premier protocole Ce protocole utilise le principe de la propagation aléatoire (la propagation d une rumeur gossip) Chaque processus (site) participe à la diffusion. Les paramètres sont : Capacité b : nombre de messages qu un processus peut stocker Nombre de retransmissions t : nombre de phases de rediffusion Nombre de destinataires f : à chaque phase, le processus transmet le message à f destinataires choisis aléatoirement Les paramètres b, t, f caractérisent un algorithme de diffusion épidémique. Ils peuvent être fixés indépendamment du nombre total n de processus ou être fonction de n. Au départ, un message (un message représente une coopération à échanger entre pairs, cette coopération comporte des opérations simple comme l insertion d une ligne à tel position dans une page, suppression d une ligne etc.) est initialement taggué avec le nombre maximale de rounds r et ensuite retransmit (forwarder) à f, autre nœuds distincts choisi de manière aléatoire. À la réception (par un pair), le nombre de rounds est décrémenté. Si le nombre de rounds atteint le zéro, le message est supprimé sinon, on l envoie encore 32

une autre fois à f autres nœuds connus d avantage par le pair qui vient de recevoir le message. Les garanties offertes par ce Protocole dépendent d une configuration approprié des deux paramètres r et f. d une autre part lors de la réception d un nouveau message par un pairs p ce dernier consulte sa liste de nœuds connus et en supprime un de manière aléatoire et ajoute à sa place le pair auteur du message reçu. Cette manière dynamique d interconnecté les pairs et de crée les liens entre eux permet d avoir une topologie fiable et tolérante au panne (notamment la déconnexion massive des pairs) 3.1.2.2 Le deuxième protocole Ce protocole est un protocole biphasé d'anti-entropie qui opère parmi une série désynchronisé de pairs. Chaque site choisit régulièrement (de manière aléatoire) un autre site (voisin). Le site appelant calcule la différence avec le site appelé et obtient une liste de messages perdus. La deuxième phase consiste à corriger de telles pertes en récupérant les coopérations manquantes. On constate que la diffusion épidémique sur un réseau pair à pair est utilisée sur des systèmes de grande taille. Avec une évolution dynamique, parmi les avantages de ce type de diffusion on cite : Facilité de réalisation et de mise en place Robustesse (vis-à-vis des modifications de l environnement) Grande tolérance aux défaillances Pas de reconfiguration pour la reprise 33

Ajustement via un petit nombre de paramètres Malheureusement ce système révèle quelques limitations : Nécessite des ressources en mémoire Pas de garanties strictes (seulement probabilistes) Par conséquent, nous avons mis en place une troisième couche qui permet de combler plus au moins ces difficultés : Gestionnaire d état : Le gestionnaire d état est une autre couche du protocole qui intervient dans des moments bien précis. Pour résoudre le problème lié à la mémoire, nous avons adopté une politique de purge qui consiste à lancer une suppression du log qui contient les messages reçus de part et d autres. Cette suppression n est pas aléatoire. Elle peut être déclenchée par exemple pour supprimer les anciens messages qui datent de plus d un mois, ou bien si une certaine taille du log est atteinte (log cyclique) la purge est lancée. Au même instant et avant de supprimer réellement les messages, un état qui correspond au site à ce moment là est créé. Cet état est très important car il permet aux autre sites qui sont hors synchronisation (un site qui s est déconnecté pendant trois mois et qui voudrait commencer une opération d anti-entropie à partir d un message qui ont déjà été supprimé est considéré comme out of sync) de récupérer un état cohérent à partir duquel il peut commencer à synchroniser avec le site émetteur de l état. Un site nouvellement ajouté au réseau n a pas besoin de récupérer tous les messages qui ont été émis depuis le départ ; on dit qu il n a pas besoin de 34

suivre toute l histoire d une certaine ressource répliquée. Pour cela, il récupère un état à partir d un voisin. En intégrant cet état, il peut être opérationnel et peut commencer à coopérer avec le reste des pairs. 3.1.3 Conclusion Nous avons un système fortement répliqué qui possède a priori de nombreuses propriétés favorables pour l obtention d une bonne disponibilité des données. En terme de tolérance aux pannes, nous supportons deux types de pannes : les pannes de sites et les pannes de réseau. De plus, la programmation de la partie système de réplication a été faite en suivant l état de l art. C'est-à-dire en utilisant des solutions et des algorithmes prouvées et testées pour leur efficacité et leurs passages à l échelle. 3.1.4 Complément Mathématique Les algorithmes épidémiques comportent une succession de tours. Soit n la taille de la population, Y(r) le nombre d individus touchés ( infectés ) après le r-ième tour. Alors, si un individu infecté continue la propagation à tous les tours, on a p = Y(r)/n! 1/( 1 + n exp( fr)) (f = fanout, taille de l ensemble de diffusion) Donc la proportion d individus touchés augmente exponentiellement avec le nombre de tours et avec f. Si un individu touché ne propage l infection que pendant un tour ( infect and die ), alors la proportion p satisfait l équation. p = 1 exp( pf) 35

Dans ce modèle, supposons que f = log(n) + c (c est un paramètre) Alors la probabilité que tous les processus soient touchés à terme est P = exp ( exp ( c)) Il y a un changement de comportement quand c change de signe, donc quand f dépasse log(n) 3.2 La conception du WOOKI La conception du projet WOOKI a déjà été entamée au moment ou nous travaillions sur l algorithme WOOT, et ceci par deux stagiaires qui pendant leur présence dans l équipe ont mis en place avec notre tuteur un modèle UML décrivant les principaux composant que le système WOOKI devrait intégrer en plus des relations entre ces composants. Des diagrammes de classes ainsi que les diagrammes des cas d'utilisation (usecases) nous ont été parvenu par ces deux stagiaires. Nous avons donc commencé l analyse de ces documents. Nous avons eu beaucoup de réunion avec l ingénieur associé et les deux stagiaires afin de discuter des schémas fournis. Des modifications et des améliorations ont été introduites au modèle de conception de WOOKI à l issue de chaque réunion. A ce stade de la conception, nous sommes arrivés aux modèles suivants : 36

Authentification Not part of the system!! login edit page <<use>> user <<use>> see page synchronization clock create page add a new neighbour administrator delete a neighbour Figure 3.1 : use-case 37

Use Case Actors Brief Description Add a new neighbour. Administrator. In this use case, the system administrator adds a new neighbour (server) to those which are already in the system. Preconditions Basic flow of events The new neighbour mustn t be an existing neighbour. Step Action 1 Administrator selects the operation add new neighbour. 2 System asks to the administrator the location of the new neighbour. 3 Administrator inserts the URL of the new neighbour. 4 System checks that new neighbour s URL is not an existing one. Alternative flow of events 5 System adds the new neighbour. 6 System informs the administrator about the operation achievement. Use case ends. Step Action 4 The URL is an existing one, system asks for a new URL. Return to step 4. Postconditions 1..4 Administrator cancels the operation, go to step 6. 1..6 An error occurs on the net, go to step 6. The new neighbour has been inserted. Comments Figure 3.2 : use case (Ajouter un nouveau voisin) 38

: administrator : site selectoption(addnewneighbour) requesturl( URL) seturl(url) checkurl( URL) addurl( URL) Figure 3.3 : Diagramme de séquence (ajouter un nouveau voisin) 39

Use Case Actors Brief Description Preconditions Basic flow of events Delete a neighbour. Administrator. In this use case, the system administrator deletes an existing neighbour (server) from the system. The neighbour must be an existing neighbour. Step Action 1 Administrator selects the operation delete neighbour. 2 System searches the list of existing neighbours. 3 System shows the existing neighbours list to the administrator. Alternative flow of events Postconditions Comments 4 Administrator selects the chosen neighbour from the list. 5 System disconnects the server. 6 System deletes the neighbour from the list. 7 System informs the administrator about the operation achievement. Use case ends. Step Action 1..6 Administrator cancels the operation, go to step 7. 1..7 An error occurs on the net, go to step 7. The neighbour becomes inaccesible. Figure 3.4 : use case supprimer un voisin 40

: administrator : site selectoption(deleteneighbour) showurllist(list) selecturl(url) searchurllist() disconnecturl(url) deleteurl(url) Figure 3.5 : Diagramme de séquence, supprimer un voisin 41

Use Case Actors Brief Description Preconditions Basic flow of events See page User. This use case shows the content of a page. Step Action 1 User inserts the name of the page s/he wants to see. 2 System searches the page. 3 If page doesn't exist 3.1 System informs the user of the event. 3.2 System asks the user if he wants to create a page with that name. Alternative flow of events Postconditions Comments 4 System shows the selected page in reading mode. 5 Use case ends. Step Action 1..4 User cancels the operation, go to step 5. 1..4 An error occurs on the net, go to step 5. Figure 3.6 : use cas consulter une page : user : site insert(pagename) [page doesn't exist] createpage() search(pagename) show(pagename) Figure 3.7 : Diagramme de séquence chercher une page 42

Use Case Actors Brief Description Preconditions Basic flow of events Edit page This use case opens a page in edition mode. The use case See page has been successfully carried out. Step Action 1 System creates a local copy of the open page. 2 System opens the local copy of the selected page in edition mode. Alternative flow of events Postconditions Comments 3 User inserts page changes. 4 User saves the changes. 5 Use case ends. Step Action 1..4 User cancels the operation go to step 5. 1..4 An error occurs on the net, go to step 5. Figure 3.8 : use case Edition d une page : user : site openlocalcopy(pagename) createlocalcopy(pagename) insertchanges() savechanges() save() Figure 3.9 : Diagramme de séquence édition d une page 43

Use Case Actors Brief Description Preconditions Basic flow of events Alternative\ flow of events Postconditions Comments Create page In this use case, the user creates a new page. The use case See page has been successfully carried out. Step Action 1 User select the operation create page. 2 System sets an unique Id for the page. 3 System links the Id and the name of the page. 4 Go to Edit page use case. 5 Use case ends. Step Action 1..4 User cancel the operation go to step 5. 1..4 An error occurs on the net, go to step 5. Figure 3.10 : use case créer une page : user : site selectoption(createpage) setid(pageid) link(pageid, pagename) See diagram: Edit page Figure 3.11 : Diagramme de séquence créer une page 44

Use Case Actors Brief Description Preconditions Basic flow of events Shyncronization. Clock. In this use case, operations carried out in different sites are integrated. Step Action 1 Clock access the corresponding site. 2 Clock requests the new operations to be integrated. 3 Site looks up its neighbours' list. 4 Site requests each neighbour its new operations which have to be integrated. Alternative flow of events Postconditions Comments 5 Site provides the system with the received operations. 6 System integrates the operations. 7 System broadcasts the integration over all the sites. 8 Use case ends. Step Action 1..7 An error occurs on the net, go to step 8. This use case is carried out regularly by the clock of each site. Figure 3.12: use case synchronisation 45

Id localclock site page pageid insert() display() 1 0..* row rowid visible value 0..* 1 +pageid next integrate() synchro() synchro() seturl() checkurl(url)() requesturl() checkurl() addurl() opname() set() link() See diagram: Edit page.() See diagram: Edit page() 1 +URL 0..* neighbours URL LSD 1 1 log diff() get() 1 0..* op localdate opid opname() previous getlog() insertline pageid Cp Cn value deleteline lineid pageid insertpage pageid Figure 3.13 Diagramme de classes (Note: comme vous pouvez le remarquer, les diagrammes et schémas sont en Anglais, ceci est due au fait que les deux stagiaires étaient des espagnoles. Par conséquent nous échangions les documents en Anglais) 46

A partir de là, nous avons débuté la phase de développement des différents packages. Durant le développement il y eut énormément de changement que ce soit par rapport au code ou bien vis-à-vis de la conception ; un grand refactoring a eu lieu à la fin du stage (voir partie 3.3.2) En même temps, des travaux d optimisation de l algorithme WOOT ont eu lieu afin d arriver à des temps d exécution et d intégration correctes. A noter que le point positif durant cette phase d optimisation est la participation de deux parmi les auteurs de l algorithme ainsi que l ingénieur associé. Ces journées ont été très bénéfiques pour nous car nous avons travaillé en groupe. En effet, les sources étaient disponible sur un serveur qui offre des fonctionnalités CVS (voir partie 1.1.6 concernant libre source) et ainsi, tout le monde passe le code en revue, propose des modifications et envoie (commit) ces changements aux autres. A chaque modification, nous utilisions des programmes dits de profiling pour évaluer les temps de réponse du programme et l utilisation de la mémoire. En fait, une version de WOOT écrite en C++ nous servait de base pour la comparaison. 47

Figure 3.14 Profiler de l éditeur NetBeans, 48

Figure 3.15 Profiler Utilisé sous NetBeans Avant de passer au chapitre suivant, le bilan que nous pouvons dresser à la fin de cette phase est notre adoption d une méthode de programmation claire est structuré. Cette méthode (réflexes) est le résultat des conseils des gens qui nous entouraient ; en l occurrence notre tuteur et l ingénieur associé. 49

Ces réflexes de coding consistent en quelques points clés : La revue du code par groupe (par un binôme avec mon tuteur et l ingénieur) ; Les tests sont utiles. Ils sont systématiquement fait avant chaque implémentation ; Le choix d une conception simple, car la conception est importante. Elle est faite tout au long du projet (refactoring) ; car elle change souvent. La simplicité permet d'avancer plus vite. Nous choisirons toujours la solution la plus simple ; On trouve là les principes de base qui régissent L'Extreme Programming. 3.3 Architecture de l application 3.3.1 Introduction Cette partie n a pas pour objectif d expliquer de manière exhaustive le fonctionnement de chaque composants, ni de rentrer dans les détails de programmation qui ont permis de réaliser tels ou tels tâches mais elle a pour but d offrir au lecteur une vue globale de l architecture du système WOOKI tout en maintenant un certain niveau d abstraction face a la présentation des composants et des solutions choisies. Nous allons aborder dans ce chapitre l architecture du projet WOOKI par la présentation des principaux schémas UML (diagrammes de classes principalement) utilisés pendant la phase de conception. 50

3.3.2 Schéma global Le schéma de la figure 3.16 expose les packages de l'application. Parmi les grands changements qui ont été effectué sur la conception de WOOKI, on note la division en quatre principaux package de l application. En fait, la première approche avait tendance à mélanger le système de réplication avec celui des classes métiers (à savoir l algorithme WOOT) qui avaient comme tâche l intégration des coopérations. Cela donnait un certain aspect d ambiguïté quant aux dépendances de chaque composant vis-à-vis de l autre. De plus, cette architecture ne reflétait pas nécessairement la véritable implantation souhaitée par l équipe, et qui avait comme principal but, la réutilisation de certains composants. Une autre problématique se soulevait systématiquement. Il s agissait de la difficulté de réécrire les packages de tests (preuve de convergence, contre exemples, performances, thread-safe etc.). A chaque modification dans le modèle, cette opération était très laborieuse et très coûteuse en terme de temps. Après avoir discuté longuement avec notre tuteur de l utilité de chaque composant, nous sommes arrivés aux conclusions suivantes : - WOOT est un algorithme qui fonctionne sans vecteur d horloge est sans l aide d un journal (log) des coopérations intégrées, - WOOKI sera prochainement utilisé par un autre algorithme de réplication de données optimiste (TTF). Il serait préférable d opérer ce changement de manière dynamique et succincte. 51

Par conséquent, il était nécessaire de maintenir un certain niveau d abstraction avant l implémentation des classes. Ces changements se traduisent par le design présenté dans cette partie. Figure 3.16 les différents packages de WOOKI Le package fr.loria.ecoo contient quatre packages : algorithme : Comme son nom l indique ce package va contenir l implémentation de l algorithme responsable de la convergence des différents répliques (WOOT est utilisé actuellement, TTF va probablement être utilisé prochainement). Neighbors : Ce package est très important car il intègre les algorithmes de diffusion des coopérations ainsi que la création de la topologie réseau pairs à pairs (voir la partie précédente 3.1) 52

log : Le log est le journal des coopérations stockées par WOOKI afin de les partager et les échanger avec les voisins. Util: On regroupe ici toute classe utile mais qui n a pas de rapport direct avec le projet. La plupart des classes qui s y trouvent sont statique. 3.3.1 Package Algorithm Figure 3.17 : Package algorithm 53

Le package algorithme se constitue tout d abord de l interface Algorithm qui définis les point d entrés et de sorties que l implémentation doit offrir aux autre packages pour que la communication puisse être mise en place. Parmi les méthodes importantes on cite les opérations de base à savoir ins et del, (il faut rappeler que le fonctionnement de WOOT est très simple, il s agit de réaliser des opérations d insertion et de suppression sur une structure de données même celle-ci n est pas définie). Le package contient bien évidement la classe WootSite, l implémentation de l interface Algorithm, le package contient aussi le package test. En fait, parmi les conséquences positives de ce nouveau design, c est la disposition des tests qui sont spécifique à chaque package. Dans notre cas Algorithm, on trouve que les tests qui ont un rapport avec ce composant, l idée dominante, toute au long de cette phase d implémentation est la suivante, «l écriture d un composant simple qui réalise une et une seule tâche, et qu il réalise bien, aussi, ce composant dispose d une batterie de tests assez complète». C est l idée clé qui nous a guidé durant toute la partie conception, notre tuteur n a pas hésité à nous «rappeler à l ordre» à chaque fois qu on transgressé cette règle! 3.3.1.1 Le Package WOOT Le Package WOOT se divise en trois sous packages : Op, clock, core : Op : comporte la définition d une opération de base dans l algorithme WOOT, ces opérations sont de type insertion ou suppression d une ligne dans une page clock : est le package contenant l implémentation d une horloge persistante Note : l horloge est utilisée par exemple comme moyen de trie pour les opérations selon un certain ordre 54

Figure 3.18 : Package WOOT 55

Core : est le package cœur de l algorithme WOOT, il inclut la définition de la structure de données (WootPage) ainsi que la définition de la queue d exécution persistante (Pool, c est ici qu on stocke les opérations qui ne peuvent pas être exécutées pour le moment, car elles ne satisfont pas leurs pré-conditions). Figure 3.20 : Package Op 56

Image 3.21 : Package Clock 57

Figure 3.22 : Package core 58

3.3.1.2 Package test Ce package englobe les principaux tests concernant l algorithme WOOT, nous trouvons les tests de convergence (preuve de convergence, contre exemples, respect de l intention par le système etc.). Il renferme aussi une batterie de test de performances (temps nécessaire à l intégration des données etc.). Figure 3.23 : Package test 59

3.3.2 Package Neighbors Dans cette partie nous allons exposer l implémentation de l algorithme de broadcast au sein de l application WOOKI. L intégration de l algorithme de broadcast est très simple, nous avons une interface Neighbors (voisins) qui définit les règles générales que n importe quelle implémentation doit suivre. Les méthodes de l interface sont définies dans la classe HashNeighbors (nous avons choisi ce nom car d autre implémentations de l interface étaient présentes, la différence entre eux réside dans le choix de la structure de données qui devait accueillir les Neighbors, dans notre cas nous avons décidé de garder l implémentation qui utilise les HashTable d où le nom HashNeighbors, (d autres utilisent les Vector etc. ). Comme la coutume le veut bien, nous retrouvons aussi la batterie de test associé à ce package. 60

Figure 3.24 : Package Neighbors 61

a classe HashNeighbors, contient deux partie, d une partie : les méthodes qui permettent d interagir avec une voisin, on cite : l ajout d un voisin à sa liste, la suppression, vérifier si un voisin est opérationnel (échange de coopérations possible). Et d autre partie, on trouve les méthodes spécifiques au protocole de braodcast : start, stop et resume synchronization qui vont démarrer, arrêter ou bien reprendre la couche anti-entropie du protocole, notifyneighbors a pour mission de broadcaster aux voisins une nouvelle coopération, par contre la construction de la topologie du réseau (la mise à jour de la liste des voisins) est à la charge de la méthode add qui reçoit une coopération d un autre voisin et se charge d exécuter l algorithme approprié décrit dans la partie 3.1.2.1. 3.3.4.1 Package test Les tests consistent à simuler un réseau pour broadcaster des messages et voir l évolution des différents Peer (voisins), les tests vérifient aussi la contamination des Peers (la contamination est le fait qu un message est bien arrivé à tous les voisins), ils vérifient aussi que la propagation des messages s est bien déroulée. 62

Figure 3.25 : Package test 63

3.3.3 Package log Ce package représente l historique des événements, c est-à-dire l'enregistrement séquentiel sur un support persistant des différentes coopérations reçues ou produites. Il offre aussi une interface qui est le point d entrée des autre packages. LogImp est la classe qui implémente cette interface et qui propose un certain nombre d opérations élémentaires à savoir : clearpatchs qui réalise la tâche purge log utilisée dans l algorithme de diffusion (voir partie 3.1.2.2). On trouve aussi la méthode qui ajoute une coopération, en fait on utilise un système de Message (Classe MessageImpl) un message représente une coopération : il contient (selon l algorithme vue dans la partie 3.1.2.1) un round, un expéditeur et enfin le contenu. Le contenu est représenté sous forme de Patch (classe PatchImpl) le patch contient une collection d opérations (voir package Op). Image 3.26 : Package log 64

65

3.3.4 Package Editor Les packages et les classes se trouvant dans ce Package servent à gérer et configurer l ensemble de l application WOOKI et la rendre interactive. Figure 3.27 : Package Editor Un éditeur se doit d implémenter l interface Editor qui contient un point d entrée vers l interface Log ainsi qu une méthode executeandgeneratepatch qui permet la génération et l exécution d une coopération. Bien entendu la manière dont la coopération est générée dépend de l implémentation choisie. 66

Dans notre cas le package webapp intègre cette interface et utilise principalement des composants J2EE (Servlets, taglib, JSP page etc ) afin de réaliser cette adaptation. 3.3.4.1 Package Webapp Figure 3.28 : Package webapp 67

À la racine de ce package on repère deux Classes : WookiStart : est la ServletListener elle a à sa charge la capture des événements du début et la fin de l application, ces événements sont très importants, en effet, ils permettent une initialisation correcte et le chargement des paramètres stockés sur le support persistant. Quant à la classe WookiConfig elle permet de créer le singleton WookiConfig qui sera accessible à toutes les Servlets qui nécessitent un accès a une ressource particulière, par exemple, une Servlet qui nécessite l accès au package Woot afin de soumettre un patch a exécuter, une autre Servlet qui aura besoin de récupérer un certain nombre de Messages stockés dans le log etc. Cette approche évite de créer plusieurs instances des différents packages, en les centralisant ainsi (l accès), nous avons un gain de mémoire et une lecture clarifiée du code. 3.3.4.1.1Package HttpUnitTests Est le package de tests des Servlets, il utilise la librairie HttpUnit (l équivalent de Junit, mais pour les applications basées sur le protocole http). Figure 3.29: Package HttpUnitTests 68

3.3.4.1.2 Package Wiki Figure 3.30 : Package Wiki Quelques macro (smiles, images, liens) et taglib sont utilisés dans Wooki on trouve ici leurs définitions. À noter que nous avons intégré le rendu de la syntaxe wiki grâce à la librairie du moteur connu Radeox (site officiel : http://radeox.org/). 69

3.3.4.1.3 Package Servlets Ce package comporte l ensemble des Servlets de l application (juste les Servlets pas les pages JSP), Nous allons dans ce qui suit donner une breve description à chacune. (Note : Pour des raisons de lisibilité nous avons choisi de découpé le diagramme UML en trois parties afin que le lecteur puisse suivre les explications) Partie 1 : BaseServlet : C est la Servlet mère, les autres Servlets doivent dériver d elle. En fait, le système de gestion des exceptions est à l origine de ce choix, nous considérons que toutes les exceptions sont levées et ensuite traitées par la Servlet mère qui en fonction de l exception redirige vers la bonne page d erreur, c est elle qui a la charge de différencier les types d exceptions (selon que l erreur est due au système erreur interne- ou bien c est une erreur externe impossibilité de lire un fichier à titre d exemple). CreatePage: C est la Servlet par défaut, en effet le mapping (dans le fichier de configuration Web.xml) redirige toutes les requêtes inattendues vers cette Servlet, (par exemple pour des raisons de sécurité on empêche l accès directe à certain page JSP, par conséquent l appel via une url de la page renvoie vers la Servlet par défaut). Autre cette fonctionnalité CreatePage permet évidement de créer une page, les pré-conditions pour que cette création aboutisse, est un nom de page qui n existe pas, en plus de choisir un nom valide. ViewPage: Affiche le contenu d une page et cela en faisant appel aux méthodes appropriées dans le package Algorithm via le singleton WookiConfig. 70

Figure 3.31 : Package Servlets (partie 1) 71

C est aussi la première Servlet appelée par la ServletListener WookiStart et c est elle qui vérifie si tous les paramètres de configuration ont été bien chargés au moment de l initialisation, dans le cas contraire elle fait appel à la Servlet BootStrap qui va amorcer et initialiser l application WOOKI. (note : bootstrap est un petit programme d'amorçage qui permet d'en lancer un plus gros) Bootstrap: Est la Servlet qui est appelée lors de l absence du fichier de configuration de l application (généralement au premier démarrage). Elle est aussi appelée en cas de problème avec un paramètre qui fait obstacle face au processus. de démarrage (par exemple, un fichier de configuration importé d un système Linux, pour être utilisé sous Windows, dans ce cas les chemins de fichiers absolus vont poser certainement un problème). Bootstrap fait appel à une page JSP qui présente à l administrateur un formulaire (prérempli) dans lequel il devra renseigner certains paramètres. Des tests sont ensuite appliquer aux paramètres. S il existe un quelconque souci, le système ne démarre pas et redemande la correction des paramètres toutes en indiquant le(s) message(s) d erreur(s). EditPage : Comme son nom l indique cette Servlet donne la possibilité à un utilisateur d éditer le contenu d une page afin d en modifier le contenu, en fait, ce processus d édition se compose de deux phases : la première phase, consiste en la génération d une refcopy. Une refcopy est une copie de l état actuel de la page à l instant t (en d autre termes, c est l état de la page comme la voie l utilisateur x à l instant t). Cette refcopy est produite pour deux raisons. Tout d abord, la page peut être modifiée par un autre utilisateur pendant la modification (intégration par le système des opérations générées). Deuxièmement, cette refcopy va être utilisée dans la deuxième phase qui consiste à calculer à l aide de la librairie présentée dans la partie?, à savoir Jlibdiff, la différence entre les deux fichier (refcopy et page modifiée) pour en générer un Patch d opérations. Celui-ci sera ensuite exécuter par le système, puis intégrer dans un Message pour être envoyer à nos voisins. Tout ce 72

processus est implémenté par la méthode executeandgeneratepatch qui n est autre que la méthode de l interface Editor, donc EditPage dans notre cas. ViewModifications: Il s agit d une Servlet à caractère utilitaire, elle permet juste l affichage de la page (à l instar de ViewPage) mais dans un mode spéciale ou nous pouvons voir toutes les modifications qui ont été apportées à la page depuis sa création (il faut rappeler que l algorithme WOOT ne supprime pas physiquement les lignes, il pose juste un marqueur pour indiquer que cette ligne est visible ou non à l utilisateur d où la présence des méthodes tostring et tohumanstring dans le package Algorithm). PageList: Liste l ensemble des pages existantes. Partie 2 : Neighbors : Cette Servlet et le point d entrée des opérations concernant les voisins : elle affiche la liste des voisins disponibles, nous avons la possibilité d en supprimer un ou bien d en rajouter un nouveau. Join : Cette Servlet permet de joindre un groupe (réseaux de voisins) en sélectionnant l adresse d un élément du groupe dans le but de se connecter et se faire connaître (en envoyant un Message voir l algorithme de broadcast 3.1.2). AddNeighbor : Ajoute un voisin à la liste. L appel de cette Servlet n est pas le seul moyen d en rajouter, en effet, en suivant l algorithme de broadcast (voir partie 3.1.2) lors de la réception d un nouveau message on regarde le destinataire, s il n existe pas on le rajoute (dans la limite du nombre maximal de voisins à connaître). 73

RemoveNeighbor : Supprime un voisin de la liste. L appel de cette Servlet n est pas la seule manière de supprimer un voisin, en fait, dans la class HashNeighbors toutes les communications avec un autre voisin sont soumis a un timeout (délai de connexion). Si par exemple on n arrive pas à contacter ce voisin au bout de ce timeout, il sera systématiquement supprimé de la liste, le voisin est également supprimé si on rencontre un problème réseau en essayant de le contacter. IsWookiSite : Cette Servlet n est pas directement accessible par l utilisateur, mais elle est utilisée principalement par la Servlet AddNeighbor et Join afin de vérifier que le site proposé pour l ajout est un vrai site WOOKI et qu il est opérationnel (cette vérification est faite par l envoie de certain headers http) 74

Figure 3.32 : Package Servlets (partie 2) 75

Partie 3 : ReceiveMessage : Cette Servlet est invoquée par le voisin appelant qui veut envoyer un message à tous ses voisins. Le site appelé reçoit donc le message et appel la méthode receive de l interface Neighbors qui se charge d exécuter l algorithme de réception d un nouveau message (voir partie 3.1.2.1) GetMessageIds : Cette Servlet retourne tous les messages id disponibles dans notre log afin de les retourner au site appelant. En fait, cette Servlet fait partie du processus d anti-entropie, en effet, si le site a souhaite réaliser une anti-entropie avec le site b, il va tout d abord récupérer les messages id (les identifiants des messages, pas le message avec le contenu!). Il calcul ensuite la différence avec ce qu il dispose dans son log de messages en invoquant la méthode getmissingmessageids du package log. Une fois cette différence calculée, le site a fait appel à la Servlet GetMessages du site b afin de récupérer les messages manquants. À la fin le site a sauvegarde conjointement avec l URL du site b la dernière opération avec laquelle il a synchronisé avec celuici, afin de faire une requête GetMessaIds à partir d une certaine opération la prochaine fois (pour éviter qu a chaque fois le site b envoie la totalité de ses messages id, ce qui est fastidieux). GetMessages: Comme expliqué dans la partie concernant la Servlet GetMessageIds, cette Servlet est appelée avec un certain nombre de paramètres (des messages id) elle permet de retourner les messages demandés en guise de réponse. ReceiveOutOfSync: Cette Servlet n est pas appelée spécialement par l utilisateur, mais elle est invoquée pendant une opération d anti-entropie, lorsque qu un site a veut récupérer des messages qui ont été supprimés (purgés) par le site b, ce dernier envoie le message (Header http) OutOfSync au site a avec les informations nécessaire pour que le site a puisse télécharger un état cohérent (voir partie suivante). 76

DownloadState: Cette Servlet est appelée dans deux cas: le premier par l utilisateur qui voudrait initialiser sont site en téléchargent un état d un autre site. Le deuxième dans le cas où un site reçoit une notification OutOfSync pendant une opération de. Dans les deux cas il déclenche aussitôt la procédure de téléchargement et d installation d un nouvel état. Un état est tout simplement un fichier compressé qui contient les pages dont le site appelé dispose à un instant donné. Cette Servlet se charge de télécharger et d installer les différents pages, elle permet de créer aussi une nouvelle instance du package algorithm et cela on appelant la méthode bootstrap de ce package. Cette méthode permet donc d initialiser une instance WOOT à partir d un fichier contenant tous les informations nécessaire. CreateState: Il s agit de la Servlet qui est appelée pour créer un état, un état ou State et concrètement un fichier zip qui contient les pages actuelles ainsi que le fichier Pool (queue d exécution d opérations en attentes). La création (la copie, déplacement, et la compression) se fait principalement grâce à des appels au package State et à la classe qui implémente cette interface à savoir StateImpl. Figure 3.34 : Package Servlets (partie 3) 77

78

3.3.5 Package Util Ce package regroupe comme son nom l indique un certains nombre de classes utiles qui réalisent des tâches différentes : création d un identifiant unique (utilisé principalement par WOOT), copie d objets (clone) et une classe qui regroupe quelques méthodes qui permettent d interagir avec les fichiers et réaliser quelques opérations basiques (copie, déplacement, compression, décompression etc. ). 79

Figure 3.35 : Package Util 80

CONCLUSION Pendant ce stage, nous avons démontré le potentiel de l algorithme WOOT face à la gestion des réplications optimiste. Cette démonstration se concrétise par le développement de l application WOOKI. Nous avons aussi mis en place un système de propagation qui permet de coordonner et gérer les éventuelles coopérations répliquées par les sites WOOKI. Notre stage a été très varié du point de vue de nos réalisations, la participation à la phase initiale d un projet fait que la conception a été au centre de notre activité. L analyse des problèmes et la recherche des solutions nous a permis d acquérir de nouvelles expérience de travail dans en équipe. D un point de vue technique, il n y a aucun doute sur le fait que ce stage nous a donné la possibilité d améliorer notre niveau dans plusieurs domaines de programmation. L utilisation approfondie de l architecture J2EE ainsi qu un certain nombre de librairie (Junit, Jlibdiff, httpunit, quartz etc ) a eu un impact positif par rapport à notre capacité à acquérir de nouvelles compétences. D un point de vue plus personnel maintenant, ce stage nous a donné l opportunité d être entouré de personnes très expérimentées, qui n ont pas hésité à partager leurs connaissances avec nous. En effet, on trouve que les discussions et les remarques souvent posées sont très constructives. Nous concluons donc sur le fait que ce stage a été une expérience positive et très enrichissante. 81

BIBLIOGRAPHIE [1] [Gérald Oster, Pascal Urso, Pascal Molli, Abdessamad Imine]. [Real time group editors without Operational transformation]. [ECOO, LORIA], [ 2005-05-01]. [2] [Gérald Oster, Pascal Urso, Pascal Molli, Abdessamad Imine]. [Data Consistency for P2P Collaborative Editing]. [ECOO, LORIA], [2005]. [3] [J.Perira, L.Rodrigues, M..J. Monteiro, R.Oliviera, A-M Kermarrec]. [NEEM : Network(friendly Epidemic Multicast]. [Computer Society], [6-18 Oct. 2003] [4] [Pascal Molli, Gérald Oster]. [Réplication des données]. [ECOO, LORIA], [Novembre 9, 2005] Transitions on Computer Systems], [2, May 1999] [7] [Mohsen Founes]. [Stockage Diférentiel Pour le Prototype Tuamotu]. [ECOO LORIA], [1998]. [8] [P.TH Eugster, R, Guerraoui, S, B, Handurukande, and P. Kouznetsov]. [Lightweight Probabilistic Broadcast]. [ACM Transaction on Computer Systems]. [4, November 2003]. [9] [Gérald Oster, Pascal Urso, Pascal Molli, Abdessamad Imine]. [Édition, collaborative sur réseau pairà-pair à large échelle]. [ECOO LORIA]. [2005] [5] [Alan Demers, Dan Greene, Carl Hauser, Wes Irish, Jhon Larson, Scott Shenker, Howard Sturgis, Dan Swinehart, and Doug Terry]. [Epidemic Algorithms For Replicated Database Maintenance]. [Xerox Palo Alto Research Center], [1987] [6] [Kenneth P. Birman, Mark Hayden, Oznur Ozkasp and Zhen Xiao, Mihai Budiu, and Yaron Minsky]. [Bimodal Multicast]. [ACM 82

INDEX C C++, 2.3 D DIFF, 2.4 E ECOO, 1.2 Extreme Programming, 3.2 J Jlibdiff, 2.4 L LORIA, 1.1 LibreSource, 1.1.6 P Profiling, 3.2 R Refactoring 3.2 S Scalability, 3.1.1 T Tuamotu, 2.4 TTF, 3.3.2 X XML, 2.2.3 W WOOT, 2.2 WOOKI, 3.2 W-caractère, 2.2.4.1 W-ligne, 2.2.4.1 W-string, 2.2.4 82

83