MISE EN PLACE D UNE ARCHITECTURE DE TYPE SOA POUR UN

Transcription

1 Université de Fribourg, Suisse Département d'informatique Bachelor en informatique MISE EN PLACE D UNE ARCHITECTURE DE TYPE SOA POUR UN PROJET INFORMATIQUE Travail de bachelor Büschi Mathias Chemin des écoliers Etoy [email protected] Dr. Stefan Hüsemann Janvier 2011

2 ABSTRACT La recherche de solutions visant à faciliter l intégration entre de nombreuses applications hétérogènes est de nos jours nécessaires dans un monde où la complexité des systèmes d informations ne cesse de croître. L architecture orientée services (SOA) est l un des modèles intéressants permettant de faire face à cette problématique. Ce travail vise dans une première partie à mettre en exergue les concepts qui entourent la SOA en y apportant une description suffisante afin d aborder par la suite les aspects architecturaux de la SOA. Le mapping relationnel-objet, permettant de relier le modèle relationnel d une base de données à un modèle objet, sera abordé sous un angle théorique et pratique en vue de son intégration dans la SOA. s Enfin les connaissances assimilées dans la première partie seront utilisées pour élaborer une architecture SOA dans le cadre de l association Börsenspiel der Schweizer Universitäten (BSU). L implémentation d une partie de l architecture sera effectuée. Il s agira de la partie de calcul des portefeuilles des joueurs pour le jeu Portfolio Management Simulation (PMS). Une des volontés de ce travail sera d amener au système d informations (SI) de la BSU une capacité à s aligner plus facilement avec les processus de l association. MOTS-CLÉS BSU, PMS, association, bourse, architecture, SOA, système, information, portefeuille, UML,.NET, persistance, mapping, relationnel-objet

3 Table des matières Table des matières 1 INTRODUCTION Problématique Objectifs Démarche utilisée ARCHITECTURE DE SI Définition et analyse d une architecture du système d information (SI) Aperçu de l architecture de type SOA Définition d un modèle de référence SOA et conception d une architecture de référence SOA Utilité d une architecture structurée et planifiée PRÉSENTATION DU MAPPING RELATIONNEL-OBJET Définition Rôle dans l architecture de type SOA Outils de mapping relationnel-objet existants STRUCTURE GÉNÉRALE DE L ARCHITECTURE DE RÉFÉRENCE DE LA BSU Aspects à prendre en compte Vue des différentes couches Roadmap vers l architecture de référence SOA PARTIE PRATIQUE Présentation du jeu PMS et de son environnement Analyse actuelle de la structure Modifications de la structure envisagées Architecture cible... 26

4 Table des matières Conséquences et avantages de la nouvelle architecture Services métiers Définitions de cas d utilisations et règles métiers pour le module PMS Core Cas d utilisations Règles métiers Choix des composants tiers pour un développement du projet sous.net LINQ to SQL Windows Communication Framework Logging ASP.NET et Web Forms jquery Implémentation PMS Core PMS Administration Déploiement Tests RÉSULTATS PRATIQUES OBTENUS ET ÉVALUATION Présentation de l interface PMS Administration Présentation de PMS Core Avantages et désavantages de la nouvelle architecture Différences avec les attentes théoriques CONCLUSION Conclusion finale Conclusions personnelles... 61

5 Table des matières 8 RESSOURCES ANNEXE A ANNEXE B... 67

6 Table des illustrations Table des illustrations FIGURE 1 : BÉNÉFICES D UNE SOA [MARKS/BELL 2006, P.134] FIGURE 2: ARCHITECTURE DE RÉFÉRENCE SOA [OASIS 2006] FIGURE 3 : APPLICATION N-TIER COUCHE D ACCÈS AUX DONNÉES [ROS 2003] FIGURE 4 : ARCHITECTURE DE RÉFÉRENCE DE L ENTREPRISE IPT [IPT 2010] FIGURE 5 : LES 6 DOMAINES DÉFINIS PAR BEA [BEA 2005] FIGURE 6 : ARCHITECTURE DE RÉFÉRENCE ÉTABLIE POUR PMS TOP FIGURE 7 : NOUVELLE ARCHITECTURE POUR LE JEU PMS FIGURE 8 : TYPES DE SERVICES DANS LA NOUVELLE ARCHITECTURE FIGURE 9 : CAS D UTILISATION POUR LE MODULE PMS CORE FIGURE 10: INTÉGRATION DES TECHNOLOGIES DANS L ARCHITECTURE FIGURE 11 : LES DIFFÉRENTES IMPLÉMENTATIONS DE LINQ FIGURE 12: RÔLE DE LINQ TO SQL DANS LA NOUVELLE ARCHITECTURE FIGURE 13 : EXEMPLE DE L APPEL DE L OPÉRATION NEXTPERIOD SUR LE SERVICE PMS CORE FIGURE 14 : STRUCTURE ET FONCTIONNEMENT D UNE WEB FORM FIGURE 15 : MÉCHANISME DE PULL FIGURE 16 : STRUCTURE DU PROJET PMS CORE FIGURE 17: COMPOSANTS DU ENDPOINT FIGURE 18 : INTERFACE UTILISATEUR PMS ADMINISTRATION FIGURE 19: ENVIRONNEMENT BSU ACTUEL FIGURE 20 : LA VUE PÉRIODES FIGURE 21 : LA VUE RÉPARATION DE COURS FIGURE 22 : LA VUE LOGS... 57

7 Abréviations Abréviations BSU PMS SOA MVC SOAP XML HTTP WSDL DAO POO CRUD AJAX TCP JVM BLL DAL IT UML DOM URL BR SQL WCF LINQ Börsenspiel der Schweizer Universitäten Portfolio Management Simulation Service Oriented Architecture Model- View - Controller Simple Object Access Protocol Extensible Markup Language Hypertext Transfer Protocol Web Services Description Language Data Access Object Programmation orienté objets Create-read-update-delete Asynchronous JavaScript and XML Transmission Control Protocol Java Virtual Machine Business Logic Layer Data Access Layer Information Technology Unified Modeling Language Document Object Model Uniform Resource Locator Business Rule Structured Query Language Windows Communication Framework Language Integrated Query

8 Introduction 6 1 Introduction Problématique Le présent travail va trouver une utilité dans le cadre du jeu Portfolio Management Simulation (PMS) de l association Börsenspiel der Schweizer Universitäten (BSU). Il s agit d une simulation boursière destinée aux étudiants des hautes écoles suisses. L organisation de ce jeu repose sur du travail de marketing, de finances et d informatique. L association BSU et formée d une équipe d étudiants d environ 8 personnes qui fournissent leurs compétences dans les domaines cités précédemment. Les interactions entre ces domaines sont nombreuses. L équipe de gestion par exemple définit les nouveautés du jeu que l équipe d informatique doit implémenter. L équipe de marketing demande des statistiques et des changements pour rendre le site plus populaire. L ensemble de l infrastructure informatique de la BSU est ainsi très sollicité. Outre la maintenance, il faut également garantir la pérennité du jeu chaque année en offrant de nouvelles fonctionnalités, en améliorant le support aux joueurs et en offrant une qualité grandissante de jeu. Pour ce faire, l amélioration du système informatique régissant le jeu et l administration qui y est liée est un besoin non négligeable. Cette amélioration passe par la mise en place d une nouvelle architecture. L accès aux données doit par ailleurs être l un des points-clés de l architecture. L architecture Service Oriented Architecture (SOA) ainsi que le mapping relationnel-objet font parler d eux depuis quelques années. Ce travail souhaite vérifier la possibilité d une intégration de ces principes dans le système informatique de la BSU en vue de définir une nouvelle architecture Objectifs Le présent travail s articule autour d une partie théorique et d une partie pratique. Il aura pour objectif d amener des réponses aux questions scientifiques suivantes d après ces parties : Partie théorique - Qu entend-ton par une architecture du système d information (SI)? - Quelle est l utilité d une architecture structurée et planifiée?

9 Introduction 7 - Quels sont les apports de la SOA? - Comment relier le code et les données dans une application? Partie pratique - Quelles sont les exigences pour le calcul du jeu PMS? - Quelle est l architecture du système PMS? - Comment intégrer le mapping relationnel-objet avec la technologie.net dans le cadre d un projet? - Qu est-ce que la nouvelle architecture apporte de plus par rapport à l ancienne? Ce travail veut également proposer une nouvelle architecture au jeu PMS. La recherche et la mise en place de cette nouvelle architecture permettra de répondre aux questions précédentes. Une partie de l implémentation de cette architecture sera également réalisée dans le cadre de ce travail en développant le module PMS Core. Ce module sert à calculer et à mettre à jour les portefeuilles des joueurs à l issue de chaque journée de jeu. Le développement et l établissement de l architecture de référence s axera autour d une architecture de type SOA. Cette architecture s oriente en général vers les grandes entreprises en raison de son coût et de sa complexité. Mais ce travail veut également démontrer qu en adoptant certains principes de bases de ce type d architecture, il peut en résulter un système stable et évolutif. L implémentation du module et de la nouvelle architecture s appuiera sur les technologies.net déjà utilisés dans le jeu ainsi que sur de nouvelles technologies qui seront expliquées plus loin dans ce travail. La première partie de ce travail définit la notion d architecture de système d information. Le type SOA sera particulièrement analysé et mènera à la définition et à l étude de la mise en place d une architecture de référence SOA. Reprenant ces points, l utilité d une architecture structurée et planifiée sera démontrée. La deuxième partie présente le mapping relationnel-objet, son utilité dans la nouvelle architecture ainsi que la technologie qui sera choisie parmi les nombreuses à disposition. La troisième partie sera dédiée à la modélisation de l architecture cible de la BSU et enfin la dernière partie entrera au cœur de l implémentation de PMS Core.

10 Introduction Démarche utilisée La lecture et l étude de textes pertinents liés à ces thèmes fourniront une base de connaissances sur laquelle s appuyer. Pour répondre aux questions formulées dans le chapitre précédent, une démarche empirique sera adoptée mais appuyée par des méthodes déductives. L idée est de partir de connaissances générales pour développer des connaissances plus spécifiques en s aidant d expérimentations.

11 Architecture de SI 9 2 Architecture de SI Ce chapitre va au travers de la littérature et une réflexion personnelle essayer de répondre aux questions suivantes : - Qu entend-ton par une architecture du système d information (SI)? - Quelle est l utilité d une architecture structurée et planifiée? - Quelles sont les apports de l architecture orientée services (SOA)? - Comment relier le code et les données dans une application? La recherche d une réponse à ces questions va permettre de poser une base théorique indispensable pour la compréhension et l élaboration de la future architecture du jeu Portfolio Management Simulation (PMS). 2.1 Définition et analyse d une architecture du système d information (SI) Pour aboutir à une définition d une architecture SI, il faut au préalable définir le terme d architecture ainsi que la notion de système d information. Une architecture de manière générale peut être définie de la manière suivante : L architecture est l ensemble de décisions significatives à propos de l organisation d un système informatique. [Bass al. 2003] La définition d un système d information est la suivante : Un système d information est un ensemble organisé de ressources (matériel, logiciel, données et procédures) qui permet de regrouper, classifier, de traiter et de diffuser de l information sur un phénomène donné. [Wikipedia 2010] Une architecture de système d information doit donc définir des afin d implémenter et de comprendre un système qui pour tâche de gérer l information de la manière la plus flexible possible. Les motivations pouvant mener à adopter une telle architecture sont les suivantes : - Simplification des processus métiers grâce à une découverte et une élimination de la redondance dans les processus métiers. - Augmentation des capacités d intégration de l entreprise grâce à une meilleure consolidation et transmission des données. L architecture pousse à adopter des standards pour le partage des données.

