Conception et développement d un système d information basé sur XML

Transcription

1 Projet de Master Conception et développement d un système d information basé sur XML Tania Magnenat EPFL - Section Informatique Sous la supervision de : Dr. Christine Vanoirbeek Dr. Aida Boukottaya 24 février 2006

2 Table des matières 1 Introduction Cadre général du projet Le Center for Global Computing Motivations Objectifs du projet de Master Le Reporting La gestion du personnel But du projet Contributions et plan Analyse des besoins et choix technologique Analyse des besoins fonctionnels Fonctionnement du management Choix technologique Frameworks Bases de données Étude comparative Conception Architecture Les web services Reporting périodique : les calculs Table Table Form C Financial Report Gestion du personnel Feuilles de temps Formulaires Projet Coûts directs Personnel

3 3.5 Schéma de la base de données Développement du système Services Web Apache Axis Services web déployés Interface Exemple : mise à jour des données d un projet Évaluation Conclusions Travaux futurs et perspectives A Orbeon Presentation Server 54 A.1 XForms A.1.1 XForms, c est quoi? A.1.2 Les contrôles de XForms A.1.3 Combinaisons de balises A.2 Le Page Flow Controller (PFC) A.2.1 page-flow.xml A.2.2 Pages A.2.3 Navigation entre les pages A.3 Le XML Pipeline Definition Language B Schéma de base de données 68 C Installation de l application 72 C.1 Introduction C.1.1 Prérequis C.2 Apache HTTP Server C.2.1 Téléchargement et installation C.2.2 Tester l installation C.3 Apache Tomcat C.3.1 Téléchargement et installation C.3.2 Tester l installation C.4 MySQL Server C.4.1 Téléchargement et installation C.4.2 Tester l installation C.5 Apache Axis C.5.1 Téléchargement et installation C.5.2 Tester l installation C.6 Global Computing Information System C.6.1 Installation du système C.6.2 Configuration des Web Services (Axis) C.6.3 Configuration de la base de données

4 Table des figures 1.1 La structure du CGC L actuel système de reporting L actuel système de gestion du personnel L actuel système de gestion Le futur système de gestion Fonctionnement de Struts Les application JSF sont event-driven Séparation des taches selon Cocoon Modèle traditionnel Le modèle Ajax Possibilités pour stocker des documents XML Architecture du système d information La Table La Table Le Form C Le Financial Report Feuille de temps Le schéma de la base de données La page de bienvenue de l application La liste de projets présents dans la base de données Formulaire pour mettre à jour les données d un projet Cycle pour la mise à jour d un projet Connection directe entre le système d information et le centre financier A.1 XForms A.2 Design d une application grâce au PFC A.3 Entrées et sorties du pipeline du Listing A C.1 Page de test pour l installation de Apache HTTP Server C.2 Page de test pour l installation de Tomcat

5 C.3 Page de test pour l installation de Axis

6 Liste des tableaux 2.1 Comparaison de frameworks Comparaison de base de données relationnelles Comparaison de base de données natives XML Nombre d heures pas rapport au taux d occupation Méthodes de la classe Features.java Méthodes de la classe Persons.java Méthodes de la classe ReportingTables.java Méthodes de la classe TimeSheets.java Méthodes de la classe Projects.java Méthodes de la classe Months.java

7 Listings 4.1 deploy.wsdd undeploy.wsdd Partie de page-flow.xml concernant la mise à jour d un projet getproject.xpl : pour récuperer les données d un projet Formulaire XForms pour la mise à jour d un projet A.1 Le modèle XForms A.2 Modèle A.3 Utilisation de repeat : création d une ligne pour chaque personne A.4 Élimination du dernier élément de la collection A.5 Insertion d un élément avant le dernier élément de la collection A.6 L attribut path-info A.7 L attribut id A.8 Les attributs model et view A.9 Exemple de l utilisation de action et result A.10 Exemple de fichier XPL A.11 Syntaxe du <choose>

8 Chapitre 1 Introduction 1.1 Cadre général du projet Ce travail de Master s est concentré sur la conception et le développement d un système d information basé sur les technologies XML pour le Center for Global Computing [3] Le Center for Global Computing Le Center for Global Computing (CGC) est un centre de compétence interdisciplinaire ancré dans la faculté Informatique & Communication [5] de l EPFL [26]. Sa mission principale est la mise en œuvre et le suivi d activités de recherche (projets, séminaires, formations, etc.) qui encouragent et valorisent une potentielle synergie entre plusieurs laboratoires de l EPFL dans les domaine du global computing et des systèmes distribués. Le centre contribue aussi à la réalisation de projets de développement d environnements intégrés pour valoriser les domaines d expertise des membres du centre ou un résultat spécifique développé par l un des membres. Pour remplir sa mission, le CGC déploie des activités de différentes natures : aide au montage de projets de recherche gestion scientifique et administrative des projets organisation d événements scientifiques CGC LSIR LIA LBD... Fig. 1.1: La structure du CGC 7

