GESTION D'UNE BASE DE DONNEES DOCUMENTAIRE

Transcription

1 GESTION D'UNE BASE DE DONNEES DOCUMENTAIRE PAR Edwige Prisca KOM MBIENGANG Marc FERRADOU Hugo CORDIER 1

2 INTRODUCTION Le but du projet est la mise en place d'une application distribué : une bibliothèque. La bibliothèque est une application de gestion des documents électroniques- de la forme <résumé,contenu>, organisée en un réseau d'agences situées sur différents sites. Ces agences ont une connaissance partielle de la bibliothèque ; elles connaissent leurs voisines ainsi que les documents qu'elles gèrent elles-même. Les agences doivent se faire enregistrer auprès d'un annuaire pour un service donné en lui donnant son adresse IP et le numéro de port sur lequel il fournit ce service. Une agence peut être amenée à servir plusieurs clients. Pour pouvoir communiquer avec une agence, le client doit la localiser. C'est en faisant une demande à l'annuaire qu'il saura quelle est l'agence la plus proche qui lui rendra le service voulu. Le client pourra alors soit : consulter ou retirer un document: ces deux transactions passent forcément par une phase de sélection ajouter un document :c'est une transaction locale au serveur et il y a pas besoin de sélection. La sélection des documents par le client à partir d'un mot clé- est une requête qui doit atteindre toutes les agences du réseau, et cela sans que le client le sache. A la fin de toutes les transactions, le client doit libérer les documents. Cela passe par une validation, où toutes les transactions (ajout/retrait) prennent effet, ou d'invalidation, où il n' y a pas modification des fonds de la bibliothèque. Le client peut aussi libérer des documents qui ne répondent pas à sa demande : c'est la libération anticipée. Lors des transactions de client, si l'agence qui communique directement avec le client ne possède pas les documents voulus, elle le demande à ses voisines. Pour se faire, nous avons pris un certains nombre de décisions en ce qui concerne les choix techniques, d'architecture, et d'algorithme. Cependant, nous avons aussi rencontrés un certains nombre de problèmes que nous avons résolu. 1.CHOIX DE CONCEPTION Pour la conception de notre bibliothèque distribué, nous avons eu à définir notre démarche. En d'autres termes, pour chaque acteur de notre système ( les acteurs sont les agences, les clients et l'annuaire), nous avons pris des décisions d'implémentation. Le langage utilisé pour toutes ces implémentation est le JAVA. Il est vrai que le C++ aurait été aussi efficace que le JAVA, mais nous avions une meilleure connaissance dans ce dernier. De plus, nous avons juger que JAVA possédait des librairies, tels que les sockets, qui sont plus facile de compréhension et d'utilisation. A. ANNUAIRE Dans notre système distribué, l annuaire a pour rôle de donner à chaque client qui fait une requête de sélection sur un service, une adresse IP et le port du serveur le plus proche qui effectue ce service. La figure ci-après exprime l'échange des acteurs client et agences. Edwige Prisca KOM MBIENGANG Marc FERRADOU Hugo CORDIER 2

3 1 Annuaire Serveur 2 Client 3 Serveur Serveur Notre client en 1 demande à localiser le serveur le plus proche qui effectue le service bibliothèque. L annuaire lui répond avec une adresse IP et un port en 2. Le client peut alors faire sa requête en 3. Ceci sous entend que l annuaire connait l ensemble des serveurs qui effectue ce service. Il faut donc que ceux-ci s enregistrent auprès de l annuaire. Notre annuaire ignore les requêtes de localisation des clients tant que tous les serveurs effectuant ce service ne se sont pas enregistré. Une des spécifications de notre annuaire est que celui-ci doit communiquer à chacune des agences qui se sont enregistrés l'ensemble des agences qui lui sont voisines et fournissent le même service qu'elle. Pour plus de facilité, nous avons considéré que l'annuaire avait connaissance de la topologie du réseau. Mais pour se rapprocher de la réalité, qui est que le fait admis plus tôt n'est pas exact, nous avons pensé utilisé un protocole de type RIP(Routing Internet Protocol). Cela aurait permis à chaque serveur de connaître ses voisins sans l'aide de l'annuaire. Chaque serveur pouvant avoir une adresse IP qui varie, nous avons choisi de les identifier par un numéro. Cet identifiant est spécifié lors de l'enregistrement auprès de l'annuaire et ne peut être identique pour deux serveurs différents. Nous partons du principe que les serveurs connaissent leur identifiant et qu'il n'usurpera pas l'identifiant d'un autre. De plus l annuaire connait le nombre de serveurs effectuant chaque service, il sait donc quand un service a finit de s enregistrer. Et enfin, si le service à finit de s enregistrer (tout les serveurs de ce service ce sont enregistrer) alors l annuaire se met à jour. Il va demander pour chaque identifiant si le voisin correspondant à sa topologie effectue le service mis a jour et si c est le cas, il le rajoute dans sa Edwige Prisca KOM MBIENGANG Marc FERRADOU Hugo CORDIER 3

