Etude et implémentation d un système de travail collaboratif entre le logiciel D-Sight et une plateforme web.

Transcription

1 UNIVERSITE LIBRE DE BRUXELLES Faculté des Sciences Appliquées Année académique Etude et implémentation d un système de travail collaboratif entre le logiciel D-Sight et une plateforme web. Directeur de Mémoire : Yves De Smet Mémoire de fin d études présenté par Alexandre Mathieu en vue de l obtention du diplôme d Ingénieur Civil Informaticien

2 Remerciements Ce travail n aurait pas été possible sans la présence de plusieurs personnes que je tiens spécialement à remercier : Le Professeur Yves De Smet, promoteur de ce mémoire, dont l exigence a été un moteur dans le cadre de mes projet ces deux dernières années et dont l accessibilité et la sympathie ont contribué à rendre cette dernière année universitaire particulièrement agréable. Quantin Hayez, co-gérant de Decision Sights, dont l enthousiasme et la bonne humeur constante ont égayé les réunions ayant parsemé l année. Je lui souhaite le meilleur pour le développement de Decision Sights et j espère sincèrement que ses projets rencontreront le succès qu ils méritent. Mes parents, toujours présents depuis 25 ans, et qui ont vu leur temps de sommeil réduit par les incessantes corrections orthographiques et les relectures successives des drafts de ce rapport. Pauline, mon amour, pour n avoir pas (trop) râlé face à mes horaires de travail parfois étranges. Elle a également contribué activement à certaines tournures de phrases présentes dans ce texte.

3 Résumé Un système collaboratif permet à plusieurs personnes de travailler simultanément sur un projet commun en mettant en oeuvre des moyens facilitant l échange d informations entre les intervenants. Ce travail va implémenter un tel système dans un logiciel de façon à permettre à ses utilisateurs de synchroniser, entre eux, automatiquement les données qu ils modifient. De plus, un service web connecté au système collaboratif permettra la gestion et la sauvegarde de ces projets. Ce rapport présente les raisons économiques qui ont encouragé la réalisation de ce projet ainsi que les questions stratégiques qui sont apparues lors de la mise au point du cahier des charges. L implémentation du système est présentée en trois parties distinctes. La première partie traite des modifications apportées au logiciel pour lui permettre d envoyer et de recevoir des informations via un réseau. La seconde partie présente l organisation de l entité chargée de superviser les échanges de messages. Enfin, la troisième partie présente les défis liés à la communication entre cette entité et le service web. Le rapport est clôturé par une analyse rétrospective du travail et par une présentation des possibilité de déploiement et du système implémenté. Abstract A collaborative system allows multiple people to simultaneously work on a common project by facilitating the exchange of information between stakeholders. This work will implement such a system in a software, allowing users to synchronize their data. In addition, a web service connected to the collaborative system will enable the management and persistence of these projects. This report describes the economic reasons that have encouraged this project and the different questions that arose during the development of the specification. The system implementation is presented in three distinct parts. The first part deals with the modification of the software to enable it to send and receive information through a network. The second part describes the organization of the entity responsible for overseeing the exchange of messages. The third part presents the challenges of communication between this entity and the web service. The report is ended by a retrospective analysis of the project and describes the possibility of deployment of the implemented system.

4 Table des matières Table des matières 4 I Présentation 6 1 Introduction Introduction Présentation des intervenants Le projet Intérêt du projet II Implémentation 16 2 Vue globale Architecture générale de D-Sight Architecture générale de la plateforme Le protocole HTTP L architecture REST Organisation du travail Communication entre D-Sight et le serveur collaboratif Informations à échanger Modifications apportées à D-Sight Protocole de communication Organisation du serveur Mécanismes de sécurité Communication entre le serveur collaboratif et la plateforme Modifications du serveur collaboratif Modification apportées à la plateforme Problématique d authentification Problématique de sécurité Le chargement Procédure générale connexion initale et authentification Sélection et chargement du projet

5 III Conclusions 80 6 Analyses personnelles Analyse rétrospective Perspectives de déploiement Conclusions Bibliographie 93

6 Première partie Présentation

7 CHAPITRE 1 Introduction

8 1.1. Introduction Introduction Durant des années, l explosion des capacités de calcul des ordinateurs a permis l utilisation de l informatique dans un nombre croissant de domaines. Cette évolution est maintenant accompagnée par une amélioration sensible de la qualité et de la vitesse des connexions entre ces machines, permettant d adapter ces technologies à de nouveaux usages. Au cours de ce mémoire, ces perspectives seront mises en application sur un logiciel commercial en lui ajoutant une fonctionnalité permettant à plusieurs utilisateurs de travailler simultanément, et de façon interactive, sur un projet commun. Ce travail est couplé avec un stage, réalisé dans la même entreprise durant l été 2010 et intégré dans le cursus de la faculté. Au cours de ce stage, l étudiant a pris l initiative, après accord du corps académique et de Decision Sights, d orienter son travail de fin d études vers ce sujet. Les problématiques techniques abordées sont typiquement rencontrées lorsqu on tente de gommer la frontière existant entre les applications destkop et les services web. Or, avec le développement rapide de l informatique dans les nuages, cette distinction tend à disparaitre sous l impulsion de l industrie qui souhaite profiter de cette nouvelle souplesse. Ce mémoire s inscrit donc naturellement dans ce mouvement et permet à Decision Sights de proposer rapidement une solution aux nouveaux besoins de ses clients. Ce rapport présente, en trois parties distinctes, l ensemble du projet. Il rassemble les réflexions nées durant les phases d analyse et les défis techniques relevés durant l implémentation. Il permet également au mémorant d exprimer son point de vue sur certaines technologies et de donner son avis sur certaines décisions d ordre plus stratégique. Cet aspect est fondamental dans la mesure où la définition précise du cahier des charges a été un élément clef sur lequel a pu être conçu le plan d implémentation. La première partie présentera les deux éléments centraux de ce projet : le logiciel propriétaire (nommé D-Sight) et la plateforme. Cette présentation sera suivie d un compterendu des discussions ayant eu lieu entre le mémorant et Decision Sights pour aboutir à une définition plus claire des objectifs du projet. Ces discussions montrent que le travail n est pas resté cantonné à un cadre purement technique, mais que des questions d ordre stratégique ont été soulevées dès l élaboration du sujet, sollicitant des compétences d ingénieur pour y répondre efficacement. La seconde partie concernera l implémentation du cahier des charges défini durant la première section. L ensemble des défis techniques relevés et des problématiques rencontrées sera présenté de la façon la plus générique possible afin d isoler et d exposer une difficulté avant d explorer ses solutions. La complexité principale concerne le contournement des limitations du protocole HTTP dans le cadre de multiples connexions concurrentes liées par une session de travail commune. Enfin, la troisième partie offrira un regard critique sur le travail en analysant rétrospectivement les choix effectués. Elle permettra également de présenter les moyens de distribution du projet en détaillant les contraintes supplémentaires inhérentes à la phase de mise en production. Ceci démontre une volonté de produire un système utilisable, répondant à un besoin concret, aspect fondamental de la faculté des sciences appliquées.

9 1.2. Présentation des intervenants Présentation des intervenants D-Sight D-Sight est le nom du logiciel sur lequel va se dérouler ce mémoire. C est lui qui va recevoir les fonctionnalités de travail collaboratif qui seront réalisées dans le cadre de ce travail. Il s agit d un logiciel d aide multicritère à la décision basé sur la méthodologie PRO- METHEE - GAIA[4] développée au sein du Service des Mathématiques de la Gestion (SMG) de l ULB depuis D un point de vue pratique, le logiciel est commercialisé sous la forme d un exécutable qui permet d installer le logiciel sur la machine des clients et de l utiliser. Le développement de D-Sight a commencé en 2007 dans le cadre d une bourse First Spin-off offerte par la région Wallonne. Après trois ans de recherche, la société Decision Sights a été fondée afin de commercialiser le logiciel. En tant que logiciel d aide à la décision multicritère, D-Sight a pour objectif d aider un décideur qui fait face à un problème complexe, dont la solution ne semble pas évidente. Un cas d utilisation typique de D-Sight se déroule en trois phases 1 : L utilisateur entre les alternatives qu il doit départager ainsi que les critères sur lesquels elles sont comparées. Il évalue ensuite chaque alternative en fonction de chaque critère. Il va modifier les paramètres de chaque critère (par exemple son poids qui mesure l importance relative de ce critère). De nombreux outils visuels et interactifs permettent de modifier aisément ces paramètres et surtout d évaluer la conséquence des changements effectués. Il est important de noter que, même si D-Sight peut établir un ranking des alternatives en fonction des paramètres rentrés (c est-à-dire un classement de la meilleure alternative jusqu à la moins bonne ), D-Sight a surtout pour vocation d aider le décideur en lui offrant un maximum d informations. Un exemple concret d utilisation permet au lecteur d appréhender l utilisation de D- Sight. Une entreprise YYY oeuvrant dans le transport de marchandises souhaite acheter une flotte de camions pour développer son activité. Elle passe donc un appel d offre auquel cinq sociétés répondent. La réponse contient les caractéristiques techniques du véhicule proposé, le prix unitaire et le délai de livraison. Le décideur de la société YYY va utiliser D-Sight pour faire son choix : il va lister les cinq modèles proposé ainsi que les critères qu il juge importants. Par exemple, le prix, le délai de livraison, la consommation, le volume transportable et le tonnage maximum. Il va ensuite évaluer chacun des camions selon les critères énoncés, ce qui consiste dans ce cas-ci à recopier la valeur présente dans la réponse à l appel d offre. Enfin, le décideur va modifier les caractéristiques de chaque critère : il peut changer l importance du critère ou encore indiquer qu un volume transportable trop important n est pas souhaitable dans la mesure ou le prix d entretien 1. Ces trois étapes sont données à titre indicatif : en pratique, le logiciel n impose pas de suivre l ordre donné en exemple

10 1.2. Présentation des intervenants 10 du camion augmente. A chaque modification, le décideur peut voir le ranking des véhicules se mettre à jour. Figure 1.1: Capture d écran de D-Sight La plateforme La plateforme est le nom donné à un projet interne de Decision Sights. Il s agit d une version web de D-Sight : l objectif est de permettre aux clients de la plateforme de profiter d un système d aide à la décision sous forme d un site internet. L accès à la plateforme n est pas actuellement commercialisé car elle n existe que sous la forme de Proof of Concept 2 (POC). Pour Decision Sights, comme pour ses clients, le format site internet peut être plus avantageux pour différentes raisons qui sont propres à l informatique dans les nuages (on parle, en anglais, de Cloud Computing). Ce Cloud Computing consiste à déplacer toute la partie logicielle depuis le client vers le prestataire qui loue alors l accès à ses services. On passe ainsi d un business model basé sur la vente de licence, vers un business model basé sur la location de services (également connu sous le nom de SaaS : Software as a Service). Il peut être intéressant de lister les avantages du Cloud Computing, tant pour le client que pour le prestataire de service (Decision Sights dans le cas de la plateforme). 2. Un Proof of Concept est un logiciel informatique destiné à prouver la faisabilité d un concept. Il n a pas pour objectif d être utilisable au quotidien et le temps de développement est donc largement raccourci.

11 1.2. Présentation des intervenants 11 Pour les clients L accès au site est facturé mois par mois. En entreprise, il est largement plus facile de justifier une petite dépense régulière nécessaire au bon fonctionnement d un service que l achat d une licence relativement onéreuse. Le site internet est, à priori, accessible partout : il n est pas nécessaire d installer un logiciel sur une ou plusieurs machines, opération qui peut nécessiter la validation du service informatique de l entreprise. Les mises à jour sont disponibles automatiquement et sans suppléments. Tant que l utilisateur paye l accès au site, il profite des dernières nouveautés sans devoir installer une nouvelle version. La gestion des fichiers et des sauvegardes est confiée au prestataire de services. Tous ces avantages permettent au client de ne pas devoir se soucier de toute la partie technique du logiciel qui est située dans le nuage que représente internet. Pour le prestataire L accès au site est loué et non pas vendu. Les rentrées d argent sont donc plus régulières et il est donc plus aisé d effectuer des prévisions et des plans. Les avantages de l informatique dans les nuages sont des éléments marketing forts vis-à-vis des clients. Le coût d entrée est largement plus faible : un client peut profiter d une version très complète d un produit durant une durée très faible si le besoin s en fait sentir. La somme de tous ces petits clients qui n utilisent le service que durant un mois ou deux et qui n auraient pas acheté une licence du logiciel pour le peu d utilisation qu ils en auraient eu peut représenter une rentée d argent supplémentaire significative. On peut voir cela comme une application supplémentaire de l effet longue traine[3]. Outre ses limitations techniques (bande passante, quantité de calculs,...), le Cloud Computing présente également des désavantages, principalement pour le client qui perd la maîtrise de ses données et le contrôle sur l architecture technique. Dans certaines industries (par exemple, le domaine militaire ou la recherche de pointe), il peut s agir d un réel frein à l utilisation de l informatique dans les nuages. Pour cela, certaines grosses entreprises mettent sur pied un cloud privé : les logiciels utilisés par leurs employés sont placés dans un cloud entièrement contrôlé par le service informatique de la compagnie. Enfin, avoir un accès à internet (de préférence de haut débit) est une condition nécessaire pour pouvoir utiliser un tel service. Ces accès internet ne sont pas toujours disponibles partout, notamment en situation de mobilité. La démocratisation des accès haut débit via le réseau GSM (technologie 3G) est un des éléments à l origine de la montée en puissance du Cloud Computing et les problèmes d accessibilité sont de moins en moins souvent mis en avant.

12 1.3. Le projet Le projet L objectif du projet Afin de permettre au lecteur de suivre ce rapport, il semble nécessaire de définir clairement les objectifs du projet ainsi que les limites de celui-ci. Ce chapitre montrera que ce cadre est le fruit d une réflexion prenant en compte les intérêts de Decision Sights et du mémorant. Ce mémoire traite de la mise en place d un système de travail collaboratif entre D- Sight et la plateforme. La première étape majeure dans la définition du cadre du travail semble être de comprendre ce que l on entend par travail collaboratif. A ce titre, une définition du mot collaborer semble être un bon point de départ : Collaborer, c est travailler de concert avec quelqu un d autre, l aider dans ses fonctions ; participer avec un ou plusieurs autres à une oeuvre commune. Lexis Cette définition introduit trois concepts fondamentaux : 1. La notion de travail simultané. 2. Le fait qu il y ait plusieurs intervenants. 3. L importance d une oeuvre commune. Dans le cadre de D-Sight, la mise en place d un système de travail collaboratif doit donc permettre à plusieurs utilisateurs de travailler ensemble sur le même projet. Pour cela, l ensemble des modifications qui seront effectuées par chaque utilisateur sur le projet en cours doivent être envoyées à tous les participants. De plus, pour des raisons d ergonomie, on permettra à des participants supplémentaires de se joindre au travail collaboratif à n importe quel moment. Dans ce cadre de travail collaboratif, D-Sight sera l outil principal employé par les utilisateurs pour modifier leurs projets. La plateforme quant à elle servira à définir les différents projets sur lesquels prendront part les utilisateurs de D-Sight ainsi que les droits qui leur sont attribués (cette notion de permission n existe pas dans D-Sight). Les utilisateurs de D-Sight se connecteront au système collaboratif en utilisant un login et un mot de passe correspondant à leur identifiant sur la plateforme et pourront charger dans le logiciel les différents projets auxquels ils ont accès le site internet. Toute modification apportée à l un de ces projets sera répercutée sur la plateforme et sera automatiquement transmise aux autres utilisateurs travaillant sur le même projet. Cette séparation claire du rôle de la plateforme (création et management des projets) et de D-Sight (travail collaboratif sur les projets) fait suite à un choix effectué au cours du mémoire. Initialement, il était prévu que des utilisateurs de D-Sight puissent travailler sur le même projet que des utilisateurs de la plateforme, de façon collaborative.

13 1.3. Le projet 13 Au cours du développement, il est apparu que cette fonctionnalité ne serait pas implémentée, pour les raisons suivantes : Si les fonctionnalités de gestion de projet de la plateforme étaient déjà implémentées, la partie decision restait en chantier. Dans l optique d une commercialisation rapide de la fonctionnalité de travail collaboratif, le fait de limiter le rôle de la plateforme est donc un atout. Decision Sights souhaite continuer à vendre D-Sight en tant que produit principal durant quelques années encore. Il serait donc maladroit de vendre aux entreprises la fonctionnalité de travail collaboratif en mettant en avant que cela leur permettra d utiliser une autre version de D-Sight (cela donne l impression de payer deux fois pour le même service). A ce titre, séparer clairement les possibilités et les rôles de chaque intervenant est donc un atout. D une point de vue ergonomique, une page internet est perçue par les utilisateurs comme un élément statique, contrairement à l interface d un client lourd (un logiciel desktop). S il est techniquement possible de rendre une page internet dynamique (c est à dire, la faire bouger sans action de l utilisateur), cela a tendance à perturber les utilisateurs. Il faut donc être particulièrement attentif à la façon d organiser les pages et offrir des retours visuels plus importants que dans le cas d une application desktop classique. Dans la suite de ce rapport, la plateforme sera donc essentiellement vue comme un outil de management et de stockage des projets plutôt que comme une version web de D-Sight. Notons cependant que rien n empêche un utilisateur de travailler sur un projet via la plateforme en même temps qu un utilisateur qui est connecté sur le même projet via D-Sight. Ils ne profiteront simplement pas de la fonctionnalité de travail collaboratif et donc leurs écrans respectifs ne se modifieront pas automatiquement en fonction des modifications apportées par l autre intervenant.

14 1.4. Intérêt du projet Intérêt du projet Le point de vue académique D un point de vue académique, ce mémoire est une opportunité de développer un système à vocation commerciale basé sur des éléments existants. La phase d analyse du projet nécessitera donc de prendre en compte les contraintes techniques qu ils imposent : Les langages de programmation utilisés. L organisation des structures de données. Les limitations des fonctionnalités implémentées. En plus de ces contraintes techniques, le projet sera cadré par les intérêts de Decision Sights et l ensemble des fonctionnalités implémentées correspond à une plus-value commercialisable pour D-Sight. De plus, le fait que le résultat du projet puisse être utilisé par des entreprises en cas de mise en production, oblige à prendre en compte certains aspects supplémentaires, comme par exemple, la sécurité. Enfin, du point de vue des technologies utilisées, ce projet sera centré autour des communications réseau, et des services web. Le protocole HTTP, fondement même du web, sera présenté et les limitations qu il impose seront analysées. Ces technologies sont actuellement en pleine croissance, comme en témoigne le buzz qui entoure les technologies dites in the cloud. Les compétences acquises durant ce mémoire sont donc typiques de celles d un ingénieur. Sa réussite s appuie à la fois sur une étude réfléchie de la solution à appliquer en fonction des contraintes techniques et des besoins du commanditaire et fait appel à une bonne maîtrise et une bonne compréhension des technologies sous-jacentes Le point de vue de Decision Sights Pour Decision Sights, ce mémoire est une opportunité d apporter une fonctionnalité supplémentaire à D-Sight. De par sa nature, cette fonctionnalité vise principalement les entreprises possédant des équipes de plusieurs personnes dédiées aux problématiques de la décision. Ces entreprises sont une cible privilégiée pour Decision Sights puisqu elles achètent plusieurs licences du logiciel. Le travail collaboratif offre donc deux avantages : 1. Il s agit d une fonctionnalité optionnelle payante pour ces entreprises. Cela représente donc une source de revenus supplémentaire pour Decision Sights. 2. Ce module est utile à ces entreprises dans la mesure où elle permet d intégrer D- Sight beaucoup plus facilement dans le workflow d une équipe. Cela constitue donc un argument marketing supplémentaire. Comme elles le seront présentées dans la suite de ce rapport, certaines modifications seront apportées à D-Sight. Il sera démontré que ces modifications ont des apports positifs pour D-Sight, même en dehors du cadre du projet de travail collaboratif : elles apportent des fonctionnalités supplémentaires dont peuvent profiter tous les utilisateurs de D-Sight. Enfin, ce projet permet à Decision Sights de faire découvrir la plateforme à ses clients avant de la déployer en tant qu alternative à D-Sight. Cela permet d obtenir des premiers

15 1.4. Intérêt du projet 15 retours d utilisateurs vis-à-vis des fonctionnalités de gestion de projet. Il sera ainsi plus aisé de déterminer l organisation des pages et la structure générale du site, en fonction des premiers commentaires.

16 Deuxième partie Implémentation

