UNIVERSITE LIBRE DE BRUXELLESFaculte des Sciences

Departement d’Informatique

Gestion d’une plate-forme temps reel

sur une architecture basee sur

les evenements

Mohammed Jelti

Promoteur : Memoire presente en vue deProf. Esteban Zimanyi l’obtention du grade de

Master en Sciences Informatiques

Annee academique 2009 - 2010

A tous ceux qui m’ontsoutenu, pendant

huit ans d’existence ici

“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’tfight them. Just find a different way to stand.”

Oprah Winfrey

Remerciements

Je tiens tout d’abord a adresser mes plus sinceres remerciements a M. EstebanZimanyi, directeur de ce memoire, ainsi qu’a M. Sabri Skhiri directeur de rechercheet de developpement d’Euranova, pour m’avoir suivi et pour m’avoir consacre autant detemps.

Je voudrais egalement remercier ici l’equipe d’informatique d’Alcatel-Lucent a Na-mur, et notamment M. Xavier Lerot qui m’a beaucoup aide durant ce travail et qui m’aprodigue de precieux conseils.

Je ne saurai oublier ici l’administration et tous les enseignants de l’ULB qui ontcontribue a ma formation universitaire et plus particulierement les membres du jury dece memoire, messieurs Raymond Devillers et Joel Goossens.

Je temoigne aussi toute ma reconnaissance amicale a toute l’equipe d’Euranova dontla disponibilite et la courtoisie ont ete constantes a mon egard.

Enfin, je remercie tous ceux qui ont contribue de pres ou de loin a l’elaboration dece travail.

Table des matieres

1 Introduction 3

1.1 Contexte du probleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Objectif du memoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Organisation du memoire . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Architecture logicielle d’entreprises 6

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 La couche de presentation . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 La couche des processus metiers . . . . . . . . . . . . . . . . . . . . . . . 7

2.4 La couche d’integration . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 caracteristiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

v

vi

4 Outils et technologies d’implementation 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 Presentation 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’integration 70

6.1 Les apports de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6.2 Description de la solution d’integration . . . . . . . . . . . . . . . . . . . 72

6.3 Implementation de la solution d’integration . . . . . . . . . . . . . . . . 75

6.4 Generation automatique de la solution . . . . . . . . . . . . . . . . . . . 80

7 Conclusion 83

Bibliographie 84

A Rapport du stage en entreprise 88

A.1 Implementation d’un Event Collector . . . . . . . . . . . . . . . . . . . . 88

A.2 Implementation d’un CEP . . . . . . . . . . . . . . . . . . . . . . . . . . 94

A.3 Patterns d’implementation pour une EDA . . . . . . . . . . . . . . . . . 95

1

AMI Amazon Machine ImageAMQP Advanced Message Queuing ProtocolAS Application ServerAPI Application Programming InterfaceBAM Business Activity ManagementBPEL Business Process Execution LanguageBPL Business Process LayerBPM Business Process ManagementCBR Content Based RoutingCDIF CASE Data Interchange FormatCEP Complex Event ProcessingCRUD Create, Read, Update, DeleteCRM Customer Relationship ManagementCWN Commun Warehouse MetamodelDNS Domain Name SystemEAI Enterprise Application IntegrationEIA Electronic Industries AllianceEC2 Elastic Compute CloudEDA Event Driven ArchitectureEJB Enterprise JavaBeanEMF Eclipse Modeling FrameworkEPA Event Processor AgentEPN Event Processing NetworkERP Enterprise Resource PlanningEPR End Point ReferenceESB Enterprise Service BusESC Enterprise Service CloudESM Enterprise Messaging SystemFTP File Transfer ProtocolHTTP HyperText Transfer ProtocolIAAS Infrastructure as a ServiceIDE Integrated Development EnvironmentIHM Interface Homme-machineIIOP Internet Inter-Orb ProtocolIP Internet ProtocolISB Internet Service BusJAAS Java Authentication and Authorization ServiceJBOSS Java Beans Open Source SoftwareJCA Java Connector ArchitectureJDBC Java DataBase ConnectivityJDK Java Development KitJEE Java Enterprise EditionJET Java Emitter TemplatesJMX Java Management ExtensionJMS Java Messaging ServiceJNDI Java Naming and Directory InterfaceJPA Java Persistance APIJSF Java Server FaceJSP Java Server Page

2

JSPX Java Server Page XMLJTA Java Transaction APIJTS Java Transaction ServicesLDAP Lightweight Directory Access ProtocolMDA Model Driven ArchitectureMOF Meta-Object FacilityMOM Message Oriented MiddlewareMVC Model View ControlerNDS Naming and Directory ServiceNGIN Next Generation Intelligent NetworkNIS Network Information ServiceOCL Object Constraint LanguageOM Objet MetierOMG Object Management GroupOMS Objet Metier SpecifiqueOSGi Open Services Gateway initiativePAAS Platform As A ServicePIM Platform-Independent ModelPOJO Plain Old Java ObjectREST Representational state transferRCP Rich Client PlatformRFID Radio Frequency IDentityRFP Request for ProposalRMI Remote Method InvocationSAAS Software As A ServiceSAM Service Activity MonitoringSBB Service Building BlockSCA Service Component ArchitectureSMIF Serial Model Interchange FormatSDK Software Development KitSMTP Simple Mail Transfer ProtocolSOA Service Oriented ArchitectureSOAP Simple Object Access ProtocolSOCCA Service Oriented Cloud Computing ArchitectureSQL Structured Query LanguageSWT Standard Widget ToolkitS3 Simple Storage ServiceXMI XML Model InterchangeXML eXtensible Markup LanguageXSL eXtensible Stylesheet LanguageUDDI Universal Description Discovery and IntegrationUML Unified Modeling LanguageURI Unique Resource IdentifierWS Web ServiceWSDL Web Services Description Language

Chapitre 1

Introduction

1.1 Contexte du probleme

Les economistes s’accordent depuis quelques decennies sur l’importance du progrestechnique en tant que facteur de la croissance economique. Les entreprises, premieresconcernees, tachent d’optimiser le systeme informatique en vue d’ameliorer les perfor-mances. Ainsi, les directeurs informatique se concentrent sur deux elements centraux ausein de l’entreprise : le flux de travail (Workflow) et le flux de donnees (Dataflow). Leurmaıtrise reste le meilleur moyen d’ameliorer l’efficacite de l’entreprise.

Tres souvent, les entreprises se tournent vers les experts en matiere d’architectureIT 1 afin de concevoir et de coordonner le flux de donnees. Ce dernier reste difficile-ment gerable sachant que de nouvelles applications sont rajoutees au fur et a mesuredu developpement du systeme informatique de l’entreprise. Ceci implique une interven-tion continue de la part des experts, ce qui oblige les entreprises a s’orienter vers desarchitectures inter-applications evolutives capables de gerer l’echange de donnees entreapplications. Plusieurs solutions proprietaires pour ce type d’architecture sont proposeespar les fournisseurs IT. Toutefois, d’autres solutions open-source et utilisant des proto-coles standards ont vu le jour ces dernieres annees.

De maniere generale, le systeme informatique de l’entreprise doit pas resister auxchangements applicatifs. L’introduction d’une nouvelle application doit se faire sansmodifier le reste du systeme. Seuls le flux entrant et le flux sortant de la nouvelleapplication doivent etre disctutes avec le fournisseur ou le developpeur. Malheureu-sement a l’heure actuelle, beaucoup d’entreprises sont loin d’avoir des systemes infor-matiques aussi flexibles. Neanmoins, les fournisseurs IT restent tres vigilants quant auxdifferentes possibilites d’integration de leurs applications. Il va sans dire que les entre-prises privilegient les applications faciles a integrer, celles-ci evitent beaucoup de fraisde developpement et de temps de perdu.

Du point de vue conceptuel, lorsque l’on veut construire un systeme informatiqueflexible, le premier point auquel on pense est la reutilisabilite. Souvent les applicationsont des besoins communs qui peuvent etre traites par un meme composant. Cela facilitel’evolution de ce dernier tout en evitant la redondance. Ce principe est un des fondementsde l’architecture orientee services ou Service Oriented Architecture (SOA) dans laquelle

1. Information Technology

3

4

des composants dits “Services” peuvent etre invoques de maniere synchrone par lesdifferents composants du systeme informatique. Remarquons que grace a la montee enpuissance des technologies web, notamment le langage XML et le protocole HTTP, cetype d’architecture a eu beaucoup de succes aupres des entreprises ces dernieres annees.Parallelement a cela, un deuxieme fondement sur lequel repose ce type d’architectureet qui est le decouplage lache ne semble plus tenir [12] . En effet, les applications dansune telle architecture ne sont pas completement independantes vu qu’elles s’adressentdirectement aux services exposes en solicitant une reponse immediate a leurs requetes.Or, ceci limite l’autonomie des applications et fausse l’idee de decouplage lache que proneSOA. Cela etant, l’utilisation de SOA reste toujours conseillee dans l’implementationdes processus metiers (chaınes d’actions) ou lorsque les requetes necessitent une reponseimmediate ( ex : transactions, etc).

Event Driven Architecture (EDA) ou architecture basee sur les evenements vientrenforcer la reduction du couplage entre les composants grace notamment au caractereasynchrone des requetes. Les composants communiquent via des evenements qui sontrecoltes et centralises par une seule entite. Cette derniere s’occupe egalement de leurtransmission aux applications interessees. Concretement, ce type d’architecture vise arecolter les evenements pour savoir l’etat actuel du systeme et pouvoir y reagir.

1.2 Objectif du memoire

Comme explique auparavant, l’integration d’une application au sein d’un systemeinformatique deja developpe peut couter tres cher a l’entreprise. Nous entendons parle terme “Integration”, le fait d’exposer les nouvelles fonctionnalites de l’application aureste du systeme informatique et vice versa. En effet, les applications du S.I 2 doiventpouvoir faire appel a ces fonctions, soit directement, soit en passant par un intermedairequi joue le role de “convertisseur” de donnees. L’entreprise interessee par cette methoded’integration peut demander l’intervention de techniciens qualifies qui s’occupent de lamise en place de liens (one-to-one) entre l’application et le reste du systeme. Rappelonsqu’outre les depenses, cette procedure genere un ensemble d’interfaces inter-applicativesqui empechera les applications concernees d’evoluer vu leurs dependances directes aureste du systeme. Ce probleme est connu sous le nom de “l’effet spaghetti”.

Dans ce memoire, nous allons nous concentrer sur une application de gestion deplate-forme temps reel qui doit etre integree dans le S.I d’un operateur lambda. Nousproposerons une nouvelle approche pour faciliter cette tache et offrir un ensemble le plusflexible possible.

Evidemment, l’application en question dispose d’une couche applicative qui exposeses fonctionnalites et accepte les liens one-to-one mais le but de ce travail est de proposerune maniere intelligente d’acceder a ces “Services” tout en limitant les dependances et enoffrant plus de souplesse et de flexibilite. Clairement, nous allons proposer une solutionorientee evenements permettant a cette application de s’inserer dans une architecturebasee sur les evenements. Ainsi, n’importe quelle application du S.I pourra faire appela ces fonctionnalites via des evenements.

2. Systeme d’information

5

Pour illustrer le fonctionnement souhaite, rien de mieux qu’un exemple concret :

Un evenement A, qui represente une demande de creation d’un nouveau compte pourun client, se declenche dans l’application X du S.I. Il est avale par l’entite centrale quicollecte les evenements et transmis a l’application de gestion, dont il est sujet ici, pouretre traite. Ce meme evenement A pourra etre transmis a toutes les applications inter-essees pourvu qu’elles soient inscrites au niveau de l’entite centrale (publish/subscribe).Cette derniere joue un role semblable a celui du routeur reseau mais veille en plus ala transformation des donnees des evenements afin qu’elles soient manipulables par lesdifferentes applications.

L’exemple ci-dessus explique le fonctionnement souhaite de l’application dans unearchitecture basee sur les evenements. Malheureusement, beaucoup d’operateurs ne dis-posent pas encore de ce genre d’architecture. En annexe de ce memoire se trouve un guided’implementation d’architecture basee sur les evenements a partir d’outils open-sourceet respectant les standards actuels.

Notre but ultime est de montrer les avantages d’une architecture basee sur lesevenement et tout ce qu’elle peut apporter a l’entreprise.

1.3 Organisation du memoire

Ce memoire commencera par une etude complete de l’architecture IT des entreprises.Nous verrons l’ensemble des composants du systeme informatique ainsi que les differentestechnologies d’integration : Enterprise Application Integration (EAI), Enterprise ServiceBus (ESB), etc. Nous discuterons le role central de l’ESB dans l’integration d’applica-tions d’entreprise et comment l’architecture SOA peut-elle etre implementee a traversl’EDA.

Le troisieme chapitre est consacre a l’EDA. Nous verrons ses caracteristiques endetail ainsi que les differents elements qui la composent.

Ensuite, le quatrieme chapitre abordera l’ensemble des outils et des technologiesd’implementation qui sont utilisees dans la conception de l’application de gestion de laplate-forme temps reel (Eclipse Modeling Framework (EMF), Java Emitter Templates(JET), JBoss, Enterprise JavaBean (EJB), etc).

Le dernier chapitre presentera l’architecture de l’application ainsi que l’implementationdetaillee de la solution. Rappelons que cette solution vise l’integration “intelligente” decette application dans une architecture basee sur les evenements(EDA).

Enfin, ce memoire se terminera par une conclusion qui reprendra les apports et lesresultats de ce travail.

Chapitre 2

Architecture logicielle

d’entreprises

2.1 Introduction

Aujourd’hui, les entreprises s’orientent vers l’integration des applications avec commeobjectif de permettre la communication entre toutes les applications qu’elles soientdeveloppees en interne ou en externe. Parallelement a cela, on remarque une tendancedes entreprises a aller vers des solutions logicielles orientees services. On constate aussile fort accroissement de l’utilisation des processus metier par les dirigeants IT.

Dans ce chapitre, nous allons montrer les changements impliques par l’introductiondes processus metiers au niveau de l’architecture IT. Nous verrons comment l’ensembledes couches applicatives s’adapte pour beneficier des apports de l’architecture orienteeservices et surtout comment reconcilier les processus metier, la SOA et l’integration desapplications. La figure suivante illustre les differentes couches applicatives qui serontdecortiquees dans la suite.

Figure 2.1 – Couches applicatives

6

7

2.2 La couche de presentation

La couche de presentation utilise les operations des couches inferieures pour accom-plir les fonctionnalites demandees par les utilisateurs au travers des interfaces Homme-Machine. Il est important de bien separer les composants de cette couche des autrescomposants afin d’eviter de dupliquer du code et d’ameliorer l’independance entre lescouches.

Le portail (figure 2.1) va permettre aux utilisateurs d’avoir un point d’acces uniquepour acceder aux composants et aux ressources de la couche de presentation.

2.3 La couche des processus metiers

Aujourd’hui, les processus metiers sont devenus essentiels pour les dirigeants ITet permettent de formaliser le savoir-faire de l’entreprise. Leur optimisation demeurele meilleur moyen pour ameliorer la productivite de l’entreprise et faire face aux exi-gences des clients. On appelle processus metier ou processus operationnel un ensemblede fonctions metiers qui menent a un resultat tangible. On peut prendre pour exemplele processus metier “vente de produits sur internet” qui peut etre decortique en plu-sieurs etapes ou sous-processus metier : parcourir les produits, choix d’un ou plusieursproduits, commande et reception du produit par le client.

Figure 2.2 – processus metier : vente de produits sur internet

Naturellement, l’architecture IT de l’entreprise se doit d’offrir de nouvelles fonction-nalites pour l’integration et la gestion reguliere de ces processus. Pour ce faire, une

8

nouvelle couche est introduite dans le modele informatique traditionnel. Il s’agit de lacouche des processus metier ou Business Process Layer (BPL).

Cette couche se trouve entre la couche presentation et la couche d’integration etcontient :

1. Les modeles des processus metier.

2. Les regles associees aux modeles.

3. L’ordonnancement des processus.

4. Les donnees necessaires pour la transformation des donnees.

Elle doit assurer :– L’integration des donnees provenant de tous les composants.– Le transport des donnees entre applications.– Gestion des processus metier grace au Business Process Management (BPM).A ce niveau, chaque processus metier definit les services metier qu’il va utiliser et

qui vont etre orchestres par le BPM.

2.3.1 BPM : Business Process Management

Comme explique auparavant, les processus metier permettent de formaliser le savoir-faire de l’entreprise et s’alignent sur le concept de SOA. Cependant, l’entreprise doit avoirles outils et les methodes pour gerer ses processus metier. C’est le role du BPM.

Le BPM permet d’avoir une vue globale sur l’ensemble des processus metier et offrela possibilite de s’adapter a de nouvelles situations.

Une Solution BPM est composee de plusieurs elements :– Un outil de modelisation qui permet de decrire les procedures de production en

processus (voir l’exemple de vente de produits sur internet : figure 2.2)– Des outils d’aide a l’implementation.– Un moteur d’execution de processus.– Des outils d’administration pour parametrer l’ensemble des processus et analyser

les donnees collectees apres l’execution des processus. Parmi ces outils, on peuttrouver le Business Activity Management (BAM) qui permet de suivre l’activited’un processus metier.

L’adoption d’une telle solution doit passer par plusieurs etapes :

1. Etude de l’entreprise afin de determiner les processus metier.

2. Modelisation des processus metiers.

3. Implementation de la solution

4. Execution

5. Pilotage : analyser l’etat des processus ainsi que leurs performances.

6. Optimisation : amelioration des performances des processus metiers.

Le BPM offre aux entreprises la possibilite de gerer le cycle de vie complet de leursprocessus metiers : identification, modelisation, implementation, execution, analyse etoptimisation des processus metier. Ceci ameliore les performances et rend le systeme etles processus metier adaptables aux changements potentiels.

9

2.3.2 BAM : Business Activity Monitoring

De son cote, le BAM a pour objectif de s’adresser specifiquement au responsablemetier plutot que technique. Pour cela, le BAM va s’appuyer sur le Service ActivityMonitoring (SAM) pour recolter des informations sur l’etat de fonctionnement des pro-cessus.

Les informations collectees seront presentees aux utilisateurs au travers de la consolede supervision BAM.

2.3.3 SAM : Service Activity Monitoring

Le SAM permet de controler et de mesurer les performances techniques de la plate-forme et des services deployes.

2.4 La couche d’integration

Deux technologies sont principalement utilisees pour l’integration des applicationsau sein des entreprises :

2.4.1 EAI pour Enterprise Application Integration

“L’Integration d’applications d’entreprise ou en anglais Enterprise Applica-tion Integration, est une architecture intergicielle permettant a des applica-tions heterogenes de gerer leurs echanges”

IBM.fr

Le systeme informatique des entreprises est constitue de plusieurs applications quicommuniquent entre elles grace a des passerelles ou des interfaces dont le temps derealisation peut etre assez important. L’idee de base de l’EAI est de creer un concentra-teur qui recoit le flux de donnee de sortie de chaque application, le traite et le redistribueaux applications interessees. Ainsi, l’ajout de nouvelles applications s’effectue avec plusde rapidite et consiste a modifier simplement le point d’entree et de sortie de cettederniere afin de la brancher sur le concentrateur. Elle pourra, des lors, beneficier du fluxde donnees provenant d’autres composants du systeme.

Dans cette architecture (figure 2.3), les applications peuvent fonctionner independammentles unes des autres grace aux elements suivants :

– Les connecteurs : Ce sont les interfaces entre l’EAI et les applications. Ils s’oc-cupent de la transmission de donnees entre l’EAI et les applications.

– Objet Metier Specifique (OMS) : ou en anglais Application Specific BusinessObjects. Ce sont les donnees qui transitent entre l’EAI et les applications

– Objet Metier (OM) : Objet de metier standard, les connecteurs transformentles OMS en OM (modele de donnee global) avant d’etre traites.

– Protocoles au niveau de la couche de transport (comme HyperText TransferProtocol (HTTP))

10

Figure 2.3 – Entreprise Application Integration

Il existe deux types d’architecture de base pour l’integration d’applications d’entre-prise :

Architecture Hub and spoke

Cette architecture est constituee d’un point de connexion central et d’un ensembled’adaptateurs qui permettent de connecter l’ensemble des applications (reseau en etoile).Les adaptateurs recoivent les messages d’informations et les transmettent au systemede messagerie qui s’occupe de la transformation, traduction et routage de l’informationvers les modules interesses. Il est evident qu’avoir un point central rend l’architecturefacile a gerer mais constitue un handicap au niveau de l’extension (lorsque le nombrelimite d’operations est atteint au niveau du concentrateur). Dans ce cas, on peut tresbien imaginer une architecture basee sur plusieurs Hub et dont les regles peuvent etredefinies de maniere globale et propagees sur l’ensemble des concentrateurs.

Architecture basee sur un Bus

Dans cette architecture, les messages publies par les adaptateurs transitent via unBackbone (bus) et sont transmis aux applications inscrites sur le bus. Chaque applicationest dotee d’adaptateurs qui s’occupent de la transformation de ses messages dans le bonformat. Cette architecture regle le probleme d’extension car la charge du systeme estrepartie sur l’ensemble des noeuds (point de connexion a une application), ce qui estcense offrir de meilleures performances.

Les solutions EAI proposees aux entreprises utilisent des protocoles et des interfacesproprietaires qui ne sont pas en principe compatibles avec ceux d’autres fournisseursde solutions EAI, ce point essentiel limite l’interoperabilite entre les entreprises quiutilisent des solutions EAI differentes. L’ESB solutionne ce probleme en s’appuyant sur

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 WebService (WS).

2.4.2 ESB pour Enterprise Service Bus

L’ESB est une plate-forme d’integration qui met en application la notion de SOA. Lanotion de SOA est un modele architectural qui a pour principe d’augmenter l’efficacite,l’agilite et la productivite d’une entreprise en placant la notion de services comme lemoyen principal pour atteindre les objectifs strategiques [12].

Dans la terminologie SOA [12], on distingue differents type de services :– Les Services Create, Read, Update, Delete (CRUD) permettent de creer,

rechercher, mettre a jour ou supprimer des donnees dans des referentiels (base dedonnees, annuaire, fichier, etc).

