03 ServeurArchivage - DocumentDeConception

Serveur d'Archivage 2007 Document de conception
Document de conception
Serveur d'archivage
Projet ISL 2006/2007
Type du document Auteur(s) Date de cration Domaine de diffusion Valid par
Conception : spcifications techniques, analyse UML. Eric Bouladier, Danielle Drillon, Damien Grasselino, Ala Eddine Haouas, Yoann Pantic 28/03/2007 illimit Equipe
Versions 1.0 1.1
Date 28/03/2007 29/03/2007
Auteur(s) Eric Bouladier Eric Bouladier
Modifications Assemblages des diffrentes contributions Corrections erreurs assemblage
1/87
2/87
Table des matires

1.Description du projet Serveur d'Archivage.......................................................................................................... 6 2.Ralisation des diagrammes................................................................................................................................. 6 3.Cas d'utilisation.................................................................................................................................................... 7 3.1.Remarques sur les cas d'utilisation............................................................................................................... 7 3.2.Rle des utilisateurs...................................................................................................................................... 7 3.3.Visiteur......................................................................................................................................................... 8 3.3.1.Rechercher un document en passant par les mtadonnes....................................................................8 3.3.2.Consulter un document......................................................................................................................... 9 3.3.3.S'authentifier......................................................................................................................................... 9 3.4.Dposant..................................................................................................................................................... 10 3.4.1.Saisir les mtadonnes........................................................................................................................ 10 3.4.2.Uploader le(s) fichier(s) d'un document............................................................................................. 11 3.4.3.Changer les droits d'accs d'un document dpos...............................................................................11 3.4.4.Changer les formats de diffusion d'un document dpos....................................................................12 3.5.Bibliothcaire..............................................................................................................................................13 3.5.1.Ajouter un type de document.............................................................................................................. 13 3.5.2.Supprimer un type de document......................................................................................................... 14 3.5.3.Ajouter des mtadonnes pour un type de document......................................................................... 14 3.5.4.Export d'un document (fichiers et/ou mtadonnes)...........................................................................15 3.6.Administrateur............................................................................................................................................ 16 3.6.1.Paramtrer l'application...................................................................................................................... 16 4.Diagrammes de navigation................................................................................................................................. 17 4.1.Remarques.................................................................................................................................................. 17 4.2.Page d'accueil : point d'entre du serveur d'archivage................................................................................17 4.3.Authentification.......................................................................................................................................... 18 4.4.Recherche de documents............................................................................................................................ 19 4.5.Consultation de document.......................................................................................................................... 20 4.6.Administration............................................................................................................................................ 21 4.6.1.Ajout d'un type de document.............................................................................................................. 21 4.6.2.Modification d'un document (fichier)................................................................................................. 22 4.6.3.Modification d'un document (mtadonnes).......................................................................................23 4.6.4.Gestion des mtadonnes pour un type de document......................................................................... 24 4.7.Dpt d'un document.................................................................................................................................. 25 4.7.1.Avec le rle dposant ....................................................................................................................25 4.7.2.Avec le rle bibliothcaire ............................................................................................................ 26 5.Diagrammes de composants............................................................................................................................... 27 5.1.Vision d'ensemble des composants de l'application................................................................................... 27 5.2.La couche DAO.......................................................................................................................................... 28 5.3.La couche de prsentation.......................................................................................................................... 29 5.4.Le package Workflow.................................................................................................................................30 6.Diagrammes de squence................................................................................................................................... 31 6.1.Introduction.................................................................................................................................................31 6.2.Authentification d'un utilisateur................................................................................................................. 31 6.3.Fonction de recherche.................................................................................................................................32 3/87
Serveur d'Archivage 2007 Document de conception 6.3.1.Recherche parmi tous les documents.................................................................................................. 33 6.3.2.Recherche par type de document........................................................................................................ 34 6.3.3.Recherche par mtadonnes................................................................................................................36 6.4.Dpt d'un document.................................................................................................................................. 37 7.Diagrammes d'activits.......................................................................................................................................39 7.1.Ajouter et/ou modifier mtadonnes et/ou fichiers d'un document............................................................ 39 7.2.Ajout d'un nouveau document.................................................................................................................... 40 7.3.Modification d'un document existant..........................................................................................................41 7.4.Export d'un document dans un format cible............................................................................................... 42 8.Couche mtier, les diffrents compartiments..................................................................................................... 43 8.1.Les packages non dtaills..........................................................................................................................43 8.1.1.Le package Business........................................................................................................................... 43 8.1.2.Le package common........................................................................................................................... 44 8.1.3.Le package util.................................................................................................................................... 45 8.1.4.Le package workflow..........................................................................................................................46 8.2.Le traitement des archives.......................................................................................................................... 48 8.2.1.Objet....................................................................................................................................................48 8.2.2.Principales activits externes.............................................................................................................. 48 8.2.3.Principales activits internes...............................................................................................................48 8.3.Les mtadonnes dynamiques.................................................................................................................... 53 8.3.1.Principe............................................................................................................................................... 53 8.4.Les caractristiques des mtadonnes : le mtamodle......................................................................... 53 8.5.Un fichier xml trous : le modle....................................................................................................54 8.6.Implmentation Java.............................................................................................................................. 55 8.7.La recherche de documents........................................................................................................................ 57 8.7.1.Principe............................................................................................................................................... 57 8.7.2.Critres de recherche...........................................................................................................................57 8.7.3.Implmentation Java........................................................................................................................... 58 9.La couche d'accs aux donnes.......................................................................................................................... 59 9.1.Donnes persistes et choix technologiques...............................................................................................59 9.2.Diagramme de classes.................................................................................................................................60 9.2.1.L'interface Idao et son implmentation...............................................................................................60 9.2.2.Les classes DaoFS et DaoXML.......................................................................................................... 61 9.3.Articulation des diffrentes couches...........................................................................................................62 9.3.1.Schma en couches :........................................................................................................................... 62 9.4.Structure du stockage dans la base de donnes eXist................................................................................. 63 9.5.Ajout Mise jour des documents............................................................................................................... 66 9.6.Ajout et mise jour des types de donnes.................................................................................................. 66 9.7.Requtage dans eXist..................................................................................................................................66 10.La couche de prsentation :.............................................................................................................................. 68 10.1.L'arborescence du module ServeurArchivageWeb...................................................................................69 10.2.Le package archivage.web et Spring MVC.............................................................................................. 69 10.2.1.Le contrleur principal dispatchServlet............................................................................................ 70 10.2.2.Les contrleurs secondaires.............................................................................................................. 72 10.2.3.Les contrleurs basiques ............................................................................................................. 73 10.2.4.Les contrleurs de formulaires..........................................................................................................74 10.2.5.Notre intercepteur d'authentification.................................................................................................78 4/87
Serveur d'Archivage 2007 Document de conception 10.2.6.Autres composants de Spring............................................................................................................80 10.2.7.Liste des couples action-contrleur...................................................................................................81 10.2.8.Filtre de pages JSP............................................................................................................................ 82 11.Diagramme de dploiement..............................................................................................................................83 12.Annexe 1 : Recherches technologiques............................................................................................................85 12.1.Xstream.....................................................................................................................................................85 12.1.1.Objectif : le stockage des mtadonnes en XML..............................................................................85 12.1.2.La librairie XStream.............................................................................................................................. 85 12.1.3.Problmes rencontrs.............................................................................................................................85 12.2.Spring........................................................................................................................................................86
5/87
1. Description du projet Serveur d'Archivage

Dans l'Universit il y a toute une littrature (littrature grise) qui n'est jamais diffuse officiellement : il s'agit des thses, des cours des enseignants, des mmoires, des rapports de projets, des rapports techniques, des preprints d'article. Ceci est une richesse de l'Universit et le SCD (Service commun de la Documentation) souhaite mettre en place l'Universit de la Mditerrane, un systme permettant de l'exploiter. Voici les objectifs du projets :
Dfinition de formats pour le dpt de documents : il s'agit de mtadonnes pour la description du document et des fichiers joints. Ces mtadonnes (sous forme xml) dcrivent la nature du document, son ou ses auteurs, les responsables du contenu, son format informatique et bien d'autres choses. Systme de dpt automatique par le biais de formulaires qui remplissent les meta donnes. Stockage des documents. Diffusion de l'information en utilisant ces meta-donnes et les normes existantes. Recherche d'information sur ce serveur.
2. Ralisation des diagrammes

Nous avons utilis le logiciel BOUML (http://bouml.free.fr) pour modliser l'ensemble du projet. C'est un logiciel libre, multiplateforme et complet qui supporte l'UML 2.0. Il est capable de gnrer, entre autres, du code Java et de faire du reverse engineering. Par ailleurs, chose importante, il est remarquablement stable. Stabilit qui fait dfaut d'autres logiciels que nous avons essays tels que Umbrello ou Poseidon. Autre avantage, BOUML ne ncessite pas de cl de dverrouillage, limite ou pas dans le temps, comme c'est le cas pour Poseidon ou la version d'essai de Rational Rose. Enfin, il permet de travailler en mode collboratif.
6/87
3. Cas d'utilisation
3.1. Remarques sur les cas d'utilisation
Les cas d'utilisation sont accompagns d'une description textuelle dont voici une description.

prconditions : il s'agit des conditions qui doivent imprativement tre remplies pour excuter le cas d'utilisation dcrit. scnario nominal : c'est un scnario qui se droule sans erreur. enchanements alternatifs : ils rsultent du choix de l'acteur au moment de la ralisation du cas nominal. enchanements d'erreur : les exceptions qui peuvent se produirent au moment de l'excution du scnario nominal ou d'un des enchanements alternatifs. postconditions : elles reprsentent ce qui se passe sur le systme une fois le scnario nominal ralis.
3.2. Rle des utilisateurs

Les rles dcrits ci-dessous sont ceux utiliss dans le cahier des charges.

Bibliothcaire : personnes en charge de l'application au Service Commun de Documentation. Administrateur : personnes en charge des systmes informatiques sur lesquels est dploy l'application. Dposant : personnes en charge du dpt des documents dans le systme. Exemples : tudiants,doctorants, enseignants-chercheurs, encadrant ou secrtariat du dpartement du dposant... Visiteur : personnes anonymes ou authentifies ayant accs aux documents entreposs.
7/87
3.3. Visiteur
3.3.1. Rechercher un document en passant par les mtadonnes

a. Prconditions
Pour mettre en oeuvre ce cas d'utilisation, au moins un type de document doit tre prsent dans l'application et des mtadonnes doivent tre associes ce type.
b. Scnario nominal
1. L'internaute choisit un type de document. 2. L'internaute cre sa requte (cf. Cahier des Charges). 3. Le systme affiche une liste des documents correspondants aux critres saisis et accessibles l'internaute qui a lanc la recherche.
c. Enchanements alternatifs
Si l'internaute ne choisit pas de type de document pour affiner sa recherche, les critres sont limits aux mtadonnes gnriques (Dublin Core).
d. Enchanements d'erreur
Si les critres saisis sont errons ou mal remplis par l'internaute, le cas d'utilisation se termine en erreur : la recherche n'est pas effectue.
8/87
Serveur d'Archivage 2007 Document de conception 3.3.2. Consulter un document

a. Prconditions
Le document consult doit tre accessible l'internaute.

b. Scnario nominal
1. L'internaute demande la consultation du document (clic sur un lien d'affichage). 2. Si le document original n'est pas encore converti vers le format de diffusion demand, la conversion est effectue. 3. Le document ainsi que ses mtadonnes sont prsents au format xhtml.
L'internaute peut demander le tlchargement du document au format PDF.

