Étude et implémentation d'un moteur d'inférence dans une ...

117
FACULTÉ DES SCIENCES APPLIQUÉES COMPUTER & DECISION ENGINEERING DEPARTMENT Année académique 2009 - 2010 Étude et implémentation d’un moteur d’inférence dans une architecture orientée événements basée sur JSLEE Mémoire de fin d’études présenté par Smail Djerir sous la direction du Professeur Esteban Zimányi en vue de l’obtention du titre d’ingénieur civil informaticien à finalité ingénierie informatique MEMBRE DE L’ACADÉMIE UNIVERSITAIRE WALLONIE-BRUXELLES ET DU PÔLE UNIVERSITAIRE EUROPÉEN BRUXELLES WALLONIE

Transcript of Étude et implémentation d'un moteur d'inférence dans une ...

  • FACULT DES SCIENCES APPLIQUES COMPUTER & DECISION ENGINEERING DEPARTMENT

    Anne acadmique 2009 - 2010

    tude et implmentation dun moteur dinfrence dans

    une architecture oriente vnements base sur JSLEE

    Mmoire de fin dtudes prsent par Smail Djerir sous la direction du Professeur Esteban Zimnyi en vue de lobtention du titre dingnieur civil informaticien finalit

    ingnierie informatique

    MEMBRE DE LACADMIE UNIVERSITAIRE WALLONIE-BRUXELLES ET DU PLE UNIVERSITAIRE EUROPEN BRUXELLES WALLONIE

  • Remerciements

    Ma gratitude s'adresse particulirement mon co-promoteur Sabri Skhiripour sa disponibilit, sa bienveillance, ses conseils judicieux et ses encoura-gements qu'il m'a prodigu avec patience et gentillesse tout au long de laralisation de ce mmoire.

    Je remercie galement mon promoteur Pr. Esteban Zimanyi de m'avoirincit amliorer la qualit de mon travail, je tiens le remercier aussi pourle temps consacr la lecture de ce travail.

    Enn, je tiens remercier ma sur Habiba, mes amis Amine Ghoubali,Abdelkarim Ghoubali et Belkacem Kherrab qui m'ont aid, conseill et sou-tenu tout au long de l'anne.

    1

  • Rsum

    Ce travail propose d'tudier les moteurs d'infrence de type BRE et detype CEP an de crer une architecture hybride permettant de substituerle moteur d'infrence CEP par un moteur d'infrence de type BRE. Nousproposons une architecture hybride oriente vnements base sur le serveurd'application JSLEE. La premire partie prsente le concept des architec-tures orientes vnements et les moteurs d'infrence BRE et CEP. Nouscomparons ensuite les deux types de moteurs d'infrence avant de proposerdans la deuxime partie notre architecture hybride base sur JSLEE.

    2

  • Table des matires

    Introduction 8

    I tat de l'art 10

    1 L'architecture oriente vnement 11

    1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.2 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.3 Concepts SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.4 volution du SOA . . . . . . . . . . . . . . . . . . . . . . . . 151.5 EDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

    2 Les moteurs d'infrence BRE 24

    2.1 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.2 Dnition des Business Rules Engine . . . . . . . . . . . . . . 252.3 Dnition des rgles . . . . . . . . . . . . . . . . . . . . . . . 262.4 Intrt de BRE . . . . . . . . . . . . . . . . . . . . . . . . . . 262.5 BRE et SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.6 Architecture BRE . . . . . . . . . . . . . . . . . . . . . . . . . 272.7 Caractristiques des BRE . . . . . . . . . . . . . . . . . . . . 322.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

    3 Les moteurs d'infrence CEP 34

    3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.2 Dnition CEP . . . . . . . . . . . . . . . . . . . . . . . . . . 353.3 Motif d'vnement . . . . . . . . . . . . . . . . . . . . . . . . 373.4 Intrt du CEP . . . . . . . . . . . . . . . . . . . . . . . . . . 383.5 Cas d'utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 383.6 Architecture CEP . . . . . . . . . . . . . . . . . . . . . . . . 403.7 Dirence entre CEP et BRE . . . . . . . . . . . . . . . . . . 42

    3

  • 3.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

    4 JSLEE 45

    4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.2 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.3 Dnition JSLEE . . . . . . . . . . . . . . . . . . . . . . . . . 464.4 Version JSLEE . . . . . . . . . . . . . . . . . . . . . . . . . . 474.5 Architecture JSLEE . . . . . . . . . . . . . . . . . . . . . . . 474.6 Composants JSLEE . . . . . . . . . . . . . . . . . . . . . . . . 484.7 Architecture d'application SLEE . . . . . . . . . . . . . . . . 514.8 Dploiement des services . . . . . . . . . . . . . . . . . . . . . 524.9 Utilisation JSLEE . . . . . . . . . . . . . . . . . . . . . . . . . 524.10 Implmentations de JSLEE . . . . . . . . . . . . . . . . . . . 524.11 JSLEE mobicents . . . . . . . . . . . . . . . . . . . . . . . . . 534.12 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

    II Implmentation d'un moteur d'infrence dans unearchitecture EDA 55

    5 Extension BRE-CEP 56

    5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.2 Extensions d'algorithme d'infrence . . . . . . . . . . . . . . 575.3 Quelles sont les extensions BRE? . . . . . . . . . . . . . . . . 585.4 Exemple d'extension d'un BRE . . . . . . . . . . . . . . . . . 605.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

    6 Motivations et objectifs 72

    6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 726.2 Pourquoi un BRE la place d'un CEP? . . . . . . . . . . . . 736.3 Quel obstacle ? . . . . . . . . . . . . . . . . . . . . . . . . . . 746.4 Les grandes lignes de la solution . . . . . . . . . . . . . . . . . 756.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

    7 Spcication 77

    7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777.2 Fondements du projet . . . . . . . . . . . . . . . . . . . . . . 787.3 Contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797.4 Spcications fonctionnelles . . . . . . . . . . . . . . . . . . . 807.5 Spcications non fonctionnelles . . . . . . . . . . . . . . . . . 857.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

    4

  • 8 Analyse et conception 87

    8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 878.2 Les composants de l'architecture . . . . . . . . . . . . . . . . 888.3 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . 928.4 Dploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 948.5 Dnition d'vnement . . . . . . . . . . . . . . . . . . . . . 968.6 L'architecture rpond-t-elle aux attendus ? . . . . . . . . . . . 968.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

    9 Implmentation 98

    9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 989.2 L'vnement gnrique . . . . . . . . . . . . . . . . . . . . . . 999.3 Le Resource Adaptor Drools . . . . . . . . . . . . . . . . . . 1009.4 Le service Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 1059.5 Agent EDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1069.6 Agent X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1079.7 Exemple d'excution . . . . . . . . . . . . . . . . . . . . . . . 1079.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

    Conclusion Gnrale 111

    Bibliographie 113

    5

  • Table des gures

    1.1 Description du concept SOA . . . . . . . . . . . . . . . . . . . 131.2 Architecture d'un simple service web . . . . . . . . . . . . . . 161.3 Architecture SOA par ESB . . . . . . . . . . . . . . . . . . . . 181.4 Architecture EDA . . . . . . . . . . . . . . . . . . . . . . . . . 23

    2.1 BRE & SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.2 Architecture BRE . . . . . . . . . . . . . . . . . . . . . . . . . 292.3 Rseau RETE . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

    3.1 Traitement complexe des vnements . . . . . . . . . . . . . . 373.2 Architecture CEP . . . . . . . . . . . . . . . . . . . . . . . . 40

    4.1 Architecture SLEE . . . . . . . . . . . . . . . . . . . . . . . . 484.2 graphe SBB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.3 plateforme Mobicents . . . . . . . . . . . . . . . . . . . . . . . 54

    6.1 Architecture Hybride . . . . . . . . . . . . . . . . . . . . . . 76

    7.1 Prte de travail . . . . . . . . . . . . . . . . . . . . . . . . . . 817.2 diagramme des cas d'utilisation . . . . . . . . . . . . . . . . . 82

    8.1 Architecture hybride . . . . . . . . . . . . . . . . . . . . . . . 898.2 Architecture du resource adaptor BRE Drools . . . . . . . . . 918.3 diagramme de squence du cas d'utilisation 1 . . . . . . . . . 938.4 diagramme de squence du cas d'utilisation 2 . . . . . . . . . 948.5 diagramme de dploiement . . . . . . . . . . . . . . . . . . . 95

    9.1 Le JMS Resource Adapter RA . . . . . . . . . . . . . . . . . 999.2 Diagramme de classe du Resource Adaptor Type . . . . . . . 1019.3 Diagramme de classe du Resource Adapter Drools . . . . . . 1039.4 Exemple dploiement des rgles . . . . . . . . . . . . . . . . . 1059.5 Exemple Service Proxy . . . . . . . . . . . . . . . . . . . . . 1059.6 Diagramme de classe du SBB Proxy . . . . . . . . . . . . . . 106

    6

  • 9.7 Schma de l'exemple . . . . . . . . . . . . . . . . . . . . . . . 1079.8 Interface application Client . . . . . . . . . . . . . . . . . . . . 110

    7

  • Introduction

    Les outils informatiques connaissent dans ces dernires annes une volu-tion rapide. Ils sont utiliss dans toutes les couches de l'entreprise, partant dusystme oprant tel que les outils d'automatisation jusqu'aux outils d'aide la mise en place des stratgies d'entreprise. D'autres types d'outils se trouventdans un niveau plus haut dans les couches de l'entreprise o ils sont utilisspour l'automatisation de la prise de dcision, nous y trouvons dans le do-maine du BI Business Intelligence . Bien qu'aujourd'hui nous ne sommepas encore arriv l'ultime phase du BI, qui consiste la prise de dcisionautomatique, un grand progrs a t fait dans ce sens. Nous trouvons alorsdes outils comme les processeurs d'vnements et les moteurs de rgles mtierqui orent un sous ensemble de fonctionnalits du BI.

    Les moteurs de rgles mtier sont des outils qui permettent de sparerles rgles dnies par l'entreprise et de les isoler du code source. Ceci an deles grer sparment pour pouvoir les tester et les mettre jour sans avoir modier des codes source, souvent non comprhensible par les experts del'entreprise. Les moteurs de rgles mtier sont responsables de l'valuation etl'excution au moment adquat. Les CEP sont d'autre part des outils orantdes fonctionnalits BI combines des contraintes de traitement temps rel.Contrairement aux moteurs de rgls mtier les CEP s'intgrent souvent auxarchitectures orientes vnements dans lesquelles les dirents composantsdu systme communiquent travers l'change d'vnements. Ces dernierssont des objets vhiculant l'information. Les CEP captent ces vnementset analysent en temps rel les informations vhicules par eux, ceci an dedtecter une squence d'vnements appele motif, par consquent une suited'actions sera excute.

    Bien que les deux composants semble dirents il y a entre eux une grandesimilitude de fonctionnement, car ils sont tous les deux des moteurs d'inf-rence. Leur principe de fonctionnement consiste analyser des donnes vial'valuation des conditions. Malgr cette similitude les technologies BRE paroppos aux CEP ont atteint leur maturit ainsi les outils BRE existants sontplus rpandus que les CEP. Cela mne la question suivante est-il possible

    8

  • d'utiliser les moteurs BRE comme des moteurs CEP?.L'objectif de ce travail est d'tudier les moteurs de rgles mtier BRE-

    et les processeurs d'vnements CEP- ainsi que les technologies qui y sontassocies, an de pouvoir les comparer et proposer ensuite une architecturehybride dans laquelle un moteur BRE est utilis pour orir un service CEP.Cette architecture combine le moteur d'infrence Drools et le Serveur d'ap-plication JSLEE.

    Le travail est organis en deux parties. Dans la premire partie nous com-menons par un tat de l'art qui prsente les architectures des systmes infor-matiques notamment l'architecture oriente services et l'architecture orientevnements. Nous nous penchons ensuite sur les moteurs de rgles mtier etles processeurs d'vnements, nous donnons leurs dnitions, leurs architec-tures ainsi que leurs fonctionnements. Nous passons ensuite la comparaisonentre les deux types de moteurs d'infrence an de rpondre la questionpose au dbut. Nous terminons cette partie par une prsentation du ser-veur d'application JSLEE que nous utilisons dans la partie suivante, nousdcrivons ses composants et son utilisation. Dans La deuxime partie nouscommenons par prsenter les extensions qui ont donn une capacit CEPau moteur BRE Drools, nous passons la description de l'objectif de notrearchitecture hybride o nous justions l'utilisation du BRE Drools et du ser-veur d'application JSLEE pour orir une plateforme CEP. Nous prsentonsensuite les composants et le fonctionnement de notre architecture hybride.

    Enn nous prsentons l'implmentation d'un prototype de notre archi-tecture qui sera prsent sous forme d'une dmonstration dans laquelle noussimulons l'application de cette architecture la supervision d'un rseau d'ac-cs.

    9

  • Premire partie

    tat de l'art

    10

  • Chapitre 1

    L'architecture oriente vnement

    Sommaire1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . 12

    1.2 Historique . . . . . . . . . . . . . . . . . . . . . . . . 12

    1.3 Concepts SOA . . . . . . . . . . . . . . . . . . . . . 13

    1.3.1 Dnition du SOA . . . . . . . . . . . . . . . . . . 13

    1.3.2 Dnition d'un Service . . . . . . . . . . . . . . . . 14

    1.3.3 Intrt du SOA . . . . . . . . . . . . . . . . . . . . 14

    1.4 volution du SOA . . . . . . . . . . . . . . . . . . . 15

    1.4.1 WS-SOA . . . . . . . . . . . . . . . . . . . . . . . 15

    1.4.2 SOA par BPM . . . . . . . . . . . . . . . . . . . . 16

    1.4.3 SOA par ESB . . . . . . . . . . . . . . . . . . . . . 17

    1.4.4 BRMS dans SOA . . . . . . . . . . . . . . . . . . . 17

    1.4.5 BRMS vs BPM . . . . . . . . . . . . . . . . . . . . 19

    1.4.6 Limites du SOA . . . . . . . . . . . . . . . . . . . 19

    1.5 EDA . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

    1.5.1 SOA 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 19

    1.5.2 L'vnement . . . . . . . . . . . . . . . . . . . . . . 20

    1.5.3 Dnition EDA . . . . . . . . . . . . . . . . . . . . 20

    1.5.4 Intrt du EDA . . . . . . . . . . . . . . . . . . . . 21

    1.5.5 Fonctionnement EDA . . . . . . . . . . . . . . . . 22

    1.5.6 Composants du EDA . . . . . . . . . . . . . . . . . 22

    1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 23

    11

  • 1.1 Introduction

    Le concept EDA 1 existe naturellement dans notre monde. Le Professeur.David Luckham a dclar dans un article traitant du concept EDA que nousvivons dans un monde vnementiel The world is event-driven [Luc07].Dans la nature il existe plusieurs exemples de cela, la raction d'un lion face l'vnement de l'arrive d'un zbre doit tre instantan, il perdra sinon uneoccasion d'avoir une proie et de la mme manire le zbre n'attendra paspour ragir l'arrive du lion qui est un vnement dangereux pour lui.

    Dans le monde de l'entreprise, les situations dirent, mais le paradigmereste le mme. Les bourses possdent des algorithmes temps rel qui r-agissent aux changements l'intrieur du march boursier, soit pour saisirdes occasions ou pour viter des dgts. Les banques aussi ragissent auxtransactions et peuvent dtecter les tentatives de fraude. La question qui sepose est de savoir si les systmes IT retent cette ralit vnementielle etseront-ils capable d'en tirer avantage ?.

    1.2 Historique

    Revenons un peu en arrire pour voir quel tait le fonctionnement dessystmes IT. Au dbut, la base du de fonctionnement tait le mode Schedulequi est lui-mme bas sur une architecture assez simple. Le mode Scheduleest le fait de planier une certaine action un certain temps sous formede Batch ou de travail excuter priodiquement. Malgr le fait que cemode rpondait des besoins de cette poque, il reste loin de rpondre auxbesoins actuels de l'entreprise. Aujourd'hui, ce mode est incapable de reterla nature vnementielle de notre monde. Nous donnons un exemple o lemode Schedule ne permet pas cette interaction : imaginons une entreprise quigre les commandes de ses clients en mode Schedule, chaque n de journe elleexcute un Batch qui envoie les commandes de livraison. Une telle approcheretarde la livraison ce qui engendrera la perte des clients. Le mode Schedule,quoiqu'il rpond un certain besoin, est incapable de satisfaire les besoins denotre monde vnementiel. Pour rpondre aux besoins actuels de l'entrepriseun nouveau paradigme qui porte le nom SOA est apparu dans le monde IT.

    1. Event Driven Architecture

    12

  • 1.3 Concepts SOA

    1.3.1 Dnition du SOA

    SOA 2 est apparue pour donner plus de uidit aux systmes IT. L'entre-prise est vue comme un ensemble de services combins. Ces services appar-tiennent dirents domaines : nancier, gestion du personnel, productionetc. SOA permet la combinaison des services pour raliser le business[Tay06]L'intrt de ce concept est d'augmenter la rutilisation des composants dusystme IT et de diminuer la dpendance entre ses dirents composants.SOA n'est pas lie une technologie ni une implmentation c'est une archi-tecture qui se base sur deux principes : la modularit et l'accs distant. SOApeut tre implment avec plusieurs technologies, titre d'exemple DCOM,CORBA ou WS 3 cette dernire technologie est l'implmentation la plus cou-rante du SOA. Le WS consiste envelopper dans un serveur les codes quidlivrent le service. Ces codes sont crs avec direntes technologies, ils se-ront, ensuite, exposs comme un service capable d'tre appel par n'importequelle entit connecte au rseau ou bien par un autre WS. An de mieuxcomprendre SOA il convient de donner la dnition d'un service.

    Figure 1.1 Description du concept SOA

    2. Service Oriented Architecture

    3. Web Service

    13

  • 1.3.2 Dnition d'un Service

    Un service est une entit business qui accepte une requte et rend unrsultat travers une interface. Un service peut eectuer un travail commedes calculs en comptabilit ou bien la mise jour d'une base de donnes.Un service ne doit pas dpendre de l'tat des autres services. Cette dni-tion donne est indpendante de la technologie utilise pour implmenter unservice. [Tay06]

    1.3.3 Intrt du SOA

    La problmatique des systmes IT c'est qu'ils sont constitus de di-rentes technologies et de dirents langages de programmation, ce qui rendla communication entre eux dicile. Par consquent il est dur de rutiliser desmodules dj existants pour complter d'autres modules. A titre d'exemple,si le service nancier dispose d'un module d'identication et que l'on enve-loppe ce service sous forme de WS, on peut l'exposer pour qu'il soit utilispar le service facturation des clients ou bien le service contrle de production.De cette faon, nous pouvons diminuer le temps de dveloppement et assurerla abilit du systme. Le deuxime intrt du SOA est le dcouplage desservices. Le dcouplage consiste sparer les dirents services ce qui veutdire qu'un service ne dpend pas d'un autre. En pratique le terme dcrit lesservices qui peuvent communiquer entre eux sans avoir besoin de partagerde connaissances au pralable telles que les noms des fonctions, le formatde message ou toute autre information. Le but de cela est de permettre lechangement des services sans tre oblig de faire des changements dans lesautres modules.

    SOA permet d'augmenter le re-use 4 et le dcouplage, mais un certainniveau, car il y a toujours un partage de connaissances. Un appelant doit, eneet, connatre les interfaces de l'autre service SOA qui lui-mme fonctionnesous forme request/reply ou en mode pull, cela veut dire que si un service abesoin de communiquer avec un autre, il lui envoie un message et attend larponse.[Fal05]

    4. rutiliser le mme service par d'autres services

    14

  • 1.4 volution du SOA

    1.4.1 WS-SOA

    SOA est implmente en gnral avec des WS. Les WS sont des units decode qui peuvent tre invoqus par le protocole HTTP. Contrairement auxautres implmentations les WS ne ncessitent pas un protocole spciquepour l'accs aux excutables distance, comme c'est le cas pour CORBA 5

    qui ncessite l'utilisation du IIOP 6 ou bien JavaBeans 7 qui ncessite RMIP 8.Ceci permet d'exposer les fonctionnalits du code sous forme de service quipeut tre utilis par les autres applications travers le rseau. Ce qui ore des applications crites en .VB ou .NET la possibilit de communiquer avecdes applications crites en Java et vice versa [Dah09].

    Un web service contient un nombre de classes, interfaces et structures quiore une boite noire pour le client distant. Un web service dnit un objetqui excute en gnral une unit de travail. A titre d'exemple lire des donnesou eectuer des calculs. Les WS communiquent en changeant des messagesSOAP Simple Object Access Protocol travers du simple HTTP ce quipermet d'utiliser la connexion faible dbit pour les implmenter.

    Pour permettre ces services de communiquer, le WS dnit un ensemblede standards facilitant l'change des messages et l'appel des procdures distance. Nous donnons ici une description de ces standards :

    -UDDI Universal Description, Discovery, and Integration est un pro-tocole qui dcrit les services web existants. Ce standard permet l'enregis-trement des services dans un annuaire et de les exposer l'extrieur. Lesentreprises peuvent alors utiliser d'autres services via le web. L'enregistre-ment et l'change se font travers des messages XML sur du HTTPS.

    -SOAP Simple Object Access Protocol c'est le protocole de communi-cation entre les services. Il permet des applications ou services distants d'ap-peler des services sur d'autres serveurs et d'invoquer des mthodes, SOAPenvoie des requtes sous forme de XML qui contiennent des donnes traiterainsi que l'adresse de l'objet appel.

    -WSDL Web Service Description Language est le standard pour ladescription du web service, c'est un chier XML qui dnit les interfaces etles dtails d'implmentation du service. WSDL est rfrenc dans UDDI etil dcrit les SOAP messages utiliss pour ce service Web Fig 1.2. Le contactentre les WS peuvent se faire par programmation interne o chaque service

    5. Standard de gestion d'objets distribus

    6. Internet Inter-ORB Protocol

    7. composants logiciels crits en langage Java

    8. Remote Method Invocation Protocol

    15

  • invoque d'autres, an de raliser le but du business. Une autre faon decoopration entre services est d'utiliser un service d'orchestration, le BPM 9

    est un candidat idal pour jouer ce rle [Wen08].

    Figure 1.2 Architecture d'un simple service web

    1.4.2 SOA par BPM

    Un BPM est une technologie qui existe depuis les annes 90 elle permetd'excuter et superviser les processus mtiers, en d'autres termes il excuteles direntes tapes et tches an de raliser un processus mtier. A titred'exemple l'ouverture d'un nouveau compte bancaire dclenche un certainnombre d'activits savoir : vrier si le demandeur n'est pas sur la listenoire, mettre jour les bases de donnes, crer des cls et des mots de passeetc.

    Dans le cadre de SOA le BPM est utilis pour orchestrer la communicationentre les WS an de raliser le but du business, il slectionne et invoquedes services, il est galement capable de suivre et tester l'ecacit de ceprocessus Dans le cas de WS-SOA le processus mtier est dcrit par unlangage spcialis, le plus rpondu parmi ces langages est WS BPEL WebService Business Process Execution Language . Le BPM excute ensuite le

    9. Business Process Management

    16

  • processus qui devient alors un service dcrit par un chier WSDL et qui peuttre lui-mme invoqu par d'autres processus [WG05] Parmi les BPM les plusconnus nous citons :

    Produit Open SourceOracle BPEL Process Manager NonIBM WebSphere Process Server Non

    Microsoft BizTalk Server NonActiveBPEL Engine Oui

    1.4.3 SOA par ESB

    SOA a volu par l'utilisation d'un ESB pour connecter les direntsservices. On peut voir le ESB comme une version allge du EAI 10 Il com-bine une technologie de transport asynchrone et des services techniques valeur ajoute (routage, transformation...etc ). Au lieu des connexions point point, un ESB ore des adaptateurs permettant l'intgration de direntsservices et systmes comme le montre la Fig1.3. Il est possible galement dednir certaines rgles dans le ESB via du XML pour lancer des Workowou ltrer certains messages. Actuellement nous trouvons dirents protocolesd'adaptateurs disponible dans le monde ESB titre d'exemple : Flat File,XML..etc.

    Parmi les ESB les plus connus nous citons :Produit Open Source

    Sonic ESBr NonIIBM WebSphere Message Broker Non

    Apache ServiceMixr OuiMule Oui

    1.4.4 BRMS dans SOA

    Dans une architecture SOA un BRMS 11 est le composant qui permet lagestion et l'automatisation des rgles mtier. Les rgles mtier drivent desrgles lgislatives (un employ peut tre licenci pour multiples absence nonjustie "), ou bien de la stratgie de l'entreprise ("chaque client fait desachats de plus de 1000 euro bncie d'une rduction de 10%"). Le BRMSpermet l'enregistrement, la classication et l'excution de ces rgles, il permetaussi de vrier la consistance des rgles, titre d'exemple : il peut dtecterl'existence de deux rgles contradictoire ("un client potentiel peut bncier

    10. Entreprise Application Integration

    11. Business Rules Management System

    17

  • Figure 1.3 Architecture SOA par ESB

    d'un crdit"), ("aucun crdit ne doit tre accept"), il peut aussi infrerd'autres faits qui engendre leur tour d'autre rgles. [Tay06]

    Parmi ses fonctionnalits, nous citons :

    un diteur de rgles des outils de dtection d'erreurs (ou dtection d'incohrences dans lesrgles)item des mcanismes de contrles de droits d'accs

    un REPOSITORY o se trouvent les direntes versions des rgles un contrleur de versions un gnrateur de code un BRE

    Le BRE n'est donc plus qu'un simple composant optionnel d'un BRMS.Certains BRMS ne disposent pas de mcanismes d'infrence en lieu et placede l'infrence, on retrouve de la gnration de code. Parmi les plus connusBRMS nous citons :

    Produit Open SourceJBoss Drools Oui

    Fair Isaac Blaze NonIBM jRules Non

    18

  • 1.4.5 BRMS vs BPM

    BRMS est dirent du BPM, car il est utilis pour la sparation et l'ex-ternalisation des rgles mtier et non pas la gestion et l'excution des ser-vices. Puisque les rgles qui dnissent la stratgie de l'entreprise changentfrquemment, si elles sont intgres aux codes des services on sera obligde redployer ces services chaque changement ce qui n'est pas pratique.Par contre, l'externalisation de ces rgles dans un BRMS permet une bonnegestion et une mise jour rapide et consistante. L'utilisation d'un langageadapt de rgles facilite leur lecture et leur mise jour notamment par desnon dveloppeurs.

    1.4.6 Limites du SOA

    Comme toute autres technologies, adapter une architecture SOA uncot payer. Il s'agit de la maintenance et l'volution des services et surtoutla revalidation de services chaque changement. Jusqu' prsent nous avonsexamin l'approche SOA, mais la question est de savoir si le SOA rpond la nature vnementielle de notre monde. La rponse est non, car le SOA suitle modle request/reply qui ncessite l'interrogation pour avoir une rponse.Un exemple d'un cas ou le SOA ne peut pas rpondre au besoin est celui ducontrle du fraude par une banque. Cette dernire n'attend pas que le clientdemande chaque fois qu'il y est contrle pour dtecter la fraude, mais pluttde le dtcter ds son apparition. L'autre obstacle de l'approche SOA est ladicult de reprsenter le tout sous forme de services indpendants [AW09].

    1.5 EDA

    1.5.1 SOA 2.0

    L'architecture SOA est trs ecace quand le traitement ou la squencedes services est connue au pralable. Cependant, dans le traitement vne-mentiel o les processus sont asynchrones le modle Request/Reply ne semblepas susant. On n'attend pas qu'un service scrute les autres services pourchercher si un vnement a eu lieu. A titre d'exemple la dtection du fraude.

    Pour palier ce problme une architecture base sur l'vnement estncessaire. Oracle a introduit le terme SOA 2.0 pour designer une architectureavances qui inclut le traitement d'vnements. Ce terme tait critiqu parles experts qui ont accus Oracle de crer la confusion par SOA 2.0 et ontdcid que SOA 2.0 n'tait en fait qu'un terme de marketing utilis pourdsigner l'approche EDA.

    19

  • Avant de dnir EDA il convient de dnir ce qu'est un vnement.

    1.5.2 L'vnement

    Dnition du dictionnaire : L'occurrence d'un important incident, sp-cialement celui qui est le plus signicatif intressant ou inhabituel [Luc08].Dans le contexte de l'entreprise :

    L'vnement rete le changement d'un tat d'un objet. L'vnement a un temps et un lieu. L'vnement peut ne pas reprsenter des donnes.

    Exemples : Une transaction d'un client a chou. Le schma d'une base de donnes a chang. Un composant rseau est en dfaillance. Une tempte a frapp la ville X. Un pattern d'une transaction de fraude est dtect. Une machine serveurs a t teinte.

    On peut classer les vnements dans une entreprise selon des catgories : Lesvnements physiques

    la source lectrique est disparue. la temprature a dpass 40 degr.

    Les vnements lis aux transactions un nouveau client a t ajout

    Les vnements d'agrgation la moyenne de production a baiss de 20% dans les 48 heures.

    Les vnements relationnels le taux d'accident Bruxelles a augment de 25% et le taux de contratd'assurance a baiss de 30%.

    Les vnements complexes c'est la combinaison des vnements prcdents dans un vnementcomplexe.

    1.5.3 Dnition EDA

    EDA Event Driven Architechture est le successeur du SOA. Le paradigmeest bas sur l'ide du tout est vnement, du moment o le monde se diviseen consommateur et producteur d'vnements. Pour comprendre la direnceentre EDA et SOA il faut examiner leur unit de commande. La requte dansSOA et l'vnement dans EDA. Dans la traditionnelle SOA le consommateurdu service envoie une requte vers le producteur, la rponse du producteur

    20

  • contient soit le rsultat soit un feedback. A titre d'exemple une action ac-complie ou bien autorise. La requte est souvent formule l'impratif : "mets jour " ou " calcule".

    Dans EDA le schma de la communication entre le consommateur etle producteur est invers. Les consommateurs ne dbutent pas la commu-nication, mais ils reoivent les vnements publis par les producteurs. Lacommunication est alors unidirectionnel le producteur n'a pas besoin d'unerequte pour continuer son travail [Dah09].Les vnements sont formuls dansla forme passive titre d'exemple, "client ajout", "commande annule " etils dnissent un changement d'tat dans le domaine du producteur [D.L08].EDA est alors un paradigme d'architecture qui permet de percevoir le monde travers les vnements qu'il mette. Et aussi de ragir en temps rel l'vo-lution de ce monde.

    1.5.4 Intrt du EDA

    L'intrt du EDA est de complter le SOA pour arriver un dcouplagedes services ,appels par EDA des agents, et de grer d'une manire ecaceles processus temps rel et asynchrones. Ceci optimise le paralllisme dansles processus. Par consquent le traitement par vnement permet de grerun volume important d'informations varies.

    L'EDA augmente le dcouplage par rapport au SOA puisque dans ce der-nier les services partagent des interfaces pour appeler les fonctions. En EDAle producteur et le consommateur ne se connaissent pas, un producteur pu-blie son vnement qui peut tre consomm par dirents consommateurs etchacun d'entre eux eectue un traitement dirent.[AW09]. Cette commu-nication par vnement augmente l'agilit du systme en lui permettant deragir en temps rel aux changements autour de lui, titre d'exemple leschangements du march boursier : dans ce cas chaque changement des va-leurs boursiers est signal par un vnement, cette agilit est obtenue grceau traitement des vnements en temps rel, Un autre intrt consiste permettre l'introduction d'un niveau plus haut de traitement en utilisant lemoteur CEP. Ce dernier permet de corrler un grand volume d'informationsqui arrivent dans une priode de temps limit an d'en extraire en tempsrel d'autres informations plus utiles, nous allons voir ce composant plus endtails dans les chapitres suivants.

    21

  • 1.5.5 Fonctionnement EDA

    L'architecture EDA est base sur le PUB/SUB 12 qui signie publier ets'abonner. Dans le PUB/SUB l'metteur publie chaque message dans unsujet. Au lieu d'envoyer un destinataire prcis, le systme de messagerieenvoie le message ou l'vnement tous les consommateurs dj inscrits cesujet. Ce mode est plus scalable que le mode point point, ceci grce lanature stateless des agents consommateurs d'vnements. Ce mode encouragegalement le dcouplage puisque souvent le producteur ne sait mme pasqui sont les consommateurs de son vnement, contrairement au principerequest/reply utilis dans WS-SOA les services ne doivent pas changer lechier WSDL [Dah09].

    1.5.6 Composants du EDA

    Event Tooling : est le composant qui permet la dnition des v-nements et la gestion de l'inscription aux ux d'vnements. Il oregalement la possibilit d'administrer l'infrastructure des vnementset la gestion des ux des vnements et de leur visualisation ainsi quela gnration des statistiques sur le traitement de ces ux.

    Enterprise Integration : ce composant joue un rle essentiel dansl'architecture EDA, il comprend le pr-traitement des vnements comme(le ltrage, le routages, la transformation). [Mic06] Ces deux dernierscomposants sont des entits logiques, elle peuvent tre implment dansun seul composant appeler collecteur d'vnements. [Mic06]

    Sources and Targets :ce sont les agents qui consomment et pro-duisent les vnements. Ils peuvent tre des systmes d'entreprise, desservices appartenant aux processus mtier, des bases de donnes ou descomposants du rseau.

    CEP : 13 : est le cur composant du EDA il est utilis dans l'extractiondes nouvelles informations. Le CEP analyse un grand nombre d'vne-ments qui se produisent durant une priode de temps an de les cor-rler et dduire d'autres informations utiles pour l'entreprise. Les CEPpeuvent aussi tre utiliss au-dessus de SOA -si on rajoute aux servicesla possibilit d'mettre des vnements-. Cela permet de raliser uneanalyse du processus mtier en temps rel. [Mic06]Fig1.4

    12. Publish and Subscribe

    13. Complex Event Processing

    22

  • Figure 1.4 Architecture EDA

    1.6 Conclusion

    L'EDA est une extension du SOA, le besoin de passer d'une architecturebase sur les services vers une architecture base sur les vnements dpendde la nature des informations qui circulent dans l'entreprise et du type detraitement de ces informations. Quand le temps et le volume sont de grandsenjeux pour l'entreprise, l'utilisation de l'EDA semble la plus adapte. Quandle business est bas sur un traitement squentiel une architecture SOA rpondalors ce besoin. Utiliser en plus un BRE permet de grer la logique du mtierd'une manire exible. D'autre part l'EDA facilite l'intgration du CEP quipermet d'extraire d'un ux important d'vnements, les informations quipermettent d'adapter les stratgies du business.

    23

  • Chapitre 2

    Les moteurs d'infrence BRE

    Sommaire2.1 Historique . . . . . . . . . . . . . . . . . . . . . . . . 24

    2.2 Dnition des Business Rules Engine . . . . . . . 25

    2.3 Dnition des rgles . . . . . . . . . . . . . . . . . . 26

    2.4 Intrt de BRE . . . . . . . . . . . . . . . . . . . . . 26

    2.5 BRE et SOA . . . . . . . . . . . . . . . . . . . . . . 27

    2.6 Architecture BRE . . . . . . . . . . . . . . . . . . . 27

    2.6.1 La base des rgles . . . . . . . . . . . . . . . . . . 27

    2.6.2 Le moteur d'infrence . . . . . . . . . . . . . . . . 29

    2.6.3 Le chainage avant . . . . . . . . . . . . . . . . . . 29

    2.6.4 Le chainage arrire . . . . . . . . . . . . . . . . . . 30

    2.6.5 RETE . . . . . . . . . . . . . . . . . . . . . . . . . 30

    2.7 Caractristiques des BRE . . . . . . . . . . . . . . 32

    2.7.1 Performance . . . . . . . . . . . . . . . . . . . . . . 32

    2.7.2 Dterminisme . . . . . . . . . . . . . . . . . . . . . 32

    2.7.3 Standardisation . . . . . . . . . . . . . . . . . . . . 32

    2.7.4 Produits BRE . . . . . . . . . . . . . . . . . . . . . 32

    2.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 33

    2.1 Historique

    Les BRE 1 peuvent tre vus comme les successeurs des Systmes Experts(ES). Ces derniers sont apparus dans les annes 80 alors que les BRE ontvu le jour dans les annes 90. Les systmes experts sont des systmes ferms

    1. Business Rules Engine

    24

  • qui n'interagissent pas avec le rseau, ils taient construits pour des tchesspciques, contrairement aux BRE qui sont connects et gnriques. Lessystmes experts sont dvelopps pour une exprience utilisateur, alors queles BRE sont plus adapts pour l'automatisation de la dcision. Par ailleurs,les dirents mcanismes d'infrences ont subi des amliorations ce qui rendles BRE plus ecaces que les SE . Dans les annes 2000, les BRE ont leur tour connu une volution pour devenir BRMS enrichis avec d'autresfonctionnalits pour la gestion et le maintien des rgles. La fonction du BREse limite l'excution des rgles et il ne permet pas leurs gestions.

    2.2 Dnition des Business Rules Engine

    Un BRE (ou moteur de rgles d'infrence) est une application dont lerle consiste eectuer des liaisons entre des donnes, des faits et des rglesmtier. Le BRE excute une ou plusieurs rgles selon les donnes qu'il reoit.Ces rgles peuvent tre des rgles lgislatives de l'entreprise ("un employrecrut doit avoir une certaine exprience "), ou bien des stratgies de l'en-treprise (un client "gold" est un client qui fait plus de 1000 euro d'achat).tant seulement le moteur d'infrence le BRE n'ore pas la gestion des rglesmtier, par consquent, il est intgr un BRMS Business Rules Mana-gement System . Parmi les fonctionnalits qui se rajoutent au BRE pourdonner un BRMS nous citant : l'enregistrement des nouvelles rgles mtier,la vrication de la consistance des rgles et la dnition des relations entreces derniers. [Chi07]] La base de fonctionnement des BRE est l'applicationd'un ensemble de rgles si/alors. L'objectif est de sparer les rgles businessfrquemment modies du reste du code. Ces rgles seront stockes sous uneforme comprhensible, ce qui facilite leur maintient et vite aux dveloppeursd'aller les chercher dans les codes source chaque modication et ventuel-lement refaire les tests. A titre d'exemple, le calcul de la valeur de rductionqu'une entreprise ore ses clients est une rgle mtier, elle peut tre misedans un code du systme sous cette forme :if (product.quantity > 100)product.price=product.price-50L'utilisation du BRE remplace le code prcdent par un appel au moteurd'infrence avec comme entre, l'identicateur du produit :ruleEngine.applyRules(product)

    La rgle est crite sparment comme suit : Rule Discount When$P :Product(quantity>100) Then P.price =p.price-50 End

    De cette faon nous avons spar le calcul de rduction du reste du code,

    25

  • cela permet de changer le taux de rduction appliqu sans aecter le reste dusystme. Bien que cet exemple semble simple, mais il illustre l'avantage del'utilisation des BRE [Dor05] Avant de continuer il convient de donner unednition la rgle business.

    2.3 Dnition des rgles

    Ce sont des dcisions qui dnissent o grent une partie du business. Ellescontrlent et inuencent son comportement. Le BRE value et excute cesrgles Et chaque rgle est exprime sous forme de si/alors. Elle est composede deux parties, la condition et l'action : quand la condition est rencontre,l'action est excute. La partie "SI" comporte la ou les conditions exemple(code-produit=100), la deuxime partie comporte l'action (exemple appliqueune rduction de 5%).

    Les rgles business permettent de : Automatiser une dcision (exemple : ce client est un client gold) Lancer une action (exemple : envoyer un mail au manager pour signalerque le stock est vide)

    Il existe plusieurs guides pour laborer des rgles mtier, voici celles donnespar la socit Business Rules Solutions :

    Atomicit : une rgle mtier ne peut tre divise sous peine de perte devaleur smantique

    Rutilisation : une rgle mtier n'est pas spcique une application,mais peut tre partage par plusieurs applications

    Business : on parle des rgles mtier qui sont donc destines desexperts mtier. Ce sont donc ces derniers qui doivent les grer et pourcela, un mode de reprsentation non technique est requis.

    Dclarative : par opposition procdurale, les rgles sont prsentes demanire dclarative et non sous forme d'une succession de conditionsimbriques les unes dans les autres.

    2.4 Intrt de BRE

    L'intrt principal des BRE est de faciliter la mise jour des rgles busi-ness et de dcrire ces rgles dans un langage plus comprhensible. L'utilisationdes BRE ore galement certains autres avantages :

    Granularit. L'utilisation des BRE comme des composants augmentela granularit, facilite la maintenance et rend le systme plus exible,

    26

  • contrairement ou BP 2 qui ne change pas souvent. Synchronisme. Contrairement la lenteur du BP, le BRE permet detraiter les rgle plus rapidement ce qui augmente la possibilit du trai-tement asynchrone.

    Statefulness. Les BRE sont dvelopps pour traiter les donnes en in-put et d'excuter les rgles ainsi que de changer la base des faits quidcrivent l'tat du systme ce qui garde un tat actuel du systmedans cette base. [Fer05] D'autre part L'utilisation des BRMS rpondaux questions suivantes :

    O peut- on -trouver les rgles business ? Comment tester ces rgles business ? Comment rutiliser les rgles dj existantes Comment simuler les rgles ? [Tib07]

    2.5 BRE et SOA

    Dans une architecture SOA le BRE est dploy comme un service dedcision spar. Ce service accde aux direntes ressources de l'entreprise etaux autres services par la mme infrastructure SOA, il propose des interfacesaccessibles aux autres services. Ces derniers remplacent les codes o des rglesont t implmentes par des appels au service de dcision qui excute lesactions correspondants aux donnes entres Fig 2.1.

    2.6 Architecture BRE

    Le nombre des composants d'un BRE dire selon les vendeurs, mais ilexiste des composants de base qui sont essentiels son fonctionnement savoir la base des rgles et le moteur d'infrence. Au-dessus de ces deux com-posants se rajoute souvent le Rules Management Application, qui reprsentel'interface utilisateur que les experts et dveloppeurs utilisent pour crer etmodier les rgles 2.2.

    2.6.1 La base des rgles

    La base des rgls ou bien le Rules Repository est la collection de rglesmtier qui peut tre modies tout moment en utilisant le Rules applica-tion management : la base des rgls contient aussi des mta-donnes qui

    2. Busness Process

    27

  • Figure 2.1 BRE & SOA

    dnissent les entits, les attributs et les relations dans les bases de don-nes existantes. Il existe direntes implmentations du Rules Repository.Ils peuvent tre implments avec un code similaire celui utilis par lesapplications. Ce code sera appel chaque fois par le moteur d'infrence,toutefois, les rgles mtier tant destines aux experts mtier, la modlisa-tion est un aspect important et doit tre accessible des non dveloppeur.Le langage dclaratif : est un format proche des spcications papier quipermet de facilit la dnition des rgles en utilisant un vocabulaire busi-ness, avec un diteur intelligent pour la rdaction des rgles. La maintenancesera donc facile, mais de nombreuses incohrences peuvent tre gnres.Deux standards dirents sont utiliss pour le format de la reprsentationde rgles : PRR (OMG) 3 association amricaine de standardisation et RIF(W3C) 4 organisme de standardisation. Par contre, dirents vendeurs deBRE n'exploitent pas les standards existants, mais ils crent un format dereprsentation de rgles spcique leur solution. La consquence est unemauvaise interoprabilit entre les direntes solutions existantes.[Mah09]

    3. Object Management Group

    4. World Wide Web Consortium

    28

  • Figure 2.2 Architecture BRE

    2.6.2 Le moteur d'infrence

    L'objectif d'un moteur d'infrence est de dterminer quelles sont les rglesqui peuvent tre appliques. Un ensemble de faits est inject dans ce qu'onappel un espace de travail. Ou Working Memory sur la base de ces faits LeBRE produit des rgles applicables qu'on appel agenda. Suivant direntscritres, une rgle de l'agenda est retenue. Cette tape est appele rsolutiondu conit. La rgle retenue est excute ce qui engendre la cration de nou-veaux faits.. Le moteur d'infrence prend en entre un ensemble de rglesappele le Rules set Collection les autres entres sont les objets reprsen-tants les donnes. Le mcanisme de production des faits sur base de rgleset d'autres faits est appel infrence. Il existe trois mcanismes l'infrence :le chanage avant Le chanage arrire et L'algorithme RETE.

    2.6.3 Le chainage avant

    Le chanage avant est le mcanisme le plus utilis et le plus vident del'infrence ainsi il est le mcanisme par dfaut de beaucoup de moteurs .Dans ce type d'infrence le moteur scrute toutes les rgles la recherched'une rgle qui possde une partie " SI" qui correspond aux faits, ds qu'une

    29

  • rgle est trouve elle sera excute et les nouveaux rsultats seront rajouts la base des faits. La procdure se rpte priodiquement jusqu' ce qu'il nereste aucune rgle qui correspond, videmment certaines stratgies sont ap-pliques an d'viter que les rgles s'appliquent plusieurs fois ou l'apparitiondes boucles.

    2.6.4 Le chainage arrire

    Contrairement au chanage avant le chanage arrire part de l'action versla condition. Il consiste chercher la partie Alors de la rgle qui est considrecomme le but. La partie condition ou la partie "SI" sera examine pourtester si la condition est vrie, si c'est le cas la rgle est ajoute l'agenda.Dans le cas contraire les littraux qui ne match pas dans la partie "SI" serontconsidrs comme de nouveaux but rechercher et ainsi le processus continuejusqu' ce que tous les littraux match les faits ou bien il ne reste plus dergles.

    2.6.5 RETE

    RETE est un algorithme de recherche des patterns qui augmente sonecacit en sacriant de l'espace. Dans RETE les rgles sont dcrites sousforme de rseau de nuds. Les faits ou les entes passent par ce rseau etsubissent des tests chaque nud. Si ces faits arrivent une feuille du rseauRETE, la rgle correspondante est ajoute l'agenda. Le rseau RETE estform de 5 types de nuds : la racine, les nuds Type, les nuds alpha,les nuds bta et les nuds feuille. Le nud racine est le point d'entre detous les faits il re-copie chaque fait vers toutes ses feuilles qui sont les nudstype. Chacun de ces derniers envoie les faits qui correspondent son typevers ses nuds alpha Fig2.3. Les nuds alpha reprsentent les littraux dela partie condition d'une rgle. Si ce littral match les faits il les envoie aunud alpha suivant. An d'eectuer des oprations de jointure, multiplesnuds bta sont utiliss. Ces derniers reoivent comme entre plusieurs faitset copient en sortant le rsultat de l'opration, ainsi la partie condition dela rgle est vrie progressivement, si un fait arrive une feuille alors lacondition est satisfaite. Ceci engendre l'ajout de la rgle correspondante l'agenda. La rsolution du conit dtermine l'ordre dans lequel les rglessont appliques [Ber02] [Sto].

    30

  • Figure 2.3 Rseau RETE

    31

  • 2.7 Caractristiques des BRE

    2.7.1 Performance

    La performance du BRE dpend surtout de la structure des rgles utili-ses. Des rgles qui ne respectent pas une bonne granularit vont conduire un workfow qui est gr dans le BRE. Pour cela il faut respecter la gra-nularit des rgles, autrement dit crer des rgles les plus courtes possible.En respectant ce principe les moteurs d'infrence bass sur RETE reste trsperformants.

    2.7.2 Dterminisme

    Il est important pour un BRE de comprendre quelle est la stratgie depriorit adopte, sinon nous allons avoir des rgles qui s'excutent dans unmauvais ordre et cela peut aecter leur fonctionnement. Si une rgle quidpend d'une autre s'excute en retard nous allons avoir de faux rsultats.L'une des stratgies pour rsoudre ce problme est de dnir la priorit selonl'action que la rgle eectue.

    2.7.3 Standardisation

    L'existence de standard est un point important qui permet des clients dechanger facilement le produit, par exemple, changer le BRE et garder le mmeRules Repository ou bien reprsenter la base des faits par une syntaxe XML.Ceci limite le risque d'investissement pour le client. Une API ApplicationProgramming Interface qui permet l'accs au BRE depuis un client JAVAa t spci dans le JSR94 Java Specication Request for a Java RulesEngine API.

    Cette spcication dnie les fonctions de base qui sont : ajouter un objetau BRE, excute une rgle et rcupre le rsultat [Jbo09]..

    2.7.4 Produits BRE

    Il existe direntes solutions qui respectent la spcication JSR94 parmilesquelles nous citons :

    Produit Open sourceJboss busniss Drools ouiOracle busness rule non

    ILOG JRules ouiJess oui

    32

  • 2.8 Conclusion

    Un BRE est un outil qui permet l'adaptation de la stratgie de l'entreprisede manire exible. Toutefois si on utilise un BRE dans une architecture SOA,nous devons savoir quel moment on excute les rgles, titre d'exempleinvoquer le moteur d'infrence par le BPM le ESB ou bien les WS, parcontre dans une architecture oriente vnement le traitement est asynchrone,ainsi l'excution d'une rgle peut tre n'importe quel moment ds qu'unvnement apparatra. Pour rpondre aux exigences du monde vnementielleil existe un autre type de moteurs d'infrence nomm CEP.

    33

  • Chapitre 3

    Les moteurs d'infrence CEP

    Sommaire3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . 34

    3.2 Dnition CEP . . . . . . . . . . . . . . . . . . . . . 35

    3.3 Motif d'vnement . . . . . . . . . . . . . . . . . . . 37

    3.4 Intrt du CEP . . . . . . . . . . . . . . . . . . . . . 38

    3.5 Cas d'utilisation . . . . . . . . . . . . . . . . . . . . 38

    3.6 Architecture CEP . . . . . . . . . . . . . . . . . . . 40

    3.6.1 La collecte . . . . . . . . . . . . . . . . . . . . . . . 40

    3.6.2 L'infrence . . . . . . . . . . . . . . . . . . . . . . 41

    3.6.3 Approche non RETE . . . . . . . . . . . . . . . . 41

    3.6.4 Approche RETE . . . . . . . . . . . . . . . . . . . 42

    3.7 Dirence entre CEP et BRE . . . . . . . . . . . . 42

    3.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 44

    3.1 Introduction

    Avec l'avnement de l'EDA et l'adoption du mode de communicationasynchrone qui utilise des vnements ou le mode publish/subscibe , lessources d'information se sont multiplies travers : les contrleurs RFID, lesbases de donnes, les workow les services. . . etc. Les contraintes liesau temps de traitement et au volume de donnes deviennent ainsi varies.Passant d'applications de gestion faible dbit et sources d'vnements li-mits aux applications de la supervision qui reoivent des vnements dedirentes sources et qui exigent un traitement en temps rel. La multipli-cit des sources d'vnements a rendu complexe la relation entre l'apparitionde certains vnements d'une part et le traitement associ d'autre part. Par

    34

  • oppos au traitement simple o l'action est dtermine aprs analyse d'unvnement indpendant, le traitement complexe ncessite la corrlation deplusieurs vnements durant une priode de temps plus au moins longue,ceci an de dcider de la nature de l'action qui doit tre prise. Ce derniertraitement se termine en gnral par la publication d'un nouveau vnement[JSS09].

    Les moteurs d'infrence CEP ont t crs pour rpondre ce type decontraintes d'analyse nous les trouvons comme composants responsables dutraitement d'vnements un niveau plus haut dans l'architecture EDA. Ilssont donc le cerveau de cette architecture [RSuS09].

    3.2 Dnition CEP

    Le terme CEP signie le traitement complexe des vnements. En d'autrestermes ce type de traitement consiste l'extraction de nouvelles informa-tions non pas par l'analyse des vnements simples et indpendants, maispar l'analyse d'un ensemble d'vnements. Nous prenons comme exemple lestransactions bancaires qui une fois traites indpendamment peuvent treordinaires et ne rien rvler, mais l'analyse d'un ensemble de transactionsbancaires sur une priode de temps peut rvler une tentative de fraude.

    Le principe de CEP est bas sur un moteur d'infrence qui reoit desux d'vnements lmentaires, venant par direntes voies et par volumeimportant. Le traitement consiste eectuer des corrlations entre ces dif-frents ux an de dtecter une squence d'vnements appele motif. Dansl'exemple prcdant le CEP analyse le ux de transactions la recherched'un motif de fraude. Les motifs sont dnis par des expressions de syntaxeproche de SQL et sont valus continuellement par le CEP. Ceci fait la dif-frence entre le traitement traditionnel dans lequel une simple requte estenvoye une Base de donnes pour rendre le rsultat, gnralement aprsune premire valuation et l'utilisation d'un moteur CEP Fig 3.1.

    Dans ce dernier cas une valuation continue des requtes est faite sur desux d'vnements. Le rsultat de la dtection d'un motif conduit l'excu-tion d'une action qui peut tre soit un code excuter ou bien une simplenotication. En rgle gnrale l'action consiste la publication d'un nou-vel vnement. Dans l'exemple prcdant un vnement de type fraudedtect est publi et de multiples applications peuvent ainsi s'inscrire cet vnement. Il est toujours dit que le CEP est l'oppos du traitementtraditionnel : au lieu de stocker les donnes puis envoyer des requtes nousstockons les requtes puis nous envoyons des donnes. titre d'exemple si onveut superviser le trac routier nous pouvons dnir un motif pour dtecter

    35

  • l'augmentation du dbit (nombre voiture/minute). Nous pouvons dnir cemotif par une expression qui calcule la moyenne des voitures qui passent pen-dant une minute et qui notie un oprateur par une alarme, ds que le dbitdpasse le seuil (150 voitures/minute). Les vnements arrivent, dans ce cas,des puces RFID installes dans les voitures. Ds qu'elle passe, un rcepteurdclanche un vnement et l'envoie au moteur CEP.

    L'expression est la suivante

    Select *, sum(RFIDEvent) as dbitFrom RFIDEvent(itemName='Vhicule').win :time(60 seconds)Where debit 150

    Deux ds existent dans le monde des CEP. Le premier est de pouvoirreprsenter la situation ou le motif qu'en veut dtecter. Cela ncessite l'uti-lisation d'un langage qui supporte des oprations complexes telles que lajointure, l'agrgation et le ltrage temporel. L'autre d et de pouvoir sup-porter la charge d'vnements et dtecter les motifs tout en respectant lescontraintes temporelles. Autrement dit l'algorithme de dtection Matchingdoit tre ecace et scalable . Le temps de rponse ncessaire pour trou-ver le motif qui correspond aux vnements ne diverge pas. La scalabilit estvalue en terme de volume d'vnements et en terme de nombre de motifs

    L'une des utilisations courantes des moteurs CEP est la supervision desrseaux de tl-communication o dirents composants envoient des rap-ports de leurs tats sous forme d'vnements. Le moteur CEP en analysantces vnements pourra dtecter si un composant est en panne ou bien risquede l'tre, ce qui donne au CEP la possibilit de prdire une situation.

    L'une des utilisations courantes des moteurs CEP est la supervision desrseaux de tl-communication o dirents composants envoient des rap-ports de leurs tats sous forme d'vnements. Le moteur CEP en analysantces vnements peut dtecter si un composant est en panne ou bien risquede l'tre, ce qui donne au CEP la possibilit de prdire une situation. Autreexemple est le systme de livraison. Si le CEP supervise des camions de li-vraison en analysant des vnements reus de leurs puces RFID, prcisantleurs positions et leurs temps d'arrive combines des vnements venantd'autres ux comme la situation du trac routier. Le CEP pourra ainsi pr-dire un retard de livraison. Le CEP peut aussi dtecter des situations n'enpas par la prsence, mais par l'absence d'un vnement. Par exemple dans lasupervision de la livraison l'absence d'vnements venant d'un camion peutrvler une panne. Il existe d'autres domaines o le CEP peut rajouter uneagilit et doter le systme d'un autre niveau d'intelligence comme dans cetarticle o le CEP est appliqu dans les ICU pour contrler l'tat des patients

    36

  • [TIB09] [Hyd09a].

    Figure 3.1 Traitement complexe des vnements

    3.3 Motif d'vnement

    Le but des motifs est de pouvoir modliser une situation. Plus prcis-ment modliser une squence d'vnements parmi tous les vnements qui seproduisent. Bien que les motifs peuvent tre exprims en utilisant le langageSQL muni de l'extension STREAM , l'expression reste toujours lourdeet complexe et les contraintes de temps ne peuvent pas tre respectes. Parconsquent le traitement se fait par des moteurs d'infrence optimiss partemps rel et en utilisant un langage dclaratif qui exprime directement lesoprations complexes, telle que la jointure temporelle et des oprateurs expri-mant la relation entre vnement tel que (A se produit pendant B). Commeexemple simple d'un motif : imaginons un systme de contrle de transportde bagages dans un aroport o chaque bagage est dot d'une puce RFID. Lebagage est transport sur un tapis roulant muni de rcepteurs qui signalentle passage du bagage chaque point : si on dnie l'vnement Ai par lepassage du bagage A par le rcepteur i nous pouvons crire ce motif

    37

  • A3 after A2 after A1 Than EO E signal l'arrive du bagageCet exemple simple dnit un motif E Le moteur CEP reoit tous les

    vnements du systme ds qu'il dtecte le passage du bagage A par lestrois premiers rcepteurs il pourra dj signaler que le bagage est bien arriv sa destination. Bien que tous les motifs soient complexes, ils varient decomplexit du moins complexe au plus complexe comme l'indique l'exemplesuivant :

    A3 aprs (non A2 pendant 10 minutes) aprs A1 alors DDans cet exemple le bagage A n'a pas t signal par le rcepteur A2

    pendant plus de 10 minutes ce qui peut rvler une situation douteuse leCEP le signale par un avnement D [CJ09].

    3.4 Intrt du CEP

    Les grandes entreprises reoivent des vnements de l'ordre de 104 ou107[ref] vnements par seconde par exemple rservation de vol, retrait d'ar-gent, Web commerce)Analyser et traiter ce volume d'informations dpasselargement les capacits de n'importe quel systme traditionnel. Pour cetteraison le CEP vient pour rsoudre ce type de problme. Autrement dit le pre-mier intrt du CEP apparat lorsque l'entreprise gnre un grand volumed'informations venant de sources direntes. Nous avons trouv dj uneutilisation des CEP o l'application reoit 4000 vnements/heure [Gar09b].

    Comme nous l'avons dj cit dans la dnition le CEP permet l'extrac-tion de nouvelles connaissances partir de simples vnements ce qui aug-mente l'agilit du systme. titre d'exemple nous trouvons le CEP commemoyen de supervision, en tant l'coute de tout ce qui se passe dans lesystme, il pourra rvler une situation critique ou une opportunit au mo-ment adquat. Cette agilit lui permet d'tre le cerveau dans une architecturede type EDA. Le CEP est alors une cl pour crer un systme exible ca-pable de ragir selon son contexte. Pour que cet intrt apparat il faut queComme son nom l'indique- le traitement soit complexe Autrement dit lesmotifs doivent tre complexes et en nombres importants : quelques motifssimples ne justient pas l'adoption d'un CEP [Gar09a] [Liu08].

    3.5 Cas d'utilisation

    Il existe aujourd'hui de nombreuses applications de la technologie CEP,allant de la simple supervision jusqu'au traitement intelligent .Des cas d'uti-

    38

  • lisations pratiques et familires peuvent tre numrs comme suit :dtection des pidmies : dirents vnements sont analyss tels que lenombre de patients et les symptmes. Ces informations sont corrles avecd'autres donnes externes an de dtecter des pidmies .La dtection des fraudes : ceci est l'une des plus courante utilisation, elleconsiste analyser les direntes transactions en corrlant dirents vne-ments venant des ATM ou des cartes de crdit an de dtecter la possibilitde fraude notons que : une seule transaction ne permet pas de dtecter unfraude, au contraire la transaction peut paratre valide et ordinaire, maisl'analyse d'un ensemble de transactions permet de dtecter une situationsuspecte.La dtection d'intrusion : c'est l'application classique des CEP, dans cecas le CEP reoit les vnements venants du systme et dtecte les tentativesd'intrusion telles que les requtes d'authentication venant de direntessources sur une priode de temps, en d'autres termes passer d'une scuritde niveau basique une scurit intelligente o les tentatives d'intrusion lesplus malignes peuvent tre divulgus.Dans les entreprises

    Une socit utilise CEP pour traiter les vnements dans sa chaned'approvisionnement an de vrier ceux qui ont t importants etd'informer les utilisateurs de cette problmatique en fonction des rglesdnies par l'utilisateur.

    Une socit de logistique utilise CEP pour suivre et contrler automa-tiquement les livraisons. Le CEP alerte en cas de problmes de charge-ment. Le CEP propose galement des voies alternatives ou des rsolu-tions possibles aux problmes.

    Une entreprise de tlcommunications intgre CEP dans ses nuds derseau pour grer les vnements et les alertes dans le rseau, recon-gurer et modier le router en rponse des problmes

    Une autre entreprise de tlcommunications utilise CEP pour grer lesaccords au niveau de service et pour rpondre des vnements et desalertes venant de routage du trac en les orientant vers des quipementsbass sur SLA. Ce CEP identie aussi les accords qui ne peuvent passatisfaire le niveau de service par la notication

    En trouve d'autres applications dans la gestion du stock avec l'introductionde la technologie RFID. Plusieurs cas d'utilisation existent notamment avecl'adoption de plus en plus d'architecture EDA au sein des organismes [Hag09].

    39

  • 3.6 Architecture CEP

    An de mettre en place une plateforme CEP nous avons d'abord besoind'une plateforme d'vnements. Une architecture EDA facilite grandementla mise en place des CEP. Dans le cas contraire des adaptateurs doiventtre dvelopps pour permettre dirents composants tels que les bases dedonnes des processus, de gnrer des vnements. Une plateforme CEP estcompose de deux niveaux fonctionnels, la collecte et l'infrence Fig 3.2.

    Figure 3.2 Architecture CEP

    3.6.1 La collecte

    Ce niveau enveloppe la collecte des vnements, le formatage et la nor-malisation an de l'adapter au contexte CEP. A ce niveau le CEP est en

    40

  • contact avec la source d'vnements qui peut tre : Des quipements physiques : des hub, des dtecteurs,RFID. . . . Etc ; Des bases de donnes qui gnrent des vnements lors de la modica-tion des tables

    Des infrastructures de messagerie comme JMS ou ESB Des processus et Des applications de gestion telles que les CRM.

    Au niveau collecte les vnements reus seront transforms en un format com-prhensible par le moteur d'infrence. La transformation consiste extraireles informations et les prsenter sous le nouveau format. Ce format dpenddu moteur CEP choisi, il peut tre XML travers des schmas XSLT ouPOJO objet ou autre.

    3.6.2 L'infrence

    Nous trouvons ici le prtraitement et le matching . Le pr-traitementconsiste appliquer des ltres d'vnements et les raner en rajoutantd'autres informations dans leurs enttes ou dans le payload le respon-sable du pr-traitement s'appelle EPA Events Preprocessing Agent . Le matching est le cur composant de la plateforme CEP c'est le moteur d'in-frence qui permet de dtecter les motifs applicables aux ux d'vnements.Nous appelons l'algorithme utilis par le moteur d'infrence l'algorithme du matching . Comme nous l'avons dcrit dans la section prcdente l'analyseCEP est en temps rel et traite un grand volume d'vnements donc le butultime est le matching rapide de motifs sachant que les algorithmes cor-respondants traditionnels (backword chain) ne parviennent pas atteindrecet objectif en particulier lorsque le volume dpasse le million d'vnements[Gar09a].

    3.6.3 Approche non RETE

    Les approches actuelles des moteurs d'infrence CEP ne se basent passur RETE, elles sont des extensions des moteurs relationnels qui permettentde grer les contraintes temporelles et des extensions au langage SQL pourpermettre l'interrogation de tels moteurs. Nous trouvons entre autres deuxclbres moteurs :

    StreamCruncher est un moteur qui s'appuie sur une base de donnesrelationnelles pour grer le CEP [Sit09]

    Esper, est un CEP connu et qui semble mettre en uvre son propremoteur relationnel, mais le langage utilis est aussi une extension dulangage SQL. [Pag10]

    41

  • Dans le domaine propritaire beaucoup d'entreprises telles que StreamBase,ont opt pour la promotion de leurs propres algorithmes spcialiss. Cesmoteurs sont bass autour d'un SQL tendu, appel "Streaming SQL"quidtecte les motifs dans les ux. Ces moteurs sont bass sur la mme techno-logie que les bases de donnes relationnelles, mais sont conus pour traiterdes donnes en temps rel. Ils introduisent une dimension de temps dans lemodle relationnel. On peut toujours appliquer les oprateurs de base (s-lection, projection etc.), mais on peut galement demander titre d'exemplel'excution de requtes bases sur les donnes qui appartiennent un inter-valle de temps[Hyd09b].

    3.6.4 Approche RETE

    L'algorithme le plus dominant qui est en mesure de raliser la scalabilit est l'algorithme RETE. Dans sa version trois RETE ore une performancetrs leve qui peut supporter la charge en terme de volume d'vnements, enterme de nombre de motifs ainsi qu'en terme de complexit des motifs. Droolsest un exemple des solutions qui ont adopt RETE amlior pour orir unemeilleure performance et pour permettre le traitement d'vnements[Doo][KUSS09].

    3.7 Dirence entre CEP et BRE

    La question frquemment pose et qui concerne les deux types de moteursd'infrence existants (BRE et CEP) est la suivante : quelle est la direnceentre un moteur d'infrence de rgles mtiers (ou BRE) et un moteur d'inf-rence de type CEP (Complex Event Processing Engine) ?. Ceci est particu-lirement intressant, car un moteur bas sur des rgles peut tre vue commeun CEP. Les vnements dans ce cas sont reprsents par les faits, les motifspeuvent tre vus comme des rgles si/alors o la partie condition de la rglen'est rien d'autre que le motif, la partie action consiste la publication dumotif dtect.

    Si (Motif A) alors publier vnements ABien que le traitement d'vnements peut tre exprim dans le style rgle,

    il existe des dirences entre le traitement des vnements et des rgles, cesdirences sont lies au contexte et aux exigences de chacun d'eux. Nouscitons les principaux points de distinction sous forme de tableau [Vin07][Etz09] :

    42

  • Dirence BRE CEPLes entres Des faits typiquement du

    genre relations entre en-tits comme BOB est lechef d'Alice et des valeursd'attributs comme le salaired'Alice=X

    Des vnements typique-ment armatifs tels que : BOB est promu et quipossdent un temps d'arri-ve et d'expiration

    Les sorties D'autres faits infrer desfaits d'entre. Des calculesdrivs des faits tels que lamoyenne. Des actions tellesqu'un code excuter

    Publication de l'vnementqui dcrit le motif

    Temps Traitement des faits sansavoir la notion de tempsce qui veut dire consid-rer l'tat actuel du sys-tme nanmoins possibi-lit de traitement temporelsimple

    Traitement essentiellementtemporel avec la prise encharge de la notion dutemps. Possibilit de limiterle traitement dans des inter-valles de temp. Fort supportdes oprateurs temporels (Aavant B, C aprs D...)

    Maintiend'tat Sta-teless/sta-teful

    Principalement ddier laPrise de dcision selon desfaits actuels le maintiend'tat pour une longue p-riode n'est pas ncessaire

    Un traitement qui dure pen-dant une priode de tempsle maintien d'tat est nces-saire donc faire appel desmcanismes de sauvegardes

    Contrainttemps rel

    Moins d'exigences en termesde rapidit

    Ncessite un traitement entemps rel et un algorithmeecace

    Langage Des expressions si/alorsavec des oprateurs prochesSQL (select, group by. . .

    Des oprateurs temporelsplus complexes du type de(avant, aprs, pendant. . . )

    Scalabi-lit

    Exige une Scalabilit moyenne en termes denombre de rgles

    Les CEP traitent des uxd'vnements importants cequi demande une scalabi-lit en terme de nombred'vnements et en termesde nombre de patterns

    Intgration Une architecture SOA estun environnement idal

    Ncessite une plateformede gnration d'vnementstels qu'une architectureEDA

    43

  • 3.8 Conclusion

    Aucun des points prcdents n'exclut l'utilisation d'un BRE standarddans les applications CEP. Mais ce qui prcde est une indication quantaux extensions qui doivent tre ajouts un BRE standard pour en faire unmoteur CEP., En eet, certains vendeurs BRE le font dj. A titre d'exempleDrools a tendu son BRE pour inclure la totalit des fonctionnalits CEPavec le module CEP appel Drools Fusion. Drools a appliqu des extensions son langage dclaratif et son algorithme an de rencontrer les exigences dutraitement complexe des vnements.

    44

  • Chapitre 4

    JSLEE

    Sommaire4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . 45

    4.2 Historique . . . . . . . . . . . . . . . . . . . . . . . . 46

    4.3 Dnition JSLEE . . . . . . . . . . . . . . . . . . . 46

    4.4 Version JSLEE . . . . . . . . . . . . . . . . . . . . . 47

    4.5 Architecture JSLEE . . . . . . . . . . . . . . . . . . 47

    4.6 Composants JSLEE . . . . . . . . . . . . . . . . . . 48

    4.6.1 Les Service Building Blocks . . . . . . . . . . . . . 48

    4.6.2 Framework . . . . . . . . . . . . . . . . . . . . . . 49

    4.6.3 Contrle et Administration . . . . . . . . . . . . . 51

    4.6.4 Ressource Adaptors . . . . . . . . . . . . . . . . . 51

    4.7 Architecture d'application SLEE . . . . . . . . . . 51

    4.8 Dploiement des services . . . . . . . . . . . . . . . 52

    4.9 Utilisation JSLEE . . . . . . . . . . . . . . . . . . . 52

    4.10 Implmentations de JSLEE . . . . . . . . . . . . . 52

    4.11 JSLEE mobicents . . . . . . . . . . . . . . . . . . . 53

    4.11.1 Introduction . . . . . . . . . . . . . . . . . . . . . . 53

    4.11.2 Caractristiques JSLEE Mobicents . . . . . . . . . 53

    4.11.3 Ressource adaptor . . . . . . . . . . . . . . . . . . 53

    4.12 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 53

    4.1 Introduction

    La notion de serveur d'application est un concept bien connu dans lemonde de dveloppement. Un SA permet le dveloppement rapide d'appli-

    45

  • cations. Il assure galement de grandes performances. En orant un Frame-work de travail, il facilite et acclre la cration et le dploiement des ap-plications. J2EE AS est le leader mondial des serveurs d'applications. Cettedernire technologie est fortement utilise dans le domaine des IT son avan-tage consiste accrotre la productivit et rduire l'eort des dveloppeursdans la rsolution du cur des problmes. Pour arriver ce rsultat des en-tits programmables seront utilises pour btir la solution. L'quivalent deJ2EE dans le monde des Tlcommunications et des applications ayant descontraintes temps rel s'appelle JSLEE. Dans ce chapitre nous prsentons leserveur d'application JSLEE, nous donnons son architecture ses composantsainsi que son principe de fonctionnement.

    4.2 Historique

    En 1998, SUN introduit la plate-forme JAVA au monde de l'industrie desfournisseurs de services en crant la communaut JAIN. Cette communautcomprend environ 80 entreprises (fournisseurs de matriels, d'quipementsrseaux, de protocoles et des dveloppeurs de services). JAIN est contrlpar SUN, qui assure la qualit des APIs, leurs homognits et leurs compa-tibilits. JAIN est un ensemble d'API qui permet un dveloppement rapidede nouveaux services pour des rseaux de tlcommunication voix ou don-nes. L'utilisation de JAIN rend le dveloppeur de services indpendant dumatriel et des protocoles. Jain ore 4 API [jai09a]. JAIN Protocol API

    JAIN Call Control API JAIN Service Logic Execution Environment ou JSLEE JAIN Service Creation Environment

    4.3 Dnition JSLEE

    SLEE 1 dsigne une architecture modulaire des applications orientes T-lcommunication, bas sur la communication en mode vnement, il spciegalement la relation entre les dirents modules d'application. La crationde cette architecture principalement ddie aux applications tlcoms estdue aux exigences de ce type d'application, nous citons titre d'exemple laconnectivit o dirents protocoles sont utiliss, nous citons aussi les exi-gences temporelles qui font que le temps de traitement est limit et enn lebesoin au maintient de charge ou la scalabilit. SLEE dnit galement l'en-vironnement dans lequel les applications s'excutent et voluent.[SL09] JS-

    1. Service Logic Executing Environement

    46

  • LEE est la spcication JAVA des serveurs SLEE, elle porte le nom JSR240,il dnit un ensemble d'API qui permet le dveloppement des applicationsdestines au monde Tlcom, il fournit galement l'environnement de dve-loppement, l'architecture de l'application et la relation entre ses direntscomposants. JSLEE permet au dveloppeur de travailler un niveau plushaut appel service, sans se proccuper des rseaux sous-jacents. Le but alorsest de rapporter la portabilit aux applications SLEE en utilisant les APIJAVA ainsi que la spcication technique. JSLEE ou JAIN SLEE est pour lemonde des tlcommunications ce que J2EE est pour le monde IT, ce qui luidonne un rle important dans l'intgration des applications IT et Telecom etouvre la porte la cration rapide de nouveaux services valeur ajout surle rseau tlcom.

    4.4 Version JSLEE

    JSLEE est actuellement en sa version 1.1 celle-ci porte sur la standardisa-tion de la connexion entre les ressources adaptors et SLEE elle rvise certainsconcepts en rajoutant des fonctions et en dtaillant ce qui tait obscure dansla version 1.0. Cette version rajoute galement certains concepts dont les li-brairies. Cependant, les applications fonctionnant dans la version 1.0 restentcompatibles avec la version 1.1 [jai09c].

    4.5 Architecture JSLEE

    tant une spcication JSLEE propose un ensemble d'entits fonction-nelles entre lies. L'architecture gnrale de JSLEE est forme de 4 partiesFig 4.1.Les SBB ce sont les entits qui dtiennent le code programmable oul'intelligence et qui vont cooprer an de fournir le service, les RA RessourceAdapter ce sont les entits qui permettent au JSLEE de communiquer avecle monde extrieur, ils sont constitus d'un ensemble d'API qui donne auSBB la possibilit de communiquer avec les ressources extrieures quel quesoit leur nature. Le Framework c'est l'ensemble de fonctionnalits oert parJSLEE au dveloppeur pour faciliter la cration des SBB titre d'exemplele TIMER, le routage d'vnement ...etc. le CM 2 c'est l'entit qui permetla gestion de l'excution des services, elle gre la cration et l'inscriptiond'vnements. Elle ore galement une console pour rcolter des statistiques[jai09c][jai09b].

    2. Contrle Module

    47

  • Figure 4.1 Architecture SLEE

    4.6 Composants JSLEE

    4.6.1 Les Service Building Blocks

    Ce sont les composants qui dtiennent le code fonctionnel de l'applicationelles cooprent pour fournir le service attendu titre d'exemple un Servicequi ore au client le lieu de restauration le plus proche peut tre constitu

    48

  • de deux SBB un SBB pour la localisation et un autre pour la recherchedu restaurant. Les SBB se communiquent en changeant des vnements titre d'exemple le SBB de localisation mettra un vnement du type "clientlocated "qui va tre consomm par le SBB de recherche. Toutefois ; ellespeuvent communiquer travers des interfaces locales.

    Un SBB est form d'une classe abstraite qui doit dnir la mthode ap-pele par JSLEE en cas de rception d'vnement, pour chaque vnementdont la SBB est lie il existe une telle mthode. Les vnements qui serontenvoys une SBB doivent tre mentionns par leur type dans la SBB elle-mme. Dans l'exemple prcdant c'est l'vnement du type "Client request"qui est envoy la SBB de localisation, par consquent la SBB de localisationdoit explicitement s'inscrire ce ux d'vnement. Les SBBs sont organissdans une architecture de parent ls. Chaque SBB doit mentionner explicite-ment ses ls ceci donne un graphe form d'un SBB racine est des SBB ls.Ce graphe modlise le service oert par l'application. Dans l'exemple prc-dant le graphe est form de deux SBBs Fig4.2. An de traiter un vnement,JSLEE instance une SBB, cette instance est appele SBB entit, la SBB ins-tanci doit imprativement tre un SBB racine d'un graphe qui modlise unservice. La SBB racine instance ensuite le reste des SBB du graphe[jai09c].

    4.6.2 Framework

    JSLEE ore un certain nombre de fonctionnalits utilisables par les SBBtelle que :

    Les proles JSLEE dnie la notion de prole an de sauvegarder lesdonnes provisionnes ces prols sont dcrits par leur schma sous formed'attributs. Les prols sont sauvegards dans des tables appeles tablesde prols titre d'exemple un prol de droit d'accs est utilis dans leservice prcdent de recherche de restaurant.Name Phone numberBob 048346676Alice 048342564Cesar 048909090

    Activity context Ce concept peut tre vue comme une session qui encapsule des attributs lies au ux d'vnements les SBB doivent trerattaches un AC 3 Ce concept peut tre vue comme une session quien-capsule des attributs lies au ux d'vnements les SBB doivent treattachs un AC Activity Context an de recevoir les vnements.

    3. Activity Context

    49

  • Figure 4.2 graphe SBB

    C'est au SLEE d'attacher les SBBs au AC, quand un vnement ditinitial auquel elles sont lies apparat et de la mme manire de les d-tacher avant de supprimer le service. Toutefois, un SBB pourra changerson AC via des mthodes, an de recevoir des vnements lis d'autreAC. Les AC sont reprsents dans JSLEE par un ACI activity contextInterface .

    Activiity object Un AO 4 est un objet qui reprsente un ux d'vne-ments, il ore un ensemble de mthodes qui permet de contrler le uxd'vnements titre d'exemple : dans le cas du service de recherche derestaurant un AO reprsente les requtes des clients. Cet AO est lie un AC et il est manipulable par l'adaptateur de ressources dcrit parla suite.

    Autre Fonctionnalits :JSLEE ore d'autres fonctionnalits telles quele Timer, la recherche des services, la recherche d'vnements...etc. Ces

    4. Activity Object

    50

  • fonctionnalits sont accessibles au SBB et au RA. JSLEE inclut la notion de librairie dans sa version 1.1 an de pouvoirremplacer l'utilisation des CLASSPATH. Une librairie est un ensemblede classes qui fournit des fonctionnalits aux composants de JSLEE(RA et SBB). L'utilisation des librairies permet de partager ces classespar dirents composants.

    4.6.3 Contrle et Administration

    JSLEE ore une console qui permet le contrle de l'excution des appli-cations. An d'administrer les services. JSLEE spcie un ensemble d'op-rations qui doivent tre oertes par la console nous citons :

    Lancer / arrter un service Installer ou dsinstaller un service Crer des proles l et les modier Rcolter des statistiques

    4.6.4 Ressource Adaptors

    le RA 5 Le RA Resource Adaptor est l'entit qui permet au SBB de dia-loguer avec le monde extrieur. Le Resource Adaptor est considr commel'un des avantages de JSLEE, car il vite au dveloppeur de se proccuperde la communication externe, ce qui acclre le dveloppement. Chaque typede Resource Adaptor est spci par un organisme ou un groupe d'experts travers des interfaces. Les dveloppeurs des RA implmentent ces interfacespour chaque produit JSLEE. A titre d'exemple un SIP Resource Adapter quipermet des SBB d'utiliser la ressource SIP. Le Resource Adapter est formd'un ensemble de classes qui incluent imprativement l'implmentation desinterfaces du type de Resource Adaptor cible. L'une des fonctionnalits lesplus importantes d'un Resource Adaptor est le transfert des vnements auJSLEE an qu'il les achemine la SBB concerne .[jai09c].

    4.7 Architecture d'application SLEE

    Une application destine JSLEE est forme d'un ensemble de SBB. Ledveloppeur pro-cde l'identication de l'ensemble des ressources auxquellesil aura besoin dans son appli-cation, titre d'exemple des Resources Adap-tor, d'autre SBB dans le JSLEE ou bien des Proles, ces ressources peuventexister ou elles sont crs par le dveloppeur. Il dessine ainsi le graphe de

    5. Ressource Adaptor

    51

  • son service qui dni l'ensemble des SBB et la relation entres elles. La sp-cication JSLEE exige que les SBB crs doivent tre sous forme de classesabstraites. Le serveur JSLEE implmentera ces classes au moment de d-ploiement. Le dveloppeur rajoute ventuellement un ensemble d'entits titre d'exemple : Les Local Interface Object qui sont des classes abstraitesdnissant un ensemble de mthodes permettant une SBB d'tre appelerpar une autre SBB. Ces interfaces sont dcrites dans le descripteur du SBB.

    4.8 Dploiement des services

    An de dployer un service JSLEE propose l'utilisation des packages JAR.Ainsi un service est sous forme d'un chier JAR contenant obligatoirementle descripteur de service. Parmi les informations incluses dans le descripteurnous trouvons les dirents descripteurs des entits utilises par le servicenotamment les SBB les Resources Adaptor les prols et les vnements . Cemcanisme facilite l'utilisation est le dploiement des services. Le contenu depackage JAR est spci de manire dtaille dans le JSLEE 1.1 [jai09c].

    4.9 Utilisation JSLEE

    JSLEE est trs rpondu, dans le monde de IMS beaucoup d'entreprisesplanie d'utiliser JSLEE comme plateforme des composants IMS par exemplele serveur d'application ou bien le CSCF. Grce a ces standards JSLEE per-met une exibilit de dveloppement et de dploiement des services orientscommunication.

    4.10 Implmentations de JSLEE

    L'implmentation de JSLEE doit respecter les contraintes de performancelies au monde de tlcommunication. Nous citons la faible latence titred'exemple le temps ncessaire pour tablir un appel doit tre < 500 ms Unedeuxime contrainte est le haut dbit qui dsigne la possibilit de suppor-ter des millions d'appel, l'autre contrainte est la disponibilit, qui doit trede 99.999 ou bien environ 6 minutes d'indisponibilit par an. Il existe di-rent vendeurs d'implmentation JSLEE : jNETx JAIN SLEE, Open Cloud,Mobicents. Alcatel-Lucent.

    52

  • 4.11 JSLEE mobicents

    4.11.1 Introduction

    JSLEE Mobicents est la seule implmentation open source de JSLEE cer-tie JSLEE 1.1 elle fait partie de la suite Mobicents Communication Plate-forme. JEE SIP SERVELET MEDIA SERVER et JSLEE. Mobicents JSLEEest un ensemble de POJO Beans Plain Old Java Object Beans dploys surun serveur J2EE JBOSS 6

    4.11.2 Caractristiques JSLEE Mobicents

    Autre que l'avantage d'tre disponible gratuitement tant un produit opensource Le dveloppeur bncie de l'aide de la communaut JBOSS. JSLEEMobicents propose aussi un dploiement facile des applications. Il ore ga-lement une console JMX qui permet la conguration et le contrle des appli-cations SLEE de manire simple [mob09].

    4.11.3 Ressource adaptor

    JSLEEMobicents ore un ensemble de Resource Adaptors parmi eux nouscitons : SIP Resource Adaptor -XMPP Resource Adaptor-Asterisk ResourceAdaptor -Java Call Control (JCC) Resource Adaptor- Parlay/Parlay-X Re-source Adaptor - J2EE/JCA Resource Adaptor- Diameter Resource Adaptor-Media Resource Adaptor -XCAP Client RA Fig4.3

    4.12 Conclusion

    Nous avons dans cette partie introduit les serveurs d'application JSLEE.que nous avons tudis et analyss leur architecture et leurs composants.Nous avons galement introduit JSLEE Mobicents qui est une implmenta-tion open source de la spcication JSLEE. Par la suite nous allons tudier lapossibilit d'utiliser le serveur d'application JSLEE pour concevoir une archi-tecture oriente vnement les dtails de cette architecture seront prsentsdans la deuxime partie de ce travail.

    6. EAS JBOSS micro container

    53

  • Figure 4.3 plateforme Mobicents

    54

  • Deuxime partie

    Implmentation d'un moteurd'infrence dans une architecture

    EDA

    55

  • Chapitre 5

    Extension BRE-CEP

    Sommaire5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . 56

    5.2 Extensions d'algorithme d'infrence . . . . . . . . 57

    5.3 Quelles sont les extensions BRE? . . . . . . . . . 58

    5.4 Exemple d'extension d'un BRE . . . . . . . . . . 60

    5.4.1 Description Drools fusion . . . . . . . . . . . . . . 60

    5.4.2 Les extensions Drools Fusion ? . . . . . . . . . . . . 68

    5.4.3 Drools Fusion et EDA . . . . . . . . . . . . . . . . 70

    5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . 71

    5.1 Introduction

    Dans un prcdent chapitre nous avons parl d'architecture oriente v-nements et de l'apport qu'une telle architecture apporte au systme IT, enl'occurrence l'agilit et la exibilit qu'ore le traitement par vnement.Nous avons galement dcrit ses composants notamment la source d'vne-ment, le collecteur d'vnements (Event collector) et le moteur d'infrenceCEP. Ce dernier avait fait l'objet d'un chapitre o nous l'avons tudi et com-par aux moteurs d'infrence des rgles mtiers (BRE) en concluant qu'unBRE standard peut tre utilis dans les applications de type CEP condi-tion que certaines extensions lui seront appliques. La question vidente estquelle sont les direntes extensions qui doivent tre appliques un moteurd'infrence de type BRE pour qu'il puisse traiter les vnements et jouer lerle d'un CEP? Dans notre travail nous analysons les extensions qui doiventtre appliques aux BRE an de satisfaire les besoins des applications CEP

    56

  • et nous essayons ensuite dans un autre chapitre de proposer une architec-ture hybride dans laquelle nous intgrons le BRE une architecture orientevnements de manire orir un service CEP.

    5.2 Extensions d'algorithme d'infrence

    CEP et RETE

    L'algorithme dominant dans le monde des moteurs d'infrence orientsrgles mtier est bien l'algorithme RETE. An de pouvoir utiliser un BREcomme CEP il faut se poser la question suivante : RETE convient-il au trai-tement complexe d'vnements ou bien CEP? Bien qu'il soit utilis surtoutdans les moteurs BRE, RETE est d'abord et avant tout un algorithme derecherche de correspondance (Matching Algorithm). Il est utilis dans lesmoteurs de rgle et les systmes experts, mais il n'y a rien qui le limiteau rgles mtier . C'est juste un moyen de compiler si / alors dans unelogique permettant le MATCHING de faon optimis o les objets et lesrgles sont cr l'excution. RETE est sorti de la ncessit de traiter dessituations trs dynamiques o un systme a besoin de s'adapter l'volu-tion des vnements. Il existe direntes stratgies pour tendre RETE autraitement d'vnements titre d'exemple le moteur JESS a supprim le m-canisme d'agenda rendant l'excution des rsultats d'activation immdiatedans le but d'accrotre la performance du processus de MATCHING. Cer-taines autres stratgies consiste l'extension de l'algorithme RETE lui-mmepour permettre la prise en compte de la logique vnement.

    Dans cette perceptive Berstel [Ber00]avait propos une extension CEP l'algorithme RETE qui se base sur la modication des nuds de jointuredu rseau RETE tout en gardant la mme ide de l'espace de travail WM.Dans cette approche, Berstel propose d'utiliser un mme WM pour insrerles faits et les vnements, la distinction entre les deux est faite au momentde l'insertion. Dans le cas des faits une mthode INSERT est utilise alorsque dans le cas des vnements la mthode INSERT-EVENT sera utilisepour l'vnement qui est annot par un TIMESTAMP. Le principe de re-cherche des motifs du Berstel consiste eectuer des tests temporels dansles noeuds de jointure, cela permet ces nuds de calculer le temps d'ex-piration d'vnement qui servira la suppression automatique d'vnementsobsoltes. Le point faible de l'algorithme de Berstel est qu'il n'avait introduitque deux oprations temporelles parmi les 13 connues. ces deux oprateurssont l'oprateur AFTER et l'oprateur BEFORE[Ber00].

    Une autre extension de RETE a t propose en vue de permettre le trai-

    57

  • tement complexe d'vnements. Dans cette approche contrairement Berstelles faits et les vnements ont t spars. Un graphe d'vnement respon-sable de la dtection des patterns est introduit cot du graphe RETE quicontinue tre responsable de la dtectio