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

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

Table des matières 1 Introduction 7 1.1 Cadre général du projet................................. 7 1.1.1 Le Center for Global Computing........................ 7 1.1.2 Motivations.................................... 8 1.2 Objectifs du projet de Master.............................. 9 1.2.1 Le Reporting................................... 9 1.2.2 La gestion du personnel............................. 9 1.3 But du projet....................................... 11 1.4 Contributions et plan.................................. 11 2 Analyse des besoins et choix technologique 12 2.1 Analyse des besoins fonctionnels............................ 12 2.1.1 Fonctionnement du management........................ 12 2.2 Choix technologique................................... 14 2.2.1 Frameworks.................................... 14 2.2.2 Bases de données................................. 18 2.2.3 Étude comparative................................ 22 3 Conception 26 3.1 Architecture........................................ 26 3.1.1 Les web services................................. 27 3.2 Reporting périodique : les calculs............................ 28 3.2.1 Table 3...................................... 28 3.2.2 Table 4...................................... 30 3.2.3 Form C...................................... 31 3.2.4 Financial Report................................. 32 3.3 Gestion du personnel................................... 32 3.3.1 Feuilles de temps................................. 33 3.4 Formulaires........................................ 34 3.4.1 Projet....................................... 34 3.4.2 Coûts directs................................... 34 3.4.3 Personnel..................................... 36 1

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

Table des figures 1.1 La structure du CGC.................................. 7 1.2 L actuel système de reporting.............................. 10 1.3 L actuel système de gestion du personnel........................ 10 2.1 L actuel système de gestion............................... 13 2.2 Le futur système de gestion............................... 13 2.3 Fonctionnement de Struts................................ 15 2.4 Les application JSF sont event-driven......................... 16 2.5 Séparation des taches selon Cocoon........................... 16 2.6 Modèle traditionnel.................................... 18 2.7 Le modèle Ajax...................................... 18 2.8 Possibilités pour stocker des documents XML..................... 20 3.1 Architecture du système d information......................... 27 3.2 La Table 3......................................... 29 3.3 La Table 4......................................... 30 3.4 Le Form C........................................ 31 3.5 Le Financial Report................................... 32 3.6 Feuille de temps..................................... 33 3.7 Le schéma de la base de données............................ 37 4.1 La page de bienvenue de l application......................... 45 4.2 La liste de projets présents dans la base de données.................. 45 4.3 Formulaire pour mettre à jour les données d un projet................ 46 4.4 Cycle pour la mise à jour d un projet.......................... 49 5.1 Connection directe entre le système d information et le centre financier....... 52 A.1 XForms.......................................... 54 A.2 Design d une application grâce au PFC........................ 63 A.3 Entrées et sorties du pipeline du Listing A.10..................... 65 C.1 Page de test pour l installation de Apache HTTP Server............... 73 C.2 Page de test pour l installation de Tomcat....................... 74 3

C.3 Page de test pour l installation de Axis......................... 76 4

Liste des tableaux 2.1 Comparaison de frameworks............................... 23 2.2 Comparaison de base de données relationnelles.................... 23 2.3 Comparaison de base de données natives XML.................... 24 3.1 Nombre d heures pas rapport au taux d occupation.................. 33 4.1 Méthodes de la classe Features.java......................... 41 4.2 Méthodes de la classe Persons.java.......................... 41 4.3 Méthodes de la classe ReportingTables.java..................... 42 4.4 Méthodes de la classe TimeSheets.java........................ 42 4.5 Méthodes de la classe Projects.java......................... 42 4.6 Méthodes de la classe Months.java........................... 43 5

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

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]. 1.1.1 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

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. 1.1.2 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

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. 1.2.1 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). 1.2.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

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

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

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 2.1.1 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

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

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. 2.2.1 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

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

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

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

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 2.2.2 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

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

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

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

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. 2.2.3 É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 2.2.1 et nous aide dans la comparaison. 22

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

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

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

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

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. 3.1.1 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

4. Recherche de service (UDDI) : il s agit de la centralisation des services Web (de leurs descriptions) dans un référentiel commun. Un service web peut donc être compris comme une application exécutable disponible en selfservice pour être utilisée par des clients (entreprises, applications, etc). Le service web est ainsi exposé sur le Web, avec la description de son fonctionnement et des paramètres dont il a besoin pour fonctionner. L un des énormes avantages est par exemple, de pouvoir utiliser un service web développé en Java sous Unix, dans une application tournant en Visual Basic dans un environnement.net de Microsoft, puisque l ensemble du dialogue se fera via des standards XML. 3.2 Reporting périodique : les calculs Afin de pouvoir structurer correctement les informations concernant les dépenses des projets, il est maintenant nécessaire de comprendre comment fonctionnent les tables de reporting qui sont générées périodiquement par le coordinateur du projet. Dans cette section on trouve donc une petite présentation des différentes coûts d un projet ainsi les descriptions et les formules nécessaires à la création des différentes tables. Les dépenses pour un projet peuvent être séparées en deux catégories, directes et indirectes. Les coûts indirects sont tous les coûts d administration, d assurances et de maintenance alors que les coûts directs sont tous les coûts indispensables au développement du projet, c est-à-dire : coûts du personnel coûts des voyages coûts des consommables coûts des équipements autres coûts (tels que traductions, coûts bancaires, etc.) 3.2.1 Table 3 La Table 3 (cf. Figure 3.2) représente une vue tabulaire des coûts prévus et des coûts actuels et sert à justifier en détails les dépenses et les ressources déployées pour un certain projet. Les calculs nécessaires à la génération de cette table sont expliqués dans les équations 3.1 à 3.8. A Total des personnes-mois = P MCommitted T otalmonths Months (3.1) B Budget pour le personnel (en Euro) = T otalmonths F undedduration Budget T otalbudget T otal ConversionRate 100 100 + IndirectCostsF latrate (3.2) Ou :. Budget = P ersonalbudget. T otalbudget = P ersonal,t ravel,consomable,equipment,other Budget. T otal = T otalbudget + T otalindirectcosts 28

A D C E F G B H Fig. 3.2: La Table 3 C Coûts du personnel = P eriod P ersonalcosts (3.3) D Total des personnes-mois pour une certaine période = P eriod P ersonalcosts T otalp ersonmonth (3.4) P ersonalcost Budget ou P ersonalcost Budget = 3.2 E Total = P eriods (3.5) F Pourcent dépensé = G Somme restante = H Coûts directs = T otalspent Budget (3.6) Budget T otalspent (3.7) P ersonal + T ravel + Consumables + Equipment + Other (3.8) 29

3.2.2 Table 4 La Table 4 (cf. Figure 3.3) représente une vue tabulaire des personnes-mois prévues et des personnes-mois actuelles. Elle sert à justifier les dépenses du personnel sur un projet. Les calculs nécessaires à la génération de cette table sont expliqués dans les équations 3.9 à 3.12. Personne-Mois Un PM est une unité de mesure de l effort investi dans un projet en termes de ressources humaines. Si par exemple on engage deux personnes, l une a 100% pendant un an, l autre a 50% pendant 18 mois, cela représente au total (12 PM + 9PM) = 21 PM. A B C D Fig. 3.3: La Table 4 A Personnes-mois planifiées = B Personnes-mois actuelles = P M Committed ReportedM onths CommittedM onths P MCommitted T otalmonths CommittedDuration P eriod P ersonnalcosts P ersonalbudget (3.9) (3.10) 30