d. Postconditions
Les statistiques de consultation du document sont mises jour. 3.3.3. S'authentifier L'authentification est ralise si les informations saisies par l'internaute anonyme correspondent une paire login/mot de passe valide dans l'annuaire LDAP de l'universit. Dans ce cas, l'internaute anonyme se voit attribuer le rle correspondant son compte : dposant, bibliothcaire, administrateur ou simple utilisateur authentifi.
9/87
3.4. Dposant
3.4.1. Saisir les mtadonnes

a. Prconditions
Un jeu de mtadonnes minimal doit tre associ au type de document dpos.

b. Scnario nominal
1. Le dposant saisit les mtadonnes dans le formulaire. Il prsente toutes les mtadonnes associes actuellement au type de document dpos. 2. Le systme vrifie la validit des informations saisies. 3. La saisie des mtadonnes est termine.
Le dposant peut choisir de rentrer les mtadonnes par un fichier plutt que par le biais du formulaire.
Les mtadonnes saisies ou envoyes par le dposant ne sont pas valides. Les mtadonnes ne sont pas enregistres.
e. Postconditions
Les mtadonnes sont associes au document et enregistres dans la base de donnes. Le document peut tre 10/87
Serveur d'Archivage 2007 Document de conception trouv par le moteur de recherche. 3.4.2. Uploader le(s) fichier(s) d'un document
a. Prconditions
Le type de document est autoris en dpt : au moins un type de fichier est accept en entre.
b. Scnario nominal
1. Le dposant parcourt sons systme de fichiers jusqu' trouver le fichier correspondant et le slectionne. 2. Le systme vrifie que le type de fichier est autoris pour ce type de document. 3. L'upload de fichier se termine avec succs.
Si le dposant veut associer plusieurs fichiers son document, l'opration est rpte.
Si le fichier n'est pas dans un type autoris pour ce type de document, l'upload est refus. Le cas d'utilisation se termine en erreur.
e. Postconditions
Le fichier est envoy sur le systme de fichiers et archiv. 3.4.3. Changer les droits d'accs d'un document dpos
a. Prconditions
Le dposant doit tre le mme que celui qui a dpos le document.

b. Scnario nominal
1. Le dposant choisit un document. 2. Le dposant modifie les droits d'accs au document (fichiers et/ou mtadonnes) : restriction de la diffusion en fonction de date (temporisation) ou pour des utilisateurs particuliers (groupe ou personne). La diffusion du document peut tre stoppe en intgralit : dans ce cas, le document n'est plus consultable par le biais du serveur d'archivage. 3. Le dposant valide sa saisie. 4. Le systme vrifie que la saisie est correcte.
Le dposant peut annuler l'opration tant qu'il n'a pas valid sa saisie.
Si les informations saisies par le dposant ne sont pas conformes, les droits d'accs du document en sont pas changs.
11/87

e. Postconditions
Les droits d'accs au document sont mis jour et pris en compte par l'application. 3.4.4. Changer les formats de diffusion d'un document dpos
a. Prconditions
Le dposant doit tre le mme que celui qui a dpos le document.

b. Scnario nominal
1. Le dposant choisit un document. 2. Le dposant slectionne les formats de diffusion de son document. 3. Le dposant valide sa saisie.
Le dposant peut annuler l'opration tant qu'il n'a pas valid sa saisie.
d. Postconditions
Les formats de diffusion du document sont mis jour et pris en compte par l'application : le document n'est plus accessible qu'aux formats restant slectionns. Si aucun format de diffusion ne subsiste aprs la modification, le contenu du document n'est plus accessible sur le serveur d'archivage.
12/87
3.5. Bibliothcaire
3.5.1. Ajouter un type de document

a. Prconditions
Le type de document ne doit pas dj tre prsent dans l'application.

b. Scnario nominal
1. Le bibliothcaire saisit le nom du nouveau type de document. 2. Le bibliothcaire saisit les caractristiques techniques de ce nouveau type de document : types de fichiers accepts en entre, ... 3. Les mtadonnes basiques sont ajoutes au type de document. 13/87
Serveur d'Archivage 2007 Document de conception 4. Le bibliothcaire peut ajouter des mtadonnes au type de document (voir cas d'utilisation ajouter des mtadonnes pour un type de document )
c. Postconditions
Le nouveau type de document est enregistr et utilisable dans l'application. 3.5.2. Supprimer un type de document
a. Prconditions
Aucun document de ce type ne doit tre prsent sur le serveur d'archivage.

b. Scnario nominal
1. Le bibliothcaire choisit un type de document supprimer. 2. Le bibliothcaire valide son choix. 3. L'application vrifie qu'aucun document de ce type n'est prsent dans le serveur d'archivage.
Le bibliothcaire peut annuler l'opration tant que son choix n'est pas valid.
d. Postconditions
Le type de document n'est plus prsent dans l'application. 3.5.3. Ajouter des mtadonnes pour un type de document
a. Scnario nominal
1. Le bibliothcaire choisit le type de document modifier. 2. Le bibliothcaire saisit les caratristiques de la mtadonne ajouter : nom, type, caractre obligatoire ou optionnel... 3. Le systme vrifie que les donnes sont valides.
b. Enchanements alternatifs
Le bibliothcaire peut dcider de mettre jour l'ensemble des documents dj prsents sur le systme. La mtadonne ajoute pour le type de document sera ajoute aux mtadonnes dj prsentes pour les documents concerns.
c. Postconditions
La mtadonne est associe au type de document.
14/87
Serveur d'Archivage 2007 Document de conception 3.5.4. Export d'un document (fichiers et/ou mtadonnes)
a. Scnario nominal
1. Le bibliothcaire choisit le document qu'il veut exporter. 2. Le bibliothcaire choisit le type d'export souhait (STAR ou OAI-PMH) et ce qu'il veut exporter (fichier ou mtadonnes). 3. Le systme prpare le document tre reu par les tiers : conversion des mtadonnes et du fichier s'il y a lieu.
b. Enchanements alternatifs
Le bibliothcaire peut annuler son opration tout moment. Dans ce cas, le document ne sera pas prt pour une exportation.
1.1.1.1 Postconditions
Le document est prt tre export.
15/87
3.6. Administrateur
3.6.1. Paramtrer l'application

a. Scnario nominal
1. L'administrateur entre les nouveaux paramtres de l'application : adresse de l'annuaire LDAP, chemin des repertoirse d'archivage, paramtres de la base de donnes... 2. L'application vrifie que les paramtres sont corrects.
b. Enchanements d'erreur
Si les paramtres ne sont pas corrects, l'application conserve les anciens paramtres.
c. Postconditions
L'application est paramtre.
16/87
4. Diagrammes de navigation
4.1. Remarques
Nous avons utilis les diagrammes d'tats pour reprsenter les diagrammes de navigation. Chaque tat possde un strotype spcifique aux pages web. page : ce strotype correspond une vue de l'application. Il s'agit de pages jsp. exception : il s'agit de pages d'erreur. action : il s'agit d'une action simple ralise par l'internaute. connector : dans le but de faciliter la lecture des diagrammes de navigation, les connectors sont utiliss. Ils permettent de diviser les diagrammes en sous-diagrammes et de les relier entre eux.
4.2. Page d'accueil : point d'entre du serveur d'archivage
17/87
4.3. Authentification
18/87
4.4. Recherche de documents
19/87
4.5. Consultation de document
20/87
4.6. Administration
4.6.1. Ajout d'un type de document
21/87
Serveur d'Archivage 2007 Document de conception 4.6.2. Modification d'un document (fichier)
22/87
Serveur d'Archivage 2007 Document de conception 4.6.3. Modification d'un document (mtadonnes)
23/87
Serveur d'Archivage 2007 Document de conception 4.6.4. Gestion des mtadonnes pour un type de document
24/87
4.7. Dpt d'un document

4.7.1. Avec le rle dposant Il s'agit d'un autoarchivage. Au minimum, les mtadonnes obligatoires pour le type de document dpos doivent tre saisies par l'utilisateur.
25/87
Serveur d'Archivage 2007 Document de conception 4.7.2. Avec le rle bibliothcaire Le bibliothcaire peut dposer un document dans le serveur d'archivage sans en saisir les mtadonnes.
26/87
5. Diagrammes de composants
5.1. Vision d'ensemble des composants de l'application
Ce diagramme a pour but d'exposer une vision synthtique des relations entre les packages de l'application.Ces packages sont ceux dcrits dans les diagrammes de classes (plus loin dans ce document). Les diffrentes couches auxquelles ils appartiennent sont aussi indiques. Chaque package fait l'objet d'un diagramme de composant dtaill, sauf archive.metadata et archive.business pour lesquels un tel diagramme ne se justifie pas.
27/87
5.2. La couche DAO
La couche d'accs aux donnes prend en charge l'accs la base de donnes eXist pour les donnes au format XML, ainsi que l'accs aux archives contenant les fichiers dposs. C'est aussi elle qui s'occupe de compresser et dcompresser les archives.
28/87
5.3. La couche de prsentation
Ce diagramme prsente les dpendances en cascade de la couche prsentation et prcise les versions des composants. En particulier, le respect de la version du composant common.logging est important pour rsoudre un problme d'incompatibilit avec log4j.
29/87
5.4. Le package Workflow
Le package workflow assure la transformation des documents d'un format dans un autre. Il prend aussi en charge la dcompression des fichiers fournis sous forme d'archives. Pour raliser ces diffrentes tches, il utilise des API ou des commandes systme.
30/87
6. Diagrammes de squence
6.1. Introduction
Les diagrammes de squence suivant montrent les interactions et les collaborations entre les diffrents objets dans des cas particuliers. Ils permettent de bien illustrer comment les utilisateurs vont interagir avec l'application.
6.2. Authentification d'un utilisateur
Si un utilisateur veut s'authentifier, il demande la page de connexion auprs du contrleur 'HomeController'. Une fois le login et le mot de passe rentrs le contrleur vrifie si l'utilisateur est prsent sur l'annuaire LDAP, il en rsulte deux possibilits : Soit l'utilisateur est prsent dans l'annuaire et le contrleur renvoie la page de l'utilisateur authentifi. Soit l'utilisateur n'est pas prsent dans l'annuaire et le contrleur renvoie un message d'erreur.
31/87
6.3. Fonction de recherche
L'utilisateur demande une recherche auprs du contrleur 'SearchController', celui-ci renvoie la liste des recherches qu'il est possible d'effectuer. Il y a trois types de recherche diffrents : La recherche en affichant tous les documents contenus dans la base de donnes XML. La recherche par type de document. La recherche en utilisant une saisie de mtadonnes.
32/87
Serveur d'Archivage 2007 Document de conception 6.3.1. Recherche parmi tous les documents
La recherche parmi tous les documents revient faire une liste des documents se trouvant dans la base de donnes XML. La demande d'affichage est traite par le contrleur 'SearchController' qui va interroger l'interface 'Business' et va renvoyer une ArrayList avec la rponse de la requte. Elle contient la liste des documents prsent dans la base de donnes XML, qui sera affiche dans la vue 'Search.form'.
33/87
Serveur d'Archivage 2007 Document de conception 6.3.2. Recherche par type de document
La recherche par type de document est d'abord une demande des diffrents types de documents existants auprs du contrleur 'SearchController' qui va interroger l'interface 'Business' pour renvoyer dans une ArrayList les diffrents types de documents contenus dans la base de donnes XML. L'utilisateur possde deux choix ds lors qu'il voit la liste des types de document : Soit il peut faire une recherche par saisie de mtadonnes pour affiner sa recherche. Soit il peut afficher tous les documents d'un type dans une vue.
34/87