– Les Services Techniques donnent acces a une ressource technique telle que :une base de donnees relationnelle, une imprimante, un systeme de trace d’infor-mation, un progiciel de type Enterprise Resource Planning (ERP), un serveur demessagerie, etc.

– Les Services Applicatifs sont des services de haut niveau (egalement appeles

12

Figure 2.6 – Enterprise Service Bus

services de facade) qui masquent aux applications composites les services de plusbas niveau tels que les Services CRUD ou techniques.

– Les Services Fonctionnels sont des services metiers qui encapsulent la logiqueet les regles metiers des processus.

Ce sont les services fonctionnels qui sont deployes au niveau de l’ESB, grace notam-ment a Service Component Architecture (SCA) qui est un ensemble de specificationsvisant a simplifier la creation et la composition de services (independamment de leurimplementation) dans le cadre de SOA.

Pour revenir a l’ESB, il s’agit d’un bus representant le backbone et qui est responsablede la transformation, du formatage et du routage des differents messages envoyes parles differents services et applications relies a l’ESB. Les avantages de cette architecturepar rapport a l’architecture Bus de l’EAI presentee 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 cout d’implementation est moins eleve que dans le cas d’un bus proprietaire,

4. l’ESB n’utilise pas des formats proprietaire contrairement aux solutions EAI.Le routage intelligent se base sur le contenu du message afin d’acheminer les donnees