9 formation veille scientifique et technologique actions de valorisation Dans ce sens, le CGC est amené à gérer un nombre important d informations qui : sont corrélées (par exemple, un descriptif de projet de recherche fait partie d une demande adressée à un bailleur de fond - Commission Européenne, FNRS, CTI, etc. - une fois accepté pour le financement, le descriptif doit être publié sur le site Web du CGC) doivent être accessibles et/ou mises à jour par différents acteurs (tels que professeurs, chercheurs, étudiants, etc.) en fonction de leur nature : scientifique ou administrative. Par exemple, une publication issue d une recherche sera publiée sur le site du CGC mais sera également intégrée dans un rapport à fournir au bailleur de fonds et alimentera la base de données de l EPFL (la gestion administrative d un projet fait intervenir des aspects financiers tels l engagement de personnel ou le financement de déplacements dont le coût doit respecter un budget). interfèrent avec d autres systèmes d information à l EPFL (le service financier, le service de gestion des ressources humaines, les services informatiques, etc.) Management des projets Le management de projets porte sur deux aspects essentiels : d une part, la gestion administrative et financière, d autre part la gestion scientifique. Pour les projets d une certaine durée, la Commission Européenne attribue le budget global d un projet par tranches : au terme de chacune d elle a lieu une évaluation qui porte sur les deux aspects. C est sur cette base que se négocie la poursuite du projet. Gestion administrative et financière La gestion administrative et financière du projet est la responsabilité du coordinateur du projet, l unique correspondant avec la Commission Européenne. Ses tâches et responsabilités concernent notamment : le reporting par rapport à la commission (aspects financiers) la gestion des conflits éventuels entre partenaires Gestion scientifique La gestion scientifique d un projet concerne essentiellement son orientation scientifique et le respect des deliverables liés aux work packages du projet Motivations Jusqu à maintenant la gestion administrative et financière a été faite à la main (grâce à des feuilles Excel) par le management team du centre. Tant que le nombre de projets n est pas trop grand, le système manuel fonctionne correctement, mais le nombre de projets (ainsi que le nombre de données) est en continuelle augmentation, et la gestion des projets en ressent : le suivi et la maintenance sont toujours plus difficiles, la cohérence des données n est pas toujours garantie, la taille des fichiers est toujours plus grande et le versioning (c est-à-dire la gestion des différentes versions disponibles) est problématique. De plus le système actuel est très répétitif et donc ennuyeux à exécuter tout le temps. Les repercussions de ces problèmes sont notamment la perte d informations et des erreurs dans la gestion. 8

10 Ces problèmes ont donc amené le management team a l idée de structurer les informations et de automatiser le système de gestion. La structuration permettra de automatiser plus facilement les traitements effectués sur les données, une lisibilité majeure et une plus grande accessibilité tandis que l automatisation du système va permettre de générer plus rapidement les documents nécessaire au management. 1.2 Objectifs du projet de Master L objectif de ce projet est l implémentation de deux modules du système d information du CGC : le module de reporting périodique et le module de gestion du personnel qui sont présentés dans les sections suivantes Le Reporting Pendant la durée d un projet, le centre doit préparer des rapports périodiques de gestion [16] (normalement sous forme de tables) pour justifier les dépenses et les ressources déployées sur le projet. Les rapports périodiques (destinés à la Commission Européenne) doivent inclure : 1. Section 1 - Justification of major cost items and resources Cette section contient des justificatifs détaillés sur tous les coûts et sur les ressources déployées pour le projet. Cela inclut les deux tables suivantes : Table 3 : une vue tabulaire des coûts prévus et des coûts actuels (cf. section 3.2.1) Table 4 : une vue tabulaire des personnes-mois prévues et des personnes-mois actuelles (cf. section 3.2.2) 2. Section 2 - Form C Financial statement per activity for the contractual reporting period Cette section constitue un rapport financier récapitulant les dépenses effectivement payées par chaque contractant et éligibles selon le modèle de coût adopté par chaque contractant (cf. section 3.2.3). 3. Section 3 - Summary financial report Contient un sommaire sur les coûts totaux (directs et indirects) en euros (cf. section 3.2.4). État actuel Tous les mois la secrétaire du CGC reporte manuellement les dépenses dans des feuilles Excel. Le coordinateur du projet récupère ensuite les données de ces feuilles pour créer les tables nécessaires au reporting (cf. Figure 1.2) La gestion du personnel Sur chaque projet il peut y avoir une ou plusieurs personnes qui y travaillent. Pour chaque personne il est nécessaire de stocker un certain nombre d informations (telles que nom, prénom, numéro de matricule, adresse,...) afin de gérer les salaires, le taux d occupation et pour générer un certain nombre de formulaires tels que des propositions d engagement, des demandes de mutations ou des feuilles de temps (cf. section 3.3.1). 9

11 Table 3 Table 4 Table 4 bis Fig. 1.2: L actuel système de reporting État actuel Dans ce cas aussi la gestion est faite avec des document Excel et Word. La secrétaire sort les informations des feuilles des salaires et les copie dans une autre feuille qui calcule le nombre d heures en base au taux d occupation de la personne. Ensuite elle copie les chiffres résultants dans un document Word qu elle imprimera par la suite pour le faire signer à la personne concernée (cf. Figure 1.3). Fig. 1.3: L actuel système de gestion du personnel 10

