Facult´e des Sciences D´epartement d’Informatique
Gestion d’une plate-forme temps r´eel sur une architecture bas´ee sur
les ´ev`enements
Mohammed Jelti
Promoteur : M´emoire pr´esent´e en vue de
Prof. Esteban Zim´anyi l’obtention du grade de
Master en Sciences Informatiques
Ann´ee acad´emique 2009 - 2010
soutenu, pendant huit ans d’existence ici
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
Remerciements
Je tiens tout d’abord `a adresser mes plus sinc`eres remerciements `a M. Esteban Zim´anyi, directeur de ce m´emoire, ainsi qu’`a M. Sabri Skhiri directeur de recherche et de d´eveloppement d’Euranova, pour m’avoir suivi et pour m’avoir consacr´e autant de temps.
Je voudrais ´egalement remercier ici l’´equipe d’informatique d’Alcatel-Lucent `a Na- mur, et notamment M. Xavier Lerot qui m’a beaucoup aid´e durant ce travail et qui m’a prodigu´e de pr´ecieux conseils.
Je ne saurai oublier ici l’administration et tous les enseignants de l’ULB qui ont contribu´e `a ma formation universitaire et plus particuli`erement les membres du jury de ce m´emoire, messieurs Raymond Devillers et Jo¨el Goossens.
Je t´emoigne aussi toute ma reconnaissance amicale `a toute l’´equipe d’Euranova dont la disponibilit´e et la courtoisie ont ´et´e constantes `a mon ´egard.
Enfin, je remercie tous ceux qui ont contribu´e de pr`es ou de loin `a l’´elaboration de ce travail.
Table des mati` eres
1 Introduction 3
1.1 Contexte du probl`eme . . . 3
1.2 Objectif du m´emoire . . . 4
1.3 Organisation du m´emoire . . . 5
2 Architecture logicielle d’entreprises 6 2.1 Introduction . . . 6
2.2 La couche de pr´esentation . . . 7
2.3 La couche des processus m´etiers . . . 7
2.4 La couche d’int´egration . . . 9
2.5 La couche des services . . . 15
2.6 La couche des applications . . . 15
2.7 Cloud Computing . . . 21
3 Event Driven Architecture 26 3.1 Introduction . . . 26
3.2 Le concept . . . 27
3.3 Ses apports . . . 28
3.4 Le contexte . . . 28
3.5 Ses caract´eristiques . . . 28
3.6 Ses composants . . . 31
3.7 Son fonctionnement . . . 32
3.8 Choix d’une solution . . . 38
3.9 EDA vs SOA . . . 38
3.10 Impl´ementation . . . 40
v
4 Outils et technologies d’impl´ementation 47
4.1 MDA : Model Driven Architecture . . . 47
4.2 EMF : Eclipse Modeling Framework . . . 49
4.3 JET : Java Emitter Templates . . . 52
4.4 EPA : Eclipse Plugin Architecture . . . 54
4.5 JBoss Application Server . . . 58
4.6 Description des services avec WSDL . . . 60
4.7 JBoss Enterprise Service Bus . . . 61
4.8 JAIN Service Logic Execution Environnement . . . 63
5 Gestion de la plate-forme 65 5.1 Pr´esentation de la plate-forme . . . 65
5.2 Architecture de l’application de gestion de la plate-forme . . . 66
5.3 Fonctionnement de l’application de gestion de la plate-forme . . . 69
6 Proposition d’une solution d’int´egration 70 6.1 Les apports de la solution . . . 70
6.2 Description de la solution d’int´egration . . . 72
6.3 Impl´ementation de la solution d’int´egration . . . 75
6.4 G´en´eration automatique de la solution . . . 80
7 Conclusion 83 Bibliographie 84 A Rapport du stage en entreprise 88 A.1 Impl´ementation d’un Event Collector . . . 88
A.2 Impl´ementation d’un CEP . . . 94
A.3 Patterns d’impl´ementation pour une EDA . . . 95
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
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´etier
OMG Object Management Group OMS Objet M´etier Sp´ecifique
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
Introduction
1.1 Contexte du probl` eme
Les ´economistes s’accordent depuis quelques d´ecennies sur l’importance du progr`es technique en tant que facteur de la croissance ´economique. Les entreprises, premi`eres concern´ees, tˆachent d’optimiser le syst`eme informatique en vue d’am´eliorer les perfor- mances. Ainsi, les directeurs informatique se concentrent sur deux ´el´ements centraux au sein de l’entreprise : le flux de travail (Workflow) et le flux de donn´ees (Dataflow). Leur maˆıtrise reste le meilleur moyen d’am´eliorer l’efficacit´e de l’entreprise.
Tr`es souvent, les entreprises se tournent vers les experts en mati`ere d’architecture IT1 afin de concevoir et de coordonner le flux de donn´ees. Ce dernier reste difficile- ment g´erable sachant que de nouvelles applications sont rajout´ees au fur et `a mesure du d´eveloppement du syst`eme informatique de l’entreprise. Ceci implique une interven- tion continue de la part des experts, ce qui oblige les entreprises `a s’orienter vers des architectures inter-applications ´evolutives capables de g´erer l’´echange de donn´ees entre applications. Plusieurs solutions propri´etaires pour ce type d’architecture sont propos´ees par les fournisseurs IT. Toutefois, d’autres solutions open-source et utilisant des proto- coles standards ont vu le jour ces derni`eres ann´ees.
De mani`ere g´en´erale, le syst`eme informatique de l’entreprise doit pas r´esister aux changements applicatifs. L’introduction d’une nouvelle application doit se faire sans modifier le reste du syst`eme. Seuls le flux entrant et le flux sortant de la nouvelle application doivent ˆetre disctut´es avec le fournisseur ou le d´eveloppeur. Malheureu- sement `a l’heure actuelle, beaucoup d’entreprises sont loin d’avoir des syst`emes infor- matiques aussi flexibles. N´eanmoins, les fournisseurs IT restent tr`es vigilants quant aux diff´erentes possibilit´es d’int´egration de leurs applications. Il va sans dire que les entre- prises privil´egient les applications faciles `a int´egrer, celles-ci ´evitent beaucoup de frais de d´eveloppement et de temps de perdu.
Du point de vue conceptuel, lorsque l’on veut construire un syst`eme informatique flexible, le premier point auquel on pense est la r´eutilisabilit´e. Souvent les applications ont des besoins communs qui peuvent ˆetre trait´es par un mˆeme composant. Cela facilite l’´evolution de ce dernier tout en ´evitant la redondance. Ce principe est un des fondements de l’architecture orient´ee services ou Service Oriented Architecture (SOA) dans laquelle
1. Information Technology
3
des composants dits “Services” peuvent ˆetre invoqu´es de mani`ere synchrone par les diff´erents composants du syst`eme informatique. Remarquons que grˆace `a la mont´ee en puissance des technologies web, notamment le langage XML et le protocole HTTP, ce type d’architecture a eu beaucoup de succ`es aupr`es des entreprises ces derni`eres ann´ees.
Parall`element `a cela, un deuxi`eme fondement sur lequel repose ce type d’architecture et qui est le d´ecouplage lˆache ne semble plus tenir [12] . En effet, les applications dans une telle architecture ne sont pas compl`etement ind´ependantes vu qu’elles s’adressent directement aux services expos´es en solicitant une r´eponse imm´ediate `a leurs requˆetes.
Or, ceci limite l’autonomie des applications et fausse l’id´ee de d´ecouplage lˆache que prˆone SOA. Cela ´etant, l’utilisation de SOA reste toujours conseill´ee dans l’impl´ementation des processus m´etiers (chaˆınes d’actions) ou lorsque les requˆetes n´ecessitent une r´eponse imm´ediate ( ex : transactions, etc).
Event Driven Architecture (EDA) ou architecture bas´ee sur les ´ev`enements vient renforcer la r´eduction du couplage entre les composants grˆace notamment au caract`ere asynchrone des requˆetes. Les composants communiquent via des ´ev`enements qui sont r´ecolt´es et centralis´es par une seule entit´e. Cette derni`ere s’occupe ´egalement de leur transmission aux applications interess´ees. Concr`etement, ce type d’architecture vise `a r´ecolter les ´ev`enements pour savoir l’´etat actuel du syst`eme et pouvoir y r´eagir.
1.2 Objectif du m´ emoire
Comme expliqu´e auparavant, l’int´egration d’une application au sein d’un syst`eme informatique d´ej`a d´evelopp´e peut coˆuter tr`es cher `a l’entreprise. Nous entendons par le terme “Int´egration”, le fait d’exposer les nouvelles fonctionnalit´es de l’application au reste du syst`eme informatique et vice versa. En effet, les applications du S.I2 doivent pouvoir faire appel `a ces fonctions, soit directement, soit en passant par un interm´edaire qui joue le rˆole de “convertisseur” de donn´ees. L’entreprise int´eress´ee par cette m´ethode d’int´egration peut demander l’intervention de techniciens qualifi´es qui s’occupent de la mise en place de liens (one-to-one) entre l’application et le reste du syst`eme. Rappelons qu’outre les d´epenses, cette proc´edure g´en`ere un ensemble d’interfaces inter-applicatives qui empˆechera les applications concern´ees d’´evoluer vu leurs d´ependances directes au reste du syst`eme. Ce probl`eme est connu sous le nom de “l’effet spaghetti”.
Dans ce m´emoire, nous allons nous concentrer sur une application de gestion de plate-forme temps r´eel qui doit ˆetre int´egr´ee dans le S.I d’un op´erateur lambda. Nous proposerons une nouvelle approche pour faciliter cette tˆache et offrir un ensemble le plus flexible possible.
Evidemment, l’application en question dispose d’une couche applicative qui expose ses fonctionnalit´es et accepte les liens one-to-one mais le but de ce travail est de proposer une mani`ere intelligente d’acc´eder `a ces “Services” tout en limitant les d´ependances et en offrant plus de souplesse et de flexibilit´e. Clairement, nous allons proposer une solution orient´ee ´ev`enements permettant `a cette application de s’ins´erer dans une architecture bas´ee sur les ´ev`enements. Ainsi, n’importe quelle application du S.I pourra faire appel
`
a ces fonctionnalit´es via des ´ev`enements.
2. Syst`eme d’information
Pour illustrer le fonctionnement souhait´e, rien de mieux qu’un exemple concret : Un ´ev`enement A, qui repr´esente une demande de cr´eation d’un nouveau compte pour un client, se d´eclenche dans l’application X du S.I. Il est aval´e par l’entit´e centrale qui collecte les ´ev`enements et transmis `a l’application de gestion, dont il est sujet ici, pour ˆ
etre trait´e. Ce mˆeme ´ev`enement A pourra ˆetre transmis `a toutes les applications inter- ess´ees pourvu qu’elles soient inscrites au niveau de l’entit´e centrale (publish/subscribe).
Cette derni`ere joue un rˆole semblable `a celui du routeur r´eseau mais veille en plus `a la transformation des donn´ees des ´ev`enements afin qu’elles soient manipulables par les diff´erentes applications.
L’exemple ci-dessus explique le fonctionnement souhait´e de l’application dans une architecture bas´ee sur les ´ev`enements. Malheureusement, beaucoup d’op´erateurs ne dis- posent pas encore de ce genre d’architecture. En annexe de ce m´emoire se trouve un guide d’impl´ementation d’architecture bas´ee sur les ´ev`enements `a partir d’outils open-source et respectant les standards actuels.
Notre but ultime est de montrer les avantages d’une architecture bas´ee sur les
´
ev`enement et tout ce qu’elle peut apporter `a l’entreprise.
1.3 Organisation du m´ emoire
Ce m´emoire commencera par une ´etude compl`ete de l’architecture IT des entreprises.
Nous verrons l’ensemble des composants du syst`eme informatique ainsi que les diff´erentes technologies d’int´egration : Enterprise Application Integration (EAI), Enterprise Service Bus (ESB), etc. Nous discuterons le rˆole central de l’ESB dans l’int´egration d’applica- tions d’entreprise et comment l’architecture SOA peut-elle ˆetre impl´ement´ee `a travers l’EDA.
Le troisi`eme chapitre est consacr´e `a l’EDA. Nous verrons ses caract´eristiques en d´etail ainsi que les diff´erents ´el´ements qui la composent.
Ensuite, le quatri`eme chapitre abordera l’ensemble des outils et des technologies d’impl´ementation qui sont utilis´ees dans la conception de l’application de gestion de la plate-forme temps r´eel (Eclipse Modeling Framework (EMF), Java Emitter Templates (JET), JBoss, Enterprise JavaBean (EJB), etc).
Le dernier chapitre pr´esentera l’architecture de l’application ainsi que l’impl´ementation d´etaill´ee de la solution. Rappelons que cette solution vise l’int´egration “intelligente” de cette application dans une architecture bas´ee sur les ´ev`enements(EDA).
Enfin, ce m´emoire se terminera par une conclusion qui reprendra les apports et les r´esultats de ce travail.
Architecture logicielle d’entreprises
2.1 Introduction
Aujourd’hui, les entreprises s’orientent vers l’int´egration des applications avec comme objectif de permettre la communication entre toutes les applications qu’elles soient d´evelopp´ees en interne ou en externe. Parall`element `a cela, on remarque une tendance des entreprises `a aller vers des solutions logicielles orient´ees services. On constate aussi le fort accroissement de l’utilisation des processus m´etier par les dirigeants IT.
Dans ce chapitre, nous allons montrer les changements impliqu´es par l’introduction des processus m´etiers au niveau de l’architecture IT. Nous verrons comment l’ensemble des couches applicatives s’adapte pour b´en´eficier des apports de l’architecture orient´ee services et surtout comment r´econcilier les processus m´etier, la SOA et l’int´egration des applications. La figure suivante illustre les diff´erentes couches applicatives qui seront d´ecortiqu´ees dans la suite.
Figure2.1 – Couches applicatives
6
2.2 La couche de pr´ esentation
La couche de pr´esentation utilise les op´erations des couches inf´erieures pour accom- plir les fonctionnalit´es demand´ees par les utilisateurs au travers des interfaces Homme- Machine. Il est important de bien s´eparer les composants de cette couche des autres composants afin d’´eviter de dupliquer du code et d’am´eliorer l’ind´ependance entre les couches.
Le portail (figure 2.1) va permettre aux utilisateurs d’avoir un point d’acc`es unique pour acc´eder aux composants et aux ressources de la couche de pr´esentation.
2.3 La couche des processus m´ etiers
Aujourd’hui, les processus m´etiers 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´eliorer la productivit´e de l’entreprise et faire face aux exi- gences des clients. On appelle processus m´etier ou processus op´erationnel un ensemble de fonctions m´etiers qui m`enent `a un r´esultat tangible. On peut prendre pour exemple le processus m´etier “vente de produits sur internet” qui peut ˆetre d´ecortiqu´e en plu- sieurs ´etapes ou sous-processus m´etier : parcourir les produits, choix d’un ou plusieurs produits, commande et r´eception du produit par le client.
Figure 2.2 – processus m´etier : vente de produits sur internet
Naturellement, l’architecture IT de l’entreprise se doit d’offrir de nouvelles fonction- nalit´es pour l’int´egration et la gestion r´eguli`ere de ces processus. Pour ce faire, une
nouvelle couche est introduite dans le mod`ele informatique traditionnel. Il s’agit de la couche des processus m´etier ou Business Process Layer (BPL).
Cette couche se trouve entre la couche pr´esentation et la couche d’int´egration et contient :
1. Les mod`eles des processus m´etier.
2. Les r`egles associ´ees aux mod`eles.
3. L’ordonnancement des processus.
4. Les donn´ees n´ecessaires pour la transformation des donn´ees.
Elle doit assurer :
– L’int´egration des donn´ees provenant de tous les composants.
– Le transport des donn´ees entre applications.
– Gestion des processus m´etier grˆace au Business Process Management (BPM).
A ce niveau, chaque processus m´etier d´efinit les services m´etier qu’il va utiliser et qui vont ˆetre orchestr´es par le BPM.
2.3.1 BPM : Business Process Management
Comme expliqu´e auparavant, les processus m´etier permettent de formaliser le savoir- faire de l’entreprise et s’alignent sur le concept de SOA. Cependant, l’entreprise doit avoir les outils et les m´ethodes pour g´erer ses processus m´etier. C’est le rˆole du BPM.
Le BPM permet d’avoir une vue globale sur l’ensemble des processus m´etier et offre la possibilit´e de s’adapter `a de nouvelles situations.
Une Solution BPM est compos´ee de plusieurs ´el´ements :
– Un outil de mod´elisation qui permet de d´ecrire les proc´edures de production en processus (voir l’exemple de vente de produits sur internet : figure 2.2)
– Des outils d’aide `a l’impl´ementation.
– Un moteur d’ex´ecution de processus.
– Des outils d’administration pour param´etrer l’ensemble des processus et analyser les donn´ees collect´ees apr`es l’ex´ecution des processus. Parmi ces outils, on peut trouver le Business Activity Management (BAM) qui permet de suivre l’activit´e d’un processus m´etier.
L’adoption d’une telle solution doit passer par plusieurs ´etapes : 1. Etude de l’entreprise afin de d´eterminer les processus m´etier.
2. Mod´elisation des processus m´etiers.
3. Impl´ementation de la solution 4. Ex´ecution
5. Pilotage : analyser l’´etat des processus ainsi que leurs performances.
6. Optimisation : am´elioration des performances des processus m´etiers.
Le BPM offre aux entreprises la possibilit´e de g´erer le cycle de vie complet de leurs processus m´etiers : identification, mod´elisation, impl´ementation, ex´ecution, analyse et optimisation des processus m´etier. Ceci am´eliore les performances et rend le syst`eme et les processus m´etier adaptables aux changements potentiels.
2.3.2 BAM : Business Activity Monitoring
De son cˆot´e, le BAM a pour objectif de s’adresser sp´ecifiquement au responsable m´etier plutˆot que technique. Pour cela, le BAM va s’appuyer sur le Service Activity Monitoring (SAM) pour r´ecolter des informations sur l’´etat de fonctionnement des pro- cessus.
Les informations collect´ees seront pr´esent´ees aux utilisateurs au travers de la console de supervision BAM.
2.3.3 SAM : Service Activity Monitoring
Le SAM permet de contrˆoler et de mesurer les performances techniques de la plate- forme et des services d´eploy´es.
2.4 La couche d’int´ egration
Deux technologies sont principalement utilis´ees pour l’int´egration des applications au sein des entreprises :
2.4.1 EAI pour Enterprise Application Integration
“L’Int´egration d’applications d’entreprise ou en anglais Enterprise Applica- tion Integration, est une architecture intergicielle permettant `a des applica- tions h´et´erog`enes de g´erer leurs ´echanges”
IBM.fr Le syst`eme informatique des entreprises est constitu´e de plusieurs applications qui communiquent entre elles grˆace `a des passerelles ou des interfaces dont le temps de r´ealisation peut ˆetre assez important. L’id´ee de base de l’EAI est de cr´eer un concentra- teur qui re¸coit le flux de donn´ee de sortie de chaque application, le traite et le redistribue aux applications int´eress´ees. Ainsi, l’ajout de nouvelles applications s’effectue avec plus de rapidit´e et consiste `a modifier simplement le point d’entr´ee et de sortie de cette derni`ere afin de la brancher sur le concentrateur. Elle pourra, d´es lors, b´en´eficier du flux de donn´ees provenant d’autres composants du syst`eme.
Dans cette architecture (figure 2.3), les applications peuvent fonctionner ind´ependamment les unes des autres grˆace aux ´el´ements suivants :
– Les connecteurs: Ce sont les interfaces entre l’EAI et les applications. Ils s’oc- cupent de la transmission de donn´ees entre l’EAI et les applications.
– Objet M´etier Sp´ecifique (OMS) : ou en anglais Application Specific Business Objects. Ce sont les donn´ees qui transitent entre l’EAI et les applications
– Objet M´etier (OM) : Objet de m´etier standard, les connecteurs transforment les OMS en OM (mod`ele de donn´ee global) avant d’ˆetre trait´es.
– Protocoles au niveau de la couche de transport (comme HyperText Transfer Protocol (HTTP))
Figure 2.3 – Entreprise Application Integration
Il existe deux types d’architecture de base pour l’int´egration d’applications d’entre- prise :
Architecture Hub and spoke
Cette architecture est constitu´ee d’un point de connexion central et d’un ensemble d’adaptateurs qui permettent de connecter l’ensemble des applications (r´eseau en ´etoile).
Les adaptateurs re¸coivent les messages d’informations et les transmettent au syst`eme de messagerie qui s’occupe de la transformation, traduction et routage de l’information vers les modules int´eress´es. Il est ´evident qu’avoir un point central rend l’architecture facile `a g´erer mais constitue un handicap au niveau de l’extension (lorsque le nombre limite d’op´erations est atteint au niveau du concentrateur). Dans ce cas, on peut tr`es bien imaginer une architecture bas´ee sur plusieurs Hub et dont les r`egles peuvent ˆetre d´efinies de mani`ere globale et propag´ees sur l’ensemble des concentrateurs.
Architecture bas´ee sur un Bus
Dans cette architecture, les messages publi´es par les adaptateurs transitent via un Backbone (bus) et sont transmis aux applications inscrites sur le bus. Chaque application est dot´ee d’adaptateurs qui s’occupent de la transformation de ses messages dans le bon format. Cette architecture r`egle le probl`eme d’extension car la charge du syst`eme est r´epartie sur l’ensemble des noeuds (point de connexion `a une application), ce qui est cens´e offrir de meilleures performances.
Les solutions EAI propos´ees aux entreprises utilisent des protocoles et des interfaces propri´etaires qui ne sont pas en principe compatibles avec ceux d’autres fournisseurs de solutions EAI, ce point essentiel limite l’interop´erabilit´e entre les entreprises qui utilisent des solutions EAI diff´erentes. L’ESB solutionne ce probl`eme en s’appuyant sur
Figure2.4 – Illustration de l’Architecture Hub and spoke
Figure2.5 – Illustration de l’Architecture Bus
des standards comme le langage eXtensible Markup Language (XML) et la norme Web Service (WS).
2.4.2 ESB pour Enterprise Service Bus
L’ESB est une plate-forme d’int´egration qui met en application la notion de SOA. La notion de SOA est un mod`ele architectural qui a pour principe d’augmenter l’efficacit´e, l’agilit´e et la productivit´e d’une entreprise en pla¸cant la notion de services comme le moyen principal pour atteindre les objectifs strat´egiques [12].
Dans la terminologie SOA [12], on distingue diff´erents type de services :
– Les Services Create, Read, Update, Delete (CRUD) permettent de cr´eer, rechercher, mettre `a jour ou supprimer des donn´ees dans des r´ef´erentiels (base de donn´ees, annuaire, fichier, etc).
– Les Services Techniques donnent acc`es `a une ressource technique telle que : une base de donn´ees relationnelle, une imprimante, un syst`eme de trace d’infor- mation, un progiciel de type Enterprise Resource Planning (ERP), un serveur de messagerie, etc.
– Les Services Applicatifs sont des services de haut niveau (´egalement appel´es
Figure2.6 – Enterprise Service Bus
services de fa¸cade) 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´etiers qui encapsulent la logique et les r`egles m´etiers des processus.
Ce sont les services fonctionnels qui sont d´eploy´es au niveau de l’ESB, grˆace notam- ment `a Service Component Architecture (SCA) qui est un ensemble de sp´ecifications visant `a simplifier la cr´eation et la composition de services (ind´ependamment de leur impl´ementation) dans le cadre de SOA.
Pour revenir `a l’ESB, il s’agit d’un bus repr´esentant le backbone et qui est responsable de la transformation, du formatage et du routage des diff´erents messages envoy´es par les diff´erents services et applications reli´es `a l’ESB. Les avantages de cette architecture par rapport `a l’architecture Bus de l’EAI pr´esent´ee ci-dessus sont :
1. Le fait que les connecteurs utilisent des technologies standards comme Java Mes- saging Service (JMS), File Transfer Protocol (FTP), HTTP, Web service, etc.
2. Le routage intelligent,
3. Le coˆut d’impl´ementation est moins ´elev´e que dans le cas d’un bus propri´etaire, 4. l’ESB n’utilise pas des formats propri´etaire contrairement aux solutions EAI.
Le routage intelligent se base sur le contenu du message afin d’acheminer les donn´ees (le concept de Content Based Routing (CBR) , Ainsi l’ESB d´eduit le destinataire du message en fonction de son contenu et des r`egles pr´ed´efinies. Chaque r`egle contient une condition ainsi que la r´ef´erence du destinataire au cas o`u le message v´erifie la condition de la r`egle.
En r´esum´e, l’ESB permet de composer les services fonctionnels afin d’assurer l’int´egration des donn´ees comme expliqu´e ci-dessus. L’information re¸cue par les connecteurs suit
une certaine logique d’int´egration (transformation, formatage, etc) avant d’arriver au syst`eme de messagerie, ce qui la rend ind´ependante de l’aspect propri´etaire.
Les connecteurs
Les connecteurs ou gateways repr´esentent les points d’entr´es de l’ESB, leur rˆole est de d´eplacer l’information de l’ext´erieur vers l’int´erieur de l’ESB tout en l’adaptant pour qu’elle soit manipulable par les composants internes. `A nouveau, pour garder cette id´ee de souplesse, chaque connecteur doit traiter un seul type de message afin de lui apporter les transformations n´ecessaires. Ceci permet de sp´ecialiser chaque connecteur en lui associant un type de message pr´ecis.
Lorsqu’on dispose d’un ensemble d’applications non homog`enes, il pourrait ˆetre int´eressant d’offrir un ensemble de type connecteurs vari´e et utilisant des technolo- gies diff´erentes pour faciliter la connection des applications. On constate aujourd’hui le d´eveloppement de nouveaux types de connecteurs. On y trouve des connecteurs de type HTTP, JMS, Simple Object Access Protocol (SOAP), Simple Mail Trans- fer 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’´echange de messages asynchrones entre applica- tions et garantit la livraison des messages (que le destinataire pr´einscrit soit disponible ou non, les messages seront mis en attente de r´eception). Il peut aussi assurer la per- sistance des messages qu’il re¸coit, 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´e pr´ec´edemment, l’´emetteur et le r´ecepteur ne doivent pas ˆetre disponibles en mˆeme temps, l’´emetteur interagit avec le serveur de messagerie au cours d’une transaction locale et ignore si les parties int´eress´ees par son message sont disponibles au moment de la transaction.
Certaines impl´ementations du MOM pr´evoient mˆeme un mod`ele de regroupement de transactions en une seule appel´e le mode all-or-nothing.
Dans ce mode, l’´emetteur peut ´echanger plusieurs messages avec le serveur de mes- sagerie sans que ce dernier n’en fasse part aux parties int´eress´ees. Seul l’envoi de la commande “commit” de la part de l’´emetteur rend l’information disponible aux modules int´eress´es (ce principe est tr`es semblable `a celui des base de donn´ees). De mˆeme, la com- mande rollBack permet l’annulation de la transaction. Dans certaines impl´ementations, le MOM fournit des interfaces pour la manipulation des ressources pendant une tran- saction.
Un message est compos´e de trois parties : un header, des propri´et´es, et un corps.
– Le headerrenseigne sur la source du message, la destination de la r´eponse si celle ci est exig´ee par l’´emetteur, type de message, etc.
– Les propri´et´essont repr´esent´ees par des paires (nom,valeur) et sont v´erifi´ees par les filtres de consommateur ou des routeurs sp´ecialis´es.
Figure 2.7 – La relation Publish and Subscribe
Il est important de savoir que chaque entit´e communicante joue le rˆole de producteur et de consommateur de messages. Les producteurs et les consommateurs sont dits “loo- sely coupled”. Cela veut dire qu’ils ne sont pas directement li´es, mais qu’ils sont reli´es de fa¸con abstraite via des canaux virtuels appel´es les canaux publish-and-subscribe ou
`
a travers des canaux point-to-point. Le producteur de messages n’a pas besoin de savoir qui va recevoir les messages, de mˆeme, le consommateur est compl`etement ind´ependant du producteur des messages. Toutefois, si le producteur du message veut exiger une r´eponse de la part du consommateur, il doit inclure l’adresse de r´eponse dans l’entˆete du message.
La relation publish-and-subscribe est une relation one-to-many. Cela ´etant, les consom- mateurs doivent s’inscrire pour un topic (Sujet) dans lequel le producteur va faire des publications. Ainsi chaque consommateur inscrit pour un topic re¸coit les messages qui concernent ce dernier. Le deuxi`eme type de relation, `a savoir la relation point-to-point, est une relation one-to-one o`u les messages du producteur sont stock´es dans une queue en attendant d’ˆetre consomm´e par un seul consommateur.
Notons que le choix du mod`ele d’´echange (publish-and-subscribe ou point-to-point) d´epend du nombre de consommateurs potentiels.
Les conteneurs de services d’int´egration
Le conteneur de services est l’´el´ement qui va se charger d’h´eberger et de composer les services d’int´egration.
L’utilisation de conteneurs de services simples et l´egers permet de r´ealiser une int´egration compl`etement distribu´ee. Ces conteneurs peuvent h´eberger 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´ecurit´e impl´ementant les standards WS-Security,
– 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´ecanique pour tracer des informations, – etc.
La diff´erence entre les conteneurs de services d’int´egration de l’ESB et les conteneurs de services d’application comme (le JBoss Application Server (AS) par exemple) est que ces derniers h´ebergent des fonctions m´etier et des pages web tant dis que les conteneurs de services d’int´egration de l’ESB h´ebergent les services d’int´egration et proc`edent `a l’int´egration des flux de donn´ees. Cela veut dire que les donn´ees vont suivre un certain parcours `a l’int´erieur de l’ESB et que leur pr´esentation va ˆetre adapt´ee pour qu’elle soit compatible avec le service qui va les utiliser.
2.5 La couche des services
Cette couche regroupe l’ensemble des ´el´ements requis pour mod´eliser, construire, tester et d´eployer les services. Ici, nous allons nous int´eresser `a deux types de services : les services d’int´egration et les services CRUD. Ces derniers sont accessibles au syst`eme op´erationnel de l’entreprise (applications traditionnelles, composants, base de donn´ees, etc) comme c’est le cas des servies m´etiers se trouvant au niveau de la couche des processus m´etier.
L’avantage majeur d’un service CRUD est sa r´eutilisabilit´e vu qu’il peut, notamment grˆace aux interfaces SOAP, recevoir des requˆetes `a partir de n’importe quelle application, pourvu qu’elle respecte ses param`etres. Remarquons qu’un service peut ˆetre construit par composition d’autres services, de mˆeme que la composition de services peut faire intervenir des services distribu´es. Enfin, les param`etres d’un service sont souvent d´ecrit au travers un fichier Web Services Description Language (WSDL) (connu grˆace aux Web Services).
2.6 La couche des applications
Dans cette partie, nous allons nous int´eresser `a certaines m´ethodes logicielles deve- nues aujourd’hui incontournables au sein des entreprises. Nous montrerons comment on con¸coit les applications Java orient´ees entreprise, notamment en utilisant des mod`eles de conception appel´es commun´ement Design patterns. Ces derniers ne sont pas li´es `a un langage de programmation et peuvent ˆetre impl´ement´es sous diff´erentes formes.
Les applications Java Enterprise d´ependent principalement de deux ´el´ements qui seront pr´esent´ees dans les sections suivantes :
– L’infrastructure d’ex´ecution offerte par JEE (section 2.6.2).
– La puissance de la programmation bas´ee sur les ´ev`enements (section 2.6.3).
2.6.1 Utilisation des design Patterns en Java
Le travail du concepteur de programmes a toujours ´et´e consist´e en deux choses : analyser et d´evelopper des applications afin de r´epondre aux besoins des utilisateurs.
Souvent, les programmeurs ne disposant d’aucune exp´erience essaient de mettre en pra- tique la th´eorie apprise `a l’´ecole et ainsi construire petit `a petit leurs applications en pensant toujours `a la premiere version finalis´ee de l’application. Seulement, l’application ne reste jamais `a sa premi`ere version et des dizaines de modifications doivent ˆetre ap- port´ees par la suite. Des modification mineures du code peuvent engendrer ´enorm´ement de bugs et d’anomalies de fonctionnement dans ce genre d’applications. Le concepteur finit par ˆetre satur´e par la complexit´e du codage (effet spaghetti). J’en veux pour preuve ma propre exp´erience sur une application Java d’environ 20000 lignes de code. Sans ar- chitecture de base, cette application est devenue progressivement ing´erable avec pour cons´equence l’´emergence de bugs de plus en plus difficiles `a corriger (effet dominos).
Pour recadrer les choses, il faut dire qu’une application doit toujours pouvoir ´evoluer.
Le code de l’application doit ˆetre ferm´e aux modifications et ouvert `a l’´evolution. Pour ce faire, des mod`eles de conceptions ont ´et´e d´efinis afin de permettre au programmeur de concevoir des applications flexibles et qui peuvent faire face aux changements.
Les design patterns ou mod`eles de conception d´ecrivent des organisations pratiques des classes d’objet. Ces organisations r´esultent souvent d’une conception empirique, le concepteur objet tente de faciliter la r´eutilisation et la maintenance du code. On peut donc concevoir un mod`ele d’application comme une forme d’organisation transpo- sable `a plusieurs applications. Ces syst`emes peuvent apparaˆıtre compl`exes aux d´ebutants voire inutiles, il est pourtant tr`es important d’en connaˆıtre plusieurs et de les appliquer syst´ematiquement (dans les cas reconnus comme pouvant ´evoluer). L’architecte objet se construit petit `a petit un “panier” de mod`eles.
Les design patterns ne sont pas r´eellement normalis´es, mais on peut les d´ecouper en trois grandes cat´egories :
– Les mod`eles de cr´eation : Ces mod`eles sont tr`es courants pour d´el´eguer `a d’autres classes la construction des objets. ex : le pattern Factory, le pattern Facade.
– Les mod`eles de structure : Ces mod`eles de conception tentent de composer des classes pour bˆatir de nouvelles structures. ex : le pattern Adapter, le pattern Proxy.
– Les mod`eles de comportement: Ces mod`eles tentent de r´epartir les responsa- bilit´es entre chaque classe (l’usage est plutˆot dynamique). ex : Template, Iterator.
Si on voulait faire un parall`ele avec UML, les deux premiers mod`eles seraient li´es
`
a des diagrammes statiques (de classes) alors que le dernier mod`ele est davantage li´e `a un diagramme dynamique (de s´equence).
2.6.2 Infrastructure d’ex´ecution offerte par JEE
Java Enterprise Edition (JEE) est une norme propos´ee par la soci´et´e Sun, port´ee par un consortium de soci´et´es internationales, visant `a d´efinir un standard de d´eveloppement d’applications d’entreprises multi-niveaux, bas´ees sur des composants.
On parle g´en´eralement de “plate-forme JEE” pour d´esigner l’ensemble constitu´e des services-Application Programming Interface (API) offerts et de l’infrastructure d’ex´ecution.
JEE comprend notamment :
– Les sp´ecifications du serveur d’application , c’est-`a-dire de l’environnement d’ex´ecution : JEE d´efinit finement les rˆoles et les interfaces pour les applications
ainsi que l’environnement dans lequel elles seront ex´ecut´ees. Ces recommandations permettent ainsi `a des entreprises tierces de d´evelopper des serveurs d’application conformes aux sp´ecifications ainsi d´efinies, sans avoir `a red´evelopper les principaux services.
– Des services, au travers d’API, c’est-`a-dire des extensions Java ind´ependantes permettant d’offrir en standard un certain nombre de fonctionnalit´es. Sun fournit une impl´ementation minimale de ces API appel´ee JEE Software Development Kit (SDK) . Dans la mesure o`u JEE s’appuie enti`erement sur le Java, il b´en´eficie des avantages de ce langage, en particulier une bonne portabilit´e et une maintenabilit´e du code.
De plus, l’architecture JEE repose sur des composants distincts, interchangeables et distribu´es, ce qui signifie notamment :
– qu’il est simple d’´etendre l’architecture ;
– qu’un syst`eme reposant sur JEE peut poss´eder des m´ecanismes de haute-disponibilit´e, afin de garantir une bonne qualit´e de service ;
– que la maintenabilit´e des applications est facilit´ee.
Les API de JEE
Les API de JEE peuvent se r´epartir en trois grandes cat´egories :
– 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´ee de l’interface avec l’utilisateur (on parle de logique de pr´esentation).
Figure 2.8 – Architecture d’une application Java entreprise
– Les composants m´etier : EJB. Il s’agit de composants sp´ecifiques charg´es des traitements des donn´ees propres `a un secteur d’activit´e (on parle de logique m´etier ou de logique applicative) et de l’interfa¸cage avec les bases de donn´ees.
Les services, pouvent ˆetre class´es par cat´egories :
Les services d’infrastructures :il en existe un grand nombre, d´efinis ci-dessous : – JDBC est une API d’acc`es aux bases de donn´ees relationnelles.
– Java Naming and Directory Interface (JNDI) est une API d’acc`es 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´efinissant des interfaces standard avec un gestionnaire de transactions.
– JCA est une API de connexion au syst`eme d’information de l’entreprise, notam- ment aux syst`emes dits “Legacy” tels que les ERP.
– Java Management Extension (JMX) fournit des extensions permettant de d´evelopper 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`es.
– JavaMail est une API permettant l’envoi de courrier ´electronique.
– JMS fournit des fonctionnalit´es de communication asynchrone (appel´ees 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´eparer les couches suivantes :
– La couche de pr´esentation, correspondant `a l’Interface Homme-machine (IHM).
– La couche m´etier contenant l’essentiel des traitements de donn´ees. Cette couche se base dans la mesure du possible sur des API existantes.
– La couche de donn´ees, correspondant aux informations de l’entreprise stock´ees dans des bases de donn´ees relationnelles ou dans des syst`emes d’information com- plexes.
2.6.3 Java et la programmation bas´ee sur les ´ev`enements
Dans les applications Java, les ´ev`enements repr´esentent une information centrale autour de laquelle, des mod`eles ont ´et´e d´evelopp´es pour en assurer la gestion et le traitement. L’id´ee de base ´etant de s´eparer les composants et de leur permettre de communiquer entre eux via des ´ev`enements. Ainsi, on peut distinguer les ´emetteurs d’´ev`enements et les r´ecepteurs d’´ev`enements. Un composant X peut s’inscrire chez un composant comme ´etant int´eress´e par un ´ev`enement alpha. Lorsque l’´ev`enement alpha se d´eclenche au niveau du composant Y, le composant X re¸coit imm´ediatement une information d´ecrivant l’´ev`enement en question.
En Java, un ´ev`enement est un “message”, c’est-`a-dire un objet qui transite d’un
´
emetteur `a un r´ecepteur. La g´en´eralisation des r´ef´erences Java nous permet de faire in- terpr´eter ce que veut dire “transiter” : L’´ev`enement est un objet construit par l’´emetteur, et dont la r´ef´erence est donn´ee de proche en proche jusqu’au r´ecepteur. Un ´ev`enement Java est donc un objet. Une bonne compr´ehension de :
– La notion d’´ev`enements ;
– De leur nature ;
– De leur niveau d’abstraction ; – Des styles de traitement ; – De la qualit´e de services exig´ee.
permet de tirer les b´en´efices de la programmation bas´ee sur les ´ev`enements.
Clairement, il existe quatre ´el´ements de base pour la conception d’un noyau de gestion d’´ev`enements :
– L’´ev`enement caract´eris´e par un type et des attributs ; – L’´emetteur (ou source) qui ´emet des ´ev`enements ;
– Le r´ecepteurqui s’abonne `a des ´ev`enements et en re¸coit ;
– L’aiguilleur (ou dispatcher) qui transmet les ´ev`enements d’un ´emetteur `a plu- sieurs r´ecepteurs.
La pattern Observateur/Observ´e, ainsi que d’autres design patterns, ont aid´e au d´eveloppement de la fameuse architecture Model View Controler (MVC). Cette m´ethode de conception consiste `a distinguer trois entit´es distinctes qui sont, le mod`ele, la vue et le contrˆoleur ayant chacun un rˆole pr´ecis dans l’interface graphique.
L’organisation globale d’une interface graphique est souvent d´elicate. Bien que la fa¸con MVC d’organiser une interface ne soit pas la solution miracle, elle fournit souvent une premi`ere approche qui peut ensuite ˆetre adapt´ee. Elle offre aussi un cadre pour structurer une application.
Dans l’architecture MVC, les rˆoles des trois entit´es sont les suivants.
– Mod`ele : donn´ees (acc`es et mise `a jour) – Vue: interface utilisateur (entr´ees et sorties)
– Contrˆoleur : gestion des ´ev`enements et synchronisation Interactions
Les diff´erentes interactions entre le mod`ele, la vue et le contrˆoleur sont r´esum´ees par le sch´ema de la figure suivante.
Figure 2.9 – Mod`ele-Vue-Controleur
Il est `a noter que les applications d’entreprise sont impl´ement´ees afin de communi- quer avec les EJBs qui sont d´eploy´es sur le serveur applicatif. Dans cet environnement client/serveur, le mod`ele de donn´ees se trouve au niveau du serveur applicatif. Ce dernier h´eberge, entre autres, les connecteurs vers la base de donn´ees.
Du cˆot´e client, on trouve :
– Les diff´erentes vues (interfaces) utilisant des objets de “transfert” qui adaptent les objets du mod`ele. En effet, ces objets ´etendent les objets du mod`ele en rajoutant des attributs qui facilitent l’affichage, le rafraichissement, la manipulation, etc.
– Les contrˆoleurs g`erent les actions des utilisateurs et veillent `a la coh´erence des donn´ees.
Figure 2.10 – Mod`ele-Vue-Contrˆoleur dans une application JEE
Toujours dans ce mode de fonctionnement, l’acc`es aux composants responsables du traitement de donn´ees (les EJBs) se fait en utilisant RMI (section 4.5.1) ou la norme WS. Cette derni`ere a eu un succ´es fulgurant ces derni`eres ann´ees, et ce principalement grˆace au langage XML et le protocole HTTP. Par ailleurs, les entreprises ne disposant pas d’un syst`eme informatique assez fiable pour supporter l’ensemble des applications ont commenc´e `a se diriger vers des fournisseurs IT capables d’h´eberger des serveurs applicatifs, des bases de donn´ee et autre. Ce concept qui fut appel´eCloud Computing permet aux entreprises de se concentrer sur la couche de pr´esentation et d’utiliser le syst`eme informatique du fournisseur pour impl´ementer les couches inf´erieures.
La section suivante d´ecortiquera les diff´erents aspects qui touchent `a ce concept.
2.7 Cloud Computing
2.7.1 Introduction
Informatique en nuage ou encore infonuagique. Ce sont les diff´erentes 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 `a petit dans les entreprises. Le principe ´etant d’utiliser les capacit´es de calcul et de stockage offertes par des parties tierces. Ainsi, tous les programmes et toutes les donn´ees sont d´eplac´ees sur cette informatique en nuage qui est consid´er´e comme un r´eseau de calcul capable d’´evoluer et d’offrir des ressources virtuelles sous forme de service (via internet) en fonction des besoins de l’utilisateur [7].
G´en´eralement, 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 `a fournir toute une infrastructure informatique en tant que service. Ama- zon.com est un des plus grand fournisseurs pour ce type de services. Amazon Elastic Compute Cloud (EC2) et Amazon Simple Storage Service (S3) sont uti- lis´es par plusieurs entreprise comme IBM, Oracle, MySQL Enterprise, etc. Dans ces syst`emes, le d´eveloppeur commence par cr´eer une Amazon Machine Image (AMI) qui contient le syst`eme d’exploitation ainsi que tous les programmes dont il a besoin. Le rajout d’une nouvelle AMI `a S3, la rend automatiquement disponible dans EC2. Le d´eveloppeur peut, ensuite, g´erer toutes les ressources qui s’ex´ecutent dans l’environnement informatique de Amazon [2, 3].
– Platform As A Service (PAAS) : consiste `a fournir des plates-formes infor- matique. Les d´eveloppeurs peuvent utiliser ces plates-formes pour d´eployer leurs applications sans devoir acqu´erir le mat´eriel ou le logiciel utilis´e par la plate-forme.
Google App Engine [5] est un exemple de plate-forme qui permet aux d´eveloppeurs d’ex´ecuter leurs applications web en utilisant l’infrastructure de Google. Cette derni`ere offre un support complet pour la cr´eation, l’ex´ecution et la gestion des application web.
– Software As A Service (SAAS): exploite les avantages de l’architecture SOA pour fournir des services `a travers internet.
Figure 2.11 – Tout comme service. X= ? [13]
2.7.2 SOCCA : Service Oriented Cloud Computing Architecture SOA et l’informatique en nuage sont ´etroitement li´es. En effet, SOA est un style architectural qui permet de cr´eer des solutions m´etier dont les composants peuvent ˆetre r´eutilisables, tandis que l’informatique en nuage est un ensemble de technologies utilis´e par des plate-forme tr`es flexibles au sein de l’architecture SOA de l’entreprise.
L’architecture Service Oriented Cloud Computing Architecture (SOCCA) peut ˆetre 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´esente les diff´erentes impl´ementations constituant les nuages.
Chaque fournisseur d’informatique en nuage dispose d’un centre de donn´ees qui alimente les services fournis. De plus, chaque nuage doit avoir sa propre techno- logie de virtualisation. Le Dispacher fonctionne en parall`ete avec le moniteur de machines virtuelles afin d’allouer les ressources demand´ees. Ces ressources sont regroup´ees sous forme de services ind´ependants comme le service de stockage, le service de calcul ou encore le service de communication. Ils disposent notamment d’interface open-standardis´e1 qui permettent leur combinaison avec les services des autres fournisseurs.
– Cloud Ontology Mapping Layer :
Le rˆole principal de cette couche est de cacher les diff´erences parmi les fournisseurs d’informatique en nuage. Elle peut aussi ˆetre utile lors de la migration d’une
1. Open-source et utilisant des standards
application d’un nuage `a un autre. Plusieurs syst`eme d’ontologie2 doivent ˆetre pr´esents au niveau de cette couche :
– Ontologie du stockage :
D´efinit les concepts et les termes li´es `a la manipulation des donn´ees au sein des nuages (mise `a jour, insertion, suppression de donn´ees, s´election de donn´ees, etc)
– Ontologie du calcul :
D´efinit l’ensemble des concepts et des termes li´es au calcul distribu´e au niveau des nuages
– Ontologie de la communication :
D´efinit les concepts et les termes li´es aux sch´emas de communication dans les nuages ( sch´ema d’encodage, routage des messages, etc)
– Cloud Broker Layer :
Cette couche h´eberge les agents interm´ediares entre les fournisseurs d’informatique en nuage et la couche de SOA. Chaque Service du nuage est associ´e `a un type de service broker. Ce dernier s’occupe des tˆaches suivantes :
– Publication des informations venant des fournisseurs :
Chaque fournisseur publie ses sp´ecifications ainsi que des informations li´ees au prix. Ces donn´ees 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´ecifications ainsi que la limitation concernant la ressource.
Des informations sur les prix : Ces prix varient d’un fournisseur `a un autre. Ils peuvent aussi ˆetre influenc´es par les variations du march´e.
– Classification :
Les brokers s’occupent de la classification des ressources publi´ees. Les services peuvent ˆetre class´es selon plusieurs crit`eres parmi lesquels on peut citer : Le prix, la disponibilit´e, le niveau de s´ecurit´e, etc
– Provision des ressources en fonction de la demande :
La meilleure fa¸con pour r´epondre convenablement aux besoins de l’utilisateur consiste `a analyser son utilisation actuelle des ressources afin de pr´edir et de pr´evoir ses exigences futures.
– SOA Layer :
Cette couche reprend les mˆemes fonctionnalit´es qu’une SOA traditionnelle.
Certains framework existants tel que CCSOA et UCSOA peuvent ˆetre int´egr´es au niveau de cette couche. Il importe de savoir que d’autres art´efacts peuvent y ˆetre publi´es et partag´es comme les templates, et en particulier les templates de collaboration, ainsi que les cas de test. Le registre des services est index´e pour chaque type d’art´efact et organis´e suivant l’ontologie.
La diff´erence fondamentale entre la couche SOA de SOCCA et une SOA tradition- nelle est que les fournisseurs de services n’h´ebergent plus directement les services publi´es. Les services sont plutˆot publi´es sous forme de packages qui peuvent ˆetre facilement r´epliqu´es et red´eploy´es sur les diff´erents environnements des nuages. Le d´eveloppeur a aussi la possibilit´e de d´esigner le nuage sur lequel sera d´eploy´e le package .
2. Ensemble structur´e des termes et concepts repr´esentant le sens d’un champ d’information
2.7.3 ISB : Internet Service Bus
Par “Informatique en nuage”, on entend le d´eplacement des programmes et des donn´ees vers les nuages afin qu’elles puissent exploiter l’infrastructure du fournisseur au lieu de s’ex´ecuter sur une machine locale.
Toujours dans le mˆeme ordre d’id´ees, l’ESB peut monter dans les nuages. Le principe est relativement simple. Il s’agit de standardiser les m´ecanismes li´es `a l’ensemble des tˆaches accomplies par le bus d’entreprises – pour les exposer sur Internet. On parle alors d’Internet Service Bus (ISB) par analogie `a l’ESB pour d´efinir ce concept de middleware orient´e messages que l’on distribue via l’Informatique en nuage.
L’approche la plus simple pour impl´ementer un ISB consite `a activer les services de l’ESB pour qu’ils soient disponibles sur internet. Cette approche n’est pas tr`es int´eressante car l’ISB, bien qu’il h´eberge des services qui sont accessibles via internet doit permettre le d´eplacement de services d´eploy´es vers les nuages d’informatique. La s´ecurit´e est un autre point qu’il faut prendre en consid´eration. Un utilisateur authentifi´e pour utiliser l’ISB doit pouvoir effectuer des communications s´ecuris´ees `a travers tous les noeuds par lesquels ses messages vont transiter.
Microsoft et linxter ont ´et´e les premiers `a avoir impl´ement´e un ISB (respectivement BizTalk Services et linxter ISB). Plusieurs concepts doivent ˆetre examin´es au niveau de ces impl´ementations :
– Le registre des services – Le nommage
– L’identification et le contrˆole d’acc`es – La connectivit´e
Le registre des services
Il s’agit d’un registre commun contenant l’ensemble des services heberg´es par l’ISB.
Ce point central peut ˆetre interrog´e par l’ensemble des services de m´ediation.
Le nommage
Les diff´erents Services ou End Point Reference (EPR) doivent ˆetre facilement iden- tifiables grˆace `a l’utilisation de conventions de nommage comme l’Unique Resource Identifier (URI).
L’identification et le contrˆole d’acc`es
Il importe de savoir quels m´ecanismes de s´ecurit´e seront mis en oeuvre(Active Direc- tory, OpenID, etc) et quelle m´ethode d’identification/authentification sera utilis´ee pour chaque service.
La connectivit´e
L’ISB doit fournir des services de m´ediation tout en cachant les diff´erents aspects li´es `a 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
l’ESB. Comme expliqu´e plus haut, les URI sont utilis´es pour identifier les services. Ainsi, chaque application peut ˆetre vue comme un ensemble d’URI, de r`egles et de fonctions.
Enfin, l’ISB permet de contrˆoler l’´echange de messages en se basant sur l’URI de l’´emetteur et l’URI du r´ecepteur.
Exemple d’impl´ementation : Linxter ISB
La solution d´evelopp´ee par Linxter vise `a 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´es par les instances d’applications.
– Outbound service: Achemine les messages aux diff´erentes instances (en attente de messages).
– Object store service: Manipule les attachements dans les messages.
– Hostname sevice : G`ere les adresses utilis´ees par les instances d’applications pour l’appel des services.
– Registration service : S’occupe de l’inscription des instances d’applications et la g´en´eration des tokens.
La figure 2.7.3 illustre la possibilit´e de cr´eer plusieurs instances d’ISB, chacune contient les services d´ecrit ci-dessus. Le SDK de linxter fournit, en outre, les outils permettant d’assurer la redondance ainsi que le load balancing entre ces diff´erentes ins- tances.
Figure 2.13 – Linxter ISB [10]
Event Driven Architecture
3.1 Introduction
Dans certains entreprises, il est parfois n´ecessaire de mettre en place des moyens pour d´etecter les ´ev`enements qui y sont en train de se produire et ainsi observer leurs symptˆomes [4]. Hier encore, un utilisateur m’a appel´e au travail pour me signaler que son application ´etait devenue trop lente au moment de la sauvegarde. Malheureusement, il m’a fallu 10 minutes de v´erifications pour me rendre que ce probl`eme ´etait dˆu `a un
´
ev`enement qui s’´etait produit bien avant que l’utilisateur ne commence `a se plaindre.
L’arrˆet d’un serveur auxiliaire en ´etait la cause.
Le traitement automatis´e des ´ev`enements qui se produisent dans le monde r´eel peut r´evolutionner notre fa¸con de vivre. Dans la suite, nous allons citer quelques exemples qui illustrent le besoin accru d’un traitement automatis´e des ´ev`enements.
– Un patient arrive dans un hˆopital et patiente dans la salle d’attente pendant une demi heure pour ˆetre re¸cu par la secr´etaire qui s’occupe de son dossier. La secr´etaire ne sait pas qui est dans la salle d’attente et se base exclusivement sur les num´eros 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´eer un dossier et un rendez-vous. Il serait int´eressant dans ce cas de d´etecter l’arriv´ee d’un patient (via une borne qui lit la carte d’identit´e ´electronique 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`eme qui re¸coit les notifications d’arriv´ee des patients et cr´ee automatiquement un dossier pour les patients qui n’en ont pas un en se basant sur les informations de la carte ´electronique. Cela
´epargnerait beaucoup de temps `a la secr´etaire et au patient,
– Les fraudes dans les institutions financi`eres sont souvent difficiles `a d´etecter. Seule l’analyse des diff´erents ´ev`enements qui se produisent au niveau de la banque et dans le syst`eme de trading permet de d´etecter les activit´es ill´egales. De mˆeme, le vol des num´eros de carte visa ne peut ˆetre d´etect´e que si une analyse des diff´erents
´ev`enements ( achat sur internet, argent retir´e `a la banque..) est effectu´ee en temps r´eel. Ce genre de traitement d’´ev`enements est appel´e “traitement pr´edictif”, – etc.
Naturellement, la technologie doit r´epondre `a tous ces cas de figures en offrant des solutions adapt´ees. Avant de s’attaquer `a ce sujet, voici une classification des raisons qui peuvent nous pousser `a envisager le traitement automatis´e des ´ev`enements :
26
– La n´ecessite d’un comportement temps r´eel dans les syst`emes informa- tiques. Cela implique implicitement la capacit´e d’adaptation dynamique des r´eactions du syst`eme face aux nouveaux ´ev`enements.
– L’observationd’un syst`eme dont le but de g´en´erer des alertes pour l’utilisateur.
– La diss´emination des donn´eesqui vise `a diffuser l’information pour arriver au bon consommateur, au bon moment et dans la bonne granularit´e.
– Le diagnostic actif. Le but ici est d’utiliser des actions pour affiner le diagnostic.
– Le traitement pr´edictif dont le but est d’identifier les ´ev`enements avant qu’il se produisent dans le syst`eme afin de les ´elimiter ou de changer leur effet.
3.2 Le concept
Dans le chapitre pr´ec´edent, nous avons ´evoqu´e la programmation bas´ee sur les
´
ev`enements et son principe de d´ecouplage de composants. Cette approche, qui est aussi
`
a la base de l’architecture IT bas´ee sur les ´ev`enements, permet d’identifier et de r´eagir intelligement dans certaines situations.
EDA est un style architectural qui s’impose de plus en plus dans les entreprises. Par opposition `a SOA o`u un “fournisseur” rend un service `a la demande d’un consommateur.
En architecture EDA, un “service” pr´evient par ´emission d’un ´ev`enement qu’il a r´ealis´e une op´eration donn´ee, ce qui permet de savoir l’avancement en temps r´eel des diff´erents processus utilisant ce service.
Il est `a noter que SOA d´ecortique parfaitement les applications en “service” ou en
“composant” et utilise la communication directe et synchrone entre ces composants.
C’est `a ce niveau-ci que r´eside toute la diff´erence avec l’EDA. En effet, les services ou agents de l’EDA envoient des requˆetes sous forme d’´ev`enements sans se pr´eocuper de leur acheminement (communication indirecte et asynchrone), ils ne sont pas cens´es savoir qui va recevoir l’information, ni comment elle sera manipul´ee. Ce sera `a un autre composant de s’ocupper de la r´ecolte et de la redistribution de ces ´ev`enements. Cela ´etant, il est possible qu’un composant impl´emente les deux approches (SOA et EDA). Il peut alors int´eragir de mani`ere directe et synchone avec les autres composants tout en jouant le rˆole de producteur et de consommateur d’´ev`enements.
La figure suivante donne une id´ee du fonctionnement g´en´eral d’une EDA. Les sections suivantes d´ecriveront ces diff´erents composants.
Figure 3.1 – Architecture bas´ee sur les ´ev`enements
3.3 Ses apports
Avant d’entamer la conception et le d´eploiement d’une EDA, il est important de savoir les caract´eristiques et les qualit´es de ses composants et surtout de comprendre comment ils peuvent fonctionner entre eux pour r´ealiser les fonctionnalit´es d´esir´ees de l’EDA.
L’objectif d’une telle architecture est tr`es simple : r´eagir intelligemment en fonction des ´ev`enements d´etect´es dans le syst`eme. Ce type d’architecture peut ˆetre utilis´e par exemple pour d´etecter et r´eagir aux vols des num´eros de cartes VISA sur internet. En effet, si la banque centrale dispose d’une architecture EDA, elle peut facilement surveiller les flux d’´ev`enements produits par les utilisateurs des cartes et essayer de trouver des anomalies (en se basant sur des r`egles pr´ed´efinies). Une carte sera automatiquement bloqu´ee si un retrait de 100 euros en Belgique est suivi d’un achat d’un article sur internet `a 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`emes des entreprises. Beaucoup de facteurs doivent ˆ
etre examin´es afin d’´evaluer les b´en´efices et la faisabilit´e d’une telle architecture. Il s’agit notamment de contraintes logiques d’applications, de contraintes sur les performances du syst`eme, de d´efis de l’entreprise et surtout le rapport coˆut-rendement de l’investissement.
Une EDA est cens´ee r´esoudre des probl`emes dans lesquels il existe diff´erents flux d’´ev`enements provenant de diff´erentes applications ou de syst`emes et o`u il est n´ecessaire d’avoir un suivi en temps r´eel de tous les ´ev`enements et des actions d´eclench´ees par ces
´
ev`enements.
3.5 Ses caract´ eristiques
3.5.1 Concentration des messages
Il s’agit ici de revoir sa vision de conception d’applications. Dans l’entreprise, certains processus m´etier sont compos´es de plusieurs services orchestr´es pour obtenir le r´esultat final. L’exemple suivant illustre le cas d’un processus m´etier qui se d´eroule en quatre
´ etapes.
Figure3.2 – Exemple de processus m´etier-1 [1]
Un changement dans les fonctions de l’application n´ecessite la modification du contrˆoleur.
Dans la vision EDA, le contrˆoleur sera remplac´e par un concentrateur de messages. Ceci rend les composants “pluggable” et facilite le rajout d’une nouvelle ´etape dans le pro- cessus m´etier.
Figure3.3 – Exemple de processus m´etier-2 [1]
3.5.2 D´ecouplage lˆache
Lorsque nous parlons de Loose Coupling, nous d´esignons un concept dans lequel les composants ne sont pas directement li´es entre eux, ils sont li´es de fa¸con abstraite en ayant chacun une connaissance des rˆoles des autres composants. Un syst`eme 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´e par les vendeurs) qui permet de v´erifier la validit´e d’une carte VISA. Ce dernier re¸coit un num´ero compos´e de 16 chiffres, une date d’expiration et un code de v´erification.
V´erifier un nouveau type de carte bancaire ne doit pas n´ecessiter la modification du programme, une nouvelle compilation, une modification du cot´e du client, etc. Autrement dit, le composant doit ˆetre compl´ement configurable, adaptable en fonction du contexte, ind´ependant du reste du syst`eme et il ne doit en aucun cas r´esister aux changements.
Cela facilitera de mani`ere significative la maintenance du service.
Il est aussi important lors de la conception du composant, de penser `a l’utilisation de patterns comme le “adapter pattern” qui permet de modifier le comportement d’un objet et l’adapter en fonction du contexte.
3.5.3 Messagerie asynchrone
Ces middelewares ont un mode de fonctionnement asynchrone, le producteur (´emetteur) et consommateur (r´ecepteur) ne doivent pas ˆetre disponibles en mˆeme temps ; l’´emetteur interagit avec le serveur de messagerie au cours d’une transaction locale et ignore si les parties int´eress´ees 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 pu- blications. Ainsi chaque consommateur inscrit pour un topic re¸coit les messages qui concernent ce dernier.
3.5.4 Exploitation des ´ev`enements
Les informations concernant l’´etat du processus m´etier doivent ˆetre stock´ees dans l’´ev`enement. Ceci permettra `a chaque composant de l’EDA de rester au courant de l’avancement du processus.
Il est `a noter qu’un mod`ele de donn´ees commun doit ˆetre ´etabli pour les ´ev`enements.
Pour ce faire, un ensemble de transformateurs doit ˆetre d´evelopp´e pour assurer la conver- sion des messages. Ainsi, un seul format de message sera manipul´e par la syst`eme de messagerie interne de l’EDA.
Toujours dans le mˆeme sens, les types d’´ev`enements doivent ˆetre facilement identi- fiables. Il est important de d´efinir une hi´erarchie pour les noms d’´ev`enements ainsi que des dictionnaires d’´ev`enements dans lesquels doivent ˆetre r´epertori´e tous les ´ev`enements susceptibles d’ˆetre d´eclench´es dans l’EDA.
3.5.5 Transport des messages
Comme d´ecrit ci-dessus, la messagerie asynchrone repr´esente l’´epine dorsale de l’EDA.
Le syst`eme de messagerie doit pouvoir v´ehiculer des millions de messages. Des compo- sants comme l’ESB ou uneQueue peuvent ˆetre utilis´es pour f´ed´erer les ´ev`enements entre les producteurs d’´ev`enements, les consommateurs d’´ev`enements ainsi que les processeurs d’´ev`enements .
Figure 3.4 – ESB comme Event Collector
3.6 Ses composants
3.6.1 Notion d’´ev`enement
Un ´ev`enement peut ˆetre tout ce qui arrive `a l’int´erieur ou `a l’ext´erieur de l’entreprise.
Il doit contenir suffisament d’informations sur le fait qui vient de se passer. Chaque
´
ev`enement est compos´e d’une entˆete et d’un corps. L’entˆete ´etant utilis´ee pour renseigner sur l’id de l’´ev`enement, son type, sa date/heure, son cr´eateur, etc. Elle sera lue par les interm´ediaires par lequels l’´ev`enement va transiter. Le corps de l’´ev`enement d´ecrit en d´etail le fait qui vient de se passer.
3.6.2 Outil de Messagerie
C’est le cœur de l’EDA et l’infrastructure qui g`ere les communications. C’est cette partie-l`a qui permet aux composants de communiquer entre eux.
3.6.3 Producteurs d’´ev`enements
Repr´esente la source des ´ev`enements. Cela peut ˆetre un ordinateur ou tout autre ap- pareil capable de communiquer. Les fournisseurs peuvent fournir des API qui permettent de communiquer facilement avec l’´equipement en question.