17 CHAPITRE 2 Vue globale Avant de passer aux détails d implémentation, ce chapitre présentera une vue légèrement plus détaillée et plus technique des différents intervenants du projet. A partir de ces informations, le plan global d implémentation du travail sera établi. Ce plan restera très général, et les chapitres suivants permettront de comprendre comment ce schéma général a pu être mis en oeuvre. Ce chapitre présentera donc successivement : L architecture générale de D-Sight. L architecture générale de la plateforme. Les spécificités du protocole HTTP et de l architecture REST. La dernière section présentera le plan global du travail et les raisons techniques ou économiques qui justifient les choix effectués.

18 2.1. Architecture générale de D-Sight Architecture générale de D-Sight Comme indiqué précédemment, D-Sight est une application desktop, c est-à-dire installable sur un ordinateur et utilisable sans connexion internet. Il a été programmé en utilisant le langage de programmation Java. L organisation du code source de D-Sight suit une optique de séparation entre : Le code constituant la vue Le code constituant le modèle Le code correspondant aux algorithmes La vue La vue est le nom donné à l ensemble du code responsable de l affichage. L interface de D-Sight est architecturée autour d une fenêtre principale servant de conteneur à un ensemble de panels aux rôles précis. On retrouvera ainsi des panels dédiés à l affichage des résultats obtenus par le logicel, et d autres permettant à l utilisateur de modifier certains paramètres. Figure 2.1: Capture d écran de deux panels de D-Sight La gestion (positionnement, redimensionnement, fermeture) de ces panels est dédiée à la libraire InfoNode 1. La majorité du code de cette couche est constitué par l ensemble des panels mis à la disposition de l utilisateur. Dans le cadre de ce projet, l interface de D-Sight ne sera pratiquement pas modifiée, il semble donc peu utile de décrire ces éléments plus en profondeur Le modèle Le modèle est le nom donné à l ensemble des classes permettant à D-Sight de stocker en mémoire l état du problème posé par l utilisateur. On peut voir le modèle comme la base de données du logiciel, ou le conteneur d informations. Chaque panel de D-Sight est lié au modèle (ou à une partie de celui-ci) : pour afficher une valeur, le panel interroge le modèle qui lui renvoie la valeur qu il stocke. Plusieurs panels peuvent être liés à la même valeur et, lorsque celle-ci est modifiée, l ensemble des 1. http ://

19 2.1. Architecture générale de D-Sight 19 panels qui l affichaient (et seulement ceux-là) sont mis à jour. Le mécanisme permettant cela sera exposé plus loin dans ce rapport. Séparer ainsi clairement le code responsable de l affichage du code responsable de la conservation en mémoire des données permet de faciliter la création d applications maintenables en forçant le développeur à créer des classes aux rôles précis et aux dépendances limitées. A ce titre, une règle de bonne pratique stipule que le modèle ne doit pas dépendre de la vue pour fonctionner. En conséquence, introduire de nouveaux panels (et donc potentiellement des bugs au niveau de la vue), n a normalement aucune influence sur l intégrité des données stockées en mémoire. Si la vue est architecturée autour de la fenêtre principale, le modèle s organise autour de la classe DataManager. Comme indiqué précédemment, on peut résumer (grossièrement) D-Sight à un logiciel permettant à des utilisateurs de donner des évaluations à différentes alternatives (nommées actions) en fonction de différents critères dont ils peuvent modifier les propriétés (appelées préférences). A partir de ces informations, la couche algorithme de D-Sight va générer des résultats (principalement sous la forme de scores). La couche de modèle doit donc refléter la présence de ces éléments et les liens qui les unissent. Le schéma UML suivant décrit l organisation grossière du modèle ainsi que les attributs principaux de chaque élément : Figure 2.2: Schéma UML simplifié du modèle de D-Sight On peut voir sur ce schéma que le DataManager est avant tout, une liste de User, Action et Criterion. Il possède également un lien direct vers le ResultManager qui est responsable de la gestion des résultats et qui ne sera pas détaillé ici. Chaque objet Action possède un ensemble d Eval : une par User et par Criterion. Chaque PreferenceStructure stocke quant à elle l ensemble des préférences d un User pour un Criterion donné. La partie modèle est responsable de maintenir sa propre intégrité. Par exemple, lorsqu une alternative est ajoutée, c est le modèle qui va prendre en charge la création des objets Eval pour chaque critère et chaque utilisateur. Le DataManager expose ainsi une

20 2.1. Architecture générale de D-Sight 20 interface composée d un ensemble de méthodes aux noms évocateurs et qui masquent la complexité du maintien d un modèle cohérent au reste de l application. La couche modèle possède également un ensemble de classes (non représentées sur le schéma ci-dessus) permettant la persistance, c est-à-dire la sauvegarde du modèle dans un fichier et la restauration du modèle à partir de ce même fichier. C est ce qui permet à D-Sight de proposer à l utilisateur d enregistrer son travail pour le réouvrir plus tard ou le transmettre à un autre utilisateur La partie algorithme Tout comme la vue, la partie algorithmique (également appelée couche applicative) repose sur le modèle. Elle a pour rôle de prendre les données entrées par l utilisateur (évaluations, préférences,...) afin de produire les résultats qui sont ensuite injectés dans le ResultManager. Figure 2.3: Utilisation de la couche algorithme de D-Sight. Comme indiqué précédemment, cette couche applicative est une implémentation en java de la méthodologie PROMETHEE - GAIA. Dans le cadre de ce projet, il n est pas utile de détailler cette couche et son organisation dans la mesure où ce sont les données brutes qui doivent être échangées plutôt que les moyens de générer les résultats La gestion des plugins En plus de cette organisation, D-Sight possède un module permettant la gestion de plugins. Ces plugins se présentent sous la forme de fichiers.jar qu il est possible de charger depuis un menu spécifique de D-Sight. En chargeant ces plugins, on peut ainsi ajouter des fonctionnalités à D-Sight ou modifier son comportement. Certains de ces plugins sont vendus par Decision Sights, tandis que d autres sont mis à disposition gratuitement. D un point de vue plus technique, ces plugins sont des bundles OSGI 2. Le module de D-Sight dédié au support des plugins met à disposition de ces derniers un service leur permettant d accéder, via un pointeur, aux deux couches principales de D-Sight : 1. Un pointeur permet d accéder au DataManager, élément central de la couche modèle 2. OSGI : http ://

21 2.1. Architecture générale de D-Sight Un pointeur permet d accéder à la MainWindow, élément central de la couche vue Via le pointeur de la vue, il est possible d accéder à la couche applicative si le besoin s en fait sentir, mais ce cas de figure reste rare. Ces plugins permettent typiquement d ajouter des panels supplémentaires à D-Sight. Eventuellement, certains plugins comprennent également une couche applicative et une couche modèle qui leur sont propres, leur permettant d intégrer leurs propres algorithmes ou de stocker des informations supplémentaires. A titre d exemple, on pourrait citer le plugin de carte qui permet de lier certaines alternatives à des zones géographiques à l aide d une carte interactive. Ces plugins sont distribués soit de façon pré-installée avec le logiciel (plugin réalisé sur commande d une entreprise), soit dans un store intégré à D-Sight (plugin plus généraliste proposé gratuitement ou de façon payante à toutes les entreprises).

22 2.2. Architecture générale de la plateforme Architecture générale de la plateforme Comme indiqué précédemment, la plateforme est une application web (un site internet) programmé dans le langage Ruby, avec l aide du framework Ruby on Rails. Ce mémoire a été réalisé à partir d une version non finalisée de la plateforme. Comme toute application web, la plateforme peut être vue comme un logiciel qui doit produire une réponse sous la forme d un texte, à partir d une requête arrivant elle aussi sous la forme d un texte. Cet aspect fondamental des applications web sera exposé plus en détail dans la section suivante. Le framework Ruby on Rails oblige les applications l utilisant à séparer le code en trois couches[2] : La couche modèle comme pour D-Sight, est la couche responsable de la gestion des données. Elle est composée de l ensemble des classes permettant l interaction avec une base de données. La couche vue comme pour D-Sight, c est à ce niveau que se trouve le code définissant l aspect des pages du site. La couche contrôleur va interagir avec la couche modèle et définir la page à afficher en fonction de la requête. Cette séparation en trois couches : Modèle - Vue - Contrôleur est très employée dans le monde informatique ou elle est reconnue sous l acronyme MVC. Si la plateforme a pour objectif à long terme d offrir une alternative à D-Sight, le fait qu elle soit encore en plein développement limite fortement les éléments qu elle est capable de gérer. Chaque entreprise souhaitant avoir accès à la plateforme doit créer un compte client. A ce compte client seront rattachés un ou plusieurs utilisateurs qui disposent chacun d un login et d un mot de passe. Ces utilisateurs sont liés à un ou plusieurs projets sur lesquels ils possèdent certains droits. Chaque projet possède des alternatives et des critères. En fonction de leurs droits, les utilisateurs peuvent éventuellement donner des évaluations à chaque alternative pour chaque critère. Le schéma relationnel permettant de stocker ces éléments dans la base de données de la plateforme est présenté sur la Figure 2.4 Une analyse comparative du modèle de D-Sight et de la plateforme permet de noter les éléments suivants : La notion de projet comprend les mêmes informations qu un fichier D-Sight. La plateforme ne gère pour chaque projet que les alternatives, les critères et les évaluations. Toutes les notions de structures de préférences intégrées à D-Sight ne sont pas encore implémentées complètement. La plateforme introduit les notions de droits et de permissions qui sont absentes de D-Sight. Il sera donc nécessaire de trouver un moyen de gérer ces notions si (et seulement si) l utilisateur travaille dans un cadre collaboratif.

23 2.3. Le protocole HTTP 23 Figure 2.4: Schéma relationnel simplifié de la base de données de la plateforme 2.3 Le protocole HTTP Présentation générale HTTP (Hyper Text Transfert Protocol) est le protocole sur lequel repose les échanges de données intervenant dans le cadre du World Wide Web (WWW)[9], c est-à-dire l affichage de pages internet. Une présentation générale des caractéristiques de ce protocole est nécessaire pour permettre au lecteur de comprendre les choix techniques effectués. Le World Wide Web repose sur l échange de messages HTTP : lorsqu un utilisateur navigue sur un site internet, son navigateur va se connecter à ce site internet, effectuer une requête HTTP et attendre une réponse. L ordinateur sur lequel est situé le site en question va accepter la connexion, recevoir la requête et produire une réponse HTTP qu il renvoie à l utilisateur. Chaque action de l utilisateur (clic sur un lien, validation d un formulaire,...) va être traduite par son navigateur en requête HTTP envoyée au site. Une application web repose sur un logiciel appelé serveur web 3 qui va réceptionner la requête HTTP, la transmettre 3. Parmi les serveur web les plus célèbres, on peut citer : Apache, Microsoft IIS ou encore Lighthttpd

24 2.3. Le protocole HTTP 24 à un logiciel écrit par le programmeur qui va être capable de produire une réponse à cette requête. Le serveur web récupère cette réponse et la renvoie à l utilisateur avant de couper la connexion. Il est essentiel d observer que le cycle de vie d une application web est totalement lié à cette notion de requête / réponse. Toute requête est suivie par une et une seule réponse. L application écrite par le programmeur ne réside pas en mémoire, et n a pas de sens hors de ce cycle requête / réponse. En d autres termes, l application démarre avec la requête et se ferme dès que la réponse a été produite. Ce cycle de vie extrêmement court est la raison pour laquelle les applications web s appuient sur des bases de données (c est-à-dire des programmes externes ) pour mémoriser des informations entre plusieurs exécutions. Figure 2.5: Comparaison du cycle de vie d une application web et d une application desktop. Une conséquence majeure de ce mode de fonctionnement est l impossibilité pour l application web de prendre l initiative de contacter un utilisateur en cas d un événement quelconque. Toute information transitant du site internet vers l utilisateur doit nécessairement être la réponse à une requête de ce dernier. Enfin, il est important de noter que HTTP est un protocole stateless ce qui signifie que chaque requête est traitée indépendamment des requêtes précédentes. Ce point jouera un rôle important dans le cadre de problématiques d authentification et sera abordé plus en détail dans la suite de ce rapport. Afin de contrer cette limitation, la technologie AJAX (Asynchronous Javascript and XML) a été mise au point. Cette technologie consiste à effectuer des requêtes régulièrement et de façon cachée et de traiter le résultat avec du javascript afin de mettre la page de l utilisateur à jour en réaction aux réponses du serveur. Il s agit donc d une interrogation régulière du serveur par le client, autrement dit, du polling.

25 2.3. Le protocole HTTP Anatomie du protocole La requête HTTP Une requête HTTP se présente sous la forme suivante : POST / form / user HTTP /1.1 Accept - Language : en name = test POST est la méthode HTTP utilisée. Les méthodes actuellement définies sont : HEAD, GET, POST, PUT, DELETE, TRACE, OPTIONS, CONNECT, PATCH. L utilité de certaines d entre elles sera abordée à la section suivante. On peut globalement considérer que la méthode HTTP décrit l intention de la requête (DELETE = supprimer, GET = récupérer,...) /form/user est l URL (Uniform Ressource Locator) d une ressource. Si la méthode représentait l intention de la requête, l URL décrit la ressource sur laquelle effectuer l opération. Accept-Language : en est un en-tête de la requête. Une requête peut comporter un nombre indéfini d en-têtes qui peuvent être vus comme des informations supplémentaires optionnelles que l on fournit au serveur web ou à l application. Une ligne vide sépare les en-têtes et le corps de la requête. name=test est le corps de la requête. En fonction de la requête, le corps peut être vide ou contenir des informations diverses La réponse HTTP Une réponse HTTP se présente sous la forme : HTTP / OK Date : Fri, 31 Dec :59:59 GMT Content - Type : text / html Content - Length : 1354 <html > <body > <h1 >Page Test </h1 >... </ body > </ html > 200 OK est le code du statut de la requête. Il sert à indiquer si la requête s est déroulée correctement (200/OK), ou si elle a rnecontré un problème. Les erreurs les plus courantes peuvent être : un bug dans l application web (500/Internal Server Error) ou encore l appel à une ressource non disponible (404/Not Found). Des headers servent à indiquer le type de contenu de la réponse ou sa longueur.

26 2.3. Le protocole HTTP 26 Une ligne vide sépare les headers du corps de la réponse. Le corps de la réponse contient les données que l application web souhaitait renvoyer. Dans le cas du World Wide Web, ces données sont souvent des strings HTML que le navigateur de l utilisateur est capable de lire et d interpréter pour générer les pages web vues par les utilisateurs.

27 2.4. L architecture REST L architecture REST REST (Representational State Transfer) est un type d architecture pour les systèmes distribués. On dit d un web service respectant les principes de REST qu il est RESTful [20]. Dans la mesure où Ruby on Rails encourage fortement la création d applications web RES- Tful tant au travers de sa documentation que des éléments qu il génère, il est important de donner au lecteur un aperçu des caractéristiques d un service RESTful. Une application RESTful peut être vue comme un ensemble de collections de ressources. Dans le cas de la plateforme, les ressources auxquelles on fera principalement référence dans ce projet seront par exemple : les utilisateurs, les alternatives, les critères ou les évaluations. L idée fondamentale de REST consiste à attribuer à chaque ressource et à chaque collection, une URL[20, 12]. On peut assigner à la collection des utilisateurs, l url : / users et assigner à chaque utilisateur une url dépendant, par exemple, de son nom. Ainsi, l utilisateur alice se verra attribuer l url : / users / alice L application web va permettre à ses clients d interagir avec ces ressources au travers de requêtes HTTP. Comme décrit plus haut, la méthode HTTP va décrire l intention du client vis-à-vis de la ressource. Les 4 méthodes utilisées sont GET, POST, PUT et DELTE. Sur une URL de collection : (par exemple, /users) : GET renvoie une liste de ressources (par exemple, une liste d utilisateurs). POST ajoute un élément à la liste (par exemple, un nouvel utilisateur va être créé). PUT remplace tous les éléments de la liste. DELETE supprime tous les éléments de la liste. Sur un URL de ressource : (par exemple, /users/alice) : GET renvoie toutes les informations concernant cette ressource (par exemple, tous les détails d alice). POST transforme la ressource en collection (peu utilisé). PUT modifie cette ressource. Par exemple, une requête PUT vers /users/alice contenant dans le corps de la requête age=22, va modifier alice pour lui donner 22 ans. DELETE supprime la ressource.

28 2.4. L architecture REST 28 Cette architecture garantit deux éléments important : 1. La requête GET est dite safe : elle ne modifie jamais la base de données de l application. 2. Les requêtes PUT et DELTE sont dites idempotentes : effectuer une ou plusieurs fois la même requête mène à un résultat identique. Une requête safe est donc toujours idempotente. Les requêtes de type POST sont donc les seules à poser d éventuels soucis en cas d appels répétés. Ces éléments sont connus des navigateurs qui prennent cela en compte. Enfin, une bonne pratique d une architecture RESTful consiste à utiliser l extension de l URL comme descriptif du schéma souhaité de la réponse. Ainsi, les deux requêtes suivantes : GET GET / users / alice. html / users / alice. xml correspondent bien à la même action (récupérer les informations concernant alice), mais la première attend une page internet comme réponse, sans doute afin de l afficher dans un navigateur, tandis que la seconde attend un flux XML, sans doute pour être utilisé dans le cadre d une application (par exemple D-Sight). Pour le programmeur de l application web, une partie du code de ces deux requêtes est similaire (et ne doit donc être écrit qu une seule fois), seule la partie mise en forme de la réponse change (c est à dire la couche vue dans le cadre d une application web respectant le pattern MVC). Les deux principales forces de Ruby on Rails sont : d une part que les URL et les contrôleurs basiques aux requêtes GET, POST, PUT et DELETE sont générées pour chaque type de ressources. Et d autre part que l application du pattern MVC permet cette réutilisation du code du contrôleur si seul le format de la réponse (la vue) change. Le programmeur ne passe du temps à écrire des contrôleurs que si ceux-ci doivent réaliser des opérations non standards, et il peut se concentrer sur la mise en forme des réponses (c est-à-dire la vue).

29 2.5. Organisation du travail Organisation du travail L objectif de cette section est de décrire l organisation à haut niveau du projet. Au terme de ce chapitre, le lecteur aura un aperçu général des différents éléments intervenant dans le projet et de leurs rôles dans le cadre du travail collaboratif. Les chapitres suivants traiteront de l implémentation réalisée. De façon très grossière, on peut énoncer le problème de la façon suivante : Lorsqu un utilisateur souhaite travailler de manière collaborative, il va se connecter avec D-Sight à une entité indéfinie qui va lui permettre de charger son projet. Toutes les modifications qu il effectue seront répercutées en temps réel sur la base de données de la plateforme et les modifications apportées par d autres intervenants lui seront automatiquement transmises. Figure 2.6: Pour les clients, les éléments contenus dans internet se chargent de gérer les échanges d informations et de mettre à jour la plateforme. Parmi les impératifs supplémentaires du projet, on va ajouter deux éléments fondamentaux : 1. La fonctionnalité de travail collaboratif doit pouvoir être incluse dans D-Sight ou retirée facilement. Ceci est indispensable pour pouvoir éventuellement commercialiser le travail collaboratif comme une option supplémentaire. 2. La plateforme est en plein développement. Il n est pas souhaitable que le système de travail collaboratif développé durant ce projet ait une influence trop importante sur le futur de cette plateforme. En d autres termes, la plateforme doit pourvoir être développée de manière indépendante, ou presque, et le système implémenté durant ce mémoire doit pouvoir s adapter aux nouvelles fonctionnalités et aux modifications de la plateforme.

30 2.5. Organisation du travail 30 La première contrainte va obliger à externaliser l ensemble du code ajouté à D-Sight pour gérer le travail collaboratif dans un plugin. Ce plugin peut alors simplement être activé ou désactivé par les utilisateurs selon qu ils souhaitent profiter de la fonctionnalité de travail collaboratif, ou non. Ce plugin appelé dans la suite de ce rapport : Plugin Collaboratif contiendra typiquement l ensemble du code relatif aux écrans de connexion, et l ensemble du code de traitement qui permettra d échanger des informations avec d autres intervenants. Si certaines modifications doivent être apportées à D-Sight ou à la plateforme, elles devront être génériques et réutilisables : il s agira de modifier l application de façon à lui apporter une souplesse supplémentaire qui sera exploitée dans le cadre du projet. Mais cette souplesse doit pouvoir être réutilisée dans le cadre d autres innovations et n est donc pas liée directement au travail collaboratif. Rapidement, il est apparu que connecter directement les différentes instances de D- Sight à la plateforme (au travers du plugin collaboratif) ne serait pas une bonne idée. Deux raisons expliquent cela : 1. Connecter directement D-Sight à la plateforme implique d ajouter à celle-ci tout le code de gestion des connexions avec les instances de D-Sight. On modifie donc lourdement la plateforme dans le seul but de gérer le travail collaboratif, ce qui est totalement contraire aux contraintes exposées précédemment. 2. La plateforme repose sur des échanges de messages HTTP. Les limitations de HTTP, exposées au chapitre précédent, le rendent peu adapté à la gestion de session de travail collaboratif. D une part, parce qu il est stateless et que chaque requête est donc indépendante (ce qui est contraire à l idée même de session ). Ensuite car il n est pas prévu par l architecture client-serveur classique que le serveur (dans ce cas-ci, la plateforme) puisse prendre l initiative de contacter les clients. Il est donc impossible de programmer dans la plateforme un module qui réaliserait l opération : Lorsqu un élément d un projet est modifié par un intervenant, il faut contacter les autres intervenants pour leur notifier cette modification. Il sera nécessaire d introduire un nouvel élément qui sera nommé Serveur Collaboratif auquel les instances de D-Sight vont se connecter. Puisque cet élément n existe pas et n a de sens que dans le cadre du travail collaboratif, le choix des technologies utilisées est libre. A ce titre, on privilégiera une connexion entre les instances de D-Sight et le serveur collaboratif sous la forme de sockets TCP. Ce socket TCP peut être vu comme un simple canal reliant une instance de D-Sight au serveur collaboratif. N importe laquelle de ces deux entités peut prendre l initiative d envoyer des bits dans ce canal, qui seront reçus par l autre intervenant. On s affranchit ainsi des limitations du protocole HTTP en laissant le socket ouvert durant la durée totale du travail collaboratif au lieu de fermer la connexion après chaque couple requête - réponse, comme le préconise HTTP.