12 1.3 But du projet Le but du projet est donc de comprendre le management de projets pour arriver a structurer les données, automatiser la gestion, stocker de manière sure les informations et accéder à ces données via une interface graphique pour pouvoir les modifier. Le résultat de ce travail devra aboutir à un système automatique capable de remplacer l actuel système manuel. 1.4 Contributions et plan Les principales contributions qui découlent de ce projets sont trois. Avant tout une étude technologique avec une analyse comparative (qui vont être présentées au chapitre 2). Ensuite la conception du système d information qui va aboutir à une architecture générale (cf. chapitre 3). Pour finir une implémentation des modules de reporting et de gestion du personnel afin de substituer l actuel système manuel (cf. chapitre 4). Le chapitre 5 va conclure avec un bilan du projet et des améliorations possibles. 11

13 Chapitre 2 Analyse des besoins et choix technologique L objectif de ce projet est de comprendre le fonctionnement du management des projets afin de pouvoir structurer l information et pour automatiser la gestion. Pour faire cela il est avant tout nécessaire d analyser les besoins fonctionnels que le système devra couvrir. Cette phase d analyse sera présentée à la section 2.1. Un autre point important pour la suite (conception et développement) du projet sont les choix technologique. En effet ces choix vont influencer les performances et les futurs développements de notre application. Il est donc important de choisir des technologies ouvertes de manière à garantir l évolutivité du système d information. Dans la deuxième partie de ce chapitre on va donc présenter des frameworks et des base de données qui pourraient être utilisées pour le développement du système d information du centre. À la fin de cette partie on présentera aussi une analyse comparative et les solutions retenues. 2.1 Analyse des besoins fonctionnels Fonctionnement du management Le système de gestion du CGC fonctionne de la manière suivante (cf. Figure 2.1) : 1. Chaque mois la secrétaire demande les données nécessaires au centre financier ou aux ressources humaines de l EPFL. 2. Après avoir reçu ces données (sous un format propriétaire) elle fait des copier-coller pour les insérer dans des feuilles Excel (séparées par projet). 3. Chaque six mois le coordinateur du projet utilise ces feuilles pour générer le reporting périodique qu il doit rendre à la Commission Européenne. Le système d information dont il est question dans ce projet doit remplacer les points 2 et 3 énoncés ci-dessus avec un ensemble de formulaires pour insérer les données, une interface graphique pour visualiser les données et les tables, et une base de données pour stocker toutes les informations nécessaires (cf. Figure 2.2). 12

14 Centre des Finances Calculs Table 3 Table 4 Form C Ou doit intervenir le systeme d information Fig. 2.1: L actuel système de gestion Centre des Finances Interface Table 3 Table 4 Form C Formulaires DB Fig. 2.2: Le futur système de gestion 13

15 2.2 Choix technologique Dans cette section on va présenter les frameworks et les base de données disponibles actuellement afin de faire une étude comparative pour trouver la solution la plus adéquate Frameworks Définition Un framework est une infrastructure logicielle qui facilite la conception d applications par l utilisation de bibliothèques, de classes ou de générateurs de programmes. Ce cadre permet une meilleure structuration des différents éléments d une application, une meilleure flexibilité ainsi qu une séparation entre la couche de présentation et les autres couches (transactions et données). Pourquoi utiliser un framework À l heure ou les pages des sites web deviennent toujours complexes et intègrent de plus en plus de fonctionnalités, le modèle qui consiste à générer manuellement les pages HTML (sous forme de flux de caractères) est devenu trop compliqué à garder à jour. L utilisation d un framework devient donc indispensable afin que l on puisse bien séparer les différentes couches et le travail : de cette manière le graphiste pourra travailler sans se soucier de la logique (c est-à-dire quand et comment naviguer entre les différentes parties et comment traiter les données) et le développeur pourra coder l application sans devoir maîtriser le graphisme. Jakarta Struts Struts[8] est un cadre de développement open source pour des applications web. Il facilite la séparation entre la couche présentation et les autres couches (transactions et données) : il permet en effet aux développeurs de construire des services sans se soucier du code HTML qu il y a autour. Il est basé sur l architecture Modèle-Vue-Contrôleur (MVC), les technologies JSP, servlets et Java- Beans et nécessite d un serveur HTTP muni d un moteur de servlets (comme JServ ou Tomcat). Plusieurs vues peuvent être utilisées, permettant l accès à l application pour un grand nombre de plate-formes, du web traditionnel (HTTP) aux technologies sans fil (WAP, Palm). Le développement peut ainsi être totalement dissocié entre contrôleur (Java) et vues (HTML et JSP). Struts peut donc être une bonne alternative au développement basé sur les servlets et JSP, d autant que ses divers composants sont des standards établis. La conception MVC Pour mieux comprendre le fonctionnement et l architecture de Struts il faut comprendre ce qui se trouve à la base : le modèle de conception Modèle-Vue-Contrôleur. Ce modèle se décompose, comme son nom l indique, en trois composants (cf. Figure 2.3) : 1. Le Modèle d une application est composé de deux sous-systèmes : l état interne du système et les actions possibles pour modifier cet état. Struts permet d utiliser de nombreuses approches différentes pour accéder au modèle, comme les JavaBeans, les classes ou une base de données (cela dépend généralement de la taille du projet et de l approche utilisée). 2. La Vue est construite à l aide de pages JSP contenant du texte HTML ou XML statique, et ayant la capacité d y insérer selon les requêtes du contenu dynamique. Struts comprend une bibliothèque interne de balises qui facilitent la création d interfaces utilisateur, et interagissent sans problème avec le modèle. 3. Le Contrôleur est le composant le plus important d une application Struts, en effet c est lui le centre névralgique. Cette servlet délègue les requêtes HTTP vers le gestionnaire approprié, qui est lié à un modèle. Ainsi, chaque gestionnaire agit comme un adaptateur entre la requête et le modèle. Le contrôleur passe ensuite par la vue pour gérer le modèle, ce qui créé une 14