a. La liste des types de document
Ce diagramme montre l'tape qui affiche la liste des documents d'un type. L'utilisateur ayant demand la liste passe par le contrleur 'SearchController' qui va alors demander l'interface 'Business' de lui fournir la liste de tous les documents d'un type. Cette liste sera renvoye l'utilisateur qui pourra effectuer sa recherche.
35/87
6.3.3. Recherche par mtadonnes
L'utilisateur rentre dans le champ adquat la ou les mtadonnes qui symbolisent l'essence du document qu'il recherche. Le contrleur 'SearchController' traite la demande et envoie une requte l'interface 'Business' qui va renvoyer une ArrayList avec un rsultat pertinent sur la recherche de l'utilisateur. Le contrleur se charge d'appeler la vue avec la liste des documents correspondants aux mtadonnes saisies.
36/87
6.4. Dpt d'un document

Lors d'un dpt de document, l'utilisateur authentifi demande la page de dpt. Cette demande est prise en charge par le contrleur 'UploadController'. Ce dernier envoie une requte l'interface 'Business' qui se charge de rcuprer la liste des types de document qui peuvent tre dposs. L'utilisateur choisit alors le type du document qu'il va dposer et le contrleur renvoie le formulaire des mtadonnes statiques que l'utilisateur doit remplir pour effectuer son dpt. Une fois le formulaire soumis, le contrleur vrifie que les mtadonnes obligatoires sont correctement renseignes. Dans le cas o l'une des mtadonnes obligatoires venait tre manquante, le contrleur renverrait nouveau le formulaire des mtadonnes statiques, sinon le formulaire des mtadonnes dynamiques est envoy par le contrleur. Encore une fois, aprs soumission du dernier formulaire, le contrleur vrifie sa validit, et donc, soit il y a une erreur et alors le formulaire des mtadonnes dynamiques est renvoy, soit le formulaire est valide auquel cas le contrleur renvoie cette fois le formulaire des mtadonnes techniques,dont le droulement reste identique aux autres. Quand le dernier formulaire est valid, le contrleur renvoie la page pour l'envoi des fichiers constituant le document. Une fois le chemin d'accs au document donn, les mtadonnes saisies ainsi que les fichiers sont envoys par le contrleur l'interface 'Business' qui pourra renvoyer une page de succs si aucune erreur n'est renvoye, ou bien redemander l'envoi du fichier dans le cas contraire.
37/87
38/87
7. Diagrammes d'activits
7.1. Ajouter et/ou modifier mtadonnes et/ou fichiers d'un document
Voici une activit gnrique pour procder la fois l'ajout des mtadonnes et/ou des fichiers un nouveau document ou bien les remplacer ou les ajouter dans un document existant. Cette mthode, suppose que l'on a pralablement rcupr les fichiers de mtadonnes XML et les fichiers constituant le document, avec pour chaque fichier, l'action effectuer (ajout, modification, suppression).
Cette activit va tre appele dans les activits suivantes.
39/87
7.2. Ajout d'un nouveau document

Voici, d'un point de vue gnral, l'ajout d'un nouveau document au serveur d'archivage. Dans la premire action, nous voyons la soumission des mtadonnes et des fichiers au contrleur. Cette action peut se comprendre et s'implmenter au choix de deux faons :

Tout est soumis avec une requte unique. Si les formulaires sont trop importants ou sans rapport les uns avec les autres, alors il sont soumis les uns aprs les autres, par tapes.
Quel que soit la nature de l'interaction avec le dposant, on suppose avoir les fichiers mtadonnes et fichiers la fin du processus de dpt. De plus, chaque action peut dclencher une erreur. Pour des raisons de lisibilit, cela n'est pas reprsent. En fait, chaque erreur aboutit l'action envoyer un message de confirmation , permettant de confirmer qu'une erreur est survenue. L'activit Ajouter et/ou modifier... est celle dtaille ci-dessus (symbole fourchette).
40/87
7.3. Modification d'un document existant

La modification d'un document existant est presque similaire l'ajout. Notons l'ajout du bean fichiers, il s'agit d'un formulaire reprsentant la liste de fichiers du document et les actions entreprendre pour chaque fichier (ajout, modification, suppression). De plus, nous appelons la mme activit Ajouter et/ou supprimer... pour traiter le document.
41/87
7.4. Export d'un document dans un format cible

Cette activit est effectue lorsqu'un client demande une vue du document dans un certain format. Nous grons un systme de cache. Si l'export existe, le fichier existant est renvoy, sinon il est gnr. Notons que cela concerne les formats PDF et HTML, mais que cela peut galement concerner l'export des mtadonnes.
42/87
8. Couche mtier, les diffrents compartiments

8.1. Les packages non dtaills
8.1.1. Le package Business Le package business contient l'interfaces mtier essentielles l'application. C'est l'interface IServeurArchivage qui offre ses services la couche de prsentation dcrite plus loin dans le document.
43/87
8.1.2. Le package common Il contient les classes utilises par les diffrentes couches.
a. La classe Base
Cette classe regroupe les 15 lments standard Dublin Core (version Simple), 5 mtadonnes ajoutes par les clients (exigence dans le cahier des charges) puis 6 mtadonnes techniques. Ces lments forme l'ensemble des mtadonnes dites statiques pour la description d'un document dans notre application. Les attributs de la classe Base se divisent en deux groupes : les attributs uniques (ayant une seule valeur) et les attributs multiples (possdant ventuellement plusieurs valeurs). Par exemple, l'attribut dcTitle (titre du document) a une unique valeur. Par contre, les mtadonnes d'un document peuvent contenir plusieurs auteurs enregistres dans l'attribut cdCreators (de type ArrayList). Un minimum de ces mtadonnes doivent ncessairement tre communiqus lors du dpt d'un document. Ces mtadonnes sont :

titre auteurs 44/87

sujet description date (de cration)
Les mtadonnes exiges par les clients enrichissent celles du Dublin Core et comblent un manque pour le renseignement des documents qui seront archivs avec notre application. Les mtadonnes techniques sont le type, l'identifiant et la date de dpt du document, l'identit du dposant et enfin le nom du fichier principal et des fichiers secondaires.
b. La classe Document
Il s'agit de notre reprsentation d'un document avec toutes les mthodes pour lire, pour ajouter et pour supprimer des informations (mtadonnes et fichiers).
c. La classe Critere
Cette classe reprsente un critre de recherche que l'utilisateur de l'application renseigne dans la page de recherche de document. L'attribut caseSensitive renseigne si la valeur du critre (attribut valeurCritere) doit respecter la contrainte casse ou non.
d. La classe Type
Cette classe regroupe les mtadonnes associes un type de document :

nom du type. libelle du type. le nom du schema. les types mimes associs ce type.
45/87
8.1.3. Le package util. Il contient les classes utilitaires. En particulier des parseurs gnriques assurant le marshalling et l'unmarshalling.
a. La classe XMLToBeans
La classe BeansToXML se charge de convertir un document XML en une liste de Java Bean de la classe ResultClass.
b. La classe BeansToXML
La mthode toXML(ArrayList<Object>) se charge de convertir une liste de Beans de la classe indique au constructeur en un document XML sous forme de chane de caractres. 8.1.4. Le package workflow. Ce package contient les classes ncessaires au traitement des documents ouverts.
46/87
a. La classe DocumentTypeAnalyser
DocumentTypeAnalyser analyse l'tat et le type courant du document. Cette classe permet de guider la prpartion des fichiers d'une part et l'export d'autre part. Par exemple, si le dposant poste une archive ZIP, getType() retourne zip , et l'on sait qu'il faut remplacer le ZIP par son contenu. Si l'on doit exporter le document vers PDF et que getType() retourne latex , on sait qu'il faut appliquer la stratgie implmente par LatexToPDFStrategy. Dans la version de base, nous supportons deux formats : PDF, ZIP contenant un travail LaTeX et travail LaTeX. Le travail LaTeX est un ensemble de fichiers habituellement impliqus dans un document LaTeX (*.tex, *.bib, *.fig, *.eps, *.png...).
b. L'interface IExportDocumentStrategy et ses implmentations
IExportDocumentStrategy symbolise un traitement exportant le document dans un format prcis. Cela rend extensible l'application n'importe quels formats de dpt et d'export. PDFToHTMLStratey, LatexToHTMLStrategy, LatexToPDFStrategy sont les implmentations d'exports de la version de base.
c. L'interface IPrepareDocumentFilesStrategy
IPrepareDocumentFilesStrategy symbolise un traitement faisant passer un document dont les fichiers ne sont pas directement exploitables (archive ZIP), en un document dont les fichiers sont sous une forme normalise, exploitable et prenne. 47/87
8.2. Le traitement des archives

8.2.1. Objet Dans le serveur d'archivage, les activits se situent plusieurs niveaux :