31 2.5. Organisation du travail 31 Une fois la présence du serveur collaboratif acceptée, la question devient : Comment relier le serveur collaboratif à la base de données de la plateforme? Deux approches sont envisageables : 1. Soit on connecte le serveur collaboratif directement à la base de données de la plateforme. 2. Soit on connecte le serveur collaboratif à la plateforme qui est elle-même connectée à sa base de données. Figure 2.7: Possibilités d interconnexion entre le serveur collaboratif et la base de données. La connexion directe implique que le serveur collaboratif va jouer le même rôle que la plateforme : il va recevoir des messages provenant d instances de D-Sight, les analyser et modifier la base de données si nécessaire. Il s agit donc de placer dans le serveur collaboratif les mêmes fonctionnalités que dans la plateforme. Ce n est pas une situation souhaitable que d avoir deux éléments réalisant la même tâche car, en plus de multiplier inutilement le travail : Deux interfaces offrent un accès direct à la base de données. On augmente donc le risque qu il y ait des vulnérabilités exploitables par un attaquant et on prend ainsi des risques au niveau de la sécurité de l ensemble. On risque d introduire des incohérences entre la façon dont la plateforme gère ses données et la façon dont le serveur collaboratif gère les mêmes données. La moindre incohérence à ce niveau peut mener à un écroulement complet du système (ni la plateforme, ni le serveur collaboratif ne fonctionnent). Dans la mesure du possible, il est préférable de réutiliser au maximum les contrôleurs déjà programmés dans la plateforme.

32 2.5. Organisation du travail 32 La connexion via la plateforme implique que le serveur collaboratif joue le rôle de traducteur entre D-Sight et la plateforme : il va recevoir les messages provenant d instances de D-Sight, les analyser et contacter la plateforme via des requêtes HTTP si nécessaire. La plateforme est donc la seule à posséder un accès à la base de données. Du point de vue de la sécurité, les accès à la base de données (en lecture ou écriture) se font donc toujours au travers de la plateforme. Si celle-ci implémente les vérifications nécessaires, la présence de vulnérabilités dans le serveur collaboratif ne sera pas synonyme de porte d entrée supplémentaire pour un attaquant. On élimine également le risque d incohérence puisque la plateforme reste seule maître de la base de données. Il n y a donc pas de risque que les données soient gérées différemment selon qu elles proviennent de D-Sight, ou d une utilisation normale de la plateforme via un navigateur internet. Le serveur collaboratif aura dans ce cas la responsabilité de réaliser le lien entre la plateforme qui attend des requêtes HTTP sur un modèle client-serveur et les instances de D-Sight qui communiqueront via des sockets TCP. On respecte ainsi les deux contraintes : D-Sight ne devrait pas devoir contenir de code spécifique au travail collaboratif puisque celui-ci est placé dans un plugin. Et la plateforme va pouvoir évoluer normalement puisque toute la complexité de la discussion avec des instances de D-Sight est placée dans le serveur collaboratif. Figure 2.8: Interconnexion entre les différents intervenants du mémoire.

33 CHAPITRE 3 Communication entre D-Sight et le serveur collaboratif Ce chapitre, traite des différents échanges prenant part entre plusieurs instances de D-Sight et le serveur collaboratif. Seront successivement présentés : L ensemble des informations à échanger. Comment D-Sight a été modifié pour permettre ces échanges. Le protocole utilisé entre D-Sight et le serveur. L organisation du code du serveur. Les mesures de sécurité mises en place pour ces communications. La plateforme Ruby on Rails n interviendra ici que très peu. Sauf mention contraire, l utilisation du mot serveur fera donc référence au serveur collaboratif, et non pas au serveur de la plateforme. De la même façon, le mot client fera référence à une instance de D-Sight. Comme expliqué au chapitre précédent, la connexion entre un client et le serveur est donc, dans ce chapitre, bi-directionnelle. Au terme de cette partie du travail, l ensemble des éléments sont en place pour permettre un travail collaboratif entre plusieurs instances de D-Sight travaillant sur un projet commun sans intervention de la plateforme.

34 3.1. Informations à échanger Informations à échanger La communication entre les clients et le serveur peut-être séparée en deux types. On distingue : Les messages qui vont du client vers le serveur. Les messages qui vont du serveur vers le client (possibles puisque la liaison est bi-directionnelle). Dans un cas typique de fonctionnement, les messages provenant d un client servent à signifier au serveur que ce client a effectué une opération qui a modifié les données dans D-Sight. A l inverse, les messages issus du serveur servent à notifier aux clients qu une opération a été effectuée par une autre instance de D-Sight travaillant sur le même projet. Lorsqu un client contacte le serveur pour lui indiquer qu une commande a été effectuée, il doit donc lui transmettre l ensemble des informations nécessaires pour que ce serveur puisse à son tour contacter les autres clients et transmettre un message leur permettant d effectuer la même commande. Pour des raisons de performance, il est nécessaire de limiter au maximum la taille des données échangées et il est donc important d essayer de limiter la transmission aux seules données qui ont réellement été modifiées. Trois raisons font qu il est, par exemple, impossible de renvoyer l ensemble du projet chaque fois qu un élément de celui-ci est modifié : Le temps de connexion nécessaire au client pour tout transmettre à chaque fois. Le temps de calcul requis par le serveur pour synchroniser une telle information avec la plateforme. Les coûts en bande passante que cela engendrerait pour Decision Sights. L information à transmettre se limite donc idéalement à indiquer : l élément modifié, l attribut concerné et la nouvelle valeur de celui-ci. Un message minimum mais suffisant serait donc une version informatique de : Le nouveau nom de l alternative a3 est : alternative3. Si un tel message arrive vers le serveur, celui-ci peut envisager de notifier la plateforme sans devoir consacrer trop de temps de calcul, et il peut notifier les autres clients de la modification à effectuer Utilisation des UUID Un problème se pose cependant : comment identifier univoquement un élément (alternative, critère, évaluation,...) entre plusieurs instances de D-Sight travaillant sur un même projet? Dans le cadre de ce projet, un bon identifiant doit offrir quatre caractéristiques. Il doit être : 1. Unique : un identifiant correspond à un et un seul élément. 2. Immuable : l identifiant ne change pas au cours du cycle de vie de l élément. 3. Partagé : le même élément doit avoir le même identifiant sur l ensemble des instances de D-Sight travaillant sur le même projet. 4. Stockable dans une base de données : pour permettre la synchronisation avec la base de données de la plateforme durant la suite du projet.

35 3.1. Informations à échanger 35 L idée initiale était d utiliser, pour les alternatives et les critères, le nom de l élément comme identifiant. Pour les évaluations, l identifiant était composé du nom de l alternative, du critère et de l utilisateur auxquelles elles étaient rattachées. Mais le nom ne constituait pas un bon identifiant dans la mesure où celui-ci n est pas immuable. On s expose donc à des problèmes de conditions de courses 1 si deux modifications sont effectuées presque simultanément sur le même élément par deux instances différentes de D-Sight. Figure 3.1: Illustration d un problème de condition de course Il aurait été possible d utiliser le nom comme identifiant à condition d implémenter un système de contrôle au niveau du serveur, celui-ci réalisant les traductions de messages s il détecte une condition de course. Cette solution est particulièrement lourde puisqu elle oblige le serveur à garder en mémoire un état de chacun des intervenants dans le seul but d éviter un problème qui reste exceptionnel. Un autre possibilité aurait été de forcer les commandes à être exécutées séquentiellement. Lorsque l utilisateur souhaite effectuer une modification, son instance de D-Sight demande une autorisation au serveur, celui-ci n accepte qu une seule demande à la fois. Le client envoie alors sa commande et lorsque celle-ci a été transmise à tous les autres clients participants, le serveur peut à nouveau accepter des connexions. Si le serveur refuse, le client est mis sur file d attente. Cette solution est particulièrement lourde pour l utilisateur, qui peut voir l effet de ses actions retardé sans réelle raison apparente et donner ainsi une impression de lenteur toujours malvenue. Enfin, il est nécessaire de gérer les cas où un client planterait / fermerait le programme entre le moment où il a réservé son canal et celui où il envoie sa commande. Aucune donnée dans D-Sight ne pouvait donc faire office d identifiant de façon efficace. Un champ d identification supplémentaire a donc été ajouté aux éléments le nécessitant : alternatives, critères et utilisateurs. Ce problème d identifications de ressources sur plusieurs systèmes distribués est relativement classique et une solution générique a été proposée par l OSF (Open Software Fondation) sous la forme des UUID. 1. Une condition de course est un défaut caractérisé par un résultat différent selon l ordre dans lequel sont effectuées certaines opérations du système.

36 3.1. Informations à échanger L UUID (Universal Unique Identifier) Un UUID est un nombre, codé sur 128 bits, conçu de manière à être unique dans le monde. Initialement, les UUID étaient conçus à partir de l adresse MAC de l ordinateur le produisant et du nombre de dixièmes de microsecondes écoulées depuis la première date dans le calendrier Grégorien[6]. Ceci garantissait l unicité puisque deux ordinateurs ne peuvent pas, en théorie, avoir la même adresse MAC, et qu un ordinateur ne peut générer deux UUID durant le même dixième de microseconde. Cet algorithme de génération a été jugé trop peu sécurisé puisqu il donnait des informations à la fois sur l ordinateur ayant généré l UUID et sur la date à laquelle il a été généré. L histoire veut que cette faille ait été à l origine de l identification de l auteur du virus Melissa [18] qui avait sévi durant les années 1999 et Depuis, les méthodes de production d UUID ont évolué. La version actuelle est la V4. Elle se base sur des générateurs de nombres pseudo aléatoires : sur les 128 bits de l UUID, 122 sont générés aléatoirement. Les bits restants servant à indiquer le numéro de version et la variante de l algorithme utilisé. Il n y a donc pas de garantie d unicité associée avec l utilisation d UUID. Cependant, avec possibilités, les chances de générer 2 UUID similaires sont infimes. Pour donner un ordre de grandeur : pour arriver à une probabilités d avoir une collision (2 UUID similaires) d environ 50%, il serait nécessaire de générer 1 milliard d UUID chaque seconde durant 100 ans 2. La possibilité d avoir une collision au niveau des UUID est donc considérée comme suffisamment négligeable dans le cadre de ce projet. 2. Ce calcul est une application simple du 3 [15]

37 3.2. Modifications apportées à D-Sight Modifications apportées à D-Sight Pour permettre d effectuer ces échanges d informations, il est nécessaire d organiser D-Sight de façon à ce que : toute modification du modèle par l utilisateur puisse être transformée en message envoyé au serveur, tout message du serveur puisse être converti en une modification du modèle, l ensemble du code relatif aux échanges avec le serveur doit pouvoir être externalisé dans un plugin. Les échanges entre la vue (l interface) et le modèle se faisaient de manière directe, sans intervention d un contrôleur. Une fois la modification enregistrée sur le modèle, celui-ci émettait le ou les événements nécessaires, et l interface se mettait à jour via le système observable/observer. Les détails d implémentation de ce pattern ne seront pas traités dans ce rapport puisque ce travail n a pas été effectué dans le cadre du mémoire. Le lecteur intéressé pourra trouver de plus amples informations sur ce pattern à l adresse suivante : 04-qa-0525-observer.html Figure 3.2: Séquence des messages envoyés dans D-Sight lors d une modification du modèle par l utilisateur Une analyse de ce système donne deux informations importantes : 1. Si on modifie le modèle, l interface se met à jour toute seule via le système de observable/observer 4 2. Il n y a pas de contrôleur centralisé par lequel passe toutes les commandes de l utilisateur. 4. Ce design pattern avait été implémenté lors de l inclusion du système de gestion de plugins pour éviter que les plugins aient à avoir conscience des détails de rafraîchissement de l interface

38 3.2. Modifications apportées à D-Sight 38 Si le premier point est un élément très positif dans l optique de ce travail, le second rend la création du plugin largement plus complexe puisqu il n existe, à priori, aucun moyen simple d intercepter toutes les commandes de l utilisateur pour les transmettre au serveur. Il apparaît donc que la mise en place d un contrôleur centralisé serait un travail long, mais sans doute indispensable à la réussite du projet. En discutant de ces points avec le promoteur du mémoire, celui-ci a rappelé qu une des fonctionnalités manquantes du logiciel était un système d annulation des dernières commandes effectuées (undo). Cette fonctionnalité avait été abordée plusieurs fois durant le stage précédant le mémoire, mais la quantité des modifications à apporter au logiciel avait été jugée incompatible avec notre volonté de garder un rythme élevé de mise à jour durant le stage, et surtout, de fournir de nouveaux plugins afin de remplir le store. La façon classique de réaliser un système d undo / redo consiste à implémenter au sein du logiciel, le design pattern Command. Or, ce pattern requiert la mise en place d un élément centralisé par lequel transitent toutes les commandes de l utilisateur. Ce pattern a donc été implémenté au sein de D-Sight Le pattern Command L idée principale de ce design pattern est de créer un objet Command qui contiendrait l ensemble des informations nécessaires pour exécuter une méthode[5, 22]. On distingue les trois intervenants suivants : le Client, l Invoker et le Receiver. Le Client est l objet qui crée la Command (souvent, il s agit d un élément de l interface). L Invoker décide lorsque la commande doit être exécutée (c est une partie du contrôleur). Le Receiver est l objet sur lequel est effectué la commande. L exécution d une action de l utilisateur avec ce design pattern se déroule donc en trois étapes : 1. Client crée un objet Command, le remplit de toutes les informations nécessaires à l exécution de son action et le passe à l Invoker. 2. L Invoker analyse la commande, et, si elle est valide, envoie un message à l objet Command pour lui demander de s exécuter. 3. La Command envoie un message au Receiver pour effectuer l action demandée par le Client. Ce pattern permet d implémenter un système d undo si, lors de la création de l objet Command, celui-ci contient suffisamment d informations pour pouvoir être appelé soit dans le sens up (exécution de la commande) soit down (annulation de la commande). L Invoker garde alors en mémoire un stack des commandes effectuées. Lorsque l utilisateur appuie sur le bouton d undo, la commande au sommet du stack est annulée Implémentation du pattern Command dans D-Sight Dans le cas de D-Sight, la majorité du travail consiste à créer les objets Command pour chaque opération que l utilisateur peut effectuer, et à modifier l ensemble des Client pour utiliser ce pattern au lieu de contacter directement le modèle. Seules les actions de

39 3.2. Modifications apportées à D-Sight 39 Figure 3.3: Comparaison entre un appel de méthode classique et la même opération en utilisant le design pattern Command l utilisateur ayant une influence sur le modèle utilisent ce système. Ainsi, redimensionner une fenêtre ne donne pas lieu à la création d un objet Command. L implémentation s est éloignée du design de référence, présenté à la section précédente, pour deux raisons : 1. Certaines actions de l utilisateur ne pouvaient que difficilement se traduire en une seule commande. 2. Il était nécessaire de mettre en place un véritable contrôleur avant que la commande n arrive à l Invoker. Il a donc fallu adapter ce pattern pour répondre au mieux aux besoins spécifiques de D-Sight. La section suivante traitera des modifications apportées par le mémorant au design de référence afin de répondre aux besoins spécifiques de D-Sight Gestion de la complexité des commandes Dans D-Sight, certaines commandes peuvent être difficiles à annuler. C est par exemple le cas d une commande qui demanderait de supprimer une alternative : pour annuler cette commande, il faut non seulement recréer une alternative (avec le même identifiant, cf 3.1.1), mais il faut également lui remettre son nom, son short-name, ses évaluations,... Or, le code exécutant chacune de ces opérations élémentaires va également devoir être utilisé par d autres commandes. Pour des raisons évidentes de maintenance et de stabilité du programme, il est essentiel que le code qui exécute ces opérations élémentaires soit partagé et non pas dupliqué par les différentes commandes qui en ont besoin. L objet Instruction a donc été créé : une instruction réalise une opération élémentaire et ne peut s exécuter que dans un seul sens. Les Command sont alors constitués de deux listes d Instruction : la liste des instructions à exécuter pour effectuer la commande, et la liste des instructions à effectuer pour annuler cette commande. Par conséquent, lorsque l Invoker va envoyer le message d exécution ou d annulation à l objet Command,

40 3.2. Modifications apportées à D-Sight 40 en interne, ce message est géré en exécutant successivement chacune des instructions de la liste ad-hoc. Figure 3.4: Contenu d un objet Command Seule exception à cette règle : dans certains cas, l objet Command peut décider d agir au niveau du système observable/observer pour couper la transmission des messages vers l interface le temps d exécuter une suite d instructions similaires ou liées. Ce mécanisme est purement optionnel et est mis en oeuvre pour des raisons de performance. Pour faciliter la création de Command par les Client, le design pattern Factory a été utilisé. Ce pattern consiste simplement à créer des classes, nommées Factories, dédiées à la création d instances. Ce pattern offre deux avantages : 1. Masquer la complexité de la création d objets Command par les Client. 2. Introduire une couche d abstraction entre les Client et les Command : si l organisation des Command devait changer dans le futur, les Client ne devraient pas être modifiés tant que l interface des Factories reste stable. Dans les faits, la majorité du travail de création des instructions est implémenté directement dans le constructeur des Command. Les Factories servent essentiellement à faciliter le travail du développeur au travers des outils d auto-complétion des IDE modernes. Pour bien comprendre le travail de création d une commande, le plus simple est de suivre étape par étape le processus qui produit une commande permettant de changer le nom d un critère. Il s agit d une commande simple, les subtilités qui interviennent dans le cas de commandes plus complexes seront présentées ensuite.

41 3.2. Modifications apportées à D-Sight 41 Etape 1 : Le développeur dispose d un pointeur vers le critère à modifier et le nouveau nom qu il faut lui attribuer. Il souhaite obtenir une instance de la classe Command qu il pourra passer au contrôleur (et donc à l Invoker) pour que l opération se fasse. Il tape : Command changernom = CommandFactory. Criterion. ChangeName ( criterion, newname ); Criterion est un membre publique de la classe statique CommandFactory et est un objet de type CriterionCommandFactory ChangeName(criterion, newname) ; est une méthode publique de la classe CriterionCommandFactory et renvoie un objet de type Command : Command ChangeName ( Criterion criterion, String newname ){ return new ChangeCriterionNameCommand ( criterion, newname ); } Etape 2 : Le constructeur de l objet ChangeCriterionNameCommand reçoit en paramètre un pointeur vers le critère à modifier et le nouveau nom à attribuer à ce critère. Il initialise ses deux listes d Instruction et crée les deux instructions qui permettront d effectuer l opération ou l annuler : ChangeCriterionNameCommand ( Criterion crit, String newname ){ upinstructions = new ArrayList < Instruction >(); downinstructions = new ArrayList < Instruction >(); upinstructions. add ( new ChangeCriterionNameInstruction ( crit. getuuid (), newname )); downinstructions. add ( new ChangeCriterionNameInstruction ( crit. getuuid (), crit. getname ())); } Il est essentiel de noter que les Instruction ne stockent ni n utilisent aucun pointeur : pour créer une instruction, il suffit d avoir accès aux identifiants des éléments à modifier. Ce point sera essentiel dans le cadre de la mise en relation de plusieurs instances de D- Sight par l intermédiaire du serveur. Stocker ainsi un identifiant au lieu du pointeur oblige à effectuer une recherche supplémentaire lors de l exécution de l Instruction. Cependant, il aurait été compliqué de stocker directement les pointeurs au sein des Instruction à cause du système de redo. Encore une fois, un exemple simple semble être le meilleur moyen de démontrer ce problème : Un utilisateur crée un critère, puis en change le nom (2 commandes). L utilisateur pousse 2x sur le bouton undo. Le critère est donc supprimé. L utilisateur pousse 1x sur le bouton redo. Son critère est donc recréé. Mais rien ne garantit qu il a la même adresse en mémoire et le programmeur ne peut agir sur ce point là. Par contre, puisqu il s agit du même critère, il possède le même identifiant que lors de sa première création. L utilisateur pousse encore sur redo. Si l instruction recherche le critère via son pointeur, le système lève une exception. Si elle recherche le critère via son identifiant, tout se passe normalement.