16 forme de liaison entre vue et modèle. Controleur (Servlet) Requetes Serveur Web Modele (Bean) Vue (JSP) Fig. 2.3: Fonctionnement de Struts Java Server Faces Java Server Faces [9] est une technologie qui propose un framework open source qui facilite et standardise le développement d applications web avec Java. Son développement a tenu compte des différentes expériences acquises lors de l utilisation des technologies standards pour le développement d applications web (servlet, JSP, JSTL) et de différents frameworks (comme Struts). JSF est un standard J2EE inclus dans Java 1.5 (c est une sorte de standardisation de Struts) et est basé sur les technologies JSP et servlet. Java Server Faces est une technologie utilisée côté serveur dont le but est de faciliter le développement de l interface utilisateur en séparant clairement la partie interface de la partie logique. De plus il permet une liaison simple entre les actions (côté client) de l utilisateur et le code Java correspondant (côté serveur). La technologie JSF contient : un ensemble de API pour représenter des composantes graphiques, pour gérer et manipuler leur état et les entrées (données rentrées pas l utilisateur) ; une librairie de balises JSP pour exprimer une interface JSF à l intérieur d une page JSP. À quoi ressemble une application JSF? Un application JSF ressemble beaucoup aux applications basées sur les servlets et JSP et elle est composée d un descripteur pour le deployement, des pages JSP et de librairies de balises. L interface utilisateur est l une des nombreuses pages JSP qui composent l application et accueille des composants tels que des formulaires ou des boutons. Comme une simple application servlet/jsp on peut utiliser des JavaBeans pour stocker les données insérées par l utilisateur. Comment marche JSF? Une application JSF fonctionne en traitant les évènements (causés par les actions de l utilisateur) déclenchés par les composants JSF dans les pages. Le développeur décide quoi faire quand un certain événement est déclenché en écrivant des event listeners (cf. Figure 2.4). 15

17 Page JSP Nom Prenom Evenement Reponse Faces Servlet Login Event Listener Fig. 2.4: Les application JSF sont event-driven Apache Cocoon Apache Cocoon [1] est un framework de publication open source écrit en Java qui repose sur les technologies XML pour fournir du contenu web. Utilisation du MVC Cocoon vise à une séparation complète des trois couches (contenu, style et logique), leur permettant d être conçues, crées et gérées indépendamment, réduisant ainsi la charge de gestion et augmentant la possibilité de réutilisation du travail. Le modèle Cocoon permet aux sites web d être hautement structurés et bien construits, réduisant les efforts de duplication et les coûts de gestion de sites en permettant différentes présentations de la même donnée selon la requête du client. Ce modèle est composé de 4 contextes de travail différents : Gestion Logique Contenu Style Fig. 2.5: Séparation des taches selon Cocoon 1. Gestion : personnes qui décident du contenu du site, de son comportement, et de son apparence. 2. Contenu : personnes responsables d écrire et gérer le contenu du site. Ce contexte est susceptible de contenir de nombreux sous contextes, un pour chaque langage utilisé pour exprimer le contenu des pages. 3. Logique : personnes responsables de l intégration avec les technologies de génération de contenu dynamique et les systèmes de base de données. 4. Style : personnes responsables de la présentation de l information, aspect et apparence, graphique du site et sa maintenance. 16

18 Notion de pipeline Cocoon implémente la notion de pipeline, c est-à-dire le traitement des requêtes de manière Lego (enchaînement des opérations). Cette notion de pipeline suit l idée de la programmation par flux de transformations : chaque unité de flux de transformation peut être enchaînée avec une autre pour composer une transformation plus complexe. Différents formats de sortie Même si la principale utilisation de Cocoon est la création automatique de code HTML au travers du traitement de fichiers XML générés statiquement ou dynamiquement, Cocoon est aussi capable de réaliser des formatages plus compliqués, comme le rendu XSL:FO sur du PDF, des transformations dépendantes du client comme le formatage WML pour les périphériques WAP ou le service XML direct pour des clients XML ou XSL, ou bien alors des formats de type JPEG, ZIP, SWF,.... Nombreuses sources de données La publication web est très limitée sans la possibilité de créer du contenu dynamique. Pour cette raison l équipe responsable de Cocoon a beaucoup travaillé pour permettre la génération de contenu XML dynamique. Voici ce qui est actuellement implementé : Le processeur XSLT qui applique des transformations XSLT au document en entrée. Le processeur DCP qui évalue les instructions de traitement XML avec une logique multilangage (Java et EcmaScript). Ce processeur permet de réaliser des substitutions et inclusions programmées en éliminant le recours à une logique de traitement complexe. Le processeur SQL qui évalue des balises simples décrivant les requêtes SQL aux drivers JDBC et qui formate leur ensemble-résultat en XML, selon les paramètres donnés. Orbeon Presentation Server Orbeon Presentation Server [14] (OPS) est un système de publication web basé sur les technologies XML et comparable au projet Cocoon (cf. section 2.2.1) du consortium Apache. Il est écrit en Java et repose sur la notion de flux de documents XML décrits sous forme de pipelines. Les principales différences techniques entre OPS et Cocoon résident dans le langage de description des pipelines, plus complet (et plus complexe) dans le cas de OPS et dans la description des formulaires de saisie. En effet Cocoon a choisi un format pour ses formulaires basé sur un langage qui lui est propre tandis que OPS propose une utilisation de la recommandation W3C [19] XForms 1.0 [20]. L utilisation de XForms apporte beaucoup d avantages tels que l indépendance de la plate-forme, la séparation entre les données et la présentation, un modèle des données flexible et structuré et des facilités pour la validation des données. L utilisation d Ajax (Asynchronous JavaScript And XML) dans OPS permet de limiter l impact des allers/retours entre client et serveur, en effet cela permet de stocker l état sur le poste client et d éviter ainsi d avoir à gérer des sessions sur le serveur (cf. Figure 2.7). Les technologies Ajax permettent de déporter des traitements au niveau du navigateur grâce à des échanges effectués de manière asynchrone en XML sur le protocole HTTP entre le navigateur et le serveur. 17