4 table avec pour entrée le service et le voisin qui effectue ce service et ainsi que son port correspondant. Voici une séquence d exécution de notre programme: Lancement du programme Ouverture des menu Une fois le service et la topologie choisi on valide Edwige Prisca KOM MBIENGANG Marc FERRADOU Hugo CORDIER 4

5 Notre mouchard ce lance B. CLIENT Le client est celui qui envoi les requêtes : dépôt et sélection. Ensuite, il pourra faire toutes les transactions tels que retrait, consultation et libération. A sa connexion,le client voit apparaître l'interface suivant : Edwige Prisca KOM MBIENGANG Marc FERRADOU Hugo CORDIER 5

6 Et après appui du bouton «sélection», l'interface est le suivant : C RESEAU D'AGENCES Rappelons que pour pouvoir faire partie de la bibliothèque, une agence doit se faire enregistrer auprès de l'annuaire. C'est le seul moyen pour elle de pouvoir rendre un service. Pour notre implémentation, nous avions le choix entre une topologie en anneau et une topologie quelconque. Ce qui, pour nous, se rapprochait le plus de la réalité et que nous avons choisi, c'est la dernière(réseau quelconque). Les agences sont amenées à coopérer entre elles de façon permanente pour la réalisation des requêtes des clients et pour le répartition du fond de bibliothèque. Le réseau entre les agences est considéré comme non fiable, donc il peut avoir perte de message. Une agence ne connait pas toutes les agences qui fournissent un certain service. Elle connait que ses voisines. Donc, lorsque que le client fait une requête, si l'agence à laquelle il est lié ne peut pas satisfaire cette requête, il l'envoi à ses voisines. Nous avons donc choisi l'algorithme de vague ECHO. Cet algorithme permet à un initiateur d'envoyer ses requêtes à ses voisins et d'attendre ainsi leur réponse. Algorithme de vague : Pour ce qui est de la phase de sélection, nous nous sommes basés sur l'algorithme suivant : --Les variables d'état sont propres à chaque serveur Variables d'état ClientItfSet reqclient ; // interfaces de réception des requêtes des clients sur les agences. // Il peut y avoir plusieurs clients connectés à une agence. CommItfSet reqagence // Interfaces liées aux agences voisines /*Table associative <initiateur,numéro de vague>--><up,waits> où up est le lien depuis lequel est Edwige Prisca KOM MBIENGANG Marc FERRADOU Hugo CORDIER 6

7 arrivé la vague et waits l'ensemble des liens sur lesquels on attend les acquittements. Les opérations sont : insert ((int,int),(commitf,commiftset)) : insertion de la nouvelle vague defined (int,int): renvoi vrai si on a déjà reçu une requête identique extract(int,int) : pour extraire les valeurs de up et waits correspondants à la vague */ Map((int,int), (CommItf,CommItfSet)) waves, wavesvalid; int HL // Horloge logique pour numérotation des vague de l'initiateur /* Liste où seront stockée les documents correspondants au mot clé Les opération sont: add(string) : pour ajouter à la liste les docs free () : pour liberer les docs length() : renvoi la taille de la liste */ Document [] LstSelect; Messages circulant au sein du réseau Select(String motcle); // Message de selection Ack(); // envoyé lors de la réception d'un doublon Ack(int src, int no) // Acquittement de la validation/invalidation struct{ int src; // identité de la source int no; // numéro de la vague String mot ; // mot clé recherché Document Lst ; // Liste regroupant tous les doc correspondants au mot clé } Ack; struct{ int src; // identité de la source int no; // numéro de la vague String mot ; // mot clé recherché } WaveSelect; Règle 1 : Réception d'une requête de selection sur l'interface client de l'initiateur foreach rc in reqclient, rc?select(motcle) && reqagence!=null ==> int no = HL++; waves.insert(<id(), no>,<null,reqagence>); foreach ra in reqagence, ra!waveselect(id(),no,motcle); LstSelect. add(mot); // action qui permet de rechercher dans la base de donnée de // l'agence les docs correspondants au mot clé et de l'ajouter //dans la liste LstSelect Edwige Prisca KOM MBIENGANG Marc FERRADOU Hugo CORDIER 7