42 3.2. Modifications apportées à D-Sight 42 Cas plus complexe : Dans certaines situations, le pointeur vers l élément à supprimer ne permet pas d avoir toutes les informations nécessaires en cas d undo. Cela arrive par exemple lorsque la Commande consiste à supprimer un élément. Dans ce cas, la liste des instructions permettant d annuler la commande reste vide jusqu à l exécution de celle-ci. Lors de l exécution, l objet Command a accès à l ensemble du modèle. Avant de lancer l exécution proprement dite, il remplit les instructions permettant d annuler la commande. Ce type de commande n est donc pas capable de s annuler jusqu à son exécution ce qui ne devrait pas poser de problème particulier : il n existe, à priori, aucune commande qui doive pouvoir être annulée avant d avoir été exécutée Implémentation du système de contrôleur Le chapitre précédent a exposé la façon dont a été modifié l objet Command pour s adapter aux aspects particuliers de D-Sight. Ce chapitre traitera de l objet Invoker et de l ensemble du contrôleur. Le design pattern de base requiert simplement de créer un objet Invoker qui aura pour rôle d exécuter la commande. Cette organisation est volontairement simple, voir simpliste, pour permettre une adaptation aisée du pattern aux différents cas particuliers rencontrés par les programmeurs. Pour D-Sight, un contrôleur complet a été créé autour de cet Invoker en conservant deux objectifs : Le contrôleur doit permettre une gestion de l historique ( undo et redo ). Le contrôleur doit être facilement accessible aux plugins. Un autre design pattern (encore un) est souvent mis en oeuvre lorsque de multiples traitements successifs peuvent être effectués à partir d une même requête 5 (dans ce cas, une commande) : il s agit du pattern Chain of Responsability. Ce pattern suggère de créer une super-classe abstraite Handler dont vont hériter l ensemble des classes qui souhaitent intervenir lors du traitement de la requête. Ces Handler vont former une chaîne (d où le nom du pattern) simplement liée : chaque Handler possède un pointeur vers l élément suivant de la chaîne. Lorsqu un Handler reçoit une requête à traiter, il effectue la gestion dont il est responsable et transmet ensuite la requête au Handler suivant qui fait de même, et ainsi de suite jusqu au dernier élément de la chaîne. Des méthodes sont créées au niveau du Handler pour permettre d ajouter et de retirer facilement des éléments dans la chaîne. Dans le cas de D-Sight, la requête à laquelle le pattern fait référence est bien évidemment l objet Command. La super-classe CommandHandler a donc été créée, par analogie au pattern. La chaîne de traitement de D-Sight se limite à deux Handler : Le CommandManager est conçu pour être le premier élément de la chaîne. Il est facilement accessible à l ensemble de l interface de D-Sight. C est lui qui gère le stack d historique. 5. L utilisation, dans ce contexte, du mot requête illustre bien que ce pattern peut facilement être mis en oeuvre dans le contexte d une application web où toutes les interactions de l utilisateur arrivent sous la forme de requêtes HTTP. Ce pattern est d ailleurs mis en oeuvre dans les framework Symfony et Ruby on Rails.

43 3.2. Modifications apportées à D-Sight 43 Le CommandExecuter est l implémentation de l Invoker. Il a un accès direct à la couche modèle de D-Sight et appelle la méthode execute() de l ensemble des Command qui arrivent jusqu à lui en passant en paramètre le lien vers le modèle. Il est donc conçu pour être le dernier élément de la chaîne puisqu il ne transmet pas la requête à un maillon suivant. Avoir ainsi utilisé un tel pattern pour seulement deux maillons peut sembler un peu lourd, mais ce système offre un gain de souplesse important pour les plugins, qui peuvent donc facilement faire du traitement personnalisé des commandes de l utilisateur ou directement créer leur propres commandes et les faire exécuter. En plus des perspectives que cela offre pour les plugins, le développement de D-Sight peut s en retrouver facilité : il serait par exemple relativement simple d implémenter les limitations de la version de démonstration de D-Sight dans un ou plusieurs Handler qui ne sont activés que si l utilisateur n a pas enregistré, et donc acheté, sa version : chaque commande de l utilisateur est analysée par ces Handler qui peuvent interrompre la chaîne et afficher un message si une opération limitée est détectée. Les différences entre la version commerciale et la version de démonstration sont donc isolées du reste de l application et sont donc plus facilement maîtrisables et maintenables. Au final, le bilan qui peut être fait de ces implémentations est globalement positif. Parmi les éléments négatifs, on notera principalement la légère perte de performances : la mise en place de ce système de commande reste plus lourd que le simple envoi de messages directs. Notons tout de même que cette perte de performances ne s est pas traduite dans les faits par une impression de lourdeur accrue pour l utilisateur. Parmi les éléments positifs, on retiendra principalement l ajout de la gestion de l historique qui était une fonctionnalité attendue, ainsi que la mise en place d un vrai contrôleur centralisé et extensible qui bénéficiera à la fois aux plugins et aux développements de D-Sight. Le tableau suivant résume les avantages et les inconvénients du nouveau système : Inconvénients L implémentation d une nouvelle commande est plus complexe Exécution plus lourde Avantages Souplesse du développement accrue Utilisation du pattern Command Permet aux plugins d agir sur les commandes Permet l implémentation de la gestion de l historique Après avoir décrit les modifications apportées à D-Sight pour implémenter ce pattern, ce rapport va maintenant montrer comment utiliser cette nouvelle organisation dans l optique de l échange de messages avec le serveur. L objectif est de décrire ici : comment transformer un objet Command en un flux de données, et comment transformer un flux de données en une commande utilisable. L idée initiale dans ce genre de situation est d utiliser les capacités de serialization (également appelé marshalling) du langage Java. Celui-ci fournit en standard des méthodes qui permettent de transformer certains objets en suite de bits (appelé blob binaire) qu il est alors possible d écrire dans un fichier ou de faire transiter par le réseau. L opération inverse,

44 3.2. Modifications apportées à D-Sight 44 la déserialization (ou unmarshalling) est également prise en charge directement par le langage. Ces opérations automatiques de marshalling / unmarshalling sont particulièrement pratiques dans le cadre des problématiques de persistance des données (sauvegarde dans un fichier ou une BDD), mais dans le cadre de ce travail elles présentaient un désavantage majeur. En effet, elles induisent une forte relation de dépendance entre les technologies du serveur et celles des clients. Pour que l opération de désérialization d un objet sérialisé se passe correctement, il est nécessaire que le récepteur du blob binaire dispose de la même classe, dans la même version que l élément qui l a produit. Si ces deux conditions ne sont pas réunies, l opération lève une exception et il n y a pas de réel moyen pour le programmeur de récupérer les données, puisqu il n a pas de moyen d agir sur l opération de sérialization / désérialization. L aspect automatique de ces fonctionnalités montre ici ses limites, le gain en terme de rapidité de développement est compensé par une perte en terme de souplesse. Choisir d utiliser la sérialization automatique de Java possède donc deux conséquences importantes. D une part, les clients qui sont mis en relation doivent utiliser la même version de D-Sight (ou en tout cas, il ne peut y avoir eu de modification des objets Command). Et d autre part, pour pouvoir inspecter le contenu des échanges entre les clients, et ainsi réaliser le lien avec la plateforme, le serveur doit être programmé en Java et avoir accès à ces classes. Il doit lui même réaliser une opération de désérialization du blob binaire avant de pouvoir lire les données. On oblige donc la création d un écosystème D-Sight / serveur dont les composants doivent avoir un numéro de version synchronisé et dont les échanges sont fermés dans le sens où les outils capables de traiter les messages sont limités. Durant le stage précédent ce mémoire, les avantages que procurait le fait de travailler avec des outils produisant des messages dans des formats standardisés et ouverts ont été fort appréciés : certains projets n auraient pas pu être possibles ou auraient demandé un temps de travail rédhibitoire si cela n avait pas été le cas. De la même façon, l adoption de standards ouverts et interopérables est un des éléments fondateurs de la croissance du web de part la souplesse que cela offre 6. Le mémorant est donc conscient des conséquences que pourraient avoir l adoption de systèmes fermés qui limitent artificiellement les technologies utilisables et les outils que l on peut mettre en oeuvre. Le mécanisme de serialization fournit par Java n a donc pas été privilégié, et a été remplacé par un export des objets Command au format XML. Ce format offre l avantage d être utilisable par de nombreux langages et d être compatible avec un maximum d outils. Le code réalisant la sérialization d un objet Command en XML peut être implémenté à deux endroits : soit directement au niveau de l objet Command lui-même, soit intégré dans le plugin de travail collaboratif. La première approche considère que la sérialization est une capacité propre des objets Command et qu elle doit donc être accessible au reste de D-Sight et à tous les plugins. La second approche sous-entend que cette sérialization est 6. Cet avis est partagé par certains grand acteur du web. Par exemple, Tristan Nitot, président de la Fondation Mozilla[16]

45 3.2. Modifications apportées à D-Sight 45 une fonctionnalité propre au cadre travail collaboratif et qu il est inutile d encombrer D-Sight avec ce code. La première approche a été privilégiée pour trois raisons : 1. En programmation orientée objet, un des aspects clef d une bonne organisation du code est de confier la responsabilité d une tâche à l objet disposant le plus facilement de l ensemble des informations nécessaires pour remplir cette tâche 7. Or, dans le cadre de la sérialization des objets Command, c est très clairement l objet lui-même qui dispose le plus facilement des informations le concernant, et non une classe dédiée externalisée dans un plugin. 2. La réalisation d un plugin permettant une gestion avancée de l historique et permettant d enregistrer celui-ci lors de la sauvegarde d un fichier D-Sight est dans les plans de Decision-Sights. Dans ce cadre, avoir un système de gestion de la persistance des commandes, est indispensable. Puisque ce travail devait être réalisé pour le projet, il semblait utile de rendre cette fonctionnalité disponible au cas ou cette idée se concrétise. 3. Certains plugins nécessiteront peut-être ajouter des commandes à D-Sight. Si le code de serialization des commandes est externalisé dans le plugin collaboratif, ces commandes ne seront pas serializables sans modification de ce plugin. A l inverse, si le code est placé directement dans la commande elle-même, aucune modification n est nécessaire. Chaque commande peut donc être exportée au format XML en appelant directement la méthode toxml(). Les commandes fournissent également un constructeur donc l unique argument est un string XML pour permettre la désérialization. L opération est transparente pour le programme qui appelle donc : Pour la sérialization : String XMLString = mycommand. toxml (); Pour la désérialization : Command mycommand = CommandFactory. fromxml ( XMLString ); Puisque toute commande peut être transformée en message exportable sur le réseau et qu un message issu du réseau peut être converti commande exécutable par D-Sight, il faut trouver un moyen simple qui permet : d intercepter les commandes de l utilisateur pour les transmettre au réseau. d avoir accès facilement à l Invoker pour transmettre les commandes issues du serveur. Notons également que ce code est réellement propre au projet de travail collaboratif et doit donc être placé dans un plugin. 7. Il s agit du pattern Information Expert décrit dans : [13]

46 3.2. Modifications apportées à D-Sight 46 La souplesse du système de contrôleur permet d intégrer, au démarrage du plugin, un CollaborativeWorkCommandHandler entre le CommandManager (qui gère l historique) et le CommandExecuter (qui joue le rôle d Invoker). Ce nouveau CommandHandler est lié à un objet ServerConnection capable d échanger des messages avec le serveur via un socket créé au démarrage du plugin en utilisant le protocole décrit au point suivant. Lorsque le CollaborativeWorkCommandHandler reçoit un message issu de l utilisateur, il le convertit en XML et charge l objet ServerConnection de transmettre l information au serveur. Lorsque l objet ServerConnection reçoit un message du serveur, il le transmet au CollaborativeWorkCommandHandler qui réalise l opération de désérialization et qui transmet le message au CommandExecuter. La Figure 3.5 montre les inter-connexions entre ces objets. Figure 3.5: Relation entre les éléments formant le contrôleur dans le cadre du travail collaboratif On aura noté que, vu l ordre dans lequel sont placés les CommandHandler, l ensemble des commandes issues du serveur ne sont pas prises en compte dans l historique de l utilisateur. Ceci est volontaire afin d éviter toute confusion pour l utilisateur : son historique gère seulement ses opérations à lui et non celles de ses collaborateurs. Ainsi, il ne risque pas d annuler par erreur une modification apportée par quelqu un d autre en appuyant sur le bouton undo. Si cela s avère nécessaire, il est possible de tenir compte de toutes les commandes en introduisant de la logique entre le CollaborativeWorkCommandHandler et le CommandHandler.

47 3.3. Protocole de communication Protocole de communication Pour que le plugin collaboratif et le serveur puissent s échanger des messages, il est nécessaire qu ils respectent le même protocole. Celui-ci définit l ensemble des règles à respecter pour pouvoir envoyer des informations. Il doit être suffisamment souple pour permettre aux informations utiles de transiter, il doit éventuellement garantir que les données soient arrivées à destination, et il faut éviter qu il n introduise trop d overhead par rapport aux données utiles afin de ne pas congestionner le réseau. Comme indiqué à la Section 2.5, le fait d utiliser un socket TCP évite la majorité des problèmes lié à HTTP 8, le protocole peut donc se permettre d être particulièrement léger. L unité d échange entre le plugin et le serveur est définie comme étant un Message qui lui-même est constitué : D un nombre entier appelé Header D un blob binaire appelé Body Dans le cas (fréquent) ou le blob binaire du Body représente un String (par exemple une commande exportée au format XML), ce String est encodé au format UTF-8. Le Header a pour rôle de décrire l objet représenté dans le Body : lorsqu un message est reçu, une simple analyse du Header permet de déterminer les opérations à effectuer avec le Body. Dans la suite de ce rapport, l ensemble des messages échangés entre le client et le serveur seront décrits au moment opportun. Dans le cadre de ce chapitre, deux messages sont nécessaires : Effectuer une commande vers le haut (do) : Header : 10, Body : séralization XML de la commande Effectuer une commande vers le bas (undo) : Header : 11, Body : séralization XML de la commande Lorsque le serveur reçoit un message issu d un plugin avec un de ces deux Header, il le transmet simplement à l ensemble des autres clients auxquels il est connecté et qui travaillent sur le même projet (ce point spécifique sera abordé plus loin). Lorsqu un client reçoit un message avec un de ces header, il sait qu il peut extraire un String au format UTF-8 à partir du Body et qu il doit le convertir en objet Command à exécuter (do ou undo). Pour envoyer ces informations, le plugin envoie successivement : L entier correspondant au Header, codé sur 4 octets (la taille standard d un int en java). Un entier correspondant à la taille du Body, en octet (codé également sur 4 octets). Un ensemble d octets correspondant au Body. Notons que cette méthode limite la taille du Body à octets (le plus gros chiffre codable sur 4 octets). Cette limitation correspond à un contenu d une taille maximum de 2 Go (Giga-octets). Dans le cadre de ce projet, cette taille maximum est très largement suffisante. 8. Pour rappel, les deux problèmes majeurs sont : le fait d être stateless et donc que chaque requête est indépendante. Et le fait que le serveur ne peut pas prendre l initiative de contacter le client

48 3.3. Protocole de communication Comparaison avec SOAP Dans le domaine de la transmission de messages sur un réseau, une technologie souvent présentée est la technologie SOAP (Simple Object Access Protocol). Elle permet l échange de messages entre deux entités utilisant éventuellement des langages de programmation différents grâce à l utilisation d un format XML standardisé [21]. Le principe est donc relativement proche du design implémenté. SOAP n a cependant pas été privilégié au profit d une solution customisée pour deux raisons : 1. Dans son principe, SOAP repose sur une transmission des messages par un canal mono-directionnel, comme le HTTP. Les librairies SOAP séparent donc clairement la partie client (qui établit la connexion et qui envoie le premier message) de la partie serveur (qui reçoit un message du client, le traite et renvoie une réponse). Dans le cas de D-Sight, chacune des entités peut initier des envois de messages puisque le canal est bidirectionnel. La séparation entre les deux rôles n a donc pas de sens. 2. L overhead inclus dans les messages XML SOAP est bien plus important que l overhead inclus dans les messages XML produits par D-Sight. L efficacité de la connexion (nombre de bits transmis par rapport au nombre de bits utiles) est donc diminuée. Dans la mesure ou SOAP n apporte en lui-même aucune fonctionnalité utile pour ce projet et qu il présente les inconvénients présentés, il n a pas été utilisé. Cependant, si l utilisation de SOAP devait devenir nécessaire pour intégrer D-Sight dans un workflow utilisant cette spécification (ce qui n est pas le cas à l heure actuelle), les modifications nécessaires ne seraient pas trop contraignantes car elles resteraient limitées à l adaptation des classes créant les messages du coté plugin et du coté serveur. Le tableau suivant résume la comparaison entre SOAP et le protocole mis au point dans le cadre du mémoire : SOAP Standardisé Orienté Client-Serveur Overhead important Protocle implémenté Solution propre Architecture libre Overhead faible

49 3.4. Organisation du serveur Organisation du serveur Le chapitre précédent présentait les aménagements apportés à D-Sight pour permettre le travail collaboratif, celui-ci décrira l organisation du code du serveur. Cette présentation sera précisée et complétée dans la suite du rapport. A cette étape du projet, il est nécessaire de faire l hypothèse que l ensemble des clients se connectant au serveur travaillent sur le même projet et sont synchronisés (leurs modèles sont totalement identiques) au moment de leur connexion. Donc, tant que l ensemble des commandes réalisées par un client est transmis à ses collaborateurs, le projet reste synchronisé, et les utilisateurs travaillent de façon collaborative. L architecture présentée ici n est donc pas l architecture finale du serveur, mais représente la première étape de sa réalisation. Lorsqu elle a été conçue, elle avait pour objectif principal de permettre l ajout facile des futurs composants qui gèreront, par exemple, les problématiques d authentification, ou les échanges de messages avec la plateforme Ruby on Rails. Ceci passe, comme souvent en POO, par une définition claire des rôles et des responsabilités de chaque classe. On distingue les éléments suivants : La classe Message : représente un message (envoyé ou reçu) qui transite entre le serveur et un client. Elle contient, par exemple, des accesseurs et des mutateurs aux attributs Body et Header (cf 3.3) La classe ClientConnection : gère les communications avec un seul client. Elle encapsule un socket, se met à l écoute de celui-ci et transforme en Message, tout flux de bits qui lui arrive. Les messages ainsi créés sont transmis à un MessageReceiver. Elle offre également la fonction : void sendmessage(message); L interface MessageReceiver : doit être implémentée par toute classe souhaitant pouvoir analyser ou traiter un message reçu par un objet de type ClientConnection. La classe SessionManager : gère l ensemble des objets ClientConnection liés à des clients qui travaillent sur le même projet. Sous l hypothèse énoncée en début de section, il n y a pour l instant pas lieu d envisager la création de plusieurs Session- Manager. Cette classe réalise l interface MessageReceiver. Le diagramme des classes de la Figure 3.6 illustre les relations entre ces éléments. Il semble utile de décrire successivement le processus de démarrage du serveur, la connexion d un client et la transmission d une commande afin d offrir un aperçu des événements intervenant dans le processus de mise en route du serveur : Lors du démarrage, un objet SessionManager est créé, ainsi qu un socket en attente d une connexion. Lorsqu un client se connecte, un objet ClientConnection est créé. Il reçoit le socket en paramètre et il est ajouté dans le pool des clients gérés par le SessionManager. L écoute des messages du socket par le ClientConnection démarre dans un nouveau thread. Le serveur recrée un nouveau socket en attente de connexion. Lorsque le ClientConnection reçoit un message, celui-ci est transmis au Session- Manager. Celui-ci transmet une copie de ce message (Header et Body identiques) à tous les autres clients de son pool.

50 3.4. Organisation du serveur 50 Figure 3.6: Représentation du serveur en diagramme UML des classes A ce niveau, le rôle du serveur se limite donc à répéter à l ensemble des clients de son pool les commandes qu il reçoit. L architecture générale du code permet néanmoins déjà d identifier les endroits où seront gérées les informations relatives à un client unique (authentification) ou propre à un projet (synchronisation).