19 Client Action + Soumission Action + Soumission Reponse + Affichage Reponse + Affichage Serveur Traitement cote serveur Traitement cote serveur Fig. 2.6: Modèle traditionnel Client Browser Action Action Action Affichage Affichage Action Affichage Affichage Ajax Engine Requete XML Reponse XML Requete XML Reponse XML Requete XML Serveur Traitement cote serveur Traitement cote serveur Traitement cote serveur Bases de données Fig. 2.7: Le modèle Ajax Dans cette section on va commencer avec quelques explications concernant le choix d où stocker des documents XML. Par la suite on présentera des bases de données (relationnelles et natives XML) afin de faire une étude comparative et de choisir la plus adaptée au système d information. 18

20 Comment choisir la base de données? Le choix d où stocker les documents XML dépend du type de document, de la nature des manipulations à réaliser sur ces documents et de la granularité nécessaire. Probablement le facteur le plus important lors du choix est de connaître le type de documents (orientés données ou orientés documents) que l on va stocker dans la base de données. Documents centrés données Les contenus orientés données utilisent XML en tant que vecteur de données entre la base et une application : ils sont en effet utilisés pour le transport et l échange de données et le fait que XML soit utilisé est généralement accessoire. De plus ils sont conçus pour être exploités par une machine et l ordre des données n est pas significatif. Ce type de document est caractérisé par une structure assez régulière et des données qui présentent une granularité fine (c est-à-dire que la plus petite unité indépendante de donnée est située au niveau d un attribut). Les données que l on trouve dans ce type de documents peuvent à la fois être originaires de la base (auquel cas on les publie sous forme XML) ou être situées en dehors de la base (et on les stocke alors dans la base). Un exemple du premier cas est fourni par la très grande quantité de données déjà existantes stockées dans les bases relationnelles ; un exemple du second cas est constitué par les données scientifiques collectées par un système de mesure et converties au format XML. Les ordres de ventes, les prévisions de vols, les données scientifiques et les cotations du marché constituent quelques exemples de contenus orientés données. Documents centrés document Les documents XML orientés document sont habituellement conçus pour être utilisés par des humains et l ordre des éléments et des données est significatif. Ils sont caractérisés par une structure moins régulière ou même franchement irrégulière et des données qui présentent une granularité plus grande. Les contenus orientés document sont ordinairement écrits manuellement en XML ou sous d autres formats tels que RTF, PDF ou SGML, puis ils sont convertis en XML. À la différence des documents orientés données, ils ne sont habituellement pas localisés dans la base (les documents générés à partir de données insérées dans un modèle sont en fait orientés données). Les livres, les messages électroniques, les annonces et presque toutes les pages XHTML constituent quelques exemples de contenus orientés document. Où stocker les documents XML? Il existe plusieurs possibilités pour stocker des documents XML [27] : les enregistrer sur un système de fichiers, les enregistrer sur une base de données relationnelles sous forme de blob ou en faisant un mapping ou les stocker dans une base de données native XML (cf. Figure 2.8). Enregistrement dans un système de fichiers C est une possibilité qui fonctionne bien si on possède un ensemble élémentaire de documents à gérer. Des recherches plein texte sur des documents XML sont évidemment inexactes car elles ne peuvent pas facilement distinguer les balises du texte et ne peuvent pas interpréter l usage des entité. Dans un petit système de telle inexactitudes peuvent être acceptables mais dans un grand système non. Si on souhaite disposer d un contrôle de transaction simple, on peut par exemple placer les documents dans un système de contrôle tel que CVS ou RCS. Utilisation des blobs dans une base de données relationnelle Un blob est une séquence de données binaires de taille arbitraire servant à stocker des données que l on ne peut pas stocker en utilisant les types natifs disponibles dans les bases de données relationnelles. 19

