Gestion d une plate-forme temps réel sur une architecture basée sur

Dimension: px
Commencer à balayer dès la page:

Download "Gestion d une plate-forme temps réel sur une architecture basée sur"

Transcription

1 UNIVERSITÉ LIBRE DE BRUXELLES Faculté des Sciences Département d Informatique Gestion d une plate-forme temps réel sur une architecture basée sur les évènements Mohammed Jelti Promoteur : Prof. Esteban Zimányi Mémoire présenté en vue de l obtention du grade de Master en Sciences Informatiques Année académique

2

3 À tous ceux qui m ont soutenu, pendant huit ans d existence ici

4 When I can t handle events, I let them handle themselves Henry Ford Challenges are gifts that force us to search for a new center of gravity. Don t fight them. Just find a different way to stand. Oprah Winfrey

5 Remerciements Je tiens tout d abord à adresser mes plus sincères remerciements à M. Esteban Zimányi, directeur de ce mémoire, ainsi qu à M. Sabri Skhiri directeur de recherche et de développement d Euranova, pour m avoir suivi et pour m avoir consacré autant de temps. Je voudrais également remercier ici l équipe d informatique d Alcatel-Lucent à Namur, et notamment M. Xavier Lerot qui m a beaucoup aidé durant ce travail et qui m a prodigué de précieux conseils. Je ne saurai oublier ici l administration et tous les enseignants de l ULB qui ont contribué à ma formation universitaire et plus particulièrement les membres du jury de ce mémoire, messieurs Raymond Devillers et Joël Goossens. Je témoigne aussi toute ma reconnaissance amicale à toute l équipe d Euranova dont la disponibilité et la courtoisie ont été constantes à mon égard. Enfin, je remercie tous ceux qui ont contribué de près ou de loin à l élaboration de ce travail.

6 Table des matières 1 Introduction Contexte du problème Objectif du mémoire Organisation du mémoire Architecture logicielle d entreprises Introduction La couche de présentation La couche des processus métiers La couche d intégration La couche des services La couche des applications Cloud Computing Event Driven Architecture Introduction Le concept Ses apports Le contexte Ses caractéristiques Ses composants Son fonctionnement Choix d une solution EDA vs SOA Implémentation v

7 vi 4 Outils et technologies d implémentation MDA : Model Driven Architecture EMF : Eclipse Modeling Framework JET : Java Emitter Templates EPA : Eclipse Plugin Architecture JBoss Application Server Description des services avec WSDL JBoss Enterprise Service Bus JAIN Service Logic Execution Environnement Gestion de la plate-forme Présentation de la plate-forme Architecture de l application de gestion de la plate-forme Fonctionnement de l application de gestion de la plate-forme Proposition d une solution d intégration Les apports de la solution Description de la solution d intégration Implémentation de la solution d intégration Génération automatique de la solution Conclusion 83 Bibliographie 84 A Rapport du stage en entreprise 88 A.1 Implémentation d un Event Collector A.2 Implémentation d un CEP A.3 Patterns d implémentation pour une EDA

8 AMI Amazon Machine Image AMQP Advanced Message Queuing Protocol AS Application Server API Application Programming Interface BAM Business Activity Management BPEL Business Process Execution Language BPL Business Process Layer BPM Business Process Management CBR Content Based Routing CDIF CASE Data Interchange Format CEP Complex Event Processing CRUD Create, Read, Update, Delete CRM Customer Relationship Management CWN Commun Warehouse Metamodel DNS Domain Name System EAI Enterprise Application Integration EIA Electronic Industries Alliance EC2 Elastic Compute Cloud EDA Event Driven Architecture EJB Enterprise JavaBean EMF Eclipse Modeling Framework EPA Event Processor Agent EPN Event Processing Network ERP Enterprise Resource Planning EPR End Point Reference ESB Enterprise Service Bus ESC Enterprise Service Cloud ESM Enterprise Messaging System FTP File Transfer Protocol HTTP HyperText Transfer Protocol IAAS Infrastructure as a Service IDE Integrated Development Environment IHM Interface Homme-machine IIOP Internet Inter-Orb Protocol IP Internet Protocol ISB Internet Service Bus JAAS Java Authentication and Authorization Service JBOSS Java Beans Open Source Software JCA Java Connector Architecture JDBC Java DataBase Connectivity JDK Java Development Kit JEE Java Enterprise Edition JET Java Emitter Templates JMX Java Management Extension JMS Java Messaging Service JNDI Java Naming and Directory Interface JPA Java Persistance API JSF Java Server Face JSP Java Server Page 1

9 JSPX Java Server Page XML JTA Java Transaction API JTS Java Transaction Services LDAP Lightweight Directory Access Protocol MDA Model Driven Architecture MOF Meta-Object Facility MOM Message Oriented Middleware MVC Model View Controler NDS Naming and Directory Service NGIN Next Generation Intelligent Network NIS Network Information Service OCL Object Constraint Language OM Objet Métier OMG Object Management Group OMS Objet Métier Spécifique OSGi Open Services Gateway initiative PAAS Platform As A Service PIM Platform-Independent Model POJO Plain Old Java Object REST Representational state transfer RCP Rich Client Platform RFID Radio Frequency IDentity RFP Request for Proposal RMI Remote Method Invocation SAAS Software As A Service SAM Service Activity Monitoring SBB Service Building Block SCA Service Component Architecture SMIF Serial Model Interchange Format SDK Software Development Kit SMTP Simple Mail Transfer Protocol SOA Service Oriented Architecture SOAP Simple Object Access Protocol SOCCA Service Oriented Cloud Computing Architecture SQL Structured Query Language SWT Standard Widget Toolkit S3 Simple Storage Service XMI XML Model Interchange XML extensible Markup Language XSL extensible Stylesheet Language UDDI Universal Description Discovery and Integration UML Unified Modeling Language URI Unique Resource Identifier WS Web Service WSDL Web Services Description Language 2

10 Chapitre 1 Introduction 1.1 Contexte du problème Les économistes s accordent depuis quelques décennies sur l importance du progrès technique en tant que facteur de la croissance économique. Les entreprises, premières concernées, tâchent d optimiser le système informatique en vue d améliorer les performances. Ainsi, les directeurs informatique se concentrent sur deux éléments centraux au sein de l entreprise : le flux de travail (Workflow) et le flux de données (Dataflow). Leur maîtrise reste le meilleur moyen d améliorer l efficacité de l entreprise. Très souvent, les entreprises se tournent vers les experts en matière d architecture IT 1 afin de concevoir et de coordonner le flux de données. Ce dernier reste difficilement gérable sachant que de nouvelles applications sont rajoutées au fur et à mesure du développement du système informatique de l entreprise. Ceci implique une intervention continue de la part des experts, ce qui oblige les entreprises à s orienter vers des architectures inter-applications évolutives capables de gérer l échange de données entre applications. Plusieurs solutions propriétaires pour ce type d architecture sont proposées par les fournisseurs IT. Toutefois, d autres solutions open-source et utilisant des protocoles standards ont vu le jour ces dernières années. De manière générale, le système informatique de l entreprise doit pas résister aux changements applicatifs. L introduction d une nouvelle application doit se faire sans modifier le reste du système. Seuls le flux entrant et le flux sortant de la nouvelle application doivent être disctutés avec le fournisseur ou le développeur. Malheureusement à l heure actuelle, beaucoup d entreprises sont loin d avoir des systèmes informatiques aussi flexibles. Néanmoins, les fournisseurs IT restent très vigilants quant aux différentes possibilités d intégration de leurs applications. Il va sans dire que les entreprises privilégient les applications faciles à intégrer, celles-ci évitent beaucoup de frais de développement et de temps de perdu. Du point de vue conceptuel, lorsque l on veut construire un système informatique flexible, le premier point auquel on pense est la réutilisabilité. Souvent les applications ont des besoins communs qui peuvent être traités par un même composant. Cela facilite l évolution de ce dernier tout en évitant la redondance. Ce principe est un des fondements de l architecture orientée services ou Service Oriented Architecture (SOA) dans laquelle 1. Information Technology 3

11 4 des composants dits Services peuvent être invoqués de manière synchrone par les différents composants du système informatique. Remarquons que grâce à la montée en puissance des technologies web, notamment le langage XML et le protocole HTTP, ce type d architecture a eu beaucoup de succès auprès des entreprises ces dernières années. Parallèlement à cela, un deuxième fondement sur lequel repose ce type d architecture et qui est le découplage lâche ne semble plus tenir [12]. En effet, les applications dans une telle architecture ne sont pas complètement indépendantes vu qu elles s adressent directement aux services exposés en solicitant une réponse immédiate à leurs requêtes. Or, ceci limite l autonomie des applications et fausse l idée de découplage lâche que prône SOA. Cela étant, l utilisation de SOA reste toujours conseillée dans l implémentation des processus métiers (chaînes d actions) ou lorsque les requêtes nécessitent une réponse immédiate ( ex : transactions, etc). Event Driven Architecture (EDA) ou architecture basée sur les évènements vient renforcer la réduction du couplage entre les composants grâce notamment au caractère asynchrone des requêtes. Les composants communiquent via des évènements qui sont récoltés et centralisés par une seule entité. Cette dernière s occupe également de leur transmission aux applications interessées. Concrètement, ce type d architecture vise à récolter les évènements pour savoir l état actuel du système et pouvoir y réagir. 1.2 Objectif du mémoire Comme expliqué auparavant, l intégration d une application au sein d un système informatique déjà développé peut coûter très cher à l entreprise. Nous entendons par le terme Intégration, le fait d exposer les nouvelles fonctionnalités de l application au reste du système informatique et vice versa. En effet, les applications du S.I 2 doivent pouvoir faire appel à ces fonctions, soit directement, soit en passant par un intermédaire qui joue le rôle de convertisseur de données. L entreprise intéressée par cette méthode d intégration peut demander l intervention de techniciens qualifiés qui s occupent de la mise en place de liens (one-to-one) entre l application et le reste du système. Rappelons qu outre les dépenses, cette procédure génère un ensemble d interfaces inter-applicatives qui empêchera les applications concernées d évoluer vu leurs dépendances directes au reste du système. Ce problème est connu sous le nom de l effet spaghetti. Dans ce mémoire, nous allons nous concentrer sur une application de gestion de plate-forme temps réel qui doit être intégrée dans le S.I d un opérateur lambda. Nous proposerons une nouvelle approche pour faciliter cette tâche et offrir un ensemble le plus flexible possible. Evidemment, l application en question dispose d une couche applicative qui expose ses fonctionnalités et accepte les liens one-to-one mais le but de ce travail est de proposer une manière intelligente d accéder à ces Services tout en limitant les dépendances et en offrant plus de souplesse et de flexibilité. Clairement, nous allons proposer une solution orientée évènements permettant à cette application de s insérer dans une architecture basée sur les évènements. Ainsi, n importe quelle application du S.I pourra faire appel à ces fonctionnalités via des évènements. 2. Système d information

12 5 Pour illustrer le fonctionnement souhaité, rien de mieux qu un exemple concret : Un évènement A, qui représente une demande de création d un nouveau compte pour un client, se déclenche dans l application X du S.I. Il est avalé par l entité centrale qui collecte les évènements et transmis à l application de gestion, dont il est sujet ici, pour être traité. Ce même évènement A pourra être transmis à toutes les applications interessées pourvu qu elles soient inscrites au niveau de l entité centrale (publish/subscribe). Cette dernière joue un rôle semblable à celui du routeur réseau mais veille en plus à la transformation des données des évènements afin qu elles soient manipulables par les différentes applications. L exemple ci-dessus explique le fonctionnement souhaité de l application dans une architecture basée sur les évènements. Malheureusement, beaucoup d opérateurs ne disposent pas encore de ce genre d architecture. En annexe de ce mémoire se trouve un guide d implémentation d architecture basée sur les évènements à partir d outils open-source et respectant les standards actuels. Notre but ultime est de montrer les avantages d une architecture basée sur les évènement et tout ce qu elle peut apporter à l entreprise. 1.3 Organisation du mémoire Ce mémoire commencera par une étude complète de l architecture IT des entreprises. Nous verrons l ensemble des composants du système informatique ainsi que les différentes technologies d intégration : Enterprise Application Integration (EAI), Enterprise Service Bus (ESB), etc. Nous discuterons le rôle central de l ESB dans l intégration d applications d entreprise et comment l architecture SOA peut-elle être implémentée à travers l EDA. Le troisième chapitre est consacré à l EDA. Nous verrons ses caractéristiques en détail ainsi que les différents éléments qui la composent. Ensuite, le quatrième chapitre abordera l ensemble des outils et des technologies d implémentation qui sont utilisées dans la conception de l application de gestion de la plate-forme temps réel (Eclipse Modeling Framework (EMF), Java Emitter Templates (JET), JBoss, Enterprise JavaBean (EJB), etc). Le dernier chapitre présentera l architecture de l application ainsi que l implémentation détaillée de la solution. Rappelons que cette solution vise l intégration intelligente de cette application dans une architecture basée sur les évènements(eda). Enfin, ce mémoire se terminera par une conclusion qui reprendra les apports et les résultats de ce travail.

13 Chapitre 2 Architecture logicielle d entreprises 2.1 Introduction Aujourd hui, les entreprises s orientent vers l intégration des applications avec comme objectif de permettre la communication entre toutes les applications qu elles soient développées en interne ou en externe. Parallèlement à cela, on remarque une tendance des entreprises à aller vers des solutions logicielles orientées services. On constate aussi le fort accroissement de l utilisation des processus métier par les dirigeants IT. Dans ce chapitre, nous allons montrer les changements impliqués par l introduction des processus métiers au niveau de l architecture IT. Nous verrons comment l ensemble des couches applicatives s adapte pour bénéficier des apports de l architecture orientée services et surtout comment réconcilier les processus métier, la SOA et l intégration des applications. La figure suivante illustre les différentes couches applicatives qui seront décortiquées dans la suite. Figure 2.1 Couches applicatives

14 7 2.2 La couche de présentation La couche de présentation utilise les opérations des couches inférieures pour accomplir les fonctionnalités demandées par les utilisateurs au travers des interfaces Homme- Machine. Il est important de bien séparer les composants de cette couche des autres composants afin d éviter de dupliquer du code et d améliorer l indépendance entre les couches. Le portail (figure 2.1) va permettre aux utilisateurs d avoir un point d accès unique pour accéder aux composants et aux ressources de la couche de présentation. 2.3 La couche des processus métiers Aujourd hui, les processus métiers sont devenus essentiels pour les dirigeants IT et permettent de formaliser le savoir-faire de l entreprise. Leur optimisation demeure le meilleur moyen pour améliorer la productivité de l entreprise et faire face aux exigences des clients. On appelle processus métier ou processus opérationnel un ensemble de fonctions métiers qui mènent à un résultat tangible. On peut prendre pour exemple le processus métier vente de produits sur internet qui peut être décortiqué en plusieurs étapes ou sous-processus métier : parcourir les produits, choix d un ou plusieurs produits, commande et réception du produit par le client. Figure 2.2 processus métier : vente de produits sur internet Naturellement, l architecture IT de l entreprise se doit d offrir de nouvelles fonctionnalités pour l intégration et la gestion régulière de ces processus. Pour ce faire, une

15 8 nouvelle couche est introduite dans le modèle informatique traditionnel. Il s agit de la couche des processus métier ou Business Process Layer (BPL). Cette couche se trouve entre la couche présentation et la couche d intégration et contient : 1. Les modèles des processus métier. 2. Les règles associées aux modèles. 3. L ordonnancement des processus. 4. Les données nécessaires pour la transformation des données. Elle doit assurer : L intégration des données provenant de tous les composants. Le transport des données entre applications. Gestion des processus métier grâce au Business Process Management (BPM). A ce niveau, chaque processus métier définit les services métier qu il va utiliser et qui vont être orchestrés par le BPM BPM : Business Process Management Comme expliqué auparavant, les processus métier permettent de formaliser le savoirfaire de l entreprise et s alignent sur le concept de SOA. Cependant, l entreprise doit avoir les outils et les méthodes pour gérer ses processus métier. C est le rôle du BPM. Le BPM permet d avoir une vue globale sur l ensemble des processus métier et offre la possibilité de s adapter à de nouvelles situations. Une Solution BPM est composée de plusieurs éléments : Un outil de modélisation qui permet de décrire les procédures de production en processus (voir l exemple de vente de produits sur internet : figure 2.2) Des outils d aide à l implémentation. Un moteur d exécution de processus. Des outils d administration pour paramétrer l ensemble des processus et analyser les données collectées après l exécution des processus. Parmi ces outils, on peut trouver le Business Activity Management (BAM) qui permet de suivre l activité d un processus métier. L adoption d une telle solution doit passer par plusieurs étapes : 1. Etude de l entreprise afin de déterminer les processus métier. 2. Modélisation des processus métiers. 3. Implémentation de la solution 4. Exécution 5. Pilotage : analyser l état des processus ainsi que leurs performances. 6. Optimisation : amélioration des performances des processus métiers. Le BPM offre aux entreprises la possibilité de gérer le cycle de vie complet de leurs processus métiers : identification, modélisation, implémentation, exécution, analyse et optimisation des processus métier. Ceci améliore les performances et rend le système et les processus métier adaptables aux changements potentiels.

16 BAM : Business Activity Monitoring De son côté, le BAM a pour objectif de s adresser spécifiquement au responsable métier plutôt que technique. Pour cela, le BAM va s appuyer sur le Service Activity Monitoring (SAM) pour récolter des informations sur l état de fonctionnement des processus. Les informations collectées seront présentées aux utilisateurs au travers de la console de supervision BAM SAM : Service Activity Monitoring Le SAM permet de contrôler et de mesurer les performances techniques de la plateforme et des services déployés. 2.4 La couche d intégration Deux technologies sont principalement utilisées pour l intégration des applications au sein des entreprises : EAI pour Enterprise Application Integration L Intégration d applications d entreprise ou en anglais Enterprise Application Integration, est une architecture intergicielle permettant à des applications hétérogènes de gérer leurs échanges IBM.fr Le système informatique des entreprises est constitué de plusieurs applications qui communiquent entre elles grâce à des passerelles ou des interfaces dont le temps de réalisation peut être assez important. L idée de base de l EAI est de créer un concentrateur qui reçoit le flux de donnée de sortie de chaque application, le traite et le redistribue aux applications intéressées. Ainsi, l ajout de nouvelles applications s effectue avec plus de rapidité et consiste à modifier simplement le point d entrée et de sortie de cette dernière afin de la brancher sur le concentrateur. Elle pourra, dés lors, bénéficier du flux de données provenant d autres composants du système. Dans cette architecture (figure 2.3), les applications peuvent fonctionner indépendamment les unes des autres grâce aux éléments suivants : Les connecteurs : Ce sont les interfaces entre l EAI et les applications. Ils s occupent de la transmission de données entre l EAI et les applications. Objet Métier Spécifique (OMS) : ou en anglais Application Specific Business Objects. Ce sont les données qui transitent entre l EAI et les applications Objet Métier (OM) : Objet de métier standard, les connecteurs transforment les OMS en OM (modèle de donnée global) avant d être traités. Protocoles au niveau de la couche de transport (comme HyperText Transfer Protocol (HTTP))

17 10 Figure 2.3 Entreprise Application Integration Il existe deux types d architecture de base pour l intégration d applications d entreprise : Architecture Hub and spoke Cette architecture est constituée d un point de connexion central et d un ensemble d adaptateurs qui permettent de connecter l ensemble des applications (réseau en étoile). Les adaptateurs reçoivent les messages d informations et les transmettent au système de messagerie qui s occupe de la transformation, traduction et routage de l information vers les modules intéressés. Il est évident qu avoir un point central rend l architecture facile à gérer mais constitue un handicap au niveau de l extension (lorsque le nombre limite d opérations est atteint au niveau du concentrateur). Dans ce cas, on peut très bien imaginer une architecture basée sur plusieurs Hub et dont les règles peuvent être définies de manière globale et propagées sur l ensemble des concentrateurs. Architecture basée sur un Bus Dans cette architecture, les messages publiés par les adaptateurs transitent via un Backbone (bus) et sont transmis aux applications inscrites sur le bus. Chaque application est dotée d adaptateurs qui s occupent de la transformation de ses messages dans le bon format. Cette architecture règle le problème d extension car la charge du système est répartie sur l ensemble des noeuds (point de connexion à une application), ce qui est censé offrir de meilleures performances. Les solutions EAI proposées aux entreprises utilisent des protocoles et des interfaces propriétaires qui ne sont pas en principe compatibles avec ceux d autres fournisseurs de solutions EAI, ce point essentiel limite l interopérabilité entre les entreprises qui utilisent des solutions EAI différentes. L ESB solutionne ce problème en s appuyant sur