51 3.5. Mécanismes de sécurité Mécanismes de sécurité Pour terminer avec cette première partie du travail, il est nécessaire d évoquer les risques de sécurité inhérents au fait de faire transiter des données via internet. Telle que présentée, l architecture du système présente deux failles majeures : 1. Il est possible d ouvrir une fausse connexion vers le serveur et de lui envoyer des données qui seront propagées aux autres clients connectés. Cette même connexion permet d avoir accès à l ensemble des commandes exécutées par les autres clients. 2. Si un attaquant parvient à mettre sur écoute le réseau d un intervenant, il peut avoir accès à l ensemble des messages échangés entre le client et le serveur et ainsi avoir accès à des données de l entreprise. La première faille ne sera pas traitée dans ce chapitre dans la mesure où les mécanismes d authentification qui seront mis en place empêcheront d ouvrir des connexions et d avoir accès à des données sans en avoir la permission. Dans un cadre commercial, il est par contre essentiel de fournir aux entreprises la garantie que leurs données restent confidentielles, même durant un transit sur internet. Assurer la confidentialité d échanges sur un réseau non-sécurisé (tel qu internet) est une problématique rencontrée régulièrement dans le monde informatique. Diverses solutions existent, la plus connue et la plus utilisée étant sans doute le cryptage des données par TLS/SSL 9. Cette solution s est imposée comme standard sur le web où elle sert, par exemple, à garantir la confidentialité des payements en ligne. SSL a été choisi pour trois raisons majeures : 1. Créer un système de sécurité personnalisé était proscrit à la fois en raison du temps de développement que cela demanderait et du peu de sécurité que cela aurait apporté SSL est utilisé pour protéger une importante quantité de données particulièrement sensibles. Des recherches intensives sont donc menées pour tenter de casser l algorithme, sans réel succès. Ce qui tend à prouver que SSL reste un moyen sûr pour protéger ses données. 3. Le taux de pénétration de SSL fait qu il est possible de trouver des librairies facilitant son utilisation pour presque tous les langages. 9. SSL a servi de base de travail à la création de TLS. SSL et TLS désignent maintenant le même algorithme : seul le numéro de version change (ex : TLS 1.0 = SSL 3.0 ). 10. L immense majorité des experts en cryptanalyse déconseille de créer ses propres algorithmes en espérant que leur aspect unique les rende plus difficile à casser [14].

52 3.5. Mécanismes de sécurité 52 SSL permet de garantir à la fois l authentification du serveur (via un mécanisme de certificats échangés lors de la connexion) et la confidentialité des messages (via un cryptage des données par clef publique). La mise en place d une connexion SSL se déroule comme suit[10] : Le client se connecte au serveur. Le serveur transmet au client un certificat contenant entre autres la clef publique qui permet au client de chiffrer les données qu il envoie au serveur ainsi qu une signature. Le client vérifie la signature. Si celle-ci est valide, le serveur est authentifié, et le client lui transmet la clef publique qui permet de chiffrer les données qui vont du serveur vers le client. La connexion s effectue de manière confidentielle puisque les données sont chiffrées en utilisant les clefs publiques des intervenants. La vérification de la signature par le client s appuie sur le recours à un Trusted CA (Trusted Certification Authority). Il s agit d une autorité à laquelle le client fait confiance pour émettre des signatures. Le gérant du serveur s adresse donc à cette autorité afin d obtenir la signature pour son certificat. Après avoir vérifié que le demandeur était bien la personne légitimement responsable de la gestion du serveur, l autorité chiffre un hashé du certificat à l aide de la clef privée, ce qui produit la signature de ce certificat. Pour vérifier cette signature, le client devra déchiffrer la signature à l aide de la clef publique de l autorité et confirmer que le résultat obtenu correspond bien au hashé du certificat. L obtention d une signature SSL par une des grandes autorités de certification étant une opération relativement onéreuse 11, une solution de remplacement a été utilisée. Pour le projet, une nouvelle autorité de certification a été spécialement créée (le certificat est donc auto-signé). Le plugin contourne la vérification de la signature et accepte donc tout certificat. Au niveau de la sécurité, les conséquences sont les suivantes : L aspect authentification fourni par SSL est perdu : un attaquant peut donc potentiellement modifier le fichier host d un client et rediriger les données vers un faux serveur collaboratif malicieux émettant son propre certificat au-signé. Une fois la correspondance établie avec un serveur (malicieux ou légitime), la confidentialité des échanges est garantie. Dans un cadre de production, il sera bien entendu nécessaire d acheter ce certificat et donc de modifier légèrement le plugin pour lui introduire la clef publique de l autorité de certification choisie. Cet aspect sera abordé dans la troisième partie de ce rapport. 11. Verisign, le trusted CA leader sur le marché propose des certificats SSL oscillant entre 399$ et 1499$ par an

53 CHAPITRE 4 Communication entre le serveur collaboratif et la plateforme Le chapitre précédent a traité des modifications apportées à D-Sight et des messages échangés entre le plugin et le serveur collaboratif. Ce chapitre traitera des échanges prenant place entre le serveur collaboratif d une part, et la plateforme Ruby on Rails d autre part. Ce chapitre présentera successivement : Les modifications apportées au serveur collaboratif pour permettre ces échanges. Les modifications apportées à la plateforme. La gestion de la problématique d authentification. La prise en compte de la sécurité de la plateforme. Comme indiqué précédemment, la plateforme Ruby on Rails repose sur le protocole HTTP et l architecture REST. La connexion entre le serveur collaboratif et la plateforme suit donc un modèle client-serveur : la connexion est mono-directionnelle. Le serveur collaboratif va agir en tant que client de la plateforme et la contacter afin de lui présenter des requêtes au format HTTP, et la plateforme va renvoyer une réponse à ces requêtes (toujours au format HTTP) avant de fermer la connexion.

54 Communication entre le serveur collaboratif et la plateforme 54 Dans le cadre de ce chapitre, nous ferons l hypothèse que les utilisateurs de D-Sight sont en train de travailler sur un projet qu ils ont déjà téléchargé. Le serveur collaboratif est donc en possession, pour chaque utilisateur, des éléments suivants : Le login de l utilisateur, entré durant la procédure de chargement et qui correspond à son identifiant sur la plateforme. Son mot de passe. L identifiant du projet sur lequel il travaille et qui correspond à un numéro unique attribué par la plateforme à chaque projet qu elle gère. Les échanges de messages prenant part entre les clients D-Sight, le serveur collaboratif et la plateforme pour arriver à cette situation feront l objet du chapitre suivant de ce rapport. Ce chapitre-ci à donc pour rôle de présenter comment les commandes arrivant au serveur collaboratif sous forme de string XML inclus dans un message formaté avec le protocole propriétaire présenté à la Section 3.3 peuvent être transmises à la plateforme Ruby on Rails à l aide de messages HTTP afin que celle-ci puisse effectuer les modifications nécessaires sur la base de données.

55 4.1. Modifications du serveur collaboratif Modifications du serveur collaboratif Situation initiale Au chapitre précédent, à la Section 3.4, il a été établi que chaque client D-Sight est géré dans le serveur collaboratif par un objet de classe ClientConnection et que l ensemble de ces ClientConnection travaillant sur le même projet sont liées entre elles par un objet de type SessionManager. Ce SessionManager reçoit l ensemble des messages provenant de chaque instance de D-Sight et avait pour unique rôle de forwarder sans modification ce message à l ensemble des clients travaillant sur le même projet. Comme indiqué précédemment, il est ici supposé que l étape de chargement s est déroulée correctement et donc que : Chaque ClientConnection possède en mémoire le login et le mot de passe de l utilisateur auquel il est rattaché et que ces identifiants sont valides. Chaque SessionManager possède en mémoire l identifiant du projet qu il gère. Figure 4.1: Représentation de l organisation du serveur. Les trois instances de D-Sight travaillent sur le même projet Modifications et ajouts Pour permettre la transformation des messages issu du protcole propriétaire présenté à la Section 3.3 en requêtes HTTP et la communication avec le serveur, deux classes ont été ajoutées : PlatformLinker et PlatformConnection.

56 4.1. Modifications du serveur collaboratif La classe PlatformConnection Chaque objet de cette classe reçoit en paramètre de son constructeur l IP et le port d une instance de la plateforme à laquelle il doit se connecter. Son interface est composée d une unique fonction : public String sendrequest ( String username, String password, String method, String relurl, String data ); Cette fonction prend en paramètre l ensemble des informations requise pour créer une requête HTTP : username : le login de l utilisateur qui effectue la requête. password : son mot de passe. method : la méthode HTTP utilisée (GET, POST, PUT, DELETE). relurl : l url de la ressource concernée. data : Si nécessaire (par exemple en cas de requête PUT ou POST), un String XML décrivant les paramètres de la requête. A partir de ces informations, la méthode crée une requête HTTP destinée à la plateforme et l envoie sur l IP et le port indiqué dans son constructeur. Si la plateforme retourne une réponse de type 200 (OK), qui signifie que tout s est déroulé normalement, le contenu de la réponse de la plateforme est retourné sous forme de String. Les particularités de la requête forgée par cette fonction feront l objet des Sections 4.3 et 4.4. Une seule instance de cette classe est créé lors de l initialisation du serveur. Il aurait donc été possible d utiliser le design pattern Singleton 1 pour éviter de passer des références à cette classe un peu partout dans l application, mais la souplesse garantie par le système d injection de dépendance 2 permet de garantir une modification plus facile de la relation entre le serveur collaboratif et la plateforme si cela s avère nécessaire La classe PlatformLinker Cette classe est celle qui est capable de comprendre et d analyser les messages envoyés par D-Sight et de déterminer quelle est la requête correspondante qui doit être effectuée sur la plateforme. Son interface est constituée d une seule fonction qui prend en entrée, un message à analyser, le nom d utilisateur de l émetteur et son mot de passe, ainsi que l identifiant du projet concerné. 1. Ce design pattern décrit comment créer une classe conçu pour n avoir qu une seule instance 2. L injection de dépendance est une technique permettant de créer des objets qui reçoivent lors de leur intialisation les liens vers les éléments dont ils dépendant [11].

57 4.1. Modifications du serveur collaboratif 57 Listing 4.1: Signature de la fonction treatmessage() qui analyse les massages reçu par le serveur collaboratif public void treatmessage ( String userlogin, String userpassword, String projectid, Message message ); Elle se charge d analyser le message reçu et d appeler la fonction sendrequest() de l instance de la classe PlatformConnection qu elle a reçu en paramètre dans son constructeur. Il s agit d une méthode assez longue et peu factorisable qui doit connaître la traduction de chaque instruction D-Sight en requête HTTP. Pour réaliser cette tâche, elle crée une liste d instructions à partir du corps du message (qui est un String XML, si le message correspond à une commande cf Section 3.3). Elle boucle ensuite sur cette liste et, pour chaque instruction, en récupère le nom. Ce nom est ensuite comparé à l ensemble des instructions connues par le PlateformLinker. En cas de match, les paramètres utiles sont extraits, et la fonction sendrequest() est appelée avec les bons paramètres. Listing 4.2: Extrait de la fonction treatmessage... else if ( instructionname. equals (" Action / ChangeName ")) { String xml = " <? xml version = 1.0 encoding = UTF -8? >" + " <alternative >" + "<name >" + instruction. getchildtext (" newname ") + " </name >" + " </ alternative >"; connexion. sendrequest ( userlogin, userpassword, " PUT ", "/ projects /"+ projectid +"/ alternatives /"+ instruction. getchildtext (" uuid ")+". xml ", xml ); } Situation finale Architecture du serveur La Figure 4.1 représentant l organisation du serveur collaboratif avant la prise en compte de la connexion avec la plateforme peut donc être complétée avec l ajout des classes PlatformLinker et PlatformConnection

58 4.1. Modifications du serveur collaboratif 58 Figure 4.2: Représentation de l organisation du serveur après ajout des classes permettant la relation avec la plateforme Suivi d un message Pour terminer avec l organisation du serveur collaboratif, il semble utile de décrire clairement l ensemble des étapes intervenant dans le traitement d un message arrivant au serveur collaboratif. Dans la mesure ou ce traitement est un des aspects majeurs du travail, il est nécessaire de préciser son fonctionnement. Le diagramme UML de séquence est donc accompagné d un texte explicatif afin de clarifier au maximum toute ambiguïté. Figure 4.3: Diagramme UML de séquence du traitement d un message arrivant au serveur collaboratif. 1. Le plugin collaboratif du client D-Sight transforme la commande en flux XML (Section 3.2.3) et le transmet au serveur collaboratif en utilisant le protocole propriétaire décrit à la Section 3.3

59 4.1. Modifications du serveur collaboratif Coté serveur, chaque client D-Sight est relié à un objet de type ClientConnection (Section 3.4) qui reçoit donc les messages et qui connaît les login et mot de passe de l utilisateur auquel il est relié. Les commandes sont transmises au SessionManager qui connaît l identifiant du projet sur lequel travaillent les clients qu il relie. 3. Le SessionManager transmet une copie du message à tous les autres clients auxquels il est relié, ce qui permet donc le travail collaboratif entre clients D-Sight comme expliqué à la section 3.4. En plus de cela, le message est transmis au PlatformLinker, en spécifiant les login et mot de passe du client à l origine du message ainsi que l identifiant du projet concerné. 4. Le PlatformLinker analyse le message et, pour chaque instruction qui le nécessite, contacte la PlatformConnection pour lui demander d effectuer une requête HTTP à la plateforme avec les paramètres qu elle déduit de la commande. 5. Le PlatformConnection effectue la requête HTTP vers la plateforme 6. La plateforme reçoit une requête HTTP et modifie la base de données en conséquence. En définitive, pour chaque commande, l ensemble des clients travaillant sur le projet sont notifiés et la base de données de la plateforme est modifiée pour prendre en compte les changements induits par chaque commande. Notons que dans certains cas, une commande peut contenir plusieurs instructions (cf Section ) et nécessite donc plusieurs requêtes HTTP pour être totalement transmise à la plateforme.

60 4.2. Modification apportées à la plateforme Modification apportées à la plateforme Si les modifications apportées à D-Sight pour permettre le travail collaboratif ont été nombreuses et relativement profondes, il n en sera pas de même concernant la plateforme qui ne subira que quelques changements mineurs. Deux raisons expliquent ceci : 1. Toute la mise en place du pattern Command au sein de D-Sight et son utilisation a pour objectif de donner un moyen efficace de transmettre une action via un flux transportable sur le réseau. Or il s agit de la base même du fonctionnement d un application web, qui utilise le protocole HTTP pour transmettre des requêtes. 2. Comme indiqué à la Section 2.5, l objectif n est pas de réécrire une couche de logique autour de la base de données, mais bien de réutiliser les éléments mis en place au sein de la plateforme et déjà utilisés par les clients web. Dans le cadre de la transmission de la traduction d une instruction D-Sight en requête HTTP, un problème peut se présenter lorsque : Les informations contenues dans la commande D-Sight ne permettent pas de concevoir une requête équivalente exécutable par la plateforme. Deux raisons peuvent mener à une telle situation : 1. La logique gérant cette requête n est pas présente sur la plateforme. Soit parce que cela ne s avère pas nécessaire, soit parce que la plateforme est en développement et que la fonctionnalité n est pas encore implémentée. 2. La fonctionnalité existe, mais la traduction du message D-Sight en requête HTTP valide est impossible Problème de la fonctionnalité inexistante Avant d entamer cette section, il semble utile de rappeler au lecteur que les requêtes HTTP qui arrivent à la plateforme représentent chacune la traduction d une instruction, qui est elle même une opération élémentaire sur D-Sight. On peut séparer les instructions en trois types : 1. Les instructions de création de ressource. 2. Les instructions de suppression de ressource. 3. Les instructions de modification de ressource. Dans ce dernier cas, la modification ne touche qu un seul attribut de la ressource à la fois. Il ne s agit donc pas ici de vérifier que les commandes de D-Sight possèdent un équivalent sur la plateforme, puisque chaque commande complexe est déjà subdivisée en une suite d instructions plus simples. Notons également que les trois types de commandes correspondent chacune à une des quatre opérations de base 3 pour la persistance 3. Opérations CRUD : Create Read Update Delete

61 4.2. Modification apportées à la plateforme 61 des données. Comme indiqué à la Section 2.2, le framework Ruby on Rails sur lequel est bâti la plateforme encourage l utilisation intelligente de l architecture REST en proposant de façon standard un contrôleur offrant ces quatre opérations élémentaires. En d autres termes, sans travail supplémentaire du programmeur, les opérations élémentaires de création, récupération, suppression, modification des données sont fournies par le framework et optimisées. Tant que l accès à ces contrôleurs basiques est possible, la problématique de la fonctionnalité inexistante ne se pose donc pas réellement. Il semble essentiel de souligner l importance capitale que l architecture REST de la plateforme a pu avoir dans le déroulement de ce projet en offrant : L assurance que les opérations de base étaient implémentées de manière correcte pour chaque ressource. Une interface standardisée et connue pour accéder à ces fonctions Problème de la traduction impossible Ce problème se pose si les informations contenues dans le message transmis ne sont pas suffisantes. Comme exposé à la Section , chaque instruction est conçue pour contenir l ensemble des informations nécessaires à son exécution. Le fait que D-Sight repose sur l exécution de ces instructions et que le travail collaboratif fonctionne sans problèmes apparents est une preuve qu à priori les données contenues dans les instructions sont suffisantes. En pratique, une difficulté se présente dans le cadre de l identification des ressources. Par défaut, Ruby on Rails attribue à chaque ressource un identifiant unique sous la forme d un nombre s incrémentant automatiquement à chaque nouvelle ressource créée. Cette attribution automatique d identifiant numérique unique à chaque ressource n est pas une surprise dans la mesure où il s agit d une mesure standard et d une règle de bonne pratique dans le cadre de la conception de base de données. Cependant, dans D- Sight, la problématique de l identification des ressources a été gérée grâce à l UUID (cf Section 3.1.1) qui peut facilement être stockée dans une base de données, mais sous la forme d un string et non d un nombre. Cette facilité avait d ailleurs été un des critères du choix des UUID comme moyen d identification. La solution a donc consisté à modifier le modèle de la plateforme de façon à forcer Ruby on Rails à utiliser des UUID à la place de ses identifiants numériques. Cette opération a nécessité trois étapes : 1. Changer le type de l ID en String. Il a également fallu modifier le type des clefs étrangères de façon à refléter cette mise à jour. 2. Importer la bibliothèque ruby permettant la gestion des UUID. 3. Modifier les contrôleurs qui gèrent la création des ressources de façon à ce qu ils génèrent une nouvelle UUID à chaque ressource si celle-ci est créée via l interface web.

62 4.3. Problématique d authentification Problématique d authentification Description du problème Comme indiqué à la Section 2.3, le protocole HTTP qui encadre les requêtes traitées par la plateforme est un protocole stateless. Ceci signifie que toute requête arrivant à la plateforme est indépendante des requêtes passées (ou futures) qui sont arrivées (ou arriveront) à la plateforme. HTTP ne prévoit donc, par défaut, pas de mécanisme pour permettre à une requête en particulier de fournir les informations suivantes : La requête yyy fait suite à la requête zzz. Avant d effectuer le traitement de la requête yyy, il faut attendre une autre requête. Si le programmeur ressent le besoin de garder une trace de la suite des requêtes de l utilisateur sur son application afin de modifier le traitement de certaines requêtes, c est à lui de trouver un moyen de réaliser ce traçage. Le cas le plus fréquent d une telle nécessité est l authentification des visiteurs. L exemple suivant montre bien que cette problématique est présente et traitée avec succès sur de nombreux sites internet : Un utilisateur se connecte sur le site de son entreprise, veut accéder à la liste des clients mais se voit refuser l accès. Il va alors sur la page d authentification, entre son login et son mot de passe, puis retourne sur la page qu il voulait voire et accède au contenu souhaité Requête Réponse 1 Afficher la page protégée liste clients Erreur : droits insuffisants 2 Afficher la page formulaire d authentification OK : envoi de la page 3 Envoyer son login et son mot de passe OK : authentification réussie 4 Afficher la page protégée liste clients OK : envoi de la page Table 4.1: Suite des requêtes et des réponses impliquées dans la visite d une page protégée Le lecteur aura noté que les requêtes numéro 1 et numéro 4 sont exactement similaires. Mais la réponse du serveur diffère car la requête 4 a été précédée d une requête d authentification qui a été réussie. Grâce à la requête 3, l utilisateur a modifié son état au sein de l application afin d acquérir des droits supplémentaires. Le programmeur de ce site internet a donc trouvé un moyen de contourner l aspect stateless du protocole HTTP afin de permettre l authentification.