21 XML Document XML Système de fichiers BLOB Base de donnée classique Base de données native XML Fig. 2.8: Possibilités pour stocker des documents XML C est une option déjà plus sophistiqué par rapport au simple système de fichiers et apporte certains avantages propres aux bases de données : contrôle de transaction, sécurité, accès multi-utilisateur, etc. Si on choisit ce type de stockage, la granularité est le document entier et une application doit recourir au parsing classique pour reconstruire le document à partir des données extraites de la base. On utilisera donc des blobs dans une base de données relationnelle pour stocker des contenus centrés document. BLOB Document XML Base de données classique Mapping du schéma Ce type de stockage aussi apporte certains avantages propres au base de données tels que ceux cités auparavant. Dans ce cas la granularité est généralement l élément ou l attribut et l application peut se baser sur l interrogation de la base de données pour manipuler les documents. On utilisera donc un mapping du schéma pour stocker des documents orientés données. 20

22 Mapping Structures XML Schémas de base de données La correspondance entre le schéma du document et le schéma de la base de données n est pas toujours une méthode efficace pour stocker des documents XML, en effet on risque d utiliser un grand nombre de tables et de colonnes (qui provoquent une perte de performance) et un grand nombre de jointures (qui entraînent une perte de vitesse). De plus on risque le round tripping, c està-dire la perte d informations entre les différents mapping, et la maintenance d une application basée sur ce type de stockage pourrait être coûteuse à cause de l évolution des documents XML. Stockage dans une base de données native XML Une base de données native XML est une base de données spécifiquement conçue pour XML : le modèle est conçu pour le stockage et l accès à des arbres ordonnés et le document XML est l unité fondamentale du stockage (tout comme une ligne d une table constitue l unité fondamentale du stockage dans une base relationnelle). L intérêt d utiliser ce type de base de données réside dans le chargement efficace de gros documents, dans les mises à jour efficaces et dans la récupération des données sans pertes d informations. Comme expliqué au paragraphe précédent, le mapping d un schéma pour une base de données relationnelle n est pas une méthode optimale pour stocker des documents XML à cause de la grande taille des tables que l on doit utiliser. De plus, si ces outils sont utilisés pour traduire des données en direct lors d un échange XML, cela risque d augmenter les temps de traitement des transactions XML et de ralentir également les autres applications qui accèdent à la base de données relationnelle. Une base de données native XML permet d accéder, de rechercher, de stocker, d échanger, de gérer et de réutiliser des documents au format XML avec une majeure rapidité et sans besoin du mapping et des restructurations nécessaires avec les bases de données traditionnelles. Un des gros désavantages réside dans le fait que ce type de base de données peut renvoyer seulement des données sous forme XML : si on a besoin des données dans un autre format on doit analyser le XML renvoyé avant de pouvoir les utiliser. Bases de données relationnelles MySQL MySQL [10] est une base de données SQL open source multithread, robuste et multiutilisateurs. Le standard ANSI SQL n est pas complètement implementé et à partir de la version 5.0 elle gère aussi les transactions. Cette base de données fonctionne sur différentes plate-formes et est interfaçable avec de nombreux langages (tels que Java, C, C++, Perl, etc.). PostgreSQL PostgreSQL [15] est un système de gestion de base de données open source relationnel et objet. Il est pratiquement conforme aux normes ANSI SQL et, comme MySQL, fonctionne sur différentes plate-formes et est interfaçable avec de nombreux langages. 21

23 Bases de données natives XML Tamino XML Server Tamino XML Server est un serveur d informations dédié au stockage, à la gestion, à la publication et à l échange de documents XML et qui nécessite d une licence payante. Tamino XML Server stocke les documents XML de manière entièrement native : le stockage est direct sans aucune conversion vers une quelconque autre structure ; ce qui rend Tamino très performant dans la recherche et la restitution de documents. Tamino XML Server est une base de données native XML (NXD), facile à intégrer dans les applications et multi-utilisateurs : il accepte en effet les connexions simultanées en gérant la sécurité (identification, authentification, contrôle des droits), les sessions et les transactions. Le protocole de communication de Tamino est le protocole standard du Web : HTTP. Cette base de données respecte les standards W3C : elle supporte les Namespaces et les schémas XML W3C et elle implémente le langage de requêtes XQuery. En plus elle indexe les documents XML et les documents non-xml et valide les documents XML. Tamino tourne sur plusieurs plate-formes (AIX, SUN Solaris, HP-UX, Linux et Windows 2000 /XP/2003) et intègre un serveur WebDAV qui permet de proposer des fonctions de travail collaboratif sur le Web en gérant les accès multi-utilisateurs aux mêmes documents, les différentes versions des documents (Delta-V) et les métadonnées. La mise à jour des documents XML stockés dans Tamino s applique au document complet ou simplement à l un de ses nœuds (NodeLevelUpdate). Cette spécificité augmente les performances de Tamino, en particulier pour les documents volumineux (performances accrues et réduction du trafic réseau). exists exists [4] est une base de données XML légère écrite en Java. Elle peut être déployée de différentes manières (processus autonome, dans un moteur de servlet ou directement incorporée dans une application) et supporte XQuery, XPath 2.0 et XUpdate. C est une base de données multi-utilisateurs qui n a aucun support des transactions. Xindice Xindice [21] est une base de données XML écrite en Java. Elle peut stocker beaucoup de petits documents XML et aussi des documents non XML. Cette base de données supporte XPath et XUpdate et est accessible à partir de langages comme Perl ou PHP Étude comparative Pour choisir les technologies à utiliser pour le développement de l application il est maintenant nécessaire de faire une étude comparative. De cette manière on pourra clairement voir les avantages et les défauts de chacune des technologies présentées aux sections précédentes. Frameworks On peut diviser les frameworks en deux groupes : Struts et JSF sont basés sur des techniques standard pour le développement web (Servlets, JSP, etc.) tandis que Cocoon et Orbeon Presentation Server sont basés sur les technologies XML. JSF et Struts sont très similaires ; JSF est juste une sorte de standardisation de Struts et est donc plus récent. En ce qui concerne les deux frameworks basé sur XML, on peut remarquer que le langage de pipeline proposé par Orbeon est plus complet par rapport à celui de Cocoon ; de plus Orbeon utilise un standard du W3C pour les formulaires, tandis que Cocoon utilise un format propre. Le Tableau 2.1 résume les principales caractéristiques des frameworks présentés à la section et nous aide dans la comparaison. 22