ou P ersonalbudget = Équation 3.2 C Personnes-mois planifiées (total) = W P P M Committed ReportedM onths CommittedM onths (3.11) D Personnes-mois actuelles (total) = 3.2.3 Form C P MActual (3.12) W P Ce formulaire 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. Les calculs nécessaires à la génération de ce formulaire sont expliqués dans les équations 3.13 à 3.15. A B C Fig. 3.4: Le Form C A Coûts directs (pour cette période) = (P ersonal + T ravel + Consomable + Equipment + Other = (3.13) P eriod B Coûts indirects = C Coûts Totaux = DirectCosts 20% (3.14) DirectCosts + IndirectCosts (3.15) 31

3.2.4 Financial Report Le Financial Report (cf. Figure 3.5) est un sommaire des coûts totaux (directs et indirects) en euros. Les calculs nécessaires à la génération de ce sommaire sont expliqués dans les équations 3.16 à 3.18. A B C Fig. 3.5: Le Financial Report A Coûts directs (pour cette période) = (P ersonal + T ravel + Consomable + Equipment + Other) (3.16) P eriod B Coûts indirects = C Coûts Totaux = 3.3 Gestion du personnel DirectCosts 20% (3.17) DirectCosts + IndirectCosts (3.18) Afin de structurer correctement les informations concernant le staff il est aussi nécessaire de comprendre la gestion du personnel et en particulier la création des feuilles de temps. Dans cette 32

section se trouve donc la description de ces feuilles de temps ainsi que les calculs nécessaires pour les générer. 3.3.1 Feuilles de temps Feuilles de temps Ces feuilles sont générées chaque mois pour chaque personne travaillant sur un projet et indiquent combien de temps les chercheurs ont travaillé sur un certain projet pour le mois considéré. A B Fig. 3.6: Feuille de temps A Le nombre d heures dépend du taux d occupation de la personne (cf. Table 3.1). Taux d occupation Heures 0.25 38 0.45 68 0.50 76 0.60 91 0.75 114 1.00 152 Tab. 3.1: Nombre d heures pas rapport au taux d occupation B Heures chercheur = SalaireM ensuel T auxhorairem oyen Le taux horaire moyen dépend du type de projet sur lequel travail la personne.. STREP T auxhorairemoyen = BudgetP ersonnel V olumet ravail 152 (3.19) (3.20) 33

ou V olumet ravail = F undedduration T otalmonths P M. IP/NOE T auxhorairemoyen = V olumew ork P M 152 (3.21) ou V olumet ravail = 3.4 Formulaires BudgetP ersonnel F undedduration 18 Après la conception de l architecture du système et l étude du reporting et de la gestion du personnel, il est nécessaire de créer un certain nombre de formulaires afin que la secrétaire puisse insérer les données concernant les projets, les coûts directs (personnel, voyages, consommables, équipements et autre coûts) et le personnel. Les données contenues dans ces formulaires se basent des informations extraites des différents centres de l EPFL (tels que les ressources humaines ou le centre financier) et qui sont rentrées à la main par la secrétaire dans des feuilles Excel pour permettre au coordinateur du projet de générer les tables de reporting. 3.4.1 Projet Pour décrire un projet on a besoin de données générales (telles que le nom, l acronyme, la date de début, la durée, etc.) et de données financières (telles le budget des coûts directs et indirects). Le formulaire pour insérer un projet va donc demander les informations suivantes : Nom du projet Acronyme Type du projet (STREP, IP, NOE, etc.) Fond Numéro du contrat Numéro du participant Mois et années de début Taux de conversion CHF-Euro (au début du projet) Le budget pour les coûts indirects Indirect Costs Flat Rate Committed Duration La durée totale du projet (en mois) Le nombre de mois reportés La funded duration Les budgets pour les coûts directs (personnel, voyages, équipements, consommables et autres coûts) Un ensemble de Work Packages (qui sont composé du numéro du WP et du nombre de personnes-mois pour ce WP) 3.4.2 Coûts directs Comme expliqué à la section 3.2 les coûts directs sont divisés en 5 catégories. Il y a des informations qui se retrouvent dans les 5 catégories, mais vu que en général les données sont assez différentes, on a préféré utiliser un formulaire pour chaque catégorie. 34

Personnel Le formulaire pour insérer une entrée salaire va demander les informations suivantes : Nom et prénom Laboratoire Mois et année Type (Salaire, bourse ou indemnité) Somme Voyage Le formulaire pour insérer une entrée voyage va demander les informations suivantes : Non et prénom Laboratoire Mois et année Lieu Date de départ et date de retour Motif Somme Équipement Le formulaire pour insérer une entrée équipement va demander les informations suivantes : Laboratoire Fournisseur Adresse du fournisseur Date Description Somme Consommable Le formulaire pour insérer une entrée consommable va demander les informations suivantes : Nom et prénom Laboratoire Lieu Date Motif Somme Autre coût Le formulaire pour insérer un autre coût va demander les informations suivantes : Nom et prénom Laboratoire Lieu (élément pas obligatoire) Date Motif Somme 35

3.4.3 Personnel Les données concernant le personnel ont été en partie extraites du formulaire pour la proposition d engagement de l EPFL [17] et d autre part de l analyse de la gestion du personnel (cf. section 3.3). Le formulaire pour insérer une personne va demander les informations suivantes : Nom et prénom Laboratoire Numéro AVS (pas obligatoire) Numéro de matricule Adresse (composée de rue, NPA et ville) Date de naissance État civil et nombre d enfants Origines (pour les suisse le lieu d origine et pour les étrangers le pays) Profession Date du diplôme Date du doctorat Permis de travail (seulement pour les étrangers) Travail de thèse probable (seulement pour les étrangers) Considéré comme post-doctorant (seulement pour les étrangers) Un ensemble de taux d occupation pour les différents projets/périodes (une personne peut travailler sur différents projets et à des taux d occupation différents selon la période) 3.5 Schéma de la base de données La dernière étape de cette partie de conception du système d information est la conception du schéma pour la base de données en se basant sur les informations récoltées lors des précédentes sections. Il y a différentes méthodes pour concevoir un schéma de base de données. Naturellement l important est qu il contienne toutes les informations nécessaires à l application. La difficulté principale lors de la conception du schéma pour le système d information du centre a été de trouver le design le plus adéquat pour le changement du modèle hiérarchique du XML Schema au modèle relationnel de la base de données choisie. En effet, tout le système est basé sur les technologies XML et si la conception est mal faite on risque des pertes de performances et/ou de données. Il faut remarquer que dans notre cas, il n y a pas de pertes d informations lors du mapping car notre document XML est orienté données. Après l étude détaillé de la gestion financière et administrative du CGC, on a décidé de diviser le schéma relationnel en onze tables. 1. Project : contient les données (telles que nom, acronyme, début, etc.) d un projet 2. Budget : contient le budget (pour chaque catégorie de coûts directs) d un projet 3. WP : contient la description d un Work Package, c est à dire son numéro et le nombre de personnes-mois qui lui sont attribuées. 4. Person : contient les données (telles que nom, prénom, date de naissance, etc.) d une personne 5. PersonProject : contient le taux d occupation d une personne pour un certain projet 36

6. Personal : représente une entrée salaire 7. Travel : représente une entrée voyage 8. Equipment : représente une entrée équipement 9. Consomable : représente une entrée consommable 10. Other : représente une entrée autres-coûts 11. Month : contient les informations (numéro mois, année et taux de change) d un mois La Figure 3.7 est le résultat de cette phase de conception du schéma de la base de données. Le schéma intégral est disponible (sous forme de texte) à l annexe B. Fig. 3.7: Le schéma de la base de données Cette deuxième partie du projet s est donc terminée avec la structuration des données. Dans le prochain chapitre on va présenter le développement pratique qui a été fait en se basant sur l architecture présentée dans ce chapitre. 37

Chapitre 4 Développement du système Après la structuration des données, le deuxième objectif de ce projet est d automatiser le système de gestion du CGC. Ce chapitre présente le développement pratique qui a été effectué grâce aux techniques et à l architecture présentés au chapitre 3 pour arriver à ce but. Pour commencer cette dernière phase du projet, on va décrire les services web que l on a créé ainsi que l outil utilisé pour les déployer. On va ensuite continuer avec la description de l interface et des appels aux services web. Pour comprendre le fonctionnement de l interface et des appels au web services on va aussi donner un exemple concret. On va finalement terminer avec une évaluation du résultat obtenu. 4.1 Services Web Cette section commence avec la description de Axis, l outil utilisé pour déployer les web services, et va ensuite continuer avec la description des services web développés pour le système d information. 4.1.1 Apache Axis Qu est ce Axis? AXIS [2] est l acronyme de Apache extensible Interaction System. Il s agit d un projet développé par Apache, qui implémente la spécification SOAP et qui apparaît comme le successeur de Apache SOAP. Il est conçu dans une optique d extensibilité vis à vis de tout protocole d échange ou de transport particulier. Architecture Axis est construit sur des fondations nouvelles qui reposent sur les concepts définis par la spécification JAX-RPC. L architecture d Axis est modulaire et extensible : l ajout d extensions pour la réalisation des traitements spécifiques sur les messages ou pour l inclusion de nouvelles fonctionnalités d administration ou de gestion est en effet réalisable. De la même manière, le moteur d Axis contient une architecture indépendante de tout protocole et extensible (il est possible d ajouter du SMTP, du FTP, etc.). Améliorations par rapport à Apache SOAP L un des principaux objectifs d Axis est d apporter de meilleures performances en termes de temps de réponse et d occupation mémoire par 38

rapport à Apache SOAP. En particulier, Apache SOAP utilisait le modèle DOM (Document Object Model) pour l analyse des flux XML. Axis s appuie désormais sur un parseur plus performant pour l analyse des flux XML ; SAX (Simple API for XML Parsing) qui permet de réduire considérablement l occupation mémoire et le temps nécessaire au traitement des flux XML. Les autres améliorations importantes sont : 1. Support de sessions et de la sécurité : Axis intègre des mécanisme de support des sessions utilisateurs (à travers les en-têtes SOAP, de façon indépendante du protocole de transport utilisé). Il intègre également des mécanismes d authentification et d autorisation d accès qui peuvent être interfacés avec les mécanismes de sécurité définis par l API Servlet de J2EE. 2. Support des types de données amélioré : le support des types de données de la norme XML- Schema (2001) dans Apache Axis est complet. Il supporte les types énumérés ainsi que les valeurs non-typées. 3. Support de WSDL et fonctionnalités de mapping Java/WSDL : Axis génère automatiquement à la volée la description WSDL des services déployés. Par ailleurs, Axis implémente les fonctionnalités de mapping Java/WSDL de l API JAX-RPC. Ainsi il est possible de générer automatiquement un client Java à partir de la description WSDL d un service ou de générer une description WSDL pour une classe ou une interface Java à exposer en tant que service Web. Comment déployer un service web en Java grâce à Axis Grâce à Axis le développement d un service web en Java est très simple. En effet il suffit de : 1. Installer Axis (cf. annexe C.5) 2. Développer les classes Java nécessaires à l application 3. Compiler les fichiers 4. Copier les fichiers.class dans le répertoire c:/tomcat/webapps/axis/web-inf/classes 5. Créer le fichier deploy.wsdd (cf. Listing 4.1) qui indique le nom du service web et la classe à laquelle il doit accéder quand il est appelé. <deployment xmlns= http : / / xml. apache. org / a x i s /wsdd / xmlns : java= http : / / xml. apache. org / a x i s /wsdd/ p r o v i d e r s / java > <s e r v i c e name= ServiceName p r o v i d e r = java :RPC > <parameter name= classname value = ClassName /> <parameter name= allowedmethods value = /> </ s e r v i c e > </deployment> Listing 4.1 deploy.wsdd 6. Déployer le service web : ouvrir un Command Prompt et exécuter la commande java org.apache.axis.client.adminclient deploy.wsdd Pour annuler le déploiement d un service web Cette opération est aussi très simple. Il suffit de créer le fichier undeploy.wsdd (cf. Listing 4.2) qui indique quel service il faut éliminer et exécuter la commande suivante dans un Command Prompt : java org.apache.axis.client.adminclient undeploy.wsdd 39

<undeployment xmlns= http : / / xml. apache. org / a x i s /wsdd/ > <s e r v i c e name= ServiceName /> </undeployment> Listing 4.2 undeploy.wsdd 4.1.2 Services web déployés Six web services on été déployés pour les deux modules développés lors de ce projet : Features Persons ReportingTables TimeSheets Projects Months Ces six services web sont divisé en six classes Java. De plus il y a une classe Config.java pour la configuration des informations pour accéder à la base de données (nom utilisateur, mot de passe, etc.), une classe Utils.java contenant des méthodes utiles aux autres classes et une classe DBManager.java pour tout ce qui est accès et requêtes à la base de données. Dans les prochains paragraphes on va expliquer le rôle de chacun de ces web services et on va donner la liste et une petite description des différentes méthodes contenues dans les classes. Features S occupe de la gestion des features : reçoit les données à partir d un formulaire XForms et, selon le choix de l utilisateur, insère, met à jour ou élimine les données d une entrée (salaire, voyage, équipement, consommable ou autre-coût). Le Tableau 4.1 donne une liste des méthodes proposées dans la classe Features.java ainsi qu une brève description de chacune d elles. Persons S occupe de la gestion des données du personnel du CGC. En effet, selon le choix de l utilisateur, ce module insère, met à jour ou élimine les données du staff. Le Tableau 4.2 donne une liste des méthodes proposées la classe Persons.java ainsi qu une brève description de chacune d elles. ReportingTables.java S occupe d exécuter les calculs nécessaires à la génération des données des tables pour le reporting périodique et pour le Budget Effort (pour la période choisie par l utilisateur). Le Tableau 4.3 donne une liste des méthodes proposées dans la classe ReportingTables.java ainsi qu une brève description de chacune d elles. TimeSheets.java S occupe d exécuter les calculs nécessaires à la génération de feuilles de temps (simples ou par mois). Le Tableau 4.4 donne une liste des méthodes proposées dans la classe TimeSheets.java ainsi qu une brève description de chacune d elles. Projects.java S occupe de la gestion (insertion, mise à jour ou élimination) des données concernant les projets. Le Tableau 4.5 donne une liste des méthodes proposées dans la classe Projects. java ainsi qu une brève description de chacune d elles. 40

Méthode String getfeature () String addtravel () String deletetravel () String gettravel () String updatetravel () String addpersonal () String deletepersonal () String getpersonal () String updatepersonal () String addequipment () String deleteequipment () String getequipment () String updateequipment () String addconsomable () String deleteconsomable () String getconsomable () String updateconsomable () String addother () String deleteother () String getother () String updateother () Description Retourne toutes les entrées d une feature pour un projet donnée Ajoute une entrée voyage Élimine une entrée voyage Retourne les données concernant une entrée voyage Met à jour les données d une entrée voyage Ajoute une entrée salaire Élimine une entrée salaire Retourne les données concernant une entrée salaire Met à jour les données concernant une entrées salaire Ajoute une entrée équipement Élimine une entrée équipement Retourne les données concernant une entrée équipement Met à jour les données concernant une entrée équipement Ajoute une entrée consommables Élimine une entrée consommables Retourne les données concernant une entrée consommables Met à jour les données concernant une entrée consommables Ajoute une entrée autre-coût Élimine une entrée autre-coût Retourne les données concernant une entrée autre-coût Met à jour les données concernant une entrée autre-coût Tab. 4.1: Méthodes de la classe Features.java Méthode String getacronym () String getpersons () String getperson () String addperson () String deleteperson () String updateperson () String getnames() Description Retourne l acronyme d un projet étant donnée son ID Retourne une liste de toutes les personnes contenues dans la base de données Retourne les données concernant une personne Ajoute les données d une personne à la base de données Élimine une personne de la base de données Met à jour les données concernant une personne Retourne une liste de noms de personnes travaillant sur un certain projet Tab. 4.2: Méthodes de la classe Persons.java 41

Méthode Description double calculatebudgeteuro () Calcule le budget en Euro selon la formule 3.2 (cf. section 3.2.1) String addmonthsdate () Méthode qui ajoute un certain nombre de mois à une date String getbudgeteffort () Retourne les données (pour le nombre de mois choisis) pour la génération du Budget Effort String table3 () Retourne les données de la Table 3 String formc () Retourne les données (pour la période choisie) du Form C String financialreport () Retourne les données (pour la période choisie) du Financial Report String table4 () Retourne les données (pour la période choisie) de la Table 4 String table4bis () Retourne les données (pour la période choisie) de la Table 4bis String getreportingtable () Selon le choix de l utilisateur, cette méthode va retourner les données de l une des tables de reporting Tab. 4.3: Méthodes de la classe ReportingTables.java Méthodes String adddaysdate () double gethours () String getmonth () String timesheet () String monthtimesheets () Description Ajoute un certain nombre de jours à une date Retourne le nombre d heures étant donnée le taux d occupation Retourne le nom du mois étant donnée le numéro Génère les données pour une feuille de temps étant donné une personne et un mois Génère les données pour les feuilles de temps d un certain mois, étant donné un projet Tab. 4.4: Méthodes de la classe TimeSheets.java Méthodes String getprojects () String addproject () String deleteproject () String getproject () String updateproject () String getacronyms Description Retourne la liste de tous les projets contenus dans la base de données Ajoute un nouveau projet dans la base de données Élimine un projet Retourne les données concernant un projet Met à jour des données concernant un projet Retourne une liste des acronymes de projets présents dans la base de données Tab. 4.5: Méthodes de la classe Projects.java 42

Méthode String getmonths () String addmonth () String deletemonth () String getmonth () String updatemonth () Description Retourne une liste de tous les mois présents dans la base de données Ajoute un mois à la base de données Élimine un mois Retourne les données concernant un mois Met à jour les données concernant un mois Tab. 4.6: Méthodes de la classe Months.java Months.java S occupe de la gestion (insertion, mise à jour ou élimination) des données concernant les mois. Le Tableau 4.6 donne une liste des méthodes proposées dans cette classe ainsi qu une brève description de chacune d elles. 4.2 Interface Toute la partie interface de l application est gérée par Orbeon Presentation Server qui est une plate-forme open source construite autour du standard XForms, du Page Flow Controller [18] (PFC), du XML Pipeline Definition Language [23] (XPL) et d autres composantes XML. XForms est la nouvelle génération de formulaires web du W3C et son but est de remplacer les actuels formulaires HTML. L idée de base est de garder séparé l aspect interface utilisateur (présentation) du modèle et des données. Le Page Flow Controller est le cœur d une application web construite avec OPS. En effet il distribue les requêtes de l utilisateur aux différentes pages construites grâce à des modèles et de vues (suivant l architecture MVC). La configuration du PFC est faite grâce à un fichier appelé page-flow.xml qui ne décrit pas seulement les pages disponibles mais aussi la logique de navigation entre les différentes pages. Le XML Pipeline Definition Language est un langage pour traiter du XML en utilisant la notion de pipeline. Le document XML entre dans le pipeline, est traité par un ou plusieurs processeurs spécifiés par les instructions XPL et est ensuite restitué pour être affiché, stocké ou pour un traitement ultérieur. Grâce à ce langage OPS peut, entre autre, appeler les services web décrits à la section précédente afin de visualiser et modifier les données. Le Page Flow Controller, le XML Pipeline Definition Language ainsi que les XForms sont expliqués en détail dans l annexe A. Pour mieux comprendre comment fonctionnent OPS et les appels aux web services on va expliquer un cas concret développé dans le projet : la visualisation d un tableau contenant tous les projets et la mise à jour des données d un projet. 4.2.1 Exemple : mise à jour des données d un projet Le fichier de configuration Comme on vient de le dire, le fichier de configuration du Page Flow Controller (cf. annexe A.2) est le cœur d une application OPS car il gère toutes les requêtes des utilisateurs en les renvoyants à la bonne page. La partie du fichier de configuration concernant cet exemple est énoncée au Listing 4.3. 43

<! PROJECTS > <page i d= p r o j e c t s path i n f o= / p r o j e c t s model= / i s / p r o j e c t s /model. xpl xforms= / i s / p r o j e c t s / form. xml view= / i s / p r o j e c t s / view. x s l > <a c t i o n when= / / a c t i o n = e d i t p r o j e c t a c t i o n= / i s / p r o j e c t s / f i n d p r o j e c t a c t i o n. xpl > <r e s u l t page= edit p r o j e c t > <xu:update s e l e c t= / form /document > <xu:copy o f s e l e c t= document ( i n p u t : a c t i o n ) / /> </ xu: update> </ r e s u l t> </ a c t i o n> <a c t i o n when= / form / a c t i o n = add p r o j e c t > <r e s u l t page= create p r o j e c t /> </ a c t i o n> <a c t i o n when= / / a c t i o n = d e l e t e p r o j e c t a c t i o n= / i s / p r o j e c t s / d e l e t e p r o j e c t / d e l e t e p r o j e c t. xpl > <r e s u l t page= d e l e t e p r o j e c t > <xu:update s e l e c t= / form /document > <xu:copy o f s e l e c t= document ( i n p u t : a c t i o n ) / /> </ xu: update> </ r e s u l t> </ a c t i o n> </ page> <! EDIT PROJECT > <page i d= edit p r o j e c t path i n f o= / e d i t P r o j e c t view= / i s / p r o j e c t s / e d i t p r o j e c t / view. x s l > <a c t i o n when= / / a c t i o n = update p r o j e c t a c t i o n= / i s / p r o j e c t s / e d i t p r o j e c t / update p r o j e c t db/ save p r o j e c t. xpl > <r e s u l t page= update p r o j e c t > <xu:update s e l e c t= / form /document > <xu:copy o f s e l e c t= document ( i n p u t : a c t i o n ) / /> </ xu: update> </ r e s u l t> </ a c t i o n> </ page> <! UPDATE PROJECT > <page i d= update p r o j e c t path i n f o= / update p r o j e c t xforms= / i s / p r o j e c t s / e d i t p r o j e c t / update p r o j e c t db/ form. xml view= / i s / p r o j e c t s / e d i t p r o j e c t / update p r o j e c t db/ view. x s l > <a c t i o n when= / / a c t i o n = p r o j e c t s > <r e s u l t page= p r o j e c t s /> </ a c t i o n> </ page> Listing 4.3 Partie de page-flow.xml concernant la mise à jour d un projet Le fichier de configuration du Listing 4.3 décrit trois pages : la page projects (qui affiche la table avec tous les projets), la page edit-project (qui affiche un formulaire pour éditer les données d un projet) et la page update-project (qui affiche le résultat de la mise à jour). Cycle de vie pour la mise à jour d un projet Quand la secrétaire clique sur Projects (cf. Figure 4.1) pour obtenir la liste de projets disponibles, OPS va appeler la méthode getprojects() dans le service web Projects. Cette méthode recherche dans la base de données un certain nombre d informations (telles que nom, acronyme, type, etc.) et les retourne sous un format XML à OPS. Ce dernier affiche les informations qu il a 44

Fig. 4.1: La page de bienvenue de l application reçu dans un tableau afin de pouvoir les visionner plus clairement (cf. Figure 4.2). Fig. 4.2: La liste de projets présents dans la base de données 45

À partir de cette table il est maintenant possible d éditer un projet afin de mettre à jour les données le concernant. Quand la secrétaire clique sur Edit (cf. Figure 4.2), OPS appelle (grâce au fichier getproject.xpl donné au Listing 4.4) la méthode getproject() (du service web Projects) qui récupère toutes les données du projet en question et les retourne sous un format XML à OPS pour que ce dernier les affiches dans un formulaire XForms (cf. Listing 4.5) donnant la possibilité de les modifier (cf. Figure 4.3). Fig. 4.3: Formulaire pour mettre à jour les données d un projet 46

<p : c o n f i g xmlns : p= http : / /www. orbeon. com/ oxf / p i p e l i n e xmlns : f = http : / / orbeon. org / oxf /xml/ f o r m a t t i n g xmlns : xhtml= http : / /www. w3. org /1999/ xhtml xmlns : x s l = http : / /www. w3. org /1999/XSL/ Transform xmlns : d e l e g a t i o n = http : / / orbeon. org / oxf /xml/ d e l e g a t i o n xmlns : oxf= http : / /www. orbeon. com/ oxf / p r o c e s s o r s xmlns : saxon= http : / / saxon. s f. net / > <p : param type= input name= i n s t a n c e /> <p : param type= output name= data /> <! Retry i n f o r m a t i o n s from web s e r v i c e s > <p : p r o c e s s o r name= oxf : x s l t > <p : input name= data h r e f= #i n s t a n c e /> <p : input name= c o n f i g > <d e l e g a t i o n : e x e c u t e s e r v i c e = g e t P r o j e c t o p e r a t i o n = get x s l : v e r s i o n = 2.0 > <m: g e t P r o j e c t xmlns :m= http : / / l o c a l h o s t :8080/ a x i s / s e r v i c e s / P r o j e c t s > <m: projectid ><x s l : value o f s e l e c t = / / i d /></m: projectid > </m: g e t P r o j e c t > </ d e l e g a t i o n : execute > </p : input> <p : output name= data i d = c a l l /> </p : p r o c e s s o r > <p : p r o c e s s o r name= oxf : d e l e g a t i o n > <p : input name= i n t e r f a c e > <c o n f i g > <s e r v i c e i d = g e t P r o j e c t type= w e b s e r v i c e s t y l e = document endpoint = http : / / l o c a l h o s t :8080/ a x i s / s e r v i c e s / P r o j e c t s > <o p e r a t i o n name= get soap a c t i o n = g e t P r o j e c t R e q u e s t /> </ s e r v i c e > </c o n f i g > </p : input> <p : input name= c a l l h r e f= # c a l l /> <p : output name= data i d = r e s u l t /> </p : p r o c e s s o r > <! Transform data i n t o XML f l o w > <p : p r o c e s s o r name= oxf : x s l t > <p : input name= data h r e f= #r e s u l t /> <p : input name= c o n f i g > <x s l : s t y l e s h e e t v e r s i o n = 1.0 xmlns : x s l = http : / /www. w3. org /1999/XSL/ Transform > <x s l : template match= / > <x s l : copy o f s e l e c t = saxon : p a r s e ( / ) /> </ x s l : template> </ x s l : s t y l e s h e e t > </p : input> <p : output name= data r e f = data /> </p : p r o c e s s o r > </p : c o n f i g > Listing 4.4 getproject.xpl : pour récuperer les données d un projet Quand la secrétaire appui sur Edit afin d éditer un projet sa requête est traitée par le pipeline du Listing 4.4. Ce dernier définit trois processeurs : 1. Un processeur XSLT oxf:xslt qui récupère les données de l instance et qui fait appel au deuxième processeur. 2. Un processeur oxf:delegation qui définit les paramètres et fait appel au service web. 3. Un deuxième processeur XSLT oxf:xslt qui transforme le flux sortant du web service en flux XML. 47

... <xforms : group r e f = /form > <t a b l e t i t l e = P r o j e c t D e t a i l > <tr > <th c o l s p a n = 3 a l i g n = l e f t > <h2>general D e s c r i p t i o n </h2> </th> </tr > <tr > <th v a l i g n = middle a l i g n = l e f t > P r o j e c t Name</th> <td> <xforms : input r e f = document/ P r o j e c t / ProjectName > <xforms : hint>string </xforms : hint> </xforms : input> </td> </tr > <tr > <th v a l i g n = middle a l i g n = l e f t >Acronym</th> <td> <xforms : input r e f = document/ P r o j e c t /Acronym > <xforms : hint>string </xforms : hint> </xforms : input> </td> </tr >... <tr > <th c o l s p a n = 2 a l i g n = l e f t > <h2>work Packages </h2> </th> </tr > <xforms : r e p e a t nodeset = /form /document/ P r o j e c t /WPs/WP i d = wps > <tr > <th v a l i g n = middle a l i g n = l e f t >WP Number</th> <td> <xforms : input r e f = WPNo > <xforms : hint>string </xforms : hint> </xforms : input> </td> </tr > <tr > <th v a l i g n = middle a l i g n = l e f t >PM Committed</th> <td> <xforms : input r e f = PMCommitted > <xforms : hint>p o s i t i v e F l o a t i n g Point Number</xforms : hint> </xforms : input> </td> </tr > </xforms : repeat > <tr > <td> <xforms : t r i g g e r appearance= xxforms : image > <xxforms : img s r c = / images /add. g i f /> <xforms : l a b e l >Add WP</xforms : l a b e l > <xforms : i n s e r t ev : event = DOMActivate nodeset = /form /document/ P r o j e c t /WPs/WP at= l a s t ( ) p o s i t i o n = a f t e r /> </xforms : t r i g g e r > </td>... </tr > <tr > <td h e i g h t = 40 /> 48

</tr > <tr ><td></td> <td> <xforms : t r i g g e r > <xforms : l a b e l >Update Project </xforms : l a b e l > <xforms : a c t i o n ev : event = DOMActivate > <xforms : s e t v a l u e r e f = a c t i o n >update p r o j e c t </xforms : s e t v a l u e > <xforms : send submission = update /> </xforms : action > </xforms : t r i g g e r > </td> </tr > </t a b l e > <p/> </xforms : group> Listing 4.5 Formulaire XForms pour la mise à jour d un projet En cliquant sur Update (cf. Figure 4.3), on fait à nouveau appel à une méthode du service web Projects afin de mettre à jour les informations dans la base de données. Tout ce cycle d appels au services pour la visualisation et la mise à jour des données d un projet est représenté à la Figure 4.4. Projects WS: Projects Method: getprojects() XML Data OPS Update OK WS: Projects() Method: updateproject() Edit Update WS: Projects Method: getproject() Fig. 4.4: Cycle pour la mise à jour d un projet 49

4.3 Évaluation Pour terminer le projet on a évalué le bon fonctionnement des deux modules (gestion financière et gestion du personnel) développés pour le système d information. Pour faire cela on a commencé par insérer dans le système les données des 8 projets actuellement gérés par le CGC. Pour évaluer la partie de reporting on a simplement comparé les tables obtenues grâce à l application aux tables générées manuellement avec des feuilles Excel : les données sorties par le système sont les mêmes que celles présentes dans les tables générées à la main. Par la suite on a aussi testé le système de gestion du personnel, et en particulier la génération automatique des feuilles de temps. Dans ce cas aussi on a simplement comparé les résultats des feuilles Excel avec les résultats de l application et on a remarqué que ces résultats étaient les mêmes. On peut donc dire que les deux modules du système d information développé dans le cadre de ce projet de Master fonctionnent correctement. 50

Chapitre 5 Conclusions L objectif de ce travail de Master était de comprendre le management de projets pour arriver à structurer les informations et automatiser la gestion. Pour arriver à cela on a commencé avec une étude technologique et une analyse comparative afin de trouver la solution la plus adéquate au développement d un système d information basé sur les standards XML. Une étude détaillée du système de gestion, et en particulier des différentes tables de reporting, s est ensuite rendue indispensable afin de structurer correctement les données et créer l interface de l application ainsi que les formulaires pour la saisie des données. Du moment ou les données étaient structurées, on a donc pu passer à l automatisation de la gestion du centre en implémentant les modules de reporting périodique et de gestion du personnel. L application a été développée en se basant sur une architecture orientée services (SOA) afin de garantir l évolution et faciliter la maintenance. La partie interface a été gérée grâce au framework Orbeon Presentation Server et le stockage des données a été pris en charge par la base de données relationnelle MySQL. À la fin de ces 16 semaines de travail, on peut dire que le but du projet à été atteint. En effet on est arrivés à structurer les données et le système développé gère correctement l information financière et les données du personnel du CGC. Ce système automatique peut donc remplacer l actuel système de gestion. En analysant le système que l on a développé on se rend rapidement compte des nombreux avantages qu il apporte, soit du point administratif que du point de vue de la maintenance. Avant tout, la cohérence et le versioning des données sont maintenant assurés. En effet les données avec lesquelles le système va interagir sont celles présentes dans la base de données sur le serveur ; il n est donc plus possible que les utilisateurs aient une copie locale sur leur propre machine (comme il était le cas avec les feuilles Excel). Ensuite la maintenance et le suivi sont plus faciles. En effet l utilisation d un framework permettant la séparation entre les différentes couches (contenu, style et logique) facilite les tâches de mise à jour des fonctionnalités. Un troisième avantage est la facile extensibilité du système : la modularité de l architecture orientée services qui a été utilisée, permet en effet de remplacer ou d ajouter facilement un composant sans devoir toucher à toute l application (comme il est le cas dans des applications tout-en-un traditionnelles). Finalement l utilisation de standards et en particulier du standard XML qui n est lié à aucune plate-forme ou à aucune langage spécifique rend le système portable. De plus, l utilisation de 51

XML permet d avoir des vues multiples sur les données grâce à la séparation entre données et présentation ; actuellement on visualise les données que sous un format HTML, mais dans le futur on pourrait très bien générer des fichier PDF ou des vues pour les PDA. Tous les avantages qui viennent d être cités amènent à une meilleure gestion administrative et financière des projet ainsi qu à une charge de travail inférieure pour le management team. L équipe administrative aura donc plus de temps pour s occuper de la partie scientifique des projets. Avant de passer aux futurs développements du système, j aimerais encore dire, que du point de vue personnel, ce projet m a beaucoup apporté. D abord de par sa taille et la variété de technologies que j ai eu l occasion de découvrir et utiliser : les web services, MySQL, les XForms, et Orbeon Presentation Server. Ensuite par son utilité et son importance pour la gestion du centre : ça a été très motivant de développer un système qui va être réellement utilisé tout les jours pour gérer un ensemble toujours plus grand de personnes et de projets. Finalement, ça a été très intéressant de discuter avec les membres du management team pour comprendre en détail comment marche la gestion de projets au niveau européen et pour arriver à formaliser les réels besoins du CGC. 5.1 Travaux futurs et perspectives Certe les objectifs du projet on été atteints, cependant diverses voies restent ouvertes pour améliorer le système développé. Collecte d informations Il est vrai que la gestion financière et administrative a été automatisé, néanmoins il reste encore une partie du travail qui doit être fait à la main. En effet l insertion des données dans le système est manuelle : la secrétaire insère à la main les données extraites du centre financier de l EPFL. L application pourrait donc être améliorée en la connectant directement au centre des finances afin de récupérer automatiquement les données. Cela nous éviterait la saisie manuelle ainsi que les éventuelles erreurs dues à cette saisie. SI Centre des finances SI Centre des finances Fig. 5.1: Connection directe entre le système d information et le centre financier Intégration dans un système plus grand Dans un futur très proche, les deux services développés lors de ce travail devront être capables de communiquer et de opérer avec les autres modules du système (tels que le module de prévisions ou le module pour la gestion de l information 52

scientifique) afin d être intégrés dans un système plus grand. Il sera donc nécessaire de spécifier des protocoles pour les différents échanges afin de garantir l interoperabilité entre les différents modules du système d information. Stockage des données L utilisation d une base de données relationnelle pour stocker les données d un système d information basé sur les technologies XML n a causé ni la perte d informations ni la diminution des performances : cela parce que les documents utilisés pour les deux modules développés sont orientés données. Un des travaux futurs pour étendre le système d information sera d ajouter un module pour gérer l information scientifique et les documents produits par ce nouveau service seront sûrement orientés documents. Un problème se posera alors pour le stockage : en effet la base de données choisie pour le développement ne pourra pas être utilisée pour sauvegarder les informations scientifiques sans perte de données. Étant donné que le système d information est très flexible, une idée pour résoudre ce problème de stockage serait de garder l application actuelle telle qu elle est maintenant, et d ajouter une base de données native XML (ou un ensemble de fichiers) et un ensemble de web services pour y accéder et interagir avec les informations. Services Web Services Web BD 1 BD 2 Sécurité des documents XML L un des plus gros problèmes au niveau des web services est la sécurité. En effet les documents échangés sont au format XML et sont donc facilement lisibles par des humains. Cela amène à un problème de sécurité lors de l échange de données financière et/ou confidentielles. La particularité de XML fait que l on ne veut pas crypter tout le document, mais seulement certains éléments, ce qui nécessite de nouvelles spécifications et méthodes de cryptage. Deux spécifications sont recommandées par le W3C : XML Signature [25] et XML Encryption [22]. Le consortium OASIS [11] propose aussi une spécification WSS [12] de sécurité des services web qui est supportée par exemple par Axis 2. Pour protéger les données sensibles du système d information du centre il serait donc judicieux d utiliser ces spécifications. 53

Annexe A Orbeon Presentation Server OPS (cf. section 2.2.1 pour une introduction sur ce framework) est une plate-forme open source construite autour : du standard XForms du Page Flow Controller (PFC) du XML Pipeline Definition Language (XPL) d autres composantes XML Dans les sections suivantes on va donc expliquer plus en détail toutes ces technologies sur lequelles est basé OPS. A.1 XForms A.1.1 XForms, c est quoi? XForms est la nouvelle génération de formulaires web du W3C et son but est de remplacer les actuels formulaires HTML. L idée de base est de garder séparé l aspect interface utilisateur (présentation) du modèle et des données. Les avantages de cette idée sont l élimination d une grande partie des scripts (par exemple JavaScript) et moins de programmation du côté du serveur. XForms Modele Interface Donnees Fig. A.1: XForms 54

Instance Les données contenues dans le formulaire sont stockées dans un document XML appelé l instance XForms. Cette dernière est déclarée avec la balise instance et est situé dans le modèle (cf. Listing A.1). Le modèle Le modèle XForms déclare une ou plusieurs instance et, optionnellement peut aussi comprendre d autres composantes : des règles (définissables en schéma XML ou avec d autres langages) pour la validation de l instance et des éléments de soumission pour la soumission des données. <xforms : model> <xforms : i n s t a n c e > <Person> <FirstName/> <LastName/> </Person> </xforms : i n s t a n c e > <xforms : bind nodeset = / Person /FirstName type = xs : s t r i n g / > </xforms : model> Listing A.1 Le modèle XForms L interface L interface permet de représenter les contrôles du formulaire de façon indépendante du média de présentation, en les rattachant à la définition du modèle de XForms. <xhtml : html> <xhtml : head/> <xhtml : body> <xforms : input r e f = / Person /FirstName > <xforms : l a b e l >FirstName</xforms : l a b e l > </xforms : input> <xforms : input r e f = / Person /LastName > <xforms : l a b e l >LastName</xforms : l a b e l > </xforms : input> </xhtml : body> </xhtml : html> Il faut remarquer que le standard XForms n est pas supporté par les actuels browser (même si Mozilla est en train de travailler sur ça et pour Explorer il existe des plugins tels que FormsPlayer [6]). Dans le cadre de ce projet on a utilisé le moteur XForms fourni par Orbeon Presentation Server. A.1.2 Les contrôles de XForms Les contrôles constituent l aspect le plus important du standard XForms. Il s agit de composantes d interface utilisateur qui facilitent la saisie et l affichage des données et qui sont très similaires aux éléments des formulaires HTML standard. Voici une liste détaillée des contrôles XForms : <input> Balise qui permet de rentrer une données textuelle (format libre). 55

<xforms : input r e f = t e x t /> <textarea> Balise qui permet l entrée de données textuelles (format libre) sur plusieurs lignes. <xforms : t e x t a r e a r e f = t e x t a r e a /> <secret> Balise ou les caractères soumis apparaissent sous forme de astérisques afin de camoufler la saisie de l utilisateur. <xforms : s e c r e t r e f = s e c r e t /> <output> Balise qui restitue une valeur provenante des données d instance mais qui n offre aucune possibilité d entrer ou de modifier des données : elle sert simplement à afficher des valeurs de l instance. <range> Balise qui permet une sélection à partir d une intervalle de valeurs séquentielles. <xforms : range r e f = range / value > <xforms : send submission= c o u n t r i e s submission ev : event= xforms value changed /> </xforms : range> 56

<upload> Balise qui permet le chargement d un fichier. <xforms : upload r e f = f i l e s / f i l e [1] > <xforms : f i l e n a m e r e f = @filename /> <xforms : mediatype r e f = @mediatype /> <xxforms : s i z e r e f = @size /> </xforms : upload> <trigger> Balise qui permet de déclencher des actions. <xforms : t r i g g e r > <xforms : l a b e l >Add c a r r i e r </xforms : l a b e l > </xforms : t r i g g e r > Balise qui permet de soumettre les données (toutes ou seulement une partie) de l ins- <submit> tance. <xforms : submit submission= main submission > <xforms : l a b e l >Submit</xforms : l a b e l > </xforms : submit> <select> Balise qui permet à l utilisateur d effectuer plusieurs sélections à partir d un ensemble de choix. Selon la valeur de l attribut appearance on va avoir des check boxes ou une liste simple. Check boxes : l attribut appearance doit prendre la valeur full. <xforms : s e l e c t r e f = wrapping appearance= f u l l > <xforms : c h o i c e s > <xforms : item> <xforms : l a b e l >Hard box</xforms : l a b e l > <xforms : value>box</xforms : value> 57

</xforms : item> <xforms : item> <xforms : l a b e l >Gift </xforms : l a b e l > <xforms : value>g i f t </xforms : value> </xforms : item> </xforms : c h o i c e s > </xforms : s e l e c t > Liste simple : l attribut appearance doit prendre la valeur compact. <xforms : s e l e c t r e f = t a s t e appearance= compact > <xforms : item> <xforms : l a b e l >Vanilla </xforms : l a b e l > <xforms : value>v a n i l l a </xforms : value> </xforms : item> <xforms : item> <xforms : l a b e l >Strawberry </xforms : l a b e l > <xforms : value>strawberry </xforms : value> </xforms : item> </xforms : s e l e c t > <select1> Balise qui permet à l utilisateur d effectuer une seule sélection à partir de plusieurs choix. Selon la valeur de l attribut appearance on va avoir des radio buttons, une liste simple ou un combo box. Radio buttons : l attribut appearance doit prendre la valeur full. <xforms : s e l e c t 1 r e f = c a r r i e r appearance= f u l l > <xforms : item> <xforms : l a b e l >Fedex</xforms : l a b e l > <xforms : value>fedex </xforms : value> </xforms : item> <xforms : item> <xforms : l a b e l >UPS</xforms : l a b e l > <xforms : value>ups</xforms : value> </xforms : item> </xforms : s e l e c t 1 > 58

Liste simple : l attribut appearance doit prendre la valeur compact. <xforms : s e l e c t 1 r e f = c a r r i e r appearance= compact > <xforms : item> <xforms : l a b e l >Fedex</xforms : l a b e l > <xforms : value>fedex </xforms : value> </xforms : item> <xforms : item> <xforms : l a b e l >UPS</xforms : l a b e l > <xforms : value>ups</xforms : value> </xforms : item> </xforms : s e l e c t 1 > Combo box : l attribut appearance doit prendre la valeur minimal. <xforms : s e l e c t 1 r e f = payment appearance= minimal > <xforms : item> <xforms : l a b e l >Cash</xforms : l a b e l > <xforms : value>cash </xforms : value> </xforms : item> <xforms : item> <xforms : l a b e l >Credit </xforms : l a b e l > <xforms : value>c r e d i t </xforms : value> </xforms : item> </xforms : s e l e c t 1 > Autres balises utiles À l intérieur des contrôles de base qui viennent d être présentés, il est possible d avoir d autres éléments qui peuvent modifier la visualisation du contrôle. En voici une liste et quelques explications. 59

<label> Cet élément obligatoire appose sur le contrôle qui le contient un étiquette descriptive. <hint> Cet élément contient un message (pour conseiller l utilisateur) qui est affiché à côté du contrôle et qui devient actif quand le contrôle est sélectionné. <xforms : t e x t a r e a r e f = t e x t a r e a > <xforms : hint>enter at l e a s t 11 c h a r a c t e r s </xforms : hint> </xforms : textarea > <alert> Cet élément contient un message qui sera montré à l utilisateur quand une erreur arrive. <xforms : s e c r e t r e f = s e c r e t > <xforms : a l e r t >I n v a l i d password </xforms : a l e r t > </xforms : s e c r e t > <help> Cet élément contient un message d aide qui sera montré seulement quand l utilisateur le demandera. <xforms : input r e f = date c l a s s = xforms date > <xforms : l a b e l c l a s s = f i x e d width > Birth date :</ xforms : l a b e l > <xforms : help>this i s supposed to be a help message e x p l a i n i n g what a b i r t h date i s. But s i n c e you a l r e a d y know, i t mostly s e r v e s the purpose o f showing how help messages can be attached to c o n t r o l s, and that they can be p r e t t y long as they can be d i s p l a y e d on m u l t i p l e l i n e s. </xforms : help> </xforms : input> 60

A.1.3 Combinaisons de balises <repeat> Cet élément puissant sert pour la répetition de structures homogènes (éléments XML continus avec le même nom et le même namespace). <xforms : model> <xforms : i n s t a n c e > <People> <Person> <Name>Tania</Name> </Person> <Person> <Name>Aida</Name> </Person> <Person> <Name>C h r i s t i n e </Name> </Person> </People> </xforms : i n s t a n c e > </xforms : model> Listing A.2 Modèle <xforms : r e p e a t nodeset = / People / Person > <xhtml : tr> <xhtml : td> <xforms : output r e f = Name /> </xhtml : td> </xhtml : tr> </xforms : repeat > Listing A.3 Utilisation de repeat : création d une ligne pour chaque personne <delete> Cette balise sert à éliminer un élément. Elle possède un attribut nodeset qui pointe vers une collection homogène et un attribut at contenant une expression XPath vers l élément à éliminer. <xforms : d e l e t e nodeset = People at= l a s t ( ) /> Listing A.4 Élimination du dernier élément de la collection <insert> Cette balise sert à insérer un élément. Elle possède un attribut nodeset qui pointe vers une collection homogène, un attribut at contenant une expression XPath vers l élément à éliminer et un attribut position pour spécifier la position de l insertion. <xforms : i n s e r t nodeset = People at= l a s t ( ) p o s i t i o n = b e f o r e /> Listing A.5 Insertion d un élément avant le dernier élément de la collection 61

L insertion et l élimination d éléments, sont des actions qui sont typiquement exécutées quand l utilisateur presse sur un bouton. Ces deux dernières balises sont donc très souvent associées à un trigger (cf. Listing A.1.3). <xforms : t r i g g e r > <xforms : l a b e l >Add</xforms : l a b e l > <xforms : a c t i o n ev : event= DOMActivate > <xforms : i n s e r t nodeset = People at= l a s t ( ) p o s i t i o n = a f t e r /> </xforms : action > </xforms : t r i g g e r > <setvalue> Cette balise est typiquement utilisé dans un trigger pour fixer la valeur d un élément de l instance. Le contenu de l élément pointé par l attribut ref va prendre soit la valeur de l attribut value soit la valeur contenue dans la balise setvalue. <xforms : t r i g g e r > <xforms : l a b e l >Submit</xforms : l a b e l > <xforms : a c t i o n ev : event= DOMActivate > <xforms : s e t v a l u e r e f = c l i c k e d >my button </xforms : s e t v a l u e > <xforms : s e t v a l u e r e f = f l a v o r value= concat ( van, i l l a ) /> </xforms : action > </xforms : t r i g g e r > A.2 Le Page Flow Controller (PFC) Le Page Flow Controller est le cœur d une application web construite avec OPS. En effet il distribue les requêtes de l utilisateur aux différentes pages construites grâce à des modèles et de vues (suivant l architecture MVC). La configuration du PFC est faite grâce à un fichier appelé page-flow.xml qui ne décrit pas seulement les pages disponibles mais aussi la logique de navigation entre les différentes pages. Le PFC permet et encourage le design d une application avec une nette séparation entre (cf. Figure A.2) : la logique du site, c est-à-dire quand et comment naviguer entre les pages ; la logique des pages, c est-à-dire comment les données rentrées sont traitées ; le layout, c est-à-dire comment les informations sont affichées et présentées à l utilisateur ; la présentation du site, c est-à-dire le layout et les comportements communs à toutes les pages de l application. 62

Logique du site Layout des pages Application Logique des pages Modele B Modele A Vue A Layout Vue B A.2.1 page-flow.xml Fig. A.2: Design d une application grâce au PFC Le fichier de configuration est normalement placé à la racine des ressources d Orbeon, mais on peut toujours changer l emplacement qui est définit dans le fichier de configuration de l application (web.xml). Ce fichier commence avec le tag config qui contient d autres balises comme par exemple la balise page pour décrire les différentes pages d une application. A.2.2 Pages Dans le page flow de OPS, chaque page est identifiée grâce à un chemin unique : cette information est stockée dans l attribut path-info de la balise page (cf. Listing A.6). <page path i n f o = / s t a f f / > Listing A.6 L attribut path-info Chaque page peut aussi avoir un attribut optionnel id qui est utile pour la navigation entre les différentes pages (cf. Listing A.7). <page i d = s t a f f path i n f o = / s t a f f / > Listing A.7 L attribut id Une page peut aussi déclarer le modèle et la vue qu il faut utiliser : pour cela il existe les attributs model et view (cf. Listing A.8) : model : c est un URL qui fait référence à un document XPL (optionnellement cela peut aussi être un document XSL ou un document XML statique) qui implémente le modèle. view : c est un URL qui fait référence à un document XSL (optionnellement cela peut aussi être un document XPL ou un document XML statique) qui implémente la vue de la page. <page i d = s t a f f path i n f o = / s t a f f model = / s t a f f /model. xpl view = / s t a f f / view. xsl / > Listing A.8 Les attributs model et view 63

A.2.3 Navigation entre les pages La logique du site décrit les conditions qui déclenchent la navigation d une page à l autre et décrit aussi comment les arguments sont passés d un page à l autre. Grâce à cette séparation entre logique du site, logique des pages et layout les pages peuvent être modélisées et dévelopées l une indépendamment des autres. L entretien du site résulte donc plus simple à faire (même quand on a plusieurs developpeurs qui travaillent sur l application) vu que toutes les relations entre les pages sont clairement définies dans le page-flow. <action> Cet élément peut être contenu dans l élément page. Il est appelé action parce qu il est typiquement exécuté comme conséquence d une action de l utilisateur, comme par exemple le click d un bouton. Il peut y avoir plusieurs éléments action dans l élément page. Cet élément peut contenir un attribut when qui contient un expression XPath qui indique dans quel cas cette action doit être exécutée. L attribut when est optionnel, mais devient obligatoire dans le cas d une succession de éléments action (seulement le dernier à le droit de ne pas avoir de when). <result> L élément action peut contenir zéro ou un élément result. Si un attribut action est spécifié dans l élément action, l élément result peut avoir un attribut when. Ce dernier contient une expression XPath qui va être exécutée sur les données sortantes du pipeline. L élément result peut optionnellement contenir un attribut page qui contient l id d une page déclarée dans le même page-flow. Quand le résultat est exécuté et cet attribut est présent, l utilisateur est renvoyé à la page pointé par cet attribut. <page i d = e d i t p r o j e c t path i n f o = / e d i t P r o j e c t model= find p r o j e c t a c t i o n. xpl view= e d i t p r o j e c t / view. x s l > <a c t i o n when= / / a c t i o n = update p r o j e c t a c t i o n = save p r o j e c t. xpl > <r e s u l t page= update p r o j e c t > <xu : update s e l e c t = /form/document > <xu : copy o f s e l e c t = document ( input : action ) / /> </xu : update> </ r e s u l t > </action > </page> Listing A.9 Exemple de l utilisation de action et result A.3 Le XML Pipeline Definition Language Le XML Pipeline Definition Language est un langage pour traiter du XML en utilisant la notion de pipeline. Le document XML entre dans le pipeline, est traité par un ou plusieurs processeurs spécifiés par les instructions XPL et est ensuite restitué pour être affiché, stocké ou pour un traitement ultérieur. Les pipelines XPL sont construit en se basant sur des composants nommés processeurs XML. Un processeur XML est une composante logicielle qui consomme et produit des documents XML. Dans les paragraphes qui suivent se trouvent des explications [7] et des exemples sur les éléments de ce langage. 64

Namespace Tous les éléments définis par XPL doivent être utilisés dans le namespace http: //www.orbeon.com/oxf/pipeline. De plus, pour garantir la consistance, tous les éléments XPL doivent utiliser le prefixe p. <p:config> Est l élément racine d un document XPL et il définit : Zéro ou plus paramètres d entrée ou de sortie du pipeline avec le tag <p:param> (cf. lignes 2 et 3 Listing A.10) Une liste de déclarations qui doivent être traitées par le pipeline. Une déclaration peut soit définir un processeur (grâce à la balise <p:processor>) avec ses connections vers un autre processeur, soit une condition en utilisant la balise <p:choose>. <p:param> Cet élément définit ce que représentent les entrées et les sorties. Chaque entrée et chaque sortie doivent avoir un nom unique : en effet il ne peut pas y avoir deux entrées ou deux sorties avec le même nom. Mais il est possible d avoir une entrée et une sortie avec le même nom. Chaque nom d une entrée définit aussi un id qui peut être référencé lors de la connection de processeurs avec l attribut href. Le nom d une sortie peut être référencé avec l attribut ref dans une balise <p:output>. Instance Data Fig. A.3: Entrées et sorties du pipeline du Listing A.10 <p:processor> Cet élément place un processeur dans le pipeline et le connecte à d autres processeurs, à des entrées ou à des sorties du pipeline. L attribut name spécifie le type de processeur. Cet attribut est composé de deux parties :. un préfixe qui définit un namespace. un nom local définit dans le namespace L élément <p:input> connecte l entrée du processeur avec le nom spécifié grâce à l attribut name à :. un document XML inline embarqué dans l élément input. un document XML obtenu grâce à l attribut href L élément <p:output> définit un id correspondant à l élément avec cet id ou il connecte la sortie du pipeline avec l attribut ref. 65

<p : c o n f i g xmlns : p= http : / /www. orbeon. com/ oxf / p i p e l i n e xmlns : d e l e g a t i o n = http : / / orbeon. org / oxf /xml/ d e l e g a t i o n xmlns : oxf = http : / /www. orbeon. com/ oxf / p r o c e s s o r s xmlns : saxon= http : / / saxon. s f. net / > 2 <p : param type= input name= i n s t a n c e /> <p : param type = output name= data /> 4 <p : p r o c e s s o r name= oxf : x s l t > <p : input name= data h r e f= #i n s t a n c e /> 6 <p : input name= c o n f i g > <d e l e g a t i o n : execute s e r v i c e = getacronyms o p e r a t i o n = get x s l : v e r s i o n = 2.0 > 8 <m: getacronyms xmlns :m= http : / / l o c a l h o s t :8080/ a x i s / s e r v i c e s / P r o j e c t s /> </ d e l e g a t i o n : execute> 10 </p : input> <p : output name= data i d = c a l l /> 12 </p : p r o c e s s o r > <p : p r o c e s s o r name= oxf : d e l e g a t i o n > 14 <p : input name= i n t e r f a c e > <c o n f i g > 16 <s e r v i c e i d = getacronyms type= w e b s e r v i c e s t y l e = document endpoint= http : / / l o c a l h o s t :8080/ a x i s / s e r v i c e s / P r o j e c t s > <o p e r a t i o n name= get soap a c t i o n = getacronymsrequest /> 18 </s e r v i c e > </c o n f i g > 20 </p : input> <p : input name= c a l l h r e f= # c a l l /> 22 <p : output name= data i d = r e s u l t /> </p : p r o c e s s o r > 24 <p : p r o c e s s o r name= oxf : x s l t > <p : input name= data h r e f= #r e s u l t /> 26 <p : input name= c o n f i g > <x s l : s t y l e s h e e t v e r s i o n = 1.0 xmlns : x s l = http : / /www. w3. org /1999/XSL/ Transform > 28 <x s l : template match= / > <x s l : copy o f s e l e c t = saxon : parse ( / ) /> 30 </ x s l : template> </ x s l : s t y l e s h e e t > 32 </p : input> <p : output name= data r e f = data /> 34 </p : p r o c e s s o r > </p : c o n f i g > Listing A.10 Exemple de fichier XPL <p:choose> Cet élément peut être utilisé pour exécuter un processeur différent selon les conditions. La syntaxe générale est très similaire à la syntaxe XSLT. Les conditions sont exprimées en XPath est opèrent sur le document XML pointé par l attribut href de l élément <p:choose> (cf. Listing A.11). Si une branche a deux sorties non connectées (par exemple output1 et output2), alors toutes les autres branches doivent déclarer les même sorties. 66

<p : choose h r e f = # c o n d i t i o n document xmlns : p= http : / /www. orbeon. com/ oxf / p i p e l i n e > <p : when t e s t = f i r s t c o n d i t i o n >... </p : when> <p : when t e s t = second c o n d i t i o n >... </p : when> <p : otherwise >... </p : otherwise > </p : choose> Listing A.11 Syntaxe du <choose> <p:for-each> Grâce à cet élément il est possible de exécuter un processeur plusieurs fois sur le contenu d un document. Dans cet élément, il est possible d avoir des processeurs multiples connectés ensemble, des éléments choose ou des for-each imbriqués. 67

Annexe B Schéma de base de données CREATE TABLE budget ( Project ID int ( 1 0 ) unsigned NOT NULL, Personal f l o a t NOT NULL, Travel f l o a t NOT NULL, Consomable f l o a t NOT NULL, Equipment f l o a t NOT NULL, OtherCosts f l o a t NOT NULL, PRIMARY KEY ( Project ID ), KEY Project ID ( Project ID ), CONSTRAINT b u d g e t i b f k 1 FOREIGN KEY ( Project ID ) REFERENCES p r o j e c t ( ID ) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=u t f 8 ; CREATE TABLE consomable ( ID int ( 1 0 ) unsigned NOT NULL auto increment, Project ID int ( 1 0 ) unsigned NOT NULL, Month ID int ( 1 0 ) unsigned NOT NULL, FirstName varchar (100) NOT NULL, LastName varchar (100) NOT NULL, Labo varchar (100) NOT NULL, Place varchar (100) NOT NULL, Date date NOT NULL, Reason varchar (255) NOT NULL, Amount f l o a t NOT NULL, PRIMARY KEY ( ID ), KEY Project ID ( Project ID ), KEY Month ID ( Month ID ), CONSTRAINT consomable ibfk 1 FOREIGN KEY ( Project ID ) REFERENCES p r o j e c t ( ID ) ON DELETE CASCADE, CONSTRAINT consomable ibfk 2 FOREIGN KEY ( Month ID ) REFERENCES month ( ID ) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=u t f 8 ; CREATE TABLE equipment ( ID int ( 1 0 ) unsigned NOT NULL auto increment, 68

Month ID int ( 1 0 ) unsigned NOT NULL, Project ID int ( 1 0 ) unsigned NOT NULL, Labo varchar (100) NOT NULL, Supplier varchar (100) NOT NULL, Address varchar (100) NOT NULL, Date date NOT NULL, D e s c r i p t i o n varchar (255) NOT NULL, Amount f l o a t NOT NULL, PRIMARY KEY ( ID ), KEY Project ID ( Project ID ), KEY Month ID ( Month ID ), CONSTRAINT equipment ibfk 1 FOREIGN KEY ( Project ID ) REFERENCES p r o j e c t ( ID ) ON DELETE CASCADE, CONSTRAINT equipment ibfk 2 FOREIGN KEY ( Month ID ) REFERENCES month ( ID ) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=u t f 8 ; CREATE TABLE month ( ID int ( 1 0 ) unsigned NOT NULL auto increment, MonthNo int ( 1 0 ) unsigned NOT NULL, YearNo int ( 1 0 ) unsigned NOT NULL, Date date NOT NULL, ConversionRate f l o a t NOT NULL, PRIMARY KEY ( ID ) ) ENGINE=InnoDB DEFAULT CHARSET=u t f 8 ; CREATE TABLE other ( ID int ( 1 0 ) unsigned NOT NULL auto increment, Project ID int ( 1 0 ) unsigned NOT NULL, Month ID int ( 1 0 ) unsigned NOT NULL, FirstName varchar (100) NOT NULL, LastName varchar (100) NOT NULL, Labo varchar (100) NOT NULL, Place varchar (100) default NULL, Date date NOT NULL, Reason varchar (255) NOT NULL, Amount f l o a t NOT NULL, PRIMARY KEY ( ID ), KEY Project ID ( Project ID ), KEY Month ID ( Month ID ), CONSTRAINT o t h e r i b f k 1 FOREIGN KEY ( Project ID ) REFERENCES p r o j e c t ( ID ) ON DELETE CASCADE, CONSTRAINT o t h e r i b f k 2 FOREIGN KEY ( Month ID ) REFERENCES month ( ID ) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=u t f 8 ; CREATE TABLE person ( ID int ( 1 0 ) unsigned NOT NULL auto increment, FirstName varchar (100) NOT NULL, LastName varchar (100) NOT NULL, AVS varchar ( 4 5 ) default NULL, S t r e e t varchar (255) default NULL, NPA int ( 1 0 ) unsigned NOT NULL, 69

Town varchar (100) NOT NULL, Birthday date NOT NULL, MaritalStatus varchar (100) NOT NULL, Childrens int ( 1 0 ) unsigned NOT NULL, Origins varchar (100) NOT NULL, Occupation varchar (100) NOT NULL, DegreeDate date default NULL, PhD varchar ( 3 ) default NULL, PhDDate date default NULL, WorkPermit varchar ( 4 5 ) default NULL, ThesisProbable varchar ( 3 ) default NULL, PostDoc varchar ( 3 ) default NULL, IdentificationNumber varchar ( 1 0 ) NOT NULL, Labo varchar ( 4 5 ) NOT NULL, PRIMARY KEY ( ID ) ) ENGINE=InnoDB DEFAULT CHARSET=u t f 8 ; CREATE TABLE personal ( ID int ( 1 0 ) unsigned NOT NULL auto increment, Person ID int ( 1 0 ) unsigned NOT NULL, Month ID int ( 1 0 ) unsigned NOT NULL, Project ID int ( 1 0 ) unsigned NOT NULL, Labo varchar (100) NOT NULL, Type varchar (100) NOT NULL, Amount f l o a t NOT NULL, PRIMARY KEY ( ID ), KEY Project ID ( Project ID ), KEY Month ID ( Month ID ), KEY Person ID ( Person ID ), CONSTRAINT p e r s o n a l i b f k 1 FOREIGN KEY ( Project ID ) REFERENCES p r o j e c t ( ID ) ON DELETE CASCADE, CONSTRAINT p e r s o n a l i b f k 2 FOREIGN KEY ( Month ID ) REFERENCES month ( ID ) ON DELETE CASCADE, CONSTRAINT p e r s o n a l i b f k 3 FOREIGN KEY ( Person ID ) REFERENCES person ( ID ) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=u t f 8 ; CREATE TABLE p e r s o n p r o j e c t ( ID int ( 1 0 ) unsigned NOT NULL auto increment, Project ID int ( 1 0 ) unsigned NOT NULL, Person ID int ( 1 0 ) unsigned NOT NULL, OccupationRate f l o a t NOT NULL, DateFrom date NOT NULL, DateTo date NOT NULL, PRIMARY KEY ( ID ), KEY Project ID ( Project ID ), KEY Person ID ( Person ID ), CONSTRAINT p e r s o n p r o j e c t i b f k 1 FOREIGN KEY ( Project ID ) REFERENCES p r o j e c t ( ID ) ON DELETE CASCADE, CONSTRAINT p e r s o n p r o j e c t i b f k 2 FOREIGN KEY ( Person ID ) REFERENCES person ( ID ) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=u t f 8 ; 70

CREATE TABLE p r o j e c t ( ID int ( 1 0 ) unsigned NOT NULL auto increment, ProjectName varchar (255) NOT NULL, Acronym varchar (255) NOT NULL, ProjectType enum( IP, STREP, NOE ) NOT NULL, Fond varchar ( 4 0 ) NOT NULL, ContractNO varchar ( 4 0 ) NOT NULL, ParticipantNo int ( 1 0 ) unsigned NOT NULL, StartingMonth int ( 1 0 ) unsigned NOT NULL, StartingYear int ( 1 0 ) unsigned NOT NULL, ConversionRate f l o a t NOT NULL, I n d i r e c t C o s t s f l o a t NOT NULL, I n d i r e c t C o s t s F l a t R a t e f l o a t NOT NULL, CommittedDurationMonths int ( 1 0 ) unsigned NOT NULL, CommittedDurationTotalMonths int ( 1 0 ) unsigned NOT NULL, ReportedMonths int ( 1 0 ) unsigned NOT NULL, FundedDuration int ( 1 0 ) unsigned NOT NULL, PRIMARY KEY ( ID ) ) ENGINE=InnoDB DEFAULT CHARSET=u t f 8 ; CREATE TABLE t r a v e l ( ID int ( 1 0 ) unsigned NOT NULL auto increment, Month ID int ( 1 0 ) unsigned NOT NULL, Project ID int ( 1 0 ) unsigned NOT NULL, FirstName varchar (100) default NULL, LastName varchar (100) NOT NULL, Labo varchar (100) NOT NULL, Place varchar (255) NOT NULL, DateFrom date default NULL, DateTo date default NULL, Reason varchar (255) NOT NULL, Amount f l o a t NOT NULL, PRIMARY KEY ( ID ), KEY Project ID ( Project ID ), KEY Month ID ( Month ID ), CONSTRAINT t r a v e l i b f k 1 FOREIGN KEY ( Project ID ) REFERENCES p r o j e c t ( ID ) ON DELETE CASCADE, CONSTRAINT t r a v e l i b f k 2 FOREIGN KEY ( Month ID ) REFERENCES month ( ID ) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=u t f 8 ; CREATE TABLE wp ( ID int ( 1 0 ) unsigned NOT NULL auto increment, Project ID int ( 1 0 ) unsigned NOT NULL, PMCommitted f l o a t NOT NULL, WPNo varchar ( 4 5 ) NOT NULL, PRIMARY KEY ( ID ), KEY Project ID ( Project ID ), CONSTRAINT wp ibfk 1 FOREIGN KEY ( Project ID ) REFERENCES p r o j e c t ( ID ) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=u t f 8 ; 71

Annexe C Installation de l application C.1 Introduction Ceci est une aide rapide pour la configuration et l installation de l application GlobalComputing Information System (basée sur les technologies XML). C.1.1 Prérequis Pour pouvoir installer l application il est indispensable d avoir installé et configuré au préalable les applications suivantes : Java 5 installé (Tomcat 5.5 fonctionne seulement avec Java 5) Apache HTTP Server (dans le répertoire c:/apache) Apache Tomcat (dans le répertoire c:/tomcat) MySQL Server 5.0 (dans le répertoire c:/mysql) Apache Axis (dans le répertoire c:/tomcat/webapps) Aux sections C.2, C.3, C.4 et C.5 il y a des explications detailées pour installer et configurer ces applications (si cela n a pas encore été fait correctement). C.2 Apache HTTP Server C.2.1 Téléchargement et installation Télécharger la dernière version (2.0.x) de Apache HTTP Server à partir de la page : http://httpd.apache.org. Pour installer le serveur, double cliquer sur le fichier.exe qui vient d être téléchargé (choisir c:/apache comme répertoire d installation). C.2.2 Tester l installation Ci cela n a pas encore été fait, démarrer le serveur Apache. Ensuite, dans un browser taper : http://localhost 72

Si l installation du serveur Apache a été faite de manière correcte, la page suivante doit s afficher : Fig. C.1: Page de test pour l installation de Apache HTTP Server C.3 Apache Tomcat C.3.1 Téléchargement et installation Télécharger la dernière version (5.5.x) de Apache Tomcat à partir de la page : http://tomcat.apache.org. Pour installer le conteneur de servlet, double cliquer sur le fichier.exe qui vient d être téléchargé (choisir c:/tomcat comme répertoire d installation). C.3.2 Tester l installation Ci cela n a pas encore été fait, démarrer Tomcat. Ensuite, dans un browser taper : http://localhost:8080 Si l installation de Tomcat a été faite de manière correcte, la page suivante doit s afficher : 73

Fig. C.2: Page de test pour l installation de Tomcat C.4 MySQL Server 5.0 C.4.1 Téléchargement et installation Télécharger la dernière version (5.0.x) de MySQL à partir de la page : http://dev.mysql.com/downloads/. Décompresser l archive qui vient d être téléchargé et double cliquer sur Setup.exe pour installer MySQL 5 (choisir c:/mysql comme répertoire d installation). C.4.2 Tester l installation Vous pouvez tester l installation de MySQL en exécutant l une des commandes suivantes dans un Command Prompt (à partir du répertoire c:/mysql/mysql Server 5.0/bin) : mysqlshow -u root -p mysqladmin version status proc -u root -p mysql -u root -p mysql test -u root -p 74

C.5 Apache Axis C.5.1 Téléchargement et installation Télécharger la dernière version de Axis à partir de la page : http://ws.apache.org/axis/. Dans l archive (.zip ou.tar.gz) qui vient d être téléchargé, copier le répertoire webapps/axis dans le répertoire c:/tomcat/webapps. Packages Pour faire marcher Axis, il est indispensable d avoir le package activation.jar. Copier donc ce fichier depuis Axis/lib dans le répertoire c:/tomcat/webapps/axis/web-inf/lib. Variables d environnement Axis utilise plusieurs packages indispensables au fonctionnement de l application. Il est donc nécessaire de fixer les variables d environnement comme suit afin que le système puisse trouver ces packages. Variable AXIS HOME AXIS LIB AXISCLASSPATH Valeur c:/tomcat/webapps/axis c:/tomcat/webapps/axis/lib %AXIS_LIB%/axis.jar ;%AXIS_LIB%/commons-discovery.jar ;%AXIS_LIB%/commonslogging.jar ;%AXIS_LIB%/jaxrpc.jar ; %AXIS_LIB%/saaj.jar ;%AXIS_LIB%/log4j- 1.2.8.jar ;%AXIS_LIB%/wsdl4j.jar C.5.2 Tester l installation Dans un browser taper : http://localhost:8080/axis Si l installation de Axis a été faite de manière correcte, la page suivante doit s afficher : 75

Fig. C.3: Page de test pour l installation de Axis Validation de l installation : pour valider l installation, cliquer sur Validation : si aucune erreur n apparait cela signifie que l installation est validé. C.6 Global Computing Information System C.6.1 Installation du système L application Global Computing Information System est basée sur Orbeon Presentation Server, qui tourne sous Tomcat. Toute l application (c est à dire tout le répertoire CGC) doit donc être placée sous c:/tomcat/webapps. C.6.2 Configuration des Web Services (Axis) Avant tout il faut (si nécessaire) corriger le fichier Java_WS/start.bat (qui compile les fichiers et déploie le Web Service) afin que le chemin vers Axis soit correct. Ensuite il faut changer la va- 76

leur des variables mysqluser et mysqlpassword dans le fichier Java_WS/Config.java avec le nom d utilisateur et le mot de passe pour accéder à la base de données MySQL qui vient d être installée sur l ordinateur. À ce moment il est possible d exécuter le script projects.bat pour compiler les fichiers, les déplacer au bon endroit et pour déploier le service web. Ensuite, pour pouvoir accéder à la base de données MySQL, il faut copier le fichier mysql-connector. jar (situé dans Java_WS/lib) dans le répertoire c:/tomcat/webapps/axis/lib. Remarque : toute les fois qu on redéploie un Web Service ou qu on modifie une classe dans Axis, se rappeler de recharger l application en tapant dans un browser Variables d environment http://localhost:8080/manager/reload?path=/axis Ajouter la variable d environnement CATALINA HOME et lui donner la valeur c:/tomcat. Ensuite ajouter à la variable d environnement AXISCLASSPATH l élément suivant : C.6.3 ;%CATALINA_HOME%/webapps/axis/WEB-INF/lib/mysql-connector.jar Configuration de la base de données Ouvrir un Command Prompt et exécuter les commandes suivantes à partir du répertoire c: /MySQL/MySQL Server 5.0/bin : 1. mysql -u root -p (pour accéder à l administration de MySQL) 2. create database cgc ; (pour créer la base de données pour l application) 3. use cgc ; (pour utiliser la base de données qu on vient de créée) 4. copier ensuite toutes les commandes de création de tables à partir du fichier db/create. sql et exécuter les dans le Command Prompt (cela pour créer les tables nécessaires dans l application) 77

Bibliographie [1] Apache Cocoon. http://cocoon.apache.org/. [2] Axis. http://ws.apache.org/axis/. [3] Center for Globalcomputing. http://globalcomputing.epfl.ch/. [4] exist, Open Source Native XML Database. http://exist.sourceforge.net/. [5] Faculté Informatique et Communications. http://ic.epfl.ch/. [6] Forms player. http://www.formsplayer.com/. [7] Introduction to the xml pipeline definition language. http://www.orbeon.com/ops/doc/ reference-xpl-pipelines. [8] Jakarta Struts. http://struts.apache.org/. [9] Java Server Faces. http://java.sun.com/j2ee/javaserverfaces/. [10] MySQL. http://www.mysql.com. [11] Oasis. http://www.oasis-open.org/. [12] Oasis wss. http://www.oasis-open.org/committees/wss/. [13] Open Source Database Software Comparison. http://www.geocities.com/ mailsoftware42/db/?200527. [14] Orbeon Presentation Server. http://www.orbeon.com/software/. [15] PostgreSQL. http://www.postgresql.org. [16] Project Reporting in FP6. ftp://ftp.cordis.lu/pub/fp6/docs/reporting_in_fp6-main_ en.pdf/. [17] Proposition d engagement. [18] The Page Flow Controller. http://www.orbeon.com/ops/doc/reference-page-flow/. 78

[19] The World Wide Web Consortium. http://www.w3.org/. [20] XForms - The Next Generation of Web Forms. http://www.w3.org/markup/forms/. [21] Xindice. http://xml.apache.org/xindice/. [22] Xml encryption. http://www.w3.org/tr/xmlenc-core/. [23] XML Pipeline Definition Language. http://www.orbeon.com/ops/doc/ reference-xpl-pipelines/. [24] Xml pipeline language (xpl) version 1.0 (draft). http://www.w3.org/submission/xpl/. [25] Xml signature. http://www.w3.org/tr/xmldsig-core/. [26] École Polytechnique Fédérale de Lausanne. http://www.epfl.ch/. [27] R. Bourret. XML et les bases de données. http://peccatte.karefil.com/software/ RBourret/xmlBD.htm. [28] E. Cerami. Web services essentials : distributed applications with XML-RPC, SOAP, UDDI and WSDL. O Reilly, 2002. [29] M. Dubinko. XForms Essentials. O Reilly, 2003. 79