18 11 Figure 2.4 Illustration de l Architecture Hub and spoke Figure 2.5 Illustration de l Architecture Bus des standards comme le langage extensible Markup Language (XML) et la norme Web Service (WS) ESB pour Enterprise Service Bus L ESB est une plate-forme d intégration qui met en application la notion de SOA. La notion de SOA est un modèle architectural qui a pour principe d augmenter l efficacité, l agilité et la productivité d une entreprise en plaçant la notion de services comme le moyen principal pour atteindre les objectifs stratégiques [12]. Dans la terminologie SOA [12], on distingue différents type de services : Les Services Create, Read, Update, Delete (CRUD) permettent de créer, rechercher, mettre à jour ou supprimer des données dans des référentiels (base de données, annuaire, fichier, etc). Les Services Techniques donnent accès à une ressource technique telle que : une base de données relationnelle, une imprimante, un système de trace d information, un progiciel de type Enterprise Resource Planning (ERP), un serveur de messagerie, etc. Les Services Applicatifs sont des services de haut niveau (également appelés

19 12 Figure 2.6 Enterprise Service Bus services de façade) qui masquent aux applications composites les services de plus bas niveau tels que les Services CRUD ou techniques. Les Services Fonctionnels sont des services métiers qui encapsulent la logique et les règles métiers des processus. Ce sont les services fonctionnels qui sont déployés au niveau de l ESB, grâce notamment à Service Component Architecture (SCA) qui est un ensemble de spécifications visant à simplifier la création et la composition de services (indépendamment de leur implémentation) dans le cadre de SOA. Pour revenir à l ESB, il s agit d un bus représentant le backbone et qui est responsable de la transformation, du formatage et du routage des différents messages envoyés par les différents services et applications reliés à l ESB. Les avantages de cette architecture par rapport à l architecture Bus de l EAI présentée ci-dessus sont : 1. Le fait que les connecteurs utilisent des technologies standards comme Java Messaging Service (JMS), File Transfer Protocol (FTP), HTTP, Web service, etc. 2. Le routage intelligent, 3. Le coût d implémentation est moins élevé que dans le cas d un bus propriétaire, 4. l ESB n utilise pas des formats propriétaire contrairement aux solutions EAI. Le routage intelligent se base sur le contenu du message afin d acheminer les données (le concept de Content Based Routing (CBR), Ainsi l ESB déduit le destinataire du message en fonction de son contenu et des règles prédéfinies. Chaque règle contient une condition ainsi que la référence du destinataire au cas où le message vérifie la condition de la règle. En résumé, l ESB permet de composer les services fonctionnels afin d assurer l intégration des données comme expliqué ci-dessus. L information reçue par les connecteurs suit

20 13 une certaine logique d intégration (transformation, formatage, etc) avant d arriver au système de messagerie, ce qui la rend indépendante de l aspect propriétaire. Les connecteurs Les connecteurs ou gateways représentent les points d entrés de l ESB, leur rôle est de déplacer l information de l extérieur vers l intérieur de l ESB tout en l adaptant pour qu elle soit manipulable par les composants internes. À nouveau, pour garder cette idée de souplesse, chaque connecteur doit traiter un seul type de message afin de lui apporter les transformations nécessaires. Ceci permet de spécialiser chaque connecteur en lui associant un type de message précis. Lorsqu on dispose d un ensemble d applications non homogènes, il pourrait être intéressant d offrir un ensemble de type connecteurs varié et utilisant des technologies différentes pour faciliter la connection des applications. On constate aujourd hui le développement de nouveaux types de connecteurs. On y trouve des connecteurs de type HTTP, JMS, Simple Object Access Protocol (SOAP), Simple Mail Transfer Protocol (SMTP), FTP, file, Java Connector Architecture (JCA), Java DataBase Connectivity (JDBC), etc. MOM pour Message Oriented Middleware Un des fondements de l ESB est le Message Oriented Middleware (MOM) qui est le cœur de cette architecture. Il permet l échange de messages asynchrones entre applications et garantit la livraison des messages (que le destinataire préinscrit soit disponible ou non, les messages seront mis en attente de réception). Il peut aussi assurer la persistance des messages qu il reçoit, il suffit de marquer un message comme persistant et le MOM se chargera d assurer qu il ne soit jamais perdu (en faisant des backups sur le disque). Le MOM a un mode de fonctionnement asynchrone. Comme expliqué précédemment, l émetteur et le récepteur ne doivent pas être disponibles en même temps, l émetteur interagit avec le serveur de messagerie au cours d une transaction locale et ignore si les parties intéressées par son message sont disponibles au moment de la transaction. Certaines implémentations du MOM prévoient même un modèle de regroupement de transactions en une seule appelé le mode all-or-nothing. Dans ce mode, l émetteur peut échanger plusieurs messages avec le serveur de messagerie sans que ce dernier n en fasse part aux parties intéressées. Seul l envoi de la commande commit de la part de l émetteur rend l information disponible aux modules intéressés (ce principe est très semblable à celui des base de données). De même, la commande rollback permet l annulation de la transaction. Dans certaines implémentations, le MOM fournit des interfaces pour la manipulation des ressources pendant une transaction. Un message est composé de trois parties : un header, des propriétés, et un corps. Le header renseigne sur la source du message, la destination de la réponse si celle ci est exigée par l émetteur, type de message, etc. Les propriétés sont représentées par des paires (nom,valeur) et sont vérifiées par les filtres de consommateur ou des routeurs spécialisés.

21 14 Figure 2.7 La relation Publish and Subscribe Il est important de savoir que chaque entité communicante joue le rôle de producteur et de consommateur de messages. Les producteurs et les consommateurs sont dits loosely coupled. Cela veut dire qu ils ne sont pas directement liés, mais qu ils sont reliés de façon abstraite via des canaux virtuels appelés les canaux publish-and-subscribe ou à travers des canaux point-to-point. Le producteur de messages n a pas besoin de savoir qui va recevoir les messages, de même, le consommateur est complètement indépendant du producteur des messages. Toutefois, si le producteur du message veut exiger une réponse de la part du consommateur, il doit inclure l adresse de réponse dans l entête du message. La relation publish-and-subscribe est une relation one-to-many. Cela étant, les consommateurs doivent s inscrire pour un topic (Sujet) dans lequel le producteur va faire des publications. Ainsi chaque consommateur inscrit pour un topic reçoit les messages qui concernent ce dernier. Le deuxième type de relation, à savoir la relation point-to-point, est une relation one-to-one où les messages du producteur sont stockés dans une queue en attendant d être consommé par un seul consommateur. Notons que le choix du modèle d échange (publish-and-subscribe ou point-to-point) dépend du nombre de consommateurs potentiels. Les conteneurs de services d intégration Le conteneur de services est l élément qui va se charger d héberger et de composer les services d intégration. L utilisation de conteneurs de services simples et légers permet de réaliser une intégration complètement distribuée. Ces conteneurs peuvent héberger un ou plusieurs services et manipulent le flux entrant et sortant du service. Il existe une multitude de services parmi lesquels on peut citer : Les services de sécurité implémentant les standards WS-Security,

22 15 Les services de transformation de messages offrant par exemple le support des transformations extensible Stylesheet Language (XSL), Les services de routage des messages, Les services d audit et de log offrant la mécanique pour tracer des informations, etc. La différence entre les conteneurs de services d intégration de l ESB et les conteneurs de services d application comme (le JBoss Application Server (AS) par exemple) est que ces derniers hébergent des fonctions métier et des pages web tant dis que les conteneurs de services d intégration de l ESB hébergent les services d intégration et procèdent à l intégration des flux de données. Cela veut dire que les données vont suivre un certain parcours à l intérieur de l ESB et que leur présentation va être adaptée pour qu elle soit compatible avec le service qui va les utiliser. 2.5 La couche des services Cette couche regroupe l ensemble des éléments requis pour modéliser, construire, tester et déployer les services. Ici, nous allons nous intéresser à deux types de services : les services d intégration et les services CRUD. Ces derniers sont accessibles au système opérationnel de l entreprise (applications traditionnelles, composants, base de données, etc) comme c est le cas des servies métiers se trouvant au niveau de la couche des processus métier. L avantage majeur d un service CRUD est sa réutilisabilité vu qu il peut, notamment grâce aux interfaces SOAP, recevoir des requêtes à partir de n importe quelle application, pourvu qu elle respecte ses paramètres. Remarquons qu un service peut être construit par composition d autres services, de même que la composition de services peut faire intervenir des services distribués. Enfin, les paramètres d un service sont souvent décrit au travers un fichier Web Services Description Language (WSDL) (connu grâce aux Web Services). 2.6 La couche des applications Dans cette partie, nous allons nous intéresser à certaines méthodes logicielles devenues aujourd hui incontournables au sein des entreprises. Nous montrerons comment on conçoit les applications Java orientées entreprise, notamment en utilisant des modèles de conception appelés communément Design patterns. Ces derniers ne sont pas liés à un langage de programmation et peuvent être implémentés sous différentes formes. Les applications Java Enterprise dépendent principalement de deux éléments qui seront présentées dans les sections suivantes : L infrastructure d exécution offerte par JEE (section 2.6.2). La puissance de la programmation basée sur les évènements (section 2.6.3) Utilisation des design Patterns en Java Le travail du concepteur de programmes a toujours été consisté en deux choses : analyser et développer des applications afin de répondre aux besoins des utilisateurs.

23 16 Souvent, les programmeurs ne disposant d aucune expérience essaient de mettre en pratique la théorie apprise à l école et ainsi construire petit à petit leurs applications en pensant toujours à la premiere version finalisée de l application. Seulement, l application ne reste jamais à sa première version et des dizaines de modifications doivent être apportées par la suite. Des modification mineures du code peuvent engendrer énormément de bugs et d anomalies de fonctionnement dans ce genre d applications. Le concepteur finit par être saturé par la complexité du codage (effet spaghetti). J en veux pour preuve ma propre expérience sur une application Java d environ lignes de code. Sans architecture de base, cette application est devenue progressivement ingérable avec pour conséquence l émergence de bugs de plus en plus difficiles à corriger (effet dominos). Pour recadrer les choses, il faut dire qu une application doit toujours pouvoir évoluer. Le code de l application doit être fermé aux modifications et ouvert à l évolution. Pour ce faire, des modèles de conceptions ont été définis afin de permettre au programmeur de concevoir des applications flexibles et qui peuvent faire face aux changements. Les design patterns ou modèles de conception décrivent des organisations pratiques des classes d objet. Ces organisations résultent souvent d une conception empirique, le concepteur objet tente de faciliter la réutilisation et la maintenance du code. On peut donc concevoir un modèle d application comme une forme d organisation transposable à plusieurs applications. Ces systèmes peuvent apparaître complèxes aux débutants voire inutiles, il est pourtant très important d en connaître plusieurs et de les appliquer systématiquement (dans les cas reconnus comme pouvant évoluer). L architecte objet se construit petit à petit un panier de modèles. Les design patterns ne sont pas réellement normalisés, mais on peut les découper en trois grandes catégories : Les modèles de création : Ces modèles sont très courants pour déléguer à d autres classes la construction des objets. ex : le pattern Factory, le pattern Facade. Les modèles de structure : Ces modèles de conception tentent de composer des classes pour bâtir de nouvelles structures. ex : le pattern Adapter, le pattern Proxy. Les modèles de comportement : Ces modèles tentent de répartir les responsabilités entre chaque classe (l usage est plutôt dynamique). ex : Template, Iterator. Si on voulait faire un parallèle avec UML, les deux premiers modèles seraient liés à des diagrammes statiques (de classes) alors que le dernier modèle est davantage lié à un diagramme dynamique (de séquence) Infrastructure d exécution offerte par JEE Java Enterprise Edition (JEE) est une norme proposée par la société Sun, portée par un consortium de sociétés internationales, visant à définir un standard de développement d applications d entreprises multi-niveaux, basées sur des composants. On parle généralement de plate-forme JEE pour désigner l ensemble constitué des services-application Programming Interface (API) offerts et de l infrastructure d exécution. JEE comprend notamment : Les spécifications du serveur d application, c est-à-dire de l environnement d exécution : JEE définit finement les rôles et les interfaces pour les applications

24 17 ainsi que l environnement dans lequel elles seront exécutées. Ces recommandations permettent ainsi à des entreprises tierces de développer des serveurs d application conformes aux spécifications ainsi définies, sans avoir à redévelopper les principaux services. Des services, au travers d API, c est-à-dire des extensions Java indépendantes permettant d offrir en standard un certain nombre de fonctionnalités. Sun fournit une implémentation minimale de ces API appelée JEE Software Development Kit (SDK). Dans la mesure où JEE s appuie entièrement sur le Java, il bénéficie des avantages de ce langage, en particulier une bonne portabilité et une maintenabilité du code. De plus, l architecture JEE repose sur des composants distincts, interchangeables et distribués, ce qui signifie notamment : qu il est simple d étendre l architecture ; qu un système reposant sur JEE peut posséder des mécanismes de haute-disponibilité, afin de garantir une bonne qualité de service ; que la maintenabilité des applications est facilitée. Les API de JEE Les API de JEE peuvent se répartir en trois grandes catégories : Les composants. On distingue habituellement deux familles de composants : Les composants web : Servlets et Java Server Page (JSP). Il s agit de la partie chargée de l interface avec l utilisateur (on parle de logique de présentation). Figure 2.8 Architecture d une application Java entreprise

25 18 Les composants métier : EJB. Il s agit de composants spécifiques chargés des traitements des données propres à un secteur d activité (on parle de logique métier ou de logique applicative) et de l interfaçage avec les bases de données. Les services, pouvent être classés par catégories : Les services d infrastructures : il en existe un grand nombre, définis ci-dessous : JDBC est une API d accès aux bases de données relationnelles. Java Naming and Directory Interface (JNDI) est une API d accès aux services de nommage et aux annuaires d entreprises tels que Domain Name System (DNS), Network Information Service (NIS), Lightweight Directory Access Protocol (LDAP), etc. Java Transaction API (JTA)/Java Transaction Services (JTS) est une API définissant des interfaces standard avec un gestionnaire de transactions. JCA est une API de connexion au système d information de l entreprise, notamment aux systèmes dits Legacy tels que les ERP. Java Management Extension (JMX) fournit des extensions permettant de développer des applications web de supervision d applications. Les services de communication : Java Authentication and Authorization Service (JAAS) est une API de gestion de l authentification et des droits d accès. JavaMail est une API permettant l envoi de courrier électronique. JMS fournit des fonctionnalités de communication asynchrone (appelées MOM) entre applications. Remote Method Invocation (RMI)-Internet Inter-Orb Protocol (IIOP) est une API permettant la communication synchrone entre objets. L architecture JEE permet ainsi de séparer les couches suivantes : La couche de présentation, correspondant à l Interface Homme-machine (IHM). La couche métier contenant l essentiel des traitements de données. Cette couche se base dans la mesure du possible sur des API existantes. La couche de données, correspondant aux informations de l entreprise stockées dans des bases de données relationnelles ou dans des systèmes d information complexes Java et la programmation basée sur les évènements Dans les applications Java, les évènements représentent une information centrale autour de laquelle, des modèles ont été développés pour en assurer la gestion et le traitement. L idée de base étant de séparer les composants et de leur permettre de communiquer entre eux via des évènements. Ainsi, on peut distinguer les émetteurs d évènements et les récepteurs d évènements. Un composant X peut s inscrire chez un composant comme étant intéressé par un évènement alpha. Lorsque l évènement alpha se déclenche au niveau du composant Y, le composant X reçoit immédiatement une information décrivant l évènement en question. En Java, un évènement est un message, c est-à-dire un objet qui transite d un émetteur à un récepteur. La généralisation des références Java nous permet de faire interpréter ce que veut dire transiter : L évènement est un objet construit par l émetteur, et dont la référence est donnée de proche en proche jusqu au récepteur. Un évènement Java est donc un objet. Une bonne compréhension de : La notion d évènements ;

26 19 De leur nature ; De leur niveau d abstraction ; Des styles de traitement ; De la qualité de services exigée. permet de tirer les bénéfices de la programmation basée sur les évènements. Clairement, il existe quatre éléments de base pour la conception d un noyau de gestion d évènements : L évènement caractérisé par un type et des attributs ; L émetteur (ou source) qui émet des évènements ; Le récepteur qui s abonne à des évènements et en reçoit ; L aiguilleur (ou dispatcher) qui transmet les évènements d un émetteur à plusieurs récepteurs. La pattern Observateur/Observé, ainsi que d autres design patterns, ont aidé au développement de la fameuse architecture Model View Controler (MVC). Cette méthode de conception consiste à distinguer trois entités distinctes qui sont, le modèle, la vue et le contrôleur ayant chacun un rôle précis dans l interface graphique. L organisation globale d une interface graphique est souvent délicate. Bien que la façon MVC d organiser une interface ne soit pas la solution miracle, elle fournit souvent une première approche qui peut ensuite être adaptée. Elle offre aussi un cadre pour structurer une application. Dans l architecture MVC, les rôles des trois entités sont les suivants. Modèle : données (accès et mise à jour) Vue : interface utilisateur (entrées et sorties) Contrôleur : gestion des évènements et synchronisation Interactions Les différentes interactions entre le modèle, la vue et le contrôleur sont résumées par le schéma de la figure suivante. Figure 2.9 Modèle-Vue-Controleur

27 20 Il est à noter que les applications d entreprise sont implémentées afin de communiquer avec les EJBs qui sont déployés sur le serveur applicatif. Dans cet environnement client/serveur, le modèle de données se trouve au niveau du serveur applicatif. Ce dernier héberge, entre autres, les connecteurs vers la base de données. Du côté client, on trouve : Les différentes vues (interfaces) utilisant des objets de transfert qui adaptent les objets du modèle. En effet, ces objets étendent les objets du modèle en rajoutant des attributs qui facilitent l affichage, le rafraichissement, la manipulation, etc. Les contrôleurs gèrent les actions des utilisateurs et veillent à la cohérence des données. Figure 2.10 Modèle-Vue-Contrôleur dans une application JEE Toujours dans ce mode de fonctionnement, l accès aux composants responsables du traitement de données (les EJBs) se fait en utilisant RMI (section 4.5.1) ou la norme WS. Cette dernière a eu un succés fulgurant ces dernières années, et ce principalement grâce au langage XML et le protocole HTTP. Par ailleurs, les entreprises ne disposant pas d un système informatique assez fiable pour supporter l ensemble des applications ont commencé à se diriger vers des fournisseurs IT capables d héberger des serveurs applicatifs, des bases de donnée et autre. Ce concept qui fut appelé Cloud Computing permet aux entreprises de se concentrer sur la couche de présentation et d utiliser le système informatique du fournisseur pour implémenter les couches inférieures. La section suivante décortiquera les différents aspects qui touchent à ce concept.

28 Cloud Computing Introduction Informatique en nuage ou encore infonuagique. Ce sont les différentes traductions que l on peut trouver sur internet. Il s agit d un nouveau concept qui est en train de se mettre en place petit à petit dans les entreprises. Le principe étant d utiliser les capacités de calcul et de stockage offertes par des parties tierces. Ainsi, tous les programmes et toutes les données sont déplacées sur cette informatique en nuage qui est considéré comme un réseau de calcul capable d évoluer et d offrir des ressources virtuelles sous forme de service (via internet) en fonction des besoins de l utilisateur [7]. Généralement, Enterprise Service Cloud (ESC) offre des services qui agissent sur trois niveaux. Infrastructure as a Service (IAAS) : ou encore Hardware as a Service. Cela consite à fournir toute une infrastructure informatique en tant que service. Amazon.com est un des plus grand fournisseurs pour ce type de services. Amazon Elastic Compute Cloud (EC2) et Amazon Simple Storage Service (S3) sont utilisés par plusieurs entreprise comme IBM, Oracle, MySQL Enterprise, etc. Dans ces systèmes, le développeur commence par créer une Amazon Machine Image (AMI) qui contient le système d exploitation ainsi que tous les programmes dont il a besoin. Le rajout d une nouvelle AMI à S3, la rend automatiquement disponible dans EC2. Le développeur peut, ensuite, gérer toutes les ressources qui s exécutent dans l environnement informatique de Amazon [2, 3]. Platform As A Service (PAAS) : consiste à fournir des plates-formes informatique. Les développeurs peuvent utiliser ces plates-formes pour déployer leurs applications sans devoir acquérir le matériel ou le logiciel utilisé par la plate-forme. Google App Engine [5] est un exemple de plate-forme qui permet aux développeurs d exécuter leurs applications web en utilisant l infrastructure de Google. Cette dernière offre un support complet pour la création, l exécution et la gestion des application web. Software As A Service (SAAS) : exploite les avantages de l architecture SOA pour fournir des services à travers internet. Figure 2.11 Tout comme service. X=? [13]

29 SOCCA : Service Oriented Cloud Computing Architecture SOA et l informatique en nuage sont étroitement liés. En effet, SOA est un style architectural qui permet de créer des solutions métier dont les composants peuvent être réutilisables, tandis que l informatique en nuage est un ensemble de technologies utilisé par des plate-forme très flexibles au sein de l architecture SOA de l entreprise. L architecture Service Oriented Cloud Computing Architecture (SOCCA) peut être vue sous forme de couches (figure 2.7.2) : Figure 2.12 Service Oriented Cloud Computing Architecture [13] Individual Cloud Provider Layer : Cette couche représente les différentes implémentations constituant les nuages. Chaque fournisseur d informatique en nuage dispose d un centre de données qui alimente les services fournis. De plus, chaque nuage doit avoir sa propre technologie de virtualisation. Le Dispacher fonctionne en parallète avec le moniteur de machines virtuelles afin d allouer les ressources demandées. Ces ressources sont regroupées sous forme de services indépendants comme le service de stockage, le service de calcul ou encore le service de communication. Ils disposent notamment d interface open-standardisé 1 qui permettent leur combinaison avec les services des autres fournisseurs. Cloud Ontology Mapping Layer : Le rôle principal de cette couche est de cacher les différences parmi les fournisseurs d informatique en nuage. Elle peut aussi être utile lors de la migration d une 1. Open-source et utilisant des standards

30 23 application d un nuage à un autre. Plusieurs système d ontologie 2 doivent être présents au niveau de cette couche : Ontologie du stockage : Définit les concepts et les termes liés à la manipulation des données au sein des nuages (mise à jour, insertion, suppression de données, sélection de données, etc) Ontologie du calcul : Définit l ensemble des concepts et des termes liés au calcul distribué au niveau des nuages Ontologie de la communication : Définit les concepts et les termes liés aux schémas de communication dans les nuages ( schéma d encodage, routage des messages, etc) Cloud Broker Layer : Cette couche héberge les agents intermédiares entre les fournisseurs d informatique en nuage et la couche de SOA. Chaque Service du nuage est associé à un type de service broker. Ce dernier s occupe des tâches suivantes : Publication des informations venant des fournisseurs : Chaque fournisseur publie ses spécifications ainsi que des informations liées au prix. Ces données incluent, entre autres : Des informations sur le fournisseur : le nom de l entreprise du fournisseur, son adresse, son adresse web, etc. Des informations sur les ressources disponibles : Que ce soit des ressources de calcul, de stockage ou de communication, le fournisseur communique les spécifications ainsi que la limitation concernant la ressource. Des informations sur les prix : Ces prix varient d un fournisseur à un autre. Ils peuvent aussi être influencés par les variations du marché. Classification : Les brokers s occupent de la classification des ressources publiées. Les services peuvent être classés selon plusieurs critères parmi lesquels on peut citer : Le prix, la disponibilité, le niveau de sécurité, etc Provision des ressources en fonction de la demande : La meilleure façon pour répondre convenablement aux besoins de l utilisateur consiste à analyser son utilisation actuelle des ressources afin de prédir et de prévoir ses exigences futures. SOA Layer : Cette couche reprend les mêmes fonctionnalités qu une SOA traditionnelle. Certains framework existants tel que CCSOA et UCSOA peuvent être intégrés au niveau de cette couche. Il importe de savoir que d autres artéfacts peuvent y être publiés et partagés comme les templates, et en particulier les templates de collaboration, ainsi que les cas de test. Le registre des services est indexé pour chaque type d artéfact et organisé suivant l ontologie. La différence fondamentale entre la couche SOA de SOCCA et une SOA traditionnelle est que les fournisseurs de services n hébergent plus directement les services publiés. Les services sont plutôt publiés sous forme de packages qui peuvent être facilement répliqués et redéployés sur les différents environnements des nuages. Le développeur a aussi la possibilité de désigner le nuage sur lequel sera déployé le package. 2. Ensemble structuré des termes et concepts représentant le sens d un champ d information

31 ISB : Internet Service Bus Par Informatique en nuage, on entend le déplacement des programmes et des données vers les nuages afin qu elles puissent exploiter l infrastructure du fournisseur au lieu de s exécuter sur une machine locale. Toujours dans le même ordre d idées, l ESB peut monter dans les nuages. Le principe est relativement simple. Il s agit de standardiser les mécanismes liés à l ensemble des tâches accomplies par le bus d entreprises pour les exposer sur Internet. On parle alors d Internet Service Bus (ISB) par analogie à l ESB pour définir ce concept de middleware orienté messages que l on distribue via l Informatique en nuage. L approche la plus simple pour implémenter un ISB consite à activer les services de l ESB pour qu ils soient disponibles sur internet. Cette approche n est pas très intéressante car l ISB, bien qu il héberge des services qui sont accessibles via internet doit permettre le déplacement de services déployés vers les nuages d informatique. La sécurité est un autre point qu il faut prendre en considération. Un utilisateur authentifié pour utiliser l ISB doit pouvoir effectuer des communications sécurisées à travers tous les noeuds par lesquels ses messages vont transiter. Microsoft et linxter ont été les premiers à avoir implémenté un ISB (respectivement BizTalk Services et linxter ISB). Plusieurs concepts doivent être examinés au niveau de ces implémentations : Le registre des services Le nommage L identification et le contrôle d accès La connectivité Le registre des services Il s agit d un registre commun contenant l ensemble des services hebergés par l ISB. Ce point central peut être interrogé par l ensemble des services de médiation. Le nommage Les différents Services ou End Point Reference (EPR) doivent être facilement identifiables grâce à l utilisation de conventions de nommage comme l Unique Resource Identifier (URI). L identification et le contrôle d accès Il importe de savoir quels mécanismes de sécurité seront mis en oeuvre(active Directory, OpenID, etc) et quelle méthode d identification/authentification sera utilisée pour chaque service. La connectivité L ISB doit fournir des services de médiation tout en cachant les différents aspects liés à la communication. En plus de ces services, il doit s occuper de l acheminement des messages aux services et ce, en exploitant les queues et les topics comme au niveau de

32 25 l ESB. Comme expliqué plus haut, les URI sont utilisés pour identifier les services. Ainsi, chaque application peut être vue comme un ensemble d URI, de règles et de fonctions. Enfin, l ISB permet de contrôler l échange de messages en se basant sur l URI de l émetteur et l URI du récepteur. Exemple d implémentation : Linxter ISB La solution développée par Linxter vise à offrir l ISB en tant que PAAS et offre un SDK permettant de communiquer avec l ISB. Ce dernier contient une collection de services : Inbound Service : Manipule les messages qui sont envoyés par les instances d applications. Outbound service : Achemine les messages aux différentes instances (en attente de messages). Object store service : Manipule les attachements dans les messages. Hostname sevice : Gère les adresses utilisées par les instances d applications pour l appel des services. Registration service : S occupe de l inscription des instances d applications et la génération des tokens. La figure illustre la possibilité de créer plusieurs instances d ISB, chacune contient les services décrit ci-dessus. Le SDK de linxter fournit, en outre, les outils permettant d assurer la redondance ainsi que le load balancing entre ces différentes instances. Figure 2.13 Linxter ISB [10]

33 Chapitre 3 Event Driven Architecture 3.1 Introduction Dans certains entreprises, il est parfois nécessaire de mettre en place des moyens pour détecter les évènements qui y sont en train de se produire et ainsi observer leurs symptômes [4]. Hier encore, un utilisateur m a appelé au travail pour me signaler que son application était devenue trop lente au moment de la sauvegarde. Malheureusement, il m a fallu 10 minutes de vérifications pour me rendre que ce problème était dû à un évènement qui s était produit bien avant que l utilisateur ne commence à se plaindre. L arrêt d un serveur auxiliaire en était la cause. Le traitement automatisé des évènements qui se produisent dans le monde réel peut révolutionner notre façon de vivre. Dans la suite, nous allons citer quelques exemples qui illustrent le besoin accru d un traitement automatisé des évènements. Un patient arrive dans un hôpital et patiente dans la salle d attente pendant une demi heure pour être reçu par la secrétaire qui s occupe de son dossier. La secrétaire ne sait pas qui est dans la salle d attente et se base exclusivement sur les numéros de tickets pour appeler les patients. Or, Certains patients sont prioritaires parce qu ils ont un rendez-vous, d autres doivent passer par un autre bureau pour se voir créer un dossier et un rendez-vous. Il serait intéressant dans ce cas de détecter l arrivée d un patient (via une borne qui lit la carte d identité électronique ou la carte SIS du patient) pour pouvoir l appeler au bon moment et essayer d optimiser le temps d attente. On pourrait imaginer un système qui reçoit les notifications d arrivée des patients et crée automatiquement un dossier pour les patients qui n en ont pas un en se basant sur les informations de la carte électronique. Cela épargnerait beaucoup de temps à la secrétaire et au patient, Les fraudes dans les institutions financières sont souvent difficiles à détecter. Seule l analyse des différents évènements qui se produisent au niveau de la banque et dans le système de trading permet de détecter les activités illégales. De même, le vol des numéros de carte visa ne peut être détecté que si une analyse des différents évènements ( achat sur internet, argent retiré à la banque..) est effectuée en temps réel. Ce genre de traitement d évènements est appelé traitement prédictif, etc. Naturellement, la technologie doit répondre à tous ces cas de figures en offrant des solutions adaptées. Avant de s attaquer à ce sujet, voici une classification des raisons qui peuvent nous pousser à envisager le traitement automatisé des évènements : 26

34 27 La nécessite d un comportement temps réel dans les systèmes informatiques. Cela implique implicitement la capacité d adaptation dynamique des réactions du système face aux nouveaux évènements. L observation d un système dont le but de générer des alertes pour l utilisateur. La dissémination des données qui vise à diffuser l information pour arriver au bon consommateur, au bon moment et dans la bonne granularité. Le diagnostic actif. Le but ici est d utiliser des actions pour affiner le diagnostic. Le traitement prédictif dont le but est d identifier les évènements avant qu il se produisent dans le système afin de les élimiter ou de changer leur effet. 3.2 Le concept Dans le chapitre précédent, nous avons évoqué la programmation basée sur les évènements et son principe de découplage de composants. Cette approche, qui est aussi à la base de l architecture IT basée sur les évènements, permet d identifier et de réagir intelligement dans certaines situations. EDA est un style architectural qui s impose de plus en plus dans les entreprises. Par opposition à SOA où un fournisseur rend un service à la demande d un consommateur. En architecture EDA, un service prévient par émission d un évènement qu il a réalisé une opération donnée, ce qui permet de savoir l avancement en temps réel des différents processus utilisant ce service. Il est à noter que SOA décortique parfaitement les applications en service ou en composant et utilise la communication directe et synchrone entre ces composants. C est à ce niveau-ci que réside toute la différence avec l EDA. En effet, les services ou agents de l EDA envoient des requêtes sous forme d évènements sans se préocuper de leur acheminement (communication indirecte et asynchrone), ils ne sont pas censés savoir qui va recevoir l information, ni comment elle sera manipulée. Ce sera à un autre composant de s ocupper de la récolte et de la redistribution de ces évènements. Cela étant, il est possible qu un composant implémente les deux approches (SOA et EDA). Il peut alors intéragir de manière directe et synchone avec les autres composants tout en jouant le rôle de producteur et de consommateur d évènements. La figure suivante donne une idée du fonctionnement général d une EDA. Les sections suivantes décriveront ces différents composants. Figure 3.1 Architecture basée sur les évènements

35 Ses apports Avant d entamer la conception et le déploiement d une EDA, il est important de savoir les caractéristiques et les qualités de ses composants et surtout de comprendre comment ils peuvent fonctionner entre eux pour réaliser les fonctionnalités désirées de l EDA. L objectif d une telle architecture est très simple : réagir intelligemment en fonction des évènements détectés dans le système. Ce type d architecture peut être utilisé par exemple pour détecter et réagir aux vols des numéros de cartes VISA sur internet. En effet, si la banque centrale dispose d une architecture EDA, elle peut facilement surveiller les flux d évènements produits par les utilisateurs des cartes et essayer de trouver des anomalies (en se basant sur des règles prédéfinies). Une carte sera automatiquement bloquée si un retrait de 100 euros en Belgique est suivi d un achat d un article sur internet à partir de Malaisie. 3.4 Le contexte Bien que cette architecture vienne toujours avec des changements positifs, elle n est pas toujours la solution aux problèmes des entreprises. Beaucoup de facteurs doivent être examinés afin d évaluer les bénéfices et la faisabilité d une telle architecture. Il s agit notamment de contraintes logiques d applications, de contraintes sur les performances du système, de défis de l entreprise et surtout le rapport coût-rendement de l investissement. Une EDA est censée résoudre des problèmes dans lesquels il existe différents flux d évènements provenant de différentes applications ou de systèmes et où il est nécessaire d avoir un suivi en temps réel de tous les évènements et des actions déclenchées par ces évènements. 3.5 Ses caractéristiques Concentration des messages Il s agit ici de revoir sa vision de conception d applications. Dans l entreprise, certains processus métier sont composés de plusieurs services orchestrés pour obtenir le résultat final. L exemple suivant illustre le cas d un processus métier qui se déroule en quatre étapes.

36 29 Figure 3.2 Exemple de processus métier-1 [1] Un changement dans les fonctions de l application nécessite la modification du contrôleur. Dans la vision EDA, le contrôleur sera remplacé par un concentrateur de messages. Ceci rend les composants pluggable et facilite le rajout d une nouvelle étape dans le processus métier. Figure 3.3 Exemple de processus métier-2 [1]

37 Découplage lâche Lorsque nous parlons de Loose Coupling, nous désignons un concept dans lequel les composants ne sont pas directement liés entre eux, ils sont liés de façon abstraite en ayant chacun une connaissance des rôles des autres composants. Un système est dit Loose coupled s il est facilement extensible. Si nous reprenons l exemple de carte VISA, il existe aujourd hui sur internet un service (utilisé par les vendeurs) qui permet de vérifier la validité d une carte VISA. Ce dernier reçoit un numéro composé de 16 chiffres, une date d expiration et un code de vérification. Vérifier un nouveau type de carte bancaire ne doit pas nécessiter la modification du programme, une nouvelle compilation, une modification du coté du client, etc. Autrement dit, le composant doit être complément configurable, adaptable en fonction du contexte, indépendant du reste du système et il ne doit en aucun cas résister aux changements. Cela facilitera de manière significative la maintenance du service. Il est aussi important lors de la conception du composant, de penser à l utilisation de patterns comme le adapter pattern qui permet de modifier le comportement d un objet et l adapter en fonction du contexte Messagerie asynchrone Ces middelewares ont un mode de fonctionnement asynchrone, le producteur (émetteur) et consommateur (récepteur) ne doivent pas être disponibles en même temps ; l émetteur interagit avec le serveur de messagerie au cours d une transaction locale et ignore si les parties intéressées par son message sont disponibles au moment de la transaction. La relation publish-and-subscribe est une relation one-to-many. Les consommateurs doivent s inscrire pour un topic (Sujet) dans lequel le producteur va faire des publications. Ainsi chaque consommateur inscrit pour un topic reçoit les messages qui concernent ce dernier Exploitation des évènements Les informations concernant l état du processus métier doivent être stockées dans l évènement. Ceci permettra à chaque composant de l EDA de rester au courant de l avancement du processus. Il est à noter qu un modèle de données commun doit être établi pour les évènements. Pour ce faire, un ensemble de transformateurs doit être développé pour assurer la conversion des messages. Ainsi, un seul format de message sera manipulé par la système de messagerie interne de l EDA. Toujours dans le même sens, les types d évènements doivent être facilement identifiables. Il est important de définir une hiérarchie pour les noms d évènements ainsi que des dictionnaires d évènements dans lesquels doivent être répertorié tous les évènements susceptibles d être déclenchés dans l EDA.

38 Transport des messages Comme décrit ci-dessus, la messagerie asynchrone représente l épine dorsale de l EDA. Le système de messagerie doit pouvoir véhiculer des millions de messages. Des composants comme l ESB ou une Queue peuvent être utilisés pour fédérer les évènements entre les producteurs d évènements, les consommateurs d évènements ainsi que les processeurs d évènements. Figure 3.4 ESB comme Event Collector 3.6 Ses composants Notion d évènement Un évènement peut être tout ce qui arrive à l intérieur ou à l extérieur de l entreprise. Il doit contenir suffisament d informations sur le fait qui vient de se passer. Chaque évènement est composé d une entête et d un corps. L entête étant utilisée pour renseigner sur l id de l évènement, son type, sa date/heure, son créateur, etc. Elle sera lue par les intermédiaires par lequels l évènement va transiter. Le corps de l évènement décrit en détail le fait qui vient de se passer Outil de Messagerie C est le cœur de l EDA et l infrastructure qui gère les communications. C est cette partie-là qui permet aux composants de communiquer entre eux Producteurs d évènements Représente la source des évènements. Cela peut être un ordinateur ou tout autre appareil capable de communiquer. Les fournisseurs peuvent fournir des API qui permettent de communiquer facilement avec l équipement en question.

39 Consommateurs d évènements Il s agit des modules ou des applications qui sont intéressées par les évènements. Le consommateur d évènements utilise l outil de messagerie pour recevoir les évènements. Pour ce faire, il doit s inscrire pour un type spécifique d évènements Processeurs d évènements Ces composants, appelés aussi agents ou Event Processor Agent (EPA) s occupent du traitement intermédiare des évènements. Il existe plusieurs styles de traitement : Simple event processing Event stream processing Complex event processing Il faut noter que plusieurs EPA peuvent collaborer pour assurer le traitement des évènements, on parle dans ce cas de réseau de traitement d évènements. Dans un monde simpliste, les EPA s occuperaient simplement de la transmission des évènements entre producteurs et consommateurs. Dans la réalité, il faut prévoir des filtres et des outils pour la transformation et le routage des évènements. Ci-dessous la liste des types d agent qui peuvent être employés dans une architecture basée sur les évènements. Les agents simples : Ce sont tous les agents réutilisables qui s occupent de la réception des évènements, du traitement de l information ainsi que du renvoi des évènements vers leurs destination. Par traitement, nous entendons des opérations de transformation, de persistance ou toute autre opération faisant appel aux seules compétences de l agent. Les agents d infrastructure : Ces agents sont utilisés pour gérer, contrôler et surveiller l environnement EDA. Leur rôle est d attendre qu une situation particulière se réalise pour se réveiller. Ils peuvent alors engager des actions ou se contenter de surveiller de près ce qui les intéressent ( exception, évènement, etc) Les agents du domaine : Leur rôle est de fournir des implémentations spécifiques au domaine. Ils sont rarement réutilisables et sont généralement construits pour exécuter un travail temporaire. L ensemble de ces agents est déployé au niveau de l outil de messagerie dans lequel plusieurs bus de messagerie peuvent être mis en oeuvre. 3.7 Son fonctionnement La production des évènements Dans la section précédente, nous avons parlé du principe de découplage lâche 1 ainsi que de ses implications au niveau de l architecture basée sur les évènements. Nous avons pu identifier l ensemble des entités qui agissent sur les évènements et les classer dans trois grandes catégories : Producteur d évènements. EPA ou agent de traitement d évènements. 1. Loose Coupling

40 33 Figure 3.5 Illustration d une instance d un réseau de traitement d évènements [4] Consommateur d évènements. Lorsque l on parle de producteur d évènements, il est important de distinguer les différents aspects de ce concept. Un producteur d évènements peut être soit : Un type abstrait de producteurs d évènements comme capteur utilisant la technologie Radio Frequency IDentity (RFID). Une collection d instances de producteurs du même type. Il est important dans ce cas de se concentrer sur l ensemble des instances comme étant une seule classe de producteurs d évènements. Ainsi, on peut trouver dans un magasin une classe qui regroupe tous les capteurs RFID de marque KRONOS. Une instance particulière d un producteur lambda. Nous pouvons prendre pour exemple, un capteur RFID intégré dans un autre équipement. Naturellement, il est plus évident de gérer des classes de producteurs que de traiter les différentes instances une à une, d autant que le nombre de producteurs d évènements peut varier quotidiennement. Une manière trés simple de modéliser les différentes classes de producteurs serait de définir les éléments suivants pour chaque classe : Les détails du producteur : La catégorie du producteur d évènements, l identifiant du producteur d évènements, les différentes fonctionnalités offertes par le producteur d évènements (possibilité de faire des annotations ou d interrogation avec des requêtes, etc) Le flux final sortant : Il s agit principalement des types d évènements qui peuvent être produits et de leurs destinations. La relation avec les autres producteurs d évènements : Elle est soit une spécialisation ou une généralisation. Rappelons qu une classe de producteurs d évènements peut spécialiser une autre classe de producteurs d évènements. Nous pouvons dire dans ce cas-ci que la classe mère représente une généralisation des sous-classes.

41 34 Jusqu ici, nous avons vu les différents aspects qui caractérisent les producteurs d évènements et nous avons décrit les différents éléments de définition qui permettent de distinguer les classes de producteurs d évènements. Nous allons maintenant classer les producteurs d évènements en fonction de leur nature : Producteurs hardware qui peuvent être des équipements médicaux, des appareils de gestion, des applications de sécurité ou même des applications militaires, etc. Producteur agissant en fonction de l interaction humaine. Dans ce cas, les évènements sont générés suite à une interaction humaine avec une interface graphique ou autre. Producteur software simulant des capteurs ou des détecteurs. Encore une fois, lorsque nous voulons intéragir avec un producteur d évènements et pour être le plus efficace possible, des patterns d interaction peuvent être choisis par les concepteurs du producteur d évènements. Ceci facilitera son intégration dans une architecture basée sur les évènements La consommation des évènements Le consommateur d évènements est le complément logique du producteur d évènements qui a été détaillé dans la section précédente. Il est représenté par un noeud qui dispose uniquement d un port d entrée et peut aussi être défini selon trois aspects : Un type abstrait de consommateurs d évènements. Un ensemble de consommateurs d évènements de même type. Une instance singulière d un consommateur d évènements. De même que dans la production des évènements, plusieurs éléments de définition peuvent être utilisés pour distinguer les différentes classes de consommateurs d évènements. La figure [?] résume l ensemble de ces éléments. Nous pouvons y remarquer l absence de la possibilité de quering ou d interrogation via des requêtes au niveau du consommateur. Le rajout de filtres permet de contrôler le flux entrant au consommateur. La dernière classification possible est celle qui se base sur la nature des consommateurs d évènements. Ici, elle donne exactement le même résultat que celui perçu au niveau des producteurs d évènements. De cette façon, on distinguera trois catégories : Consommateur hardware : parmi les actions qui peuvent être réalisées par ce genre de consommateurs, on peut citer : Verouillage et dévérouillage de portes. Ouverture et fermeture de barrières. Contrôle du niveau de l eau dans une piscine. Notons qu un consommateur d évènements de type hardware peut être intégré dans un autre équipement qui peut disposer,en outre, d un producteur d évènements. Il est important dans ce cas de bien séparer logiquement la production et la consommation d évènements. Consommateur agissant en fonction de l interaction humaine. Dans ce genre d utilisation, le rôle du consommateur d évènements est d alerter l utilisateur afin d attirer son attention. Il peut aussi reporter des informations qui sont moins intéressante pour l utilisateur ou rafraîchir l information affichée sur l écran. Consommateur Software : cette famille de consommateurs doit exclusivement être intégrée dans un software et n offre aucune interface graphique. ex : Dans un système de vente par internet, un consommateur d évènements de type paiement effectué doit lancer la procédure de livraison à domicile dés la récéption de l évènement.

42 Le traitement des évènements ou Event processing Le traitement des évènements reste le concept central de l Event Driven Architecture. En effet, C est via cette entité que transite les évènements venant des producteurs et qui doivent être traités par ce composant. Des actions peuvent alors être exécutées en fonction de ces évènements. EPN : Event Processing Network Souvent, nous parlons de réseau de traitement d évènements lorsque plusieurs agents de traitement d évènements sont mis en oeuvre (figure 3.7.3). Il existe plusieurs façons pour concevoir un réseau de traitement d évènements. En effet, l implémentation est différente selon que le réseau soit géré par une seule entité centrale ou que chaque unité de traitement (ensemble d EPA) dispose d un module de gestion. Le rôle des agents peut être : Le filtrage d évènements. Le matching en fonction de patterns prédéfinis. La dérivation de nouveaux évènements en fonction des évènements reçus. CEP : Complex Event Processing Le Complex Event Processing (CEP) est un style de traitement qui vise à analyser les flux d évènements afin de détecter des modèles d évènements (ou patterns). Figure 3.6 Eléments de définiton pour les consommateurs d évènements

43 36 À l heure où les infrastructures temps réel permettent de relever les grands défis qui préoccupent les dirigeants d entreprise. Le traitement complexe des évènements permet, en outre, de garantir une visibilité temps réel des activités de l entreprise. Cette technologie aide les entreprises à gérer plus efficacement le risque, mais aussi à prévenir toutes les anomalies. Voici quelques exemples qui illustrent les avantages d une telle approche : Un technicien est envoyé chez un client, et ce dernier annule la commande. Au même moment, un autre client situé à proximité passe une commande. Le technicien est réorienté de manière dynamique vers ce nouveau client. Les utilisateurs d un site Web se voient proposer de manière proactive des menus d achats et d enchères en fonction de leur historique de navigation, qui représentent leurs comportements spécifiques vis-à-vis du site Web et de son contenu. Une carte bancaire VISA qui est utilisée pour retirer de l argent en Belgique est bloquée si quelques minutes plus tard elle est utilisée pour faire un achat sur internet à partir d un pays d Afrique. Une solution CEP doit pouvoir évoluer pour gérer au mieux les volumes élevés d évènements. Elle doit fournir un environnement visuel permettant d analyser les évènements afin d en extraire les patterns et les causes profondes. Les composants de base qu on trouve dans un système utilisant CEP sont : Les canaux : utilisés pour acheminer les évènements. Le moteur : permet d exécuter les traitements. Des modèles ou des patterns peuvent être définis en se basant sur : Un contexte : détermine les limites de la sélection (temps, espace, entités). Un pattern d évènements : filtre, pattern matching, etc. Un ensemble de prédicats. Figure 3.7 Illustration d une EDA qui utilise un réseau de EPA [4]

44 37 Un ensemble de règles pour la gestion des chevauchements de contextes. L objectif du CEP est de fournir une fonction de prise de décision qui résolve les défis tactiques (spécifiques à chaque scénario), en temps réel et dans un contexte précis (historique des évènements, priorité et circonstances). CEP et processus métier Lorsque nous observons de plus près un processus métier, nous découvrons un grand nombre d évènements liés et non liés dirigés par des délais et des résultats définis. Les conditions et les influences opérationnelles externes des processus métier, les exigences de l instanciation et de l orchestration dynamiques des processus dépendent uniquement de la gestion d une série d évènements complexes à partir d un contexte, d une séquence et d un résultat. Grâce à EDA, le rôle du CEP vis-à-vis des processus métier opérationnels devient un élément indispensable pour l optimisation des performances des processus et le diagnostic individuel. Pour ce faire, une attention particulière doit être portée au moment de la définition des processus métier. En effet, plus le processus métier est découpé en sous-processus métier, plus les évènements deviennent précis et très utiles pour l EDA. l exemple suivant illustre cela. Nous avons le choix entre trois options de conception qui mettront en jeu deux processus métier : EnregistrerPaiement et ReserverProduitEnStock A. Le processus/application envoie un message (synchrone ou asynchrone) au processus EnregistrerPaiement Le processus/application envoie un message (synchrone ou asynchrone) au processus ReserverProduitEnStock B. Le processus/application envoie un message (synchrone ou asynchrone) au processus EnregistrerPaiement Le processus EnregistrerPaiement envoie un message (synchone ou asynchrone) au processus ReserverProduitEnStock C. Le processus/application envoie un message (synchrone ou asynchrone) au processus EnregistrerPaiement Le processus EnregisterPaiement publie l évènement paiementrecu Le service de gestion de stock étant inscrit pour recevoir les évènements liés au paiement reçoit une nouvelle notification. Le concepteur doit faire son choix de conception en fonction des besoins en termes de notifications. Il reste toujours préférable de bien séparer les processus métiers et ne pas les lier entre eux via des appels directs qu en cas de nécessité absolue. CEP et BPM Comme expliqué plus haut, le fonctionnement du CEP est étroitement lié aux processus métier. Ces dernièrs génèrent un ensemble d évènements métier qui est intercepté à la fois par le BPM (Business Process Management) et par le CEP. Nous pouvons reprendre l exemple du processus métier : vente de produits sur internet (figure 2.2), la réception du paiement d une facture est censée déclencher l évènement

45 38 métier : paiementreçu. Ce dernier sera reçu par le BPM qui clôturera la procédure d achat et entamera éventuellement d autres processus métier liés à ce processus. Ce même évènement paiementreçu fera partie du flux d évènements qui sera analysé par le CEP. Ici, la tâche principale est de trouver une correspondance aux patterns prédéfinis, détecter les instances de patterns concernées et enfin lancer la réponse appropriée. Malgré cette quête commune, à savoir l interception des évènements en vue de déclencher des actions, il demeure que la personne qui va utiliser un BPM pour la gestion de son entreprise verra le processus métier vente d un produit sur internet comme une transaction englobant plusieurs sous-processus métier[4] tandis que la personne qui s occupera de la définitions de patterns pour le CEP le verra seulement comme un évènement métier. Les spécialistes constatent aujourd hui une convergeance entre ces deux outils (CEP et BPM) [11] et rajoutent dans ce sens que les processus métier n utilisent certainement pas les évènements pour la même raisons qu un producteur d évènements dans une EDA. Néanmoins, l EDA peut très bien profiter de ce flux d évènements supplémentaire pour accomplir au mieux sa tâche. Pour conclure cette section, il faut dire que l architecte ou le développeur qui s occupe du CEP ne doit pas se limiter au concept d évènement. Au delà de ça, il faut savoir définir les entités qui seront basées sur les évènements et déterminer les exigences architecturales de chacune. Dans certains cas, une implémentation complète d une EDA ne sera pas nécessaire. 3.8 Choix d une solution Naturellement, et lorsque le budget le permet, les entreprises adoptent une suite EDA commerciale dans laquelle elles intègrent leurs applications. Toutefois, ce choix les rend complètement dépendantes des modules propriétaires qui composent cette architecture. Les développeurs travaillent dans les limites de la solution et se voient contraints d acheter de nouvelles fonctionnalités, adaptateurs, licences, etc. Les solutions Open-source, quant à elles, permettent d éviter ce genre de blocage. Cependant, l entreprise reste toujours dépendante de la volonté du développeur et de l architecte qui sont à l origine de la solution lorsqu il faut l étendre ou la maintenir. Aujourd hui, pour attirer les entreprises, certains fournisseurs offrent conjointement une solution Open-Source et des services payants pour la validation, la maintenance et l amélioration des différents éléments du framework. Ainsi, l entreprise pourra modifier la solution et compter sur le fournisseur en cas de problème. 3.9 EDA vs SOA Aujourd hui, les experts certifient que l approche SOA est la meilleure approche pour les futures architectures de développement. Cependant, la question qu il faut se poser, c est de savoir si la SOA est implémentée de la bonne manière et si elle va tenir à long terme. Encore faut-il savoir comment une architecture SOA peut être intégrée dans une architecture basée sur les évènements (EDA).

46 39 Il existe deux manières de concevoir le lien entre SOA et EDA. Dans la première vision, la SOA représente la manière dont les actions sont exécutées. Nous avons vu dans le chapitre précédent qu il était possible de définir des règles au niveau de l entité qui traite les évènements. Des actions peuvent être déclenchées lorsque les conditions de ces règles sont vérifiées. Pour cela, nous pouvons faire appel aux services de la SOA. Nous pouvons dire dans ce cas que l EDA complète SOA car les services peuvent être activés par des triggers que sont les évènements [6]. Il importe ici d insister sur la différence entre le pattern request-and-reply utilisé par SOA et le pattern publish-and-subscribe utilisé par EDA. Ceci rend SOA plus adaptée dans la décomposition des fonctions métier tandis que EDA est utilisée dans la gestion des évènements métier. Figure 3.8 Composants de l EDA + SOA Une autre façon de concevoir les choses serait de considérer chaque élément de l EDA comme un service au sein de la SOA. Figure 3.9 Services de la SOA

47 Le parallélisme au sein de l EDA La nature de l EDA favorise la décomposition et la réutilisation des composants. Ces derniers vont générer des flux d évènements parallèles qui doivent être traités en temps réel. Parmi les questions que le concepteur de l EDA doit se poser, il y a : Comment ces flux vont-ils être véhiculés aux composants responsables de leur traitement? Quelles sont les nouvelles contraintes et exigences? 3.10 Implémentation Aujourd hui, pour implémenter une EDA avec des Web services, il est nécessaire de prévoir un certain nombre d outils pour que l EDA puisse manipuler les messages SOAP de la SOA. En revanche, les web services de la SOA peuvent être déployés sur n importe quelle infrastructure réseau pourvu qu elle dispose de la couche HTTP. C est d ailleurs cette propriété qui explique la monté en puissance de la SOA ces dernières années. Notons qu en plus, les infrastructrures ESB (Enterprise Service Bus) permettent de manipuler aisément les files de messages en les combinant avec les web services. C est pour cette raison là que les différentes implémentations d ESB sont de plus en plus utilisées dans la conception des solutions combinant EDA et SOA [12]. Par ailleurs, l évolution des standards de web services comme WS-Eventing, WS- Notification, WS-MetadataExchange, WS-ReliableMessaging, WS-Security, WS-Choreography, et beaucoup d autres, combinée avec l utilisation accrue des ESB poussent les concepteurs de systèmes d exploitation à intégrer certaines fonctionnalités d ESB dans leurs produits. Notons que l implémentation de SOA et EDA doit être faite tout en considérant le BPM. Les outils offerts par ce dernier sont principalement basés sur Business Process Execution Language (BPEL). Dans sa version actuelle, BPEL est essentiellement basé sur le modèle command-and-control ainsi que sur l orchestration des services. L orchestration supporte aussi les workflow et un autre type de chorégraphie qui s approche d EDA. Cependant, BPEL reste un langage procédural qui nécessite le moteur de contrôle de BPEL. Ceci constitue un handicap pour assurer le loose coupling d EDA et ne constitue pas un problème dans le cadre de SOA. En effet, EDA fonctionne idéalement avec un model déclaratif (BPEL est un langage procédural). Dans ce type de modèle, le concepteur peut facilement connecter des producteurs à des consommateurs. Idéalement, l exécution des implémentations doit être indépendante du moteur du contrôle, elle doit être plutôt basée sur les standards de web service mentionnés cidessus. Il est évident que toutes les nouvelles solutions s orientent dans cette direction. Le meilleur moyen en ce moment est d utiliser les messages SOAP via JMS ou d utiliser d autres alternatives d ESB basées sur SOAP. En créant une solution basée sur des normes communes ainsi qu une implémentation utilisant des technologies standards comme les web services, le système promet d être robuste, évolutif.

48 Collection des évènements Pour revenir à notre premier schéma illustrant le fonctionnement d une EDA, la première entité qui concentre les évènements est appelée Event Collector, son rôle est de collecter les évènements venant de sources différentes afin d en standardiser le contenu. Aujourd hui, les ESB comme les implémentations de JMS sont vraiment adaptées pour être utilisées comme un conteneur d évènements métier. Ainsi, tous les acteurs de l EDA peuvent s inscrire comme consommateur d évènements dans ce dataspace global qui utilise des technologies standards comme le HTTP, FTP, XML, etc. La figure suivante montre une implémentation d EDA utilisant un Enterprise Service Bus pour collecter les évènements métier publiés par deux producteurs d évènements. Les gateways déployés au niveau de l ESB jouent le rôle de consommateurs d évènements et s occupent de la transformation de son contenu afin qu il puisse exister un seul type d évènement interne à l ESB. Figure 3.10 Exemple d implémentation d EDA utilisant un ESB Traitement complexe des évènements Les différents moteurs de CEP qui existent sur le marché acceptent en entrée un flux d évènements provenant idéalement d un Event Collector. L utilisation de l Event Collector permet de standardiser et de préparer le contenu des messages afin qu ils puissent être directement analysés par le moteur CEP. Les consommateurs d évènements peuvent aussi s incrire au niveau de cette entité pour recevoir les évènements qui les intéressent. Caractéristiques générales Les solutions CEP se caractérisent par :

49 42 Un traitement continu d une masse considérable (plusieurs centaines de milliers par seconde) d évènements provenant de sources d information différentes. Un besoin de prise de décision en temps réel par rapport à un ensemble d évènements quelconque surgissant dans une fenêtre temporelle définie. (de quelques secondes, à quelques heures, voire quelques jours) Notions importantes Une règle est de la forme SI ANTECEDENTS ALORS CONSEQUENTS. ANTECEDENTS : représentent les prémisses, souvent une conjonction de conditions, parfois des négations ou des disjonctions. CONSEQUENTS : représentent des actions à envisager. Souvent l ajout de nouveaux faits, toujours sous forme de conjonctions. Dépendance entre les évènements Il peut y avoir plusieurs types de dépendances entre les évènements : Dépendance basée sur la séquence : Si quelque chose s est produit avant cet évènement, le bloc d intéraction a la valeur vraie. Dépendance basée sur la répétition : Si quelques chose s est produit un certain nombre de fois avant cet évènement, le bloc d intéraction a la valeur vraie. Dépendance basée sur le temps : Si quelques chose s est produit dans une période avant cet évènement, le bloc d interaction a la valeur vraie. Moteur d inférences Le principe d un moteur d inférences est de permettre la déduction de faits grâce à d autres faits. Pour cela il faut partir d une liste de règles qui vont permettre d effectuer cette déduction. Le but est de simuler une déduction humaine avec des faits et des règles. Pattern Matching et Algorithme de RETE L algorithme de RETE établit un réseau de nœuds, où chaque nœud (excepté la racine) correspond à un modèle se produisant dans le côté gauche d une règle (soit la condition ou la prémisse). Chaque chemin reliant la racine à un nœud externe(appelé aussi feuille) définit un côté gauche complet de règle. Chaque nœud dispose d une mémoire des faits qui satisfont ce modèle. Cette structure est essentiellement un tri généralisé. Lorsque de nouveaux faits sont affirmés ou modifiés, ils se propagent le long du réseau, annotant les nœuds quand les faits correspondent au modèle. Losqu un fait ou une combinaison des faits satisfait tous les modèles d une règle donnée, un nœud externe (leaf node) est atteint et la règle correspondante est déclenchée.

50 43 Filtrage et résolution des conflits Lorsque les évènements arrivent au niveau du CEP, plusieurs conflits peuvent avoir lieu à cause des évènements qui satisfont plusieurs règles. La stratégie suivante est utilisée pour la sélection des règles compatibles (si il y en a) parmi les règles qui doivent être déclenchées. Elimination des règles utilisées pour une même donnée (voire toutes les règles qui ont été déclenchées récemment) pour ainsi éviter les boucles. Utilisation des données les plus récentes (exploration en profondeur). Utilisation des règles les plus spécifiques : celles qui possèdent le plus de conditions sont préférées aux règles générales. Utilisation d algorithme utilisant le moteur d inférence. Exemple d utilisation Supposons qu on souhaite surveiller la vente et la livraison de produits sur intenet. Supposons aussi que certains produits soient sensibles à la chaleur et qu ils doivent être livrer dans des conditions spéciales. Le plus important ici est que le produit soit livré dans les meilleurs délais et avant sa date d expiration. Durant le transport et le stockage intermédaire, les produits peuvent être exposés à des conditions de chaleur, ce qui risque de les endommager. Notre architecture basée sur les évènements va englober l ensemble des processus qui sont liés à cette transaction, à savoir la vente d un produit sur internet. Depuis le premier processus d achat et jusqu à la livraison, tous les évènements sont collectés et traités par le CEP avant de détecter des anomalies de fonctionnement. Imaginons maintenant que l administrateur du système veuille savoir pourquoi la livraison du produit X n a pas pu avoir lieu le Il doit alors traduire cela dans une requête contenant l ensemble des données dont il dispose : Destinataire +produit X ECHEC. Tous les évènements liés à ce processus vont alors s afficher. L utilisateur pourra alors, toujours au niveau du CEP, encoder d autres requêtes pour savoir la cause exacte du problème. Supposons que le problème de livraison est dû au transporteur qui n avait pas le support nécessaire pour transporter ce genre de produit. Une autre requête peut donner le nombre de livraisons infructueuses qui ont été effectuées par ce transporteur. Si le réponse révèle un nombre important de problèmes causés par ce transporteur, l administrateur peut immédiatement interroger le CEP afin de déterminer si d autres livraisons sensibles seront effectuées par ce même transporteur. Le CEP peut très bien l informer que ce transporteur est en train de charger une livraison depuis 2 min et qu il s apprête à quitter le stock. À ce moment-là, l administrateur peut contacter le responsable du stock et annuler cette livraison. Ce système permet aux dirigeants de contrôler le comportement du système en temps réel et les aide à prendre les bonnes décisions Les Actions Le moteur de CEP doit déclencher des actions lorsque cela est nécessaire. Un évènement surveillé 2 peut déclencher différents types d action. Pour ce faire et vu qu on est censé 2. Par des règles prédéfinies au niveau du CEP

51 44 être dans une architecture qui combine EDA et SOA, il serait important de profiter des services déjà disponibles au niveau de SOA. Toutes les actions peuvent être réalisées en faisant appel aux services de SOA (alarmes, processus métier, génération d un nouvel évènement, etc). Ces actions doivent elles mêmes générer des évènements pour notifier le reste du système. Figure 3.11 Utilisation de SOA pour exécuter les actions Dans la suite quelques consignes concernant la réalisation de la partie SOA. Définir une stratégie à long terme Une SOA réussie nécessite une stratégie à long terme qui facilite les améliorations. Il est important que cette stratégie à long terme soit en accord avec les objectifs stratégiques de l entreprise. Dans le même sens, il est primordiale de définir des règles pour la conception et le déploiement des web services. Des patterns (Façade, Delegation pattern..) peuvent être utilisés pour créer une couche d abstraction. Rappelons que chaque service de la SOA doit pouvoir être réutilisé dans d autres contextes. Eviter la mauvaise granularité d un service Nous entendons par mauvaise granularité qu un service couvre trop ou trop peu de fonctionnalités. Une mauvaise granularité de services dans une SOA peut conduire à : de mauvaises performances.

52 45 de faibles capacités de réutilisation. des services sans valeur ajoutée métier. Valeur métier La valeur métier doit être le facteur majeur au moment de la conception du service. Le concepteur doit fournir en plus de la documentation technique, une description détaillée des fonctions métier remplies par le service. Découplage du format de stockage Une couche d accès aux données est chargée de dialoguer avec les bases de données, en exécutant sur celles-ci des requêtes de consultation ou de modification. Souvent, le code contenu dans la couche d accès aux données est étroitement lié à la base de données utilisée. Par exemple, une couche d accès aux données prévue pour Oracle ne sera pas compatible avec SQL Server ; de la même manière, une couche d accès aux données prévue pour stocker des données au format XML ne pourra être utilisée telle quelle pour stocker des données dans un annuaire LDAP. Afin de garantir l indépendance entre les couches, il convient de mettre en œuvre un mécanisme d abstraction pour éviter que la couche d accès à la base de données ne soit conçue spécifiquement pour une implémentation particulière. Services et processus métier Les services sont définis pour supporter les processus métier. Tout au long des processus, différents services seront nécessaires pour faciliter le traitement et la logique métier. Il est primordial de comprendre les processus métier pour définir les services. Lorsqu il s agit de concevoir une SOA, le défi consiste à créer un jeu de services utiles pouvant supporter le modèle métier. Les services définis dans l architecture ne déterminent pas les processus qu on peut implémenter. En revanche, les processus métier définissent les services dont ils ont besoin. De plus, un service seul ne suffit pas. C est l interaction entre les services qui crée l implémentation des processus métier, c est pour cette raison qu ils doivent également être définis en termes de relations. Un processus utilisera rarement, voire jamais, un seul service. Par contre, il utilisera plusieurs services d une multitude de façons. L interaction entre les services est qualifiée de chorégraphie. Ainsi, une série d interactions chorégraphiées est définie entre les services est la réalisation de l implémentation des processus métier. Composants d une SOA Une architecture de services est constituée de trois composants primaires. Le premier est le prestataire de services (le service réel). Vient ensuite le demandeur du service, autrement dit le composant qui accède au service. Enfin, l agence de services fournit des services de découverte et d enregistrement.

53 46 Prestataire de services : Un prestataire de services est la source de la fonctionnalité des services. Un prestataire publie un contrat d interface 3 utilisé par les demandeurs pour accéder au service. Le contrat définit ce que fait le service et comment y accéder. Demandeur de service : Le demandeur est le client d un service. Il utilise l agence pour découvrir quels services sont disponibles. Une fois un service localisé, le demandeur extrait le contrat d interface correspondant de l agence. Le client utilise le contrat d interface pour comprendre comment accéder au service. Agence de services : Une agence de services 4 est un registre des services disponibles. Chaque prestataire publie son contrat d interface à l agence, avec les informations à utiliser pour localiser le service. Le demandeur recherche les services appropriés dans l agence et extrait le contrat d interface correspondant. Résumé des objectifs d une architecture SOA La réutilisation et la composition, permettant le partage de modules entre applications et les échanges inter-applicatifs ; La pérennité, qui implique notamment le support des technologies existantes et à venir ; L évolutivité, car toute application est vivante, a une certaine durée de vie, peut se voir greffer de nouveaux modules et doit pouvoir répondre aux nouveaux besoins fonctionnels ; L ouverture et l interopérabilité, pour partager des modules applicatifs entre plates-formes et environnements ; La distribution, pour pouvoir utiliser ces modules à distance et les centraliser au sein de l entreprise par exemple ; La performance, avec en priorité l accent mis sur la montée en charge. 3. Les contrats de type WSDL sont un exemple de contrat utilisé dans le cadre des web services. 4. L Universal Description Discovery and Integration (UDDI) est une agence de services ou un répertoire universel de tous les services.

54 Chapitre 4 Outils et technologies d implémentation Dans ce chapitre, nous expliquons les différents outils et les différentes technologies utilisées dans le développement de l application de gestion de la plate-forme temps réel. 4.1 MDA : Model Driven Architecture Les méthodes d analyse et de conception d applications d entreprise ne sont plus ce qu elles étaient il y a quelques années. En effet, si les languages de programmation n ont pas cessé d évoluer ces dernières années, certaines méthodes de conception sont devenues obsolètes et ne correspondent plus aux besoins des développeurs. C est pour cette raison là qu une nouvelle démarche de réalisation de logiciels appelée Model Driven Architecture (MDA) commence à gagner du terrain dans les entreprises. Dans la démarche de conception actuelle, le développeur commence par réaliser les différents diagrammes qui décrivent le fonctionnement interne de l application. Il doit alors passer à l étape de programmation au cours de laquelle il conçoit l ensemble des classes qui composent l application. Pendant cette même étape, le développeur doit penser à la persistance des données et définir le schéma de la base de donnée qui va héberger les données de l application. Au final, le développeur se retrouve avec trois modèles qu il est censé synchroniser en cas de modification : le modèle UML, le modèle d objet et le modèle de persistance. L objectif de MDA est très simple : séparer les spécifications fonctionnelles des spécifications de son implémentation sur une plate-forme donnée. Autrement dit, en partant d un modèle métier indépendant de l informatisation (CIM), une transformation de celui-ci en Platform-Independent Model (PIM) et enfin la transformation de ce dernier en modèle spécifique à la plate-forme cible (PSM) pour l implémentation concrète du système. Les techniques employées sont donc principalement des techniques de modélisation et des techniques de transformation de modèles Les modèles de bases Dans la suite, une explication détaillée pour chaque type de modèle 47

55 48 Figure 4.1 PIM + PM = PSM PIM : Platform-Independent Model Ce modèle est utilisé pour décrire les traitements orientés métier. Il est indépendant de toute plate-forme contrairement aux différents modèles de conception et d analyse qui restent toujours dépendant de la plate-forme d exécution comme JEE ou.net. PM : plateform model Décrit l architecture technique de l application. Plusieurs PM peuvent être utilisés dans un même projet. PSM : Platform Specific Model Le modèle de code ou de conception concrète PSM est le plus délicat de MDA car le travail de génération du code se fait à ce niveau-là. MDA estime que le code de l application peut être obtenu à partir de modèles de code. La différence entre un modèle de code et un modèle d analyse ou de conception est que le modèle de code est lié à une plate-forme d exécution. Notons que le code de l application se résume à une suite de lignes textuelles comme un fichier Java tandis qu un modèle de code est une représentation structurée incluant, par exemple, les concepts de boucle, condition, instruction, composant, évènement, etc. L écriture de code à partir d un modèle de code est une opération assez triviale Les technologies utilisées Il existe plusieurs technologies standards utilisées par MDA.

56 49 MOF : Meta-Object Facility Le formalisme de modélisation Meta-Object Facility (MOF) est un langage permettant d exprimer des modèles. UML est, par exemple, un langage recommandé pour concevoir les modèles d analyse et de conception. Le formalisme définit le concept et les relations entre concepts essentiels à l expression de modèles. MOF est un standard permettant de définir et de modifier des méta modèles et leurs modèles correspondants. Il permet de définir la syntaxe et la sémantique d un langage de modélisation, le but étant d avoir un formalisme permettant l expression de modèles de formalismes de modélisation. Un tel modèle est nommé métaformalisme et les modèles qu il permet d exprimer sont appelés des métamodèles. Dans MDA il n existe qu un seul métaformalisme, le MOF aussi appelé metamétamodèle. XMI : XML Model Interchange Un modèle correspond à un graphe général, contrairement à un programme source dans un langage de programmation qui a une représentation textuelle ou arborescente (syntaxique). Il est à noter qu il est plus commode de communiquer des formes linéaires vu que la transformation des formes arborescentes en formes linéaires est bien maîtrisée. Par contre, le passage du graphe d un modèle à une forme linéaire (sérialisation) est plus délicat. Afin de trouver une solution à ce problème, l Object Management Group (OMG) avait lancé le Request for Proposal (RFP) Serial Model Interchange Format (SMIF). Initialement il était envisagé d utiliser le format de CASE Data Interchange Format (CDIF), déjà standardisé par l Electronic Industries Alliance (EIA). En cours de travail, il est apparu que le passage intermédiaire vers la forme arborescente de XML constituait technologiquement une meilleure solution. Le RFP s est donc conclu en proposant la norme XML Model Interchange (XMI). CWN : Commun Warehouse Metamodel Ce standard a été adopté afin de faciliter les échanges de métadonnées entre outils. Il fournit : Un langage commun pour la description des métadonnées, La possibilité d utiliser XML pour échanger les métadonnées, Des APIs pour accéder aux métadonnées. 4.2 EMF : Eclipse Modeling Framework Il s agit de l environnement de la plate-forme Eclipse dédié à MDA. EMF est un framework permettant la modélisation ainsi que la génération automatique du code à partir d un modèle de données structuré. Autrement dit, partant d une spécification de modèle décrite grâce à XMI, EMF fournit les outils ainsi que le support d exécution pour générer un ensemble de classes du modèle. Il produit en outre, un ensemble d adaptateurs qui permettent l affichage et l édition du modèle. Les modèles peuvent être spécifiés en utilisant des classes Java, Unified Modeling Language (UML), XML, puis sont importés dans EMF. Le plus important est qu EMF fournit les fondements à l interopérabilité avec d autres outils ou applications basés sur EMF.

57 50 EMF propose plusieurs services : La transformation des modèles d entrées (à gauche sur la figure 4.2), présentés sous diverse formes, en Core Model, La gestion de la persistance du Core Model, La transformation du Core Model en code Java Les formats d entrée standards Comme expliqué auparavant, EMF peut manipuler trois formats de modèle qui sont : UML, XMI ainsi que du code Java annoté. UML Il s agit d importer, à l aide d une fonction d EMF, un modèle dans son format natif (qui dépend de l outil de modélisation utilisé). Seul le format IBM Rational (.mdl) permet de profiter de cet avantage. En effet, la suite Rational est la seule comptatible avec EMF. XMI XMI décrit en détail comment persister les modèles. il est en train de devenir un standard pour l échange de données de modèles et Il est utilisé pour persister les modèles ECore dans EMF. Code Java annoté Une des solutions tentantes pour modéliser les classes, qui vont être concrétisées par une application Java, est d utiliser les interfaces Java. Plusieurs raisons justifient ce choix : Elles n implémentent pas les méthodes : on s abstrait donc de cette implémentation, Les méthodes get/set peuvent être utilisées pour modéliser les attributs, Une classe pourra implémenter plusieurs interfaces ce qui facilite la modélisation. Ainsi, les interfaces sont fournies en entrée pour décrire les classes qui seront générés automatiquement. Le module qui s occupe de la conversion des modèles va détecter les au niveau des interfaces Java pour les utiliser comme éléments de la modélisation. Figure 4.2 Fonctionnement de EMF

58 Ecore ou métamodèle Ecore est un méta-modèle très proche de MOF(Meta-Object Facility). Il contient toutes les informations par rapport aux classes du projet. Quatre types d entité sont utilisés dans la définition d un tel modèle. EClass : Représente une classe contenant des attributs et des références, EAttribute : Représente un attribut avec un nom et un type, EReference : Il s agit d une extrémité d une association entre deux classes. Cette entité contient une référence vers l autre extrémité de l association, EDataType : Représente le type d un attribut. Exemple : int, float, data, etc. Il est évident que seul le modèle Ecore ne permet pas de contenir toute l information nécessaire à la transformation. C est pour cette raison qu un autre modèle appelé Genmodel doit être utilisé afin de renseigner sur les informations additionnelles nécessaire pendant la génération du code. On peut citer comme information additionnelle : la destination ou le nom des fichiers générés. Le modèle Ecore montre l objet racine qui représente le modèle. Ce dernier a des enfants qui représentent l ensemble des packages. Dans chaque package, on peut trouver un ensemble de classes dont les attributs sont représentés sous forme de noeuds enfants. Le principe global est de définir des associations entre les principaux types d éléments d un modèle sous la forme d un arbre. Nous commençons donc par créer ce qui joue le rôle du sommet de l arbre, puis à partir de là, nous créerons les éléments suivants. Ainsi, l élément principal créé est un package dans lequel nous pouvons créer des classes. celles-ci peuvent contenir différents attributs ainsi que des associations entre elles. Rappelons que les deux représentation (arbre et graphe) sont complètement équivalentes, L utilisateur doit obligatoirement utiliser la vue d arbre pour concevoir le modèle, il pourra ensuite visualiser son modèle sous forme de graphe afin de bien mettre en évidence les différentes relations entre les classes Génération du code Lors de la génération du code, des interfaces et des classes sont générées automatiquement. L idée qui a été adoptée par les concepteurs d EMF consiste à séparer l interface de l implémentation dans le code généré. Cela va se concrétiser par la génération de deux ensembles (issus du modèle d entrée, assimilable à un diagramme de classes UML) : Un ensemble d interfaces Java, Un ensemble de classes implémentant ces interfaces. Il est à noter qu EMF se base sur plusieurs patterns lors de la génération du code. En effet, les concepteurs ont voulu s aligner sur les API standards. Des interfaces comme Factory ou Package sont automatiquement générées ainsi que leurs classes d implémentation. Par ailleurs, EMF offre la possibilité de compléter manuellement le code obtenu automatiquement et surtout de pouvoir garder ce code supplémentaire en cas de regénération du code. La génération liée à un modèle est paramétrée à l aide d un modèle EMF de génération dont la structure est définie par le métamodèle appelé GenModel. Cette approche de génération paramétrée par un modèle présente comme avantages de ne pas polluer les éléments de modélisation avec des ingrédients relatifs à la génération et de pouvoir appliquer plusieurs générations différentes à un même modèle.

59 52 Figure 4.3 Exemple d instance d un modèle Ecore vue sous forme d arbre Enfin, un méta-modèle qui est basé sur le concept d Ecore offre la possibilité d exprimer un ensemble de contraintes qui sont : le typage des éléments, la composition d éléments, la cardinalité et l unicité des liens. Ceci n est malheureusement pas suffisants car d autres types de contraintes non exprimables structurellement doivent être prises en compte. Ces constats et des besoins de précision de métamodèles dans le cadre de travaux en recherche ont conduit à étendre EMF avec un support Object Constraint Language (OCL). Ce dernier permet de formaliser l expression de contraintes utilisé dans les diagrammes d UML et en particuler les diagrammes de classes. L intégration d OCL à EMF permet : La spécification de constraintes OCL pour les modèles EMF (intégrées). Le stockage des modèles avec leur contraintes. La validation syntaxique et sémantique des contraintes. La génération de code Java pour vérifier les contraintes à l exécution. 4.3 JET : Java Emitter Templates JET est un composant d EMF utilisé pour la génération du code et dont la syntaxe est très proche de celle de JSP. La génération du code à partir de modèle permet de réduire le temps de travail et la quantité du code redondant dans l applicaion. Toutefois, l outil qui est censé générer le code peut devenir très complexe et difficile à maîtriser dans le cadre de grands projets. Les templates permettent de réduire la complexité et d augmenter la lisibilité. Grâce à JET, les utilisateurs d EMF peuvent créer facilement des templates qui exprime le code

60 53 à générer, et ce, dans plusieurs langages comme le Structured Query Language (SQL), XML, ou le Java. JET contient principalement quatre librairies de commandes à savoir : Commandes de Contrôle : Utilisées pour accéder au modèle d entrée et pour contrôler l exécution du templat Commandes de format : Utilisées pour modifier le format du texte dans les modèles selon certaines règles. Commandes Java : Ce sont des balises utiles pour générer du code Java. Commandes de Workspace : Utilisées pour la création de ressources dans l espace de travail, telles que des fichiers, des dossiers et des projets. En utilisant les templates de JET, le développeur peut créer différentes implémentations pour un même modèle. Il peut ensuite, paramètrer l implémentation en fonction du contexte. Deus étapes intermédiaires sont nécessaires pendant la génération du code : La translation : Consiste à transformer les templates en une implémentation de classes Java. La génération proprement dite : L utilisation de ces classes Java en vue de l obtention du résultat désiré. Figure 4.4 Exemple d instance d un modèle Ecore dans l éditeur graphique

61 54 Figure 4.5 Transformation d un modèle EMF + JET 4.4 EPA : Eclipse Plugin Architecture Eclipse IDE est un Environnement de Développement Intégré qui a été conçu autour de la notion de Plugin. L alliance OSGi 1 a conçu un framework qui définit un modèle de gestion de cycle de vie d une application, un répertoire (registry) de services, un environnement d exécution et des modules. Eclipse IDE utilise OSGi comme modèle de composants et SWT/JFace 2 comme composants graphiques. Les composants de base d Eclipse peuvent être réutilisés pour développer des clients lourds indépendants d Eclipse grâce au projet Eclipse Rich Client Platform (RCP) Programmation orientée composant Avant d entrer dans le cœur de la technologie, nous allons détailler les caractéristiques de la programmation orientée composant afin d identifier les problématiques qu elles visent à résoudre. En effet, la programmation orientée composant vise à abolir les limitations de la programmation orientée objet. Cette dernière décrit la manière dont les classes d objet doivent être définies mais n apporte aucun support afin de mettre en relation ces classes. Malheureusement, ceci rend les grandes applications orientées objet difficilement maintenables ou évolutives. Ainsi, cet aspect peut devenir très problématique lors de la mise en oeuvre de réseaux complexes d objet. En effet, cela se traduit très souvent par des couplages forts entre objets, ce point nuisant énormément à la réutilisabilité des traitements. Chaque développeur a alors le choix des outils afin de mieux concevoir ses applications. L approche la plus adaptée consiste en la mise en oeuvre des design patterns par l intermédiaire de frameworks tels que Spring utilisés conjointement avec la programmation par interface. 1. Open Services Gateway initiative 2. Standard Widget Toolkit et JFace sont deux composants développés par IBM

62 55 Dans ce contexte, la technologie Open Services Gateway initiative (OSGi) vise à régler les différentes problématiques vues précédemment, problématiques récapitulées ci-dessous : Abolir les limitations de la programmation orientée objets, Permettre la gestion des applications complexes et de taille importante, Améliorer la qualité de service des applications, Permettre la mise en oeuvre d architectures orientées service. Dans ce type d approche, un composant est considéré comme une unité indépendante de production et de déploiement qui est combinée à d autres composants pour former une application. L objet reste au centre du composant mais l objectif diffère car le but est de toujours utiliser une approche objet, non pas au sein du code, mais au niveau de l architecture générale du logiciel. Un composant est censé fournir un service bien précis. Les fonctionnalités qu il encapsule doivent être en rapport et cohérentes entre elles. On verrait mal l intérêt d un composant regroupant les tâches de gestion d impression et de compression de fichiers, par exemple. Rappelons que le but ultime de cette approche est la réutilisabilité. Pour ce faire, les composants doivent avoir un comportement générique. Ceci n est pas malheureusement pas possible qu en cas de compromis entre la spécialisation du composant pour optimiser son utilisation dans le cadre du projet actuel, et sa généralisation en vue de sa réutilisation Architecture OSGi Figure 4.6 Architecture OSGi L architecture de la spécification OSGi est basée sur la notion de Bundle. Dans le suite, une brève description de chaque élément : Bundles : Le composant correspond à l entité centrale de la technologie OSGi est désigné par le terme bundle. Il s agit d un fichier jar contenant plusieurs composants. Services : La couche des services permet de connecter dynamiquement les bundles aux objets Plain Old Java Object (POJO). Elle offre la possibilité de mettre à disposition certains traitements des composants par l intermédiaire de services.

63 56 Services Registry : Cette API permet de gérer les services. Life-Cycle : La couche Cycle de vie (life cycle) prend quant à elle en charge les états des bundles supportés par le conteneur ainsi que les API correspondantes. Modules : La couche Modules est chargée de la gestion des bundles, aussi bien au niveau du chargement des classes (classloading) que de la gestion de leurs visibilités et de leurs versions. Security : Cette couche est chargée de la gestion des différents aspects de la sécurité, comme la limitation de fonctionnalités ou de capacités de traitement. Execution Environnement : Définit les méthodes et les classes nécessaires à l exécution de la plate-forme. Il est à noter ici que le lien étroit existant entre cette architecture et l architecture orientée service. L architecture de la technologie OSGi permet de mettre en oeuvre des composants et de mettre à disposition des services applicatifs. C est donc aussi une architecture orientée service mais qui a la caractéristique d être très légère. En effet, Elle doit pouvoir fonctionner de manière autonome dans un seul processus Java. Autrement dit, elle correspond à un modèle de service déployé une même machine virtuelle Les Bundles OSGI Avec la technologie OSGi, le concept de composant est mis en oeuvre par l intermédiaire de bundles, un bundle correspondant à un composant qui peut être déployé dans un conteneur OSGi. Clairement, il s agit d un fichier JAR qui contient, en outre des classes Java, des informations de déploiement spécifiées par l intermédiaire du fichier standard MANI- FEST.MF présent dans le répertoire META-INF. En effet, OSGi reprend ce fichier en y ajoutant différents en-têtes afin de configurer le composant. Propriétés d un Bundle Les propriétés du bundle sont définies au niveau de ce même fichier manifest : Bundle-ManifestVersion : Version du fichier MANIFEST. Bundle-Name : nom du bundle. Bundle-SymbolicName : nom symbolique du bundle. Bundle-Version : numéro de version du bundle. Bundle-RequiredExecutionEnvironment : environnement d exécution requis. Import-Package : packages importés ainsi que les numéros de versions requis. Export-Package : packages exportés. Bundle-Vendor : fournisseur du bundle. Dynamic Import-Package (à partir de la version 3 des spécifications) : dépendances importées dynamiquement. Ces dépendances ne doivent pas être obligatoirement disponible lors du démarrage du bundle. Ce type d import est intéressant pour la mise en place du Bundle.

64 57 Bundle-NativeCode : liste des bibliothèques natives utilisées. Require-Bundle : identifiant des bundles nécessaires. Bundle-Activator : nom du bundle Activator permettant d exécuter des traitements au démarrage et à l arrêt du bundle. Cette classe livrée avec le bundle doit implémenter l interface BundleActivator. Bundle-Classpath : classpath nécessaire pour l exécution du bundle. Le Activator Cet objet permet au bundle de s abonner aux évènements du Framework. Ce dernier détermine l objet Activator du Bundle en se basant sur le fichier Manifest. Techniquement, cette classe implémente l interface BundleActivator, et redéfinit les méthodes suivantes : La méthode Start(BundleContext context) Recherche et obtient des services requis auprès du contexte et/ou positionne des listeners sur des évènements, Enregistre les services fournis auprès du contexte. La méthode Stop(BundleContext context) Cycle de vie d un Bundle Figure 4.7 Cycle de vie d un Bundle Un bundle peut être dans un des états suivants : UNINSTALLED : Etat dans lequel se trouve un bundle une fois qu il a été désinstallé. INSTALLED : Etat dans lequel se trouve un bundle juste après avoir été installé, la résolution des dépendances n ayant pas encore été réalisée. RESOLVED : Etat dans lequel se trouve un bundle après avoir été installé, la résolution des dépendances ayant juste été réalisée. STARTING : Etat dans lequel se trouve un bundle lorsqu il est en train d être démarré. Cet état correspond à un état transitoire entre les évènements Résolu et Actif.

65 58 STOPPING : Etat dans lequel se trouve un bundle lorsqu il est en train d être arrêté. Cet état correspond à un état transitoire entre les évènements ACTIVE et et Resolved. ACTIVE : Etat dans lequel se trouve un bundle lorsqu il a été démarré avec succès. Le bundle ainsi que les services qu il expose sont disponibles pour les autres bundles. Interactions entre les Bundles Comme nous l évoquions dans la section précédente, un conteneur OSGi offre la possibilité de gérer la visibilité des ressources en composant. Par défaut, un composant est complètement opaque depuis l extérieur et rien n est accessible. Cet aspect implique de préciser toutes les dépendances utilisées par un composant et tous les packages mis à disposition. La spécification OSGi offre la possibilité de jouer sur cet aspect par l intermédiaire d en-têtes dans le fichier MANIFEST.MF, fichier contenant les données relatives au déploiement et décrit dans la section précédente Equinox Equinox est un nom de projet Eclipse qui fournit une implémentation de la spécification du framework OSGi R4. Il s agit d un ensemble de bundles qui implémentent les différents services optionnels de OSGi ainsi que toute l infrastructure nécessaire à l exécution des systèmes basés sur OSGi. 4.5 JBoss Application Server Dans le deuxième chapitre, nous avons vu que la plate-forme JEE définissait les spécifications du serveur d applications dans lequel les applications Java Enterprise sont exécutées. Ces recommandations permettent ainsi aux entreprises tierces de développer des serveurs d applications conformes à ses spécifications. JBoss Application Server est un des plus célèbre de ces serveurs applicatifs. JBoss AS ( Java Beans Open Source Software Application Server) définit un ensemble de modèles de composants qui peuvent être utilisés par le développeur pour la conception de ses composants. Ces derniers peuvent être déployés sur JBoss AS en utilisant le modèle de déploiement. Lorsque le composant est en cours d exécution sur le serveur, ce dernier fournit un ensemble de services qui sont destinés à ce composant. Sans ce serveur d applications et lorsque l application s exécute en local, le développeur doit initialiser l ensemble des services qui seront utilisés par l application. Il doit par exemple, préparer la connection à la base de données en fournissant le nom de l utilisateur et le mot de passe, télécharger des informations et les mettre en cache pour accélérer le lancement de l application. Grâce au serveur applicatif, la configuration de certains services utilisés par l application peut être effectuée indépendemment de l application elle même. La figure 4.8 présente la différence entre une application standalone(à gauche dans la figure) et une autre utilisant les services du serveur applicatif.

66 59 Les modèles de composants incluent des standards comme les EJBs, JSP et les servlets. Nous pouvons citer parmi les services offerts par ces composants : la gestion de la sécurité, la gestion des transactions, la persistance, la messagerie, la gestion des ressources, la gestion de la concurrence, le nommage et le déploiement. Figure 4.8 Utilisation des services du JBoss Application Server EJB : Enterprise Java Bean Les EJBs sont tout simplement un modèle de composants déployé au niveau du serveur applicatif. Chaque EJB a un rôle spécifique, il peut : Représenter des données : Il est appelé Entity Bean dans ce cas. Il peut par exemple représenter un client, un objet d un stock. Autrement dit, les entity beans correspondent à des objets réel. Proposer des services : Session Bean. Il fournit une interface distante afin de définir les méthodes que l on peut invoquer. Acomplir des tâches de manière asynchrone : Message Bean. Il attend des messages asynchrones spécifiques auxquels il répond. Les EJBs utilisent l ensemble des services offerts par le serveur applicatif pour réaliser leurs fonctions. Le client peut être une entité de toute forme : application avec ou sans interface graphique, un bean, une servlet, une JSP ou un autre EJB. Le client peut utiliser deux technlogies pour accéder aux fonctions de l EJB : Le protocole SOAP. Pour ce faire, le client génère un message SOAP contenant la requête qui doit être décodée et traitée par l interface SOAP de l EJB. RMI pour Remote Method Invocation va permettre à des applications clientes (s exécutant localement) d invoquer des méthodes sur des objets distants, c està-dire localisés dans l EJB. Contrairement à la première méthode d accès, cette méthode ne peut être utilisée que par les applications Java disposant en plus des spécifications de l objet distant. Le concepteur de l EJB doit fournir une spécification de l EJB sous la forme d une interface Java contenant l ensemble des méthodes qui pourront être invoquées sur l objet. Une implémentation courante de cette méthode d accès consiste à intégrer un stub au niveau du client. Un stub étant une représentation locale de l objet distant. Il implémente l interface remote mais contient une connexion réseau pour accéder à l objet distant.

67 Description des services avec WSDL Le standard WSDL est un langage reposant sur la notation XML permettant de décrire les services web. WSDL permet ainsi de décrire l emplacement du service web ainsi que les opérations (méthodes, paramètres et valeurs de retour) que le service propose. Le fichier WSDL est principalement composé de 5 élements, avec d autres éléments optionnels : definitions : élément racine du document, il donne le nom du service, déclare les espaces de noms utilisés, et contient les éléments du service. message : décrit un message unique, que ce soit un message de requête seul ou un message de réponse seul. L élément défini le nom du message et peut contenir (ou pas) des éléments nommés part, qui font référence aux paramètres du message ou aux valeurs retournées par le message. porttype : combine plusieurs éléments message pour composer une opération. Chaque opération se réfère à un message en entrée et à des messages en sortie. types : décrit tous les types de données utilisés entre le client et le serveur. WSDL n est pas exclusivement lié à un système spécifique de typage, mais utilise par défaut le spécification XML Schema. binding : décrit les spécifications concrètes de la manière dont le service sera implémenté : protocole de communication, format des données pour les opérations et etc. WSDL possède des extensions internes pour définir des services SOAP. Par conséquent, les informations spécifiques à SOAP se retrouvent dans cet élément. service : défini les adresses permettant d invoquer le service donné, ce qui sert à regrouper un ensemble de ports reliés. La plupart du temps, c est une URL invoquant un service SOAP. import : permet de séparer les différents éléments d une définition de service en plusieurs documents indépendants, qui peuvent être éventuellement importés. Cela permet d écrire des définitions plus claires, en séparant les définitions selon leurs niveaux d abstraction, et de maximiser la réutilisabilité Versionning des services Dans une implémentation SOA, un service n a de sens que s il est invoqué par plusieurs applications ou blocs applicatifs. Par conséquent, tout changement survenant sur un service impacte l ensemble des consommateurs de ce service. Non seulement ces changements peuvent coûter chers, en plus, l autonomie du service est un fondement de la mise en œuvre d une architecture orientée services. L autonomie se traduit par le fait que le service peut être modifié, déployé et maintenu indépendamment des consommateurs qui l invoquent. La façon la plus répondu pour faire face aux changements des services, c est le versioning. Cela se traduit par la coexistence de plusieurs versions du même service, chacune est utilisée par un ou plusieurs consommateurs. L introduction de la coexistence de multiples versions d un même service permet d avoir des cycles de vie indépendants entre fournisseurs et consommateurs de services, ce qui minimise les impacts globaux sur l implémentation SOA.

68 JBoss Enterprise Service Bus Présentation de l outil JBossESB est une solution Open Source complète. Elle est composée de plusieurs modules : Un BPM, Un Integrated Development Environment (IDE), Des connecteurs, Un gestionnaire de transactions, Un gestionnaire de sécurité, Un conteneur d applications, Un outil de messagerie, Un Naming and Directory Service (NDS), Une architecture distribuée de calcul Notions importantes Les différents acteurs qui communiquent avec l ESB n utilisent pas forcément le même format de messages que l ESB, d où l intêret d avoir des points d entrée et de sortie au niveau de l ESB (appelés gateways ou connecteurs) pour assurer le formattage et la transformation des messages. Gateways Les Gateways sont des listeners qui peuvent recevoir différents types d objet ( message JMS, tables SQL.. ), leur appliquer un ensemble d actions (transformation et autre) et renvoyer au final un objet de type Message manipulable par l ESB. JBossEsb offre plusieurs type de gateways Gateways pour les fichiers : local filesystem, ftp, sftp and ftps JMS, HTTP/HTTPS, Gateways supportant le protocole SMTP, SQL table, Hibernate. Chaque gateway dispose d un listenner spécifique. À noter qu on peut toujours définir de nouveaux types de gateways sous condition que les technologies de communication qu ils utilisent soient implémentées par l ESB. EPR Un endpoint est un point d entré d un service, d un processus, d une queue ou d un topic Un EPR est une référence vers un endpoint de l ESB. Il s agit d un objet qui contient toutes les informations nécessaires pour communiquer avec un endpoint.

69 62 Registry Représente le cœur de l ESB, il est utilisé pour stocker les informations concernant les services métier. Ainsi, lorsqu une application veut communiquer avec un service, elle introspecte d abord le registry pour avoir l EPR du service désiré. Services Un service de JBoss ESB défini : Des listeners qui peuvent être soit : des listeners gateway Ils sont en charge de transformer le message (dit unaware) reçu de l extérieur de l ESB en un message supporté par l ESB (dit aware) Des listeners ESB-aware Ils lisent les messages au format ESB (aware) Une séquence ou un pipeline d actions. Structure d un message ESB Une entête : Les informations qui s y trouvent concernent principalement le destinataire, l émetteur ainsi que le contenu du message. Un contexte : Ce sont des informations additionnelles qui expliquent le message. Cela peut contenir par exemple le dernier récepteur du message ou des liens externes. Un corps : Représente la partie utile du message Un champ Erreur : Contient l information sur les éventuelles erreurs associées au message. Un champ pour une éventuelle pièce jointe : N importe quel fichier qu on désire attacher au message. Des propriétés : Propriétés additionnelles du message. Routage Par défaut, l information est packagée, transformée et stockée sous forme de message au sein de l ESB. Ces derniers sont adressés aux EPRs sous condition que l adresse de destination soit toujours valide et que le service de destination soit en mesure de traiter ce genre de message. Le CBR solutionne ce genre de problème en routant les messages selon leur contenu. Dans ce cas, il n y a plus de problème d EPR obsolète. Il existe trois classes de routage : org.jboss.soa.esb.actions.contentbasedrouter Implémente le pattern CBR. Elle route les messages au(x) service(s) de destination en se basant sur leurs contenus et sur l ensemble de règles d évaluation. Une exception est levée lorsque aucune destination n a pu être trouvée.

70 63 org.jboss.soa.esb.actions.contentbasedwiretap Implémente le pattern WireTap qui est un pattern d intégration dans lequel une copie de chaque message est envoyée sur un canal de contrôle. org.jboss.soa.esb.actions.messagefilter Implémente le pattern Message Filter. Cette classe permet la suppression automatique de messages non valides. Un message est non valide lorsque certains de ses éléments sont absents. 4.8 JAIN Service Logic Execution Environnement La plate-forme JAIN SLEE est un standard qui permet aux développeurs Java d étaborer et de déployer des services dans des systèmes temps réel comme les réseaux de téléphonie fixe ou sans fil. Il permet d intégrer ces services dans les infrastructuress existantes sans devoir ajouter de nouveaux composants. La technologie JAIN SLEE joue le même rôle que JEE en tant que support d applications Java. Elle offre un modèle de composants pour la structuration de la logique des applications de communication. Le but étant de voir ces applications comme des composants orientés objet qu on peut composer sous forme de services fiables et modulaires. JAIN SLEE intègre un modèle d évènement avec un composant de programmation tout en incorporant des interfaces d administration (par l intermédiaire de JMX), un adaptateur de ressources pour le réseau, des interfaces de profiles génériques, un système de gestion de persistance pour les états de redondance, des systèmes de contrôle d accès concurrent comme les minuteries, des systèmes d alarmes, un système de suivi d utilisation et des traces La notion de service Un service dans la terminologie JAIN SLEE est vu comme une unité remplacable qu on peut facilement gérer [8]. L administrateur du système a la possibilité de contrôler le cycle de vie du service. Ce dernier inclut, entre autres, une description contenant son nom, le nom du vendeur de service et sa version. Notons que chaque service peut inclure des classes Java, des profiles mais aussi des Service Building Blocks Les profiles Un profile JAIN SLEE peut être vu comme une table de base de données ayant un schéma et un ensemble d attributs ou de propriétés. Par exemple, un numéro de téléphone ainsi que l adresse électronique d un individu peuvent être considérés comme deux attributs d un profile [8]. JAIN SLEE prévoit une spécification pour cela. En effet, cette spécification inclut les interfaces de gestion qui doivent être générées pour chaque profile et qui permettent de faire des modifications ou des mises à jours sur ce dernier. Les méthodes create, modify, display, remove doivent être exposées pour chaque profile. Il est à noter que ces profiles sont utilisés pour le construire la logique d application des Service Building Blocks.

71 Les Service Building Blocks L élément réutilisable au sein de l architecture JAIN SLEE est appelé Service Building Block (SBB). Un SBB est un composant logiciel qui envoie/reçoit des évènements et réalise des traitements logiques basés sur les évènements reçus ainsi que son propre état. Les SBBs sont des composants stateful 3 capables de mémoriser les résultats des requêtes précédentes et pouvant être composés à partir d autres SBBs. La notion d évènement est définie comme une occurence d un acte qui se produit à l intérieur ou à l extérieur du système. De même qu avec les profiles, les SBBs doivent inclure une description de leurs fonctionnalités. 3. Dans ce cas, chaque SBB est associé à un seul client.

72 Chapitre 5 Gestion de la plate-forme 5.1 Présentation de la plate-forme Deuxième équipementier mondial derrière Cisco, Alcatel-Lucent est une société spécialisée dans les télécommunications. Elle propose une large gamme de services : conception, intégration/déploiement, exploitation et maintenance des réseaux. L ensemble des solutions qu elle propose touche les domaines de l enseignement, l énergie, les finances, la vente, les transports, la santé, etc. Alcatel-Lucent dispose de plusieurs plates-formes de communication, temps réel et sécurisées sur lesquelles peuvent être déployé les services de communication. L achat d un service par un opérateur implique l achat de la plate-forme qui le supporte, l opérateur se charge ainsi de l hébergement du service et de sa plate-forme (Figure 5.1). Pour illustrer ce fait, nous allons prendre la plate-forme Next Generation Intelligent Network (NGIN) 1. Lorsqu un opérateur acquiert cette plate-forme (utilisée notamment pour le real-time billing 2 ), il peut la gérer via une application web qui permet, en outre, de consulter le rapport sur les différentes opérations exécutées par la plate-forme. Par ailleurs, il est tout à fait possible de faire communiquer l application de gestion de la plate-forme avec les autres composants du système informatique de l opérateur. Pour ce faire, un travail supplémentaire doit être réalisé par l équipe d intégration d Alcatel- Lucent afin d établir un lien (one-to-one) entre l application de gestion et les autres applications concernées. Une fois cette tâche accomplie, la création d un compte d utilisateur dans le Customer Relationship Management (CRM) pourra, par exemple, générer automatiquement un compte et un profile au niveau de la plate-forme NGIN. Les applications de l opérateur ainsi que l application de gestion de la plate-forme peuvent se synchroniser grâce aux liens préalablement établis par l équipe d Alcatel-Lucent. La figure 5.1 montre l intégration de la plate-forme NGIN au niveau du réseau téléphonique de l opérateur. Le système informatique de ce dernier héberge l application de gestion qui permet de contrôler la plate-forme. Comme expliqué précédemment, la 1. Il s agit d une implémentation du concept de IN (Intelligent Network) basée sur la nouvelle architecture des réseaux fixes et mobiles qu on appelle Next Generation. 2. Le real-time billing est une des plus importantes fonctionnalités dans les systèmes de services de télécommunication, elle est principalement utilisée pour les services prepaid comme les cartes de recharge téléphonique. 65

73 66 Figure 5.1 Intégration de la plate-forme NGIN dans l environnement de l opérateur méthode d intégration actuelle consiste à créer des liens directs entre l application de gestion de la plate-forme et les applications censées communiquer avec cette dernière. Le problème causé par cette méthode d intégration est d abord un problème financier car l opérateur doit payer en plus l équipe d intégration pour son travail. C est aussi un problème de perte de temps car la création d interfaces entre les applications peut nécessiter plusieurs jours de travail. Enfin, il s agit d une approche qui va handicaper l ensemble du système vu que les applications de l opérateur vont dépendre de l application de gestion de la plate-forme. 5.2 Architecture de l application de gestion de la plateforme Le développement de cette application est basé sur MDA et plus particulièrement sur EMF. Le choix d éclipse 3, comme environnement de développement s explique par sa maturité et sa puissance. Il est à noter que les deux principaux objectifs des concepteurs 3.

74 67 Figure 5.2 Exemple de deux profiles créés dans Eclipse d Eclipse sont la modularité et l extensibilité. Grâce à cela, l équipe d Alcatel-Lucent a pu développer un ensemble de modules ou de Plugin offrant des fonctionnalités avancées au niveau de la modélisation des profiles JAIN SLEE(section 4.8.1). Ainsi, nous pouvons facilement modéliser une spécification d un profile JAIN SLEE sous forme de modèle EMF. À partir de ce modèle sera automatiquement généré : Le schéma ainsi que la logique d exécution du profile sur une plate-forme JAIN SLEE. Clairement, il s agit du code du service de télécommunication. Des EJBs qui exposent les méthodes de manipulation et de mise à jour du profile. Ils disposent d une interface SOAP qui permet d effectuer des requêtes de façon très pratique. Un ensemble de page web permettant à l administateur d appeler les méthodes de gestion du profile via une interface web. A ce stade, le développeur doit : Déployer le profile JAIN SLEE sur la plate-forme adéquate. Déployer les EJBs ainsi que l application web sur un serveur applicatif Transformation du modèle EMF La transformation d un modèle représentant une spécification d un profile JAIN SLEE génère automatiquement une classe contenant l ensemble des attributs du profile ainsi que des getters et des setters pour la manipulation de ces attributs. Il est évident que la transformation ne peut pas générer toutes les classes des EJBs, ni les pages web qui seront déployées sur le serveur applicatif. En effet, l implémentation de ces classes ainsi que des pages web est tellement spécifique qu il est impossible de l indiquer au

75 68 moment de la création du modèle. C est ici que la technologie JET (section 4.8.1) va avoir son utilité car elle va nous permettre de définir l implémentation des EJBs ainsi que l ensemble des fichiers nécessaires à leur déploiement. De même, le contenu des pages web sera décrit au travers d un générateur JET. L utilisation de ces générateurs permet de changer l implémentation en fonction du contexte. Il suffit d écrire l ensemble des modèles ou des templates qui seront utilisés par le générateur et le tour est joué. Il va sans dire que plusieurs générateurs sont nécessaires au niveau de la transformation du profile JAIN SLEE. Parmi ces générateurs nous pouvons citer le générateur qui va définir l implémentation de l EJB. Notons qu un template est nécessaire pour la génération de chaque classe Java contenue dans l EJB. Afin d être plus précis, voici une description détaillée de l ensemble des composants généré grâce à l utilisation de la transformation EMF combinée avec les générateurs JET. Un projet contenant le code du profile JAIN SLEE : Ce projet contient le code du service de télécommunication ainsi que le code de la spécification du profile JAIN SLEE, il comporte aussi les éléments suivants : Un fichier XML utilisé pour le déploiement. Ce fichier XML permet d établir une relation entre le profile JAIN SLEE et la table de base de données ainsi que son utilisateur associé dans ORACLE. Un fichier zip contenant les commandes pour l installation et la configuration de la base de données. Il permet, en outre, de créer la table du profile dans la base de données. Un projet Eclipse contenant les EJBs : Chaque profile doit avoir un EJB qui le représente au sein du serveur applicatif. Cet EJB est composé des éléments suivants : Une classe Serialisable représentant le profile. Si nous reprenons l exemple de la figure 4.8.1, nous aurions automatiquement une classe Company dans l EJB responsable du profile Company. Cette dernière contient exactement les même attributs définis au niveau de la figure Quant aux méthodes métiers, elles seront définies au niveau de la classe CompanyAccessBean. Une classe permettant d exécuter l ensemble des méthodes métier (CompanyAccessBean pour le profile Compagy par exemple), elle reçoit une instance de la classe représentant le profile en vue de lui appliquer une méthode. Cette classe implémente une interface qui définit exclusivement les méthodes métiers du profile. Une interface Local et une autre Remote pour la manipulation distante de l EJB. Une classe Héritant de GenericSOAPHandler qui permet de manipuler les requêtes SOAP. Un fichier jaxws-handlers.xml indiquant le nom de la classe responsable du traitement des requêtes SOAP. Un ensemble de Stub (section 4.5.1) ainsi que toutes les classes nécessaires à leur fonctionnement. Un projet Eclipse contenant les portlets : Ce projet est constitué de plusieurs éléments : Un ensemble de ressources Java nécessaires au fonctionnement des portlets 4. Nous retrouvons dans ce package la classe représentant le profile et disposant, 4. Une portlet est un composant web destiné à être intégré dans le contexte d une page composite.

76 69 en outre des attributs, d un ensemble de méthodes métier utilisant les Stubs pour accéder aux EJBs. Un ensemble de ressources contenant principalement des script Java. Un ensemble de pages web Java Server Page XML (JSPX). Ces pages JSPX sont dédiées à la partie présentation. Le rôle d une page JSPX est : De représenter graphiquement les informations (notamment grâce à l utilisation de balises IceFaces 5 D effectuer le transfert des informations saisies par l utilisateur vers le EJB correspondant. 5.3 Fonctionnement de l application de gestion de la plateforme Figure 5.3 Illustration du fonctionnement d un EJB + portlet Pour résumer le fonctionnement habituel de l application de gestion de la plate-forme, celle-ci est accessible soit via des portlets pour l administrateur qui souhaite y accéder en utilisant une interface graphique, soit via l interface SOAP de l EJB. Les applications intéressées pouront s adresser de manière directe aux EJBs via cette interface, leurs requêtes seront traitées de manière synchrone. 5. Il s agit d une bibliothèque de composants AJAX qui permet de faciliter le développement d une application sophistiquée avec une interface riche pour une application Java Server Face (JSF).

77 Chapitre 6 Proposition d une solution d intégration 6.1 Les apports de la solution La chapitre précédent explique à la fois l architecture et le fonctionnement de l application de gestion de la plate-forme. Nous avons pu constater trois problèmes lors de son intégration dans le système informatique de l opérateur de télécommunication : Un problème financier. En effet, l opérateur doit payer les frais supplémentaires dûs au travail d intégration réalisé par l équipe d Alcatel-Lucent. Un problème de timing car le travail de l équipe d intégration peut prendre plusieurs jours. Un problème architectural vu que les liens one-to-one créés vont handicaper l ensemble des applications concernées. Nous voulons montrer, à travers ce travail, une nouvelle approche pour l intégration de l application de gestion de la plate-forme dans le système informatique de l opérateur. EDA (section 3) sera à la base de cette approche. En effet, les liens qui peuvent être établis par l équipe d intégration servent comme support pour envoyer des requêtes à l application de gestion de la plate-forme. Ces requêtes peuvent très bien être envoyées sous forme d évènements(figure 6.1). Une entité centrale 1 s occupera de la récolte de ces évènements et de leur transfert vers l application de gestion de la plate-forme. Une attention particulière doit être portée à la nature des requêtes envoyées à l application de gestion de la plate-forme. Il s agit, très souvent, de demandes de création de compte pour un client, de demandes de mise à jour des informations du client, etc. Ce sont des demandes qui doivent être traitées immédiatement. Autrement dit, les applications doivent communiquer de manière synchrone avec l application de gestion de la plate-forme. Cette remarque nous amène à la conclusion suivant laquelle il faut être vigilant lors de l implémentation du modèle publish/subscribe que prône EDA. Un traitement lent au niveau de l Event Collector engendrait un temps de latence au niveau de l application cliente. 1. Il s agit de l Event Collector 70

78 71 Figure 6.1 Intégration grâce à EDA Avant de présenter les détails de la solution, voyons l ensemble des avantages de cette approche : L abstraction En effet, lorsqu on introduit une couche d abstraction entre les composants, cela nous permet de dire que l ensemble des composants communiquants sont complètement indépendants les uns des autres. De plus, chaque application (CRM, ERP, etc) peut utiliser un format différent pour l encodage de ses requêtes. L unité centrale jouant le rôle d Event Collector se chargera de la transformation des données de ces requêtes afin qu il y ait un modèle unique d évènements au sein de l Event Collector. L exploitation des évènements L Event Collector récolte l ensemble des évènements afin de les préparer et de les redistribuer aux composants intéressés. Cela étant, une copie de ces évènements peut être utilisée à d autres fins. Un CEP (Complex Event Processing) peut être branché sur l Event Collector et profiter pour analyser tous les évènements qui y circulent. L évoluabilité Les applications communiquantes peuvent évoluer indépendamment sans se préoccuper du reste du système. Une seule entité ( l Event Collector) devra tenir compte des modifications des applications afin d assurer le transfert des évènements. Il est à noter que l Enterprise Service Bus (ESB) est spécialement adapté pour jouer le rôle de fédérateur d évènements ou d Event Collector (section ). Des composants appelés connecteurs ou gateways peuvent être définis au niveau de l ESB en vue de recevoir de l information et de la traiter afin de l acheminer vers une destination donnée. Dans la suite, une implémentation récente de JBoss ESB 2 sera utilisée comme Event Collector. 2. Le JBoss ESB 4.7

79 Description de la solution d intégration Utilisation de JBoss ESB comme Event Collector La première partie sur laquelle il faut se concentrer afin de comprendre la subtilité de la solution est la partie composée de l Event Collector (JBoss ESB) et l application de gestion de la plate-forme. En effet, l application de gestion dispose d une interface SOAP pour les appels distants. Parallèlement à cela, le JBoss ESB peut facilement manipuler le protocole SOAP. C est pour cette raison que le protocole SOAP a été choisi pour la communication entre le JBoss ESB et l application de gestion de la plate-forme. Figure 6.2 Communication entre le JBoss ESB et l application de gestion Une fois cette partie est définie, il reste à savoir comment les applications du système informatique de l opérateur vont communiquer avec le JBoss ESB. En effet, la solution qui semble tenir la route consiste à utiliser ce même protocole SOAP pour les requêtes venants de ces applications. Le choix du protocole SOAP n est pas aléatoire car tous les concepteurs de logiciels l utilisent aujourd hui dans l appel des web services. À ce stade, nous savons que seul le protocole SOAP sera utilisé pour la communication entre les applications et le JBoss ESB. Cela est censé faciler la mise en place de la solution car les interfaces SOAP des applications ne vont pas changer. Toutefois, le JBoss ESB va venir s insérer comme intermédiaire dans la communication. Maintenant que le protocole de communication est établi, nous allons essayer de trouver une méthode pour recevoir les requêtes SOAP au niveau du JBoss ESB et les traiter en vue de les renvoyer vers l application de gestion de la plate-forme.

80 73 Figure 6.3 Communication entre le JBoss ESB et les applications Utilisation de gateways pour forwarder les requêtes La section présente les gateways de l ESB comme étant des composants internes à l ESB, capables de déplacer les messages de l extérieur vers l intérieur de ce dernier tout en leurs appliquant des transformations. Plusieurs types de gateways sont mis à disposition de l utilisateur afin qu il puisse connecter toutes les applications qui respectent les standards. Ici, nous allons nous concentrer sur un type récent de gateway : les gateways de type SoapProxy. En effet, un gateway de type SoapProxy a la capacité de recevoir une enveloppe SOAP et de lui appliquer un ensemble d actions. Il est principalement utilisé pour représenter une référence externe utilisant les web services en la déployant comme référence sur l ESB. Ce dernier joue le rôle d intermédiare entre le consommateur de service et le producteur de service final [9]. L apport majeur de ce nouveau type de gateway 3 est la création d une couche d abstraction qui permet de régler les problèmes suivants : Fournir un découplage lâche entre le client et le service, ils sont complètement indépendant dans ce cas. Le client ne doit plus établir une connection directe avec le nom de machine ou l adresse IP du service distant. Le client va accéder au WSDL 4 qui modifie les paramètres de l émetteur et du récepteur afin que les requêtes transitent par lui. La transformation de l enveloppe SOAP et de son contenu peut être effectuée au niveau de l ESB. Pour cela, il suffit de définir une action qui sera déclenchée au moment de la réception de la requête. Le versionning des service (section 4.6). 3. Disponible à partir de la version 4.7 de JBoss ESB 4. Pour plus d information sur ce langage, consulter la section 4.5.1

81 74 Le routage des requêtes en se basant sur le contenu. En d autre termes, l ESB peut détecter la nature de la requête et la renvoyer à un service particulier sans que ce dernier ne soit indiqué dans la requête initiale. Figure 6.4 Utilisation d un gateway de type SoapProxy L action qui peut être exécutée au niveau du gateway SoapProxy : Est à la fois, un producteur et un consommateur de web services. Nécessite une seule propriété qui indique la référence externe du WSDL. Permet de transformer automatiquement le WSDL référencé par cette propriété. Permet d utiliser une fonction de routage pour atteindre le service final (Grâce notamment à la propriété HttpRouter) Utilisation d un gateway de type SoapProxy Plusieurs propriétés peuvent être définies au niveau de ce type de gateway [9] : wsdl cible : représente le wsdl référencé par le gateway et qui sera réécrit et exposé comme étant un nouveau wsdl sur l ESB. En fonction de l attribut address utilisé dans l élément soap indiquant le protocole de communication ( http par exemple), une implémentation spécifique pour ce protocole sera utilisée grâce à la classe SOAPProxyTransport. La valeur de ce paramètre peut utiliser différents schémas : http, https, file, classpath ou un lien interne à JBossWs. Voici un liste d exemples : http ://localhost :8080/Quickstart webservice proxy basic ws/helloworldws?wsdl https ://localhost :8443/webservice proxy security/helloworldws?wsdl file :///tmp/helloworldws.wsdl classpath ://META-INF/HelloWorldWS.wsdl internal ://jboss.ws :context=quickstart webservice proxy basic ws,endpoint=helloworldws

82 75 wsdltranform : Ce paramètre indique le fichier xml contenant la configuration pour une éventuelle transformation des requêtes SOAP. Url de la référence : peut être utilisé pour indiquer un ensemble de propriétés comme le routage utilisé, etc. fichier : utilisé lorsque le web service externe utilise la technologie SSL. clientcredentialsrequired : indique si le client doit être identifié et si un fichier doit être utilisé pour l authentification. L exemple suivant montre une implémentation d un gateway SoapProxy utilisant une authentification + ssl : Figure 6.5 Implémentation d un gateway SoapProxy 6.3 Implémentation de la solution d intégration La solution que nous proposons ici consiste en un projet déployable sur un JBoss ESB. Avant d expliquer la structure de ce projet, nous allons préparer l environnement d exécution Installation et configuration de l environnement de déploiement Le JBoss ESB 4.7 est un outil open source disponible gratuitement sur l adresse suivante : Bien qu il s agisse d un outil extrêment sophistiqué, il existe une version de JBoss ESB compilée sous forme d application web et déployable sur un serveur applicatif. C est cette version que nous allons utiliser pour l implémentation de la solution d intégration. Le serveur applicatif qui sera utilisé ici est celui de JBoss. La version 5.1 de ce dernier peut être téléchargée sur cette adresse Enfin, il importe de vérifier que la version du Java Development Kit (JDK) utilisée par défaut au niveau du système d exploitation est au moins égale à Installation de JBoss ESB sur un JBoss Application Server Le JBoss AS ne nécessite aucune installation. Il suffit de décompresser le répertoire téléchargé dans un répertoire de son choix pour pouvoir l utiliser. Ainsi, pour lancer ce serveur il suffit d exécuter le fichier batch run qui se trouve dans le sous-répertoire bin. Afin de faciliter le déploiement, nous allons d abord décompresser le JBoss ESB dans un répertoire donné et ensuite y mettre le répertoire de JBoss AS. Au final, nous devons avoir cette structure :

83 76 Figure 6.6 Contenu du répertoire jbossesb-4.7 Plusieurs éléments doivent être modifiés afin de combiner le JBoss ESB avec le JBoss AS : 1. Aller dans jbossesb-4.7/install et modifier le fichier deployement.properties en indiquant le home directory du serveur applicatif. Exemple : org.jboss.esb.server.home=/users/mohammedjelti/desktop/jbossesb-4.7/jboss ga 2. Se mettre dans le répertoire de jbossesb-4.7/install et lancer Ant deploy 5. Le fichier build.xml contient la liste des tâches nécessaires au déploiement de l application représenant l ESB sur le JBoss AS. 3. Sauvegarder le fichier jbossesb-4.7/jboss ga/server/default/deploy/adminconsole.war/plugins/rhq-jbossesbplugin as4.jar 4. Supprimer jbossesb-4.7/jboss ga/server/default/deploy/admin-console.war/ 5. Télécharger le fichier war suivant jboss/jopr/jopr-embeddedjbas5/1.3.2.ga/jopr-embedded-jbas ga. war. 6. Extraire ce fichier dans jbossesb-4.7/jboss ga/server/default/deploy/ 5. Télécharger Ant Apache si nécessaire sur

84 77 7. Copier le fichier [rhq-jbossesbplugin as4.jar] sauvegardé dans le répertoire [jbossesb-4.7/jboss ga/server/default/deploy/admin-console.war/plugins/] 8. Dans le répertoire jbossesb-4.7/jboss ga/server/default/deploy/, localiser le fichier /profileservice-secured.jar/meta-inf/ejb-jar.xml et modifier le texte de l élément res-ref-name en java :profileservice (3 occurences). 9. Dans ce même répertoire, localiser le fichier profileservice-jboss-beans.xml et modifier le contenu de l élément property dont le nom est jndiname en java :profileservice (1 occurence) 10. Copier les quatres fichiers ci-dessous de jbossesb-4.7/jboss ga/client vers jbossesb-4.7/jboss ga/lib/endorsed jbossws-native-jaxrpc.jar jbossws-native-jaxws-ext.jar jbossws-native-jaxws.jar jbossws-native-saaj.jar 11. Télécharger jbossws-native ga sur le site de jboss. 12. Décompresser le répertoire dans jbossesb-4.7/ 13. Copier le fichier jbossesb-4.7/jbossws-native-bin-dist/ant.properties.example vers /jbossws-native-bin-dist/ant.properties 14. Renseigner le jboss510.home dans ce fichier. Exemple : jboss510.home=/users/mohammedjelti/desktop/jbossesb-4.7/jboss ga 15. Se mettre dans le répertoire jbossesb-4.7/jbossws-native-bin-dist/ et exécuter la commande suivante : ant deploy-jboss510 A ce stade, le JBoss ESB est complètement déployé sur le JBoss AS. Pour vérifier cela, il suffit de lancer le JBoss AS via le batch run qui se trouve dans le répertoire jbossesb-4.7/jboss ga/bin. L écran suivant(figure 6.7) est censé s afficher au bout de quelques secondes de démarrage. La console d administration devra afficher les statistiques du JBoss ESB en plus des applications et des ressources déployés sur le JBoss AS Structure du projet La solution que nous proposons ici consiste à ouvrir un EPR (section 4.7.2) sur l ESB pour qu il puisse recevoir les requêtes SOAP destinées aux EJBs. Nous avons montré

85 78 Figure 6.7 Démarrage de JBoss AS combiné avec JBoss ESB Figure 6.8 Console d administration du JBoss AS combiné avec JBoss ESB dans la section précédente que le JBoss ESB est combiné au serveur applicatif JBoss AS. Nous supposons ici que les EJBs sont déployés sur ce même serveur applicatif. Ainsi la redirection des requêtes au niveau du gateway de l ESB fera appel à un EJB qui sera déployé en local. La projet ESB est constitué de plusieurs fichiers : Le fichier jboss-esb.xml : contient la configuration du gateway qui sera déployé sur le JBoss ESB. Le fichier jbossesb-properties.xml : contient les paramètres de configuration de JBoss ESB. Le fichier deployment.xml : décrit les ressources nécessaires à l exécution du service déployé. Le fichier jndi.properties : indique au client ou se trouve le serveur applicatif. Le fichier build.xml : contient des tâches Ant 6 pour la compilation, l exécution, le test et le déploiement du service. Seul le contenu du fichier jboss-esb.xml sera détaillé par la suite. Les autres fichiers sont des fichiers de configuration fournis par JBoss AS. Ce fichier (Figure 6.11) décrit le nouveau service qui sera déployé sur l ESB. En effet, CompanyAccessService dispose d un gateway http qui reçoit les requêtes SOAP en 6.

JEE - Cours et TP. Mickaël Montassier. 15 février 2007. Institut Universitaire de Technologie Département Informatique

JEE - Cours et TP. Mickaël Montassier. 15 février 2007. Institut Universitaire de Technologie Département Informatique et TP Institut Universitaire de Technologie Département Informatique 15 février 2007 J2EE? J2EE : Java 2 Enterprise Edition Norme prosposée par SUN visant à définir un standard de développement d applications

Plus en détail

Programmation d applications distribuées

Programmation d applications distribuées Programmation d applications distribuées François Charoy Université Henri Poincaré 8 octobre 2007 Première partie I Développement d applications distribuées Objectifs du cours Comprendre ce qu est une

Plus en détail

Architecture JEE. Objectifs attendus. Serveurs d applications JEE. Architectures JEE Normes JEE. Systèmes distribués

Architecture JEE. Objectifs attendus. Serveurs d applications JEE. Architectures JEE Normes JEE. Systèmes distribués Architecture JEE. Objectifs attendus Serveurs d applications JEE Systèmes distribués Architectures JEE Normes JEE couches logicielles, n-tiers framework JEE et design patterns 2007/02/28 Eric Hébert.eheb@yahoo.fr

Plus en détail

Conception Exécution Interopérabilité. Déploiement. Conception du service. Définition du SLA. Suivi du service. Réception des mesures

Conception Exécution Interopérabilité. Déploiement. Conception du service. Définition du SLA. Suivi du service. Réception des mesures Software propose une offre d intégration unique, qui apporte l équilibre parfait entre investissements et performances pour les entreprises qui doivent sans cesse améliorer leurs processus. Des caractéristiques

Plus en détail

NFP111 Systèmes et Applications Réparties

NFP111 Systèmes et Applications Réparties NFP111 Systèmes et Applications Réparties 1 de 38 NFP111 Systèmes et Applications Réparties Cours 11 - Les Enterprise Java Beans (Introduction aux Enterprise Claude Duvallet Université du Havre UFR Sciences

Plus en détail

Intégration d'applications d'entreprise (INTA)

Intégration d'applications d'entreprise (INTA) Master 2 SITW - Recherche Intégration d'applications d'entreprise (INTA) Dr. Djamel Benmerzoug Email : djamel.benmerzoug@univ-constantine2.dz Maitre de Conférences A Département TLSI Faculté des NTIC Université

Plus en détail

Urbanisme du Système d Information et EAI

Urbanisme du Système d Information et EAI Urbanisme du Système d Information et EAI 1 Sommaire Les besoins des entreprises Élément de solution : l urbanisme EAI : des outils au service de l urbanisme 2 Les besoins des entreprises 3 Le constat

Plus en détail

Introduction à la plateforme J2EE

Introduction à la plateforme J2EE Introduction à la plateforme J2EE Auteur : Oussama Essefi Directeur technique Expert Consulting Oussama.essefi@expert-consulting.biz Copyright 2010 Expert Consulting Page 1 1. Introduction 1.1. Pourquoi

Plus en détail

Institut Supérieur de Gestion. Cours pour 3 ème LFIG. Java Enterprise Edition Introduction Bayoudhi Chaouki

Institut Supérieur de Gestion. Cours pour 3 ème LFIG. Java Enterprise Edition Introduction Bayoudhi Chaouki Institut Supérieur de Gestion Cours pour 3 ème LFIG Java Enterprise Edition Introduction Bayoudhi Chaouki 1 Java EE - Objectifs Faciliter le développement de nouvelles applications à base de composants

Plus en détail

Environnements de Développement

Environnements de Développement Institut Supérieur des Etudes Technologiques de Mahdia Unité d Enseignement: Environnements de Développement BEN ABDELJELIL HASSINE Mouna m.bnaj@yahoo.fr Développement des systèmes d Information Syllabus

Plus en détail

Exécution des applications réparties

Exécution des applications réparties Exécution des applications réparties Programmation des Applications Réparties Olivier Flauzac URCA Master STIC-Informatique première année Olivier Flauzac (URCA) PAR : Exécution des applications réparties

Plus en détail

Objectif : Passer de l analyse métier et fonctionnelle à la définition des applications qui

Objectif : Passer de l analyse métier et fonctionnelle à la définition des applications qui Formation PARTIE 1 : ARCHITECTURE APPLICATIVE DUREE : 5 h Objectif : Passer de l analyse métier et fonctionnelle à la définition des applications qui automatisent les fonctions Définir une architecture

Plus en détail

Introduction pratique au Développement orienté Modèle Pierre Parrend, Mars 2005

Introduction pratique au Développement orienté Modèle Pierre Parrend, Mars 2005 MDA : Un Tutoriel Introduction pratique au Développement orienté Modèle Pierre Parrend, Mars 2005 1 Sommaire Table des matières 1 Sommaire 1 2 Introduction 2 2.1 A qui s adresse ce tutoriel......................

Plus en détail

Tour d horizon de Java EE 6

Tour d horizon de Java EE 6 1 Tour d horizon de Java EE 6 De nos jours, les entreprises évoluent dans une compétition à l échelle mondiale. Elles ont besoin pour résoudre leurs besoins métiers d applications qui deviennent de plus

Plus en détail

Les nouvelles architectures des SI : Etat de l Art

Les nouvelles architectures des SI : Etat de l Art Les nouvelles architectures des SI : Etat de l Art Objectif Mesurer concrètement les apports des nouvelles applications SI. Être capable d'évaluer l'accroissement de la complexité des applications. Prendre

Plus en détail

Messagerie asynchrone et Services Web

Messagerie asynchrone et Services Web Article Messagerie asynchrone et Services Web 1 / 10 Messagerie asynchrone et Services Web SOAP, WSDL SONT DES STANDARDS EMERGEANT DES SERVICES WEB, LES IMPLEMENTATIONS DE CEUX-CI SONT ENCORE EN COURS

Plus en détail

Développement logiciel pour l Architecture Orientée Services avec IBM Rational Software Development Platform

Développement logiciel pour l Architecture Orientée Services avec IBM Rational Software Development Platform IBM Software Group Développement logiciel pour l Architecture Orientée Services avec IBM Rational Software Development Platform Thierry Bourrier, Techical Consultant thierry.bourrier@fr.ibm.com L Architecture

Plus en détail

Architecture des systèmes d information

Architecture des systèmes d information Architecture des systèmes d information Table des matières 1 La décennie 70 1 2 Le modèle relationnel (les années 80) 1 3 Enrichissement du relationnel (les années 80/90) 2 4 Système d informations (les

Plus en détail

L EAI. par la pratique. François Rivard. Thomas Plantain. Groupe Eyrolles, 2003 ISBN : 2-212-11199-1

L EAI. par la pratique. François Rivard. Thomas Plantain. Groupe Eyrolles, 2003 ISBN : 2-212-11199-1 L EAI par la pratique François Rivard Thomas Plantain ISBN : 2-212-11199-1 Table des matières Avant-propos................................................ Quel est l objectif de cet ouvrage...............................

Plus en détail

ORACLE DATA INTEGRATOR ENTERPRISE EDITION - ODI EE

ORACLE DATA INTEGRATOR ENTERPRISE EDITION - ODI EE ORACLE DATA INTEGRATOR ENTERPRISE EDITION - ODI EE ORACLE DATA INTEGRATOR ENTERPRISE EDITION offre de nombreux avantages : performances de pointe, productivité et souplesse accrues pour un coût total de

Plus en détail

D une part, elles ne peuvent faire table rase de la richesse contenue dans leur système d information.

D une part, elles ne peuvent faire table rase de la richesse contenue dans leur système d information. PACBASE «Interrogez le passé, il répondra présent.». Le Module e-business Les entreprises doivent aujourd hui relever un triple défi. D une part, elles ne peuvent faire table rase de la richesse contenue

Plus en détail

Apache Tomcat 8 Guide d'administration du serveur Java EE 7 sous Windows et Linux

Apache Tomcat 8 Guide d'administration du serveur Java EE 7 sous Windows et Linux Avant-propos 1. À qui s adresse ce livre? 11 2. Les pré-requis 12 Préambule 1. Rappel sur les architectures Internet/Intranet/Extranet 13 1.1 Le protocole HTTP 14 1.1.1 Les méthodes HTTP 16 1.1.2 Les codes

Plus en détail

Auto-évaluation Aperçu de l architecture Java EE

Auto-évaluation Aperçu de l architecture Java EE Auto-évaluation Aperçu de l architecture Java EE Document: f1218test.fm 22/03/2012 ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium TRAINING & CONSULTING INTRODUCTION AUTO-ÉVALUATION APERÇU

Plus en détail

SOA et Services Web. 23 octobre 2011. SOA: Concepts de base

SOA et Services Web. 23 octobre 2011. SOA: Concepts de base SOA et Services Web 23 octobre 2011 1 SOA: Concepts de base 2 Du client serveur à la SOA N est Nest pas une démarche entièrement nouvelle: années 1990 avec les solutions C/S Besoins d ouverture et d interopérabilité

Plus en détail

NFP111 Systèmes et Applications Réparties

NFP111 Systèmes et Applications Réparties NFP111 Systèmes et Applications Réparties 1 de 46 NFP111 Systèmes et Applications Réparties Cours 2 - Les appels de procédure distants (Partie 1) Claude Duvallet Université du Havre UFR Sciences et Techniques

Plus en détail

Le Cloud Computing et le SI : Offre et différentiateurs Microsoft

Le Cloud Computing et le SI : Offre et différentiateurs Microsoft Le Cloud Computing désigne ces giga-ressources matérielles et logicielles situées «dans les nuages» dans le sens où elles sont accessibles via Internet. Alors pourquoi recourir à ces centres serveurs en

Plus en détail

NOVA BPM. «Première solution BPM intégr. Pierre Vignéras Bull R&D

NOVA BPM. «Première solution BPM intégr. Pierre Vignéras Bull R&D NOVA BPM «Première solution BPM intégr grée» Pierre Vignéras Bull R&D Définitions Business Process Pratiques existantes qui permettent aux personnes et systèmes de travailler ensemble Business Process

Plus en détail

Modèle de cahier des charges pour un appel d offres relatif à une solution de gestion des processus métier (BPM)

Modèle de cahier des charges pour un appel d offres relatif à une solution de gestion des processus métier (BPM) LA BOITE A OUTILS DE L ACHETEUR DE BPM Modèle de cahier des charges pour un appel d offres relatif à une solution de gestion des processus métier (BPM) La boîte à outils de l acheteur de solution BPM -

Plus en détail

Composition de Services Web

Composition de Services Web Composition de Services Web Dr. Djamel Benmerzoug Email : djamel.benmerzoug@univ-constantine2.dz Maitre de Conférences A, Département TLSI Faculté des NTIC Université Constantine 2 Abdelhamid Mehri 127

Plus en détail

Spring par la pratique

Spring par la pratique Spring par la pratique 2 e édition Spring 2.5 et 3.0 Arnaud Cogoluègnes Thierry Templier Julien Dubois Jean-Philippe Retaillé avec la contribution de Séverine Templier Roblou et de Olivier Salvatori Groupe

Plus en détail

l'esb JBI au coeur de l'initiative SOA

l'esb JBI au coeur de l'initiative SOA l'esb JBI au coeur de l'initiative SOA Initiative SOA Gaël Blondelle CTO EBM WebSourcing Chairman Technology Council OW2 13 Juin 2007 Agenda Ptf de référence OW2 Initiative SOA PEtALS, l'esb d'ow2 2 Opportunité

Plus en détail

Les Architectures Orientées Services (SOA)

Les Architectures Orientées Services (SOA) Les Architectures Orientées Services (SOA) Ulrich Duvent Guillaume Ansel Université du Littoral Côte d Opale 50, Rue Ferdinand Buisson BP 699 62228 Calais Cedex Téléphone (33) 03.21.46.36.92 Télécopie

Plus en détail

Introduction aux systèmes répartis

Introduction aux systèmes répartis Introduction aux systèmes répartis Grappes de stations Applications réparties à grande échelle Systèmes multicalculateurs (1) Recherche de puissance par assemblage de calculateurs standard Liaison par

Plus en détail

Architectures web pour la gestion de données

Architectures web pour la gestion de données Architectures web pour la gestion de données Dan VODISLAV Université de Cergy-Pontoise Plan Le Web Intégration de données Architectures distribuées Page 2 Le Web Internet = réseau physique d'ordinateurs

Plus en détail

WEB15 IBM Software for Business Process Management. un offre complète et modulaire. Alain DARMON consultant avant-vente BPM alain.darmon@fr.ibm.

WEB15 IBM Software for Business Process Management. un offre complète et modulaire. Alain DARMON consultant avant-vente BPM alain.darmon@fr.ibm. WEB15 IBM Software for Business Process Management un offre complète et modulaire Alain DARMON consultant avant-vente BPM alain.darmon@fr.ibm.com Claude Perrin ECM Client Technical Professional Manager

Plus en détail

Compte Rendu d intégration d application

Compte Rendu d intégration d application ISMA 3EME ANNEE Compte Rendu d intégration d application Compte Rendu Final Maxime ESCOURBIAC Jean-Christophe SEPTIER 19/12/2011 Table des matières Table des matières... 1 Introduction... 3 1. Le SGBD:...

Plus en détail

1. Une approche innovante, basée sur «l objet document» 2. Le respect des chaînes éditoriales de l entreprise

1. Une approche innovante, basée sur «l objet document» 2. Le respect des chaînes éditoriales de l entreprise Lucid e-globalizer, solution globale de gestion de contenu multilingue. Ce document a pour objectif de vous présenter Lucid e-globalizer, la solution de gestion de contenu multilingue de Lucid i.t., ses

Plus en détail

Solutions de gestion de la sécurité Livre blanc

Solutions de gestion de la sécurité Livre blanc Solutions de gestion de la sécurité Livre blanc L intégration de la gestion des identités et des accès avec l authentification unique Objectif : Renforcer la politique de sécurité et améliorer la productivité

Plus en détail

Fusion : l interopérabilité chez Oracle

Fusion : l interopérabilité chez Oracle Standardisation et interopérabilité Fusion : l interopérabilité chez Oracle Lionel Dubreuil,, Applications Technology Product Manager, Oracle France, lionel.dubreuil@oracle.com 29/03/2006 Page : 1 Oracle

Plus en détail

Conception d Applications Réparties

Conception d Applications Réparties Jean-François Roos LIFL - équipe GOAL- bâtiment M3 Extension - bureau 206 -Jean-Francois.Roos@lifl.fr 1 Objectifs du Cours Appréhender la conception d applications réparties motivations et concepts architectures

Plus en détail

BizTalk 2006. Business Process Integration

BizTalk 2006. Business Process Integration BizTalk 2006 Business Process Integration Préoccupations Métier vs IT Accroître la Qualité de Service (Faire plus avec Moins) Meilleure Visibilité et Contrôle Sur le Métier Motivé par des enjeux métiers

Plus en détail

OFFRE DE FORMATION L.M.D.

OFFRE DE FORMATION L.M.D. REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE MINISTERE DE L ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE SCIENTIFIQUE OFFRE DE FORMATION L.M.D. MASTER PROFESSIONNEL ET ACADEMIQUE Systèmes d Information

Plus en détail

Hébergement MMI SEMESTRE 4

Hébergement MMI SEMESTRE 4 Hébergement MMI SEMESTRE 4 24/03/2015 Hébergement pour le Web Serveurs Mutualités Serveurs Dédiés Serveurs VPS Auto-Hébergement Cloud Serveurs Mutualités Chaque Serveur héberge plusieurs sites Les ressources

Plus en détail

Systèmes d Information Avancés (et répartis)

Systèmes d Information Avancés (et répartis) Systèmes d Information Avancés (et répartis) Université Lyon 1 MIAGE L. Médini, mars 2005 Plan des cours Protocole HTTP et programmation serveur Architectures réparties Objets distribués Introduction aux

Plus en détail

Java et Objet. Amélie Lambert 2014-2015. Amélie Lambert 2014-2015 1 / 42

Java et Objet. Amélie Lambert 2014-2015. Amélie Lambert 2014-2015 1 / 42 Java et Objet Amélie Lambert 2014-2015 Amélie Lambert 2014-2015 1 / 42 Chapitre 8 Développement d applications Web Amélie Lambert 2014-2015 2 / 42 Plan du cours Typologie des applications Web Architecture

Plus en détail

Architecture Logicielle

Architecture Logicielle Architecture Logicielle Chapitre 3: UML pour la description et la documentation d une architecture logicielle Année universitaire 2013/2014 Semestre 1 Rappel L architecture d un programme ou d un système

Plus en détail

Chapitre I : Protocoles client serveur et architectures distribuées

Chapitre I : Protocoles client serveur et architectures distribuées Licence Pro Réseaux Télécom Systèmes Internet et Intranet pour l entreprise Chapitre I : Protocoles client serveur et architectures distribuées Département IEM / UB Eric.Leclercq@u-bourgogne.fr Bureau

Plus en détail

La S O A O pen S ource avec. Démos / Outils PEtALS

La S O A O pen S ource avec. Démos / Outils PEtALS La S O A O pen S ource avec Démos / Outils PEtALS Sept. 2007 La route vers la SOA Un ESB (Enterprise Service Bus) basé sur les standards Java, JBI et Web Services est une bonne technologie pour instancier

Plus en détail

PRIMAVERA P6 ENTERPRISE PROJECT PORTFOLIO MANAGEMENT WEB SERVICES

PRIMAVERA P6 ENTERPRISE PROJECT PORTFOLIO MANAGEMENT WEB SERVICES PRIMAVERA P6 ENTERPRISE PROJECT PORTFOLIO MANAGEMENT WEB SERVICES DÉCOUVREZ DES POSSIBILITÉS ILLIMITÉES GRÂCE A L INTÉGRATION À DES SYSTÈMES D ENTREPRISE EXISTANTS FONCTIONNALITÉS Connectivité des systèmes

Plus en détail

Construire un annuaire d entreprise avec LDAP

Construire un annuaire d entreprise avec LDAP Construire un annuaire d entreprise avec LDAP Marcel Rizcallah Éditions Eyrolles ISBN : 2-212-09154-0 2000 Introduction L économie en réseau ou la Net-économie est au cœur des débats et des stratégies

Plus en détail

Oracle Fusion Middleware Concepts Guide 11g Release 1 (11.1.1) Figure 1-1 Architecture Middleware

Oracle Fusion Middleware Concepts Guide 11g Release 1 (11.1.1) Figure 1-1 Architecture Middleware 1 Introduction Ce chapitre décrit Oracle Fusion Middleware. Il comprend : o Qu'est-ce que Middleware o Les fonction de Middleware o L'architecture de conception Middleware o L'architecture orientée services

Plus en détail

Introduction aux «Services Web»

Introduction aux «Services Web» Introduction aux «Services Web» Sana Sellami sana.sellami@univ-amu.fr 2014-2015 Modalité de contrôle de connaissances Note de contrôle de continu Note projet Evaluation du projet la semaine du 17 novembre

Plus en détail

Conception, architecture et urbanisation des systèmes d information

Conception, architecture et urbanisation des systèmes d information Conception, architecture et urbanisation des systèmes d information S. Servigne Maître de Conférences, LIRIS, INSA-Lyon, F-69621 Villeurbanne Cedex e-mail: sylvie.servigne@insa-lyon.fr 1. Introduction

Plus en détail

Cours en ligne Développement Java pour le web

Cours en ligne Développement Java pour le web Cours en ligne Développement Java pour le web We TrainFrance info@wetrainfrance Programme général du cours Développement Java pour le web Module 1 - Programmation J2ee A) Bases de programmation Java Unité

Plus en détail

Chapitre I : Protocoles client serveur et architectures distribuées

Chapitre I : Protocoles client serveur et architectures distribuées Chapitre I : Protocoles client serveur et architectures distribuées Eric Leclercq & Marinette Savonnet Département IEM / UB Eric.Leclercq@u-bourgogne.fr Bureau G212 Aile des Sciences de l Ingénieur Mise-à-jour

Plus en détail

Urbanisation des SI. Des composants technologiques disponibles. Urbanisation des Systèmes d'information Henry Boccon Gibod 1

Urbanisation des SI. Des composants technologiques disponibles. Urbanisation des Systèmes d'information Henry Boccon Gibod 1 Urbanisation des SI Des composants technologiques disponibles Urbanisation des Systèmes d'information Henry Boccon Gibod 1 Plan de l'exposé Technologies à la mode disponibles. Bus de données, ETL et EAI

Plus en détail

Les formations. Développeur Logiciel. ENI Ecole Informatique

Les formations. Développeur Logiciel. ENI Ecole Informatique page 1/8 Titre professionnel : Inscrit au RNCP de Niveau III (Bac + 2) (J.O. du 19/02/13) 24 semaines + 8 semaines de stage (uniquement en formation continue) Développer une application orientée objet

Plus en détail

Java EE. Grégory Cuellar, Julien Goullon. 1 er octobre 2007. gregory.cuellar@bull.net. julien.goullon@9business.fr

Java EE. Grégory Cuellar, Julien Goullon. 1 er octobre 2007. gregory.cuellar@bull.net. julien.goullon@9business.fr Grégory Cuellar Julien Goullon gregory.cuellar@bull.net julien.goullon@9business.fr 1 er octobre 2007 1 Généralité 2 / 54 Pourquoi? Historique Les alternatives Les composants 2 Architecture n-tiers 3 JEE

Plus en détail

Mettez les évolutions technologiques au service de vos objectifs métier

Mettez les évolutions technologiques au service de vos objectifs métier Mettez les évolutions technologiques au service de vos objectifs métier 2 OXIA a pour mission de concevoir et mettre en oeuvre les meilleures solutions technologiques visant à améliorer la productivité,

Plus en détail

VisualAge Pacbase 3.0 et WebSphere

VisualAge Pacbase 3.0 et WebSphere VisualAge Pacbase 3.0 et WebSphere Conférence VisualAge Pacbase 13 décembre 2001 Fernand Bonaguidi Jean-François Lévi 1 La plateforme logicielle WebSphere Applications de s et de Partenaires Accélérateurs

Plus en détail

Patrons de Conception (Design Patterns)

Patrons de Conception (Design Patterns) Patrons de Conception (Design Patterns) Introduction 1 Motivation Il est difficile de développer des logiciels efficaces, robustes, extensibles et réutilisables Il est essentiel de comprendre les techniques

Plus en détail

e-business, EAI et Business Intelligence Le triptyque gagnant profondément les structures des organisations et par conséquence

e-business, EAI et Business Intelligence Le triptyque gagnant profondément les structures des organisations et par conséquence e-business, EAI et Business Intelligence Le triptyque gagnant Alain Fernandez Consultant indépendant, il intervient depuis plus de 15 ans auprès des grands comptes et des PME sur la conception des systèmes

Plus en détail

Refonte front-office / back-office - Architecture & Conception -

Refonte front-office / back-office - Architecture & Conception - Refonte front-office / back-office - Architecture & Conception - GLG204 - Architectures Logicielles Java 2008/2009 Nom : Cédric Poisson Matricule : 06-49012 Version : 1.0 Jeudi 28 mai 2009 1 / 23 Table

Plus en détail

Présentation générale des Web Services

Présentation générale des Web Services Présentation générale des Web Services Vue Globale Type d'architecture reposant sur les standards de l'internet Alternative aux architectures classiques : Client/serveur n/tiers Orientée services permettant

Plus en détail

24/11/2011. Cours EJB/J2EE Copyright Michel Buffa. Plan du cours. Programmer avec Java EE. Besoins des développeurs. Prérequis / Objectifs

24/11/2011. Cours EJB/J2EE Copyright Michel Buffa. Plan du cours. Programmer avec Java EE. Besoins des développeurs. Prérequis / Objectifs Plan du cours 2 Introduction générale EJB : les fondamentaux Programmer avec Java EE Introduction générale Michel Buffa (buffa@unice.fr), UNSA 2011, modifié par Richard Grin (version 1.0), avec emprunts

Plus en détail

NFP111 Systèmes et Applications Réparties

NFP111 Systèmes et Applications Réparties NFP111 Systèmes et Applications Réparties 1 de 34 NFP111 Systèmes et Applications Réparties Cours 7 - CORBA/Partie 1 Claude Duvallet Université du Havre UFR Sciences et Techniques 25 rue Philippe Lebon

Plus en détail

Cours de Génie Logiciel

Cours de Génie Logiciel Cours de Génie Logiciel Sciences-U Lyon MDE Model Driven Engineering http://www.rzo.free.fr Pierre PARREND 1 Mai 2005 Sommaire MDE : principe MDE et le génie logiciel MDE et UML MDE et les Design Patterns

Plus en détail

Qu'est-ce qu'un Web Service?

Qu'est-ce qu'un Web Service? WEB SERVICES Qu'est-ce qu'un Web Service? Un Web Service est un composant implémenté dans n'importe quel langage, déployé sur n'importe quelle plate-forme et enveloppé dans une couche de standards dérivés

Plus en détail

Mise en œuvre des serveurs d application

Mise en œuvre des serveurs d application Nancy-Université Mise en œuvre des serveurs d application UE 203d Master 1 IST-IE Printemps 2008 Master 1 IST-IE : Mise en œuvre des serveurs d application 1/54 Ces transparents, ainsi que les énoncés

Plus en détail

Buts de l intégration en informatique

Buts de l intégration en informatique Buts de l intégration en informatique Comment faire communiquer et intégrer vos applications hétérogènes dans votre entreprise interconnectée? Quels types d applications construisons-nous? Réaliser Créer

Plus en détail

Business Process Execution Language

Business Process Execution Language Business Process Execution Language Rapport du projet de systèmes distribués d information Markus Lindström 6 mai 2009 Motivation personnelle Le sujet que j ai retenu et présenté dans le cadre du cours

Plus en détail

Solutions Microsoft Identity and Access

Solutions Microsoft Identity and Access Solutions Microsoft Identity and Access 2 Solutions Microsoft Identity and Access Microsoft Identity and Access (IDA) permet aux entreprises d améliorer leur efficacité et leurs connexions internes et

Plus en détail

Nouvelles technologies pour l intégration : les ESB

Nouvelles technologies pour l intégration : les ESB 10, avenue de l Europe Parc Technologique du Canal 31520 Ramonville st Agne 05.61.28.56.20 05.61.28.56.00 www.ebmwebsourcing.com Nouvelles technologies pour l intégration : les ESB EBM Websourcing Sommaire

Plus en détail

Extension de passerelles OSGi pour les domaines de la distribution électrique: Modèles et outils

Extension de passerelles OSGi pour les domaines de la distribution électrique: Modèles et outils Extension de passerelles OSGi pour les domaines de la distribution électrique: Modèles et outils F. Baude, A. Bottaro, J.M. Brun, A. Chazalet, A. Constancin, D. Donsez; L. Gurgen, Ph. Lalanda, V. Legrand,

Plus en détail

Les serveurs applicatifs et les architectures Java

Les serveurs applicatifs et les architectures Java 03 Lucas Part 02 Page 179 Lundi, 20. août 2001 2:58 14 Chapitre 15 Les serveurs applicatifs et les architectures Java Nous avons vu jusqu ici, dans les chapitres précédents, que les utilisateurs accèdent

Plus en détail

Hébergement de sites Web

Hébergement de sites Web Hébergement de Solutions complètes et évolutives pour l hébergement de sites Web dynamiques et de services Web sécurisés. Fonctionnalités Serveur Web Apache hautes performances Apache 1. et.0 1 avec prise

Plus en détail

Architecture N-Tier. Ces données peuvent être saisies interactivement via l interface ou lues depuis un disque. Application

Architecture N-Tier. Ces données peuvent être saisies interactivement via l interface ou lues depuis un disque. Application Architecture Multi-Tier Traditionnellement une application informatique est un programme exécutable sur une machine qui représente la logique de traitement des données manipulées par l application. Ces

Plus en détail

Offre Supervision OF. mercredi 17 septembre 2014. Groupe CGI inc. CONFIDENTIEL

Offre Supervision OF. mercredi 17 septembre 2014. Groupe CGI inc. CONFIDENTIEL Offre Supervision OF mercredi 17 septembre 2014 Groupe CGI inc. CONFIDENTIEL Agenda 1 2 3 4 5 6 7 Pourquoi cette solution? Principes et enjeux de la solution Les modules & fonctionnalités Architecture

Plus en détail

La démarche SOA et l interopérabilité applicative

La démarche SOA et l interopérabilité applicative La démarche SOA et l interopérabilité applicative Retour d'expérience des projets RITA / PRESTO de la Direction Générale de la Modernisation de l'état Abdelaziz Skalli Consultant Tél : +33.630.78.54.75

Plus en détail

Fiche technique RDS 2012

Fiche technique RDS 2012 Le 20/11/2013 OBJECTIF VIRTUALISATION mathieuc@exakis.com EXAKIS NANTES Identification du document Titre Projet Date de création Date de modification Fiche technique RDS Objectif 02/04/2013 20/11/2013

Plus en détail

PLAN PROJET. Binôme ou monôme (B/M): M. : abdlhaqmilan@gmail.com GSM : 00212640108250. : Gestion d'une agence de location de voiture.

PLAN PROJET. Binôme ou monôme (B/M): M. : abdlhaqmilan@gmail.com GSM : 00212640108250. : Gestion d'une agence de location de voiture. Développement d une application JAVA EE PLAN PROJET Binôme ou monôme (B/M): M Nom & Prénom : AZRAGUE Abdelhaq Email : abdlhaqmilan@gmail.com GSM : 00212640108250 Organisme Scolaire : Gestion d'une agence

Plus en détail

de survie du chef de projet

de survie du chef de projet KIT de survie du chef de projet 01 1 2 3 4 5 6 04 03 07 07 03 03 LE SERVEUR LE CLIENT TECHNOLOGIE WEB CLIENT LE SERVEUR WEB TECHNIQUES & CADRE DE TRAVAIL APPLICATIONS 101 LE SERVEUR Un serveur informatique

Plus en détail

L Orchestration de Services Web avec Orchestra. Goulven Le Jeune Orchestra Project Manager

L Orchestration de Services Web avec Orchestra. Goulven Le Jeune Orchestra Project Manager L Orchestration de Services Web avec Orchestra Goulven Le Jeune Orchestra Project Manager D1 Bull, Architecte d un Monde Ouvert : contributeur et acteur majeur de l'open Source Applications métiers Infrastructures

Plus en détail

Sécurisation des architectures traditionnelles et des SOA

Sécurisation des architectures traditionnelles et des SOA Sécurisation des architectures traditionnelles et des SOA Un livre blanc de Bull Evidian Gestion SAML des accès SSO aux applications classiques et J2EE. Max Vallot Sommaire Émergence des architectures

Plus en détail

Figure 1-1. Plateformes compatibles avec WCF

Figure 1-1. Plateformes compatibles avec WCF 1 Bonjour Indigo Windows Communication Foundation (WCF), auparavant connu sous le nom de code «Indigo», est une nouvelle plateforme de messages distribués. Il fait partie du Framework.NET 3.0 livré avec

Plus en détail

Introduction aux applications réparties

Introduction aux applications réparties Introduction aux applications réparties Noël De Palma Projet SARDES INRIA Rhône-Alpes http://sardes.inrialpes.fr/~depalma Noel.depalma@inrialpes.fr Applications réparties Def : Application s exécutant

Plus en détail

Les cinq raisons majeures pour déployer SDN (Software-Defined Networks) et NFV (Network Functions Virtualization)

Les cinq raisons majeures pour déployer SDN (Software-Defined Networks) et NFV (Network Functions Virtualization) Les cinq raisons majeures pour déployer SDN (Software-Defined Networks) et NFV (Network Functions Virtualization) Préparé par : Zeus Kerravala Les cinq raisons majeures pour déployer SDN et NFV NetworkWorld,

Plus en détail

Business & High Technology

Business & High Technology UNIVERSITE DE TUNIS INSTITUT SUPERIEUR DE GESTION DE TUNIS Département : Informatique Business & High Technology Chapitre 3 : Progiciels de Gestion Intégrés Sommaire Définition... 2 ERP... 2 Objectifs

Plus en détail

Business & High Technology

Business & High Technology UNIVERSITE DE TUNIS INSTITUT SUPERIEUR DE GESTION DE TUNIS Département : Informatique Business & High Technology Chapitre 3 : Le web dans l entreprise Sommaire Introduction... 1 Intranet... 1 Extranet...

Plus en détail

BUSINESSOBJECTS EDGE PREMIUM

BUSINESSOBJECTS EDGE PREMIUM PRODUITS BUSINESSOBJECTS EDGE PREMIUM Avantages de la Business Intelligence Assurer une visibilité intégrale des activités Identifier de nouvelles opportunités Détecter et résoudre les problèmes Remplacer

Plus en détail

Wonderware ArchestrA Workflow

Wonderware ArchestrA Workflow ArchestrA Workflow www.wonderware.fr Introduction ArchestrA Workflow est une solution de BPM (Business Process Management) transverse et temps-réel de gestion des processus industriels. Décuplant la collaboration

Plus en détail

Objectifs. Maîtriser. Pratiquer

Objectifs. Maîtriser. Pratiquer 1 Bases de Données Objectifs Maîtriser les concepts d un SGBD relationnel Les modèles de représentations de données Les modèles de représentations de données La conception d une base de données Pratiquer

Plus en détail

Urbanisation des Systèmes d'information

Urbanisation des Systèmes d'information Urbanisation des Systèmes d'information Des composants technologiques disponibles Urbanisation des Systèmes d'information - Henry Boccon-Gibod 1 Plan de l'exposé Technologies à la mode disponibles. Bus

Plus en détail

Intégration de systèmes

Intégration de systèmes Intégration de systèmes Préparé par: Marc Barassi, Michel Fraser, Louis Martin, Martin Simoneau Collaboration spéciale: François Boucher et Richard Boutin 3/18/14 Intégration de systèmes «L ensemble des

Plus en détail

W4 - Workflow La base des applications agiles

W4 - Workflow La base des applications agiles W4 - Workflow La base des applications agiles, W4 philippe.betschart@w4global.com Vous avez dit «workflow»? Processus : Enchaînement ordonné de faits ou de phénomènes, répondant à un certain schéma et

Plus en détail

Workflow et Service Oriented Architecture (SOA)

Workflow et Service Oriented Architecture (SOA) White Paper Workflow et Service Oriented Architecture (SOA) Présentation Cet article offre une approche pragmatique de la SOA et du workflow à travers des problématiques d'entreprises, une méthodologie

Plus en détail

Introduction à Microsoft InfoPath 2010

Introduction à Microsoft InfoPath 2010 Introduction à Microsoft InfoPath 2010 Couplé à Microsoft SharePoint Designer 2010, InfoPath 2010 simplifie la création de solutions de bout en bout sur SharePoint Server 2010, qui contiennent des formulaires

Plus en détail