12 Architecture de SI 10 - Migration plus rapide grâce à une structure simplifiée avec absence de redondance. Dans le cas de la BSU, le système d information doit remplir plusieurs fonctions : - Collecter des informations o Exemples : cours des titres, paiements des joueurs, transactions effectuées par les joueurs,...) - Mémoriser les informations et également mémoriser les informations passées o Exemples : stockage dans la base de données des transactions des joueurs, stockage dans la base de données des cours historiques - Traiter les informations o Exemples : calcul des portefeuilles des joueurs, mise à jour dans la base de données, générer des listes de résultats - Transmettre les informations o Exemples : mise à disposition des résultats aux joueurs, informations aux gestionnaires du jeu de l état des paiements Le système d information de la BSU remplit donc déjà bon nombre des fonctions que l on retrouve dans la majorité des systèmes d informations. L architecture du système d information de la BSU n est pas encore clairement établie. Il en résulte ainsi des difficultés d évolution, des problèmes de qualité dans les différentes fonctions ainsi qu une complexité évitable malgré un jeu que l on peut qualifier de fonctionnel. Le prochain point vise à découvrir un type d architecture de système d information qui peut permettre de résoudre ces points négatifs du système actuel. 2.2 Aperçu de l architecture de type SOA Le terme SOA signifie architecture orienté services. La définition suivante peut être donnée : SOA est une architecture métier conceptuel où les fonctionnalités métiers, ou la logique de l application, est mise à disposition aux utilisateurs SOA ou aux utilisateurs, en tant que services réutilisables et partagés dans un environnement informatique. Les services dans une SOA sont les modules d une fonctionnalité de l application avec des interfaces exposées et qui sont invoquées par messages. [Marks/Bell 2006]

13 Architecture de SI 11 Ce type d architecture suit des principes de modélisation modernes. Quelqu un de ces principes sont les suivants : - L architecture doit reposer sur le concept d offre et de demande de services. - Les composants doivent pouvoir communiquer entre eux de manière asynchrone et doivent être couplés faiblement. - L architecture doit être découpée en plusieurs couches o Note : L architecture n-couches la plus connue est probablement la modèle-vue-contrôleur (MVC) où l on trouve les couches présentation, métier et données. Ces principes doivent permettre de rendre le système flexible pour s adapter à la stratégie de la société. Cette flexibilité découle du fait que les services sont réutilisables grâce à une interface standardisé, une facilité d intégration accrue pour une complexité plus faible. Outre sa flexibilité, les bénéfices de la SOA peuvent être nombreux comme le montre la Figure 1. L agilité métier permet à la SOA de s adapter rapidement à son environnement métier en maintenant des services s alignant aux demandes clientes. Une réduction des coûts est atteinte par une meilleure réutilisation des services existants ainsi qu une meilleure maintenance grâce à une consolidation des applications par des services réutilisables. Cette réduction des coûts en conjonction avec une satisfaction du client amène l entreprise à accroitre ses revenues. Les fusions et acquisitions (M&A Mergers and Acquisitions) se passent plus facilement grâce à une intégration facilitée par la SOA. Agilité Réduction Accroissement Flexibilité métier des coûts revenues IT M&A plus rapide Satisfaction du client Plus rapidement vers le marché Plus de productivité Réutilisation des services Figure 1 : Bénéfices d une SOA [Marks/Bell 2006, p.134]

14 Architecture de SI 12 L application composée résultant de l assemblage de ces services est mise à disposition des utilisateurs. Dans une architecture SOA, les services se doivent de disposer d une interface standard pour accéder aux fonctionnalités logicielles qu elles proposent. L utilisation de services web est donc fréquente. Un service web possède les caractéristiques suivantes : - Couplage faible grâce à une communication par message - L interface du service est standard et auto-descriptive Ces propriétés font que les services web peuvent interagir entre eux et fournissent une description de leurs fonctionnalités et la façon d y accéder. Les services web les plus utilisées sont de type Simple Object Access Protocol (SOAP) over HTTP. La spécification SOAP définit : - Les règles de traitement du message SOAP - Les fonctionnalités et modules SOAP - Les règles qui définissent une liaison à un sous-protocole utilisé pour échanger les messages SOAP entre les nœuds SOAP - La structure du message SOAP Le standard Extensible Markup Language (XML) est utilisé pour définir ces propriétés de SOAP. Plusieurs méthodes de transport existent mais la plus utilisée est évidemment le protocole HTTP (ou HTTPS). La solution SOAP sera la technologie retenue dans ce travail toutefois d autres alternatives intéressantes existent tels que le très connu Common Request Object Broker Architecture (CORBA). Le standard Web Service Description Language (WSDL) est fortement associé aux services web et notamment au standard SOAP. Il confère au service son côté autodescriptif. L association de ces standards a donné lieu aux services web WS-*, appelés aussi services de deuxième génération. On les définit selon le type d architecture SOA. La supervision des standards SOAP et WSDL est la charge du W3C. L organisation WS-I publie entre autre des profils afin d assurer et d améliorer l interopérabilité entre les développements de services web.

15 Architecture de SI 13 Le standard Universal Description Discovery and Integration (UDDI), annuaire de services basés sur XML a également une place importante dans la SOA. Publié par OASIS, il permet la découverte des services web. Les informations données permettent de connaître l adresse à utiliser pour atteindre le service, les fonctionnalités offertes, les responsables du service et d autres informations utiles. Windows serveur inclus par défaut un serveur UDDI mais ils existent des alternatives commerciales et open source notamment Apache JUDDI, BEA Aqualogic Service Registry, Novell UDDI Server, 2.3 Définition d un modèle de référence SOA et conception d une architecture de référence SOA Le modèle de référence SOA a été spécifié par l OASIS dans sa publication Reference Model for Service Oriented Architecture 1.0 [OASIS 2006]. Cette organisation pense que la grande attention portée aux SOA a mené à trop de définitions divergentes. Le but est donc de fournir un modèle générique de modélisation d une SOA. Ce modèle de référence est donc une abstraction de toutes les SOA visant à donner des définitions communes à toutes les SOA. Ce modèle de référence fait abstraction des technologies et des implémentations. Figure 2: Architecture de référence SOA [OASIS 2006] L architecture de référence SOA (cf. Figure 2) est une spécification fonctionnelle avec laquelle on peut implémenter une SOA. L architecture de référence va donc se baser sur les définitions du modèle de référence SOA. L architecture de référence peut également

16 Architecture de SI 14 être définie comme l architecture cible idéale à atteindre. Elle permettra ainsi de définir une roadmap partant de l architecture actuelle à la future architecture. L OpenGroup fournit un blueprint pour la conception et l évaluation de SOA dans sa publication SOA Reference Architecture [The Open Group 2009]. L élaboration d une architecture de référence SOA doit idéalement se faire en suivant les standards proposés auparavant. Le modèle de référence proposé par l OpenGroup peut s adapter à n importe quel type de société. Il est ainsi possible par raison de coûts de supprimer une couche. 2.4 Utilité d une architecture structurée et planifiée De nos jours, la stratégie d une entreprise est de plus en plus complexe et est sujette à de nombreux changements. Ces changements peuvent être dus à un repositionnement face aux concurrents, à une volonté de réduction des coûts, et bien d autres facteurs amenant l entreprise à revoir sa stratégie. Le système d information doit réagir face à ces changements en s adaptant à la stratégie. Les coûts et le temps nécessaires à cette adaptation sont des facteurs cruciaux pour l entreprise. Dès lors la présence d une architecture structurée et planifiée dans le système d information de l entreprise est importante pour mener à bien ces adaptations. Une architecture structurée et planifiée peut amener les avantages suivants : - Système flexible s adaptant à l environnement métier - Gestion du système d information plus efficace grâce à une structure permettant une meilleure allocation des ressources humaines et matérielles. - Augmentation de la consistance des informations grâce à une représentation standardisée de l information - Intégration et partage de l information facilitée

17 Présentation du mapping relationnel-objet 15 3 Présentation du mapping relationnel-objet Par une recherche théorique, ce chapitre se veut de répondre aux questions suivantes : - Qu apporte le mapping relationnel-objet? 3.1 Définition Le mapping relationnel-objet est une technique permettant de transformer d un modèle à l autre les modèles objets et relationnels. Pour cela une correspondance est établi entre le modèle relationnel et le modèle objet, d où le terme de mapping. Les bases de données ne peuvent comporter que des types scalaires bien définis et des chaînes de caractères. Un type scalaire est un type de variable scalaire, une variable scalaire étant une variable qui ne peut contenir qu une valeur atomique. Les types les plus connues sont par exemple String, Char, Integer, Float ou encore Double. Cette structure n est malheureusement pas idéale lorsqu il y a utilisation de programmation orienté objet. En effet les objets contiennent souvent des valeurs non scalaires. Le programmeur doit donc effectuer de laborieuses transformations afin de sauver ses objets dans la base de données. Ces transformations peuvent être en parties automatisées grâce au mapping relationnelobjet, le programmeur se restreignant à configurer les correspondances. Ainsi le programmeur peut lire, modifier et créer des objets sans se soucier de la base de données. Il va également de soi que le code nécessaire à la gestion des données se réduit drastiquement et la complexité avec. 3.2 Rôle dans l architecture de type SOA Dans une architecture n-couche, par exemple de type SOA, une couche importante est celle de l accès aux données (cf. Figure 3). Cette couche doit offrir la possibilité de manipuler d une manière flexible les enregistrements de la base de données. Cette couche comportera en général une classe, classe dite Data Access Object (DAO), correspondante à chaque table de la base de données. Des méthodes sont présentes créer, lire, modifier et supprimer un enregistrement. On parle d interface CRUD (Create, Read, Update, Delete).