Externe : ce qui est fait par les utilisateurs. Interne : ce qui est fait par le systme.
Cette partie spcifie comment raliser les activits internes.
8.2.2. Principales activits externes cf. partie sur les cas d'utilisation. 8.2.3. Principales activits internes
a. Recevoir les fichiers et les mtadonnes et les transformer en archive
Cette activit fait suite au dpt de document qu'effectue le dposant. Elle est entirement automatique. Les erreurs de traitement interrompent l'activit et envoient un message l'utilisateur. Durant cette activit, le document trait passe par une succession d'actions rsumes ci-dessous : 1. 2. 3. 4. 5. 6. 7. Valider les fichiers entrs [1] Valider les mtadonnes entres [11] Srialiser les mtadonnes sous forme normale [12] Indexer les mtadonnes sous forme normale dans le SGBD [13] Normaliser les fichiers entrs [2] Archiver les fichiers normaliss et les mtadonnes normalises [3] Hacher l'archive et enregistrer le hachage [41]
Dfinitions Mtadonnes sous forme normale : ensemble de mtadonnes (TEF, Dublin Core, techniques) sous la forme dans laquelle l'application le traite : un fichier XML.
48/87
Fichiers sous forme normales : fichiers ventuellement retraits (encodage des accents, nom normaliss, DTD plus rcentes...), tels qu'ils sont conservs dans l'archive prenne.
b. Modifier les fichiers d'un dpt sans changer leurs mtadonnes 1. [1] 2. [2] 3. Remplacer les fichiers normaliss dans l'archive existante [4]
49/87
Serveur d'Archivage 2007 Document de conception c. Modifier les fichiers d'un dpt sans changer leurs mtadonnes
Modifier les mtadonnes
1. Importer les mtadonnes normalises [14] 2. [11] 3. Remplacer les mtadonnes normalises dans l'archive existante [5]
d. Faire un rendu de l'archive vers un format de diffusion
1. Effectuer un traitement de conversion [51] 2. Dployer le rsultat de la conversion [61] e. Exporter les mtadonnes de l'archive vers un format cible 1. [51] 2. [61]
50/87
Par exemple, l'export vers STAR, se traduit par : 1. Ouvrir les mtadonnes sous forme normales 2. En extraire les mtadonnes TEF (via XSLT) 3. Publier ces mtadonnes quelquepart afin de les transmettre STAR On peut bien gnraliser cette activite [51] suivi de [61]. Il en va de mme pour OAI-PMH. Cependant, l'accs des records OAI-PMH (collection de fichiers XML) se fait par une servlet OAI-PMH.
51/87
52/87
8.3. Les mtadonnes dynamiques

8.3.1. Principe Nous avons dcid de permettre l'ajout et la suppression de mtadonnes pour un type de document directement par l'utilisateur et sans intervention technique sur l'application. Pour rendre l'ensemble des mtadonnes paramtrables, nous avons cr un mtamodle sous la forme d'un schma xml qui va dcrire comment peut tre dfinie une mtadonne. Le modle doit bien entendu tre conforme au mtamodle et dfinit les mtadonnes d'un type de document. Enfin, le modle est utilis pour gnrer le formulaire de saisie des mtadonnes d'un document du serveur d'archivage. 8.4. Les caractristiques des mtadonnes : le mtamodle
8.4.1. Types
Les types suivants sont disponibles pour dcrire une mtadonne :

string : une chane de caractres, text : du texte brut, int : un nombre entier, mail : une adresse mail, url : une adresse web, list : une numration qui contient des lments simples.
8.4.2. Attributs
Les attributs permettent de prciser la dfinition de la mtadonne et la gnration du formulaire de saisie. Tous les attributs ne sont pas applicables tous les types disponibles. Nom label desc required occurs maxSize Description nom de la mtadonne dans l'application, si diffrent du nom de la balise associe une brve description de la mtadonne qui sera affiche pour aider la saisie et la recherche par exemple il permet de prciser si la saisie de la mtadonne est obligatoire ou non false Valeur par dfaut
utilis pour dfinir la cardinalit de la mtadonne : prsente une ou plusieurs 1 fois longueur maximale accepte pour cette mtadonne 50
53/87
Serveur d'Archivage 2007 Document de conception minSize rows cols multiValued saveEmpty searchable longueur minimale accepte pour cette mtadonne taille en nombre de lignes de la zone de saisie taille en colonnes de la zone de saisie pour dterminer si plusieurs choix sont possibles pour une mtadonne 1 1 20 false
si la mtadonne n'est pas renseigne lors de la saisie, cet attribut permet de false dfinir si la balise de la mtadonne est insre dans le document xml ou non s'il est positionn true , il permet d'utiliser la mtadonne correspondante true dans les formulaires de recherche
8.5. Un fichier xml trous : le modle Le modle est un document xml valide par rapport au mtamodle qui permet la dfinition de la structure des mtadonnes et de l'interface de saisie.
8.5.1. Formulaire de saisie du modle
Afin de raliser une application utilisable par des non-informaticiens, nous avons cr un formulaire de saisie du modle : il permet la cration du fichier xml trous par le biais d'une interface conviviale. La premire version de cette interface de saisie ne gre qu'un seul niveau de profondeur dans les mtadonnes : il s'agit de la page adminManageDynMetadata.jsp.
Le contrleur de cette page est archivage.web.adminManageDynMetadataController. Le bean utilis est archivage.web.bean.NodeList. Cette classe ne contient qu'une ArrayList de Node, classe dcrite plus loin dans ce document.
a. Interface utilisateur
Chaque mtadonne dfinie offrira une interface utilisateur spcifique.

Les types int, string, url et mail
dans le document xml modle

<nom> <blank label="Nom de l'auteur" desc="Veuillez entrer le nom de l'auteur du document" required="true" occurs="1" cols="20" maxSize="15"
54/87

</nom> minSize="3" type="string"/>
dans le formulaire de saisie
Le type text

<description> <blank type="text" desc="Description du document" occurs="1" cols="20" rows="4"/> </description>
Le type list

<diffusion> <blank label="Diffusion du document" desc="Voulez-vous diffuser votre document?" required="true" occurs="1" type="list"> <item>oui</item> <item>non</item> </blank> </diffusion>
8.6. Implmentation Java

8.6.1. Emplacement des fichiers
L'emplacement du rpertoire des modles est configurable. Par dfaut c'est le rpertoire template du rpertoire de l'application qui est utilis. Le nom d'un fichier xml modle est normalis de la faon suivante : <nomTypeDocument>.xml.
8.6.2. Classes Java pour la saisie des mtadonnes d'un document
Classe Blank : la dfinition d'une mtadonne 55/87
Serveur d'Archivage 2007 Document de conception La classe Blank permettra de dfinir un trou dans le fichier xml. Elle aura tous les attributs et mthodes ncessaires la reprsentation d'une mtadonne et de son formulaire de saisie. Classe AllBlanks : le bean avec toutes les mtadonnes Cette classe est le bean utilis dans la page jsp pour enregistrer la valeur saisie par l'utilisateur dans le fichier xml de sortie.
8.6.3. Classes Java pour le formulaire de saisie du modle des mtadonnes d'un type de document
Classe Node : il s'agit d'un noeud dans le fichier xml modle : un nom de mtadonne et un trou . Pour l'implmentation des niveaux d'imbrication, il faudra ajouter un attribut de type arrayList<Node> la classe.De cette manire, la hirarchie des noeuds pourra tre conserve. Classe MetadataHelper : elle contient 2 mthodes relatives aux mtadonnes dynamiques. La premire est utilise dans la recherche de documents, la seconde permet de rcuprer les mtadonnes qui se trouvent dans le modle de document afin de pr-remplir le formulaire de saisie.
56/87
8.7. La recherche de documents

8.7.1. Principe La recherche de documents contenus dans le serveur d'archivage est l'une des fonctionnalits essentielles de l'application. Elle doit permettre l'internaute de slectionner des documents en fonction de critres qu'il aura saisis.
a. L'interface utilisateur
8.7.2. Critres de recherche