24 Struts JSF Cocoon OPS Open Source Oui Usage du MVC Oui Non Oui Validation Serveur Serveur Serveur Client Technologies Servlets, JSP,... XML Standard XML Non Oui Pipelines Non Oui Tab. 2.1: Comparaison de frameworks Base de données Pour l étude comparative des bases de données, on a préféré séparer les bases de données relationnelles de celles natives XML. Cela parce que la méthode de stockage est différente (orienté données pour les premières et orientée documents pour les autres) et donc les caractéristiques à comparer sont différentes. MySQL vs. PostgreSQL MySQL et PostgreSQL sont, grâce à leur stabilité, flexibilité et performances, les deux base de données relationnelles open source les plus utilisées actuellement. Avec la récente sortie de MySQL 5 qui supporte les transactions, on peut dire que les deux bases de données sont pratiquement équivalentes. La plus grande différence réside dans les licences : MySQL est disponible sous licence open source (GPL) tant que l application est aussi GPL et sous forme commerciale quand l application est non GPL. Par contre la licence BSD de PostgreSQL est plus permissive et permet aussi l utilisation en open source même pour des applications non open source. Le Tableau 2.2 [13] résume les principales caractéristiques de ces deux bases de données et nous aide dans la comparaison. MySQL 5.0 PostgreSQL Licence GPL et commerciale BSD Plate-formes Windows, Linux, Solaris,... Conformité aux standard SQL Moyenne Haute Stabilité Haute - Très haute Haute Vitesse Moyenne - Haute Moyenne Dispositifs de sécurité Moyen Moyen - Haut Support de la concurrence Oui Support des transactions Oui Tab. 2.2: Comparaison de base de données relationnelles Tamino XML Server vs. exists vs. Xindice Tamino, exists et Xindice sont actuellement les trois base de données qui stockent nativement des documents XML les plus connues. Par rapport aux bases de données relationnelles, on remarque qu il y a d assez grandes différences entre ces base de données natives XML. Tamino est une excellente base de données (qui a été testée lors d un projet de semestre) qui supporte les transactions et la concurrence et offre une sécurité assez haute. Son plus grand défaut est le fait d avoir besoin d une licence payante pour pouvoir 23

25 l utiliser. exists semble aussi une assez bonne base de données : elle tourne sur plusieurs plateformes et supporte beaucoup de standards du W3C. Par contre elle ne gère pas les transactions et ses dispositifs de sécurité et de gestion de la concurrence ne sont pas très développés. Au contraire des deux autres bases de données XML, Xindice donne la forte impression d être une version pas encore terminée et pour être utilisée dans un projet de grande envergure il faudrait attendre qu elle soit développée un peu plus. En effet elle ne gère ni les transactions ni la concurrence, n a aucun dispositif de sécurité et la taille limitée des documents peut poser problème. Le Tableau 2.3 résume les principales caractéristiques de ces base de données et nous aide dans la comparaison. Tamino exists Xindice Licence Commerciale GPL Plate-formes Windows, Unix Multi-Utilisateurs Oui Oui (basique) Non Dispositifs de sécurité Oui Oui (basique) Non Mises à jour Document et nœud Standards XML XML Schema, XQuery, XPath, XPath, XUpdate XQuery, XPath, XInclude, XPointer, Namespaces, XSL XSL, XUpdate Transactions Oui Non APIs Java, C, PHP, Java, Python, PHP Java.NET, JScript Tab. 2.3: Comparaison de base de données natives XML Solutions retenues Pour terminer cette étude comparative, il a fallu choisir les technologies les plus adéquates pour le développement d un système d information tel que celui présenté à la Figure 2.2. On va donc conclure cette partie en présentant le framework et la base de données retenus pour la suite du projet et en expliquant les raisons de ces choix. Frameworks L atout indéniable de tous ces frameworks est la séparation entre la couche de présentation et les autres couches. Comme déjà dit, cela permet une meilleure structuration des différents éléments et une meilleure division du travail à exécuter. Le principal défaut d un framework est le temps d apprentissage : en effet avant de pouvoir concevoir une application il est nécessaire un certain temps (qui peut varier selon le framework utilisé) pour bien comprendre son fonctionnement et ses mécanismes. Vu que l idée de base de ce projet était d utiliser les technologies XML, les deux frameworks qui ont retenu le plus notre attention ont été Cocoon et Orbeon Presentation Server, c est à dire ceux qui reposent sur les technologies XML. Le choix final c est posé sur Orbeon Presentation Server, et cela pour les raisons suivantes : 1. OPS utilise la recommandation W3C Xforms 1.0 pour les formulaires, tandis que Cocoon utilise un format basé sur un langage qui lui est propre. L utilisation d un standard du W3C va sûrement permettre une meilleure évolutivité du système. 2. Le langage de pipeline créé par Orbeon (XML Pipeline Language) est plus complet que celui de Cocoon. Actuellement ce langage n est pas un standard, mais Orbeon l a soumis au W3C pour le faire devenir un standard du W3C [24]. 24