63 4.3. Problématique d authentification Alternatives et solution retenue Identification par IP L application garde en mémoire une hashtable 4 dont les clefs sont des adresses IP et les valeurs des structures contenant l ensemble des paramètres du visiteur. Lors d une nouvelle visite (IP non contenue dans la hashtable), le visiteur reçoit une structure de données vide de toute information. Lorsqu il entre un login et un mot de passe, sa structure de données est modifiée pour refléter les autorisations et propriétés du compte qu il possède. Enfin, à chaque requête, le système vérifie si les droits nécessaires sont bien contenus dans la structure de données du visiteur et traite la requête en lui attribuant la paternité des modifications apportées à la base de données. La limitation principale de ce système est que l ensemble des ordinateurs se connectant au site avec la même IP recevront les mêmes droits, ce qui peut poser des problèmes de sécurité si plusieurs machines se trouvent derrière le même NAT 5. Dans le cadre du serveur collaboratif, ce système semble peu optimisé : en effet, du point de vue de la plateforme, toutes les requêtes issues du serveur collaboratif proviennent du même utilisateur (puisque provenant de la même IP). Or la plateforme représente en toute généralité plusieurs comptes auprès de la plateforme. Pour éviter d attribuer une requête au mauvais utilisateur, il faudrait donc automatiquement faire précéder chaque requête utile d une requête d authentification ce qui augmenterait sensiblement la charge sur la plateforme et laisserait la porte ouverte à de possibles problèmes de condition de course Identification par cookie L identification par cookie est similaire à l identification par IP dans la mesure où elle se base également sur l utilisation d une hastable dont les valeurs sont des structures contenant les paramètres du visiteur. La différence réside dans le fait que la clef de la hashtable n est plus l adresse IP du visiteur, mais une valeur spécifique présente dans l entête HTTP de la requête. Cette valeur est attribuée par le serveur qui demande au navigateur du visiteur de la placer dans l entête de chacune de ses requêtes. Ce mécanisme est connu sous le nom de Cookie [8]. Un cookie est donc une valeur placée dans l entête d un requête HTTP suite à la demande du serveur. Pour envoyer un cookie, le serveur produit une réponse dont l entête contient l instruction Set-Cookie. 4. Une hashtable est une structure de données optimisée pour permettre de retrouver rapidement une donnée nommée valeur à partir d une autre donnée nommée clef 5. Le NAT (Network Adress Translation) est un système qui permet entre autre à plusieurs machines physiques possédant chacune une adresse IP privée différente, d utiliser la même IP publique (celle qui apparait réellement sur internet) en réalisant automatiquement les traductions nécessaires entre l IP publique et les IP privées

64 4.3. Problématique d authentification 64 HTTP / OK Content - type : text / html Set - Cookie : name = value... contenu de la page... Listing 4.3: Réponse du serveur menant à l envoi d un cookie Si le navigateur de l utilisateur accepte le cookie (décide de le prendre en compte), les futures requêtes vers ce site auront un entête de la forme : GET / index. html HTTP /1.1 Host : www. example. org Cookie : name = value Accept : */* Listing 4.4: Requête GET contenant un cookie Souvent, l acceptation ou le rejet des cookies est géré automatiquement par le navigateur et le processus est donc totalement transparent pour l utilisateur. Mais il est souvent possible de modifier ce comportement pour que le programme demande une autorisation à l utilisateur pour chaque cookie en allant modifier les options de sécurité et de confidentitalité du navigateur. Les cookies sont un exellent moyen de contourner l aspect stateless du protocole HTTP. Dans le cas des problématiques d authentification, il est courant d attribuer à chaque visiteur un identifiant via un cookie de la forme : VisitorID = d8e8fca2dc0f896fd7cb4cb0031ba249 et la valeur du cookie VisitorID est utilisée comme clef de la hashtable. Dans le cas du serveur collaboratif, cette solution est applicable en réalisant, pour chaque utilisateur se connectant au serveur, une requête HTTP de login vers la plateforme permettant de récupérer la valeur du cookie pour cet utilisateur. A chaque requête utile (traduisant une instruction), le logiciel peut alors générer un en-tête HTTP contenant le cookie correspondant au bon utilisateur Identification par HTTP-Auth Une troisième possibilité pour gérer les problématiques d authentification consiste simplement à transmettre les login et les mot de passe de l utilisateur automatiquement à chaque requête. On conserve ici le principe purement stateless du protocole HTTP puisque chaque requête contient en son sein l ensemble des informations nécessaires à son exécution en ce y compris les informations d authentification. Il est possible de transmettre directement un login et un mot de passe dans un en-tête d une requête HTTP depuis la version 1.0 du protocole [7]. Pour inclure un login et un mot de passe directement au sein d une requête, il faut encoder en base 64 un string composé du login, du caractère deux point ( : ) et du mot de passe et inclure le résultat

65 4.3. Problématique d authentification 65 dans l en-tête de la requête : Login Mot de passe String à encoder String encodé AliBaba SesameOuvresToi AliBaba :SesameOuvresToi QWxpQmFiYTpTZXNhbWVPdXZyZXNUb2k= Listing 4.5: Requête GET contenant des informations d authentification GET / index. html HTTP /1.1 Host : www. example. org Authorization : Basic QWxpQmFiYTpTZXNhbWVPdXZyZXNUb2k = Accept : */* Dans le cadre du projet de serveur collaboratif, il s agit du système le plus simple à mettre en oeuvre puisqu il ne se base que sur des informations disponibles dès la connexion de l utilisateur au serveur et qu il ne nécessite aucune requête supplémentaire pour obtenir un token. L un des inconvénients majeurs de cette solution est que le nom d utilisateur et le mot de passe de l utilisateur circulent en clair 6 sur le réseau à chaque requête. Un attaquant peut donc facilement découvrir les informations d identification d un utilisateur en capturant une seule requête (attaque appelée Man in the middle). Ce système ne peut donc être employé que si le canal de communication entre les deux entités est considéré comme sûr. Dans la cas de ce travail, il est prévu d installer le serveur collaboratif sur la même machine physique que la plateforme : la communication se fait alors directement via des accès mémoires, sans passer par un réseau. Une attaque Man in the middle n est donc pas possible puisque l attaquant n a pas de moyen physique de capturer le moindre message. L hypothèse du canal sûr est donc, ici, raisonnable. 6. L encodage en base 64 est totalement symétrique et n offre donc aucune sécurité

66 4.4. Problématique de sécurité Problématique de sécurité Le framework Ruby on Rails permet de protéger par défaut les applications qui l utilisent contre certaines des attaques les plus fréquentes présentes sur internet [1]. On peut citer, par exemple, les attaques de type SQL Injection ou XSS (Cross Site Scripting). Une protection est également fournie contre les attaques de type CSRF (Cross Site Request Forgery). Or, la protection mise en place par Ruby on Rails pose problème dans le cadre de la communication entre le serveur collaboratif et la plateforme. Cette section va présenter successivement : Une description de l attaque CSRF. Les moyens mis en oeuvre pour s en prémunir, et pourquoi ils posent problème dans le cadre du projet. Comment il a été possible de contourner le problème sans désactiver la protection, et donc sans diminuer la sécurité de la plateforme L attaque CSRF Une attaque CSRF (également appelée XSRF) est un schéma d attaque qui permet à un attaquant de réaliser des opérations pour lesquelles il ne possède pas les droits en utilisant un utilisateur enregistré comme moyen de transport [19] Schéma d une attaque Soit Alice, un administrateur d un site internet communautaire. Mallory est un simple utilisateur de ce site et Bob, un attaquant qui souhaite faire disparaître le compte de Mallory. Bob connaît la structure du site d Alice et sait que s il arrive à réaliser une requête POST à la page : en passant le paramètre : account=mallory tout en ayant les autorisations suffisantes, le compte de Mallory sera supprimé 7. Bob ne possède pas ces autorisations et lorsqu il tente d envoyer cette requête POST, le site d Alice lui envoie une erreur d authentification. Bob va alors concevoir une page web malicieuse contenant un formulaire dont la cible est la page et contenant un champ caché impliquant account=mallory. La page de Bob est présentée de façon à encourager un utilisateur à compléter le formulaire. Bob contacte alors Alice en lui recommandant de compléter le formulaire qu il a conçu. Alice se rend sur la page malicieuse de Bob, complète le formulaire et valide l envoi. En appuyant sur envoyer, Alice effectue donc un requête POST vers la page et contenant le paramètre account=mallory à cause du champ caché. Le site accepte donc la requête (puisqu elle provient de Alice, l administrateur du site) et supprime le compte de Mallory. Bob a réussi son attaque. 7. On aura noté que ce site ne respecte donc pas le principe REST puisqu une requête de type DELETE aurait été plus appropriée pour cette action. Une partie non négligeable des sites internet utilisent uniquement les requêtes GET et POST et négligent les requêtes PUT et DELETE.

67 4.4. Problématique de sécurité 67 Il est important de noter que : Bob doit connaître la structure du site d Alice pour être capable de créer le formulaire. Ceci peut-être le cas si : Bob est un ancien responsable du site. Alice utilise un site clef en main 8 dont la structure est connue de tout le monde. La structure du site d Alice est suffisamment claire pour être devinée. Tenter de cacher la structure de son site n est pas un bon moyen de protection : cela permet de rendre l attaque plus difficile, mais pas de l empêcher totalement. Si Alice avait observé le code du site de Bob, l attaque aurait été révélée immédiatement. Mais il n est pas souhaitable de demander à un administrateur de site de vérifier le code de tous les formulaires qu il remplit. Dans l attaque présentée, Alice arrive sur la page qu elle voit lorsqu elle supprime un compte. Elle peut donc se rendre compte qu elle a été la cible d une attaque. Des versions plus évoluées de l attaque permettent parfois d éviter que cette page ne s affiche, et l attaque n est donc pas toujours détectable. Listing 4.6: Code HTML d un formulaire permettant à Bob de réaliser son attaque Entrez votre pour recevoir un joli cadeau : <form action =" http :// site -de - alice. com / account / delete " method =" POST "> <input type =" hidden " name =" account " value =" mallory " /> <input type =" text " name =" " /><br /> <input type =" submit " / > </ form > Moyens de protection L objectif est de vérifier que le formulaire à l origine d une requête POST a bien été créé par le site et non pas par une autre entité. Deux moyens sont disponibles [19] : 1. Vérifier l entête Referrer de la requête HTTP. Cet entête contient l adresse qui est à l origine de l arrivée sur une page. Si le referrer de la requête POST n est pas le site lui-même mais une page provenant d un autre domaine, la requête est rejetée. Malheureusement, il existe des attaques permettant d agir sur ce referrer 9. Cette protection n est donc pas idéale. 2. Inclure dans tout les formulaires générés par le site un champ caché nommé csrf token dont la valeur est générée par le site. Lors de la réception d une requête POST, il faut vérifier que le champ csrf token est présent et que son contenu est valide (ie : généré par le site) avant d effectuer l action. Pour générer ce token, la méthode habituelle consiste à réaliser un hash d un string composé d un mot secret, du nom donné au formulaire et de l identifiant de l utilisateur (adresse IP ou contenu du Cookie). Ainsi, le token change pour chaque visiteur et pour chaque formulaire, il est facile de vérifier que les token correspondent et il est impossible de générer un token valide sans connaissance du mot secret. C est la méthode choisie par Ruby on Rails pour protéger les formulaires [1]. 8. On peut citer par exemple : Wordpress, PHPBB, vbulletin, Joomla, Technique appelée Referrer Spoofing

68 4.4. Problématique de sécurité 68 Dans le cadre de la communication entre le serveur collaboratif et la plateforme, cette présence obligatoire d un token CSRF valide pose problème puisqu il oblige le serveur collaboratif à être capable de générer lui même ce token ou de le récupérer en réalisant une demande à la plateforme. Enfin, une dernière possibilité consiste à essayer de détecter si la requête provient de la plateforme et, si c est le cas, de ne pas vérifier le token Solution Puisque désactiver la protection CSRF n est pas une option (on diminuerait la sécurité de la plateforme), il est nécessaire de proposer une solution compatible avec le mécanisme de token. La première piste consiste à tenter de récupérer le token à chaque requête (ou en tout cas, une fois par type de requête). Cette solution semble complexe et peu pratique car cela nécessite de réaliser une première requête de récupération de token pour chaque requête utile et multiplie donc par deux la charge pour le serveur collaboratif et pour la plateforme. De plus, l analyse du code HTML pour récupérer le token à partir du code du formulaire envoyé par la plateforme est une tâche relativement complexe et sensible à la moindre variation effectuée sur le plateforme. Cette détection aurait fortement tendance a bugger à la moindre variation de la plateforme. Une seconde option consiste à trouver un moyen de générer le token directement dans le serveur collaboratif. Il faut pour cela avoir accès à l ensemble des paramètres permettant la création du token et connaître l algorithme de génération utilisé. Ruby on Rails utilise entre autre le numéro de session attribué par cookie (voire Section ) à chaque visiteur. Dans la mesure où la plateforme ne tient pas compte de ce cookie, même dans un cadre d authentification, cette formation n est pas accessible sans modification de la plateforme. Mais il s agit d une voie envisageable. La dernière solution consiste à faire réaliser par le serveur des requêtes HTTP encodées au format XML. Lors d une requête POST ou PUT, le navigateur encode les paramètres de la requête directement dans le corps du message en utilisant le format x-www-form-urlencoded. Or, il est également possible d encoder les paramètres de la requête en utilisant le format XML. Cette option est habituellement utilisée lorsque l application internet propose une API 10. Une requête POST ou PUT dont les paramètres sont encodés en XML ne provient pas d un navigateur 11, et ne constituent donc pas une menace. Par défaut, Ruby on Rails désactive donc la vérification du token CSRF pour ce type de requête. L utilisation du XML pour encoder les paramètres des requêtes POST et PUT offre également l avantage d être plus facile à manipuler pour le programmeur, d être plus lisible et donc de faciliter la création du programme et son débogage. Il s agit donc de la solution retenue dans le cadre de ce projet 10. API : Application Programming Interface. C est un ensemble d outils qui permet à un programmeur d interagir avec un service dans ses applications 11. Une requête HTTP dont les paramètres sont encodés en XML peut provenir d un navigateur dans le cadre de l utilisation de l objet XMLHttpRequest mis en oeuvre dans la technologie AJAX. Cependant, les requêtes AJAX cross-site ne sont pas autorisées, justement pour des raisons de sécurité.

69 4.4. Problématique de sécurité 69 POST /login.jsp HTTP/1.1 POST /login.jsp HTTP/1.1 Host : Host : User-Agent : Mozilla/4.0 User-Agent : Mozilla/4.0 Content-Length : 27 Content-Length : 88 Content-Type : application/x-www-form-urlencoded Content-Type text/xml ; charset= utf-8 userid=joe&password=guessme <?xml version= 1.0 encoding= UTF-8?> <userid>joe</userid> <password>guessme</password> Table 4.2: Comparaison entre une requête POST au format x-www-form-urlencoded et au format xml

70 CHAPITRE 5 Le chargement Les deux chapitres précédents traitaient des échanges de messages permettant le travail collaboratif. Ce chapitre traitera des échanges de message entre D-Sight, le serveur collaboratif et la plateforme prenant place entre le moment où un utilisateur lance D- Sight et le moment ou celui-ci commence à travailler de manière collaborative. Les divers nouveaux éléments de codes permettant ce chargement seront également présentés. Au terme de ce chapitre, la situation sera telle que : L utilisateur aura devant lui un fichier D-Sight ouvert correspondant à la dernière version disponible. Et l ensemble des objets nécessaires auront été créés pour permettre le travail collaboratif. En particulier, le plugin collaboratif pourra transformer toute commande en XML, et communiquer avec le serveur collaboratif. Le serveur collaboratif aura associé chaque instance de D-Sight à un objet de type ClientConnection associé à l objet SessionManager du projet sur lequel l utilisateur travaille. Ces deux états correspondent aux hypothèses posées au début des deux chapitres précédents.

71 5.1. Procédure générale Procédure générale Le processus de chargement se déroule comme présenté à la Figure 5.1 Figure 5.1: Schéma UML de séquence du chargement L utilisateur se connecte au serveur collaboratif et fournit son login et son mot de passe. Le serveur collaboratif renvoie un message indiquant si l authentification s est bien déroulée. Si l authentification est réussie, le plugin collaboratif demande la liste des projets de l utilisateur. Le serveur collaboratif lui renvoie la liste des projets auxquels cet utilisateur est associé. L utilisateur sélectionne le projet sur lequel il souhaite travailler. Le serveur collaboratif renvoie la liste des autorisations que possède cet utilisateur pour ce projet. Le serveur collaboratif renvoie la version actuelle du projet sélectionné On aura noté que la requête sélection de projet mène à l envoie de deux réponses de la part du serveur collaboratif. Ceci est possible puisque la connexion entre les deux entités est une connexion par socket comme indiqué à la Section 2.5. Cette suite d opérations a été mise au point de façon à être le plus naturel et interactif possible pour l utilisateur.

72 5.2. connexion initale et authentification connexion initale et authentification Le point de vue de D-Sight Lorsque l utilisateur pousse sur le bouton connect, le plugin ouvre une connexion par socket vers l ip et le port défini par l utilisateur. Une fois la connexion établie, le plugin envoie un message de login dont le header vaut 0 et le corps est la concaténation du nom d utilisateur et du mot de passe entré par l utilisateur, séparés par le caractère deux points ( : ) : Header : 0, Body : login : motdepasse Le plugin attend alors un message indiquant si le couple login/mot de passe a été reconnu par la plateforme. Un message sans corps dont le header vaut 100 indique que l opération s est bien déroulée. Un message sans corps dont le header vaut 200 indique une erreur d authentification. Si l authentification est réussie, le plugin envoie automatiquement (sans action supplémentaire de l utilisateur), un message demandant la liste des projets de l utilisateur : Header : 1, Body : / En réponse, le plugin attend un message listant les projets de l utilisateur : Header : 101, Body : Liste des projets, au format XML

73 5.2. connexion initale et authentification Le point de vue du serveur collaboratif Lorsqu une demande de connexion par socket arrive, un objet de type ClientConnection est créé, et encapsule le socket. Le serveur attend alors un message contenant le login et le mot de passe de l utilisateur. Lorsque ce message est reçu, le serveur collaboratif sauve ces deux informations et effectue une requête vers la plateforme de la part de cet utilisateur : GET / users / current. xml Si la réponse de la plateforme est valide (réponse de type : 200/OK), c est que ce couple login / mot de passe est effectivement associé à un utilisateur de la plateforme. Le serveur collaboratif renvoie alors le message de confirmation de login. Dans le cas contraire, il renvoie le message indiquant une erreur et coupe la connexion avec l instance de D-Sight. Lorsque la plateforme reçoit un message demandant la liste des projets de l utilisateur, elle effectue une requête : GET / projects. xml et renvoie la réponse de la plateforme directement à l instance de D-Sight. Listing 5.1: Représentation XML de la liste des projets < projects type =" array "> < project > <client - account -id type =" integer ">1</ client - account -id > <created -at type =" datetime "> T00:55:36Z </ created -at > <id type =" integer ">1</id > <name > TestProject </ name > < objective >Avoir son diplome </ objective > <updated -at type =" datetime "> T00:55:36Z </ updated -at > </ project > < project > <client - account -id type =" integer ">1</ client - account -id > <created -at type =" datetime "> T05:03:34Z </ created -at > <id type =" integer ">3</id > <name > Second Test </ name > < objective >Un autre objectif </ objective > <updated -at type =" datetime "> T05:03:34Z </ updated -at > </ project > </ projects > Le flux XML transmis donne donc pour chaque projet : son identifiant, son nom, l objectif (sorte de courte description), la date de création et la date à laquelle a eu lieu la dernière modification du nom ou de l objectif.

74 5.3. Sélection et chargement du projet Sélection et chargement du projet Point de vue de D-Sight Lorsque le plugin reçoit le message contenant la liste des projets, il s en sert comme source de données pour générer le panel présenté ci-dessus. Si l identifiant du projet n est pas affiché, il est néanmoins conservé en mémoire. Lorsque l utilisateur appuie sur le bouton Load, un message de sélection de projet est envoyé au serveur collaboratif : Header : 2, Body : L identifiant du projet choisi Le serveur collaboratif répond alors avec deux messages successifs. Le premier contient le niveau d autorisation de l utilisateur vis-à-vis du projet sélectionné, et le second contient le fichier à ouvrir Gestion de l autorisation Le plugin reçoit le message contenant le niveau d autorisation : Header : 202, Body : Le niveau d autorisation ( sous forme de String ) Le niveau d autorisation peut valoir : Viewer : l utilisateur ne peut faire aucune modification sur le projet, mais peut simplement le consulter. Expert : l utilisateur peut modifier ses évaluations et utiliser le logiciel normalement pour dégager une solution. Il ne peut par contre pas modifier la structure du problème (ajouter ou retirer des alternatives ou des critères).