a. Types de document
Le premier champ de recherche propose un filtre sur le type de document rechercher. Si l'utilisateur veut chercher dans tous les types de documents, il doit slectionner divers dans la liste droulante.
b. Mtadonnes
Par dfaut, si aucun type de document n'est slectionn par l'utilisateur, la recherche se fera sur toutes les mtadonnes de base (Dublin Core). Si l'utilisateur prcise un type de document, les mtadonnes paramtrables accessibles la recherche seront ajoutes la liste des champs par le biais de la mthode getDynMetadataForDocumentType de la classe archivage.metadata.MetadataHelper.
c. Oprateurs
Nous proposons les oprateurs suivants entre un champ et la valeur de recherche : Nom Contient Ne contient pas gal Diffrent de Antrieur Antrieur ou gal Description xquery Le champ de mtadonne contient la valeur fn:contains(<champ>,<valeur>) saisie par l'utilisateur Le champ de mtadonne ne contient pas la not(fn:contains(<champ>,<valeur>)) valeur saisie par l'utilisateur Le champ de mtadonne est gal la valeur saisie par l'utilisateur <champ>=<valeur>
Le champ de mtadonne est diffrent de la <champ>!=<valeur> valeur saisie par l'utilisateur Le champ de mtadonne est antrieur la valeur saisie par l'utilisateur <champ><<valeur> <champ><=<valeur>
57/87
Serveur d'Archivage 2007 Document de conception Postrieur Postrieur ou gal Le champ de mtadonne est postrieur que <champ>><valeur> la valeur saisie par l'utilisateur <champ>>=<valeur>
d. Recherche multi critres
L'application proposera l'utilisateur d'entrer plusieurs critres de recherche en les coordonnant avec un oprateur et ou ou .
e. Sensibilit la casse
Par dfaut, la recherche ne sera pas sensible la casse. Il sera quand mme possible l'utilisateur de forcer la sensibilit la casse en cochant la case prvue cet effet. 8.7.3. Implmentation Java La soumission du formulaire de recherche fait appel au contrleur advancedSearchController du package archivage.web. Le contrleur demande la couche mtier (archivage.business.ServeurArchivage) la liste des documents correspondants aux critres de recherche saisis. La couche mtier lui renvoie les mtadonnes de base (Dublin Core) des documents trouvs. La requte Xquery est construite dans la couche DAO de l'application (classe archivage.dao.DaoXML). Voici un exemple de requte dans laquelle on demande parmi tous les documents de type these ceux dont l'un des champs de mtadonnes contienne Doc quelle que soit la casse :
<root> { for $i in collection("these") where some $j in $i/root/* satisfies fn:contains(lower-case($j),lower-case("Doc")) return <resultat> { $i/root/dcTitle } </resultat> } </root>
Le rsultat de la recherche est un document xml quivalent si la recherche a retourn un rsultat:

<root> <resultat> <dcTitle>Titre du document</dcTitle> <[autres mtadonnes du document]/> </resultat> </root>
58/87
9. La couche d'accs aux donnes

9.1. Donnes persistes et choix technologiques
Nous pouvons organiser les donnes persistantes de l'application en trois ensembles. Le premier est constitu des informations associes aux documents (mtadonnes), sur lesquelles nous effectuons des recherches pour retrouver un document et donc ses fichiers associs. Le deuxime concerne les fichiers associs aux documents dposs. Le troisime ensemble concerne les paramtres de l'application. Pour chacun de ses ensembles, nous avons opt pour la technologie qui nous semblait rpondre le mieux ses spcificits.
9.1.1. Les mtadonnes
Le cahier des charges pose comme principe que les mtadonnes associes un type de document ne doivent pas tre figes la conception. De plus, le format de ses mtadonnes doit permettre de couvrir les normes en vigueur dans le domaine fonctionnel de la gestion documentaire (DublinCore, STAR et autres). Ces normes ont une particularit qui est d'exploiter pleinement les possibilits offertes par XML, en organisant les informations sous une forme arborescente. Face ces contraintes, nous avons choisi de confier la gestion des mtadonnes une base de donnes XML native qui nous permet de faon relativement simple de stocker, indexer et rechercher des informations dont on ne connait pas l'avance la structure.
9.1.2. Les fichiers associs aux documents
Les fichiers constitutifs du document peuvent tre de nature diffrente (images, textes, sons, etc.) et en nombre indtermin. De plus, ces fichiers peuvent tre organiss selon une arborescence de rpertoires dont la conservation est ncessaire la restitution correcte du document final. Nous avons dcid pour traiter ces problmes de fabriquer une archive de l'ensemble des ces objets afin de le manipuler simplement. Le format d'archives utilis est paramtrable (choix parmi tar.bz2, tar et zip). Par dfaut, c'est le tar.bz2 qui est utilis. Les archives produites par l'application sont stockes sur le file system du serveur. Nous aurions pu les stocker dans une base de donnes sous forme de blob (dans eXist ou autre), mais ce choix ne nous a pas sembl pertinent. Il est plus simple et plus sr pour un administrateur de manipuler des fichiers archives stocks sur le file system que dans une base de donnes. De plus, ce choix nous permet, en conservant les mtadonnes associes au document dans l'archives ellemme, de rinitialiser la base de donnes des mtadonnes en repartant des archives. Le rle imparti la base de donnes se rduit donc l'indexation des archives, pas leur sauvegarde.
9.1.3. Les paramtres de l'application
Dans le primtre actuel de l'application, les donnes paramtres de l'application sont trs peu nombreuses. Les paramtres techniques (dfinition des rpertoires, des drivers de base de donnes, etc.) sont stocks dans un fichier de proprits au format java.util.Properties. Ce fichier s'appelle config.properties est se situe la racine de l'application. Il est cr automatiquement lors du dploiement. Les paramtres fonctionnels se rduisent la dfinition des types de documents et de leur mtadonnes associes. Les types sont stocks dans la base de donnes eXist, dans une collection ddie : typesdoc. La dfinition des mtadonnes est stocke sous forme de fichier XML portant le nom du type, dans le rpertoire 59/87
Serveur d'Archivage 2007 Document de conception nomm template . Dans l'hypothse d'un accroissement du nombre de paramtres fonctionnels, il faudra peut-tre envisager d'utiliser une base de donnes relationnelle plus communment utilise par les dveloppeurs.
9.2. Diagramme de classes
9.2.1. L'interface Idao et son implmentation L'interface Idao est utilise pour raliser des concrtisations de simulation (utile uniquement en phase de dveloppement). 60/87
Serveur d'Archivage 2007 Document de conception La classe DaoFront, implmente l'interface IDao. Elle prsente une faade masquant la complexit des accs la base de donne eXist et des oprations de compression/dcompression d'archive.Elle propose des mthodes fonctionnelles par opposition aux oprations techniques ralises par les classes sous-jascentes : save() : sauvegarde un document. Enregistre les mtadonnes dans la base de donnes eXist (utilise ensuite des fins de recherche) et stocke une version compresse du document dans le systme de fichiers du serveur. open() : ralise en partie l'opration inverse de save(). Met disposition une version dcompresse du document dans un rpertoire temporaire. search() : effectue une recherche de documents suivant des critres plus ou moins complexes. Elle retourne une liste de documents rpondant aux critres de recherche. load() : retourne les mtadonnes concernant un document particulier. addTypeDoc() : ajoute un nouveau type de document (correspond une collection dans la base de donnes XML : thses, annales, etc.). listTypeDoc() : renvoie la liste des types de documents. 9.2.2. Les classes DaoFS et DaoXML La classe DaoFS assure les oprations techniques de compression/dcompression de l'archive. Nous ne dtaillons pas ici le contenu de cette classe. De plus amples informations sont disponibles dans la Javadoc. La classe DaoXML assure les opration technique de lecture/mise jour dans la base de donnes XML. De mme que pour DaoFS, de plus amples informations sont disponibles dans la Javadoc.
61/87
9.3. Articulation des diffrentes couches

La couche de persistance est conue de faon pouvoir modifier simplement les technologies employes. 9.3.1. Schma en couches :
Couche de prsentation
Couche mtier
Couche de persistance Faade de la couche de persistance
Persistance en base de donnes XML
Persistance sur le File System
Base de donnes XML native eXist
File System
La faade de la couche de persistance en prsente une vision fonctionnelle. Les demandes issues de la couche mtier sont aiguilles vers le composant technique devant traiter la demande en fonction de la technologie choisie.
62/87
9.4. Structure du stockage dans la base de donnes eXist

La base de donnes eXist est structure autour de deux natures d'objet : la collection et la ressource. Les ressources sont soit des documents XML, soit des fichiers binaires. Les collections permettent de dfinir un classement arborescent des ressources, chaque collection pouvant contenir plusieurs sous collections. L'application dfinit deux collections de bases, cres automatiquement lors du dmarrage de l'application : biblio pour le stockage des mtadonnes et typesdoc pour le stockage des dfinitions de type de document. Ces deux collections sont cres sous la racine de la base eXist (/db). Les informations correspondantes un type de donnes sont enregistres dans un fichier XML portant le nom du type de donnes. Ce nom ne doit pas contenir de caractres spciaux ou accentus. Pour chaque type de donnes, une sous-collection est cre dans la collection biblio . Chaque ensemble de mtadonnes constitue un fichier XML identifi par le nom du document. Ce nom est un timestamp dtermin au moment du dpt. Les fichiers de mtadonnes sont stocks dans la collection biblio/xxxxxx o xxxxxx reprsente le nom du type de document auquel est rattach le document. Les collections et les ressources de la base de donnes sont accessibles au travers du client graphique fourni avec eXist. Collections de bases vues par le client eXist.
Sous-collections correspondant aux types de documents dfinis.
Ressources correspondant la dfinition des types de documents
63/87
Ressources correspondant aux mtadonnes des documents dposs.
64/87
Serveur d'Archivage 2007 Document de conception Les fichiers de mtadonnes stocks dans eXist sont issus du regroupement des mtadonnes statiques et dynamiques.
65/87
9.5. Ajout Mise jour des documents

La couche mtier dlivre un document la couche de persistance sous la forme d'un rpertoire temporaire (portant le nom du document) contenant deux sous-rpertoires. Le premier, nomm document contient les fichiers dposs. Le deuxime sous-rpertoire, nomm metadata , contient deux fichiers de mtadonnes : base.xml pour les mtadonnes statiques et param.xml pour les mtadonnes dynamiques. Base.xml est obligatoirement prsent, param.xml n'est prsent que s'il y a des mtadonnes dynamiques dfinies pour le type de document concern. La classe archivage.dao.MrgXmlFiles prend en charge la fabrication d'un fichier XML unique partir de ces deux fichiers pour pouvoir ensuite l'enregistrer dans eXist (classe archivage.dao.DaoXML). La classe archivage.dao.DaoFS s'occupe de fabrication de l'archives partir du rpertoire temporaire. La totalit du rpertoire est mise dans l'archives. Le nom de cette dernire est constitu du nom du document (donc du rpertoire temporaire) suffix par le format d'archives. L'archive est sauvegarde sur le systme de fichiers du serveur, dans le rpertoire paramtr (C:\ServeurArchivage par dfaut). A l'issue de la sauvegarde du document, le rpertoire temporaire est supprim par la couche mtier. Pour la mise jour d'un document existant, la couche de persistante se charge de reconstruire le rpertoire temporaire partir de l'archive (classe archivage.dao.DaoFS ). Elle procde ensuite sa sauvegarde selon la mme procdure que celle dcrite pour l'ajout. Nous avons utilis l'API trueZip pour la fabrication des archives. Celle-ci prend en charge le format tar.bz2 et accepte des noms de fichiers avec accent (contrairement l'API fournie avec le JDK Java). Cette API est disponible sous licence Apache 2.0.
9.6. Ajout et mise jour des types de donnes

Les informations en provenance de la couche de prsentation sont transmises par la couche mtier sous forme de beans Type. Afin de traiter d'une faon gnrale la transformation d'un bean en fichier XML enregistrable dans eXist, nous avons dvelopp une classe ddie : archivage.util.BeansToXml. Cette classe peut transformer n'importe quelle srie de beans en un fichier XML condition de respecter les contraintes suivantes :

Les beans en question doivent respecter les conventions de nommage des JavaBeans. Les proprits des beans doivent correspondre au nom des balises du fichier XML. Les noms root et bean ne doivent pas tre utiliss. Seuls les types String, Date, Integer, Short, Long, Float, Double, Boolean ou ArrayList de String sont autoriss.
Le fichier XML issu de cette transformation possde une racine root et chaque ensemble d'information correspondant un bean est encadr par une balise bean .
9.7. Requtage dans eXist

Les requtes sont traites par le biais de fichiers de requtes stocks dans un rpertoire nomm xquery (paramtrable). La syntaxe des requtes est dite FLOWR (for-let-where-order by-return). L'externalisation du contenu des requtes autorise une certaine souplesse dans leur maintenance. Exemple d'une requte.
66/87
Les variables $collections et $clausewhere sont alimentes la vole au moment de l'excution. Elles dpendent de la demande de l'utilisateur. La clause WHERE de la requte est construite dynamiquement en fonction des critres de recherche, par la classe ddie archivage.dao.BuildXqueryWhere. Les rsultats d'une requte sont au format XML. La couche de persistance dialogue avec la couche mtier en changeant des beans ou des listes de bean. Nous avons donc dvelopp une classe ddie la transformation du rsultat des requtes en beans ou liste de bean (unmarshalling). Il s'agit de la classe archivage.util.xmlToBeans qui tend la classe org.xml.sax.helpers.DefaultHandler. Cette classe est capable de transformer n'importe quel rsultat de requte en une ArrayList de beans sans connatre l'avance ni la requte ni la structure des beans. Ceci condition de respecter les contraintes suivantes :

Les beans en question doivent respecter les conventions de nommage des JavaBeans. Les proprits des beans doivent correspondre au nom des balises du fichier XML. Les noms root et resultat ne doivent pas tre utiliss. Seuls les types String, Date, Integer, Short, Long, Float, Double, Boolean ou ArrayList de String sont autoriss. Le document XML issu de la requte doit tre structur en ayant root comme racine et un ou des ensembles de rsultats encadrs par une balise resultat . S'il n'y a qu'un ensemble de rsultats, l'encadrement par resultat est facultatif.
67/87
10. La couche de prsentation :

Le projet Serveur d'Archivage 2007 est btie autour d'une architecture 3-tiers avec une couche de prsentation (interface graphique fournie l'utilisateur), une couche mtier fournissant une srie de fonctionnalits et une couche d'accs aux donnes. La couche de prsentation respecte plus prcisment l'architecture Modle-Vue-Contrleur. La vue correspond un lment de l'interface utilisateur par laquelle il pourra interagir avec l'application. Le contrleur gre les vnements (en gnral les actions de l'utilisateur) et modifie le modle en appelant ventuellement la couche mtier si l'action le ncessite. Puis, il associe ce modle la vue qui va l'intgrer pour le prsenter l'utilisateur. Le modle correspond une reprsentation spcifique des informations formant la rponse l'vnement qui s'est produit. Afin de mettre en place cette architecture, nous avons dcid d'utiliser Spring MVC, branche du framework Open Source Spring ddie au dveloppement web MVC. Nous justifions ce choix par le fait que ce framework fournit une vaste plateforme stable, prouve et optimise qui convient particulirement notre projet. Aprs une priode d'initiation et de documentation sur les capacits de Spring MVC, celui-ci s'est avr trs utile pour acclrer le dveloppement de la couche de prsentation et galement pour assimiler le concept MVC. Par ailleurs, le framework Spring n'est pas fig et propose des ouvertures sur d'autres technologies et outils Open Source. Il comprend plusieurs sous-projets comme Spring Web Flow qui est un framework d'application web Java de plus niveau encore en introduisant la notion de flows (modules autonomes et rutilisables associs des actions) et Spring LDAP qui est une librairie pour la simplification des oprations LDAP. Spring peut galement aider au dveloppement des couches mtier et d'accs aux donnes grce l'intgration d'autres frameworks comme Hibernate qui est un service de persistance Objet / Relationnel. Ces derniers points sont des atouts certains dans la perspective de projets futures autour des applications web Java et le projet Serveur d'Archivage formerait ainsi un prcieux tremplin. Enfin, en dernier argument, nous ajouterons le fait que Struts, l'une des alternatives rpandues Spring, n'volue plus et n'offre pas ces ouvertures vers d'autres outils. En ce qui concerne les vues, nous utilisons la technologie JSP 2.0 enrichie de la JSTL afin de produire du contenu web dynamique. La JSTL regroupe un ensemble de balises, chacune de ces balises correspondant une fonctionnalit comme l'itration sur une Collection Java ou le formatage d'une date (de type java.util.Date). Les implmentations de la JSTL ont de plus l'avantage d'tre optimis. Javascript sera incorpor aux pages HTML produites afin de gnrer des champs cot client. Le conteneur de servlets Apache Tomcat 5 a t choisi afin de dployer notre application, premirement car il fait rfrence et deuximement car nous nous tions dj exerc dessus sur un projet antrieur. Pendant la phase dveloppement, le plugin Tomcat pour Eclipse de Sysdeo servira tester l'application sans produire le fichier war (format de dploiement d'une application web Java) chaque modification. La plateforme de dveloppement Eclipse 3.2 est notre outil de dveloppement. En plus de sa large diffusion dans la communaut des dveloppeurs Java, cet IDE se distingue par sa capacit intgrer de nombreux plugins. Nous avons incorpor les plugins J2EE Standard Tools, Web Standards Tools , Spring IDE et Subclipse. J2EE Standard Tools et Web Standards Tools offre une aide au dveloppement en Java et avec les pages JSP. Spring IDE facilite le dveloppement et le dbuggage des composants provenant ou tendant ceux de Spring MVC. Subclipse est quant lui un client SVN. L'outil de modlisation UML pour les diagrammes de classes est le logiciel Bouml.
68/87
10.1. L'arborescence du module ServeurArchivageWeb

Le module ServeurArchivageWeb est la partie du projet traitant la couche de prsentation. Afin d'tre dploy sous Tomcat 5, le module doit respect une arborescence standard. En mode dveloppement, l'arborescence est la suivante :

archivageweb/jsp (pages JSP). archivageweb/src (code source des classes Java et fichiers *.properties). archivageweb/work (rpertoire de dpt des classes Java produites partir des pages JSP). archivageweb/WEB-INF (contient les fichiers de configuration ncessaires au dploiement au sein du serveur Tomcat ainsi que les fichiers de configuration des contrleurs Spring). archivageweb/WEB-INF/classes (fichiers compils .class et fichiers *.properties). archivageweb/WEB-INF/lib (librairies ncessaires au dveloppement et au dploiement de l'application). archivageweb/WEB-INF/tld (fichiers de dclarations des librairies de tags disponibles dans les pages JSP).
Le fichier de configuration de Tomcat est web.xml (situe dans le rpertoire WEB-INF) contient la dfinition du chargeur de contexte de Spring (voir dtail ci-dessous), du contrleur principal de l'application, du filtre de pages JSP et d'encodage des caractres en UTF-8 et des librairies de tags. Les descriptions dtailles suivront dans le document.
10.2. Le package archivage.web et Spring MVC

Une application web bas sur Spring MVC est construite autour d'un contrleur principal et d'un ensemble de contrleurs secondaires. Le framework Spring met la disposition des dveloppeurs une srie de composants gnriques et spcialiss sous forme de classes et d'interface Java et qui sont typiques de composants intgrs dans des applications web. Nous avons la libert d'utiliser et d'enrichir ces composants en fonction de notre besoin. Les descriptions qui vont suivre dtaillerons l'implmentation de la couche de prsentation concrtis dans le package archivage.web et dans ses sous-packages. Nous avons dcid de dcomposer nos classes de la manire suivante :
archivage.web contient les contrleurs secondaires, les validateurs, l'intercepteur et le filtre de pages JSP. Le package archivage.web.bean contient les classes des beans associs aux diffrents formulaires. Le package archivage.web.exception contient les classes drives de java.lang.RuntimeException ventuellement lances au cours de l'excution de l'application.
69/87
10.2.1. Le contrleur principal dispatchServlet

Le contrleur principal (classe org.springframework.web.servlet.DispatcherServlet), se charge de transmettre la requte du client l'un des contrleurs secondaires. En fait, chaque action de l'utilisateur est associe un contrleur secondaire. Le dispatchServlet se prsente sous la forme d'un fichier XML nomm dispatch70/87
Serveur d'Archivage 2007 Document de conception servlet.xml et contient la dfinition des Beans ncessaires au dploiement de la couche de prsentation. Un autre ensemble de Beans de porte (ou scope) application, c'est--dire accessible tout le long de l'excution, sont dfinis dans le fichier applicationContext.xml. Cela nous sera utile pour renseigner tous les contrleurs de la classe de la couche mtier et de la couche DAO ainsi que le contrleur de gestion des messages (afin d'afficher les messages d'erreurs par exemple). Ce dernier fichier de configuration ainsi que le fichier dispatchservlet.xml sont stockes dans le rpertoire WEB-INF. Qu'est ce qu'un Bean ? Dans Spring, les objets formant le squelette de l'application et grs par le conteneur IoC sont appel les Beans. Ainsi, un Bean est simplement un objet qui est instanci, assembl et gr par l'IoC. Donc, tous les objets instances de classes que nous crerons seront considrs comme des Beans. L'interface de l'API de Spring reprsentant le conteneur IoC est org.springframework.beans.factory.BeanFactory. La classe XmlBeanFactory est une implmentation de cette interface qui permet d'exprimer les beans dans un fichier XML. C'est cette implmentation que nous utiliserons pour le BeanFactory. De plus, notre application Web utilisera l'interface ApplicationContext (package org.springframework.context) qui tends les fonctionnalits du BeanFactory en les amliorant. Son premier avantage est de fournir le service du BeanFactory sans initialiser ce dernier manuellement. Pour cela, nous utiliserons la classe ContextLoader (package org.springframework.web.context) qui charge l'ApplicationContext automatiquement au dmarrage de l'application Web. Le diagramme de classes suivant (tir de l'API de Spring) illustre les classes DispatcherServlet, FrameworkServlet (package org.springframework.web.servlet) et ContextLoader. Il montre comment l'ApplicationContext (extension du BeanFactory) est initialis au dmarrage. C'est par ce mcanisme que le BeanFactory est dploy. De ce fait, tous les Beans des classes que nous implmenterons seront intgrs l'application et interagirons avec le contrleur principal jouant le rle de relais entre les actions de l'utilisateur et nos contrleurs.
71/87
10.2.2. Les contrleurs secondaires

Les contrleurs secondaires implmentent l'interface org.springframework.web.servlet.mvc.Controller. Chacun d'eux traite l'action excute par l'utilisateur (en l'occurrence *.form). Les contrleurs associes aux actions ont le mme comportement : ils construisent un modle (ensemble d'objets contenant des informations) en interrogeant ventuellement la couche mtier et choisissent une vue. Puis, ils rappellent le contrleur principal qui se charge de demander l'affichage de la vue. Par exemple, le contrleur SearchController est lanc suite une action Search.form et construit le formulaire de recherche de documents. Les contrleurs de formulaires seront traits plus en dtails par la suite. La liste des contrleurs secondaires est la suivante :

le gestionnaire de vues ou ViewResolver le gestionnaire de mapping des URLs 72/87

le gestionnaire d'exceptions Java les contrleurs associs aux actions :

d'authentification de gestion de documents archivs :

consultation dpt mise jour suppression ajout mise jour suppression
d'administration des types de documents

de dconnexion
10.2.3. Les contrleurs basiques
Pour implmenter des contrleurs basiques, nous avons tendu la classe org.springframework.web.servlet.mvc.AbstractController. Il s'agit d'une base intressante pour construire un 73/87
Serveur d'Archivage 2007 Document de conception modle et lui associer une vue, en surchargeant la mthode handleRequestInternal(). Pour ce faire, le contrleur doit renvoyer un objet de la classe ModelAndView (package org.springframework.web.servlet) qui comme son nom l'indique peut enregistrer le nom d'une vue et un modle (ensemble d'informations). Pour associer une vue, il suffit d' indiquer le nom de la vue dans le constructeur de la classe ModelAndView. Le modle se construit l'aide de la mthode addObject( nom de l'objet , valeur de l'objet ). Nos contrleurs dfinissent un attribut de type ServeurArchivage (classe du package archivage.business de la couche mtier) ainsi que le getter et le setter afin de rcuprer l'objet prsent en porte (ou scope) application ce qui permet d'accder aux mthodes de la couche mtier.
10.2.4. Les contrleurs de formulaires

a. Les formulaires simples (une seule page)
Afin de mettre en place des contrleurs grant la saisie d'informations partir d'un formulaire, nous tendrons la classe org.springframework.web.servlet.mvc.SimpleFormController qui est spcialise dans ce service. Elle permet une manipulation aise des champs du formulaire, reprsents sous la forme d'attributs au sein d'un Java Bean (classe Login du package archivage.web.bean). La mthode que nous surchargeons pour ce type de contrleurs est onSubmit(). 74/87
Serveur d'Archivage 2007 Document de conception L'interface org.springframework.validation.Validator est une base pour l'criture des classes de validation (cit dans la rfrence au SimpleFormController). Elle exige l'implmentation de la mthode validate(Object obj, org.springframework.validation.Error errors) o obj correspond au Bean du formulaire. La classe Error est un moyen de transmission des messages vers la vue destine l'utilisateur. Aprs soumission du formulaire et si les valeurs des champs entrs par l'utilisateur ne sont pas valids, l'application le redirigera vers la page prcdente en lui signalant ses erreurs. Dans le cas contraire, l'utilisateur verra une page de confirmation du succs de l'opration. b. Les formulaires simples (une seule page) de la partie administration
Un autre exemple d'un contrleurs grant la saisie d'informations partir d'un formulaire, et qui tend la classe org.springframework.web.servlet.mvc.SimpleFormController. Dans la partie administration l'utilisateur peut ajouter un type de document ou en modifier un dj existant. Dans cette optique le contrleur AdminAddController permet de faire les deux fonctions. Pour cela nous redfinissons les mthode suivantes :
formBackingObject() la demande d'une nouvelle instance du contrleur cette mthode permet l'initialisation des champs du formulaire associ et de les pr-remplir. Deux actions sont possibles selon l'action demande, ajout ou modification d'un type de document. La premire renvoie un Java Bean TypePlus vide, en ce qui concerne l'ajout. La seconde renvoie un Java Bean TypePlus, contenant les informations sur un type de document en fonction du nom du type de document reu en paramtre. onSubmit() la demande de soumission du formulaire, la mthode va, l'aide d'un StringTokenizer, 75/87
Serveur d'Archivage 2007 Document de conception rcuprer les types mimes et les ranger dans une ArrayList, de faon conforme au Java Bean Type. La mthode TypePlusToType() prend alors le relais pour transformer le Java Bean TypePlus en Java Bean Type qui sera par la suite ajout. Aprs la soumission du formulaire, la classe de validation ValidateAdminAdd se charge de valider les champs de celui-ci. Si les valeurs des champs entrs par l'utilisateur ne sont pas valids, l'application demandera de saisir nouveau les valeurs qui sont errones. Sinon le nouveau type est ajout et une page de confirmation d'ajout ou de modification est affiche l'utilisateur.
c. Le formulaire de type wizard
76/87
Pour implmenter la fonction de dpt / mise jour de document qui implique l'entre par l'utilisateur de nombreuses informations, nous avons dcid de mettre en place un wizard , c'est--dire un formulaire sur 3 pages. Spring MVC met notre disposition la classe AbstractWizardFormController (package org.springframework.web.servlet.mvc) qui est adapt cette configuration, avec une srie de mthodes qui sont lances des moments bien dfinis. Les mthodes que nous avons surcharges sont les suivantes :
formBackingObject() qui doit contenir le code d'initialisation du Java Bean du formulaire. En fonction du contexte (dpt ou mise jour), l'initialisation est diffrente. Cette mthode est lance la cration d'une nouvelle instance de ce contrleur. processFinish() qui est appele la validation finale du formulaire. Elle doit rediriger la vue vers une autre page comme par exemple une page de confirmation. processCancel() qui est appele si l'utilisateur abandonne le formulaire. Elle doit rediriger la vue vers une autre page comme par exemple la page d'accueil. validatePage() qui est lance la soumission de chaque page composant le formulaire. Ici, nous faisons appel l'objet Validator pour tester la valeur des champs. postProcessPage() qui est lance aprs la validation de la page de formulaire, c'est dire aprs l'appel de la mthode validatePage(). On l'utilise pour traiter les informations qui ont t rentrs par l'utilisateur ou pour appliquer un autre jeu de validation. referenceData() qui sert initialiser chaque page du formulaire indiduellement et qui est donc lance avant l'affichage de la page. Cela nous permet d'insrer notre code d'initialisation. initBinder() qui est excute l'initialisation de la classe AbstractWizardFormController et servant mettre en place des convertisseurs d'objets de type String (obtenus partir du formulaire HTML) vers des objets du type de notre choix. Ainsi, nous avons install un convertisseur vers le type Date (package java.util).
Grce l'attribut allowDirtyBack , l'utilisateur a la possibilit de repartir en arrire pour modifier une page du formulaire qu'il a dj soumise. Nous devons faire une remarque ce sujet : dans le cas d'une mise jour, si l'utilisateur valide la premire page de chargement de fichiers, les ajouts/suppressions de fichiers seront prises en compte sur le champ. En clair, l'utilisateur ne pourra plus obtenir le premier jeu de fichiers aprs qu'il ait valid la premire page. Nous avons appel DeposController notre contrleur qui tend la classe de Spring. La classe associe ce contrleur et contenant la dfinition des champs est la classe WizardForm (package archivage.web.bean). Cette classe reprends tous les attributs de la classe Base en y ajoutant quelques attributs ncessaires Spring pour faire la jonction avec le formulaire de la page HTML. Par exemple, la collection de tableau de byte[] (attribut contenuSeconds) sert charger le contenu des fichiers secondaires. Certaines mtadonnes sont valeurs multiples, comme les auteurs du document. Une mtadonne valeur multiple est reprsente dans la classe WizardForm par un attribut de type ArrayList. Pour implmenter cette caractristique, nous avons dvelopp une solution en Javascript cot client, c'est--dire au niveau de l'explorateur web de l'utilisateur. Dans la pratique, lorsque l'utilisateur clique sur l'image + (ou -), un champ apparat (ou disparat). Il s'agit de balises HTML input de type text . Toutefois, comme cette opration est effectue cot client, le composant Spring ne peut rcuprer automatiquement les valeurs entres dans ces champs. Nous avons donc crit un algorithme du cot du contrleur pour rcuprer les valeurs de ces champs (passes en paramtres de la requte HTTP). De plus, nous avons adapt le code Javascript pour que l'on puisse 77/87
Serveur d'Archivage 2007 Document de conception distinguer les champs connues par Spring (lien automatique entre le champ i et l'lment de l'ArrayList d'index i) et ceux qui ont t produit dynamiquement. En fait, la fonction Javascript prend en argument le nom du noeud HTML courant (par exemple auteurs ) et l'indice du dernier lment produit cot serveur (donc connu par le composant Spring). Nous utilisons ce mme mcanisme pour grer les fichiers secondaires multiples. Dans le cas d'une mise jour, les anciens fichiers archivs sont prsents dans des checkbox (case cocher). Dans la classe WizardForm, les checkbox sont reprsents par un tableau de chanes de caractres (String[] checkBoxSeconds). On utilise les checkboxs supprimer les fichiers qui ont t dcochs. La validation des champs se fait pour chaque page individuellement ( chaque soumission d'un page) et une nouvelle fois de manire globale la validation finale du formulaire. La classe de validation est ValidateWizardForm avec trois mthodes de validation spcifique, une pour chaque page. La premire page demande l'utilisateur de spcifier le type de document et d'entrer le fichier principal et les fichiers secondaires ventuels (vue upload.jsp). La seconde page du formulaire (vue depos.jsp) contient les champs des mtadonnes du Dublin Core (simples et tendues). La troisime page est consacre aux champs des mtadonnes dynamiques (vue dynamic.jsp).
78/87
10.2.5. Notre intercepteur d'authentification
a. La classe MyHandlerInterceptor
Un contrleur particulier de type intercepteur implmentant l'interface org.springframework.web.servlet.HandlerInterceptor se place automatiquement entre le contrleur principal et les contrleurs secondaires. Cet intercepteur (de classe web.MyHandlerInterceptor) nous permet de restreindre l'accs certaines parties de l'application aux seuls utilisateurs authentifis. Afin de permettre l'accs aux anonymes, ce test sera effectu uniquement pour un ensemble pr-dfini d'URLs (galement appeles actions). Les utilisateurs sont reprsents par la classe User.
b. La classe User
Un objet de la classe User dcrit les informations associes un utilisateur :

login. mot de passe.
79/87

tat (authentifi ou non authentifi). type (deposant ou biblio pour bibliothcaire).
10.2.6. Autres composants de Spring

Les autres composants de l'API de Spring que nous dfinissons dans le fichier dispatch-servlet.xml sont :
la classe de gestion de vues org.springframework.web.servlet.view.InternalResourceViewResolver qui permet de fixer un suffixe et un prfixe aux noms des vues pour simplifier leurs dclarations (par exemple prfixe"/jsp/" et suffixe .jsp ). la classe de mapping URL / Controller org.springframework.web.servlet.handler.SimpleUrlHandlerMapping qui associe une action un contrleur secondaire. la classe de gestion du chargement des fichiers du poste client vers le serveur org.springframework.web.multipart.commons.CommonsMultipartResolver la classe de gestion des exceptions org.springframework.web.servlet.handler.SimpleMappingExceptionResolver qui redirige la vue vers une page spcifique selon l'exception qui a t capture. A tout moment, une exception pourra tre lev par l'application et attrap par la couche de prsentation. Grce au gestionnaire d'exception, l'utilisateur verra une page de description de l'erreur qui a t rencontr. La centralisation des messages dans un fichier plac dans le rpertoire de fichiers source (src/messages.properties). Ce fichier est trs utile pour l'affichage des messages qui sont par exemple gnrs lors de la validation des champs.
80/87
10.2.7. Liste des couples action-contrleur

Action Home.form Login.form Depos.form Contrleur secondaire HomeController LoginController DeposController Vue produite par l'action Page d'accueil avec formulaire d'authentification (home.jsp). Page de confirmation avec un menu associ au type dposant ou bibliothcaire (confirm.jsp). Formulaire de dpt / mise jour de documents avec entre des mtadonnes et chargement des fichiers (upload.jsp depos.jsp dynamic.jsp). Action de dconnexion menant vers la page d'accueil (home.jsp) Gestion des documents archivs menant vers la page de choix du type de document (listTypes.jsp) Page listant les documents d'un mme type (listDocs.jsp) Page affichant le contenu d'un document (infoDoc.jsp) Formulaire de choix de critres pour la recherche de documents (search.jsp) Page listant les fichiers consultables Page affichant le plan de l'application (plan.jsp) Page proposant les fonctionnalits ddies un bibliothcaire (admin.jsp).
Logout.form List.form ListDocs.form InfoDoc.form Search.form View.form Plan.form Admin.form
LogoutController ListController ListDocsController InfoDocController SearchController ViewController PlanController AdminController
81/87
10.2.8. Filtre de pages JSP

Nous avons dclar dans le fichier de configuration web.xml une classe de filtrage des pages JSP. Cette classe JspFilter implmente l'interface javax.servlet.Filter qui correspond un standard de filtre Java, standard reconnu par Apache Tomcat 5. Pour appliquer le filtre notre application, nous avons renseign en plus de JspFilter la liste des fichiers JSP auxquels on interdit l'accs. Nous avions galement la possibilit de marquer une expression rgulire (comme *.jsp ) mais on ne souhaitait pas bloquer l'accs tous les fichiers JSP. En effet, le filtrage de certains fichiers n'est ncessaire que pour une partie limite et cela pour viter une ventuel faille de scurit. Ainsi, appliquer un filtrage avec l'expression rgulire *.jsp nous aurait amener dplacer les fichiers auxquels ne s'appliquent pas une contrainte de scurit (typiquement la page d'accueil).
82/87
Serveur d'Archivage 2007 Document de conception 11. Diagramme de dploiement
Ce diagramme de dploiement reste gnrique en ce qui concerne les matriels et systmes d'exploitation. En 83/87
Serveur d'Archivage 2007 Document de conception effet, l'application Serveur Archivage peut tre dploye sur n'importe quel serveur de la famille Windows (moyennant l'installation du logiciel Cygwin) ou Unix. Nous n'avons pas jug utile de crer deux diagrammes se distinguant uniquement pas le composant Cygwin. La seule contrainte pose sur les postes client est qu'ils doivent possder un navigateur rcent.
84/87
12. Annexe 1 : Recherches technologiques

12.1. Xstream
12.1.1. Objectif : le stockage des mtadonnes en XML
Principe
Nous avions dcid de crer un bean reprsentant la partie des mtadonnes dite statique : le bean base . Dans la mesure o les mtadonnes avaient pour vocation d'tre enregistres dans la base de donnes XML, nous nous sommes mis la recherche de librairies susceptibles de nous faciliter la tche.
12.1.2. La librairie XStream

Srialisation et dsrialisation des beans
XStream est une librairie trs simple d'utilisation qui permet de srialiser des beans vers du XML et d'instancier un bean partir d'un fichier xml : http://xstream.codehaus.org/. Une fois la classe que l'on souhaite srialiser cre, un simple appel la librarie cre le fichier xml correspondant.
12.1.3. Problmes rencontrs

Mtadonnes dynamiques
L'utilisation de XStream ncessite une classe fige, dont on connat les lments. Or, par dfinition, nous ne pouvons prvoir ce qui va tre dfini par l'utilisateur pour ce type de mtadonnes. L'utilisation de XStream s'est donc avre impossible pour cette partie des mtadonnes. Nous sommes donc partis sur la solution des fichiers xml trous dcrite plus loin dans ce document.
Mtadonnes statiques
Pour les mtadonnes dites statiques , il ne semblait pas y avoir de contre-indications l'utilisation de la librairie. Malheureusement, aprs quelques jours de dveloppement, nous avons rencontr le problme suivant : une incohrence entre la sortie produite par la librairie et l'entre attendue par la couche de stockage (DAO). Exemple pour un attribut du bean Base : la liste des auteurs d'un document
Code de l'attribut dans la classe Base
ArrayList<String> dcCreators;
Cet attribut peut donc contenir les valeurs suivantes : Jean Dupond et Jacques Durand.
Fragment du fichier XML attendu
<dcCreators>Jean Dupond</dcCreators>
85/87

<dcCreators>Jacques Durand</dcCreators>
Fragment du fichier XML produit par XStream

<dcCreators> <string>Jean Dupond</string> <string>Jacques Durand</string> </dcCreators>
Nous avions alors le choix pour corriger ce problme : tout en conservant XStream : changer le format d'entre de la couche de stockage pour l'adapter au format de sortie natif de XStream : c'est la solution la plus rapide mais cela implique des changements dans toutes les requtes et ne correspond pas nos spcifications initiales, paramtrer XStream pour obtenir le format de sortie attendu : c'est la solution la plus propre puisqu'elle respecte nos spcifications mais les transformations profondes dans le bean (cration d'une classe spcifique par attribut de type collections) auraient impliqu des changements majeurs dans la couche de prsentation. dvelopper notre parser : il s'agit l de supprimer l'origine du problme en crant un parser qui correspond nos attentes. C'est la solution que nous avons retenue car elle permet, sans changement des spcifications ou des parties dj dveloppes, d'atteindre l'objectif.
12.2. Spring
Ds le deuxime semaine du projet, aprs notre premire runion interne date du 08/02/2007, nous nous sommes consacr un travail de R&D dans le domaine du framework Open Source de dveloppement Web Spring. Nous tions partis sur cette piste car Spring fait toujours l'objet d'volution et d'intgration de nouveaux services contrairement son alternative Struts. Cette priode de R&D a dur un peu plus de deux semaines jusqu' l'obtention d'un prototype qui proposait des solutions approfondir dans la perspective d'intgration dans l'application Web Serveur d'Archivage 2007. En premier lieu, nous nous sommes lancs dans le test d'AppFuse, projet Open Source qui intgre d'autres outils Open Source comme Spring et Hibernate dans le but de construire des applications Web rapidement et de manire efficace. AppFuse est sur le papier une solution trs intressante mais non encore assez rpandu dans la communaut des dveloppeurs Java. En effet, nous avons rencontr de srieux problmes pour dployer AppFuse 1.9 (bas sur Ant) et AppFuse 2.0 (bas sur Maven2 et intgrant JDK 5, JSP 2.0 et Servlet 2.4). Maven 2 et Ant sont des outils pour la gestion et l'automatisation de production des projets Java. Nous n'avons notamment pas trouv de tutoriel complet pour leur installation. De plus, au fur et mesure que nous avons avanc dans le projet, le choix d'une base de donnes XML s'est prcis ce qui a annul les avantages amens par Hibernate car celui-ci ne gre pas le service de persistance pour ce type de SGBD. Hibernate est en effet spcialis dans la persistance Objet / Relationnel. Nous nous sommes donc concentrs directement sur le Framework Spring et plus prcisment sur la branche Spring MVC. Nous nous sommes documents l'aide du document de rfrence et de l'API disponibles sur le site officiel (http://www.springframework.org/documentation). Mme s'il est long et complexe, le document de rfrence de Spring nous a grandement aid pour une meilleure comprhension de l'architecture MVC et du fonctionnement interne du framework. Ainsi, en plus d'une description classique du fonctionnement des composants, on retrouve des commentaires des dveloppeurs expliquant en dtail la raison pour laquelle ils ont propos plusieurs solutions un mme problme et dans quel contexte il faut les utiliser. De plus, nous nous sommes inspir des guides propos par Serge Tah Matre de confrences l'universit d'Angers 86/87
Serveur d'Archivage 2007 Document de conception (http://tahe.developpez.com/). Ses explications nous ont fournis un tremplin au dmarrage du dveloppement du prototype. Le prototype que nous avions produit au bout de cette phase de R&D regroupait des fonctionnalits que nous avons repris dans l'application Serveur Archivage 2007. Ces implmentations taient basiques et non pousses toutes les possibilits mais cela permettait une visibilit qui nous manquait ce moment l. Les points que nous avons dvelopp taient les suivants :

L'authentification (un seul type d'utilisateur). L'intercepteur d'authentification. Le formulaire de dpt d'un seul fichier. Le formulaire simple pour entrer du texte (en prvision des mtadonnes). Plusieurs validateurs de champs de formulaire. Ajout de la librairie de tags de Spring dans les pages JSP. Interfaage avec une couche mtier basique dvelopp pour l'occasion.
Une remarque sur la couche mtier que nous avons mis en place : elle nous a servi pour tester XStream (librairie de conversion JavaBean <-> document XML). Nous avons donc galement t amen dvelopp une couche d'accs aux donnes qui nous permettait de sauvegarder des Beans en XML sur le disque dur puis de les lire et de produire nouveau des JavaBeans. Cela nous a permis d'afficher le contenu de fichiers XML dans nos pages HTML. Nous avons galement brivement suivi la branche des EJB (Enterprise JavaBeans). La technologie des EJB est le composant architectur cot serveur pour la plateforme Java Entreprise Edition. Cette technologie est ancre dans le domaine des service Web et dfinit une API pour la persistance des objets (depuis la version 3.0). Encore une fois, cette solution qui par ailleurs s'intgre bien avec Spring, nous a paru dpassant trop largement les besoins techniques de notre projet, sachant qu'elle ncessitait l'installation d'un serveur d'application comme JBoss ce qui impliquait un risque de plus dans la gestion du temps de R&D. De l'autre cot, l'association Spring / Tomcat 5 tait plus sr car nous nous tions dj exerc ce conteneur de servlet.
87/87

03 ServeurArchivage - DocumentDeConception

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

03 ServeurArchivage - DocumentDeConception

Transféré par

Droits d'auteur :

Formats disponibles

Serveur d'Archivage 2007 Document de conception

Type du document Auteur(s) Date de cration Domaine de diffusion Valid par

Versions 1.0 1.1

Date 28/03/2007 29/03/2007

Auteur(s) Eric Bouladier Eric Bouladier

Modifications Assemblages des diffrentes contributions Corrections erreurs assemblage

Serveur d'Archivage 2007 Document de conception

Serveur d'Archivage 2007 Document de conception

Table des matires

Serveur d'Archivage 2007 Document de conception

1. Description du projet Serveur d'Archivage

2. Ralisation des diagrammes

Serveur d'Archivage 2007 Document de conception

3.2. Rle des utilisateurs

Serveur d'Archivage 2007 Document de conception

3.3.1. Rechercher un document en passant par les mtadonnes

Serveur d'Archivage 2007 Document de conception 3.3.2. Consulter un document

Le document consult doit tre accessible l'internaute.

L'internaute peut demander le tlchargement du document au format PDF.

Serveur d'Archivage 2007 Document de conception

3.4.1. Saisir les mtadonnes

Un jeu de mtadonnes minimal doit tre associ au type de document dpos.

Le dposant doit tre le mme que celui qui a dpos le document.

Serveur d'Archivage 2007 Document de conception

Le dposant doit tre le mme que celui qui a dpos le document.

Serveur d'Archivage 2007 Document de conception

3.5.1. Ajouter un type de document

Le type de document ne doit pas dj tre prsent dans l'application.

Aucun document de ce type ne doit tre prsent sur le serveur d'archivage.

La mtadonne est associe au type de document.

Le document est prt tre export.

Serveur d'Archivage 2007 Document de conception

3.6.1. Paramtrer l'application

L'application est paramtre.

Serveur d'Archivage 2007 Document de conception

4.2. Page d'accueil : point d'entre du serveur d'archivage

Serveur d'Archivage 2007 Document de conception

Serveur d'Archivage 2007 Document de conception

4.4. Recherche de documents

Serveur d'Archivage 2007 Document de conception

4.5. Consultation de document

Serveur d'Archivage 2007 Document de conception

4.6.1. Ajout d'un type de document

Serveur d'Archivage 2007 Document de conception

4.7. Dpt d'un document

Serveur d'Archivage 2007 Document de conception

Serveur d'Archivage 2007 Document de conception

5.2. La couche DAO

Serveur d'Archivage 2007 Document de conception

5.3. La couche de prsentation

Serveur d'Archivage 2007 Document de conception

5.4. Le package Workflow

Serveur d'Archivage 2007 Document de conception

6.2. Authentification d'un utilisateur

Serveur d'Archivage 2007 Document de conception

6.3. Fonction de recherche

Serveur d'Archivage 2007 Document de conception

Serveur d'Archivage 2007 Document de conception

6.3.3. Recherche par mtadonnes

Serveur d'Archivage 2007 Document de conception

6.4. Dpt d'un document

Serveur d'Archivage 2007 Document de conception

Serveur d'Archivage 2007 Document de conception