18 Présentation du mapping relationnel-objet 16 Figure 3 : Application n-tier Couche d accès aux données [Ros 2003] Le mapping relationnel-objet n est pas directement lié aux SOA. Cette couche d accès aux données peut très bien se passer de cette technologie. Mais comme expliqué auparavant, cette technologie permet de diminuer le code et la complexité, le programmeur ne traitant que des objets. Elle trouve donc un rôle apportant des gains de temps et de coûts. Par ailleurs, ils existent des outils de persistance offrant la mapping relationnel-objet. Ils ont l avantage de proposer également un fort découplage avec la base de données en plus des nombreuses fonctionnalités offertes tels que la mise en cache, la gestion de la concurrence, etc. Ce découplage rentre dans le concept de la SOA. 3.3 Outils de mapping relationnel-objet existants De nombreux outils existent sur le marché en version open source ou commerciale. Ces outils proposent des fonctionnalités communes mais aussi des fonctionnalités propres à chacun de ces outils. Les fonctionnalités suivantes sont en général demandées par une majorité de programmeurs : - Utilisation de l héritage et du polymorphisme : Il faut profiter de la POO pour donner une structure aux entités (ex : hiérarchie) - Gérer les transactions, agrégations et groupement : Présentes dans SQL, elles se doivent de l être également dans le mapping relationnel-objet. - Gérer les différents types de relation : Une relation 1-n sera ainsi représentée dans une classe DAO par un tableau. Ces fonctionnalités apparaissent comme indispensables pour que le mapping relationnel-objet n apporte pas plus de désavantages qu avantages. De nombreuses

19 Présentation du mapping relationnel-objet 17 autres fonctionnalités sont en général fournies. Les critères d adoption d un outil dépendront du besoin de l architecture. Pour le cas de la SOA, il est ainsi important de considérer d autres fonctionnalités : - Les objets doivent pouvoir être convertis sous forme de «message». La sérialisation le permet en transformant l objet sous forme de chaine de caractère dans un format standard. - Les objets doivent pouvoir être stockés sous différents formats donc différents support de stockage (SQL, XML, ) Parmi de bons outils de mapping relationnel-objet pour.net, on peut citer : - LINQ to SQL - NHibernate - ADO.NET Entity Framework - DataObjects.NET - ObjectMapper.NET Les technologies Microsoft, LINQ to SQL et ADO.NET Entity Framework, permet d offrir rapidement un accès aux données aux applications. ADO.NET Entity Framework a toutefois l avantage de ne pas être dépendant du schéma relationnel en programmant son propre modèle conceptuel. Il est possible en quelque sorte de définir plus librement le mapping qu avec la technologie LINQ to SQL. NHibernate est un produit open source sous licence LGPL (Lesser GNU Public Licence). Il offre pratiquement autant de fonctionnalités que ADO.NET Entity Framework et constitue un bon choix pour les programmeurs ayant déjà connaissance de sa version en Java, Hibernate. DataObjects.NET et ObjectMapper.NET sont des solutions commerciales qui mettent en avant une performance accrue ainsi qu une approche plus programmatique que leurs concurrents gratuits pour une gestion du mapping relationnel-objet plus avancée.

20 Structure générale de l architecture de référence de la BSU 18 4 Structure générale de l architecture de référence de la BSU 4.1 Aspects à prendre en compte La définition d une architecture de référence (cf. chapitre 2.3) pour la BSU devra prendre en compte les ressources et du temps à disposition pour mettre en place la nouvelle architecture. L association disposant de moyens faibles et de temps limité, il est primordial d adopter une architecture qui pourra être maintenue à long terme. La SOA devra apporter : - Flexibilité et rapidité quant à l évolution du jeu PMS - Administration de la BSU facilitée. Intégration de nouveau modules d administration et modifications des actuelles dans les meilleurs délais. Ces objectifs devront être remplis en choisissant une architecture de référence respectant au mieux le modèle de référence SOA (cf. chapitre 2.3). 4.2 Vue des différentes couches De nombreuses architectures de références existent déjà. L architecture qui a été choisie dans le cadre de ce travail (cf. Figure 4) a été élaborée par l entreprise IPT [ipt 2010] et proposé par Mr. Stefan Hüsemann. Figure 4 : Architecture de référence de l entreprise IPT [ipt 2010]

21 Structure générale de l architecture de référence de la BSU 19 La couche donnée est composée de base de données relationnelle et de datawarehouses qui contiennent les données nécessaires aux exigences métiers de l entreprise. La couche d accès aux données permet d accéder à ces données et à leur offrir un moyen d accès standard et unique. Cet accès peut soit être réutilisable grâce à l utilisation de services de données ou soit être privé si le besoin en est. La logique métier est contenue dans la couche logique métier. Il s agit d une couche importante permettant de séparer la logique des données et de la couche présentation. Les composants de cette couche sont les suivants : - Services métiers : Ils fournissent des éléments logiques réutilisables - Logique métier privée : Il s agit d implémentation de logique spécifique à une application - Business Rule Engine : Ce composant permet de modifier de la logique métier. Il exécute des règles métiers externalisée du code. Dans la couche intégration, le composant ESB (Entreprise Service Bus) est un intergiciel permettant l intégration d applications hétérogènes. Pour offrir des processus réels à la couche présentation, il faut assembler certains services et les intégrer. La couche d intégration s en charge avec un composant appelé moteur d orchestration. Ce composant utilise en général le langage BPEL (Business Process Execution Language) défini comme standard et utilisant un langage dérivé du XML. Finalement la couche présentation offre une interface aux utilisateurs sous la forme d une application web ou d un portail via un serveur web. La couche client définit les applications utilisées pour accéder à la couche de présentation telle qu un navigateur web. Le client peut aussi utiliser une application client riche. Il s agit d applications traditionnelles qui se connecteront en général directement aux services métiers 4.3 Roadmap vers l architecture de référence SOA La roadmap SOA est un plan unique du système d information de l entreprise qui est défini itérativement et incrémentalement au fur et à mesure de l avancement. La maturité de la roadmap doit évoluer conjointement avec la maturité de la SOA. Par ailleurs elle doit également tenir compte de l environnement global en distinguant les 6

22 Structure générale de l architecture de référence de la BSU 20 domaines liés entre eux (cf. Figure 5 : Les 6 domaines définis par BEA [BEA 2005]). La roadmap définit une ligne du temps transparent et flexible pour accomplir les objectifs de la SOA. Des tests de qualités sont également effectués à chaque étape. Figure 5 : Les 6 domaines définis par BEA [BEA 2005] Construction de la roadmap selon les étapes définies dans le livre blanc de BEA Systems [BEA 2005] : 1. Planification de la SOA La SOA est organisée et définie. Les limites et l environnement sont établis. La SOA est également justifiée et sa capacité à remplir les besoins actuelles et futurs de l entreprise est démontrée. 2. Evaluation de la maturité de la SOA Identification des fonctionnalités offertes par la SOA. Analyse de l état actuel de la SOA par l équipe actuel. 3. Vision future de la SOA Définition en équipe de l état futur désiré de la SOA. 4. Définition de la roadmap SOA En se basant sur les 3 phases précédentes, une analyse des objectifs de la SOA est accomplie et des timelines sont définies pour y parvenir. Les objectifs à court terme sont détaillées et les objectifs à plus long terme sont décrits plus

23 Structure générale de l architecture de référence de la BSU 21 sommairement afin qu ils puissent encore s adapter à l expérience qui sera acquise par la suite. Découverte Analyse état actuel Définition état futur Roadmap Ces phases peuvent être appliquées à la BSU de la manière suivante : Découverte Le kick-off de la BSU permet chaque année de réunir les parties prenantes de l informatique et de la gestion. Il permet de comprendre la vision informatique, l état actuel et les besoins. Ce rendez-vous annuel permet d augmenter progressivement le degré de maturité de l architecture du système d information. Cette phase de la SOA peut donc être mise en place facilement. Il s agira ainsi de : - Définir les compétences de la SOA - Identifier les limites et la l alignement avec de nouvelles idées IT. - Montrer l alignement avec d actuelles et futures idées de gestion - Démontrer l utilité de la SOA Analyse de l état actuel A ce stade, les moyens et services de la BSU pouvant servir à la SOA doivent être identifiés. Il peut s agir de projets existant pouvant servir de base à la SOA. Un exemple sommaire de l état actuel de la BSU en départageant les domaines pourrait être le suivant :

24 Structure générale de l architecture de référence de la BSU 22 Stratégie et processus métier Stratégies : - Objectif d atteinte d un nombre de joueurs minimum pour la session de jeu - Offre de nouvelles fonctionnalités pour maintenir l attractivité du jeu Processus métiers : Définition du nouveau jeu Publicité : mailing, affiches, agents Configuration du jeu Gestion des paiements des joueurs Etablissement des gagnants et récompense Sondage Architecture La BSU utilise pour certains de ces projets une architecture MVC. Le standard XML est déjà utilisé dans plusieurs projets. Coûts Les coûts inhérents au système d information actuel de la BSU est quasi nul. Toutefois grâce au sponsoring la BSU possède des moyens qui normalement seraient sujets à des coûts tels que les machines virtuelles par exemple. Blocs de constructions Technologies :.NET, SQL, XML Services : Important de cours, calcul de jeu, configuration du jeu Outils : Datawarehouse, outils de sauvegarde Processus : Mise en place d une nouvelle session de jeu, calcul des portefeuilles, clôture du jeu Projets et applications Applications existantes : calcul de jeu, PMS Quotes, PMS Configuration Projets prévus : PMS Payments, PMS Core, PMS Administration

25 Structure générale de l architecture de référence de la BSU 23 Organisation et gouvernance Organisation et hiérarchie actuelle de la BSU : Vorstand IT Gestion Définition de l état futur Mise en place des modules PMS Core et PMS Administration pour la prochaine session de jeu. Intégration des modules PMS Importation et Configuration à la SOA à moyen terme. Justification par le fait que toutes ces applications sont des applications composées à partir de services communs. Ces applications correspondent également aux processus métiers de la BSU. Définition des services partagées : récupération des infos d un joueur, récupération du classement d un joueur, modification d un portefeuille, Définition de la roadmap SOA Objectifs court-terme : Administration Définition d une architecture SOA Implémentation PMS Core et PMS Objectifs moyen-terme : PMS Configuration Intégration des modules PMS Importation et

26 Partie pratique 24 5 Partie pratique Les réponses aux questions de la partie pratiques seront amenées dans ce chapitre. Elles se fonderont sur les apports théoriques des chapitres précédents ainsi que par l expérimentation découlant de l implémentation de la nouvelle architecture. Les questions sont les suivantes : - Quelles sont les exigences pour le calcul du jeu PMS? - Quelle est l architecture du système PMS? - Comment intégrer le mapping relationnel-objet avec la technologie.net dans le cadre d un projet? - Qu est-ce que la nouvelle architecture apporte de plus par rapport à l ancienne? 5.1 Présentation du jeu PMS et de son environnement L association BSU a organisé depuis sa création en 1991 plusieurs jeux boursiers pour les étudiants des universités et hautes écoles suisses. Actuellement l association ne propose plus que le jeu PMS (Portfolio Management Simulation). Ce jeu permet aux participants de gérer sur une période définie un portefeuille virtuel. Les titres négociables sont choisis d avance et sont de nature diversifiée : actions, obligations, options, devises,.. Pour participer les membres BSU paient une cotisation annuelle. Pour gérer tous ces aspects du jeu de manière efficace, il est important pour les membres du comité de la BSU d utiliser un système d information adéquat. Une restructuration du système avait été prévue dans le cadre du projet PMS Top. L idée était de décomposer chaque partie du jeu en sous-projet et ensuite d interconnecter le tout. Sous-projets de PMS Top : PMS Requirements and Test : Définition des exigences, Modélisation du système PMS, documentation PMS Administration : Gestion du jeu PMS. Ce module rassemble PMS Configuration et PMS Core PMS Configuration : Gestion des paramètres du jeu, des membres et des différentes instances du jeu