26 3. L utilisation de Ajax qui permet une validation directe des formulaire du côté du client au lieu de faire de continus allers/retours de données entre le client et le serveur nous semble très intéressante et surtout très utile car cela nous évite d écrire du code pour valider les formulaires du côté du serveur. Base de données Le choix concernant la base de données a été très difficile à faire. Étant donnée que l on voulait utiliser les technologies XML pour notre système d information, on aurait voulu utiliser une base de données native XML afin d éviter de faire continuellement des mapping de schéma. Malheureusement cela n a pas été possible parce que l on n a pas réussi à trouver une solution XML qui nous satisfasse totalement, c est-à-dire open source, robuste et avec une bonne gestion de la sécurité et des transactions. Après longue réflexion, le choix final est tombé sur la dernière version de MySQL : MySQL 5.0. Cela parce que MySQL est la base de données open source la plus populaire au monde grâce à sa performance, sa fiabilité et sa simplicité d utilisation. De plus MySQL offre des fonctions de sécurité qui garantissent une bonne protection des données (seuls les utilisateurs autorisés ont accès au serveur de la base de données), et la protection des données est un point essentiel pour des applications comme celle qu on veut développer pour le centre. Après cette phase d analyse des besoins et d étude technologique, on va passer à la deuxième partie de ce projet, c est-à-dire la conception du système d information. 25

27 Chapitre 3 Conception La deuxième partie de ce projet consiste dans la conception du système d information. On rappelle que l objectif de ce projet est de bien structurer les informations afin d arriver à automatiser le système de gestion du CGC et la conception est donc une phase très importante pour arriver à ce but. Après la présentation de l architecture du système, dans ce chapitre on va étudier en détails les tables de reporting et les feuilles de temps pour arriver à la proposition d un schéma pour la base de données et d un ensemble de formulaires pour l insertion des données. 3.1 Architecture Comme on la vu à la section 2.2.3, les technologies retenues pour le développement du système d information sont Orbeon Presentation Server (cf. annexe A) et MySQL. Entre OPS et MySQL on a décidé de placer une couche de web services afin d avoir une architecture SOA. Architecture SOA Une architecture orientée services (notée SOA pour Services Oriented Architecture) est une architecture logicielle s appuyant sur un ensemble de services. L objectif d une telle architecture est de décomposer une fonctionnalité en un ensemble de fonctions basiques, appelées services, fournies par des composants et de décrire finement le schéma d interaction entre ces services. L idée sous-jacente est de cesser de construire la vie de l entreprise autour d une applications tout-en-un pour faire en sorte de construire une architecture logicielle globale décomposées en services correspondant aux processus métiers de l entreprise. Pourquoi utiliser une architecture SOA architecture orientée services sont : Les principaux avantages lors de l utilisation d une Une modularité permettant de remplacer facilement un composant (service) par un autre Une réutilisabilité possible des composants (par opposition à une système tout-en-un fait sur mesure pour une organisation). De meilleures possibilités d évolution (il suffit de faire évoluer un service ou d ajouter un nouveau service) Une maintenance plus facile L application développée pendant ce projet est donc divisée en trois parties (cf. Figure 3.1) : 26

28 WS Form. WS WS Form. WS MySQL XSLT OPS WS WS Fig. 3.1: Architecture du système d information 1. Orbeon Presentation Server s occupe de la partie interface. Il est en effet responsable de tout ce qui est insertion et mise à jour (grâce à des formulaires web) et visualisation (normalement sous forme de tables générées grâce à des feuilles XSLT) des données. 2. La base de données MySQL où sont stockées toutes les données du système. 3. Un ensemble de web services qui s occupent de relier OPS à la base de données. N importe quelle requête (insertion, mise à jour ou visualisation des données) passe en effet par un services web. Par exemple si on veut sauvegarder les données d un personne travaillant sur un projet, le web service va recevoir (du formulaire) les données concernant cette personne et, grâce à une requête SQL, il va les insérer dans la base de données Les web services Définition Un service Web est un composant logiciel représentant une fonction applicative (ou un service applicatif). Il est accessible depuis une autre application (un client, un serveur ou un autre service Web) à travers le réseaux Internet en utilisant les protocoles de transports disponibles. Ce service applicatif peut être implémenté comme une application autonome ou comme un ensemble d applications. Il s agit d une technologie permettant à des applications de dialoguer à distance via Internet, et ceci indépendamment des plate-formes et des langages sur lesquelles elles reposent. Pour ce faire, les services web s appuient sur un ensemble de protocoles standardisant les modes d invocation mutuels de composants applicatifs. Ces protocoles sont répartis selon quatre axes : 1. Couche de transport (HTTP, FTP ou SMTP) : cette couche s occupe de transporter les messages entre les applications. 2. Messages XML (SOAP) : il s agit de formaliser les messages à l aide d un vocabulaire XML commun. 3. Description des services (WSDL) : il s agit de la description de l interface publique des services Web. 27