75 5.3. Sélection et chargement du projet 75 DecisionMaker : l utilisateur possède exactement les mêmes rôles que ci-dessus. La séparation entre les rôles de ces deux intervenants n a pas encore été implémentée dans la plateforme. ProjectManager : l utilisateur possède tout les droits sur le projet. Une fois ce message reçu, le plugin crée un nouvel objet de type CommandHandler (cf Section ) correspondant au niveau d autorisation de l utilisateur. Ce Command- Handler est ajouté dans la chaîne du contrôleur et vérifie que toutes les commandes qu il reçoit soient autorisées. Si les commandes sont valides, elles sont simplement transmises sans modification. Sinon, un message d erreur est affiché et la commande est interrompue (et n est donc pas exécutée). L objectif de ce CommandHandler est donc d empêcher l exécution sur D-Sight d une commande qui se verrait refusée par la plateforme. Lorsque la commande arrive à la plateforme sous la forme d une suite de requêtes HTTP, les autorisations sont bien évidemment re-vérifiées avant que les modifications ne soient apportées à la base de données. Lorsque ce mécanisme d autorisation a dû être implémenté au sein de D-Sight, trois possibilités sont apparues : 1. Demander l autorisation à chaque commande : un message est envoyé depuis le plugin vers le serveur collaboratif pour chaque commande que l utilisateur souhaite effectuer. Le serveur collaboratif contacte alors la plateforme pour vérifier si la commande est autorisée et renvoie la réponse au plugin. Cette solution présente trois désavantages majeurs. D une part, il aurait fallu ajouter à la plateforme le traitement des requêtes de type : Cette commande est-elle autorisée?. D autre part, effectuer pour chaque commande utile, une ou plusieurs requêtes demandant les autorisations aurait augmenté la charge de façon inutile. Enfin, la requête d autorisation introduit un délai entre le moment ou l utilisateur effectue la commande (par exemple en poussant sur un bouton) et le moment ou celle-ci est effectivement répercutée. Même si ce délai reste relativement court, il génère immédiatement une impression de lourdeur dans l application. 2. Obtenir les autorisations et vérifier les commandes avant leur exécution : c est la solution retenue. Le plugin obtient les autorisations de la plateforme suite à une requête unique, puis se charge de vérifier les requêtes manuellement avant de les effectuer et de les transmettre. De cette façon, aucune requête invalide ne devrait arriver à la plateforme. Ce système est relativement simple à mettre en place si les niveaux d autorisation de la plateforme sont facilement implémentables dans un CommandHandler, ce qui est le cas avec la version de la plateforme sur laquelle ce projet s est basé. 3. Effectuer la commande et l annuler si nécessaire : dans ce cas, la commande est effectuée immédiatement et transmise. Si la commande est refusée par la plateforme, un message du serveur collaboratif alerte le plugin que la commande doit être annulée. Il s agit d un système plus souple et plus puissant que le précédent puisque chaque commande n est effectivement validée (n est pas annulée) que si elle a été confirmée par la plateforme. Ce système est également plus complexe à implémenter. Il n a donc pas été privilégié pour cette raison, mais il reste une piste accessible si la gestion des autorisations devient trop complexe avec la méthode retenue.

76 5.3. Sélection et chargement du projet Gestion du fichier binaire Après avoir reçu le message contenant l autorisation de l utilisateur vis à vis du projet, le plugin va recevoir le message contenant le projet en tant que tel : Header : 102, Body : Le fichier binaire Le fichier à ouvrir est encodé directement au format D-Sight. Le Body du message qui le transporte est donc bien un ensemble de bit (blob binaire), et non pas un String, comme c est le cas habituellement. Ce blob binaire est enregistré par le plugin dans un fichier placé dans le répertoire temporaire de l ordinateur puis ouvert automatiquement, en utilisant la même procédure que lors de l ouverture d un fichier normal. Une fenêtre modale 1 bloque les actions de l utilisateur durant le processus de téléchargement du fichier et son ouverture. Avant de fermer automatiquement cette fenêtre, l objet CollaborativeWorkCommandHandler 2 est créé et mis en place à la suite du CommandHandler gérant les permissions. Cette position du CollaborativeWorkCommandHandler dans la chaîne du contrôleur, juste après le CommandHandler gérant les permissions, est importante pour deux raisons : 1. Les commandes rejetées ne sont pas converties en XML, et ne sont donc pas envoyées à la plateforme, ni aux autres participants. 2. Les commandes issues du serveur collaboratif (donc provenant d autres utilisateurs) ne sont pas vérifiées par le plugin. Ceci permet à plusieurs personnes travaillant sur le même projet de travailler collaborativement tout en ayant des permissions différentes Le point de vue du serveur collaboratif Lorsque le serveur collaboratif reçoit le message de sélection de projet, il doit commencer par renvoyer un message contenant les permissions de l utilisateur pour le projet sélectionné. Pour cela, il effectue une requête vers la plateforme : GET / projects / PROJECT_ID / roles PROJECT_ID = identifiant du projet choisi La réponse de la plateforme est un flux XML que le serveur collaboratif analyse afin d en déduire le rôle précis de l utilisateur, et renvoie ce résultat sous forme de String, comme indiqué précédemment. Du coté de la plateforme, la réponse à cette requête HTTP n était pas présente et il a donc été nécessaire d ajouter cette fonctionnalité. 1. Une fenêtre modale empêche l utilisateur d interagir avec le reste de l application tant qu elle est ouverte. Ce type de widget est utilisé pour forcer l utilisateur à patienter durant une opération longue ou lorsqu il doit impérativement répondre à une question avant de pouvoir continuer à utiliser le logiciel 2. Cet objet transforme toute commande qu il reçoit en flux XML et envoie un message à la plateforme et qui transforme les messages de la plateforme en commandes exécutables. Le détail est disponible à la Section 3.2.3

77 5.3. Sélection et chargement du projet 77 Après avoir envoyé ce message, il faut permettre au client D-Sight de charger le projet sauvegardé dans la base de données de la plateforme. La sous-section précédente a indiqué que D-Sight allait recevoir un blob binaire correspondant au fichier à ouvrir pour charger le projet. Le choix de cette solution fait suite à une analyse qu il semble nécessaire de présenter avant d expliciter les détails techniques de l implémentation réalisée Chargement du projet : analyse L objectif de cette étape consiste à transmettre à D-Sight les informations qui vont lui permettre d effectuer les modifications nécessaires sur son modèle de façon à le synchroniser avec la version du projet présente dans la base de données de la plateforme. D-Sight possède en standard un mécanisme de persistance lui permettant de sauvegarder un état du modèle dans un fichier (donc une suite de bits) portant habituellement l extension.dsi. En ouvrant ce fichier, D-Sight est capable de restaurer l état du modèle sauvegardé. Recréer un modèle à partir d un ensemble d informations étant une étape relativement complexe et assez sensible, il a semblé intéressant de tenter de réutiliser cette fonctionnalité de persistance déjà écrite et largement testée. La difficulté consiste donc à générer un fichier.dsi (ou en tout cas son contenu) à partir des informations stockées dans la base de données relationnelle de la plateforme. Cette traduction peut prendre place à trois endroits : 1. Au niveau de la plateforme. 2. Au niveau du serveur collaboratif. 3. Au niveau du plugin de D-Sight. La troisième possibilité n a pas été retenue, puisque qu il a été indiqué précédemment que le message envoyé par le serveur collaboratif contenait déjà le blob binaire correspondant au fichier à ouvrir. Génération au niveau de la plateforme : Il s agit de créer la réponse à une requête du type : GET / projects / PROJECT_ID / dsi le corps de la réponse contant le fichier.dsi. Si cette requête était effectuée depuis un navigateur internet, elle correspondrait à un téléchargement du fichier. Le serveur collaboratif n aurait qu à effectuer cette requête et transmettre la réponse sans modification. Cette solution implique de lier directement la plateforme à D-Sight : il est nécessaire d introduire dans la plateforme du code spécifique au fait que D-Sight interagit avec la plateforme. Par exemple, en cas d évolution de D-Sight, il peut-être nécessaire d aller modifier cette fonction dans le code de la plateforme. Or, l objet même du projet est de conserver une séparation la plus forte possible entre D-Sight et la plateforme. Si certaines fonctionnalités ont dû être ajoutées à la plateforme, ou à D-Sight, elles l ont été de façon à être utilisables dans le cadre d autres projets.

78 5.3. Sélection et chargement du projet 78 Génération au niveau du serveur collaboratif : Le serveur collaboratif effectue une ou plusieurs requêtes HTTP vers la plateforme, ce qui lui permet de de récupérer les informations nécessaires à la création d un fichier.dsi qui est renvoyé au plugin. C est la solution retenue puisqu elle s inscrit totalement dans la logique d implémenter au niveau du serveur collaboratif, l ensemble des fonctionnalités de traduction entre D-Sight et la plateforme. Génération au niveau de D-Sight : Le plugin reçoit les données directement depuis la plateforme, génère le fichier.dsi et l ouvre. Cette solution fut rapidement rejetée car elle oblige à réaliser et à déployer des mises à jour du plugin à chaque modification de la plateforme. Le développement de la plateforme devient donc largement plus complexe, et les mises à jour trop régulières du plugin peuvent gêner les utilisateurs Chargement du projet : implémentation Au niveau de la plateforme, le traitement à une requête de type : GET / projects / PROJECT_ID. xml a été implémenté. La réponse à cette requête est un flux XML contenant l ensemble des informations disponibles pour ce projet. Le serveur collaboratif effectue donc cette requête puis doit générer un fichier.dsi à partir de la réponse reçue. Pour cela, la couche modèle de D-Sight a été allégée et exportée sous forme de librairie. Cette librairie est constituée de l ensemble des classes contenant le modèle de D-Sight auquel ont été supprimés : Tous les aspects de gestion d événements, utilisés pour les rafraîchissement d interface, comme exposé à la Figure 3.2. Toute référence à la partie logique, celle qui implémente les calculs réalisés par D-Sight pour produire ses résultats. Toute la partie résultat du modèle. Seules les fonctionnalités de conservation des données initiales du problème ont donc été conservées. Pour générer un fichier.dsi, le serveur collaboratif va donc successivement : Instancier un modèle de D-Sight à partir de la librairie. Remplir ce modèle à partir des informations du flux XML. Cette étape est plus simple que sur une version normale de D-Sight : le modèle peut avoir ici, temporairement, un état incohérent. Sous D-Sight, les rafraîchissements d interface et l actualisation des résultats imposent l ordre dans lequel doivent être effectués les modifications. L opération est donc plus complexe dans ce cas là. Utiliser la fonctionnalité de sauvegarde de D-Sight, qui est inclue dans la librairie. L intérêt majeur de cette méthode est que tout l aspect de génération du fichier.dsi à partir des données est directement copié depuis D-Sight, les chances de bug ou d incompatibilité sont donc très faibles. Le code d analyse du flux XML reçu par la plateforme

79 5.3. Sélection et chargement du projet 79 doit simplement agir sur le modèle instancié sans nécessiter de connaissance du format.dsi, ce qui rend cette étape également plus simple et claire. Pour conserver un code bien organisé, une classe DsiGenerator a été créée. C est elle qui encapsule toute la complexité de la création d un fichier.dsi. Son interface n est constitué que d une fonction : public static byte [] generatedsi ( String xml, String version ) Cette fonction prend entrée le flux XML fourni par la plateforme ainsi que la version de D-Sight pour laquelle elle doit générer un fichier.dsi 3. La sortie est bien évidemment la suite de bits correspondant au contenu du fichier généré. Une fois le blob binaire renvoyé à l utilisateur grâce au message ad-hoc, le serveur collaboratif doit associer l objet ClientConnection lié à l utilisateur, avec l objet Session- Manager lié au projet sur lequel il travaille. Pour se faire, le serveur collaboratif garde en mémoire une hashtable 4 dont les clefs sont des identifiants de projet et les valeurs sont les objets SessionManager associé à chaque projet. Si aucun objet SessionManager n est référencé pour le projet sélectionné par l utilisateur, une nouvelle instance est créée et ajoutée à la hashtable, puis le ClientConnection de l utilisateur lui est associé. Si un SessionManager existait déjà pour ce projet, il recevra simplement un ClientConnection supplémentaire. 3. Dans le cadre de ce projet, une seule version de D-Sight est gérée et ce paramètre a donc peu de sens. Mais en production, de multiples versions de D-Sight devront sans doute être prises en compte et la version de D-Sight de l utilisateur aura alors une importance 4. Pour rappel : une hashtable est une structure de données optimisée pour permettre de retrouver rapidement une donnée nommée valeur à partir d une autre donnée nommée clef.

80 Troisième partie Conclusions

81 CHAPITRE 6 Analyses personnelles Ce chapitre contient l ensemble des analyses ayant pris part après la phase d implémentation. Il est en effet utile de porter un regard critique sur le travail effectué. Les conclusions de ces analyses seront séparées en deux sections : 1. La première section va comparer le résultat obtenu avec le cahier des charges initial. Les principaux choix techniques seront commentés et éventuellement critiqués. 2. La seconde section va porter sur les perspectives du projet. Différentes possibilités de déploiement seront analysées. Enfin, ce chapitre clôturera ce rapport par une conclusion générale.

82 6.1. Analyse rétrospective Analyse rétrospective Pour rappel, le cahier des charges défini à la Section imposait quatre éléments majeurs : 1. Toute modification d une alternative, d un critère ou d une évaluation devait être transmise instantanément aux autres participants. 2. Ces modifications devaient être répercutées sur la plateforme. 3. Un participant devait pouvoir joindre la session à tout moment. 4. Les droits et les permissions devaient pouvoir être gérés dans D-Sight. En plus de ces objectifs, deux contraintes supplémentaires devraient être remplies : La fonctionnalité de travail collaboratif devait pouvoir être activée ou désactivée facilement depuis D-Sight. Le code de la plateforme devait être modifié au minimum et sans gêner son développement futur. Au cours de ce chapitre, les principaux choix techniques effectués seront analysés. Il est important de noter que les implémentations réalisées permettent de remplir le cahier des charges : le projet fonctionne et une démonstration de travail collaboratif sera réalisé lors de la défense. Le but de ce chapitre est donc de démontrer que le mémorant porte un regard critique vis-à-vis de son travail et que l ensemble des expériences acquises au cours du projet ont fait l objet d une réflexion L architecture générale A postériori, le choix d implémenter le code de gestion des clients D-Sigh dans une entité spécialisée (le serveur collaboratif) semble avoir été un bon choix. Comme souhaité, cela a permis de modifier la plateforme au minimum tout en offrant une grande souplesse dans les communications entre ce serveur collaboratif et les clients D-Sight. Le choix de connecter ce serveur collaboratif à la plateforme plutôt qu à la base de données semble là encore avoir été le bon choix. Il est important de noter que la relative facilité avec laquelle il est possible d interagir avec la plateforme est principalement due à l utilisation intelligente de l architecture REST et de la séparation en trois couches (principe MVC ). Les capacités du framework Ruby on Rails ont, à ce titre, facilité grandement tous les échanges de messages avec la plateforme Les modifications apportées à D-Sight L ajout du design pattern Command à D-Sight a été un aspect important du projet. Le système proposé est fonctionnel et suffisamment souple pour être adaptable et extensible dans le cadre des futurs améliorations de D-Sight. De plus, la gestion de la fonctionnalité d undo et de l historique est une fonctionnalité qui n était pas prévue dans le cahier des charges initial. Si utiliser ce système dans la vue est particulièrement simple et rapide, créer de nouvelles commandes est une opération plus longue que le simple ajout d une fonction

83 6.1. Analyse rétrospective 83 supplémentaire dans le modèle. A ce titre, les fonctionnalités d exportation et d importation de chaque commande en XML restent des opérations lourdes à gérer pour le programmeur. Il aurait peut-être été possible d automatiser cette tâche avec des librairies telles que XStream 1. Cette tâche reste cependant relativement rare. Enfin, si la majorité des appels au modèle ont été convertis pour utiliser le nouveau système, les tests automatisés pour vérifier que seul le pattern command est utilisé n ont pas été menés pour toutes les opérations. Seules les opérations inclues dans le cadre du travail collaboratif ont été vérifiées systématiquement. Les opérations les plus courantes ont été migrées, afin de tester le système plus en profondeur, mais certains panels peu utilisés doivent encore subir des modifications. Cette partie du travail s étant terminée aux alentours du mois de janvier 2011, on peut regretter que ces fonctionnalités n aient pas pu être inclues dans la branche principale de D-Sight. Cela aurait pu être bénéfique a trois niveaux : 1. La fonctionnalité aurait pu être disponible pour les clients de Decision Sights plus rapidement. 2. Avec l aide de Decision Sights l ensemble de l application aurait pu bénéficier du nouveau système. 3. Depuis janvier, D-Sight a subi une mise à jour. Le merging de la branche contenant le pattern commande avec la branche principale pourrait être légèrement plus complexe. La résolution des conflits potentiels devrait être relativement aisée puisque la majorité du code produit correspond à des créations de nouvelles classes et que les modifications sont très localisées Les modifications apportées à la plateforme Deux types de modifications ont été apportées à la plateforme : 1. La modification du type des identifiants, depuis un ID numérique vers un ID sous forme de String correspondant à un UUID. 2. L ajout de certains contrôleurs ou de certaines vues. Les contrôleurs ajoutés et les vues générées sont relativement simples. Aucune de ces modifications n implique de mis à jour de la base de données, et la sécurité de ces éléments a été testée. Ces changements concernent la gestion de requêtes légitimes ; peu liées au travail collaboratif en lui-même. Les sorties de ces contrôleurs se présentent sous la forme de flux XML standardisés. On peut donc affirmer qu ils s intègrent naturellement dans le code de la plateforme sans la mettre en danger. Ces nouveaux points d accès peuvent être vus comme un premier pas vers la constitution d une API pour la plateforme. La modification du type des identifiants pour gérer les UUID est largement plus intrusive et plus spécifique aux problématiques du travail collaboratif. A ce titre, la contrainte de modification minimum de la plateforme n est pas entièrement respectée. Cependant, même plusieurs mois après le début de l implémentation de ces modifications, aucune autre solution de remplacement techniquement envisageable n a pu être présentée. 1. Libraire de sérialization/désérialization des classes java en XML :

84 6.1. Analyse rétrospective Le serveur collaboratif L organisation du serveur collaboratif ne nécessite pas de commentaire majeur. L ensemble des classes le constituant possèdent chacune un rôle bien défini l utilisation d interfaces lorsque cela se justifie permet de conserver un couplage faible. Le serveur collaboratif suit donc les préceptes des bonnes pratiques de la programmation orientée objet ce qui garantit une bonne maintenabilité du code et permettra des modifications aisées La communication entre D-Sight et le serveur collaboratif Comme espéré, l utilisation d un protocole simple au-dessus d un socket TCP permet d échanger les messages de façon efficace (peu d overhead). Les librairies standards de java qui interagissent avec la classe Socket permettent de modifier facilement les flux échangés, par exemple pour changer les mécanismes de sécurité. Le protocole en lui-même est facilement extensible (il suffit de réserver des numéros de header supplémentaires), ce qui est un élément important pour Decision Sights. On pourrait éventuellement lui reprocher de ne pas proposer de moyen standard pour passer des options au sein du header, comme le permet HTTP. Notons néanmoins que cette fonctionnalité est largement moins importante qu elle ne peut l être pour HTTP du fait du coté non stateless du moyen de communication. Un exemple simple de cette affirmation pourrait être la gestion du numéro de version (le traitement des messages sur le serveur doit varier en fonction de la version de D-Sight utilisée) : dans le cas de HTTP, il serait idéal d ajouter, à chaque requête, le numéro de version de D-Sight via un header HTTP de la forme : dsight - version : Dans le cas du protocole mis au point dans ce mémoire, on préférera créer un nouveau message dont le corps renseignera le numéro de version de D-Sight concerné. Ce message est envoyé une seule fois, et toutes les communications suivantes seront traitées de façon adéquate La communication entre le serveur collaboratif et la plateforme La communication entre le serveur collaboratif et la plateforme se fait en HTTP. Les deux seules particularités utilisées dans le projet sont : 1. L utilisation de HTTP Basic Auth pour les problématiques d authentification. 2. L encodage des paramètres des requêtes POST et PUT en XML pour éviter les vérifications des tokens CSRF.

85 6.1. Analyse rétrospective 85 L encodage des donnée en XML n introduit pas de réelle complexité supplémentaire et ne constitue donc pas un choix risqué. La problématique de la transmission en clair des identifiants de connexion par HTTP Basic Auth sera abordé dans la section suivante.