(le concept de Content Based Routing (CBR) , Ainsi l’ESB deduit le destinataire dumessage en fonction de son contenu et des regles predefinies. Chaque regle contient unecondition ainsi que la reference du destinataire au cas ou le message verifie la conditionde la regle.

En resume, l’ESB permet de composer les services fonctionnels afin d’assurer l’integrationdes donnees comme explique ci-dessus. L’information recue par les connecteurs suit

13

une certaine logique d’integration (transformation, formatage, etc) avant d’arriver ausysteme de messagerie, ce qui la rend independante de l’aspect proprietaire.

Les connecteurs

Les connecteurs ou gateways representent les points d’entres de l’ESB, leur roleest de deplacer l’information de l’exterieur vers l’interieur de l’ESB tout en l’adaptantpour qu’elle soit manipulable par les composants internes. A nouveau, pour garder cetteidee de souplesse, chaque connecteur doit traiter un seul type de message afin de luiapporter les transformations necessaires. Ceci permet de specialiser chaque connecteuren lui associant un type de message precis.

Lorsqu’on dispose d’un ensemble d’applications non homogenes, il pourrait etreinteressant d’offrir un ensemble de type connecteurs varie et utilisant des technolo-gies differentes pour faciliter la connection des applications. On constate aujourd’huile developpement de nouveaux types de connecteurs. On y trouve des connecteursde type HTTP, JMS, Simple Object Access Protocol (SOAP), Simple Mail Trans-fer Protocol (SMTP), FTP, file, Java Connector Architecture (JCA) , Java DataBaseConnectivity (JDBC), etc.

MOM pour Message Oriented Middleware

Un des fondements de l’ESB est le Message Oriented Middleware (MOM) qui est lecœur de cette architecture. Il permet l’echange de messages asynchrones entre applica-tions et garantit la livraison des messages (que le destinataire preinscrit soit disponibleou non, les messages seront mis en attente de reception). Il peut aussi assurer la per-sistance des messages qu’il recoit, il suffit de marquer un message comme persistant etle MOM se chargera d’assurer qu’il ne soit jamais perdu (en faisant des backups sur ledisque).

Le MOM a un mode de fonctionnement asynchrone. Comme explique precedemment,l’emetteur et le recepteur ne doivent pas etre disponibles en meme temps, l’emetteurinteragit avec le serveur de messagerie au cours d’une transaction locale et ignore siles parties interessees par son message sont disponibles au moment de la transaction.Certaines implementations du MOM prevoient meme un modele de regroupement detransactions en une seule appele 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 interessees. Seul l’envoi de lacommande “commit” de la part de l’emetteur rend l’information disponible aux modulesinteresses (ce principe est tres semblable a celui des base de donnees). De meme, la com-mande rollBack permet l’annulation de la transaction. Dans certaines implementations,le MOM fournit des interfaces pour la manipulation des ressources pendant une tran-saction.

Un message est compose de trois parties : un header, des proprietes, et un corps.

– Le header renseigne sur la source du message, la destination de la reponse si celleci est exigee par l’emetteur, type de message, etc.

– Les proprietes sont representees par des paires (nom,valeur) et sont verifiees parles filtres de consommateur ou des routeurs specialises.

14

Figure 2.7 – La relation Publish and Subscribe

Il est important de savoir que chaque entite communicante joue le role de producteuret de consommateur de messages. Les producteurs et les consommateurs sont dits “loo-sely coupled”. Cela veut dire qu’ils ne sont pas directement lies, mais qu’ils sont reliesde facon abstraite via des canaux virtuels appeles les canaux publish-and-subscribe oua travers des canaux point-to-point. Le producteur de messages n’a pas besoin de savoirqui va recevoir les messages, de meme, le consommateur est completement independantdu producteur des messages. Toutefois, si le producteur du message veut exiger unereponse de la part du consommateur, il doit inclure l’adresse de reponse dans l’entetedu 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 despublications. Ainsi chaque consommateur inscrit pour un topic recoit les messages quiconcernent ce dernier. Le deuxieme type de relation, a savoir la relation point-to-point,est une relation one-to-one ou les messages du producteur sont stockes dans une queueen attendant d’etre consomme par un seul consommateur.

Notons que le choix du modele d’echange (publish-and-subscribe ou point-to-point)depend du nombre de consommateurs potentiels.

Les conteneurs de services d’integration

Le conteneur de services est l’element qui va se charger d’heberger et de composerles services d’integration.

L’utilisation de conteneurs de services simples et legers permet de realiser une integrationcompletement distribuee. Ces conteneurs peuvent heberger un ou plusieurs services etmanipulent le flux entrant et sortant du service. Il existe une multitude de services parmilesquels on peut citer :

– Les services de securite implementant les standards WS-Security,

15

– Les services de transformation de messages offrant par exemple le support destransformations eXtensible Stylesheet Language (XSL),

– Les services de routage des messages,– Les services d’audit et de log offrant la mecanique pour tracer des informations,– etc.

La difference entre les conteneurs de services d’integration de l’ESB et les conteneursde services d’application comme (le JBoss Application Server (AS) par exemple) est queces derniers hebergent des fonctions metier et des pages web tant dis que les conteneursde services d’integration de l’ESB hebergent les services d’integration et procedent al’integration des flux de donnees. Cela veut dire que les donnees vont suivre un certainparcours a l’interieur de l’ESB et que leur presentation va etre adaptee pour qu’elle soitcompatible avec le service qui va les utiliser.

2.5 La couche des services

Cette couche regroupe l’ensemble des elements requis pour modeliser, construire,tester et deployer les services. Ici, nous allons nous interesser a deux types de services :les services d’integration et les services CRUD. Ces derniers sont accessibles au systemeoperationnel de l’entreprise (applications traditionnelles, composants, base de donnees,etc) comme c’est le cas des servies metiers se trouvant au niveau de la couche desprocessus metier.

L’avantage majeur d’un service CRUD est sa reutilisabilite vu qu’il peut, notammentgrace aux interfaces SOAP, recevoir des requetes a partir de n’importe quelle application,pourvu qu’elle respecte ses parametres. Remarquons qu’un service peut etre construitpar composition d’autres services, de meme que la composition de services peut faireintervenir des services distribues. Enfin, les parametres d’un service sont souvent decritau travers un fichier Web Services Description Language (WSDL) (connu grace aux WebServices).

2.6 La couche des applications

Dans cette partie, nous allons nous interesser a certaines methodes logicielles deve-nues aujourd’hui incontournables au sein des entreprises. Nous montrerons comment onconcoit les applications Java orientees entreprise, notamment en utilisant des modelesde conception appeles communement Design patterns. Ces derniers ne sont pas lies a unlangage de programmation et peuvent etre implementes sous differentes formes.

Les applications Java Enterprise dependent principalement de deux elements quiseront presentees dans les sections suivantes :

– L’infrastructure d’execution offerte par JEE (section 2.6.2).– La puissance de la programmation basee sur les evenements (section 2.6.3).

2.6.1 Utilisation des design Patterns en Java

Le travail du concepteur de programmes a toujours ete consiste en deux choses :analyser et developper des applications afin de repondre aux besoins des utilisateurs.

16

Souvent, les programmeurs ne disposant d’aucune experience essaient de mettre en pra-tique la theorie apprise a l’ecole et ainsi construire petit a petit leurs applications enpensant toujours a la premiere version finalisee de l’application. Seulement, l’applicationne reste jamais a sa premiere version et des dizaines de modifications doivent etre ap-portees par la suite. Des modification mineures du code peuvent engendrer enormementde bugs et d’anomalies de fonctionnement dans ce genre d’applications. Le concepteurfinit par etre sature par la complexite du codage (effet spaghetti). J’en veux pour preuvema propre experience sur une application Java d’environ 20000 lignes de code. Sans ar-chitecture de base, cette application est devenue progressivement ingerable avec pourconsequence 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 ferme aux modifications et ouvert a l’evolution. Pource faire, des modeles de conceptions ont ete definis afin de permettre au programmeurde concevoir des applications flexibles et qui peuvent faire face aux changements.

Les design patterns ou modeles de conception decrivent des organisations pratiquesdes classes d’objet. Ces organisations resultent souvent d’une conception empirique,le concepteur objet tente de faciliter la reutilisation et la maintenance du code. Onpeut donc concevoir un modele d’application comme une forme d’organisation transpo-sable a plusieurs applications. Ces systemes peuvent apparaıtre complexes aux debutantsvoire inutiles, il est pourtant tres important d’en connaıtre plusieurs et de les appliquersystematiquement (dans les cas reconnus comme pouvant evoluer). L’architecte objet seconstruit petit a petit un “panier” de modeles.

Les design patterns ne sont pas reellement normalises, mais on peut les decouper entrois grandes categories :

– Les modeles de creation : Ces modeles sont tres courants pour deleguer ad’autres classes la construction des objets. ex : le pattern Factory, le patternFacade.

– Les modeles de structure : Ces modeles de conception tentent de composerdes classes pour batir de nouvelles structures. ex : le pattern Adapter, le patternProxy.

– Les modeles de comportement : Ces modeles tentent de repartir les responsa-bilites entre chaque classe (l’usage est plutot dynamique). ex : Template, Iterator.Si on voulait faire un parallele avec UML, les deux premiers modeles seraient liesa des diagrammes statiques (de classes) alors que le dernier modele est davantagelie a un diagramme dynamique (de sequence).

2.6.2 Infrastructure d’execution offerte par JEE

Java Enterprise Edition (JEE) est une norme proposee par la societe Sun, portee parun consortium de societes internationales, visant a definir un standard de developpementd’applications d’entreprises multi-niveaux, basees sur des composants.

On parle generalement de “plate-forme JEE” pour designer l’ensemble constitue desservices-Application Programming Interface (API) offerts et de l’infrastructure d’execution.JEE comprend notamment :

– Les specifications du serveur d’application , c’est-a-dire de l’environnementd’execution : JEE definit finement les roles et les interfaces pour les applications

17

ainsi que l’environnement dans lequel elles seront executees. Ces recommandationspermettent ainsi a des entreprises tierces de developper des serveurs d’applicationconformes aux specifications ainsi definies, sans avoir a redevelopper les principauxservices.

– Des services, au travers d’API, c’est-a-dire des extensions Java independantespermettant d’offrir en standard un certain nombre de fonctionnalites. Sun fournitune implementation minimale de ces API appelee JEE Software Development Kit(SDK) . Dans la mesure ou JEE s’appuie entierement sur le Java, il beneficie desavantages de ce langage, en particulier une bonne portabilite et une maintenabilitedu code.

De plus, l’architecture JEE repose sur des composants distincts, interchangeables etdistribues, ce qui signifie notamment :

– qu’il est simple d’etendre l’architecture ;– qu’un systeme reposant sur JEE peut posseder des mecanismes de haute-disponibilite,

afin de garantir une bonne qualite de service ;– que la maintenabilite des applications est facilitee.

Les API de JEE

Les API de JEE peuvent se repartir en trois grandes categories :– Les composants. On distingue habituellement deux familles de composants :

– Les composants web : Servlets et Java Server Page (JSP). Il s’agit de la partiechargee de l’interface avec l’utilisateur (on parle de logique de presentation).

Figure 2.8 – Architecture d’une application Java entreprise

18

– Les composants metier : EJB. Il s’agit de composants specifiques chargesdes traitements des donnees propres a un secteur d’activite (on parle de logiquemetier ou de logique applicative) et de l’interfacage avec les bases de donnees.

Les services, pouvent etre classes par categories :

Les services d’infrastructures : il en existe un grand nombre, definis ci-dessous :– JDBC est une API d’acces aux bases de donnees relationnelles.– Java Naming and Directory Interface (JNDI) est une API d’acces 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 definissantdes interfaces standard avec un gestionnaire de transactions.

– JCA est une API de connexion au systeme d’information de l’entreprise, notam-ment aux systemes dits “Legacy” tels que les ERP.

– Java Management Extension (JMX) fournit des extensions permettant de developperdes 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’acces.– JavaMail est une API permettant l’envoi de courrier electronique.– JMS fournit des fonctionnalites de communication asynchrone (appelees 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 separer les couches suivantes :– La couche de presentation, correspondant a l’Interface Homme-machine (IHM).– La couche metier contenant l’essentiel des traitements de donnees. Cette couche

se base dans la mesure du possible sur des API existantes.– La couche de donnees, correspondant aux informations de l’entreprise stockees

dans des bases de donnees relationnelles ou dans des systemes d’information com-plexes.

2.6.3 Java et la programmation basee sur les evenements

Dans les applications Java, les evenements representent une information centraleautour de laquelle, des modeles ont ete developpes pour en assurer la gestion et letraitement. L’idee de base etant de separer les composants et de leur permettre decommuniquer entre eux via des evenements. Ainsi, on peut distinguer les emetteursd’evenements et les recepteurs d’evenements. Un composant X peut s’inscrire chez uncomposant comme etant interesse par un evenement alpha. Lorsque l’evenement alphase declenche au niveau du composant Y, le composant X recoit immediatement uneinformation decrivant l’evenement en question.

En Java, un evenement est un “message”, c’est-a-dire un objet qui transite d’unemetteur a un recepteur. La generalisation des references Java nous permet de faire in-terpreter ce que veut dire “transiter” : L’evenement est un objet construit par l’emetteur,et dont la reference est donnee de proche en proche jusqu’au recepteur. Un evenementJava est donc un objet. Une bonne comprehension de :

– La notion d’evenements ;

19

– De leur nature ;– De leur niveau d’abstraction ;– Des styles de traitement ;– De la qualite de services exigee.

permet de tirer les benefices de la programmation basee sur les evenements.

Clairement, il existe quatre elements de base pour la conception d’un noyau degestion d’evenements :

– L’evenement caracterise par un type et des attributs ;– L’emetteur (ou source) qui emet des evenements ;– Le recepteur qui s’abonne a des evenements et en recoit ;– L’aiguilleur (ou dispatcher) qui transmet les evenements d’un emetteur a plu-

sieurs recepteurs.La pattern Observateur/Observe, ainsi que d’autres design patterns, ont aide au

developpement de la fameuse architecture Model View Controler (MVC). Cette methodede conception consiste a distinguer trois entites distinctes qui sont, le modele, la vue etle controleur ayant chacun un role precis dans l’interface graphique.

L’organisation globale d’une interface graphique est souvent delicate. Bien que lafacon MVC d’organiser une interface ne soit pas la solution miracle, elle fournit souventune premiere approche qui peut ensuite etre adaptee. Elle offre aussi un cadre pourstructurer une application.

Dans l’architecture MVC, les roles des trois entites sont les suivants.

– Modele : donnees (acces et mise a jour)– Vue : interface utilisateur (entrees et sorties)– Controleur : gestion des evenements et synchronisation

Interactions

Les differentes interactions entre le modele, la vue et le controleur sont resumees parle schema de la figure suivante.

Figure 2.9 – Modele-Vue-Controleur

20

Il est a noter que les applications d’entreprise sont implementees afin de communi-quer avec les EJBs qui sont deployes sur le serveur applicatif. Dans cet environnementclient/serveur, le modele de donnees se trouve au niveau du serveur applicatif. Ce dernierheberge, entre autres, les connecteurs vers la base de donnees.

Du cote client, on trouve :– Les differentes vues (interfaces) utilisant des objets de “transfert” qui adaptent les

objets du modele. En effet, ces objets etendent les objets du modele en rajoutantdes attributs qui facilitent l’affichage, le rafraichissement, la manipulation, etc.

– Les controleurs gerent les actions des utilisateurs et veillent a la coherence desdonnees.

Figure 2.10 – Modele-Vue-Controleur dans une application JEE

Toujours dans ce mode de fonctionnement, l’acces aux composants responsables dutraitement de donnees (les EJBs) se fait en utilisant RMI (section 4.5.1) ou la normeWS. Cette derniere a eu un succes fulgurant ces dernieres annees, et ce principalementgrace au langage XML et le protocole HTTP. Par ailleurs, les entreprises ne disposantpas d’un systeme informatique assez fiable pour supporter l’ensemble des applicationsont commence a se diriger vers des fournisseurs IT capables d’heberger des serveursapplicatifs, des bases de donnee et autre. Ce concept qui fut appele Cloud Computingpermet aux entreprises de se concentrer sur la couche de presentation et d’utiliser lesysteme informatique du fournisseur pour implementer les couches inferieures.

La section suivante decortiquera les differents aspects qui touchent a ce concept.

21

2.7 Cloud Computing

2.7.1 Introduction

Informatique en nuage ou encore infonuagique. Ce sont les differentes traductionsque l’on peut trouver sur internet.

Il s’agit d’un nouveau concept qui est en train de se mettre en place petit a petitdans les entreprises. Le principe etant d’utiliser les capacites de calcul et de stockageoffertes par des parties tierces. Ainsi, tous les programmes et toutes les donnees sontdeplacees sur cette informatique en nuage qui est considere comme un reseau de calculcapable d’evoluer et d’offrir des ressources virtuelles sous forme de service (via internet)en fonction des besoins de l’utilisateur [7].

Generalement, Enterprise Service Cloud (ESC) offre des services qui agissent surtrois niveaux .

– Infrastructure as a Service (IAAS) : ou encore Hardware as a Service. Celaconsite a fournir toute une infrastructure informatique en tant que service. Ama-zon.com est un des plus grand fournisseurs pour ce type de services. AmazonElastic Compute Cloud (EC2) et Amazon Simple Storage Service (S3) sont uti-lises par plusieurs entreprise comme IBM, Oracle, MySQL Enterprise, etc. Dans cessystemes, le developpeur commence par creer une Amazon Machine Image (AMI)qui contient le systeme d’exploitation ainsi que tous les programmes dont il abesoin. Le rajout d’une nouvelle AMI a S3, la rend automatiquement disponibledans EC2. Le developpeur peut, ensuite, gerer toutes les ressources qui s’executentdans l’environnement informatique de Amazon [2, 3].

– Platform As A Service (PAAS) : consiste a fournir des plates-formes infor-matique. Les developpeurs peuvent utiliser ces plates-formes pour deployer leursapplications sans devoir acquerir le materiel ou le logiciel utilise par la plate-forme.Google App Engine [5] est un exemple de plate-forme qui permet aux developpeursd’executer leurs applications web en utilisant l’infrastructure de Google. Cettederniere offre un support complet pour la creation, l’execution et la gestion desapplication web.

– Software As A Service (SAAS) : exploite les avantages de l’architecture SOApour fournir des services a travers internet.

Figure 2.11 – Tout comme service. X= ? [13]

22

2.7.2 SOCCA : Service Oriented Cloud Computing Architecture

SOA et l’informatique en nuage sont etroitement lies. En effet, SOA est un stylearchitectural qui permet de creer des solutions metier dont les composants peuvent etrereutilisables, tandis que l’informatique en nuage est un ensemble de technologies utilisepar des plate-forme tres flexibles au sein de l’architecture SOA de l’entreprise.

L’architecture Service Oriented Cloud Computing Architecture (SOCCA) peut etrevue sous forme de couches (figure 2.7.2) :

Figure 2.12 – Service Oriented Cloud Computing Architecture [13]

– Individual Cloud Provider Layer :Cette couche represente les differentes implementations constituant les nuages.Chaque fournisseur d’informatique en nuage dispose d’un centre de donnees quialimente les services fournis. De plus, chaque nuage doit avoir sa propre techno-logie de virtualisation. Le Dispacher fonctionne en parallete avec le moniteur demachines virtuelles afin d’allouer les ressources demandees. Ces ressources sontregroupees sous forme de services independants comme le service de stockage, leservice de calcul ou encore le service de communication. Ils disposent notammentd’interface open-standardise 1 qui permettent leur combinaison avec les servicesdes autres fournisseurs.

– Cloud Ontology Mapping Layer :Le role principal de cette couche est de cacher les differences parmi les fournisseursd’informatique en nuage. Elle peut aussi etre utile lors de la migration d’une

1. Open-source et utilisant des standards

23

application d’un nuage a un autre. Plusieurs systeme d’ontologie 2 doivent etrepresents au niveau de cette couche :– Ontologie du stockage :

Definit les concepts et les termes lies a la manipulation des donnees au sein desnuages (mise a jour, insertion, suppression de donnees, selection de donnees,etc)

– Ontologie du calcul :Definit l’ensemble des concepts et des termes lies au calcul distribue au niveaudes nuages

– Ontologie de la communication :Definit les concepts et les termes lies aux schemas de communication dans lesnuages ( schema d’encodage, routage des messages, etc)

– Cloud Broker Layer :Cette couche heberge les agents intermediares entre les fournisseurs d’informatiqueen nuage et la couche de SOA. Chaque Service du nuage est associe a un type deservice broker. Ce dernier s’occupe des taches suivantes :– Publication des informations venant des fournisseurs :

Chaque fournisseur publie ses specifications ainsi que des informations liees auprix. Ces donnees incluent, entre autres :Des informations sur le fournisseur : le nom de l’entreprise du fournisseur, sonadresse, son adresse web, etc.Des informations sur les ressources disponibles : Que ce soit des ressourcesde calcul, de stockage ou de communication, le fournisseur communique lesspecifications ainsi que la limitation concernant la ressource.Des informations sur les prix : Ces prix varient d’un fournisseur a un autre. Ilspeuvent aussi etre influences par les variations du marche.

– Classification :Les brokers s’occupent de la classification des ressources publiees. Les servicespeuvent etre classes selon plusieurs criteres parmi lesquels on peut citer : Leprix, la disponibilite, le niveau de securite, etc

– Provision des ressources en fonction de la demande :La meilleure facon pour repondre convenablement aux besoins de l’utilisateurconsiste a analyser son utilisation actuelle des ressources afin de predir et deprevoir ses exigences futures.

– SOA Layer :Cette couche reprend les memes fonctionnalites qu’une SOA traditionnelle.Certains framework existants tel que CCSOA et UCSOA peuvent etre integresau niveau de cette couche. Il importe de savoir que d’autres artefacts peuvent yetre publies et partages comme les templates, et en particulier les templates decollaboration, ainsi que les cas de test. Le registre des services est indexe pourchaque type d’artefact et organise suivant l’ontologie.La difference fondamentale entre la couche SOA de SOCCA et une SOA tradition-nelle est que les fournisseurs de services n’hebergent plus directement les servicespublies. Les services sont plutot publies sous forme de packages qui peuvent etrefacilement repliques et redeployes sur les differents environnements des nuages. Ledeveloppeur a aussi la possibilite de designer le nuage sur lequel sera deploye lepackage .

2. Ensemble structure des termes et concepts representant le sens d’un champ d’information

24

2.7.3 ISB : Internet Service Bus

Par “Informatique en nuage”, on entend le deplacement des programmes et desdonnees vers les nuages afin qu’elles puissent exploiter l’infrastructure du fournisseur aulieu de s’executer sur une machine locale.

Toujours dans le meme ordre d’idees, l’ESB peut monter dans les nuages. Le principeest relativement simple. Il s’agit de standardiser les mecanismes lies a l’ensemble destaches accomplies par le bus d’entreprises – pour les exposer sur Internet. On parle alorsd’Internet Service Bus (ISB) par analogie a l’ESB pour definir ce concept de middlewareoriente messages que l’on distribue via l’Informatique en nuage.

L’approche la plus simple pour implementer un ISB consite a activer les servicesde l’ESB pour qu’ils soient disponibles sur internet. Cette approche n’est pas tresinteressante car l’ISB, bien qu’il heberge des services qui sont accessibles via internetdoit permettre le deplacement de services deployes vers les nuages d’informatique. Lasecurite est un autre point qu’il faut prendre en consideration. Un utilisateur authentifiepour utiliser l’ISB doit pouvoir effectuer des communications securisees a travers tousles noeuds par lesquels ses messages vont transiter.

Microsoft et linxter ont ete les premiers a avoir implemente un ISB (respectivementBizTalk Services et linxter ISB). Plusieurs concepts doivent etre examines au niveau deces implementations :

– Le registre des services– Le nommage– L’identification et le controle d’acces– La connectivite

Le registre des services

Il s’agit d’un registre commun contenant l’ensemble des services heberges par l’ISB.Ce point central peut etre interroge par l’ensemble des services de mediation.

Le nommage

Les differents Services ou End Point Reference (EPR) doivent etre facilement iden-tifiables grace a l’utilisation de conventions de nommage comme l’Unique ResourceIdentifier (URI).

L’identification et le controle d’acces

Il importe de savoir quels mecanismes de securite seront mis en oeuvre(Active Direc-tory, OpenID, etc) et quelle methode d’identification/authentification sera utilisee pourchaque service.

La connectivite

L’ISB doit fournir des services de mediation tout en cachant les differents aspectslies a la communication. En plus de ces services, il doit s’occuper de l’acheminement desmessages aux services et ce, en exploitant les queues et les topics comme au niveau de

25

l’ESB. Comme explique plus haut, les URI sont utilises pour identifier les services. Ainsi,chaque application peut etre vue comme un ensemble d’URI, de regles et de fonctions.

Enfin, l’ISB permet de controler l’echange de messages en se basant sur l’URI del’emetteur et l’URI du recepteur.

Exemple d’implementation : Linxter ISB

La solution developpee par Linxter vise a offrir l’ISB en tant que PAAS et offreun SDK permettant de communiquer avec l’ISB. Ce dernier contient une collection deservices :

– Inbound Service : Manipule les messages qui sont envoyes par les instancesd’applications.

– Outbound service : Achemine les messages aux differentes instances (en attentede messages).

– Object store service : Manipule les attachements dans les messages.– Hostname sevice : Gere les adresses utilisees par les instances d’applications

pour l’appel des services.– Registration service : S’occupe de l’inscription des instances d’applications et

la generation des tokens.La figure 2.7.3 illustre la possibilite de creer plusieurs instances d’ISB, chacune

contient les services decrit ci-dessus. Le SDK de linxter fournit, en outre, les outilspermettant d’assurer la redondance ainsi que le load balancing entre ces differentes ins-tances.

Figure 2.13 – Linxter ISB [10]

Chapitre 3

Event Driven Architecture

3.1 Introduction

Dans certains entreprises, il est parfois necessaire de mettre en place des moyenspour detecter les evenements qui y sont en train de se produire et ainsi observer leurssymptomes [4]. Hier encore, un utilisateur m’a appele au travail pour me signaler queson application etait devenue trop lente au moment de la sauvegarde. Malheureusement,il m’a fallu 10 minutes de verifications pour me rendre que ce probleme etait du a unevenement qui s’etait produit bien avant que l’utilisateur ne commence a se plaindre.L’arret d’un serveur auxiliaire en etait la cause.

Le traitement automatise des evenements qui se produisent dans le monde reel peutrevolutionner notre facon de vivre. Dans la suite, nous allons citer quelques exemplesqui illustrent le besoin accru d’un traitement automatise des evenements.

– Un patient arrive dans un hopital et patiente dans la salle d’attente pendant unedemi heure pour etre recu par la secretaire qui s’occupe de son dossier. La secretairene sait pas qui est dans la salle d’attente et se base exclusivement sur les numerosde tickets pour appeler les patients. Or, Certains patients sont prioritaires parcequ’ils ont un rendez-vous, d’autres doivent passer par un autre bureau pour sevoir creer un dossier et un rendez-vous. Il serait interessant dans ce cas de detecterl’arrivee d’un patient (via une borne qui lit la carte d’identite electronique ou lacarte SIS du patient) pour pouvoir l’appeler au bon moment et essayer d’optimiserle temps d’attente. On pourrait imaginer un systeme qui recoit les notificationsd’arrivee des patients et cree automatiquement un dossier pour les patients quin’en ont pas un en se basant sur les informations de la carte electronique. Celaepargnerait beaucoup de temps a la secretaire et au patient,

– Les fraudes dans les institutions financieres sont souvent difficiles a detecter. Seulel’analyse des differents evenements qui se produisent au niveau de la banque etdans le systeme de trading permet de detecter les activites illegales. De meme, levol des numeros de carte visa ne peut etre detecte que si une analyse des differentsevenements ( achat sur internet, argent retire a la banque..) est effectuee en tempsreel. Ce genre de traitement d’evenements est appele “traitement predictif”,

– etc.

Naturellement, la technologie doit repondre a tous ces cas de figures en offrant dessolutions adaptees. Avant de s’attaquer a ce sujet, voici une classification des raisonsqui peuvent nous pousser a envisager le traitement automatise des evenements :

26

27

– La necessite d’un comportement temps reel dans les systemes informa-tiques. Cela implique implicitement la capacite d’adaptation dynamique des reactionsdu systeme face aux nouveaux evenements.

– L’observation d’un systeme dont le but de generer des alertes pour l’utilisateur.– La dissemination des donnees qui vise a diffuser l’information pour arriver au

bon consommateur, au bon moment et dans la bonne granularite.– Le diagnostic actif. Le but ici est d’utiliser des actions pour affiner le diagnostic.– Le traitement predictif dont le but est d’identifier les evenements avant qu’il

se produisent dans le systeme afin de les elimiter ou de changer leur effet.

3.2 Le concept

Dans le chapitre precedent, nous avons evoque la programmation basee sur lesevenements et son principe de decouplage de composants. Cette approche, qui est aussia la base de l’architecture IT basee sur les evenements, permet d’identifier et de reagirintelligement dans certaines situations.

EDA est un style architectural qui s’impose de plus en plus dans les entreprises. Paropposition a SOA ou un “fournisseur” rend un service a la demande d’un consommateur.En architecture EDA, un “service” previent par emission d’un evenement qu’il a realiseune operation donnee, ce qui permet de savoir l’avancement en temps reel des differentsprocessus utilisant ce service.

Il est a noter que SOA decortique 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 reside toute la difference avec l’EDA. En effet, les services ouagents de l’EDA envoient des requetes sous forme d’evenements sans se preocuper de leuracheminement (communication indirecte et asynchrone), ils ne sont pas censes savoir quiva recevoir l’information, ni comment elle sera manipulee. Ce sera a un autre composantde s’ocupper de la recolte et de la redistribution de ces evenements. Cela etant, il estpossible qu’un composant implemente les deux approches (SOA et EDA). Il peut alorsinteragir de maniere directe et synchone avec les autres composants tout en jouant lerole de producteur et de consommateur d’evenements.

La figure suivante donne une idee du fonctionnement general d’une EDA. Les sectionssuivantes decriveront ces differents composants.

Figure 3.1 – Architecture basee sur les evenements

28

3.3 Ses apports

Avant d’entamer la conception et le deploiement d’une EDA, il est important desavoir les caracteristiques et les qualites de ses composants et surtout de comprendrecomment ils peuvent fonctionner entre eux pour realiser les fonctionnalites desirees del’EDA.

L’objectif d’une telle architecture est tres simple : reagir intelligemment en fonctiondes evenements detectes dans le systeme. Ce type d’architecture peut etre utilise parexemple pour detecter et reagir aux vols des numeros de cartes VISA sur internet. Eneffet, si la banque centrale dispose d’une architecture EDA, elle peut facilement surveillerles flux d’evenements produits par les utilisateurs des cartes et essayer de trouver desanomalies (en se basant sur des regles predefinies). Une carte sera automatiquementbloquee si un retrait de 100 euros en Belgique est suivi d’un achat d’un article surinternet a partir de Malaisie.

3.4 Le contexte

Bien que cette architecture vienne toujours avec des changements positifs, elle n’estpas toujours la solution aux problemes des entreprises. Beaucoup de facteurs doiventetre examines afin d’evaluer les benefices et la faisabilite d’une telle architecture. Il s’agitnotamment de contraintes logiques d’applications, de contraintes sur les performances dusysteme, de defis de l’entreprise et surtout le rapport cout-rendement de l’investissement.

Une EDA est censee resoudre des problemes dans lesquels il existe differents fluxd’evenements provenant de differentes applications ou de systemes et ou il est necessaired’avoir un suivi en temps reel de tous les evenements et des actions declenchees par cesevenements.

3.5 Ses caracteristiques

3.5.1 Concentration des messages

Il s’agit ici de revoir sa vision de conception d’applications. Dans l’entreprise, certainsprocessus metier sont composes de plusieurs services orchestres pour obtenir le resultatfinal. L’exemple suivant illustre le cas d’un processus metier qui se deroule en quatreetapes.

29

Figure 3.2 – Exemple de processus metier-1 [1]

Un changement dans les fonctions de l’application necessite la modification du controleur.Dans la vision EDA, le controleur sera remplace par un concentrateur de messages. Cecirend les composants “pluggable” et facilite le rajout d’une nouvelle etape dans le pro-cessus metier.

Figure 3.3 – Exemple de processus metier-2 [1]

30

3.5.2 Decouplage lache

Lorsque nous parlons de Loose Coupling, nous designons un concept dans lequelles composants ne sont pas directement lies entre eux, ils sont lies de facon abstraiteen ayant chacun une connaissance des roles des autres composants. Un systeme est dit“Loose coupled” s’il est facilement extensible.

Si nous reprenons l’exemple de carte VISA, il existe aujourd’hui sur internet unservice (utilise par les vendeurs) qui permet de verifier la validite d’une carte VISA. Cedernier recoit un numero compose de 16 chiffres, une date d’expiration et un code deverification.

Verifier un nouveau type de carte bancaire ne doit pas necessiter la modification duprogramme, une nouvelle compilation, une modification du cote du client, etc. Autrementdit, le composant doit etre complement configurable, adaptable en fonction du contexte,independant du reste du systeme et il ne doit en aucun cas resister aux changements.Cela facilitera de maniere significative la maintenance du service.

Il est aussi important lors de la conception du composant, de penser a l’utilisationde patterns comme le “adapter pattern” qui permet de modifier le comportement d’unobjet 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 (recepteur) ne doivent pas etre disponibles en meme temps ; l’emetteurinteragit avec le serveur de messagerie au cours d’une transaction locale et ignore si lesparties interessees par son message sont disponibles au moment de la transaction.

La relation publish-and-subscribe est une relation one-to-many. Les consommateursdoivent s’inscrire pour un topic (Sujet) dans lequel le producteur va faire des pu-blications. Ainsi chaque consommateur inscrit pour un topic recoit les messages quiconcernent ce dernier.

3.5.4 Exploitation des evenements

Les informations concernant l’etat du processus metier doivent etre stockees dansl’evenement. Ceci permettra a chaque composant de l’EDA de rester au courant del’avancement du processus.

Il est a noter qu’un modele de donnees commun doit etre etabli pour les evenements.Pour ce faire, un ensemble de transformateurs doit etre developpe pour assurer la conver-sion des messages. Ainsi, un seul format de message sera manipule par la systeme demessagerie interne de l’EDA.

Toujours dans le meme sens, les types d’evenements doivent etre facilement identi-fiables. Il est important de definir une hierarchie pour les noms d’evenements ainsi quedes dictionnaires d’evenements dans lesquels doivent etre repertorie tous les evenementssusceptibles d’etre declenches dans l’EDA.

31

3.5.5 Transport des messages

Comme decrit ci-dessus, la messagerie asynchrone represente l’epine dorsale de l’EDA.Le systeme de messagerie doit pouvoir vehiculer des millions de messages. Des compo-sants comme l’ESB ou une Queue peuvent etre utilises pour federer les evenements entreles producteurs d’evenements, les consommateurs d’evenements ainsi que les processeursd’evenements .

Figure 3.4 – ESB comme Event Collector

3.6 Ses composants

3.6.1 Notion d’evenement

Un evenement peut etre tout ce qui arrive a l’interieur ou a l’exterieur de l’entreprise.Il doit contenir suffisament d’informations sur le fait qui vient de se passer. Chaqueevenement est compose d’une entete et d’un corps. L’entete etant utilisee pour renseignersur l’id de l’evenement, son type, sa date/heure, son createur, etc. Elle sera lue par lesintermediaires par lequels l’evenement va transiter. Le corps de l’evenement decrit endetail 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 gere les communications. C’est cettepartie-la qui permet aux composants de communiquer entre eux.

3.6.3 Producteurs d’evenements

Represente la source des evenements. Cela peut etre un ordinateur ou tout autre ap-pareil capable de communiquer. Les fournisseurs peuvent fournir des API qui permettentde communiquer facilement avec l’equipement en question.

32

3.6.4 Consommateurs d’evenements

Il s’agit des modules ou des applications qui sont interessees par les evenements. Leconsommateur d’evenements utilise l’outil de messagerie pour recevoir les evenements.Pour ce faire, il doit s’inscrire pour un type specifique d’evenements.

3.6.5 Processeurs d’evenements

Ces composants, appeles aussi agents ou Event Processor Agent (EPA) s’occupentdu traitement intermediare des evenements.

Il existe plusieurs styles de traitement :– Simple event processing– Event stream processing– Complex event processingIl faut noter que plusieurs EPA peuvent collaborer pour assurer le traitement des

evenements, on parle dans ce cas de reseau de traitement d’evenements. Dans un mondesimpliste, les EPA s’occuperaient simplement de la transmission des evenements entreproducteurs et consommateurs. Dans la realite, il faut prevoir des filtres et des outilspour la transformation et le routage des evenements. Ci-dessous la liste des types d’agentqui peuvent etre employes dans une architecture basee sur les evenements.

– Les agents simples : Ce sont tous les agents reutilisables qui s’occupent de lareception des evenements, du traitement de l’information ainsi que du renvoi desevenements vers leurs destination. Par traitement, nous entendons des operationsde transformation, de persistance ou toute autre operation faisant appel aux seulescompetences de l’agent.

– Les agents d’infrastructure : Ces agents sont utilises pour gerer, controler etsurveiller l’environnement EDA. Leur role est d’attendre qu’une situation par-ticuliere se realise pour se reveiller. Ils peuvent alors engager des actions ou secontenter de surveiller de pres ce qui les interessent ( exception, evenement, etc)

– Les agents du domaine : Leur role est de fournir des implementations specifiquesau domaine. Ils sont rarement reutilisables et sont generalement construits pourexecuter un travail temporaire.

L’ensemble de ces agents est deploye au niveau de l’outil de messagerie dans lequelplusieurs bus de messagerie peuvent etre mis en oeuvre.

3.7 Son fonctionnement

3.7.1 La production des evenements

Dans la section precedente, nous avons parle du principe de decouplage lache 1 ainsique de ses implications au niveau de l’architecture basee sur les evenements. Nous avonspu identifier l’ensemble des entites qui agissent sur les evenements et les classer danstrois grandes categories :

– Producteur d’evenements.– EPA ou agent de traitement d’evenements.

1. Loose Coupling

33

Figure 3.5 – Illustration d’une instance d’un reseau de traitement d’evenements [4]

– Consommateur d’evenements.

Lorsque l’on parle de producteur d’evenements, il est important de distinguer les differentsaspects de ce concept. Un producteur d’evenements peut etre soit :

– Un type abstrait de producteurs d’evenements comme “capteur utilisant latechnologie Radio Frequency IDentity (RFID)”.

– Une collection d’instances de producteurs du meme type. Il est important dansce cas de se concentrer sur l’ensemble des instances comme etant une seule classede producteurs d’evenements. Ainsi, on peut trouver dans un magasin une classequi regroupe tous les capteurs RFID de marque KRONOS.

– Une instance particuliere d’un producteur lambda. Nous pouvons prendre pourexemple, un capteur RFID integre dans un autre equipement.

Naturellement, il est plus evident de gerer des classes de producteurs que de traiterles differentes instances une a une, d’autant que le nombre de producteurs d’evenementspeut varier quotidiennement. Une maniere tres simple de modeliser les differentes classesde producteurs serait de definir les elements suivants pour chaque classe :

– Les details du producteur : La categorie du producteur d’evenements, l’iden-tifiant du producteur d’evenements, les differentes fonctionnalites offertes par leproducteur d’evenements (possibilite de faire des annotations ou d’interrogationavec des requetes, etc)

– Le flux final sortant : Il s’agit principalement des types d’evenements quipeuvent etre produits et de leurs destinations.

– La relation avec les autres producteurs d’evenements : Elle est soit unespecialisation ou une generalisation. Rappelons qu’une classe de producteurs d’evenements

peut specialiser une autre classe de producteurs d’evenements. Nous pouvons diredans ce cas-ci que la classe mere represente une generalisation des sous-classes.

34

Jusqu’ici, nous avons vu les differents aspects qui caracterisent les producteursd’evenements et nous avons decrit les differents elements de definition qui permettentde distinguer les classes de producteurs d’evenements. Nous allons maintenant classerles producteurs d’evenements en fonction de leur nature :

– Producteurs hardware qui peuvent etre des equipements medicaux, des appareilsde gestion, des applications de securite ou meme des applications militaires, etc.

– Producteur agissant en fonction de l’interaction humaine. Dans ce cas, les evenementssont generes suite a une interaction humaine avec une interface graphique ou autre.

– Producteur software simulant des capteurs ou des detecteurs.Encore une fois, lorsque nous voulons interagir avec un producteur d’evenements et

pour etre le plus efficace possible, des patterns d’interaction peuvent etre choisis parles concepteurs du producteur d’evenements. Ceci facilitera son integration dans unearchitecture basee sur les evenements.

3.7.2 La consommation des evenements

Le consommateur d’evenements est le complement logique du producteur d’evenementsqui a ete detaille dans la section precedente. Il est represente par un noeud qui disposeuniquement d’un port d’entree et peut aussi etre defini selon trois aspects :

– Un type abstrait de consommateurs d’evenements.– Un ensemble de consommateurs d’evenements de meme type.– Une instance singuliere d’un consommateur d’evenements.De meme que dans la production des evenements, plusieurs elements de definition

peuvent etre utilises pour distinguer les differentes classes de consommateurs d’evenements.La figure [?] resume l’ensemble de ces elements. Nous pouvons y remarquer l’absencede la possibilite de “quering” ou d’interrogation via des requetes au niveau du consom-mateur. Le rajout de filtres permet de controler le flux entrant au consommateur.

La derniere classification possible est celle qui se base sur la nature des consom-mateurs d’evenements. Ici, elle donne exactement le meme resultat que celui percu auniveau des producteurs d’evenements. De cette facon, on distinguera trois categories :

– Consommateur hardware : parmi les actions qui peuvent etre realisees par cegenre de consommateurs, on peut citer :– Verouillage et deverouillage de portes.– Ouverture et fermeture de barrieres.– Controle du niveau de l’eau dans une piscine.Notons qu’un consommateur d’evenements de type hardware peut etre integredans un autre equipement qui peut disposer,en outre, d’un producteur d’evenements.Il est important dans ce cas de bien separer logiquement la production et laconsommation d’evenements.

– Consommateur agissant en fonction de l’interaction humaine. Dans ce genred’utilisation, le role du consommateur d’evenements est d’alerter l’utilisateur afind’attirer son attention. Il peut aussi reporter des informations qui sont moinsinteressante pour l’utilisateur ou rafraıchir l’information affichee sur l’ecran.

– Consommateur Software : cette famille de consommateurs doit exclusivementetre integree dans un software et n’offre aucune interface graphique. ex : Dansun systeme de vente par internet, un consommateur d’evenements de type “paie-ment effectue” doit lancer la procedure de livraison a domicile des la reception del’evenement.

35

3.7.3 Le traitement des evenements ou Event processing

Le traitement des evenements reste le concept central de l’Event Driven Architecture.En effet, C’est via cette entite que transite les evenements venant des producteurs etqui doivent etre traites par ce composant. Des actions peuvent alors etre executees enfonction de ces evenements.

EPN : Event Processing Network

Souvent, nous parlons de reseau de traitement d’evenements lorsque plusieursagents de traitement d’evenements sont mis en oeuvre (figure 3.7.3).

Il existe plusieurs facons pour concevoir un reseau de traitement d’evenements. Eneffet, l’implementation est differente selon que le reseau soit gere par une seule entitecentrale ou que chaque unite de traitement (ensemble d’EPA) dispose d’un module degestion. Le role des agents peut etre :

– Le filtrage d’evenements.– Le matching en fonction de patterns predefinis.– La derivation de nouveaux evenements en fonction des evenements recus.

CEP : Complex Event Processing

Le Complex Event Processing (CEP) est un style de traitement qui vise a analyserles flux d’evenements afin de detecter des modeles d’evenements (ou patterns).

Figure 3.6 – Elements de definiton pour les consommateurs d’evenements

36

A l’heure ou les infrastructures temps reel permettent de relever les grands defis quipreoccupent les dirigeants d’entreprise. Le traitement complexe des evenements permet,en outre, de garantir une visibilite temps reel des activites de l’entreprise. Cette techno-logie aide les entreprises a gerer plus efficacement le risque, mais aussi a prevenir toutesles anomalies.

Voici quelques exemples qui illustrent les avantages d’une telle approche :

– Un technicien est envoye chez un client, et ce dernier annule la commande. Aumeme moment, un autre client situe a proximite passe une commande. Le techni-cien est reoriente de maniere dynamique vers ce nouveau client.

– Les utilisateurs d’un site Web se voient proposer de maniere proactive des menusd’achats et d’encheres en fonction de leur historique de navigation, qui represententleurs comportements specifiques vis-a-vis du site Web et de son contenu.

– Une carte bancaire VISA qui est utilisee pour retirer de l’argent en Belgique estbloquee si quelques minutes plus tard elle est utilisee pour faire un achat surinternet a partir d’un pays d’Afrique.

Une solution CEP doit pouvoir evoluer pour gerer au mieux les volumes elevesd’evenements. Elle doit fournir un environnement visuel permettant d’analyser les evenementsafin d’en extraire les patterns et les causes profondes.

Les composants de base qu’on trouve dans un systeme utilisant CEP sont :

– Les canaux : utilises pour acheminer les evenements.– Le moteur : permet d’executer les traitements.– Des modeles ou des patterns peuvent etre definis en se basant sur :

– Un contexte : determine les limites de la selection (temps, espace, entites).– Un pattern d’evenements : filtre, pattern matching, etc.– Un ensemble de predicats.

Figure 3.7 – Illustration d’une EDA qui utilise un reseau de EPA [4]

37

– Un ensemble de regles pour la gestion des chevauchements de contextes.

L’objectif du CEP est de fournir une fonction de prise de decision qui resolve lesdefis tactiques (specifiques a chaque scenario), en temps reel et dans un contexte precis(historique des evenements, priorite et circonstances).

CEP et processus metier

Lorsque nous observons de plus pres un processus metier, nous decouvrons un grandnombre d’evenements lies et non lies diriges par des delais et des resultats definis. Lesconditions et les influences operationnelles externes des processus metier, les exigences del’instanciation et de l’orchestration dynamiques des processus dependent uniquement dela gestion d’une serie d’evenements complexes a partir d’un contexte, d’une sequence etd’un resultat. Grace a EDA, le role du CEP vis-a-vis des processus metier operationnelsdevient un element indispensable pour l’optimisation des performances des processuset le diagnostic individuel. Pour ce faire, une attention particuliere doit etre portee aumoment de la definition des processus metier. En effet, plus le processus metier estdecoupe en sous-processus metier, plus les evenements deviennent precis et tres utilespour l’EDA. l’exemple suivant illustre cela.

Nous avons le choix entre trois options de conception qui mettront en jeu deuxprocessus metier : “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) auprocessus “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’evenement “paiementRecu”– Le service de gestion de stock etant inscrit pour recevoir les evenements lies au

paiement recoit une nouvelle notification.Le concepteur doit faire son choix de conception en fonction des besoins en termes

de notifications. Il reste toujours preferable de bien separer les processus metiers et nepas les lier entre eux via des appels directs qu’en cas de necessite absolue.

CEP et BPM

Comme explique plus haut, le fonctionnement du CEP est etroitement lie aux pro-cessus metier. Ces derniers generent un ensemble d’evenements metier qui est in-tercepte a la fois par le BPM (Business Process Management) et par le CEP . Nouspouvons reprendre l’exemple du processus metier : vente de produits sur internet(figure 2.2), la reception du paiement d’une facture est censee declencher l’evenement

38

metier : “paiementRecu”. Ce dernier sera recu par le BPM qui cloturera la procedured’achat et entamera eventuellement d’autres processus metier lies a ce processus.

Ce meme evenement “paiementRecu” fera partie du flux d’evenements qui sera ana-lyse par le CEP. Ici, la tache principale est de trouver une correspondance aux patternspredefinis, detecter les instances de patterns concernees et enfin lancer la reponse ap-propriee.

Malgre cette quete commune, a savoir l’interception des evenements en vue dedeclencher des actions, il demeure que la personne qui va utiliser un BPM pour lagestion de son entreprise verra le processus metier “vente d’un produit sur internet”comme une transaction englobant plusieurs sous-processus metier[4] tandis que la per-sonne qui s’occupera de la definitions de patterns pour le CEP le verra seulement commeun evenement metier.

Les specialistes constatent aujourd’hui une convergeance entre ces deux outils (CEPet BPM) [11] et rajoutent dans ce sens que les processus metier n’utilisent certainementpas les evenements pour la meme raisons qu’un producteur d’evenements dans une EDA.Neanmoins, l’EDA peut tres bien profiter de ce flux d’evenements supplementaire pouraccomplir au mieux sa tache.

Pour conclure cette section, il faut dire que l’architecte ou le developpeur qui s’occupedu CEP ne doit pas se limiter au concept d’evenement. Au dela de ca, il faut savoir definirles entites qui seront basees sur les evenements et determiner les exigences architecturalesde chacune. Dans certains cas, une implementation complete d’une EDA ne sera pasnecessaire.

3.8 Choix d’une solution

Naturellement, et lorsque le budget le permet, les entreprises adoptent une suiteEDA commerciale dans laquelle elles integrent leurs applications. Toutefois, ce choix lesrend completement dependantes des modules proprietaires qui composent cette architec-ture. Les developpeurs travaillent dans les limites de la solution et se voient contraintsd’acheter de nouvelles fonctionnalites, adaptateurs, licences, etc.

Les solutions Open-source, quant a elles, permettent d’eviter ce genre de “blocage”.Cependant, l’entreprise reste toujours dependante de la volonte du developpeur et del’architecte qui sont a l’origine de la solution lorsqu’il faut l’etendre ou la maintenir.

Aujourd’hui, pour attirer les entreprises, certains fournisseurs offrent conjointementune solution Open-Source et des services payants pour la validation, la maintenance etl’amelioration des differents elements du framework. Ainsi, l’entreprise pourra modifierla solution et compter sur le fournisseur en cas de probleme.

3.9 EDA vs SOA

Aujourd’hui, les experts certifient que l’approche SOA est la meilleure approche pourles futures architectures de developpement. Cependant, la question qu’il faut se poser,c’est de savoir si la SOA est implementee de la bonne maniere et si elle va tenir a longterme. Encore faut-il savoir comment une architecture SOA peut etre integree dans unearchitecture basee sur les evenements (EDA).

39

Il existe deux manieres de concevoir le lien entre SOA et EDA. Dans la premierevision, la SOA represente la maniere dont les actions sont executees. Nous avons vu dansle chapitre precedent qu’il etait possible de definir des regles au niveau de l’entite quitraite les evenements. Des actions peuvent etre declenchees lorsque les conditions de cesregles sont verifiees. Pour cela, nous pouvons faire appel aux services de la SOA.

Nous pouvons dire dans ce cas que l’EDA complete SOA car les services peuventetre actives par des triggers que sont les evenements [6].

Il importe ici d’insister sur la difference entre le pattern request-and-reply utilise parSOA et le pattern publish-and-subscribe utilise par EDA. Ceci rend SOA plus adapteedans la decomposition des fonctions metier tandis que EDA est utilisee dans la gestiondes evenements metier.

Figure 3.8 – Composants de l’EDA + SOA

Une autre facon de concevoir les choses serait de considerer chaque element de l’EDAcomme un service au sein de la SOA.

Figure 3.9 – Services de la SOA

40

3.9.1 Le parallelisme au sein de l’EDA

La nature de l’EDA favorise la decomposition et la reutilisation des composants. Cesderniers vont generer des flux d’evenements paralleles qui doivent etre traites en tempsreel.

Parmi les questions que le concepteur de l’EDA doit se poser, il y a :

– Comment ces flux vont-ils etre vehicules aux composants responsables de leurtraitement ?

– Quelles sont les nouvelles contraintes et exigences ?

3.10 Implementation

Aujourd’hui, pour implementer une EDA avec des Web services, il est necessaire deprevoir un certain nombre d’outils pour que l’EDA puisse manipuler les messages SOAPde la SOA . En revanche, les web services de la SOA peuvent etre deployes sur n’importequelle infrastructure reseau pourvu qu’elle dispose de la couche HTTP. C’est d’ailleurscette propriete qui explique la monte en puissance de la SOA ces dernieres annees. Notonsqu’en plus, les infrastructrures ESB (Enterprise Service Bus) permettent de manipuleraisement les files de messages en les combinant avec les web services. C’est pour cetteraison la que les differentes implementations d’ESB sont de plus en plus utilisees dansla conception des solutions combinant EDA et SOA [12].

Par ailleurs, l’evolution des standards de web services comme WS-Eventing, WS-Notification, WS-MetadataExchange, WS-ReliableMessaging, WS-Security, WS-Choreography,et beaucoup d’autres, combinee avec l’utilisation accrue des ESB poussent les concep-teurs de systemes d’exploitation a integrer certaines fonctionnalites d’ESB dans leursproduits.

Notons que l’implementation de SOA et EDA doit etre faite tout en considerantle BPM. Les outils offerts par ce dernier sont principalement bases sur Business Pro-cess Execution Language (BPEL). Dans sa version actuelle, BPEL est essentiellementbase sur le modele command-and-control ainsi que sur l’orchestration des services. L’or-chestration supporte aussi les workflow et un autre type de choregraphie qui s’ap-proche d’EDA. Cependant, BPEL reste un langage procedural qui necessite le moteur decontrole de BPEL. Ceci constitue un handicap pour assurer le loose coupling d’EDA etne constitue pas un probleme dans le cadre de SOA. En effet, EDA fonctionne idealementavec un model declaratif (BPEL est un langage procedural). Dans ce type de modele, leconcepteur peut facilement connecter des producteurs a des consommateurs.

Idealement, l’execution des implementations doit etre independante du moteur ducontrole, elle doit etre plutot basee sur les standards de web service mentionnes ci-dessus. Il est evident 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’uti-liser d’autres alternatives d’ESB basees sur SOAP. En creant une solution basee surdes normes communes ainsi qu’une implementation utilisant des technologies standardscomme les web services, le systeme promet d’etre robuste, evolutif.

41

3.10.1 Collection des evenements

Pour revenir a notre premier schema illustrant le fonctionnement d’une EDA, lapremiere entite qui concentre les evenements est appelee “Event Collector”, son roleest de collecter les evenements venant de sources differentes afin d’en standardiser lecontenu.

Aujourd’hui, les ESB comme les implementations de JMS sont vraiment adapteespour etre utilisees comme un conteneur d’evenements metier. Ainsi, tous les acteursde l’EDA peuvent s’inscrire comme consommateur d’evenements dans ce “dataspace”global qui utilise des technologies standards comme le HTTP, FTP, XML, etc.

La figure suivante montre une implementation d’EDA utilisant un Enterprise ServiceBus pour collecter les evenements metier publies par deux producteurs d’evenements.Les gateways deployes au niveau de l’ESB jouent le role de consommateurs d’evenementset s’occupent de la transformation de son contenu afin qu’il puisse exister un seul typed’evenement interne a l’ESB.

Figure 3.10 – Exemple d’implementation d’EDA utilisant un ESB

3.10.2 Traitement complexe des evenements

Les differents moteurs de CEP qui existent sur le marche acceptent en entree unflux d’evenements provenant idealement d’un Event Collector. L’utilisation de l’EventCollector permet de standardiser et de preparer le contenu des messages afin qu’ilspuissent etre directement analyses par le moteur CEP. Les consommateurs d’evenementspeuvent aussi s’incrire au niveau de cette entite pour recevoir les evenements qui lesinteressent.

Caracteristiques generales

Les solutions CEP se caracterisent par :

42

– Un traitement continu d’une masse considerable (plusieurs centaines de millierspar seconde) d’evenements provenant de sources d’information differentes.

– Un besoin de prise de decision en temps reel par rapport a un ensemble d’evenementsquelconque surgissant dans une fenetre temporelle definie. (de quelques secondes,a quelques heures, voire quelques jours)

Notions importantes

Une regle est de la forme “SI ANTECEDENTS ALORS CONSEQUENTS”.

– ANTECEDENTS : representent les premisses, souvent une conjonction de condi-tions, parfois des negations ou des disjonctions.

– CONSEQUENTS : representent des actions a envisager. Souvent l’ajout denouveaux faits, toujours sous forme de conjonctions.

Dependance entre les evenements

Il peut y avoir plusieurs types de dependances entre les evenements :– Dependance basee sur la sequence :

Si quelque chose s’est produit avant cet evenement, le bloc d’interaction a la valeurvraie.

– Dependance basee sur la repetition :Si quelques chose s’est produit un certain nombre de fois avant cet evenement, lebloc d’interaction a la valeur vraie.

– Dependance basee sur le temps :Si quelques chose s’est produit dans une periode avant cet evenement, le blocd’interaction a la valeur vraie.

Moteur d’inferences

Le principe d’un moteur d’inferences est de permettre la deduction de faits grace ad’autres faits. Pour cela il faut partir d’une liste de regles qui vont permettre d’effectuercette deduction.

Le but est de simuler une deduction humaine avec des faits et des regles.

Pattern Matching et Algorithme de RETE

L’algorithme de RETE etablit un reseau de nœuds, ou chaque nœud (excepte laracine) correspond a un modele se produisant dans le � cote gauche � d’une regle (soitla condition ou la premisse). Chaque chemin reliant la racine a un nœud externe(appeleaussi feuille) definit un � cote gauche � complet de regle. Chaque nœud dispose d’unememoire des faits qui satisfont ce modele. Cette structure est essentiellement un trigeneralise. Lorsque de nouveaux faits sont affirmes ou modifies, ils se propagent le longdu reseau, annotant les nœuds quand les faits correspondent au modele. Losqu’un faitou une combinaison des faits satisfait tous les modeles d’une regle donnee, un nœudexterne (leaf node) est atteint et la regle correspondante est declenchee.

43

Filtrage et resolution des conflits

Lorsque les evenements arrivent au niveau du CEP, plusieurs conflits peuvent avoirlieu a cause des evenements qui satisfont plusieurs regles.

La strategie suivante est utilisee pour la selection des regles compatibles (si il y ena) parmi les regles qui doivent etre declenchees.

– Elimination des regles utilisees pour une meme donnee (voire toutes les regles quiont ete declenchees recemment) pour ainsi eviter les boucles.

– Utilisation des donnees les plus recentes (exploration en profondeur).– Utilisation des regles les plus specifiques : celles qui possedent le plus de conditions

sont preferees aux regles generales.– Utilisation d’algorithme utilisant le moteur d’inference.

Exemple d’utilisation

Supposons qu’on souhaite surveiller la vente et la livraison de produits sur intenet.Supposons aussi que certains produits soient sensibles a la chaleur et qu’ils doivent etrelivrer dans des conditions speciales. Le plus important ici est que le produit soit livredans les meilleurs delais et avant sa date d’expiration. Durant le transport et le stockageintermedaire, les produits peuvent etre exposes a des conditions de chaleur, ce qui risquede les endommager.

Notre architecture basee sur les evenements va englober l’ensemble des processusqui sont lies a cette transaction, a savoir la vente d’un produit sur internet. Depuis lepremier processus d’achat et jusqu’a la livraison, tous les evenements sont collectes ettraites par le CEP avant de detecter des anomalies de fonctionnement.

Imaginons maintenant que l’administrateur du systeme veuille savoir pourquoi lalivraison du produit X n’a pas pu avoir lieu le 11.07.2010. Il doit alors traduire cela dansune requete contenant l’ensemble des donnees dont il dispose : “Destinataire”+produitX+“11.07.2010”+ ECHEC. Tous les evenements lies a ce processus vont alors s’afficher.L’utilisateur pourra alors, toujours au niveau du CEP, encoder d’autres requetes poursavoir la cause exacte du probleme. Supposons que le probleme de livraison est du autransporteur qui n’avait pas le support necessaire pour transporter ce genre de produit.

Une autre requete peut donner le nombre de livraisons infructueuses qui ont eteeffectuees par ce transporteur. Si le reponse revele un nombre important de problemescauses par ce transporteur, l’administrateur peut immediatement interroger le CEP afinde determiner si d’autres livraisons “sensibles” seront effectuees par ce meme transpor-teur. Le CEP peut tres bien l’informer que ce transporteur est en train de charger unelivraison depuis 2 min et qu’il s’apprete a quitter le stock. A ce moment-la, l’adminis-trateur peut contacter le responsable du stock et annuler cette livraison.

Ce systeme permet aux dirigeants de controler le comportement du systeme en tempsreel et les aide a prendre les bonnes decisions.

3.10.3 Les Actions

Le moteur de CEP doit declencher des actions lorsque cela est necessaire. Un evenementsurveille 2 peut declencher differents types d’action. Pour ce faire et vu qu’on est cense

2. Par des regles predefinies au niveau du CEP

44

etre dans une architecture qui combine EDA et SOA, il serait important de profiter desservices deja disponibles au niveau de SOA.

Toutes les actions peuvent etre realisees en faisant appel aux services de SOA(alarmes, processus metier, generation d’un nouvel evenement, etc). Ces actions doiventelles memes generer des evenements pour notifier le reste du systeme.

Figure 3.11 – Utilisation de SOA pour executer les actions

Dans la suite quelques consignes concernant la realisation de la partie SOA.

Definir une strategie a long terme

Une SOA reussie necessite une strategie a long terme qui facilite les ameliorations.Il est important que cette strategie a long terme soit en accord avec les objectifsstrategiques de l’entreprise. Dans le meme sens, il est primordiale de definir des reglespour la conception et le deploiement des web services. Des patterns (Facade, Delegationpattern..) peuvent etre utilises pour creer une couche d’abstraction.

Rappelons que chaque service de la SOA doit pouvoir etre reutilise dans d’autrescontextes.

Eviter la mauvaise granularite d’un service

Nous entendons par mauvaise granularite qu’un service couvre trop ou trop peu defonctionnalites. Une mauvaise granularite de services dans une SOA peut conduire a :

– de mauvaises performances.

45

– de faibles capacites de reutilisation.– des services sans valeur ajoutee metier.

Valeur metier

La valeur metier doit etre le facteur majeur au moment de la conception du ser-vice. Le concepteur doit fournir en plus de la documentation technique, une descriptiondetaillee des fonctions metier remplies par le service.

Decouplage du format de stockage

Une couche d’acces aux donnees est chargee de dialoguer avec les bases de donnees,en executant sur celles-ci des requetes de consultation ou de modification.

Souvent, le code contenu dans la couche d’acces aux donnees est etroitement lie ala base de donnees utilisee. Par exemple, une couche d’acces aux donnees prevue pourOracle ne sera pas compatible avec SQL Server ; de la meme maniere, une couche d’accesaux donnees prevue pour stocker des donnees au format XML ne pourra etre utiliseetelle quelle pour stocker des donnees dans un annuaire LDAP.

Afin de garantir l’independance entre les couches, il convient de mettre en œuvre unmecanisme d’abstraction pour eviter que la couche d’acces a la base de donnees ne soitconcue specifiquement pour une implementation particuliere.

Services et processus metier

Les services sont definis pour supporter les processus metier. Tout au long des pro-cessus, differents services seront necessaires pour faciliter le traitement et la logiquemetier. Il est primordial de comprendre les processus metier pour definir les services.

Lorsqu’il s’agit de concevoir une SOA, le defi consiste a creer un jeu de servicesutiles pouvant supporter le modele metier. Les services definis dans l’architecture nedeterminent pas les processus qu’on peut implementer. En revanche, les processus metierdefinissent les services dont ils ont besoin. De plus, un service seul ne suffit pas. C’estl’interaction entre les services qui cree l’implementation des processus metier, c’estpour cette raison qu’ils doivent egalement etre definis en termes de relations. Un pro-cessus utilisera rarement, voire jamais, un seul service. Par contre, il utilisera plu-sieurs services d’une multitude de facons. L’interaction entre les services est qualifieede choregraphie. Ainsi, une serie d’interactions choregraphiees est definie entre les ser-vices est la realisation de l’implementation des processus metier.

Composants d’une SOA

Une architecture de services est constituee de trois composants primaires. Le premierest le prestataire de services (le service reel). Vient ensuite le demandeur du service,autrement dit le composant qui accede au service. Enfin, l’agence de services fournit desservices de decouverte et d’enregistrement.

46

– Prestataire de services :Un prestataire de services est la source de la fonctionnalite des services. Un pres-tataire publie un contrat d’interface 3 utilise par les demandeurs pour acceder auservice. Le contrat definit ce que fait le service et comment y acceder.

– Demandeur de service :Le demandeur est le client d’un service. Il utilise l’agence pour decouvrir quelsservices sont disponibles. Une fois un service localise, le demandeur extrait lecontrat d’interface correspondant de l’agence. Le client utilise le contrat d’interfacepour comprendre comment acceder au service.

– Agence de services :Une agence de services 4 est un registre des services disponibles. Chaque prestatairepublie son contrat d’interface a l’agence, avec les informations a utiliser pourlocaliser le service. Le demandeur recherche les services appropries dans l’agenceet extrait le contrat d’interface correspondant.

Resume des objectifs d’une architecture SOA

– La reutilisation et la composition, permettant le partage de modules entreapplications et les echanges inter-applicatifs ;

– La perennite, qui implique notamment le support des technologies existantes eta venir ;

– L’evolutivite, car toute application est vivante, a une certaine duree de vie, peutse voir greffer de nouveaux modules et doit pouvoir repondre aux nouveaux besoinsfonctionnels ;

– L’ouverture et l’interoperabilite, pour partager des modules applicatifs entreplates-formes et environnements ;

– La distribution, pour pouvoir utiliser ces modules a distance et les centraliserau sein de l’entreprise par exemple ;

– La performance, avec en priorite l’accent mis sur la montee en charge.

3. Les contrats de type WSDL sont un exemple de contrat utilise dans le cadre des web services.

4. L’Universal Description Discovery and Integration (UDDI) est une agence de services ou un

repertoire universel de tous les services.

Chapitre 4

Outils et technologies

d’implementation

Dans ce chapitre, nous expliquons les differents outils et les differentes technologiesutilisees dans le developpement de l’application de gestion de la plate-forme temps reel.

4.1 MDA : Model Driven Architecture

Les methodes d’analyse et de conception d’applications d’entreprise ne sont plusce qu’elles etaient il y a quelques annees. En effet, si les languages de programmationn’ont pas cesse d’evoluer ces dernieres annees, certaines methodes de conception sontdevenues obsoletes et ne correspondent plus aux besoins des developpeurs. C’est pourcette raison la qu’une nouvelle demarche de realisation de logiciels appelee Model DrivenArchitecture (MDA) commence a gagner du terrain dans les entreprises.

Dans la demarche de conception actuelle, le developpeur commence par realiser lesdifferents diagrammes qui decrivent le fonctionnement interne de l’application. Il doitalors passer a l’etape de programmation au cours de laquelle il concoit l’ensemble desclasses qui composent l’application. Pendant cette meme etape, le developpeur doitpenser a la persistance des donnees et definir le schema de la base de donnee qui vaheberger les donnees de l’application. Au final, le developpeur se retrouve avec troismodeles qu’il est cense synchroniser en cas de modification : le modele UML, le modeled’objet et le modele de persistance.

L’objectif de MDA est tres simple : separer les specifications fonctionnelles desspecifications de son implementation sur une plate-forme donnee. Autrement dit, enpartant d’un modele metier independant de l’informatisation (CIM), une transforma-tion de celui-ci en Platform-Independent Model (PIM) et enfin la transformation dece dernier en modele specifique a la plate-forme cible (PSM) pour l’implementationconcrete du systeme. Les techniques employees sont donc principalement des techniquesde modelisation et des techniques de transformation de modeles.

4.1.1 Les modeles de bases

Dans la suite, une explication detaillee pour chaque type de modele

47

48

Figure 4.1 – PIM + PM = PSM

PIM : Platform-Independent Model

Ce modele est utilise pour decrire les traitements orientes metier. Il est independantde toute plate-forme contrairement aux differents modeles de conception et d’analysequi restent toujours dependant de la plate-forme d’execution comme JEE ou .Net.

PM : plateform model

Decrit l’architecture technique de l’application. Plusieurs PM peuvent etre utilisesdans un meme projet.

PSM : Platform Specific Model

Le modele de code ou de conception concrete PSM est le plus delicat de MDAcar le travail de generation du code se fait a ce niveau-la. MDA estime que le codede l’application peut etre obtenu a partir de modeles de code. La difference entre unmodele de code et un modele d’analyse ou de conception est que le modele de codeest lie a une plate-forme d’execution. Notons que le code de l’application se resume aune suite de lignes textuelles comme un fichier Java tandis qu’un modele de code estune representation structuree incluant, par exemple, les concepts de boucle, condition,instruction, composant, evenement, etc. L’ecriture de code a partir d’un modele de codeest une operation assez triviale.

4.1.2 Les technologies utilisees

Il existe plusieurs technologies standards utilisees par MDA.

49

MOF : Meta-Object Facility

Le formalisme de modelisation Meta-Object Facility (MOF) est un langage per-mettant d’exprimer des modeles. UML est, par exemple, un langage recommande pourconcevoir les modeles d’analyse et de conception. Le formalisme definit le concept etles relations entre concepts essentiels a l’expression de modeles. MOF est un stan-dard permettant de definir et de modifier des meta modeles et leurs modeles corres-pondants. Il permet de definir la syntaxe et la semantique d’un langage de modelisation,le but etant d’avoir un formalisme permettant l’expression de modeles de formalismes demodelisation. Un tel modele est nomme metaformalisme et les modeles qu’il permet d’ex-primer sont appeles des metamodeles. Dans MDA il n’existe qu’un seul metaformalisme,le MOF aussi appele metametamodele.

XMI : XML Model Interchange

Un modele correspond a un graphe general, contrairement a un programme sourcedans un langage de programmation qui a une representation textuelle ou arborescente(syntaxique). Il est a noter qu’il est plus commode de communiquer des formes lineairesvu que la transformation des formes arborescentes en formes lineaires est bien maıtrisee.Par contre, le passage du graphe d’un modele a une forme lineaire (serialisation) est plusdelicat. Afin de trouver une solution a ce probleme, l’Object Management Group (OMG)avait lance le Request for Proposal (RFP) Serial Model Interchange Format (SMIF).Initialement il etait envisage d’utiliser le format de CASE Data Interchange Format(CDIF), deja standardise par l’Electronic Industries Alliance (EIA). En cours de travail,il est apparu que le passage intermediaire vers la forme arborescente de XML constituaittechnologiquement une meilleure solution. Le RFP s’est donc conclu en proposant lanorme XML Model Interchange (XMI).

CWN : Commun Warehouse Metamodel

Ce standard a ete adopte afin de faciliter les echanges de metadonnees entre outils.Il fournit :

– Un langage commun pour la description des metadonnees,– La possibilite d’utiliser XML pour echanger les metadonnees,– Des APIs pour acceder aux metadonnees.

4.2 EMF : Eclipse Modeling Framework

Il s’agit de l’environnement de la plate-forme Eclipse dedie a MDA. EMF est unframework permettant la modelisation ainsi que la generation automatique du code apartir d’un modele de donnees structure. Autrement dit, partant d’une specification demodele decrite grace a XMI, EMF fournit les outils ainsi que le support d’execution pourgenerer un ensemble de classes du modele. Il produit en outre, un ensemble d’adaptateursqui permettent l’affichage et l’edition du modele. Les modeles peuvent etre specifies enutilisant des classes Java, Unified Modeling Language (UML), XML, puis sont importesdans EMF. Le plus important est qu’EMF fournit les fondements a l’interoperabiliteavec d’autres outils ou applications bases sur EMF.

50

EMF propose plusieurs services :– La transformation des modeles d’entrees (a gauche sur la figure 4.2), presentes

sous diverse formes, en Core Model,– La gestion de la persistance du Core Model,– La transformation du Core Model en code Java.

4.2.1 Les formats d’entree standards

Comme explique auparavant, EMF peut manipuler trois formats de modele qui sont :UML, XMI ainsi que du code Java annote.

UML

Il s’agit d’importer, a l’aide d’une fonction d’EMF, un modele dans son format natif(qui depend de l’outil de modelisation utilise). Seul le format IBM Rational (.mdl)permet de profiter de cet avantage. En effet, la suite Rational est la seule comptatibleavec EMF.

XMI

XMI decrit en detail comment persister les modeles. il est en train de devenir unstandard pour l’echange de donnees de modeles et Il est utilise pour persister les modelesECore dans EMF.

Code Java annote

Une des solutions tentantes pour modeliser les classes, qui vont etre concretiseespar une application Java, est d’utiliser les interfaces Java. Plusieurs raisons justifient cechoix :

– Elles n’implementent pas les methodes : on s’abstrait donc de cette implementation,– Les methodes get/set peuvent etre utilisees pour modeliser les attributs,– Une classe pourra implementer plusieurs interfaces ce qui facilite la modelisation.

Ainsi, les interfaces sont fournies en entree pour decrire les classes qui seront generesautomatiquement. Le module qui s’occupe de la conversion des modeles va detecterles tags @model au niveau des interfaces Java pour les utiliser comme elements de lamodelisation.

Figure 4.2 – Fonctionnement de EMF

51

4.2.2 Ecore ou metamodele

Ecore est un meta-modele tres proche de MOF(Meta-Object Facility). Il contienttoutes les informations par rapport aux classes du projet.

Quatre types d’entite sont utilises dans la definition d’un tel modele.

– EClass : Represente une classe contenant des attributs et des references,– EAttribute : Represente un attribut avec un nom et un type,– EReference : Il s’agit d’une extremite d’une association entre deux classes. Cette

entite contient une reference vers l’autre extremite de l’association,– EDataType : Represente le type d’un attribut. Exemple : int, float, data, etc.

Il est evident que seul le modele Ecore ne permet pas de contenir toute l’informationnecessaire a la transformation. C’est pour cette raison qu’un autre modele appele Gen-model doit etre utilise afin de renseigner sur les informations additionnelles necessairependant la generation du code. On peut citer comme information additionnelle : ladestination ou le nom des fichiers generes.

Le modele Ecore montre l’objet racine qui represente le modele. Ce dernier a desenfants qui representent l’ensemble des packages. Dans chaque package, on peut trouverun ensemble de classes dont les attributs sont representes sous forme de noeuds enfants.Le principe global est de definir des associations entre les principaux types d’elementsd’un modele sous la forme d’un arbre. Nous commencons donc par creer ce qui jouele role du sommet de l’arbre, puis a partir de la, nous creerons les elements suivants.Ainsi, l’element principal cree est un package dans lequel nous pouvons creer des classes.celles-ci peuvent contenir differents attributs ainsi que des associations entre elles.

Rappelons que les deux representation (arbre et graphe) sont completement equivalentes,L’utilisateur doit obligatoirement utiliser la vue d’arbre pour concevoir le modele, ilpourra ensuite visualiser son modele sous forme de graphe afin de bien mettre en evidenceles differentes relations entre les classes.

4.2.3 Generation du code

Lors de la generation du code, des interfaces et des classes sont generees automatique-ment. L’idee qui a ete adoptee par les concepteurs d’EMF consiste a separer l’interfacede l’implementation dans le code genere. Cela va se concretiser par la generation de deuxensembles (issus du modele d’entree, assimilable a un diagramme de classes UML) :

– Un ensemble d’interfaces Java,– Un ensemble de classes implementant ces interfaces.Il est a noter qu’EMF se base sur plusieurs patterns lors de la generation du code.

En effet, les concepteurs ont voulu s’aligner sur les API standards. Des interfaces commeFactory ou Package sont automatiquement generees ainsi que leurs classes d’implementation.

Par ailleurs, EMF offre la possibilite de completer manuellement le code obtenu auto-matiquement et surtout de pouvoir garder ce code supplementaire en cas de regenerationdu code. La generation liee a un modele est parametree a l’aide d’un modele EMF degeneration dont la structure est definie par le metamodele appele GenModel. Cette ap-proche de generation parametree par un modele presente comme avantages de ne paspolluer les elements de modelisation avec des ingredients relatifs a la generation et depouvoir appliquer plusieurs generations differentes a un meme modele.

52

Figure 4.3 – Exemple d’instance d’un modele Ecore vue sous forme d’arbre

Enfin, un meta-modele qui est base sur le concept d’Ecore offre la possibilite d’ex-primer un ensemble de contraintes qui sont : le typage des elements, la compositiond’elements, la cardinalite et l’unicite des liens. Ceci n’est malheureusement pas suffi-sants car d’autres types de contraintes non exprimables structurellement doivent etreprises en compte. Ces constats et des besoins de precision de metamodeles dans le cadrede travaux en recherche ont conduit a etendre EMF avec un support Object ConstraintLanguage (OCL). Ce dernier permet de formaliser l’expression de contraintes utilisedans les diagrammes d’UML et en particuler les diagrammes de classes. L’integrationd’OCL a EMF permet :

– La specification de constraintes OCL pour les modeles EMF (integrees).– Le stockage des modeles avec leur contraintes.– La validation syntaxique et semantique des contraintes.– La generation de code Java pour verifier les contraintes a l’execution.

4.3 JET : Java Emitter Templates

JET est un composant d’EMF utilise pour la generation du code et dont la syntaxeest tres proche de celle de JSP.

La generation du code a partir de modele permet de reduire le temps de travail et laquantite du code redondant dans l’applicaion. Toutefois, l’outil qui est cense generer lecode peut devenir tres complexe et difficile a maıtriser dans le cadre de grands projets.Les templates permettent de reduire la complexite et d’augmenter la lisibilite. Grace aJET, les utilisateurs d’EMF peuvent creer facilement des templates qui exprime le code

53

a generer, et ce, dans plusieurs langages comme le Structured Query Language (SQL),XML, ou le Java.

JET contient principalement quatre librairies de commandes a savoir :– Commandes de Controle : Utilisees pour acceder au modele d’entree et pour

controler l’execution du templat– Commandes de format : Utilisees pour modifier le format du texte dans les

modeles selon certaines regles.– Commandes Java : Ce sont des balises utiles pour generer du code Java.– Commandes de Workspace : Utilisees pour la creation de ressources dans l’es-

pace de travail, telles que des fichiers, des dossiers et des projets.En utilisant les templates de JET, le developpeur peut creer differentes implementations

pour un meme modele. Il peut ensuite, parametrer l’implementation en fonction ducontexte. Deus etapes intermediaires sont necessaires pendant la generation du code :

– La translation : Consiste a transformer les templates en une implementation declasses Java.

– La generation proprement dite : L’utilisation de ces classes Java en vue del’obtention du resultat desire.

Figure 4.4 – Exemple d’instance d’un modele Ecore dans l’editeur graphique

54

Figure 4.5 – Transformation d’un modele EMF + JET

4.4 EPA : Eclipse Plugin Architecture

Eclipse IDE est un Environnement de Developpement Integre qui a ete concu autourde la notion de Plugin. L’alliance OSGi 1 a concu un framework qui definit un modelede gestion de cycle de vie d’une application, un repertoire (registry) de services, unenvironnement d’execution et des modules. Eclipse IDE utilise OSGi comme modele decomposants et SWT/JFace 2 comme composants graphiques.

Les composants de base d’Eclipse peuvent etre reutilises pour developper des clientslourds independants d’Eclipse grace au projet Eclipse Rich Client Platform (RCP).

4.4.1 Programmation orientee composant

Avant d’entrer dans le cœur de la technologie, nous allons detailler les caracteristiquesde la programmation orientee composant afin d’identifier les problematiques qu’ellesvisent a resoudre. En effet, la programmation orientee composant vise a abolir les limi-tations de la programmation orientee objet. Cette derniere decrit la maniere dont lesclasses d’objet doivent etre definies mais n’apporte aucun support afin de mettre enrelation ces classes. Malheureusement, ceci rend les grandes applications orientees objetdifficilement maintenables ou evolutives.

Ainsi, cet aspect peut devenir tres problematique lors de la mise en oeuvre dereseaux complexes d’objet. En effet, cela se traduit tres souvent par des couplages fortsentre objets, ce point nuisant enormement a la reutilisabilite des traitements. Chaquedeveloppeur a alors le choix des outils afin de mieux concevoir ses applications. L’ap-proche la plus adaptee consiste en la mise en oeuvre des “design patterns” par l’in-termediaire de frameworks tels que Spring utilises conjointement avec la programmationpar interface.

1. Open Services Gateway initiative

2. Standard Widget Toolkit et JFace sont deux composants developpes par IBM

55

Dans ce contexte, la technologie Open Services Gateway initiative (OSGi) vise aregler les differentes problematiques vues precedemment, problematiques recapituleesci-dessous :

– Abolir les limitations de la programmation orientee objets,– Permettre la gestion des applications complexes et de taille importante,– Ameliorer la qualite de service des applications,– Permettre la mise en oeuvre d’architectures orientees service.

Dans ce type d’approche, un composant est considere comme une unite independantede production et de deploiement qui est combinee a d’autres composants pour formerune application. L’objet reste au centre du composant mais l’objectif differe car le butest de toujours utiliser une approche objet, non pas au sein du code, mais au niveau del’architecture generale du logiciel.

Un composant est cense fournir un service bien precis. Les fonctionnalites qu’il en-capsule doivent etre en rapport et coherentes entre elles. On verrait mal l’interet d’uncomposant regroupant les taches de gestion d’impression et de compression de fichiers,par exemple. Rappelons que le but ultime de cette approche est la reutilisabilite. Pource faire, les composants doivent avoir un comportement generique. Ceci n’est pas mal-heureusement pas possible qu’en cas de compromis entre la specialisation du composantpour optimiser son utilisation dans le cadre du projet actuel, et sa generalisation en vuede sa reutilisation .

4.4.2 Architecture OSGi

Figure 4.6 – Architecture OSGi

L’architecture de la specification OSGi est basee sur la notion de Bundle. Dans lesuite, une breve description de chaque element :

– Bundles :Le composant correspond a l’entite centrale de la technologie OSGi est designepar 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 objetsPlain Old Java Object (POJO). Elle offre la possibilite de mettre a dispositioncertains traitements des composants par l’intermediaire de services.

56

– Services Registry :Cette API permet de gerer les services.

– Life-Cycle :La couche Cycle de vie (life cycle) prend quant a elle en charge les etats des bundlessupportes par le conteneur ainsi que les API correspondantes.

– Modules :La couche Modules est chargee de la gestion des bundles, aussi bien au niveau duchargement des classes (classloading) que de la gestion de leurs visibilites et deleurs versions.

– Security :Cette couche est chargee de la gestion des differents aspects de la securite, commela limitation de fonctionnalites ou de capacites de traitement.

– Execution Environnement : Definit les methodes et les classes necessaires al’execution de la plate-forme.

Il est a noter ici que le lien etroit existant entre cette architecture et l’architectureorientee service. L’architecture de la technologie OSGi permet de mettre en oeuvre descomposants et de mettre a disposition des services applicatifs. C’est donc aussi une ar-chitecture orientee service mais qui a la caracteristique d’etre tres “legere”. En effet, Elledoit pouvoir fonctionner de maniere autonome dans un seul processus Java. Autrementdit, elle correspond a un modele de service deploye une meme machine virtuelle.

4.4.3 Les Bundles OSGI

Avec la technologie OSGi, le concept de composant est mis en oeuvre par l’in-termediaire de bundles, un bundle correspondant a un composant qui peut etre deployedans un conteneur OSGi.

Clairement, il s’agit d’un fichier JAR qui contient, en outre des classes Java, desinformations de deploiement specifiees par l’intermediaire du fichier standard MANI-FEST.MF present dans le repertoire META-INF. En effet, OSGi reprend ce fichier eny ajoutant differents en-tetes afin de configurer le composant.

Proprietes d’un Bundle

Les proprietes du bundle sont definies au niveau de ce meme fichier manifest :

– Bundle-ManifestVersion : Version du fichier MANIFEST.– Bundle-Name : nom du bundle.– Bundle-SymbolicName : nom symbolique du bundle.– Bundle-Version : numero de version du bundle.– Bundle-RequiredExecutionEnvironment : environnement d’execution requis.– Import-Package : “packages” importes ainsi que les numeros de versions requis.– Export-Package : “packages” exportes.– Bundle-Vendor : fournisseur du bundle.– Dynamic Import-Package (a partir de la version 3 des specifications) : dependances

importees dynamiquement. Ces dependances ne doivent pas etre obligatoirementdisponible lors du demarrage du bundle. Ce type d’import est interessant pour lamise en place du Bundle.

57

– Bundle-NativeCode : liste des bibliotheques natives utilisees.– Require-Bundle : identifiant des bundles necessaires.– Bundle-Activator : nom du bundle Activator permettant d’executer des traite-

ments au demarrage et a l’arret du bundle. Cette classe livree avec le bundle doitimplementer l’interface BundleActivator.

– Bundle-Classpath : classpath necessaire pour l’execution du bundle.

Le Activator

Cet objet permet au bundle de s’abonner aux evenements du Framework. Ce dernierdetermine l’objet Activator du Bundle en se basant sur le fichier Manifest. Technique-ment, cette classe implemente l’interface BundleActivator, et redefinit les methodessuivantes :

– La methode Start(BundleContext context)– Recherche et obtient des services requis aupres du contexte et/ou positionne des

listeners sur des evenements,– Enregistre les services fournis aupres du contexte.

– La methode Stop(BundleContext context)

Cycle de vie d’un Bundle

Figure 4.7 – Cycle de vie d’un Bundle

Un bundle peut etre dans un des etats suivants :– UNINSTALLED : Etat dans lequel se trouve un bundle une fois qu’il a ete

desinstalle.– INSTALLED : Etat dans lequel se trouve un bundle juste apres avoir ete installe,

la resolution des dependances n’ayant pas encore ete realisee.– RESOLVED : Etat dans lequel se trouve un bundle apres avoir ete installe, la

resolution des dependances ayant juste ete realisee.– STARTING : Etat dans lequel se trouve un bundle lorsqu’il est en train d’etre

demarre. Cet etat correspond a un etat transitoire entre les evenements Resolu etActif.

58

– STOPPING : Etat dans lequel se trouve un bundle lorsqu’il est en train d’etrearrete. Cet etat correspond a un etat transitoire entre les evenements ACTIVEet et Resolved.

– ACTIVE : Etat dans lequel se trouve un bundle lorsqu’il a ete demarre avecsucces. Le bundle ainsi que les services qu’il expose sont disponibles pour lesautres bundles.

Interactions entre les Bundles

Comme nous l’evoquions dans la section precedente, un conteneur OSGi offre lapossibilite de gerer la visibilite des ressources en composant. Par defaut, un composantest completement opaque depuis l’exterieur et rien n’est accessible. Cet aspect impliquede preciser toutes les dependances utilisees par un composant et tous les packages misa disposition.

La specification OSGi offre la possibilite de jouer sur cet aspect par l’intermediaired’en-tetes dans le fichier MANIFEST.MF, fichier contenant les donnees relatives audeploiement et decrit dans la section precedente.

4.4.4 Equinox

Equinox est un nom de projet Eclipse qui fournit une implementation de la specificationdu framework OSGi R4. Il s’agit d’un ensemble de bundles qui implementent les differentsservices optionnels de OSGi ainsi que toute l’infrastructure necessaire a l’execution dessystemes bases sur OSGi.

4.5 JBoss Application Server

Dans le deuxieme chapitre, nous avons vu que la plate-forme JEE definissait lesspecifications du serveur d’applications dans lequel les applications Java Enterprise sontexecutees. Ces recommandations permettent ainsi aux entreprises tierces de developperdes serveurs d’applications conformes a ses specifications. JBoss Application Server estun des plus celebre de ces serveurs applicatifs.

JBoss AS ( Java Beans Open Source Software Application Server) definit un ensemblede modeles de composants qui peuvent etre utilises par le developpeur pour la conceptionde ses composants. Ces derniers peuvent etre deployes sur JBoss AS en utilisant lemodele de deploiement. Lorsque le composant est en cours d’execution sur le serveur, cedernier fournit un ensemble de services qui sont destines a ce composant. Sans ce serveurd’applications et lorsque l’application s’execute en local, le developpeur doit initialiserl’ensemble des services qui seront utilises par l’application. Il doit par exemple, preparerla connection a la base de donnees en fournissant le nom de l’utilisateur et le mot depasse, telecharger des informations et les mettre en cache pour accelerer le lancement del’application. Grace au serveur applicatif, la configuration de certains services utilisespar l’application peut etre effectuee independemment de l’application elle meme. Lafigure 4.8 presente la difference entre une application standalone(a gauche dans la figure)et une autre utilisant les services du serveur applicatif.

59

Les modeles de composants incluent des standards comme les EJBs, JSP et lesservlets. Nous pouvons citer parmi les services offerts par ces composants : la gestionde la securite, la gestion des transactions, la persistance, la messagerie, la gestion desressources, la gestion de la concurrence, le nommage et le deploiement.

Figure 4.8 – Utilisation des services du JBoss Application Server

4.5.1 EJB : Enterprise Java Bean

Les EJBs sont tout simplement un modele de composants deploye au niveau duserveur applicatif. Chaque EJB a un role specifique, il peut :

– Representer des donnees : Il est appele Entity Bean dans ce cas. Il peut parexemple representer un client, un objet d’un stock. Autrement dit, les entity beanscorrespondent a des objets reel.

– Proposer des services : Session Bean. Il fournit une interface distante afin dedefinir les methodes que l’on peut invoquer.

– Acomplir des taches de maniere asynchrone : Message Bean. Il attenddes messages asynchrones specifiques auxquels il repond.

Les EJBs utilisent l’ensemble des services offerts par le serveur applicatif pour realiserleurs fonctions. Le client peut etre une entite de toute forme : application avec ou sansinterface graphique, un bean, une servlet, une JSP ou un autre EJB.

Le client peut utiliser deux technlogies pour acceder aux fonctions de l’EJB :– Le protocole SOAP. Pour ce faire, le client genere un message SOAP contenant la

requete qui doit etre decodee et traitee par l’interface SOAP de l’EJB.– RMI pour Remote Method Invocation va permettre a des applications clientes

(s’executant localement) d’invoquer des methodes sur des objets distants, c’est-a-dire localises dans l’EJB. Contrairement a la premiere methode d’acces, cettemethode ne peut etre utilisee que par les applications Java disposant en plusdes specifications de l’objet distant. Le concepteur de l’EJB doit fournir unespecification de l’EJB sous la forme d’une interface Java contenant l’ensembledes methodes qui pourront etre invoquees sur l’objet.Une implementation courante de cette methode d’acces consiste a integrer un stubau niveau du client. Un stub etant une representation locale de l’objet distant. Ilimplemente l’interface remote mais contient une connexion reseau pour acceder al’objet distant.

60

4.6 Description des services avec WSDL

Le standard WSDL est un langage reposant sur la notation XML permettant dedecrire les services web. WSDL permet ainsi de decrire l’emplacement du service webainsi que les operations (methodes, parametres et valeurs de retour) que le service pro-pose. Le fichier WSDL est principalement compose de 5 elements, avec d’autres elementsoptionnels :

– definitions : element racine du document, il donne le nom du service, declare lesespaces de noms utilises, et contient les elements du service.

– message : decrit un message unique, que ce soit un message de requete seul ou unmessage de reponse seul. L’element defini le nom du message et peut contenir (oupas) des elements nommes part, qui font reference aux parametres du message ouaux valeurs retournees par le message.

– portType : combine plusieurs elements message pour composer une operation.Chaque operation se refere a un message en entree et a des messages en sortie.

– types : decrit tous les types de donnees utilises entre le client et le serveur.WSDL n’est pas exclusivement lie a un systeme specifique de typage, mais utilisepar defaut le specification XML Schema.

– binding : decrit les specifications concretes de la maniere dont le service seraimplemente : protocole de communication, format des donnees pour les operationset etc. WSDL possede des extensions internes pour definir des services SOAP. Parconsequent, les informations specifiques a SOAP se retrouvent dans cet element.

– service : defini les adresses permettant d’invoquer le service donne, ce qui serta regrouper un ensemble de ports relies. La plupart du temps, c’est une URLinvoquant un service SOAP.

– import : permet de separer les differents elements d’une definition de service enplusieurs documents independants, qui peuvent etre eventuellement importes. Celapermet d’ecrire des definitions plus claires, en separant les definitions selon leursniveaux d’abstraction, et de maximiser la reutilisabilite.

4.6.1 Versionning des services

Dans une implementation SOA, un service n’a de sens que s’il est invoque par plu-sieurs applications ou blocs applicatifs. Par consequent, tout changement survenant surun service impacte l’ensemble des consommateurs de ce service. Non seulement ces chan-gements peuvent couter chers, en plus, l’autonomie du service est un fondement de lamise en œuvre d’une architecture orientee services. L’autonomie se traduit par le fait quele service peut etre modifie, deploye et maintenu independamment des consommateursqui l’invoquent.

La facon la plus repondu pour faire face aux changements des services, c’est leversioning. Cela se traduit par la coexistence de plusieurs versions du meme service,chacune est utilisee par un ou plusieurs consommateurs. L’introduction de la coexistencede multiples versions d’un meme service permet d’avoir des cycles de vie independantsentre fournisseurs et consommateurs de services, ce qui minimise les impacts globauxsur l’implementation SOA.

61

4.7 JBoss Enterprise Service Bus

4.7.1 Presentation de l’outil

JBossESB est une solution Open Source complete. Elle est composee de plusieursmodules :

– Un BPM,– Un Integrated Development Environment (IDE),– Des connecteurs,– Un gestionnaire de transactions,– Un gestionnaire de securite,– Un conteneur d’applications,– Un outil de messagerie,– Un Naming and Directory Service (NDS),– Une architecture distribuee de calcul.

4.7.2 Notions importantes

Les differents acteurs qui communiquent avec l’ESB n’utilisent pas forcement lememe format de messages que l’ESB, d’ou l’interet d’avoir des points d’entree et desortie au niveau de l’ESB (appeles gateways ou connecteurs) pour assurer le formattageet la transformation des messages.

Gateways

Les Gateways sont des “listeners” qui peuvent recevoir differents types d’objet (message JMS, tables SQL.. ), leur appliquer un ensemble d’actions (transformation etautre) 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 specifique.

A noter qu’on peut toujours definir de nouveaux types de gateways sous conditionque les technologies de communication qu’ils utilisent soient implementees par l’ESB.

EPR

Un endPoint est un point d’entre d’un service, d’un processus, d’une queue ou d’untopic Un EPR est une reference vers un “endPoint” de l’ESB. Il s’agit d’un objet quicontient toutes les informations necessaires pour communiquer avec un “endpoint”.

62

Registry

Represente le cœur de l’ESB, il est utilise pour stocker les informations concernantles services metier. Ainsi, lorsqu’une application veut communiquer avec un service, elleintrospecte d’abord le registry pour avoir l’EPR du service desire.

Services

Un service de JBoss ESB defini :– Des listeners qui peuvent etre soit :

– des listeners gatewayIls sont en charge de transformer le message (dit unaware) recu de l’exterieurde l’ESB en un message supporte par l’ESB (dit aware)

– Des listeners ESB-awareIls lisent les messages au format ESB (aware)

– Une sequence ou un pipeline d’actions.

Structure d’un message ESB

– Une entete :Les informations qui s’y trouvent concernent principalement le destinataire, l’emetteurainsi que le contenu du message.

– Un contexte :Ce sont des informations additionnelles qui expliquent le message. Cela peut conte-nir par exemple le dernier recepteur du message ou des liens externes.

– Un corps :Represente la partie utile du message

– Un champ Erreur :Contient l’information sur les eventuelles erreurs associees au message.

– Un champ pour une eventuelle piece jointe :N’importe quel fichier qu’on desire attacher au message.

– Des proprietes :Proprietes additionnelles du message.

Routage

Par defaut, l’information est “packagee”, transformee et stockee sous forme de mes-sage au sein de l’ESB. Ces derniers sont adresses aux EPRs sous condition que l’adressede destination soit toujours valide et que le service de destination soit en mesure detraiter ce genre de message. Le CBR solutionne ce genre de probleme en routant lesmessages selon leur contenu. Dans ce cas, il n y a plus de probleme d’EPR obsolete. Ilexiste trois classes de routage :

– org.jboss.soa.esb.actions.ContentBasedRouterImplemente le pattern CBR. Elle route les messages au(x) service(s) de destina-tion en se basant sur leurs contenus et sur l’ensemble de regles d’evaluation. Uneexception est levee lorsque aucune destination n’a pu etre trouvee.

63

– org.jboss.soa.esb.actions.ContentBasedWireTapImplemente le pattern WireTap qui est un pattern d’integration dans lequel unecopie de chaque message est envoyee sur un canal de controle.

– org.jboss.soa.esb.actions.MessageFilterImplemente le pattern Message Filter. Cette classe permet la suppression auto-matique de messages non valides. Un message est non valide lorsque certains deses elements sont absents.

4.8 JAIN Service Logic Execution Environnement

La plate-forme JAIN SLEE est un standard qui permet aux developpeurs Javad’etaborer et de deployer des services dans des systemes temps reel comme les reseauxde telephonie fixe ou sans fil. Il permet d’integrer ces services dans les infrastructuressexistantes sans devoir ajouter de nouveaux composants.

La technologie JAIN SLEE joue le meme role que JEE en tant que support d’appli-cations Java. Elle offre un modele de composants pour la structuration de la logique desapplications de communication. Le but etant de voir ces applications comme des com-posants orientes objet qu’on peut composer sous forme de services fiables et modulaires.JAIN SLEE integre un modele d’evenement avec un composant de programmation touten incorporant des interfaces d’administration (par l’intermediaire de JMX), un adap-tateur de ressources pour le reseau, des interfaces de profiles generiques, un systeme degestion de persistance pour les etats de redondance, des systemes de controle d’accesconcurrent comme les minuteries, des systemes d’alarmes, un systeme de suivi d’utilisa-tion et des traces.

4.8.1 La notion de service

Un service dans la terminologie JAIN SLEE est vu comme une unite remplacablequ’on peut facilement gerer [8]. L’administrateur du systeme a la possibilite de controlerle cycle de vie du service. Ce dernier inclut, entre autres, une description contenant sonnom, le nom du vendeur de service et sa version. Notons que chaque service peut incluredes classes Java, des profiles mais aussi des Service Building Blocks.

4.8.2 Les profiles

Un profile JAIN SLEE peut etre vu comme une table de base de donnees ayantun schema et un ensemble d’attributs ou de proprietes. Par exemple, un numero detelephone ainsi que l’adresse electronique d’un individu peuvent etre consideres commedeux attributs d’un profile [8]. JAIN SLEE prevoit une specification pour cela. En effet,cette specification inclut les interfaces de gestion qui doivent etre generees pour chaqueprofile et qui permettent de faire des modifications ou des mises a jours sur ce dernier.Les methodes create, modify, display, remove doivent etre exposees pour chaque profile.

Il est a noter que ces profiles sont utilises pour le construire la logique d’applicationdes Service Building Blocks.

64

4.8.3 Les Service Building Blocks

L’element reutilisable au sein de l’architecture JAIN SLEE est appele Service Buil-ding Block (SBB). Un SBB est un composant logiciel qui envoie/recoit des evenementset realise des traitements logiques bases sur les evenements recus ainsi que son propreetat. Les SBBs sont des composants “stateful” 3 capables de memoriser les resultats desrequetes precedentes et pouvant etre composes a partir d’autres SBBs.

La notion d’evenement est definie comme une occurence d’un acte qui se produit al’interieur ou a l’exterieur du systeme. De meme qu’avec les profiles, les SBBs doiventinclure une description de leurs fonctionnalites.

3. Dans ce cas, chaque SBB est associe a un seul client.

Chapitre 5

Gestion de la plate-forme

5.1 Presentation de la plate-forme

Deuxieme equipementier mondial derriere Cisco, Alcatel-Lucent est une societe specialiseedans les telecommunications. Elle propose une large gamme de services : conception,integration/deploiement, exploitation et maintenance des reseaux. L’ensemble des solu-tions qu’elle propose touche les domaines de l’enseignement, l’energie, les finances, lavente, les transports, la sante, etc.

Alcatel-Lucent dispose de plusieurs plates-formes de communication, temps reel etsecurisees sur lesquelles peuvent etre deploye les services de communication. L’achat d’unservice par un operateur implique l’achat de la plate-forme qui le supporte, l’operateurse charge ainsi de l’hebergement du service et de sa plate-forme (Figure 5.1).

Pour illustrer ce fait, nous allons prendre la plate-forme Next Generation IntelligentNetwork (NGIN) 1. Lorsqu’un operateur acquiert cette plate-forme (utilisee notammentpour le real-time billing 2), il peut la gerer via une application web qui permet, en outre,de consulter le rapport sur les differentes operations executees par la plate-forme.

Par ailleurs, il est tout a fait possible de faire communiquer l’application de gestion dela plate-forme avec les autres composants du systeme informatique de l’operateur. Pource faire, un travail supplementaire doit etre realise par l’equipe d’integration d’Alcatel-Lucent afin d’etablir un lien (one-to-one) entre l’application de gestion et les autresapplications concernees. Une fois cette tache accomplie, la creation d’un compte d’utili-sateur dans le Customer Relationship Management (CRM) pourra, par exemple, genererautomatiquement un compte et un profile au niveau de la plate-forme NGIN. Les ap-plications de l’operateur ainsi que l’application de gestion de la plate-forme peuvent sesynchroniser grace aux liens prealablement etablis par l’equipe d’Alcatel-Lucent.

La figure 5.1 montre l’integration de la plate-forme NGIN au niveau du reseautelephonique de l’operateur. Le systeme informatique de ce dernier heberge l’applicationde gestion qui permet de controler la plate-forme. Comme explique precedemment, la

1. Il s’agit d’une implementation du concept de IN (Intelligent Network) basee sur la nouvelle archi-

tecture des reseaux fixes et mobiles qu’on appelle Next Generation.

2. Le real-time billing est une des plus importantes fonctionnalites dans les systemes de services de

telecommunication, elle est principalement utilisee pour les services prepaid comme les cartes de recharge

telephonique.

65

66

Figure 5.1 – Integration de la plate-forme NGIN dans l’environnement de l’operateur

methode d’integration actuelle consiste a creer des liens directs entre l’application degestion de la plate-forme et les applications censees communiquer avec cette derniere.

Le probleme cause par cette methode d’integration est d’abord un probleme finan-cier car l’operateur doit payer en plus l’equipe d’integration pour son travail. C’est aussiun probleme de perte de temps car la creation d’interfaces entre les applications peutnecessiter plusieurs jours de travail. Enfin, il s’agit d’une approche qui va handicaperl’ensemble du systeme vu que les applications de l’operateur vont dependre de l’appli-cation de gestion de la plate-forme.

5.2 Architecture de l’application de gestion de la plate-

forme

Le developpement de cette application est base sur MDA et plus particulierement surEMF. Le choix d’eclipse 3, comme environnement de developpement s’explique par samaturite et sa puissance. Il est a noter que les deux principaux objectifs des concepteurs

3. www.eclipse.org

67

Figure 5.2 – Exemple de deux profiles crees dans Eclipse

d’Eclipse sont la modularite et l’extensibilite. Grace a cela, l’equipe d’Alcatel-Lucent apu developper un ensemble de modules ou de Plugin offrant des fonctionnalites avanceesau niveau de la modelisation des profiles JAIN SLEE(section 4.8.1). Ainsi, nous pouvonsfacilement modeliser une specification d’un profile JAIN SLEE sous forme de modeleEMF. A partir de ce modele sera automatiquement genere :

– Le schema ainsi que la logique d’execution du profile sur une plate-forme JAINSLEE. Clairement, il s’agit du code du service de telecommunication.

– Des EJBs qui exposent les methodes de manipulation et de mise a jour du profile.Ils disposent d’une interface SOAP qui permet d’effectuer des requetes de facontres pratique.

– Un ensemble de page web permettant a l’administateur d’appeler les methodes degestion du profile via une interface web.

A ce stade, le developpeur doit :– Deployer le profile JAIN SLEE sur la plate-forme adequate.– Deployer les EJBs ainsi que l’application web sur un serveur applicatif.

5.2.1 Transformation du modele EMF

La transformation d’un modele representant une specification d’un profile JAINSLEE genere automatiquement une classe contenant l’ensemble des attributs du profileainsi que des getters et des setters pour la manipulation de ces attributs. Il est evidentque la transformation ne peut pas generer toutes les classes des EJBs, ni les pages webqui seront deployees sur le serveur applicatif. En effet, l’implementation de ces classesainsi que des pages web est tellement specifique qu’il est impossible de l’indiquer au

68

moment de la creation du modele. C’est ici que la technologie JET (section 4.8.1) vaavoir son utilite car elle va nous permettre de definir l’implementation des EJBs ainsique l’ensemble des fichiers necessaires a leur deploiement. De meme, le contenu des pagesweb sera decrit au travers d’un generateur JET.

L’utilisation de ces generateurs permet de changer l’implementation en fonction ducontexte. Il suffit d’ecrire l’ensemble des modeles ou des templates qui seront utilisespar le generateur et le tour est joue. Il va sans dire que plusieurs generateurs sontnecessaires au niveau de la transformation du profile JAIN SLEE. Parmi ces generateursnous pouvons citer le generateur qui va definir l’implementation de l’EJB. Notons qu’untemplate est necessaire pour la generation de chaque classe Java contenue dans l’EJB.

Afin d’etre plus precis, voici une description detaillee de l’ensemble des composantsgenere grace a l’utilisation de la transformation EMF combinee avec les generateursJET.

– Un projet contenant le code du profile JAIN SLEE :Ce projet contient le code du service de telecommunication ainsi que le code de laspecification du profile JAIN SLEE, il comporte aussi les elements suivants :– Un fichier XML utilise pour le deploiement. Ce fichier XML permet d’etablir

une relation entre le profile JAIN SLEE et la table de base de donnees ainsi queson utilisateur associe dans ORACLE.

– Un fichier zip contenant les commandes pour l’installation et la configurationde la base de donnees. Il permet, en outre, de creer la table du profile dans labase de donnees.

– Un projet Eclipse contenant les EJBs :Chaque profile doit avoir un EJB qui le represente au sein du serveur applicatif.Cet EJB est compose des elements suivants :– Une classe Serialisable representant le profile. Si nous reprenons l’exemple de

la figure 4.8.1, nous aurions automatiquement une classe Company dans l’EJBresponsable du profile Company. Cette derniere contient exactement les memeattributs definis au niveau de la figure 4.8.1. Quant aux methodes metiers, ellesseront definies au niveau de la classe CompanyAccessBean.

– Une classe permettant d’executer l’ensemble des methodes metier (CompanyAc-cessBean pour le profile Compagy par exemple), elle recoit une instance de laclasse representant le profile en vue de lui appliquer une methode. Cette classeimplemente une interface qui definit exclusivement les methodes metiers du pro-file.

– Une interface Local et une autre Remote pour la manipulation distante de l’EJB.– Une classe Heritant de GenericSOAPHandler qui permet de manipuler les requetes

SOAP.– Un fichier jaxws-handlers.xml indiquant le nom de la classe responsable du trai-

tement des requetes SOAP.– Un ensemble de Stub (section 4.5.1) ainsi que toutes les classes necessaires a

leur fonctionnement.– Un projet Eclipse contenant les portlets :

Ce projet est constitue de plusieurs elements :– Un ensemble de ressources Java necessaires au fonctionnement des portlets 4.

Nous retrouvons dans ce package la classe representant le profile et disposant,

4. Une portlet est un composant web destine a etre integre dans le contexte d’une page composite.

69

en outre des attributs, d’un ensemble de methodes metier utilisant les Stubspour acceder 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 dediees a la partie presentation. Le role d’une page JSPX est :– De representer graphiquement les informations (notamment grace a l’utilisa-

tion de balises IceFaces 5

– D’effectuer le transfert des informations saisies par l’utilisateur vers le EJBcorrespondant.

5.3 Fonctionnement de l’application de gestion de la plate-

forme

Figure 5.3 – Illustration du fonctionnement d’un EJB + portlet

Pour resumer 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 acceder enutilisant une interface graphique, soit via l’interface SOAP de l’EJB. Les applicationsinteressees pouront s’adresser de maniere directe aux EJBs via cette interface, leursrequetes seront traitees de maniere synchrone.

5. Il s’agit d’une bibliotheque de composants AJAX qui permet de faciliter le developpement d’une

application sophistiquee avec une interface riche pour une application Java Server Face (JSF).

Chapitre 6

Proposition d’une solution

d’integration

6.1 Les apports de la solution

La chapitre precedent explique a la fois l’architecture et le fonctionnement de l’ap-plication de gestion de la plate-forme. Nous avons pu constater trois problemes lors deson integration dans le systeme informatique de l’operateur de telecommunication :

– Un probleme financier. En effet, l’operateur doit payer les frais supplementairesdus au travail d’integration realise par l’equipe d’Alcatel-Lucent.

– Un probleme de timing car le travail de l’equipe d’integration peut prendre plu-sieurs jours.

– Un probleme architectural vu que les liens one-to-one crees vont handicaper l’en-semble des applications concernees.

Nous voulons montrer, a travers ce travail, une nouvelle approche pour l’integrationde l’application de gestion de la plate-forme dans le systeme informatique de l’operateur.

EDA (section 3) sera a la base de cette approche.

En effet, les liens qui peuvent etre etablis par l’equipe d’integration servent commesupport pour envoyer des requetes a l’application de gestion de la plate-forme. Cesrequetes peuvent tres bien etre envoyees sous forme d’evenements(Figure 6.1). Une entitecentrale 1 s’occupera de la recolte de ces evenements et de leur transfert vers l’applicationde gestion de la plate-forme.

Une attention particuliere doit etre portee a la nature des requetes envoyees a l’ap-plication de gestion de la plate-forme. Il s’agit, tres souvent, de demandes de creationde compte pour un client, de demandes de mise a jour des informations du client, etc.Ce sont des demandes qui doivent etre traitees immediatement. Autrement dit, les ap-plications doivent communiquer de maniere synchrone avec l’application de gestion dela plate-forme. Cette remarque nous amene a la conclusion suivant laquelle il faut etrevigilant lors de l’implementation du modele publish/subscribe que prone EDA. Un trai-tement lent au niveau de l’Event Collector engendrait un temps de latence au niveau del’application cliente.

1. Il s’agit de l’Event Collector

70

71

Figure 6.1 – Integration grace a EDA

Avant de presenter les details de la solution, voyons l’ensemble des avantages de cetteapproche :

– L’abstractionEn effet, lorsqu’on introduit une couche d’abstraction entre les composants, celanous permet de dire que l’ensemble des composants communiquants sont completementindependants les uns des autres. De plus, chaque application (CRM, ERP, etc)peut utiliser un format different pour l’encodage de ses requetes. L’unite centralejouant le role d’Event Collector se chargera de la transformation des donnees deces requetes afin qu’il y ait un modele unique d’evenements au sein de l’EventCollector.

– L’exploitation des evenementsL’Event Collector recolte l’ensemble des evenements afin de les preparer et de lesredistribuer aux composants interesses. Cela etant, une copie de ces evenementspeut etre utilisee a d’autres fins. Un CEP (Complex Event Processing) peut etrebranche sur l’Event Collector et profiter pour analyser tous les evenements qui ycirculent.

– L’evoluabiliteLes applications communiquantes peuvent evoluer independamment sans se preoccuperdu reste du systeme. Une seule entite ( l’Event Collector) devra tenir compte desmodifications des applications afin d’assurer le transfert des evenements.

Il est a noter que l’Enterprise Service Bus (ESB) est specialement adapte pour jouer lerole de federateur d’evenements ou d’Event Collector (section 3.10.1). Des composantsappeles connecteurs ou gateways peuvent etre definis au niveau de l’ESB en vue derecevoir de l’information et de la traiter afin de l’acheminer vers une destination donnee.Dans la suite, une implementation recente de JBoss ESB 2 sera utilisee comme EventCollector.

2. Le JBoss ESB 4.7

72

6.2 Description de la solution d’integration

6.2.1 Utilisation de JBoss ESB comme Event Collector

La premiere partie sur laquelle il faut se concentrer afin de comprendre la subtilite dela solution est la partie composee de l’Event Collector (JBoss ESB) et l’application degestion de la plate-forme. En effet, l’application de gestion dispose d’une interface SOAPpour les appels distants. Parallelement a cela, le JBoss ESB peut facilement manipulerle protocole SOAP. C’est pour cette raison que le protocole SOAP a ete choisi pour lacommunication 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 definie, il reste a savoir comment les applications du systemeinformatique de l’operateur vont communiquer avec le JBoss ESB. En effet, la solutionqui semble tenir la route consiste a utiliser ce meme protocole SOAP pour les requetesvenants de ces applications. Le choix du protocole SOAP n’est pas aleatoire car tous lesconcepteurs de logiciels l’utilisent aujourd’hui dans l’appel des web services.

A ce stade, nous savons que seul le protocole SOAP sera utilise pour la communi-cation entre les applications et le JBoss ESB. Cela est cense faciler la mise en place dela solution car les interfaces SOAP des applications ne vont pas changer. Toutefois, leJBoss ESB va venir s’inserer comme intermediaire dans la communication.

Maintenant que le protocole de communication est etabli, nous allons essayer detrouver une methode pour recevoir les requetes SOAP au niveau du JBoss ESB et lestraiter en vue de les renvoyer vers l’application de gestion de la plate-forme.

73

Figure 6.3 – Communication entre le JBoss ESB et les applications

6.2.2 Utilisation de gateways pour forwarder les requetes

La section 4.7.2 presente les gateways de l’ESB comme etant des composants in-ternes a l’ESB, capables de deplacer les messages de l’exterieur vers l’interieur de cedernier tout en leurs appliquant des transformations. Plusieurs types de gateways sontmis a disposition de l’utilisateur afin qu’il puisse connecter toutes les applications quirespectent les standards. Ici, nous allons nous concentrer sur un type recent de gateway :les gateways de type SoapProxy.

En effet, un gateway de type SoapProxy a la capacite de recevoir une enveloppeSOAP et de lui appliquer un ensemble d’actions. Il est principalement utilise pourrepresenter une reference externe utilisant les web services en la deployant commereference sur l’ESB. Ce dernier joue le role d’intermediare entre le consommateur deservice et le producteur de service final [9].

L’apport majeur de ce nouveau type de gateway 3 est la creation d’une couche d’abs-traction qui permet de regler les problemes suivants :

– Fournir un decouplage lache entre le client et le service, ils sont completementindependant dans ce cas.

– Le client ne doit plus etablir une connection directe avec le nom de machine oul’adresse IP du service distant.

– Le client va acceder au WSDL 4 qui modifie les parametres de l’emetteur et durecepteur afin que les requetes transitent par lui.

– La transformation de l’enveloppe SOAP et de son contenu peut etre effectuee auniveau de l’ESB. Pour cela, il suffit de definir une action qui sera declenchee aumoment de la reception de la requete.

– Le versionning des service (section 4.6).

3. Disponible a partir de la version 4.7 de JBoss ESB

4. Pour plus d’information sur ce langage, consulter la section 4.5.1

74

– Le routage des requetes en se basant sur le contenu. En d’autre termes, l’ESB peutdetecter la nature de la requete et la renvoyer a un service particulier sans que cedernier ne soit indique dans la requete initiale.

Figure 6.4 – Utilisation d’un gateway de type SoapProxy

L’action qui peut etre executee au niveau du gateway SoapProxy :– Est a la fois, un producteur et un consommateur de web services.– Necessite une seule propriete qui indique la reference externe du WSDL.– Permet de transformer automatiquement le WSDL reference par cette propriete.– Permet d’utiliser une fonction de routage pour atteindre le service final (Grace

notamment a la propriete HttpRouter).

6.2.3 Utilisation d’un gateway de type SoapProxy

Plusieurs proprietes peuvent etre definies au niveau de ce type de gateway [9] :– wsdl cible : represente le wsdl reference par le gateway et qui sera reecrit et

expose comme etant un nouveau wsdl sur l’ESB. En fonction de l’attribut addressutilise dans l’element soap indiquant le protocole de communication (“http” parexemple), une implementation specifique pour ce protocole sera utilisee grace a laclasse SOAPProxyTransport.La valeur de ce parametre peut utiliser differents schemas : http, https, file, class-path ou un lien interne a 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

75

– wsdlTranform : Ce parametre indique le fichier xml contenant la configurationpour une eventuelle transformation des requetes SOAP.

– Url de la reference : peut etre utilise pour indiquer un ensemble de proprietescomme le routage utilise, etc.

– fichier : utilise lorsque le web service externe utilise la technologie SSL.– clientCredentialsRequired : indique si le client doit etre identifie et si un fichier

doit etre utilise pour l’authentification.

L’exemple suivant montre une implementation d’un gateway SoapProxy utilisant uneauthentification + ssl :

Figure 6.5 – Implementation d’un gateway SoapProxy

6.3 Implementation de la solution d’integration

La solution que nous proposons ici consiste en un projet deployable sur un JBossESB. Avant d’expliquer la structure de ce projet, nous allons preparer l’environnementd’execution.

6.3.1 Installation et configuration de l’environnement de deploiement

Le JBoss ESB 4.7 est un outil open source disponible gratuitement sur l’adressesuivante : http://www.jboss.org/jbossesb/downloads.html. Bien qu’il s’agisse d’unoutil extrement sophistique, il existe une version de JBoss ESB compilee sous formed’application web et deployable sur un serveur applicatif. C’est cette version que nousallons utiliser pour l’implementation de la solution d’integration.

Le serveur applicatif qui sera utilise ici est celui de JBoss. La version 5.1 de ce dernierpeut etre telechargee sur cette adresse http://jboss.org/jbossas/downloads/.

Enfin, il importe de verifier que la version du Java Development Kit (JDK) utiliseepar defaut au niveau du systeme d’exploitation est au moins egale a 1.6.0 17.

Installation de JBoss ESB sur un JBoss Application Server

Le JBoss AS ne necessite aucune installation. Il suffit de decompresser le repertoiretelecharge dans un repertoire de son choix pour pouvoir l’utiliser. Ainsi, pour lancer ceserveur il suffit d’executer le fichier batch run qui se trouve dans le sous-repertoire bin.Afin de faciliter le deploiement, nous allons d’abord decompresser le JBoss ESB dans unrepertoire donne et ensuite y mettre le repertoire de JBoss AS. Au final, nous devonsavoir cette structure :

76

Figure 6.6 – Contenu du repertoire jbossesb-4.7

Plusieurs elements doivent etre modifies afin de combiner le JBoss ESB avec le JBossAS :

1. Aller dans jbossesb-4.7/install et modifier le fichier deployement.properties en in-diquant le home directory du serveur applicatif.

Exemple :org.jboss.esb.server.home=/Users/mohammedjelti/Desktop/jbossesb-4.7/jboss-5.1.0.GA

2. Se mettre dans le repertoire de jbossesb-4.7/install et lancer Ant deploy 5.Le fichier build.xml contient la liste des taches necessaires au deploiement de l’ap-plication represenant l’ESB sur le JBoss AS.

3. Sauvegarder le fichier jbossesb-4.7/jboss-5.1.0.GA/server/default/deploy/admin-console.war/plugins/rhq-jbossesbplugin-2.3.1-as4.jar

4. Supprimer jbossesb-4.7/jboss-5.1.0.GA/server/default/deploy/admin-console.war/

5. Telecharger le fichier war suivant http://repository.jboss.org/maven2/org/jboss/jopr/jopr-embeddedjbas5/1.3.2.GA/jopr-embedded-jbas5-1.3.2.GA.war.

6. Extraire ce fichier dans jbossesb-4.7/jboss-5.1.0.GA/server/default/deploy/

5. Telecharger Ant Apache si necessaire sur http://ant.apache.org/

77

7. Copier le fichier [rhq-jbossesbplugin-2.3.1-as4.jar] sauvegarde dans le repertoire[jbossesb-4.7/jboss-5.1.0.GA/server/default/deploy/admin-console.war/plugins/]

8. Dans le repertoire jbossesb-4.7/jboss-5.1.0.GA/server/default/deploy/, localiser lefichier /profileservice-secured.jar/META-INF/ejb-jar.xml et modifier le texte del’element res-ref-name en java :profileService (3 occurences).

9. Dans ce meme repertoire, localiser le fichier profileservice-jboss-beans.xml et mo-difier le contenu de l’element property dont le nom est jndiName en java :pro-fileService (1 occurence)

10. Copier les quatres fichiers ci-dessous de jbossesb-4.7/jboss-5.1.0.GA/client versjbossesb-4.7/jboss-5.1.0.GA/lib/endorsed– jbossws-native-jaxrpc.jar– jbossws-native-jaxws-ext.jar– jbossws-native-jaxws.jar– jbossws-native-saaj.jar

11. Telecharger jbossws-native-3.2.1.GA sur le site de jboss.

12. Decompresser le repertoire 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-5.1.0.GA

15. Se mettre dans le repertoire jbossesb-4.7/jbossws-native-bin-dist/ et executer lacommande suivante :ant deploy-jboss510

A ce stade, le JBoss ESB est completement deploye sur le JBoss AS. Pour verifiercela, il suffit de lancer le JBoss AS via le batch run qui se trouve dans le repertoirejbossesb-4.7/jboss-5.1.0.GA/bin. L’ecran suivant(Figure 6.7) est cense s’afficher au boutde quelques secondes de demarrage.

La console d’administration devra afficher les statistiques du JBoss ESB en plus desapplications et des ressources deployes sur le JBoss AS.

6.3.2 Structure du projet

La solution que nous proposons ici consiste a ouvrir un EPR (section 4.7.2) sur l’ESBpour qu’il puisse recevoir les requetes SOAP destinees aux EJBs. Nous avons montre

78

Figure 6.7 – Demarrage de JBoss AS combine avec JBoss ESB

Figure 6.8 – Console d’administration du JBoss AS combine avec JBoss ESB

dans la section precedente que le JBoss ESB est combine au serveur applicatif JBossAS. Nous supposons ici que les EJBs sont deployes sur ce meme serveur applicatif. Ainsila redirection des requetes au niveau du gateway de l’ESB fera appel a un EJB qui seradeploye en local.

La projet ESB est constitue de plusieurs fichiers :

– Le fichier jboss-esb.xml : contient la configuration du gateway qui sera deploye surle JBoss ESB.

– Le fichier jbossesb-properties.xml : contient les parametres de configuration deJBoss ESB.

– Le fichier deployment.xml : decrit les ressources necessaires a l’execution du servicedeploye.

– Le fichier jndi.properties : indique au client ou se trouve le serveur applicatif.– Le fichier build.xml : contient des taches Ant 6 pour la compilation, l’execution,

le test et le deploiement du service.

Seul le contenu du fichier jboss-esb.xml sera detaille par la suite. Les autres fichiers sontdes fichiers de configuration fournis par JBoss AS.

Ce fichier (Figure 6.11) decrit le nouveau service qui sera deploye sur l’ESB. Eneffet, CompanyAccessService dispose d’un gateway http qui recoit les requetes SOAP en

6. http://ant.apache.org/

79

Figure 6.9 – Contenu du fichier jboss-esb.xml

declenchant une action qui utilise la classe org.jboss.soa.esb.actions.soap.proxy.SOAPProxypour renvoyer les requetes vers

http ://127.0.0.1 :8080/test-Company–Alcatel- Lucent–v1.EJB/CompanyAccessBean

Finalement, c’est le lien suivant qui sera utilise pour appeler l’EJB en passant parl’ESB.

http ://localhost :8080/esbgateways/http/alcatel-lucent/companyAccessService

6.3.3 Deploiement du projet

Le deploiement de ce service est effectue grace a la tache Deploy contenue dansle fichier build.xml. En effet, losque la commande Ant est disponible dans le systemed’exploitation, il suffit de se mettre dans le repertoire du projet et tapper ant deploypour que le service soit immediatement deploye au niveau de l’ESB.

6.3.4 Test du projet

Tester le fonctionnement du nouveau service deploye sur l’ESB consite a creer unprojet Java qui appelle le service suivant :

http ://localhost :8080/esbgateways/http/alcatel-lucent/companyAccessService

Nous constatons alors que le service redirige correctement les requetes et que lesreponses de l’EJB sont bien renvoyees a l’application appelante.

80

6.4 Generation automatique de la solution

Le souhait initial de l’equipe d’Alcatel-Lucent etait de pouvoir generer automatique-ment une solution d’integration pour l’application de gestion de la plate-forme. En effet,le projet que nous avons decrit ci-dessus doit etre genere automatiquement en se basantsur le modele EMF representant le profile JAIN SLEE (figure 5.2).

Pour ce faire, nous avons du creer un Plugin Eclipse (section 4.4) representant ungenerateur JET (ensemble de templates) capable de generer un projet ESB deployabledirectement sur un JBoss ESB. Deux templates essentiels vont etre decrits dans la suite.Il s’agit bien entendu du template d’entree qui amorce la transformation ainsi que decelui qui genere le fichier de configuration du gateway, a savoir jboss-esb.xml.

Avant d’entamer l’explication des generateurs JET, il faut dire qu’une regle de nom-mage a ete etablie par l’equipe d’Alcatel-Lucent pour les EJBs generes automatique-ment lors de la transformation. Le nom de l’EJB representant le profile JAIN SLEEest compose du nom du profile (exemple : Company) suivi de “AccessService”. C’est laseule information qui sera necessaire lors de l’appel des EJBs finaux. Autrement dit, laseule information parametrable qui sera passee au transformateur est le nom de l’EJB(exemple companyAccessService). Afin de faciliter les choses, nous allons passer une seuleinformation au generateur, une variable contenant le nom du l’EJB.

La figure 6.10 montre le conteu du fichier main.jet. Ce dernier represente le fichierprincipal qui est execute lors de l’appel du Plugin de la transformation. Nous montreronsplus tard, grace a un exemple, comment appele ce Plugin a partir d’un autre PluginEclipse.

6.4.1 main.jet

Figure 6.10 – Main.jet

81

Le nom du profile est passe en parametre au generateur JET. Grace a la commande contexte.getSource(),nous pouvons recuperer le contenu de cette variable. Ainsi, la cinquieme ligne du fichier main.jet illustrela recuperation du nom du profile sous forme de String.

Dans la suite du template main.jet, l’instruction ws :project permet de creer un projet nomme ge-neratedEsbEpr. La dixieme ligne cree un nouveau repertoire dans lequel seront sauvegarde les fichiersgeneres. Ainsi, pour chaque fichier genere, un template est indique grace a l’instruction ws :file qui recoit lenom du fichier genere et le template a utiliser. Il est a noter que chaque template peut appeler la methodecontexte.getSource() pour recuperer la valeur du parametre initial.

6.4.2 jbossesb.xml.jet

Figure 6.11 – jbossesb.xml.jet

Comme explique precedemment, l’instruction contexte.getSource() permet d’intialiser une variable lo-cale contenant le nom du profile. Cette derniere peut etre utilisee librement dans le template courant. Nouspouvons remarquer qu’a la ligne 18, le nom du service genere sera compose du nom du profile concateneavec la chaine AccessService .

Apres la definition de ces templates et leur compilation. L’ensemble du projet doit etre exporte entant que Plugin Eclipse et sera appele a partir d’un autre plugin grace a son identifiant. Rappelons quel’identifiant d’un plugin doit etre indique au niveau du fichier Manifest du projet Eclipse. Dans notre cas,l’identifiant attribue au plugin de transformation est : alu.esbEprTransformer.

Afin de lancer la transformation, le plugin predecemment decrit doit etre mis dans les dependances duplugin qui va lancer la transformation. Ici, nous allons nous contenter de completer la classe principale duplugin appelant afin de lancer la transformation au demarrage du plugin (figure 6.12). Remarquons que les

82

deux methodes START et STOP (section 4.4.3) sont declenchees respectivement au demarrage et a l’arretdu plugin.

La figure 6.13 montre l’execution de la transformation, notamment en initialisant une variable de typeJET2Context representant le nom du profile. Ainsi, la methode runTransform de la classe JET2Plateformva assurer la transformation de l’objet en se basant sur l’identifiant du plugin contenant les templates,l’objet qui sera transforme ainsi qu’un objet heritant de org.eclipse.core.runtime.IProgressMonitor pourmesurer la progression de la transformation.

Figure 6.12 – contenu de la classe Activator du Plugin

Figure 6.13 – Execution de la transformation JET

Chapitre 7

Conclusion

Dans ce travail, nous avons considere un probleme d’integration d’une applicationdans un systeme informatique. Loin des details techniques de l’integration, nous avonsessaye, dans le deuxieme chapitre, de comprendre les differentes tendances architec-turales qui peuvent etre d’application au niveau des systemes informatiques. Il s’agitd’une etude de l’art qui nous permet de comprendre les besoins et les exigences desentreprises en vue de faire un choix strategique d’integration. Le premier grand defide ce travail fut d’analyser les differentes couches du systeme informatique des entre-prises afin de mettre le doigt sur les points primordiaux qui preoccupent les dirigeantsIT. Nous avons aussitot compris qu’une integration d’applications qui est faite dansles regles de l’art doit enrichir le systeme informatique et non pas l’handicaper. Notreobjectif fut alors, de fournir une approche nouvelle capable de faciliter l’integrationd’applications tout en rendant l’ensemble du systeme informatique plus evolutif et plusefficace.

La nouvelle approche que nous avons proposee n’est rien d’autre qu’EDA. En effet,ce concept devrait se generaliser dans un futur proche pour completer SOA, et ainsipermettre aux concepteurs des architectures IT de profiter des evenements declenchesau niveau de l’entreprise, pour construire un systeme informatique capable de reagir demaniere intelligente aux evenements. Dans le troisieme chapitre, le lecteur aura trouveune analyse complete de ce type d’architecture ainsi que les differents aspects lies a sonimplementation.

Par ailleurs, il est evident qu’une integration reussie doit prendre en consideration lastructure de l’application concernee et les outils utilises dans son developpement. Celarepresente le troisieme volet qui a ete etudie dans ce memoire. Nous avons pu constateque les fournisseurs IT utilisaient des technologies nouvelles (MDA, EMF, JET, etc)afin d’accelerer le developpement de leurs produits.

En ayant une connaissance approfondie de ces trois elements, a savoir : l’existantau niveau de l’entreprise, la structure de l’application a integrer et enfin l’approchea adopter, nous avons pu montrer la validite de cette approche d’integration qui, audela de ses objectifs propres, permet aux applications du systeme informatique d’etreconstruites de maniere plus reactive, plus souple et plus flexible.

Naturellement, chaque solution a ses avantages et ses inconvenients. Parmi lesrisques que presente cette solution, nous pouvons citer le fait que toute l’architec-ture soit basee sur une entite centrale qui collecte les evenements. Celle-ci n’est pas

83

84

a l’abri de certains problemes techniques qui peuvent bloquer toutes les applicationscommunicantes. Nous pouvons dans ce cas, envisager l’utilisation d’un cluster ESBcomme Event Collector afin de pallier aux problemes de surcharge et aux problemestechniques. Une instance du cluster pourra reprendre les taches d’une autre instancelorsque cette derniere tombe en panne. Cela etant, la configuration de ce point cen-tral qui est l’Event Collector doit etre faite dans les regles de l’art. L’evolution dechaque flux d’evenements doit etre etudiee au prealable afin de prevoir les ressourcesnecessaires a son traitement.

Enfin, l’adoption d’une EDA necessite des competences nouvelles de la part desanalystes metier. En effet, dans le troisieme chapitre, nous avons presente l’ensembledes concepts de base d’EDA. Une methodologie de conception ainsi qu’un ensembled’outils de support doivent etre maıtrises afin de mettre en pratique tous ces concepts.

Bibliographie

[1] Addison-Wesley, editor. Event Driven Architecture, how SOA enables the Real-timeEnteprise. pearsontechgroup.com, 2009.

[2] Amazon.com. Amazon elastic compute cloud (amazon ec2). http://aws.amazon.com/ec2/, consulte le 10 juillet 2010.

[3] Amazon.com. Amazon simple storage service. http://aws.amazon.com/s3/,consulte le 10 juillet 2010.

[4] MEAP Edition, editor. Event Processing in action. Manning Publications Co, 2010.

[5] Google.com. Google app engine. GoogleAppEngine,http://code.google.com/appengine/, consulte le 10 juillet 2010.

[6] Jeff Hanson. Event-driven services in soa. Design an event-driven and service-oriented platform with Mule.

[7] SYS-CON Media Inc, editor. Twenty Experts Define Cloud Computing.http ://cloudcomputing.sys-con.com/read/612375/pr.htm, 2008.

[8] jainslee.org. Jain slee fundamentals. http://www.jainslee.org/slee/fundamentals.html, consulte le 19 juillet 2010.

[9] jboss.org. Class soapproxy. http://docs.jboss.org/jbossesb/docs/4.7/javadoc/esb/org/jboss/soa/esb/actions/soap/proxy/SOAPProxy.html,consulte le 14 Mai 2010.

[10] linxterdeveloper.com. Linxter internet service bus. http://linxterdeveloper.com/platform-overview/isb-services, consulte le 20 juin 2010.

[11] Joe McKendrick. Why business process management and complex event processingare converging. http://www.zdnet.com/blog/service-oriented/title/4071,consulte le 12 Mai 2010.

[12] Jack Vanhoof. How eda extends soa and why it is important. http://soa-eda.blogspot.com/2006/11/how-eda-extends-soa-and-why-it-is.html, consultele 13 Mai 2010.

[13] Janaka Balasooriya Wei-Tek Tsai*, Xin Sun. Service-oriented cloud computingarchitecture. 2010 Seventh International Conference on Information Technology.

85

Table des figures

2.1 Couches applicatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 processus metier : vente de produits sur internet . . . . . . . . . . . . . 7

2.3 Entreprise Application Integration . . . . . . . . . . . . . . . . . . . . . 10

2.4 Illustration de l’Architecture Hub and spoke . . . . . . . . . . . . . . . . 11

2.5 Illustration de l’Architecture Bus . . . . . . . . . . . . . . . . . . . . . . 11

2.6 Enterprise Service Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.7 La relation Publish and Subscribe . . . . . . . . . . . . . . . . . . . . . 14

2.8 Architecture d’une application Java entreprise . . . . . . . . . . . . . . . 17

2.9 Modele-Vue-Controleur . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.10 Modele-Vue-Controleur dans une application JEE . . . . . . . . . . . . . 20

2.11 Tout comme service. X= ? [13] . . . . . . . . . . . . . . . . . . . . . . . 21

2.12 Service Oriented Cloud Computing Architecture [13] . . . . . . . . . . 22

2.13 Linxter ISB [10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1 Architecture basee sur les evenements . . . . . . . . . . . . . . . . . . . 27

3.2 Exemple de processus metier-1 [1] . . . . . . . . . . . . . . . . . . . . . 29

3.3 Exemple de processus metier-2 [1] . . . . . . . . . . . . . . . . . . . . . 29

3.4 ESB comme Event Collector . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.5 Illustration d’une instance d’un reseau de traitement d’evenements [4] 33

3.6 Elements de definiton pour les consommateurs d’evenements . . . . . . 35

3.7 Illustration d’une EDA qui utilise un reseau de EPA [4] . . . . . . . . 36

3.8 Composants de l’EDA + SOA . . . . . . . . . . . . . . . . . . . . . . . . 39

3.9 Services de la SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.10 Exemple d’implementation d’EDA utilisant un ESB . . . . . . . . . . . 41

3.11 Utilisation de SOA pour executer les actions . . . . . . . . . . . . . . . . 44

4.1 PIM + PM = PSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.2 Fonctionnement de EMF . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.3 Exemple d’instance d’un modele Ecore vue sous forme d’arbre . . . . . . 52

86

87

4.4 Exemple d’instance d’un modele Ecore dans l’editeur graphique . . . . . 53

4.5 Transformation d’un modele EMF + JET . . . . . . . . . . . . . . . . . 54

4.6 Architecture OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.7 Cycle de vie d’un Bundle . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.8 Utilisation des services du JBoss Application Server . . . . . . . . . . . 59

5.1 Integration de la plate-forme NGIN dans l’environnement de l’operateur 66

5.2 Exemple de deux profiles crees dans Eclipse . . . . . . . . . . . . . . . . 67

5.3 Illustration du fonctionnement d’un EJB + portlet . . . . . . . . . . . . 69

6.1 Integration grace a EDA . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6.2 Communication entre le JBoss ESB et l’application de gestion . . . . . . 72

6.3 Communication entre le JBoss ESB et les applications . . . . . . . . . . 73

6.4 Utilisation d’un gateway de type SoapProxy . . . . . . . . . . . . . . . . 74

6.5 Implementation d’un gateway SoapProxy . . . . . . . . . . . . . . . . . 75

6.6 Contenu du repertoire jbossesb-4.7 . . . . . . . . . . . . . . . . . . . . . 76

6.7 Demarrage de JBoss AS combine avec JBoss ESB . . . . . . . . . . . . 78

6.8 Console d’administration du JBoss AS combine avec JBoss ESB . . . . 78

6.9 Contenu du fichier jboss-esb.xml . . . . . . . . . . . . . . . . . . . . . . 79

6.10 Main.jet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

6.11 jbossesb.xml.jet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6.12 contenu de la classe Activator du Plugin . . . . . . . . . . . . . . . . . . 82

6.13 Execution de la transformation JET . . . . . . . . . . . . . . . . . . . . 82

A.1 Event Collector utilisant un ESB . . . . . . . . . . . . . . . . . . . . . . 89

A.2 Event Collector utilisant MuleESB . . . . . . . . . . . . . . . . . . . . . 90

A.3 Event Collector utilisant un JMS . . . . . . . . . . . . . . . . . . . . . . 91

A.4 AMQP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

A.5 Utilisation des services de la SOA en tant que consommateurs d’evenements 92

A.6 Illustration d’un Event Collector distribue utilisant des ESB . . . . . . . 93

A.7 Architecture d’un moteur CEP . . . . . . . . . . . . . . . . . . . . . . . 94

A.8 pattern N°1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

A.9 paterne N°2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

A.10 pattern N°3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

A.11 pattern N°4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

A.12 pattern N°5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

A.13 pattern N°6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

A.14 pattern N°7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Annexe A

Rapport du stage en entreprise

Le but du stage realise chez Euranova 1 etait de montrer comment on peut mettreen oeuvre une EDA en utilisant des outils Open Source. Ce rapport contient l’essentieldes patterns d’implementation pour une telle architecture. Il est a noter que tous cespatterns ont ete mis en pratique lors du stage afin d’en verifier la validite et surtoutles performaces.

A.1 Implementation d’un Event Collector

Le role principal d’un Event Collector dans une architecture EDA est la collectedes evenements provenant de differentes sources.

Outre la collecte des evenements sous forme de messages, l’Event Collector assurela standardisation de leurs contenus. Ceci permet aux autres acteurs de l’architectureEDA de manipuler un seul type de messages. Pour ce faire, un modele unique doit etredefini au niveau de l’entreprise afin de modeliser les messages qui sont censes transporterles donnees des evenements. Parallelement a cela, des outils de transformation doiventetre developpes en vue de rendre tous les messages conformes au modele predefini.

Ici nous allons montrer comment utiliser certaines solutions Open-source pourconnecter differentes sources d’evenements, assurer le formattage des messages et laconversion des protocoles.

A.1.1 En utilisant un Enterprise Service Bus

Le role principal d’un Enterprise Service Bus est d’assurer l’integration des appli-cations. Autrement dit, il assure l’integration des donnees provenants de differentessources afin qu’elles puissent etre utilisees par le reste du systeme informatique. Cecicorresponds exactement au comportement de l’Event-Collector qui assure la receptiondes evenements et leur standardisation avant de les transmettre aux autres acteurs del’architecture EDA.

1. Euranova est une societe de conseil en innovation technologique creee en septembre 2008, elle

collabore avec des grandes firmes comme Alcatel-Lucent.

88

89

JBoss ESB

La communication entre l’event generator et l’Event Collector est demarree lors-qu’un evenement se produit au niveau de l’event generator, le gateway s’occupe dutransfert et de la transformation du contenu de l’evenement. L’ESB heberge, en outredes gateway, des services d’integration qui peuvent etre utilises pour manipuler lesevenements.

Figure A.1 – Event Collector utilisant un ESB

MuleESB

Dans son livre “Manning Mule in Action”, Ross Mason -Cofondateur de MuleSource-evoque toutes les infrastructures IT construites sans qu’aucune logique metier ne soitdefinie. Cette infrastructure fonctionne, d’apres lui, comme un travail d’ane (d’ou lenom de son programme).

Mule est un ESB Open Source concu comme un event-driven framework combineavec une representation unifiee des messages, extensible avec des modules pluggable.Ces derniers offrent une large gamme de fonctionnalites qui assurent,entre autres, lagestion des transactions, la securite, le traitement et la transformation des messages.Cela etant, cet ESB peut etre utilise exactement de la meme maniere que dans le casde JBoss ESB. Les gateways sont appeles connecteurs ici(connectors).

Il existe des connecteurs pour les fichiers, les base de donnees, les JMS et autres.Il est meme possible de definir son propre connecteur en utilisant l’API de Mule. Clai-rement, il faudra definir un nouveau service avec des connecteurs qui vont chercher lesdonnees et les transformer pour les mettre a disposition des routeurs. Ces derniers vontles diriger en fonction de leurs caracteristiques. Il est a noter que au coeurs de chaqueservice se trouve un component entoure de routeurs. Son role est de recevoir, de traiteret de renvoyer les messages. Ce sont les composants de ce type qui seront utilises pourtraiter les messages representant les evenements.

90

Figure A.2 – Event Collector utilisant MuleESB

A.1.2 En utilisant une Queue (Java Messaging Service)

JMS est un composant(API) essentiel de JEE. il permet d’envoyer et de recevoirdes messages de maniere asynchrone entre applications ou composants Java.

Pour utiliser l’API JMS, il est necessaire d’utiliser un fournisseur de service quigere les connections, les sessions, les destinations et les messages. Il y a de multiplesfournisseurs de service JMS. Certains permettent meme d’appliquer des transformationssur les messages, ce qui est fort interessant lorsqu’on cherche a utiliser le fournisseurde service comme Event Collector.

Deux Styles de messagerie s’offrent aux concepteurs lors la mise en place d’un JMSen tant qu’ESB.

– Queue : Ce style definit une relation point-to-point (one-to-one) ou les messagesdu producteur sont persistes avant d’etre consommes. Il est a noter que chaquemessage doit etre consomme par un seul consommateur.

– Topic : Il s’agit d’une relation publish-and-subscribe (one-to-many). Les produc-teurs envoient leurs messages dans une entite appelee Topic. Les consommateursqui sont inscrits dans ce topic recoivent une copie de chaque message recu par letopic.

Plusieurs protocoles standards en vue le jour afin de faciliter la communicationentre client et le fournisseur JMS ( JBossMessaging par exemple).

– JMS : pour les applications ecrites en Java.– STOMP : un protocole tres simple d’utilisation avec les systemes de messagerie.– Advanced Message Queuing Protocol (AMQP) : protocole emergeant qui

assure l’interoperabilite d’echange des messages.– Representational state transfer (REST) : Dans cette approche, les res-

sources de messagerie sont manipulees comme des ressources definies par des URIet utilisent des operations simples tel que PUT, POST, GET ..

– des API proprietaires peuvent etre developpe pour assurer la communicationentre le client et le systeme de messagerie.

91

Figure A.3 – Event Collector utilisant un JMS

A.1.3 En utilisant un ESM (Enterprise Messaging System)

Appele aussi MOM. Il s’agit d’un middleware a base de messages qui se charged’acheminer les messages d’une application a une autre. Cet outil est souvent meconnuet sous-utilise au sein des ESB afin d’assurer le decouplage lache et la garantie d’ache-minement.

Certains solutions Open-Source ont vu le jour grace notamment au developpementdu protocole open-souce AMQP. En effet, La conception d’un MOM Open-sourcenecessite l’utilisation d’un protocole d’echange ouvert et oriente message qui est ca-pable de :

– Standardiser les echanges,– Gerer les files d’attentes,– Router les messages,– Assurer la securite et la fiabilite des echanges.

C’est le cas du protocole AMQP.

Il existe plusieurs outils qui utilisent ce protocole et qui fonctionnent en modeasynchrone. (OpenAMQ ou RabbitMQ en sont des exemples)

Parmi les fonctionnalites offertes par OpenAMQ, on peut citer :– Implementation du patterns publish-and-subcribe,– Queues partagees ou privees,– Support de messages de grande taille (jusque 4Go).

92

Figure A.4 – AMQP

A.1.4 En utilisant les Web Services de la SOA

Beaucoup d’entreprises disposent d’une architecture SOA aujourd’hui d’ou l’ideed’exposer de nouveaux services capables de recevoir des evenements sous forme d’enve-loppe SOAP et de les integrer dans le systeme de messagerie. un Enterprise MessagingSystem (ESM) (section A.4) peut etre utilise comme outil de messagerie dans ce cas-ci.

Figure A.5 – Utilisation des services de la SOA en tant que consommateursd’evenements

93

A.1.5 Event Collector distribue

L’Event Collector reste une entite sensible dans une EDA. En effet, a l’instar durouteur reseau, des millions de messages vont transiter via ce point central qui n’estpas a l’abri des pannes. Pour pallier aux problemes de surcharge et aux problemestechniques, un Event Collector distribue peut etre mis en place afin de distribuer lacharge du systeme sur l’ensemble des unites qui composent l’Event Collector. Ainsi,des services de mediation doivent etre mis en place pour assurer le load-balancing etla synchronisation des differentes instances. La figure A.6 montre une implementationd’un Event Collector distribue utilisant un ensemble d’ESB exposant plusieurs EPR.Ces derniers representent les services d’integrations des evenements.

Neanmoins, cette solution reste extrement compliquee a mettre en place. Une mau-vaise configuration risque de modifier les performances et ainsi ralentir la circulationdes messages.

Figure A.6 – Illustration d’un Event Collector distribue utilisant des ESB

94

A.2 Implementation d’un CEP

La principale caracteristique d’un moteur CEP est qu’il est concu pour le tempsreel. L’Event Collector permet de concenter les flux d’evenements en vue de les delivrerau moteur CEP. Ce dernier analyse les evenements recus afin de detecter des modelesd’evenements appeles aussi des patterns. Les flux d’evenements arrivent au CEP sousplusieurs formes et partagent des caracteristiques communes :

– Les evenements sont classes grace au timeStamp (attribut de l’evenement).– Le volume d’evenement est toujours important.– Les flux d’evenements doivent etre homogenes (ils doivent contenir le meme type

d’evenement).

La figure A.7 montre l’achitecture d’une solution commerciale d’un moteur CEP.Nous pouvons constater differents points d’entree, ce qui n’est d’ailleurs pas toujoursle cas dans les moteurs CEP. En effet, certaines solutions n’offrent qu’un seul pointd’entree, ce qui impose l’utilisation d’un Event Collector pour fournir, au final, un seulflux regroupant tous les flux recus par l’Event Collector. Dans l’architecture presentee ala figure A.7, des adaptateurs peuvent etre mis en oeuvre au niveau des points d’entreesen vue d’appliquer des transformations sur les flux entrants. Autrement dit, ce moteurCEP est concu pour fonctionner sans Event Collector mais avec un nombre limite deflux. Cela ne change en rien l’importance accordee a l’Event Collector dans une EDAcar ce dernier assure la collection mais surtout le redistribution des evenements au restedu systeme.

Apres les points d’entree, les evenements sont routes vers un moteur de regles quiessaie de detecter des dependances basees sur la sequence, sur la repetition ou sur letemps.

Figure A.7 – Architecture d’un moteur CEP

95

A.3 Patterns d’implementation pour une EDA

Les diagrammes d’Activite sont un meilleur moyen qui permet de montrer comment les differentsflux d’evenements peuvent etre achemines a travers une EDA. Chaque generateur d’evenements (premierecolonne de la figure A.8) est branche a l’ESB (deuxieme colonne) via un gateway qui, apres avoir transformeles donnees de l’evenement, fait appel au MOM pour le deplacement du message a l’interieur de l’ESB.Dans cet exemple, nous supposons que plusieurs Queues sont definies au niveau de l’ESB, chacune de cesQueues va stocker un type de messages. Cela permet de regrouper les evenements qui peuvent etre liesdans une seule Queue et ainsi faciliter le travail du moteur CEP. En effet, ce dernier peut utiliser sesadaptateurs d’entree pour lire les evenements qui sont stockes dans les Queues.

Le moteur CEP peut declencher des actions metier lorsque la condition d’une regle est verifiee. cetteaction est censee produire un nouvel evenement qui notifie l’Event Collector. le gateway2 permet de trans-former le contenu de cet evenement afin qu’il soit injecte au niveau de l’Event Collector pour etre analyseavec l’ensemble des evenements.

Enfin, le generateur des evenements necessite parfois une reponse de la part du systeme. Une queue auniveau de l’ESB peut etre prevue a cet egard. Les messages destines au generateur d’evenements peuventetre stockes au niveau de cette Queue pour etre consommes plus tard.

Figure A.8 – pattern N°1

96

Nous avons vu dans le pattern precedent que l’utilisation de plusieurs Queues permet de classer lesevenements en vue de les transferer vers le moteur CEP. Certaines solutions de moteur CEP n’acceptentqu’un seul flux d’evenements en entree. L’utilisation d’un composant ou un agent(colonne 3 de la figure A.9)pour concentrer tous ces flux resout le probleme d’entree unique au niveau du moteur CEP. Ce composantva lire les evenements dans les Queues et en faire un seul flux utilisable par le moteur CEP. Notons que leCEP represente une source importante d’information temps reel, un BAM peut etre connecte au moteurCEP afin de benificier de notifications en temps reel.

Figure A.9 – paterne N°2

97

L’utilisation de plusieurs moteurs CEP peut accelerer l’analyse et la detection de patterns au niveaudes flux d’evenements. La figure A.10 montre plusieurs moteurs CEP connectes aux Topics de l’ESB.Rappelons qu’un Topic peut etre lu par plusieurs consommateurs.

Les differents moteurs CEP peuvent fonctionner en parallele et generer des notifications ainsi que denouveaux evenements qui sont injectes au niveau de l’Event Collector. Il est evident que la surcharge d’unmoteur CEP peut ralentir le fonctionnement du systeme d’ou l’idee de mettre plusieurs instances capabled’analyser les differents flux en parallele.

Figure A.10 – pattern N°3

98

Ce dernier pattern qui utilise un ESB en tant qu’Event Collector illustre le cas de plusieurs generateursd’evenements qui communiquent avec l’Event Collector via des gateways. Chaque gateway est cense rece-voir un type de messages afin de lui apporter les transformations necessaires. La premiere colonne de lafigure A.11 montre qu’il est tout a fait possible de connecter deux generateurs d’evenements via un memegateway pour vu qu’ils utilisent le meme format de messages. L’utilisation de Topics ou de Queues auniveau de l’ESB ne changera pas l’implementation car seul l’agent CEP est cense lire ces evenements (unseul consommateur).

Figure A.11 – pattern N°4

99

Comme explique dans la section A.3, un fournisseur de JMS (exemple : JbossMessaging) peut etre utiliseen tant qu’Event Collector. Le JBossMessaging offre un ensemble de fonctionnalite visant la facilitationdes traitements sur les messages. En effet, des composants appeles Bridges ont la capacite de deplacer del’information de l’exterieur vers l’interieur du fournisseur de JMS. Cette information peut etre stockee sousforme de message au niveau d’un Topic ou d’une Queue.

Le reste du pattern est semblable au Pattern N°1.

Figure A.12 – pattern N°5

100

Les fournisseurs de JMS sont devenus tres performants et peuvent etre utilises comme un middlewareou un outil de messagerie. Le pattern suivant illustre l’exploitation de JBossMessaging comme EventCollector. L’agent du CEP est utilise pour preparer les flux d’evenements au moteur CEP.

Figure A.13 – pattern N°6

101

Les concepteurs de methodes d’integration s’interessent a tous les outils qui peuvent etre utilises commesystemes de messagerie entre les applications. Certaines implementations du protocole AMQP permettentde recevoir et de socker le messaege dans un Topic ou dans Direct Exchange. Il est donc tout a fait possibled’utiliser ce systeme de messagerie (colonne 2 de la figure A.14) afin de faire circuler les evenements entreproducteurs et consommateurs d’evenements. Le moteur CEP peut fonctionner exactement de la mememaniere qu’avec un ESB ou un fournisseur JMS.

Figure A.14 – pattern N°7