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 mathias.bueschi@unifr.ch 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