86 6.2. Perspectives de déploiement Perspectives de déploiement La section précédente a permis au mémorant d effectuer une critique de son travail en portant un regard sur le passé de celui-ci. Cette section-ci, au contraire, va concerner le futur du projet. Elle analysera les différents moyens d appliquer les résultats obtenus, les éléments restant à développer ainsi que les problématiques propres à la mise en production. Cette section est utile à la fois au lecteur académique qui y trouvera la preuve que le mémorant conserve un regard lucide sur son travail et à Decision Sights qui y trouvera les avis de l étudiant sur les différents moyens d exploiter son travail. Certaines réponses à des problématiques techniques propres à la mise en production seront également abordées Mise en production du système de undo Comme explicité précédemment, la fonctionnalité d undo n est pas liée au travail collaboratif : il est possible de mettre en production le système d undo sans jamais distribuer la plateforme, ou le plugin collaboratif. Il convient donc de séparer clairement cette partie du travail. Outre la problématique de la conversion de tout les appels au modèle en commande, déjà exposée à la section précédente, il reste une problématique d ordre plus stratégique : la gestion des commandes issues de plugins. On peut globalement séparer ces commandes en deux catégories : 1. Les commandes effectuant une action uniquement sur le modèle de D-Sight. Par exemple, un plugin aurait un bouton ajouter alternative : cette action modifie uniquement le modèle de D-Sight. 2. Les commandes effectuant une action sur le modèle de D-Sight et sur des données propres au plugin. Par exemple, le plugin de carte possède un bouton Lier l alternative yyy à cette zone géographique : cela ne modifie pas de données contenues dans le modèle de D-Sight, mais modifie la couche modèle du plugin. Le premier type de commande pose peu de problèmes : d une part car il serait étrange de ne pas les porter (l utilisateur ne voit pas de réelle raison à ce qu il puisse annuler la création d une alternative s il utilise le bouton de la fenêtre principale, mais pas s il utilise le bouton du panel du plugin), et d autre part car porter ces commandes ne pose techniquement pas plus de problèmes que porter les commandes de D-Sight. Le second type de commande est plus délicat. Trois approches sont possibles : La première approche consiste à ne pas porter ces commandes vers le nouveau système : ces opérations ne sont alors pas exportables en XML (donc pas de transmission des commandes sur le réseau), ni annulables. La situation reste donc dans l état actuel, pour ces opérations. La seconde approche consiste à porter ces commandes vers le nouveau système, mais à permettre aux instructions les composants de conserver des pointeurs vers les modèles des plugins qu ils modifient. On ne peut alors pas les convertir en XML (cf Section ), mais elles peuvent être gérées par l historique.

87 6.2. Perspectives de déploiement 87 La troisième approche consiste à vouloir imposer les mêmes contraintes aux commandes issues des plugins qu à celles issues de D-Sight. Il faut donc offrir un moyen aux instructions de ces commandes de retrouver un pointeur vers le modèle à modifier. Il faut donc permettre aux plugins d enregistrer leurs modèles respectifs auprès de D-Sight en mettant à disposition une méthode de type : void registermodel ( String modelname, Object model ); Les instructions pourront alors récupérer le bon modèle grâce à une méthode présente dans le DataManager : Object fetchmodel ( String modelname ); Les instructions doivent alors simplement contenir le nom du modèle qu elles doivent modifier, sous forme de String, et ne sont pas obligées d avoir un pointeur. Elles sont donc transformables en flux XML. Pour permettre l opération de désérialization, il faut là encore permettre aux plugins de notifier D-Sight qu ils possèdent un composant capable de créer certaines commandes à partir d un String XML. Ces modifications sont donc largement plus lourde puisqu elles nécessitent d implémenter des fonctionnalités supplémentaires à D-Sight et de réécrire une partie des plugins Mise en production du système de travail collaboratif Remarques générales Après avoir présenté les questions techniques et stratégiques qui entourent la mise en production du système d undo, cette section va se concentrer sur la mise en production du système de travail collaboratif en lui-même. Il semble évident que la priorité pour Decision Sights va être de terminer d implémenter, au sein de la plateforme, l ensemble des données gérées par D-Sight. Le mémoire a été réalisé sur un Proof of Concept, qui reprenait les bases de D-Sight : pour permettre à la plateforme de jouer son rôle de gardien de données, il faut : Implémenter chaque concept de D-Sight dans le schéma relationnel de la base de données. Mettre à disposition du serveur collaboratif les requêtes GET / POST / PUT et DELETE de base pour chacun de ces éléments. Comme indiqué à la Section 2.4, cette partie du travail est grandement facilitée par le framework Ruby on Rails qui permet d automatiser certaines tâches. Il était difficile d effectuer ce travail durant le mémoire dans la mesure ou le Proof of Concept de la plateforme avait pour objectif d être un D-Sight allégé. Les contrôleurs implémentaient donc déjà une couche de calculs, et la plateforme faisait donc plus que du simple stockage. Ceci est une conséquence directe du fait que la version de la plateforme

88 6.2. Perspectives de déploiement 88 utilisée dans ce mémoire avait pour simple objectif d explorer des pistes d exploitation possibles. Si Decision Sights se donne pour objectif de distribuer le système collaboratif en utilisant la plateforme comme moyen de stockage et de management, l ensembles des contrôleurs pourront être largement allégés. L organisation des pages devra sans doute être revue pour mieux refléter ce nouveau rôle. En plus de ce travail indispensable sur la plateforme, le serveur collaboratif doit lui aussi être adapté. Les trois améliorations qui semblent prioritaires sont : 1. La mise en place d un réel système de logging. Utile en cas de problème ainsi que pour permettre d effectuer des analyses sur l utilisation de D-Sight. Dans le cadre du mémoire, le logging est réalisé directement sur la sortie standard, ce qui permet un débogage aisé. En fonction des besoins de Decision Sights en terme d analyse de marché, des systèmes de logging plus évolué peuvent être mis en place. 2. Un réel traitement des erreurs provenant de la plateforme. Chaque réponse HTTP devrait être analysée pour repérer d éventuelles erreurs de type : 500 Internal Server Error : la plateforme plante. toutes les connexions actives avec des clientsd-sight devraient être coupées. Et le serveur collaboratif déconnecté. 403 Forbidden : indique un problème de permissions. Seule la connexion à l origine de la requête devrait être coupée.... On peut imaginer l envoi d un message spécifique avant d effectuer les coupures. 3. Implémenter dans le plugin la vérification du certificat émis par le serveur collaboratif. Cette troisième amélioration fait directement suite à la remarques émise à la fin de la Section 3.5 : dans le cadre du mémoire, le serveur collaboratif utilise un certificat auto-signé, ce qui permet de garantir que les échanges entre le serveur collaboratif et le plugin sont confidentiels. Par contre, l aspect auto-signé du certificat utilisé annule la fonctionnalité d authentification permise par SSL. Il est donc possible à un attaquant de créer un faux serveur collaboratif, utilisant un certificat lui aussi auto-signé, qui va dialoguer avec des plugins. En utilisant une autorité de certification extérieure, et en limitant les certificats acceptés à ceux émis par cette autorité, ce n est plus possible. La modification doit donc avoir lieu à la fois au niveau du serveur, qui doit utiliser le certificat fourni par l autorité, et au niveau du plugin qui ne peut accepter que les certificats signés par cette autorité : Au niveau du serveur collaboratif : Au niveau du serveur collaboratif, le code ne change pas, mais il est nécessaire de créer un Keystore à partir des fichiers fournis par l autorité de certification. La suite précises des commandes à taper dépend du fournisseur choisi, mais cela reste une opération bien expliquée sur internet [17] et probablement reprise dans la documentation de l autorité de certification choisie. Une fois le Keystore généré, le serveur collaboratif doit simplement être lancé à l aide de la commande :

89 6.2. Perspectives de déploiement 89 java - Djavax. net. ssl. keystore = mykeystore \ - Djavax. net. ssl. keystorepassword = mykeystorepassword \ - jar DSightCollaborativeServer. jar Au niveau du plugin, la clef publique de l autorité de certification doit être inclue comme ressource dans le plugin, puis chargée dans le TrustStore. La classe ServerConnection du plugin doit donc être modifiée pour éliminer toute référence à l entité qui validait tous les certificats et ne valider que l autorité choisie. Les lignes : SSLContext sc = SSLContext. getinstance (" SSL "); sc. init ( null, trustallcerts, new java. security. SecureRandom ()); Doivent être modifié en : // --- Creation du certificat a partir du fichier trustedca. pem --- CertificateFactory cf = CertificateFactory. getinstance (" X.509 "); InputStream in = ClassLoader. class. getresourceasstream (" trustedca. pem "); X509Certificate cert =( X509Certificate ) cf. generatecertificate ( in ); in. close (); // --- Ajout de ce certificat au truststore --- KeyStore ks = KeyStore. getinstance (" jks "); ks. load (null, null ); ks. setcertificateentry (" My Certificate Authority ", cert ); TrustManagerFactory tmf = TrustManagerFactory. getinstance (" PKIX "); tmf. init (ks ); // --- Demarrage du systeme SSL avec le truststore modifie --- SSLContext sc = SSLContext. getinstance (" SSL "); sc. init (null, tmf. gettrustmanagers (), null ); Le TrustManager nommé trustallcert peut également être supprimé Placement du serveur collaboratif Decision Sights doit décider où placer le serveur collaboratif par rapport au client et à la plateforme. Il est possible de placer le serveur collaboratif à deux endroits : Chez le client : le client installe et gère son propre serveur collaboratif. Chez Decision Sights : le serveur collaboratif est installé sur une machine possédée (ou louée) par Decision Sights. Installer le serveur collaboratif chez le client semble peu intéressant pour deux raisons majeures. D une part, cela augmente largement la complexité de mise en place du système pour le client qui doit gérer lui même l installation et la maintenance du serveur collaboratif. Cela va totalement à l encontre des avantages apportés pour le Cloud Computing et peut constituer un frein majeur à l adoption du système. D autre part, l hypothèse du canal sûr entre le serveur collaboratif et la plateforme n est plus acceptable, puisque les messages HTTP transitent par internet et son donc capturables aisément. Au niveau des avantages, on notera que les messages entre D-Sight et le serveur collaboratif transitent

90 6.2. Perspectives de déploiement 90 au sein du réseau local de l entreprise et sont donc transmis légèrement plus rapidement. Le délai entre la modification d un paramètre et la mise à jour des écrans des autres intervenants est donc légèrement réduit. Pour le mémorant, le fait que cette solution impose des contraintes supplémentaires pour les clients de Decision Sights est un élément rhédibitoire à son adoption. Si Decision Sights décide de gérer elle même le serveur collaboratif, elle peut le placer à trois endroits : Sur la même machine que celle qui héberge la plateforme. C est dans ces condition que ce mémoire a été réalisé. Sur une machine située sur le même réseau local que la machine hébergeant la plateforme. Sur une machine située dans un autre réseau. Une analyse objective des trois possibilités semble nécessaire. Placer le serveur collaboratif sur la même machine que la plateforme offre plusieurs avantages intéressants. Tout d abord, du point de vue de la sécurité, l hypothèse du canal sûr est respectée. Ensuite, la communication entre le serveur collaboratif et la plateforme est extrêmement rapide puisque les messages sont échangés via de simples accès mémoire et ne font pas appel à des composants réseaux. Enfin, cette communication est gratuite et cela diminue donc les coûts opérationnels pour Decision Sights. Cette option soulève néanmoins des problématiques de montée en charge : le serveur collaboratif et la plateforme partagent les mêmes ressources en terme de mémoire, de temps CPU et d interface réseau. Le serveur collaboratif consomme principalement des ressources CPU (lors de l analyse des messages et de la génération des fichiers.dsi) et maintient une connexion TCP ouverte par client connecté. Le mémorant est d avis que cette solution peut être envisagée de façon sérieuse jusqu à ce que les premiers problèmes de montée en charge n apparaissent. Elle n implique aucune modification du serveur collaboratif puisque c est celle qui a été utilisée durant le développement. Placer le serveur collaboratif sur le même réseau local que la plateforme permet de régler la problématique de montée en charge mise en avant au paragraphe précédent en offrant au serveur collaboratif une machine dédiée. L hypothèse du canal sûr avec la plateforme est conservée. La connexion entre ces deux éléments est par contre moins rapide. La mise en place de cette solution n est pas nécessairement facile si les machines sont louées par Decision Sights chez un hébergeur : celui-ci n offre pas nécessairement d option de ce type (ou à quel prix). Si Decision Sights gère lui-même son parc de serveurs, il s agit probablement de l option la plus intéressante. Placer le serveur collaboratif sur un autre réseau est une option très facile à mettre en place puisqu il suffit d acheter ou de louer une machine supplémentaire n importe où pour y placer le serveur collaboratif. Cette facilité est compensée par le fait que la communication avec la plateforme se fait par internet, qui est un réseau : lent, non fiable et non sécurisé. De plus, Decision Sights va devoir supporter le coût de ces

91 6.2. Perspectives de déploiement 91 communications. Des modifications seront nécessaires au niveau du serveur collaboratif puisque l hypothèse du canal sûr n est plus respectée : le login et le mot de passe de l utilisateur ne peuvent plus circuler en clair. Deux options sont envisageables : Utiliser HTTP Digest Auth, pour transmettre ces informations dans le header en lieu et place de HTTP Basic Auth. Utiliser une connexion de type HTTPS 2 avec la plateforme. L inconvénient majeure de la méthode HTTP Digest Auth est qu elle nécessite de multiplier par deux le nombre de requêtes effectuées vers la plateforme : ce protocole oblige en effet le client à récupérer une valeur (nommée nonce ) qu il peut utiliser pour générer un hash qui servira à l authentifier lors de la seconde requête. Une connexion HTTPS permet de continuer à utiliser HTTP Basic Auth comme moyen d authentification. Cela oblige par contre la plateforme à accepter les connexions SSL (et donc Decision Sights doit acheter un certificat). La modification à apporter au serveur collaboratif est alors relativement légère : dans la classe PlatformConnection, il faut faire appel à un objet HttpsURLconnexion au lieu d utiliser un objet HttpURLconnexion et ajouter la clef publique de l autorité de certification de la plateforme dans le TrustStore du serveur collaboratif. Notons également que l établissement d une connexion HTTPS est plus long que l établissement d une requête HTTP. Le tableau suivant résume les avantages et les inconvénients de chaque possibilité : Position Avantages Inconvénients Chez le client - Communication efficace entre D-Sight - Complexe pour le client et le serveur - Sécurité Sur la machine de la plateforme - Communication entre le serveur et la - Montée en charge plateforme très rapide - Sécurité - Simple à mettre en place Sur le réseau de la plateforme - Communication entre le serveur et la - Option pas toujours disponible plateforme assez rapide si les machines sont louées - Sécurité - Simple à mettre en place Placement indépendant - Souplesse dans le choix du prestataire - Sécurité - Communication entre le serveur et la plateforme lente et peu fiable - Coût de la bande passante 2. Une Connexion HTTPS signifie qu on va faire transiter des données en utilisant le protocole HTTP au travers un socket TCP protégé par SSL

92 6.3. Conclusions Conclusions Ce travail a été utile pour Decision Sights à deux niveaux. D une part, les améliorations apportées à D-Sight vont pouvoir faire l objet d une mise à jour apportant des fonctionnalités très appréciées des utilisateurs. D autre part, le système de travail collaboratif implémenté, et les questions qui ont été soulevées, permettent à l entreprise d envisager le déploiement de ce type de service de façon plus concrète. Le rôle du mémorant n a pas été limité à la simple réalisation d un cahier des charges bien défini. Il a été impliqué dès le début du projet dans des discussions d ordre stratégique afin de déterminer le cadre précis du travail, ses limites et ses buts. Ces décisions ont été guidées par les besoins des utilisateurs et par les objectifs de l entreprise. Le travail de l ingénieur est également d apporter ses connaissances et son expérience technique lors de ces entretiens. Une fois le cahier des charges explicité, le plan général du travail a été établi. Une bonne connaissance théorique des protocoles de communication informatique et de l architecture d une application web a été nécessaire afin d identifier le plus tôt possible les obstacles potentiels et les facilités proposées par l environnement dans lequel se déroulait le mémoire. Les diverses difficultés rencontrées durant les phases d implémentation ont été présentées de façon claire. Pour chacune d entre elles, plusieurs solutions ont été proposées et analysées objectivement. Il s agit d une garantie que le travail réalisé présente de réelles qualités techniques, et d une preuve que l expérience acquise fût enrichissante. Les problématiques traitées ont concerné : l implémentation de design patterns (parfois au coeur même du fonctionnement du logiciel et donc critique pour sa fiabilité ), des questions de performances liée aux protocoles utilisés et les aspects de sécurisation des échanges. Le système s est appuyé autant que possible sur des standards ouverts, principalement le XML, pour permettre une réutilisation aisée des modules réalisés dans de futurs projets. Cette présentation de l implémentation a été suivie par une analyse rétrospective du travail fourni tant sur le plan technique que méthodologique. Elle est complétée par une présentation des diverses possibilités de déploiement du système développé. Cette dernière partie démontre une volonté de produire une application concrète et servira à Decision Sights à établir un premier plan de distribution. Ce mémoire a fait appel à un large panel des compétences requises par le travail d un ingénieur. Il démontre les compétences techniques de l étudiant et sa capacité à intégrer une discussion afin d apporter son expérience et ses connaissances. La réussite du projet prouve que le mémorant a acquis ces compétences et qu il peut les mettre au service d une entreprise.

93 Bibliographie [1] 37Signals. Ruby On Rails Security Guide. security.html. Guide de la sécurité de Ruby on Rails, par les créateurs du framework. Dernière visite le 03 / 05 / [2] 37Signals. Getting Started with Rails. started.html#the-mvc-architecture, Introduction à Ruby on Rails, par les créateurs du framework. Dernière visite le 02 / 05 / [3] Atypicom. Le phénomène de longue traîne : un modèle de la Net économie mis en avant. internationale/le-phenomene-de-longue-traine-un-modele-de-la-neteconomie-mis-en-avant html, Dernière visite le 27 / 04 / [4] J.P. Brans and B. Mareschal. PROMETHEE-GAIA. Une Méthodologie d Aide à la Décision en Présence de Critères Multiples. Ellipses, Paris, France, [5] E. Gamma, R. Helm, R. E. Johnson, and J. Vlissides. Design Patterns : Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, MA, [6] Network Working Group. UUIDs and GUIDs. info/draft-leach-uuids-guids-01.txt, Dernière visite le 03 / 02 / [7] Internet Engineering Task Force (IETF). Basic authentication scheme. tools.ietf.org/html/rfc1945#section-11.1, Documentation officielle de l authentification basique en HTTP. Dernière visite le 03 / 05 / [8] Internet Engineering Task Force (IETF). Http state management mechanism Documentation officielle des Cookies. Dernière visite le 03 / 05 / [9] Internet Engineering Task Force (IETF). Hypertext Transfer Protocol HTTP/ Documentation officielle du protocole HTTP. Dernière visite le 30 / 04 / [10] Internet Engineering Task Force (IETF). The transport layer security (tls) protocol version Documentation officielle du protocole TLS 1.2 (= SSL 3.3). Dernière visite le 03 / 05 / [11] J. Jenkov. What is Dependency Injection? dependency-injection/index.html, Dernière visite le 27 / 04 /

94 Bibliographie 94 [12] Savas Parastatidis Jim Webber and Ian Robinson. How to GET a cup of coffee Dernière visite le 30 / 04 / [13] C. Larman. Applying UML and Patterns An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd ed.). New Jersey : Prentice Hall, [14] N. Lawson. Dangers of amateur cryptography. 18/dangers-of-amateur-cryptography/, Dernière visite le 03 / 05 / [15] R. Matthews and F. Stones. Coincidences : the truth is out there. TEACHING STATISTICS, 20(1) :17 19, [16] T. Nitot. Le web ouvert est important comme la démocratie dans la politique Dernière visite le 20 / 04 / [17] OrionServer.com. Setting up SSL and HTTPS. docs/ssl.html#keytool, Dernière visite le 09 / 05 / [18] Luke Reiter. Tracking Melissa s alter egos. tracking-melissas-alter-egos/101974, Dernière visite le 03 / 02 / [19] A. Robert. The Cross-Site Request Forgery (CSRF/XSRF) FAQ. cgisecurity.com/csrf-faq.html, Dernière visite le 03 / 05 / [20] Stefan Tilkov. A Brief Introduction to REST. rest-introduction, Dernière visite le 30 / 04 / [21] World Wide Web Consortium (W3C). SOAP. REC-soap12-part /, Documentation officielle de SOAP. Dernière visiste le 13 / 04 / [22] Wikipedia. Command pattern. pattern. L article Wikipedia sur le design pattern Command est particulièrement complet. Il comporte une présentation théorique ainsi qu un exemple d implémentation en Java. Dernière visiste le 10 / 04 / 2011.