27 Partie pratique 25 PMS Core : Calcul des portefeuilles et classement. Modification des cours manuellement. PMS Quotes : Importation des cours depuis une source externe et écriture dans la base de données PMS Environment : Mise en place d un environnement de développement, test et production PMS Web : Site Internet faisant office d interface de gestion des portefeuilles pour les membres BSU. Actuellement certains projets ont été menés à bien, d autres sont en cours de développement et d autres en suspens. Le projet PMS a donné plus de transparence au système d information, de nouvelles fonctionnalités et une meilleure qualité de jeu. Une architecture de référence a également été définie dans le cadre du projet PMS Top (cf. Figure 6. Figure 6 : Architecture de référence établie pour PMS Top Cette architecture de référence représente bien l état actuel ce qui signifie que le projet PMS Top a bien atteint son objectif au niveau architectural.

28 Partie pratique Analyse actuelle de la structure Le projet PMS Top a notamment été lancé pour faire face à différents problèmes techniques : - Difficulté de configuration de jeu - Lenteur de calcul des portefeuilles - Problèmes d importation - Vieilles technologies présentes - Pas de gestion commune des multiples instances du jeu - Pas d environnement de développement et de test - Gestion des connexions des membres sur le site désuète - Manque d innovation Si de nombreux problèmes sont résolus, d autres sont encore présents tels que la lenteur du calcul des portefeuilles, la présence de veilles technologies et le manque d innovation. Il est donc intéressant de se pencher sur les causes qui ont rendus difficile la résolution de ces problèmes. Au sein de l association BSU, une moyenne de cinq programmeurs bénévoles sont en charge de relever les défis rencontrés par l évolution du jeu PMS chaque année. Les ressources humaines sont donc moindres sachant que l équipe IT ne peut travailler que occasionnellement pour le jeu PMS. Chaque module possède entre autre ses spécificités d implémentation et dès lors il est difficile de modifier un module créé par un autre développeur. L absence de code partagé au sein de ces projets rend la tâche du programmeur compliqué, ce dernier n ayant aucune base sur laquelle s appuyer. 5.3 Modifications de la structure envisagées Afin d amener une solution aux problèmes cités auparavant, il est utile d envisager une évolution de la structure actuelle. C est pourquoi ce travail souhaite proposer une nouvelle architecture. Pour ce faire, cette dernière s appuiera sur l architecture de référence proposée dans le chapitre Architecture cible L architecture cible est clairement simplifiée par rapport à l architecture de référence pour répondre aux exigences de la BSU sans toutefois apporter une complexité inutile. Grâce aux nombreux outils fournis par le framework.net, le temps d implémentation

29 Partie pratique 27 est limité. Les choix des outils et technologies qui seront utilisés seront expliqués au chapitre 5.5. Les couches intégration et orchestration ont été retirées pour l'architecture cible (cf. Figure 7) car elles ne correspondent pas aux besoins du jeu PMS même à long terme. Figure 7 : Nouvelle architecture pour le jeu PMS Conséquences et avantages de la nouvelle architecture La nouvelle architecture cible (cf Figure 7) amène de nombreux avantages concrets pour le jeu PMS. - Création rapide d un nouveau module en se servant de services existants, un module étant un élément du système. - Mise à jour facilité d un service en cas de bug, modification de la logique, migration vers une nouvelle technologie - Support de données interchangeable - Couche de présentation unique permettant d afficher rapidement de nouveaux types de données ou de la modifier sans crainte de modifier la logique - Transparence de l architecture : accès identique à tous les services (standard) - Indépendant du langage de programmation. Un programme en Java exploitant des services web PMS peut être écrit par exemple.

30 Partie pratique 28 Par ailleurs un changement de rôle intervient dans certains projets de PMS Top (cf. chapitre 5.1). Ce travail a pour but d implémenter les projets PMS Core et Administration selon l architecture définie (cf. Figure 7). Les changements majeurs dans PMS Top sont les suivants : - PMS Core a désormais la responsabilité de publier les services communiquant avec la couche de données. - Une partie de PMS Administration est déjà présente grâce à la possibilité de réutilisation de librairies existantes dans PMS Configuration. Ces librairies seront étendue afin d offrir une meilleure abstraction et des services web exposeront les fonctionnalités. Une partie de la logique pourra également être reprise de PMS Configuration pour créer les services métiers car une couche d accès aux données est déjà présente. - PMS Administration consommera les services de PMS Core afin d offrir des vues de gestion (changement période, lancement calcul, correction du cours d un titre). - La majorité du travail résidera donc dans l implémentation de PMS Core. Les règles de calculs seront revues et une abstraction suffisante sera créée afin de laisser la liberté de créer de nouvelles règles de calculs de portefeuille ou de classement. Ce travail permettra également de résoudre des problèmes dans la logique de calcul rencontrée lors de la dernière session de jeu. PMS Administration ne regroupe donc plus PMS Core et PMS Configuration mais représente un nouveau projet dans PMS Top chargé d offrir une interface de gestion pour le calcul du jeu.

31 Partie pratique Services métiers Différentes types de services seront construits. Les types les plus communs suivant la classification du livre de Erl [Erl 2007]. - Services entités Ce service se base sur les entitées métiers. Il fournit en général les opérations create-read-delete-update (CRUD). Il s agit d un service hautement réutilisable. - Services de tâche Ce service métier est associé à une tâche parent ou un processus. La réutilisabilité tend à être moindre. - Services utilitaires Certains services n ont pas besoin d une logique associée à un modèle métier ou un processus. Il fournir des fonctionnalités réutilisables et utilitaires. Cette classification est utile dans le cadre de ce travail car différents types de services sont mis en place (cf. Figure 8). Services de tâche Services utilitaires CalculService - nextgameperiod - prevgameperiod - nextwebperiod - prevwebperiod CoreUtil - backupdb - restoredb Services entités QuotesService - getquotesforperiod - updatequote Figure 8 : Types de services dans la nouvelle architecture

32 Partie pratique Définitions de cas d utilisations et règles métiers pour le module PMS Core Le langage Unified Modeling Language (UML) est utilisé afin de spécifier le processus de calculs des portefeuilles et des classements. Des cas d utilisations décrivent les exigences fonctionnelles de PMS Core. Les règles métiers définissent la prise de décisions dans la logique métier Cas d utilisations Cette partie décrit les fonctionnalités du module PMS Core. Toutes ces fonctionnalités sont accessibles depuis l administration web. La plupart de ces cas d utilisations ont déjà été définis dans le cadre du travail d Elira Shehu [Shehu 2008]. Ce nouveau diagramme (cf. Figure 9) doit être vu comme une mise à jour de ce dernier correspondant au module PMS Core implémenté et mis en place dans le cadre de ce travail. Figure 9 : Cas d utilisation pour le module PMS Core

33 Partie pratique Descriptions des cas d utilisations Une brève description accompagne chaque cas d utilisation de la Figure 9 pour un souci de clarté. UC7 : Avance d une période le calcul des portefeuilles des joueurs UC32 : Recule jusqu à une période choisie le calcul des portefeuilles des joueurs UC4 : Permet de corriger d éventuelles erreurs de cours due à une importation erronée dans une période choisie UC33 : Avance d une période sur le site. Il s agit de la période dans laquelle les joueurs peuvent effectuer des transactions. UC34 : Recule d une période sur le site. Il s agit de la période dans laquelle les joueurs peuvent effectuer des transactions UC28 : Effectue les transactions des joueurs en passant les ordres d achat ou de vente UC29 : Calcule les intérêts dus entre deux périodes aux comptes des joueurs UC30 : Mets à jour les différentes listes de classements UC31 : Mets à jour le compte des joueurs en créditant les intérêts et en débitant/créditant les gains/pertes des joueurs. UC32 : Avance à une période spécifique le calcul du portefeuille d'un joueur Spécification du cas d utilisation UC7 (Avance d une période de calcul des portefeuilles des joueurs) Une description plus complète et structurée accompagne généralement les cas d utilisations pour améliorer leur compréhension. Le cas d utilisation UC7 (cf. Figure 9) qui est l une des fonctionnalités les plus importantes du jeu est spécifié ci-dessous. Objectif : Cette fonctionnalité permet de calculer l état du portefeuille des joueurs, l état du compte en banque des joueurs ainsi que de mettre à jour les listes de classements pour la période suivante. Acteur : L administrateur du jeu Préconditions : - L administrateur utilise une interface disposant de cette fonctionnalité offerte par PMS Core

34 Partie pratique 32 - La période actuelle est inférieure ou égal à la dernière période du jeu - Le jeu a été initialisé par PMS Configuration - L importation des cours s est effectuée correctement Scénario principal : 1. Le cas d utilisation commence quand l administrateur veut faire calculer une période de jeu. 2. L administrateur choisi le type de jeu. 3. PMS Core affiche les détails sur l état du jeu choisi. 4. L administrateur clique sur le bouton «calculer période». 5. Si des nouveaux portefeuilles sont présents, ces derniers sont actualisés à la période actuelle. o INCLUDE [UC32 Avance à une période spécifique le calcul du portefeuille d'un joueur] 6. PMS Core calcule la période pendant le calcule PMS Core affiche des informations sur l avancement du calcule o INCLUDE [UC28 Effectuer les transactions] o INCLUDE [UC29 Calculer les intérêts des joueurs] o INCLUDE [UC30 Mettre à jour les classements] o INCLUDE [UC31 Mettre à jour le compte des joueurs] 7. PMS Core affiche l information que le calcule est terminé avec succès. Des statistiques sur le calcule sont affichés (durée du calcule, nombre de transactions pris en compte, nombre de joueurs calculés etc.) 8. Le cas d utilisation se termine ici Scénario alternatif 6a problème durant le calcul : Condition de branchement : un problème surgit durant le calcul de la période 6a1 PMS Core n applique pas les modifications sur la base de données 6a2 PMS Core affiche un message d erreur qui permet d identifier la raison de l erreur. 6a3 L administrateur analyse l erreur. 6a4 Le cas d utilisation se termine ici. Scénario alternatif 6b calcul de plusieurs périodes :

35 Partie pratique 33 Condition de branchement : L'administrateur choisit de calculer plusieurs périodes 6b1 L'administrateur choisit une autre période à calculer que celle par défaut (Période actuelle + 1). 6b2 Le scénario 6 est répété jusqu'à atteindre la période souhaité Postconditions en cas de succès : - La mise à jour des comptes en banque, des portefeuilles et des listes de classement s est faite sans erreur - La période de calcul est avancée Postconditions en cas d échec: - La mise à jour des comptes en banque, des portefeuilles et des listes de classement n a pu s effectuer - La période de calcul n est pas avancée - Les transactions ne sont pas calculées Règles de gestion : - Si des transactions liées à des titres dont le cours utilisé pour le calcul est faux, l administrateur doit corriger les erreurs de cours (UC5) et réutiliser la présente fonctionnalité. Point d extension : Aucun point d extension Règles métiers La prise de décisions consistantes pour une entreprise dépend de faits et règles consistantes et de haute qualité qui sont mises à disposition preneurs de décision et des systèmes. Ces faits et règles sont connues sous le nom de règles métiers. [Von Halle 2006]. Des règles métiers ont ainsi été définies pour PMS Core afin de définir des règles de calculs pour les portefeuilles des joueurs. Elles sont d une grande aide dans la spécification et la gouvernance de projets en décrivant des comportements précis en détails. Elles font également office d excellentes documentations pour les projets grâce à leur clarté. Les différentes entrées des règles métiers sont lues de la façon suivante :

36 Partie pratique 34 Nom : Il donne une idée globale du sujet de la règle. Il est en générale clair et concis. Identifiant : Il permet de référencer la règle afin de la citer dans d autres règles ou d en faire référence dans un document externe. Description : Elle donne une description précise de la règle. Si la règle est changée, il est capital de mettre à jour ce champ et d ajouter le champ révision pour indiquer la date et l auteur du changement en question. Exemple : Pour mieux comprendre la règle et éviter d éventuels mauvaise interprétation, un exemple vient appuyer la description. Règles liées : Permet de référencer les règles ayant un impact sur la règle Les règles métiers de l ensemble de règles «Effectuer les transactions» sont présentées ci-après afin d aider le lecteur dans leur lecture et interprétation. Nom Options Eurex Identifiant BR1 Description Si le prix d une option Eurex est de 1 centime, il n est pas possible de l acheter. La transaction n est dans ce cas pas marquée comme calculé afin que PMS Web puisse informer le joueur du refus de la transaction. Exemple Si une option FESX tombe à un prix de 0.01 et qu un achat est effectué, l achat est annulé. Règles liées / Nom Identifiant Description Nombre de titres maximum par catégorie BR2 Un pourcentage maximum de titres d une même catégorie est défini pour le portefeuille. Tout achat de titres dans cette catégorie est plafonné à ce pourcentage.

37 Partie pratique 35 Exemple Si le pourcentage maximum pour la catégorie options eurex est de 5%, les options eurex existantes du portefeuille atteignent 5'000 CHF et que la valeur totale du portefeuille est de 100'000 CHF, aucune option eurex supplémentaire ne pourra être achetée. Règles liées / Nom Crédit Identifiant BR3 Description L achat de titre ne peut amener la valeur du portefeuille à dépasser le solde en banque disponible ajouté au montant du crédit accordé. Exemple Si le crédit accordé est de 2000 CHF et le solde en banque de 10'000 CHF, il n est pas possible d acheter pour plus de CHF Règles liées / Nom Calcul des frais de courtage Identifiant BR4 Description Les frais de courtage sont calculés selon un pourcentage défini. Un minimum et un maximum de frais de courtage sont définis Exemple Si une transaction a pour montant 10'000 et que le pourcentage de courtage est de 2%, les frais de courtages sont de 200 CHF. Règles liées / Nom Identifiant Description Exemple Calcul du coût de l achat d un titre BR5 Le calcul s effectue par la multiplication du nombre de contrats souhaités pour un titre par la grandeur du contrat et par le cours du titre à la fermeture du marché suivant l achat du titre. Les frais de courtages y sont également ajoutés. Une option Eurex à un cours de 1 centime ne peut être achetée (BR1) Si un joueur achète 10 contrats d une option ABB avec une grandeur de contrat de 10 et un cours pour l option à la fermeture de 2 CHF, le

38 Partie pratique 36 Règles liées prix d achat sera de 200 CHF (10*10*2) plus les frais de courtages. BR4, BR1 Nom Identifiant Description Exemple Règles liées Calcul du revenu découlant de la vente d un titre BR6 Le calcul s effectue par la multiplication du nombre de contrats à vendre pour un titre par la grandeur du contrat et par le cours du titre à la fermeture du marché suivant l achat du titre. Les frais de courtages y sont déduits. Si un joueur vend 10 contrats d une option ABB avec une grandeur de contrat de 10 et un cours pour l option à la fermeture de 2 CHF, le revenu sera de 200 CHF (10*10*2) moins les frais de courtages. Le système ne permet toutefois pas de calculer le gain ou la perte effectuée en calculant la différence entre le prix d achat et vente du titre. BR4 On remarquera que ces règles sont atomiques (ne se décomposent pas) et cohésives. Ces critères permettent de définir les règles plus facilement. L atomicité par ailleurs permet d augmenter la réutilisabilité de ces règles. La définition de ces règles devrait apporter une meilleure compréhension du fonctionnement du jeu pour toutes les parties prenantes en clarifiant le processus plutôt complexe du calcul des portefeuilles. Les règles définies dans l Annexe A contiennent certaines contraintes pour le jeu qui ne sont parfois pas évidentes car n étant pas en phase avec la réalité pour des raisons techniques et de temps d implémentation. Une personne non avertie peut ainsi prendre connaissances des spécificités du calcul au sein de PMS Core.

39 Partie pratique Choix des composants tiers pour un développement du projet sous.net Les composants tiers ont été choisis selon plusieurs critères : - Remplissent des besoins d une architecture de type SOA - Permettent de diminuer la taille du code - Offrent une maintenance facilitée - Garantissent leur utilisation à long terme (continuité) - Sous licence Open Source ou gratuites La Figure 10 permet de visualiser les différents composants tiers utilisés et quelle place ils occupent dans l architecture (cf. chapitre 5.3.1). Chacun de ces composants fera l objet d une explication dans les sous-chapitres suivants et la raison de son choix sera argumentée. Figure 10: Intégration des technologies dans l architecture

40 Partie pratique LINQ to SQL Ce produit de Microsoft apparu dans le Framework 3.5 permet de créer un pont entre la programmation orienté-objets et les données relationnels. Offrant une syntaxe intuitive, cette solution permet de manipuler des données sous formes d objets. Grâce à son abstraction (cf. Figure 11), il est possible de manipuler différents types de données qu il s agisse de collections d objets, d enregistrements de bases de données ou encore de données XML. LINQ to OBJECTS LINQ to ADO.NET LINQ to XML LINQ to SQL LINQ to Dataset LINQ to Entities Figure 11 : Les différentes implémentations de LINQ L implémentation LINQ to SQL est choisie dans ce projet pour sa stabilité et sa simplicité. Ce choix s impose également pour rester dans la continuité des autres projets PMS qui ont choisis LINQ. LINQ to SQL va permettre l implémentation de la couche d accès aux données (cf. Figure 12). Cette couche est l abstraction de la persistance objets. Les couches supérieures de l application pourront ainsi manipuler les données de manière transparente sans se soucier de la persistance objets.

41 Partie pratique 39 Client DTO Objects CalculService BLL Business Logic Layer DAL Data Access Layer IDALFacade - CRUD operations LINQ to SQL PMS DB Figure 12: Rôle de LINQ to SQL dans la nouvelle architecture Les objets provenant de LINQ to SQL sont uniquement manipulées dans CalculService. Une projection vers des objets simplifiés, les Data Transfer Objects (DTO), est effectuée afin d augmenter le découplage et d offrir des objets simples à manipuler du côté client. Le passage de ces objets entre les différentes couches déconnecte les objets de leur contexte de données. C est à dire que LINQ to SQL n est plus en mesure de suivre les modifications de l objet pour les répercuter sur la base de données. Il est donc nécessaire d indiquer à LINQ qu il doit rattacher les objets au contexte. Un autre but de cet attachement est de permettre à LINQ d effectuer un test de concurrence. Ainsi une exception sera générée si l entrée a été modifiée entre temps,

42 Partie pratique Windows Communication Framework Il a été choisi dans la nouvelle architecture PMS de découpler la couche client de la couche métier. Il est donc nécessaire de mettre en place une interface standard proposant les fonctionnalités de la couche métier à la couche client. Le moyen de communication a privilégier est évidemment le service web communiquant par HTTP et SOAP. Ce travail étant soucieux de l évolution de l architecture et des besoins futurs, la technologie Windows Communication Framework (WCF) de Microsoft a été choisie. Ce framework de communication permet de communiquer aisément entre différents composants applicatifs. Il réunifie également une majorité de moyens de communications tels que TCP binaire, HTTP et SOAP, COM+, MSMQ pour ne citer que les plus importants. Cette forte abstraction permet de choisir librement le moyen de communication souhaitée, appelé Binding dans WCF. Il est également à noter, pour se rendre compte de la puissance de ce framework, qu il est possible d implémenter son propre Binding. Le Binding choisit dans ce travail se nomme WSDualHttpBinding. Ce moyen de communication offre des services sécurisés permettant aux services ainsi qu aux clients d envoyer et de recevoir des messages. On s écarte donc du traditionnel service web appelant un service et recevant de manière synchrone une réponse. Ce Binding permet de créer des services asynchrones (cf. exemple de la Figure 13) car le service peut lui aussi appeler des fonctions du côté client. Cette possibilité permettra dans ce travail d appeler des opérations du service coûteuses en temps, tel que le calcul des portefeuilles pour une certaine période, de manière asynchrone. Le client peut ainsi être notifié de l avancement de la tâche ainsi que de l issue du calcul et garde la main durant l exécution du calcul rendant inutile une attente de réponse de la part du service. Service web PMS Core Opérations nextperiod prevperiod Appel de nextperiod Etat avancement Etat avancement Résultat / Fin Client Figure 13 : Exemple de l appel de l opération nextperiod sur le service PMS Core

43 Partie pratique 41 La sécurité de ces services est également à prendre compte. Les services du PMS vont opérer dans un environnement semi-sécurisé étant donné qu ils ne seront pas accessibles en dehors de leur domaine. Un niveau de sécurité minimum est donc requis sur ces services. WCF propose un nombre incroyable de types d authentification. L authentification peut se faire au niveau de la couche de transport (exemple : authentification basic HTTP) ou par message (exemple : authentification Windows). Le type de Binding choisi, WSDualHttpBinding, nous contraint à choisir parmi les types d authentification par message. L authentification s effectuera par cryptage asymétrique à l aide de certificats en fournissant au service web une identification par nom d utilisateur et mot de passe Logging Le logging est un suivi des événements d une application sous forme d enregistrements sur divers supports. Au fur et à mesure de l évolution de la SOA, les erreurs peuvent être de plus en plus difficiles à déceler. Il faut déterminer dans quelle application et sur quelle couche s est produite l erreur. Les erreurs générées doivent donc être inscrites sur un support adéquat et offrir des informations pertinentes aidant à situer l erreur. Un outil de logging pour les composants applicatifs dans une SOA est ainsi indispensable. Ces outils offrent des fonctionnalités simples d utilisation pour inscrire des événements sur un support souhaité. Le plus connu est probablement Log4j pour Java permettant d inscrire des événements selon le niveau de gravité des erreurs. Ces événements peuvent ensuite, grâce à des règles et l emplacement, être envoyés sur le support le plus adéquat. Les supports les plus utilisés sont le journal et la sortie sur console. Mais dans un environnement SOA, il peut être intéressant de centraliser ces informations sur une même machine. L outil le permet également grâce à son nombreux choix de supports. Log4j est évoqué dans ce travail par le fait que la plupart des outils de logging pour.net sont des clones de ce fameux outil. Log4net, étant un de ces clones, convient parfaitement dans le cadre de ce travail. Il permet de configurer aisément avec un fichier XML l ensemble du processus de logging. L inscription d événements se fait simplement avec un appel d un singleton dans la classe souhaitée et l appel de la fonction log.

44 Partie pratique 42 Exemple d utilisation: //Au début de la class, instanciation private static readonly ILog logger = LogManager.GetLogger(typeof(Init)); //Inscription d une information utile au débogguage logger.debug("initialisation de l application"); Les différents niveaux de log sont les suivants : - Debug : Information utile au débogage de l application - Info : Niveau permettant d afficher différentes informations relatives au déroulement de l application. - Warn : Erreur de faible gravité. L application peut continuer à s exécuter sans problèmes - Error : Erreur important. L application peut continuer mais l erreur peut affecter le comportement de l application. - Fatal : L application ne peut plus continuer, l erreur étant trop critique. L utilisation de ces différents niveaux peut légèrement différer selon le développeur ou l équipe de développement. L idée la plus intéressante dans une approche SOA serait d envoyer les informations à un service web afin de centraliser les données. Une solution plus simple écrivant des journaux sur un dossier partagé en réseau a été privilégiée ASP.NET et Web Forms ASP.NET désigne les technologies de programmation orientées Web offertes par Microsoft dans son framework.net. Contrairement à l ancienne technologie Active Server Page (ASP), il est désormais possible d utiliser n importe quel langage supporté par le Common Language Runtime (CLR), autrement dit le cœur de la machine virtuelle du framework.net. Le CLR dans son fonctionnement peut être comparée à la Java Virtual Machine (JVM) de Java. Les Web Forms est une des technologies présentes dans ASP.NET. Ils permettent de programmer des pages web qui permettent de renvoyer aux utilisateurs une interface web dans leur navigateur. La logique des pages est implémentée du côté serveur, dans un fichier appelé Code-Behind avec une extension aspx.cs (cf. Figure 14).

45 Partie pratique 43 Figure 14 : Structure et fonctionnement d une Web Form Cette technologie s appuie essentiellement sur un modèle de programmation événementielle. Il est ainsi possible de lier des événements survenant du côté client ou serveur à du code côté serveur de manière transparente, le programmeur n ayant nullement à se soucier de a manière dont se fait cette liaison. Les Web Forms simplifient aussi la conservation de l état des formulaires et de ses composants. Une alternative très intéressant aurait été ASP.NET MVC. Ce framework utilise le paradigme de programmation modèle-vue-contrôleur (MVC). Les Web Forms et ASP.NET MVC sont deux approches différentes faisant l objet souvent de grands débats pour savoir lequel est la meilleure. Les Web Forms ont été retenues dans ce travail pour un souci de continuité avec d autres projets du PMS jquery La librairie JavaScript jquery est utilisée dans ce travail. jquery est une librairie qui vie à simplifier des tâches essentielles dans l interaction du langage JavaScript avec le code HTML. Elle offre une compatibilité avec une majorité des navigateurs. Les fonctionnalités les plus intéressantes sont les suivantes : - Parcours et manipulation du Document Objet Model (DOM) - Gestion des événements - Animations - Communication Asynchronous JavaScript and XML (AJAX)

46 Partie pratique 44 La dernière fonctionnalité, l utilisation de la technologie AJAX, est la plus utile dans le cadre de ce travail. Ajax représente une approche utilisant les technologies web modernes communes à tous les navigateurs. La combinaison de ces technologies permet de mettre à jour dynamiquement une page web sans devoir procéder à un nouveau chargement de la page. Ajax permet notamment, par le biais de l objet XMLHttpRequest, de communiquer de manière asynchrone avec le serveur pour envoyer et recevoir des données et ainsi mettre à jour la page web. Cette fonctionnalité permet de remplacer le contraignant rafraichissement de l ensemble de la page imposé par les Web Forms. Une application web possède certains désavantages par rapport à une application classique. Le serveur ne peut par exemple pas envoyer des données supplémentaires à une page web suite à son chargement dans le navigateur du client. Cette fonctionnalité est toutefois utile si une tâche s exécute du côté serveur et que l on souhaite informer le client de l avancement. En supposant qu une page web affiche l état de l avancement, le client a besoin de la rafraichir constamment pour connaitre la progression de la tâche. La communication asynchrone permet de palier à ce problème. Il est possible d utiliser un mécanisme de pull (cf. Figure 15). Le pull consiste à la page web de demander au serveur à une certaine fréquence et via une communication asynchrone le nouvel état. PMS Core Services PMS Administration Session progression Mises à jour Navigateur web Page web jquery Figure 15 : Méchanisme de pull L utilisation de ce mécanisme dans ce travail permet d afficher l avancement du calcul des portefeuilles des joueurs à l utilisateur du système. La progression n est évidemment pas parfaitement en temps réel mais permet d en donner l illusion à l utilisateur.

47 Partie pratique Implémentation PMS Core Le projet PMS Core est un projet.net en ligne de commande se chargeant de publier des services offrant différentes opérations nécessaires au jeu PMS dont notamment le calcul des portefeuilles des joueurs. Ces différentes opérations comportent la gestion des périodes jeu, la correction des cours pour les titres négociables ainsi que différentes opérations utilitaires tels que la sauvegarde et restauration de la base de données en cas de problème. La figure Figure 16 présente la structure du projet. Figure 16 : Structure du projet PMS Core PMS Core est décomposé en deux projets. Le principal contenant la logique et les services s appellent PMS Core Services. Le projet PMS Core Web s occupe uniquement de lancer le service dans le serveur IIS.

48 Partie pratique 46 Une brève description des fichiers du projet PMS Core Services les plus importants est donnée ci-dessous : Init.cs : Se charge de l initialisation et de la publication du service PlayerContext.cs : Permet de stocker les informations relatives à un joueur qui seront utilisées durant le processus de calcul Log4net_config.xml : Contient la configuration du logging pour log4net CalculEngine.cs : Contient la logique pour le calcul d une période du jeu. Fichiers WSServices : Contient les opérations des services publiés. Pour l instant uniqment CalculService est publié. Fichiers PlayerPortfolioOperation : Contient une parte du processus du calcul du portfeuille pour un joueur. UpdateBuyOperation se charge ainsi de l exécution des transactions d achat de titres d un joueur. Fichiers ChangeTracker : S occupe de stocker les changements à effectuer sur la base de données. Ce système permet d éviter de trop nombreuses interactions avec la base de données, coûteuses en performance. Fichiers DbBackup : Fournissent les utilitaires nécessaires à la sauvegarde et restauration de la base données. Fichiers DTO : Classes correspondant aux objets DTO (cf. chapitre 5.5.1). Une analyse de l implémentation des parties les plus importantes est effectuée dans les sous-chapitres suivants Initialisation du service web Le projet n utilisant pas le serveur Internet Information Services (IIS), l utilisation de la classe ServiceHost est nécessaire pour configurer et publier le service. Uri baseaddress = new Uri(" using (ServiceHost host = new ServiceHost(typeof(CalculService), baseaddress)) { // Enable metadata publishing. ServiceMetadataBehavior smb = new ServiceMetadataBehavior();

49 Partie pratique 47 smb.httpgetenabled = true; smb.metadataexporter.policyversion = PolicyVersion.Policy15; //host.description.behaviors.add(smb); messages // Open the service host. Listen for host.open(); logger.info("the service is ready at " + baseaddress); Console.WriteLine("The service is ready at {0}", baseaddress); Console.WriteLine("Press <Enter> to stop the service."); Console.ReadLine(); } // Close the service host. host.close(); return 0; Un service expose un endpoint (cf. Figure 17). Le endpoint est le point d accès au service depuis l extérieur. Il se compose : - D une adresse : l adresse de publication du service sous la forme d une URL - D un Binding : du moyen de communication (cf. chapitre 5.5.2) - D un contrat : définit ce que le endpoint communique. Il s agit concrètement de l interface de du service à publier. Figure 17: Composants du Endpoint

50 Partie pratique 48 L adresse est définie dans le constructeur de la classe ServiceHost. Uri baseaddress = new Uri(" using (ServiceHost host = new ServiceHost(typeof(CalculService), baseaddress)) Il est à noter que l adresse définie doit être libre et que le système doit autoriser le programme à réserver cette adresse. Le binding ainsi que le contrat sont définies dans le fichier de configuration de l application. <service behaviorconfiguration="pmscalcul.calculservicebehavior" name="pmscalcul.calculservice"> <endpoint binding="wsdualhttpbinding" contract="pmscalcul.icalculinterface" /> <endpoint address="mex" binding="mexhttpbinding" contract="imetadataexchange" /> </service> Suite à la configuration le service est publié par la méthode open(). host.open(); Pour éviter que le programme se termine, ce dernier se met en attente d une saisie dans la console. Console.ReadLine(); Si une saisie se produit, le programme peut se terminer. Il termine alors proprement la communication du service web : host.close(); Implémentation du contrat Le contrat du service web est implémenté avec une interface. L attribut ServiceContract permet de la définir comme contrat et de lui spécifier un espace de noms, un mode de

51 Partie pratique 49 session ainsi que le contract de retour. Le contrat de retour (CallbackContrat) permet de définir des opérations qui peuvent être appelées du côté client. Le binding vu précédemment, WSDualHttpBinding, permet d accomplir cela. L attribut OperationContrat définit le contrat de l opération. La propriété isoneway permet de créer une opération asynchrone. Le client n aura ainsi pas besoin d attendre de réponse du service web. Ce dernier pourra lui envoyer la réponse de manière asynchrone grâce au contrat de retour car les méthodes définies dans ce contrat seront implémentées chez le client. namespace PMSCalcul { [ServiceContract( Name = "CalculService", Namespace = " CallbackContract = typeof(icalculcallback), SessionMode = SessionMode.Required)] interface ICalculInterface { [OperationContract(IsOneWay = true)] void nextgameperiod(int period); Implémentation d une opération asynchrone Comme vu dans le chapitre , il est possible de définir une opération comme asynchrone. Il alors intéressant de voir comment sera implémenté la méthode en question. public void nextgameperiod(int period) { callback = OperationContext.Current.GetCallbackChannel<ICalculCallback >(); //begin calculation CalculEngine engine = new CalculEngine(callback); engine.nextgameperiod(2, 2); System.Diagnostics.Debug.WriteLine("Begin computation next game period"); }

52 Partie pratique 50 L interface du callback est récupérée et passée à la classe se chargeant du calcul du jeu. On s aperçoit qu il n y a pas de réponse fournie. A la suite du calcul du jeu, il sera alors possible de notifier le client de la fin des calculs (la variable ws_callback correspondant à callback fournie à la classe CalculEngine) : _wscallback.signalend("success"); Implémentation de la fonction d avancement d une période Cette fonctionnalité est la plus longue et importante du projet PMSCalcul car elle s occupe de mettre à jour : - Les portefeuilles des joueurs selon leurs transactions effectuées - Le compte en banque de chaque joueur en tenant compte des intérêts et des gains ou profits réalisées sur les transactions. - La liste de résultat pour chaque type de classement La première étape consiste à récupérer les paramètres du jeu et à calculer le nombre de jours entre la période actuelle et la prochaine période. public void nextgameperiod(int periode, int spielid) { Console.WriteLine("Starting computation for the period {0}", periode); // load common settings CommonObjects.BsuSpiel spiel = BLL.BLLFacade.getSpiel(spielId); BLL.BLLFacade.setCurrentSpiel(spiel); loadcommonsettings(spiel); // get nb periods between last period and now int periodinterval = getdiffperiods(2, 5); Il faut ensuite calculer un à un les portefeuilles des joueurs. Le calcul des opérations sur le portefeuille d un joueur a été ajouté dans un pool de threads. Le pool de threads est une file de processus où s exécute simultanément un nombre maximum de processus. Il n est malheureusement pas possible d utiliser cette puissance dans ce travail car cela impliquerait de modifier toute la couche d accès aux données pour y intégrer des

53 Partie pratique 51 mécanismes de synchronisation. Cette implémentation a été faite de cette manière à titre didactique. Chaque opération sur le portefeuille correspond à une classe prenant comme arguments dans son constructeur les variables player et playercontext. List<Entities.Spieler> players = BLL.BLLFacade.getAllSpieler(spiel, "asc"); int threadcount = 0; ManualResetEvent finished = new ManualResetEvent(false); int nbplayers = players.count; PlayerPortfolioCalculation[] calcarray = new PlayerPortfolioCalculation[nbPlayers]; int i=0; foreach (Entities.Spieler player in players) { Interlocked.Increment(ref threadcount); ThreadPool.QueueUserWorkItem(delegate { PlayerContext(); commonsettings; periodinterval; PlayerContext playercontext = new playercontext.commonsettings = playercontext.periodinterval = playercontext.spiel = spiel; playercontext.currentperiod = periode; PlayerPortfolioCalculation ppcalc = new PlayerPortfolioCalculation(player,playerContext); calcarray[i] = ppcalc; ppcalc.threadpoolcallback(i); i++; Thread.Sleep(100); _wscallback.signalprogress(nbplayers); if (Interlocked.Decrement(ref threadcount) == 0) { finished.set(); } //interests UpdateBankInterestOperation bkintop = new UpdateBankInterestOperation();

54 Partie pratique 52 playercontext); bkintop.updateplayerportfolio(player, PMS Administration Le projet PMS Administration est un projet web ASP.NET. Il s agit de l interface utilisateur (cf. Figure 18) pour contrôler le calcul du jeu. Les interactions avec PMS Core ne se font que via des services web. L analyse de l implémentation se limite également aux aspects les plus importants et nouveaux dans les projets PMS. Figure 18 : Interface utilisateur PMS Administration Configuration et implémentation du contrat de retour pour PMS Core L utilisation d opérations asynchrones dans PMS Core nécessite une configuration du côté client. Cette configuration met en place également un endpoint permettant à PMS Core d atteindre les opérations définies dans le contrat de retour. <bindings> <wsdualhttpbinding> <binding name="wsdualhttpbinding" clientbaseaddress=" </binding> </wsdualhttpbinding> </bindings>

55 Partie pratique 53 Le code nécessaire à l utilisation du service PMS Core est automatiquement généré grâce à l utilitaire svcutil. L outil génére le fichier CalculService.cs qu il suffit d ajouter au projet. svcutil L instanciation se fait également facilement. CalculServiceClient calculservice = new CalculServiceClient(new InstanceContext(new Callback(Session))); Il est toutefois nécessaire de fournir l instance de la classe implémentant les méthodes du contrat de retour créé dans PMS Core. Il s agit dans ce projet de la classe Callback. Cette classe a pour interface CalculServiceCallback qui a été automatiquement générée par svcutil. public class Callback : CalculServiceCallback { private HttpSessionState _Session; private static int nbcalculated = 0; public Callback(HttpSessionState Session) { _Session = Session; } public void signalend(string status) { _Session["status"] = status; }

56 Partie pratique Déploiement Le déploiement des applications PMS Administration et PMS Core (cf. Annexe B pour la procédure) se font sur les serveurs virtuels BSU mises à disposition par le service informatique de l université de Fribourg (SIUF). Actuellement la BSU dispose de 3 serveurs virtuels : - Serveur base de données: Contient le serveur SQL Server pour le stockage des données du jeu PMS. - Serveur web : Contient le serveur web IIS publiant les applications PMS Administration, PMS Administration, PMS Portal ainsi que le datawarehouse. - Serveur d intégration et test : Contient les outils d intégration continue ainsi que l application PMS Core. Le schéma ci-dessous (cf. Figure 19) présente le nouvel environnement BSU. Les applications PMS Core et PMS Administration sont déployées sur le serveur web. Figure 19: Environnement BSU actuel

57 Partie pratique Tests Les tests de changements de période ont été menés en utilisant des données des années précédentes. Pour s assurer que la qualité n est pas inférieure à l ancien programme écrit en Microsoft Access, il a été décidé de comparer les résultats du calcul en partant d un même état. En ce qui concerne, les fonctionnalités secondaires, celle-ci sont plus facilement vérifiable au niveau fonctionnelle. L ensemble de ces fonctionnalités sera par ailleurs testée dans une phase précédente au jeu par l ensemble de l équipe BSU.

58 Résultats pratiques obtenus et évaluation 56 6 Résultats pratiques obtenus et évaluation Présentation de l interface PMS Administration Ce travail a permis de mettre en place le projet PMS Administration qui permet de gérer une partie des processus du jeu dont notamment le calcul des portefeuilles. Cette application se présente sous la forme d une interface web allégée et intuitive. Il est possible de changer facilement le type de jeu grâce à une liste sous le menu (cf. Figure 20). La vue «Périodes» (cf. Figure 20) permet de passer d une période à une autre du jeu. On distingue la période du jeu et la période web. La période jeu est la période qui est actuellement calculée c'est-à-dire la période dans laquelle les portefeuilles sont à jour. La période web est la période dans laquelle les joueurs peuvent passer des transactions. Cette distinction permet d effectuer le calcul des portefeuilles indépendamment des transactions. L opération, avancer d une période de jeu, qui nécessite plus de temps à s accomplir est accompagnée d une barre de progression pour afficher l avancement de la tâche. Figure 20 : La vue Périodes La vue «Correction de cours» (cf. Figure 21) permet quant à elle de modifier les cours qui ont été importés par le module d importation PMS Quotes. Cette fonctionnalité permet de corriger facilement quelques petites erreurs d importation qui auraient pu survenir.

59 Résultats pratiques obtenus et évaluation 57 Figure 21 : La vue Réparation de cours La vue «Logs» (cf. Figure 22) permet de créer un emplacement unique de visualisation des logs. L utilisateur peut ainsi visualiser les différents messages provenant des modules de l architecture SOA. Figure 22 : La vue Logs La vue «Configuration» n est dans un premier temps pas utilisée. Elle servira à terme à modifier les paramètres de configurations de certains services de PMS Core.

60 Résultats pratiques obtenus et évaluation Présentation de PMS Core Ce travail a permis d'implémenter la plupart des cas d'utilisation définies dans le chapitre 5.4.1). Le cas d'utilisation UC 32 et le scénario alternatif 6b du cas d'utilisation UC 27 n'ont toutefois pas été implémentés pour des raisons de temps. Le projet permet toutefois d'ajouter facilement de nouveaux services et l'implémentation de ces fonctionnalités pourra se faire rapidement dans le futur Avantages et désavantages de la nouvelle architecture La nouvelle architecture grâce au découplage entre la couche métier et la couche vue permet une réutilisabilité des services ainsi qu une extensibilité simplifiée. Les nouvelles fonctionnalités peuvent être facilement implémentées en intégrant la logique métier dans PMS Core en se servant de la logique existante. Les services peuvent ensuite être consommés où l on veut, que cela soit dans PMS Administration ou dans un programme indépendant. La nouvelle solution PMS Administration permet désormais de gérer les deux types de jeu utilisés chaque année dans la BSU à l aide d une seule interface. Les autres types de jeu peuvent être facilement configurés et implémentés dans la solution actuelle. L interface web permet de se connecter depuis chez soi pour effectuer des tâches sur le jeu PMS. La sécurité est également augmentée car les services métiers, grâce au découplage, peuvent être isolés sur un autre serveur que le serveur web. La communication entre les vues et les services est par ailleurs parfaitement sécurisée. L exécution asynchrone de tâches permet de ne pas bloquer l ensemble du système pour une seule tâche. Si l on trouve beaucoup d avantages dans la nouvelle architecture, il n y a pas pour moins des désavantages. Le temps d implémentation est plus long du au découplage nécessaire et aux nombreuses technologies à maîtriser. 6.2 Différences avec les attentes théoriques Les technologies et modèles en théorie donnent souvent une impression de facilité d implémentation. Malheureusement il n est pas toujours aisé de transposer cette théorie dans la pratique si l on tient compte des délais, des obstacles techniques ou encore du nombre de technologies à maîtriser. Dès lors il est intéressant de relever les aspects

61 Résultats pratiques obtenus et évaluation 59 ayant posé le plus de problèmes. Il est à noter que les différences entre la pratique et la théorie qui suivent concernent ce travail et de ce fait ne sont pas à retenir comme des vérités. Ces différences peuvent s expliquer selon différents facteurs liées à l environnement de ce travail. Les différents problèmes rencontrés qui n ont pas été parfaitement anticipées sont également abordés. Le découplage entre la couche métier et la couche vue s est fait avec plus d efforts que prévu. Les objets LINQ n ont pas pu être directement sérialiser pour transiter sur le canal de communication des services web. Leur structure est probablement trop complexe pour être sérialisée proprement. Ainsi des objets dits Data Transfer Object ont été utilisés (cf. chapitre 5.5.1). Il s agit ainsi d une différence par rapport aux attentes même si les DTO sont également conseillés dans de nombreuses architectures. Il a en résulté un temps d implémentation plus conséquent car les objets doivent être converties de DTO à LINQ et réciproquement. Malgré la présence de plus en plus forte de documentation au sein de la BSU, certaines applications manquent encore de documentation sur leur fonctionnement. La migration du système de calcul des portefeuilles vers PMS Administration et PMS Core a ainsi nécessité d appréhender parfaitement le fonctionnement du logiciel Access dans laquelle fonctionnait l ancienne application. Les règles métiers et les spécifications de cas d utilisation abordées dans ce travail (cf. chapitre 5.4) sont d excellents outils pour faire face à ces problèmes dans le futur. Le déploiement ne s est pas fait sans difficultés également. Il a fallu tenir compte de l environnement actuel. Les serveurs virtuels fonctionnent avec le système d exploitation Microsoft Windows Server Il s agit d un système qui ne connaissait pas encore ces technologies. Le déploiement a donc nécessité beaucoup de configuration notamment au niveau sécurité avec très peu de documentation à disposition. Les systèmes plus récents disposent en effet d outils permettant de configurer plus rapidement ces aspects. En ce qui concerne encore le déploiement des applications, une configuration pour chaque environnement aurait été souhaitable. Il est actuellement nécessaire d adapter ou de vérifier la configuration de l environnement de développement sur l environnement de production. L utilisation d outils d intégration continue serait une excellente solution pour résoudre ce problème.

62 Conclusion 60 7 Conclusion 7.1 Conclusion finale Une réponse aux questions amenées en introduction a été apportée tout au long de ce travail. Une définition et explication d une architecture du système d information a été donnée (cf. chapitre 2.1) en s appuyant sur de la littérature. Se poser la question de l utilité d une architecture structurée et planifiée (cf. chapitre 2.2) a permis d aboutir à une architecture particulière, l architecture orientée services. Les apports de la SOA sur un plan théorique et pratique ont été mis en avant sur la base de l expérience et des connaissances assimilées (cf. chapitres 2.3 et 2.4). Finalement l intérêt s est porté sur la liaison entre le code et les données (cf. chapitre 3 ). On a vu que l utilisation d une couche d accès aux données permet d obtenir cette liaison et que des outils tel que LINQ to SQL permettent de mettre en place plus facilement cette couche. Finalement des questions relatives au projet développé ont été abordées dans la partie pratique. L architecture du jeu PMS a été construite (cf. chapitre 5.3) sur la base de l architecture de référence SOA proposée dans la partie théorique. Les exigences pour le calcul du jeu PMS ont été définies (cf. chapitre 5.4) sous la forme de cas d utilisations et par des règles métiers. L utilisation de LINQ to SQL a été privilégiée dans le projet PMS Core et son intégration avec le projet a été abordée de manière concrète (cf. chapitre 5.5). Finalement les apports de la nouvelle architecture du jeu PMS par rapport à l ancienne ont été relevés (cf. chapitre 6.1.3). La recherche de réponses à ces questions a permis de se plonger dans l univers de la SOA. Le travail s est focalisé pleinement sur le sujet de ce travail en mettant en place une architecture de type SOA dans le cadre d un projet pour l association BSU.

63 Conclusion Conclusions personnelles Ce travail a permis par le biais de l apprentissage du modèle SOA ainsi que du mapping relationnel-objet d implémenter les projets PMS Core et PMS Administration. Il a également relevé l importance de tenir compte de l architecture actuelle pour définir une nouvelle architecture. Comme vu dans le chapitre précédent, le travail est souvent plus important que celui promis théoriquement. Il faut ainsi établir une architecture qui pourra être atteinte de manière itérative depuis l architecture actuelle. Des méthodes agiles, non abordées dans ce travail, sont de ce fait et à mon avis indispensable lors de projets identiques avec une taille plus conséquente. Une des leçons que j ai tirée de ce travail est également de rester réaliste face aux objectifs. Les exigences de l architecture sont parfois fixées non en fonction des besoins mais en fonction de la beauté de l architecture. La SOA est évidemment très à la mode actuellement et on est tenté d accomplir parfaitement ce modèle. L adéquation avec le contexte est pourtant plus importante et il suffit parfois de ne retenir que les points les plus intéressants (best practices) de certains modèles ou technologies. Une tendance remarquée est d opposer deux d entre eux alors qu il est souvent possible de les intégrer ensemble et de tirer partie de leur complémentarité.

64 Ressources 62 8 Ressources [Ambler 2009] Ambler, Scott : Business Rules, dernier accès [Ballinger 2003] Ballinger, Keith :.NET Web Services: Architecture and Implementation, Addison Wesley, 2003 [Bass et al. 2003] Bass, Len; Paul, Clements; Rick Kazman: Software Architecture in Practice, Addison-Wesley, 2003 [BEA 2005] BEA : Domain Model for SOA, pdf, dernier accès : [Benett 2006] Benett, Stephen : Building Your SOA Roadmap, dernier accès: [Bieberstein et al. 2008] Bieberstein, Norbert; Laird, Robert G.; Jones, Dr. Keith; Mitra, Tilak : Executing SOA: A Practical Guide for the Service-Oriented Architect, IBM Press, 2008 [Erl 2005] Erl, Thomas : Service-Oriented Architecture: Concepts, Technology and Design, Indiana, Prenctice Hall, 2005 [Erl 2007] Erl, Thomas : SOA : Principles of Service Design, Indiana, Prenctice Hall, 2007 [Gartner 2003] Gartner: Service oriented architecture scenario, dernier accès: [Grenier/Moine 2003] Grenier, Claude ; Moine, Camille : Construire le système d information de l entreprise. Paris, Foucher, [Hamilton/Miles 2006] Hamilton, Kim; Miles, Russell : Learning UML 2.0, O Reilly, 2006 [Hüsemann 2009] Hüsemann, Stefan : Systèmes d information I. Université de Fribourg, Suisse, [Hüsemann 2009] Hüsemann, Stefan : Systèmes d information II. Université de Fribourg, Suisse, 2009.

65 Ressources 63 [IBM 2007] IBM : Design an SOA solution using a reference architecture, dernier accès: [ipt 2010] Innovation Process Technology (ipt): SOA Referenzarchitektur und Technologien, documentation du cours SOA in a Day, Zug, Janvier 2010 [Krafzig et al. 2004] Krafzig, Dick; Banke, Karl, Slama Dirk : Entreprise SOA: Service-Oriented Architecture Best Practices, Indiana, Prenctice Hall, 2004 [Marks/Bell 2006] Marks A., Eric, Bell, Michael : Service-Oriented Architecture: A planning and Implementation Guide for Business and Technology, 2006 [Newcomer/Lomow 2004] Newcomer, Eric; Lomow, Greg : Understanding SOA with Web Services, Upper Sadle River, Pearson Education, 2004 [OASIS 2006] OASIS : Reference Model for Service Oriented Architecture 1.0, accès: dernier [Ros 2003] Ros, Sébastien : Mapping objet-relationnel, Couche d accès aux données et Frameworks de persistance, dernier accès : [Short 2002] Short, Scott : Building XML Web Services for the.net Platform, Microsoft, 2002 [Shehu 2008] Shehu, Elira: Analyse d un système informatique et extension de celui-ci par de nouvelles fonctionnalités, Travail de séminaire, 2008 [The Open Group 2009] Open Group : SOA Reference Architecture, pdf, dernier accès: [Von Halle 2006] Von Halle, Barbara: Business Rules Applied: Building Better Systems Using the Business Rules Approach, 2006 [Wikipedia 2010] Wikipedia : Software Architecture, dernier accès :

66 Annexe A 64 Annexe A Cette annexe regroupe les règles métiers qui n ont pas été présentées dans le chapitre Ensemble de règles Calculer les intérêts dues aux joueurs Nom Calcul de l intérêt du à un joueur Identifiant BR7 Description Le calcul s effectue par l utilisation d un taux d intérêt annuel différent selon que l avoir en banque soit positif ou négatif. Ce taux d intérêt annuel est converti en taux pour une période en jours correspondante au nombre de jours entre la période à calculer et la période actuelle. Ce taux est ensuite multiplié par le montant de l avoir en banque du joueur pour donner l intérêt en faveur de la banque si le compte est négatif ou en faveur du joueur dans le cas contraire. Exemple Si l avoir en banque du joueur est de 10'000 CHF, l intérêt annuel est de 0.5% et le nombre de jours entre les deux périodes de 3, les intérêts à créditer sur le compte du joueur seront de *(0.005/360*3) soit 41 centimes. Règles liées / Ensemble de règles Mise à jour des classements Nom Calcul de la performance journalière Identifiant BR8 Description La différence entre le patrimoine actuelle (avoir en banque + valeur du portefeuille) et celui de la dernière période est calculée et divisée par le patrimoine de la dernière période. Exemple Si le patrimoine de la période 2 est de 12'000 et celui de la période 1 de 10'000, la performance journalière est de ( '000)/10'000 soit 20%. Règles liées /

67 Annexe A 65 Nom Calcul de la performance totale Identifiant BR9 Description La performance totale est la performance effectuée entre la première période et la période actuelle. Elle est calculée de la façon suivante : Patrimoine actuelle du joueur / avoir en banque avant le jeu 1. Exemple Si le patrimoine actuel est de 11'000, l avoir en banque initiale de 10'000, la performance totale est de (11 000/10'000)-1 soit 10%. Règles liées / Nom Calcul de la performance journalière moyenne Identifiant BR10 Description La performance journalière moyenne est calculée en effectuant la moyenne de toutes les performances journalières en incluant celle de la période actuelle Exemple / Règles liées / Nom Identifiant Description Exemple Règles liées Calcul du risque BR11 L écart type des performances journalières est calculé pour obtenir le risque. Il s agit donc de la calculer la variance et d en calculer la racine. Soit une performance journalière moyenne de 10% calculée sur deux performances journalières de 9% et 11%. Le risque est de srqt([(9-10)^2+(11-10)^2]/2) soit 1.4. BR10, BR9

68 66 Nom Identifiant Description Exemple Règles liées Calcul du Sharp Ratio BR12 Le Sharp Ratio est un indicateur de rentabilité. Il permet de quantifier la rentabilité du portefeuille par rapport au risque qui a été pris. Cet indicateur se base sur un référentiel de comparaison étant en général un taux de placement sans risque. Sharp Ratio = (performance totale annuelle taux sans risque) / risque Si la performance annuelle totale est de 10%, le taux sans risque de 1.5% et le risque de 1.4, le Sharp Ratio est alors de BR10, BR9

69 Annexe B 67 Annexe B Cette annexe explique le processus pour la mise en place de l environnement de développement et pour le déploiement des applications PMS Core et PMS Administration. Mise en place de l environnement de développement sur une machine de développement local Pré-requis : - Serveur Microsoft IIS (Internet Information Services) - Microsoft Visual Studio Plugin Visual Studio AnkhSVN - Désactivation de l UAC (User Account Control) pour autoriser les services web Importation des projets - Configurer le repository svn://diuf-svn.unifr.ch/huesemann-bsu dans VisualStudio - Faire un checkout des projets PMS Core et PMS Administration ainsi que des modules CommonObjects, DAL, BLL et Entities. - S assurer que les modules sont bien configurés comme références et dépendances du projet PMS Core Configuration du serveur de production - Installer les certificats X.509 BSUServer et BSUClient sur le serveur - Créer un pool dans IIS utilisant le compte Administrateur - Utiliser ce pool pour les projets PMS Core et Administration Déploiement des projets - Utiliser la fonction Publier le projet pour déployer les projets sur le serveur via un dossier monté en réseau - Configurer dans les fichiers Web.config les paramètres qui différent pour l environnement de production.