8 Règle 2 : Réception de la requête de sélection par une agence terminale exists ra in reqagence, ra?waveselect(src,no,mot) && Card(reqAgence)==1 ==> LstSelect.add(mot); // on renvoi directement l'information à celui de qui vient la vague ra!ack(src,no,mot,lstselect); Règle 3 : 1 ere Réception de la requête de sélection par une agence non terminale exists ra in reqagence, ra?waveselect(src,no,mot) && Card(reqAgence)!=1 &&!waves.defined(<src,no>)==> LstSelect.add(mot); waves.insert(<src,no>,<ra,reqagence-{ra}>); foreach ra1 in reqagence-{ra}, ra1! WaveSelect(src,no,mot); Règle 4 : réception d'un doublon par un non terminal exists ra in reqagence, ra?waveselect(src,no,mot) && Card(reqAgence)!=1 && waves.defined(<src,no>)=> ra!ack(); Règle 5 : Réception d'un Acquittement exists ra in reqagence, ra?ack(src,no,mot,lstselect) ==> <up,waits> = waves.extract(<src,no>); waits-={ra}; _LstSelect = LstSelect.ConcatWith(this); // concaténation avec la liste locale à l'agence if(vide(waits) && src!=id()){ // c'est pas l'initiateur de la vague up! Ack(src,no,mot,_LstSelect); } elsif (vide(waits && src==id()) // Inititeur // Fin de la vague int nbre_doc = _LstSelect.length(); } else { // mise à jour de la table associative waves.insert(<src,no>,<up,waits>; } En bref, Le client envoi sa requête avec un mot clé. Le serveur qui reçoit la requête devient initiateur. Il récupère dans sa propre liste LstSelect, la liste des documents dont le résumé contient le mot clé. Puis il envoi a tous ses voisins la requête de sélection avec le mot clé, son id pour le retour (acquittement). Chaque serveur qui reçoit la requête de l'initiateur fait passer la requête a ses voisins. Et ceci jusqu'à la dernière agence. Quand la vague arrive au bout, la dernière agence envoi un acquittement avec l'id de l'initiateur, le numéro de la vague, sa liste contenant les résumé des différents documents où il a trouvé le mot clé. Quand celui au dessus là reçoit, il concatène sa liste avec celle reçu et envoi l'acquittement au dessus. Et ainsi de suite jusqu'à l'initiateur. Ce dernier peut alors répondre au client en affichant les résumé des différents documents qu'il a reçu. Cet algorithme est aussi utilisé pour les phase de validation/invalidation. A la différence que on demandera aux agences de rendre disponible tous les documents qui ont pas été retiré. Edwige Prisca KOM MBIENGANG Marc FERRADOU Hugo CORDIER 8

9 En ce qui concerne les transactions de retrait et de consultation, l'algorithme est différent. Lorsque le client dépose l'une de ses requêtes, si l'initiateur peut y répondre, il le fait. Sinon, il envoi la demande aux voisins. Là, il s'agit d'une vague. Pour le dépôt, nous considérons qu'il se fait de prime abord que cela se fait en local. Ensuite, entre les agences, il aura équilibrage de charge. Ci dessous est représenté l'interface du serveur. Dans le champ Identifiant, le serveur rentre un entier. Puis charger la liste des document qu'il possède. La représentation des documents est sous forme d'xml. Ensuite ajouter le service que l'on veut(exemple Bibliothèque) en oubliant pas le port. Il faut bien faire attention au fait que les numéros de port pour deux serveurs différents soient différents. Si le numéro d'identification existe déjà, le serveur ne se connecte pas. Il faut donc relancer un serveur. Et recommencer depuis le début. Après s'être enregistré, le serveur reste en attente jusqu'à ce que tous les serveurs fournissant le même service que lui se sont enregistré. 2.PROBLEMES RENCONTRES/SOLUTIONS PROPOSEES Pour que notre bibliothèque soit plus réaliste, il aurait fallu que lorsque le dernier serveur d'un service s'enregistre, il aux autres la Pour que les serveurs puissent s enregistrer et que le dernier serveur enregistrer signale au autre que l enregistrement est finit il a fallut faire communiquer des threads ensemble. Nous ne l avions jamais implémenter, la solution que nous avons trouvé est de faire un tableau synchronisé (CopyOnWriteArrayList) où tout les thread communique avec. De même le concept de transaction a été compliquer à mettre en place. Notre solution est expliquer plus loin? Nous ne savions pas trop comment faire pour les conditions initiales, protocole de routage des serveur? Nous avons choisit que l annuaire connaissait la topologie et de ne pas mettre en place de protocole de routage. De plus pour avoir une vague il fallait que tout les serveur puisse communiquer avec leur voisin quelque soit le service. Nous avons choisit de les relié via un port Edwige Prisca KOM MBIENGANG Marc FERRADOU Hugo CORDIER 9

10 bien connu. Edwige Prisca KOM MBIENGANG Marc FERRADOU Hugo CORDIER 10