Étude et implémentation d un moteur d inférence dans une architecture orientée événements basée sur JSLEE

Transcription

1 FACULTÉ DES SCIENCES APPLIQUÉES COMPUTER & DECISION ENGINEERING DEPARTMENT Étude et implémentation d un moteur d inférence dans une architecture orientée événements basée sur JSLEE Année académique 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

2 Remerciements Ma gratitude s'adresse particulièrement à mon co-promoteur Sabri Skhiri pour sa disponibilité, sa bienveillance, ses conseils judicieux et ses encouragements qu'il m'a prodigué avec patience et gentillesse tout au long de la réalisation de ce mémoire. Je remercie également mon promoteur Pr. Esteban Zimanyi de m'avoir incité à améliorer la qualité de mon travail, je tiens à le remercier aussi pour le temps consacré à la lecture de ce travail. Enn, je tiens à remercier ma s ur Habiba, mes amis Amine Ghoubali, Abdelkarim Ghoubali et Belkacem Kherrab qui m'ont aidé, conseillé et soutenu tout au long de l'année. 1

3 Résumé Ce travail propose d'étudier les moteurs d'inférence de type BRE et de type CEP an de créer une architecture hybride permettant de substituer le moteur d'inférence CEP par un moteur d'inférence de type BRE. Nous proposons une architecture hybride orientée événements basée sur le serveur d'application JSLEE. La première partie présente le concept des architectures orientées événements et les moteurs d'inférence BRE et CEP. Nous comparons ensuite les deux types de moteurs d'inférence avant de proposer dans la deuxième partie notre architecture hybride basée sur JSLEE. 2

4 Table des matières Introduction 8 I État de l'art 10 1 L'architecture orientée événement Introduction Historique Concepts SOA Évolution du SOA EDA Conclusion Les moteurs d'inférence BRE Historique Dénition des Business Rules Engine Dénition des règles Intérêt de BRE BRE et SOA Architecture BRE Caractéristiques des BRE Conclusion Les moteurs d'inférence CEP Introduction Dénition CEP Motif d'événement Intérêt du CEP Cas d'utilisation Architecture CEP Diérence entre CEP et BRE

5 3.8 Conclusion JSLEE Introduction Historique Dénition JSLEE Version JSLEE Architecture JSLEE Composants JSLEE Architecture d'application SLEE Déploiement des services Utilisation JSLEE Implémentations de JSLEE JSLEE mobicents Conclusion II Implémentation d'un moteur d'inférence dans une architecture EDA 55 5 Extension BRE-CEP Introduction Extensions d'algorithme d'inférence Quelles sont les extensions BRE? Exemple d'extension d'un BRE Conclusion Motivations et objectifs Introduction Pourquoi un BRE à la place d'un CEP? Quel obstacle? Les grandes lignes de la solution Conclusion Spécication Introduction Fondements du projet Contraintes Spécications fonctionnelles Spécications non fonctionnelles Conclusion

6 8 Analyse et conception Introduction Les composants de l'architecture Fonctionnement Déploiement Dénition d'événement L'architecture répond-t-elle aux attendus? Conclusion Implémentation Introduction L'événement générique Le Resource Adaptor Drools Le service Proxy Agent EDA Agent X Exemple d'exécution Conclusion Conclusion Générale 111 Bibliographie 113 5

7 Table des gures 1.1 Description du concept SOA Architecture d'un simple service web Architecture SOA par ESB Architecture EDA BRE & SOA Architecture BRE Réseau RETE Traitement complexe des événements Architecture CEP Architecture SLEE graphe SBB plateforme Mobicents Architecture Hybride Prtée de travail diagramme des cas d'utilisation Architecture hybride Architecture du resource adaptor BRE Drools diagramme de séquence du cas d'utilisation diagramme de séquence du cas d'utilisation diagramme de déploiement Le JMS Resource Adapter RA Diagramme de classe du Resource Adaptor Type Diagramme de classe du Resource Adapter Drools Exemple déploiement des règles Exemple Service Proxy Diagramme de classe du SBB Proxy

8 9.7 Schéma de l'exemple Interface application Client

9 Introduction Les outils informatiques connaissent dans ces dernières années une évolution rapide. Ils sont utilisés dans toutes les couches de l'entreprise, partant du système opérant tel que les outils d'automatisation jusqu'aux outils d'aide à la mise en place des stratégies d'entreprise. D'autres types d'outils se trouvent dans un niveau plus haut dans les couches de l'entreprise où ils sont utilisés pour l'automatisation de la prise de décision, nous y trouvons dans le domaine du BI Business Intelligence. Bien qu'aujourd'hui nous ne somme pas encore arrivé à l'ultime phase du BI, qui consiste à la prise de décision automatique, un grand progrès a été fait dans ce sens. Nous trouvons alors des outils comme les processeurs d'événements et les moteurs de règles métier qui orent un sous ensemble de fonctionnalités du BI. Les moteurs de règles métier sont des outils qui permettent de séparer les règles dénies par l'entreprise et de les isoler du code source. Ceci an de les gérer séparément pour pouvoir les tester et les mettre à jour sans avoir à modier des codes source, souvent non compréhensible par les experts de l'entreprise. Les moteurs de règles métier sont responsables de l'évaluation et l'exécution au moment adéquat. Les CEP sont d'autre part des outils orant des fonctionnalités BI combinées à des contraintes de traitement temps réel. Contrairement aux moteurs de réglés métier les CEP s'intègrent souvent aux architectures orientées événements dans lesquelles les diérents composants du système communiquent à travers l'échange d'événements. Ces derniers sont des objets véhiculant l'information. Les CEP captent ces événements et analysent en temps réel les informations véhiculées par eux, ceci an de détecter une séquence d'événements appelée motif, par conséquent une suite d'actions sera exécutée. Bien que les deux composants semble diérents il y a entre eux une grande similitude de fonctionnement, car ils sont tous les deux des moteurs d'inférence. Leur principe de fonctionnement consiste à analyser des données via l'évaluation des conditions. Malgré cette similitude les technologies BRE par opposé aux CEP ont atteint leur maturité ainsi les outils BRE existants sont plus répandus que les CEP. Cela mène à la question suivante est-il possible 8

10 d'utiliser les moteurs BRE comme des moteurs CEP?. L'objectif de ce travail est d'étudier les moteurs de règles métier BREet les processeurs d'événements CEP- ainsi que les technologies qui y sont associées, an de pouvoir les comparer et proposer ensuite une architecture hybride dans laquelle un moteur BRE est utilisé pour orir un service CEP. Cette architecture combine le moteur d'inférence Drools et le Serveur d'application JSLEE. Le travail est organisé en deux parties. Dans la première partie nous commençons par un état de l'art qui présente les architectures des systèmes informatiques notamment l'architecture orientée services et l'architecture orientée événements. Nous nous penchons ensuite sur les moteurs de règles métier et les processeurs d'événements, nous donnons leurs dénitions, leurs architectures ainsi que leurs fonctionnements. Nous passons ensuite à la comparaison entre les deux types de moteurs d'inférence an de répondre à la question posée au début. Nous terminons cette partie par une présentation du serveur d'application JSLEE que nous utilisons dans la partie suivante, nous décrivons ses composants et son utilisation. Dans La deuxième partie nous commençons par présenter les extensions qui ont donné une capacité CEP au moteur BRE Drools, nous passons à la description de l'objectif de notre architecture hybride où nous justions l'utilisation du BRE Drools et du serveur d'application JSLEE pour orir une plateforme CEP. Nous présentons ensuite les composants et le fonctionnement de notre architecture hybride. Enn nous présentons l'implémentation d'un prototype de notre architecture qui sera présenté sous forme d'une démonstration dans laquelle nous simulons l'application de cette architecture à la supervision d'un réseau d'accès. 9

11 Première partie État de l'art 10

12 Chapitre 1 L'architecture orientée événement Sommaire 1.1 Introduction Historique Concepts SOA Dénition du SOA Dénition d'un Service Intérêt du SOA Évolution du SOA WS-SOA SOA par BPM SOA par ESB BRMS dans SOA BRMS vs BPM Limites du SOA EDA SOA L'événement Dénition EDA Intérêt du EDA Fonctionnement EDA Composants du EDA Conclusion

13 1.1 Introduction Le concept EDA 1 existe naturellement dans notre monde. Le Professeur. David Luckham a déclaré dans un article traitant du concept EDA que nous vivons dans un monde événementiel The world is event-driven [Luc07]. Dans la nature il existe plusieurs exemples de cela, la réaction d'un lion face à l'événement de l'arrivée d'un zèbre doit être instantané, il perdra sinon une occasion d'avoir une proie et de la même manière le zèbre n'attendra pas pour réagir à l'arrivée du lion qui est un événement dangereux pour lui. Dans le monde de l'entreprise, les situations dièrent, mais le paradigme reste le même. Les bourses possèdent des algorithmes temps réel qui réagissent aux changements à l'intérieur du marché boursier, soit pour saisir des occasions ou pour éviter des dégâts. Les banques aussi réagissent aux transactions et peuvent détecter les tentatives de fraude. La question qui se pose est de savoir si les systèmes IT reètent cette réalité événementielle et seront-ils capable d'en tirer avantage?. 1.2 Historique Revenons un peu en arrière pour voir quel était le fonctionnement des systèmes IT. Au début, la base du de fonctionnement était le mode Schedule qui est lui-même basé sur une architecture assez simple. Le mode Schedule est le fait de planier une certaine action à un certain temps sous forme de Batch ou de travail à exécuter périodiquement. Malgré le fait que ce mode répondait à des besoins de cette époque, il reste loin de répondre aux besoins actuels de l'entreprise. Aujourd'hui, ce mode est incapable de reéter la nature événementielle de notre monde. Nous donnons un exemple où le mode Schedule ne permet pas cette interaction : imaginons une entreprise qui gère les commandes de ses clients en mode Schedule, chaque n de journée elle exécute un Batch qui envoie les commandes de livraison. Une telle approche retarde la livraison ce qui engendrera la perte des clients. Le mode Schedule, quoiqu'il répond à un certain besoin, est incapable de satisfaire les besoins de notre monde événementiel. Pour répondre aux besoins actuels de l'entreprise un nouveau paradigme qui porte le nom SOA est apparu dans le monde IT. 1. Event Driven Architecture 12

14 1.3 Concepts SOA Dénition du SOA SOA 2 est apparue pour donner plus de uidité aux systèmes IT. L'entreprise est vue comme un ensemble de services combinés. Ces services appartiennent à diérents domaines : nancier, gestion du personnel, production etc. SOA permet la combinaison des services pour réaliser le business[tay06] L'intérêt de ce concept est d'augmenter la réutilisation des composants du système IT et de diminuer la dépendance entre ses diérents composants. SOA n'est pas liée à une technologie ni à une implémentation c'est une architecture qui se base sur deux principes : la modularité et l'accès distant. SOA peut être implémenté avec plusieurs technologies, à titre d'exemple DCOM, CORBA ou WS 3 cette dernière technologie est l'implémentation la plus courante du SOA. Le WS consiste à envelopper dans un serveur les codes qui délivrent le service. Ces codes sont créés avec diérentes technologies, ils seront, ensuite, exposés comme un service capable d'être appelé par n'importe quelle entité connectée au réseau ou bien par un autre WS. An de mieux comprendre SOA il convient de donner la dénition d'un service. Figure 1.1 Description du concept SOA 2. Service Oriented Architecture 3. Web Service 13

15 1.3.2 Dénition d'un Service Un service est une entité business qui accepte une requête et rend un résultat à travers une interface. Un service peut eectuer un travail comme des calculs en comptabilité ou bien la mise à jour d'une base de données. Un service ne doit pas dépendre de l'état des autres services. Cette dénition donnée est indépendante de la technologie utilisée pour implémenter un service. [Tay06] Intérêt du SOA La problématique des systèmes IT c'est qu'ils sont constitués de diérentes technologies et de diérents langages de programmation, ce qui rend la communication entre eux dicile. Par conséquent il est dur de réutiliser des modules déjà existants pour compléter d'autres modules. A titre d'exemple, si le service nancier dispose d'un module d'identication et que l'on enveloppe ce service sous forme de WS, on peut l'exposer pour qu'il soit utilisé par le service facturation des clients ou bien le service contrôle de production. De cette façon, nous pouvons diminuer le temps de développement et assurer la abilité du système. Le deuxième intérêt du SOA est le découplage des services. Le découplage consiste à séparer les diérents services ce qui veut dire qu'un service ne dépend pas d'un autre. En pratique le terme décrit les services qui peuvent communiquer entre eux sans avoir besoin de partager de connaissances au préalable telles que les noms des fonctions, le format de message ou toute autre information. Le but de cela est de permettre le changement des services sans être obligé de faire des changements dans les autres modules. SOA permet d'augmenter le re-use 4 et le découplage, mais à un certain niveau, car il y a toujours un partage de connaissances. Un appelant doit, en eet, connaître les interfaces de l'autre service SOA qui lui-même fonctionne sous forme request/reply ou en mode pull, cela veut dire que si un service a besoin de communiquer avec un autre, il lui envoie un message et attend la réponse.[fal05] 4. réutiliser le même service par d'autres services 14

16 1.4 Évolution du SOA WS-SOA SOA est implémentée en général avec des WS. Les WS sont des unités de code qui peuvent être invoqués par le protocole HTTP. Contrairement aux autres implémentations les WS ne nécessitent pas un protocole spécique pour l'accès aux exécutables à distance, comme c'est le cas pour CORBA 5 qui nécessite l'utilisation du IIOP 6 ou bien JavaBeans 7 qui nécessite RMIP 8. Ceci permet d'exposer les fonctionnalités du code sous forme de service qui peut être utilisé par les autres applications à travers le réseau. Ce qui ore à des applications écrites en.vb ou.net la possibilité de communiquer avec des applications écrites en Java et vice versa [Dah09]. Un web service contient un nombre de classes, interfaces et structures qui ore une boite noire pour le client distant. Un web service dénit un objet qui exécute en général une unité de travail. A titre d'exemple lire des données ou eectuer des calculs. Les WS communiquent en échangeant des messages SOAP Simple Object Access Protocol à travers du simple HTTP ce qui permet d'utiliser la connexion faible débit pour les implémenter. Pour permettre à ces services de communiquer, le WS dénit un ensemble de standards facilitant l'échange des messages et l'appel des procédures à distance. Nous donnons ici une description de ces standards : -UDDI Universal Description, Discovery, and Integration est un protocole qui décrit les services web existants. Ce standard permet l'enregistrement des services dans un annuaire et de les exposer à l'extérieur. Les entreprises peuvent alors utiliser d'autres services via le web. L'enregistrement et l'échange se font à travers des messages XML sur du HTTPS. -SOAP Simple Object Access Protocol c'est le protocole de communication entre les services. Il permet à des applications ou services distants d'appeler des services sur d'autres serveurs et d'invoquer des méthodes, SOAP envoie des requêtes sous forme de XML qui contiennent des données à traiter ainsi que l'adresse de l'objet appelé. -WSDL Web Service Description Language est le standard pour la description du web service, c'est un chier XML qui dénit les interfaces et les détails d'implémentation du service. WSDL est référencé dans UDDI et il décrit les SOAP messages utilisés pour ce service Web Fig 1.2. Le contact entre les WS peuvent se faire par programmation interne où chaque service 5. Standard de gestion d'objets distribués 6. Internet Inter-ORB Protocol 7. composants logiciels écrits en langage Java 8. Remote Method Invocation Protocol 15

17 invoque d'autres, an de réaliser le but du business. Une autre façon de coopération entre services est d'utiliser un service d'orchestration, le BPM 9 est un candidat idéal pour jouer ce rôle [Wen08]. Figure 1.2 Architecture d'un simple service web SOA par BPM Un BPM est une technologie qui existe depuis les années 90 elle permet d'exécuter et superviser les processus métiers, en d'autres termes il exécute les diérentes étapes et tâches an de réaliser un processus métier. A titre d'exemple l'ouverture d'un nouveau compte bancaire déclenche un certain nombre d'activités à savoir : vérier si le demandeur n'est pas sur la liste noire, mettre à jour les bases de données, créer des clés et des mots de passe etc. Dans le cadre de SOA le BPM est utilisé pour orchestrer la communication entre les WS an de réaliser le but du business, il sélectionne et invoque des services, il est également capable de suivre et tester l'ecacité de ce processus Dans le cas de WS-SOA le processus métier est décrit par un langage spécialisé, le plus répondu parmi ces langages est WS BPEL Web Service Business Process Execution Language. Le BPM exécute ensuite le 9. Business Process Management 16

18 processus qui devient alors un service décrit par un chier WSDL et qui peut être lui-même invoqué par d'autres processus [WG05] Parmi les BPM les plus connus nous citons : Produit Open Source Oracle BPEL Process Manager Non IBM WebSphere Process Server Non Microsoft BizTalk Server Non ActiveBPEL Engine Oui SOA par ESB SOA a évolué par l'utilisation d'un ESB pour connecter les diérents services. On peut voir le ESB comme une version allégée du EAI 10 Il combine une technologie de transport asynchrone et des services techniques à valeur ajoutée (routage, transformation...etc ). Au lieu des connexions point à point, un ESB ore des adaptateurs permettant l'intégration de diérents services et systèmes comme le montre la Fig1.3. Il est possible également de dénir certaines règles dans le ESB via du XML pour lancer des Workow ou ltrer certains messages. Actuellement nous trouvons diérents protocoles d'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 Non IIBM WebSphere Message Broker Non Apache ServiceMixr Oui Mule Oui BRMS dans SOA Dans une architecture SOA un BRMS 11 est le composant qui permet la gestion et l'automatisation des règles métier. Les règles métier dérivent des règles législatives (un employé peut être licencié pour multiples absence non justiée "), ou bien de la stratégie de l'entreprise ("chaque client fait des achats de plus de 1000 euro bénécie d'une réduction de 10%"). Le BRMS permet l'enregistrement, la classication et l'exécution de ces règles, il permet aussi de vérier la consistance des règles, à titre d'exemple : il peut détecter l'existence de deux règles contradictoire ("un client potentiel peut bénécier 10. Entreprise Application Integration 11. Business Rules Management System 17

19 Figure 1.3 Architecture SOA par ESB d'un crédit"), ("aucun crédit ne doit être accepté"), il peut aussi inférer d'autres faits qui engendre à leur tour d'autre règles. [Tay06] Parmi ses fonctionnalités, nous citons : un éditeur de règles des outils de détection d'erreurs (ou détection d'incohérences dans les règles) item des mécanismes de contrôles de droits d'accès un REPOSITORY où se trouvent les diérentes versions des règles un contrôleur de versions un générateur de code un BRE Le BRE n'est donc plus qu'un simple composant optionnel d'un BRMS. Certains BRMS ne disposent pas de mécanismes d'inférence en lieu et place de l'inférence, on retrouve de la génération de code. Parmi les plus connus BRMS nous citons : Produit Open Source JBoss Drools Oui Fair Isaac Blaze Non IBM jrules Non 18

20 1.4.5 BRMS vs BPM BRMS est diérent du BPM, car il est utilisé pour la séparation et l'externalisation des règles métier et non pas la gestion et l'exécution des services. Puisque les règles qui dénissent la stratégie de l'entreprise changent fréquemment, si elles sont intégrées aux codes des services on sera obligé de redéployer ces services à chaque changement ce qui n'est pas pratique. Par contre, l'externalisation de ces règles dans un BRMS permet une bonne gestion et une mise à jour rapide et consistante. L'utilisation d'un langage adapté de règles facilite leur lecture et leur mise à jour notamment par des non développeurs Limites du SOA Comme toute autres technologies, adapter une architecture SOA à un coût à payer. Il s'agit de la maintenance et l'évolution des services et surtout la revalidation de services à chaque changement. Jusqu'à présent nous avons examiné l'approche SOA, mais la question est de savoir si le SOA répond à la nature événementielle de notre monde. La réponse est non, car le SOA suit le modèle request/reply qui nécessite l'interrogation pour avoir une réponse. Un exemple d'un cas ou le SOA ne peut pas répondre au besoin est celui du contrôle du fraude par une banque. Cette dernière n'attend pas que le client demande à chaque fois qu'il y est contrôle pour détecter la fraude, mais plutôt de le détécter dès son apparition. L'autre obstacle de l'approche SOA est la diculté de représenter le tout sous forme de services indépendants [AW09]. 1.5 EDA SOA 2.0 L'architecture SOA est très ecace quand le traitement ou la séquence des services est connue au préalable. Cependant, dans le traitement événementiel où les processus sont asynchrones le modèle Request/Reply ne semble pas susant. On n'attend pas qu'un service scrute les autres services pour chercher si un événement a eu lieu. A titre d'exemple la détection du fraude. Pour palier à ce problème une architecture basée sur l'événement est nécessaire. Oracle a introduit le terme SOA 2.0 pour designer une architecture avancées qui inclut le traitement d'événements. Ce terme était critiqué par les experts qui ont accusé Oracle de créer la confusion par SOA 2.0 et ont décidé que SOA 2.0 n'était en fait qu'un terme de marketing utilisé pour désigner l'approche EDA. 19

21 Avant de dénir EDA il convient de dénir ce qu'est un événement L'événement Dénition du dictionnaire : L'occurrence d'un important incident, spécialement celui qui est le plus signicatif intéressant ou inhabituel [Luc08]. Dans le contexte de l'entreprise : L'événement reète le changement d'un état d'un objet. L'événement a un temps et un lieu. L'événement peut ne pas représenter des données. Exemples : Une transaction d'un client a échoué. Le schéma d'une base de données a changé. Un composant réseau est en défaillance. Une tempête a frappé la ville X. Un pattern d'une transaction de fraude est détecté. Une machine serveurs a été éteinte. On peut classer les événements dans une entreprise selon des catégories : Les événements physiques la source électrique est disparue. la température a dépassé 40 degré. Les événements liés aux transactions un nouveau client a été ajouté Les événements d'agrégation la moyenne de production a baissé de 20% dans les 48 heures. Les événements relationnels le taux d'accident à Bruxelles a augmenté de 25% et le taux de contrat d'assurance a baissé de 30%. Les événements complexes c'est la combinaison des événements précédents dans un événement complexe Dénition EDA EDA Event Driven Architechture est le successeur du SOA. Le paradigme est basé sur l'idée du tout est événement, du moment où le monde se divise en consommateur et producteur d'événements. Pour comprendre la diérence entre EDA et SOA il faut examiner leur unité de commande. La requête dans SOA et l'événement dans EDA. Dans la traditionnelle SOA le consommateur du service envoie une requête vers le producteur, la réponse du producteur 20

22 contient soit le résultat soit un feedback. A titre d'exemple une action accomplie ou bien autorisée. La requête est souvent formulée à l'impératif : " mets à jour " ou " calcule". Dans EDA le schéma de la communication entre le consommateur et le producteur est inversé. Les consommateurs ne débutent pas la communication, mais ils reçoivent les événements publiés par les producteurs. La communication est alors unidirectionnel le producteur n'a pas besoin d'une requête pour continuer son travail [Dah09].Les événements sont formulés dans la forme passive à titre d'exemple, "client ajouté", "commande annulée " et ils dénissent 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 événements qu'il émette. Et aussi de réagir en temps réel à l'évolution de ce monde Intérêt du EDA L'intérêt du EDA est de compléter le SOA pour arriver à un découplage des services,appelés par EDA des agents, et de gérer d'une manière ecace les processus temps réel et asynchrones. Ceci optimise le parallélisme dans les processus. Par conséquent le traitement par événement permet de gérer un volume important d'informations variées. L'EDA augmente le découplage par rapport au SOA puisque dans ce dernier les services partagent des interfaces pour appeler les fonctions. En EDA le producteur et le consommateur ne se connaissent pas, un producteur publie son événement qui peut être consommé par diérents consommateurs et chacun d'entre eux eectue un traitement diérent.[aw09]. Cette communication par événement augmente l'agilité du système en lui permettant de réagir en temps réel aux changements autour de lui, à titre d'exemple les changements du marché boursier : dans ce cas chaque changement des valeurs boursiers est signalé par un événement, cette agilité est obtenue grâce au traitement des événements en temps réel, Un autre intérêt consiste à permettre l'introduction d'un niveau plus haut de traitement en utilisant le moteur CEP. Ce dernier permet de corréler un grand volume d'informations qui arrivent dans une période de temps limité an d'en extraire en temps réel d'autres informations plus utiles, nous allons voir ce composant plus en détails dans les chapitres suivants. 21

23 1.5.5 Fonctionnement EDA L'architecture EDA est basée sur le PUB/SUB 12 qui signie publier et s'abonner. Dans le PUB/SUB l'émetteur publie chaque message dans un sujet. Au lieu d'envoyer à un destinataire précis, le système de messagerie envoie le message ou l'événement à tous les consommateurs déjà inscrits à ce sujet. Ce mode est plus scalable que le mode point à point, ceci grâce à la nature stateless des agents consommateurs d'événements. Ce mode encourage également le découplage puisque souvent le producteur ne sait même pas qui sont les consommateurs de son événement, contrairement au principe request/reply utilisé dans WS-SOA les services ne doivent pas échanger le chier WSDL [Dah09] Composants du EDA Event Tooling : est le composant qui permet la dénition des événements et la gestion de l'inscription aux ux d'événements. Il ore également la possibilité d'administrer l'infrastructure des événements et la gestion des ux des événements et de leur visualisation ainsi que la génération des statistiques sur le traitement de ces ux. Enterprise Integration : ce composant joue un rôle essentiel dans l'architecture EDA, il comprend le pré-traitement des événements comme (le ltrage, le routages, la transformation). [Mic06] Ces deux derniers composants sont des entités logiques, elle peuvent être implémenté dans un seul composant appeler collecteur d'événements. [Mic06] Sources and Targets :ce sont les agents qui consomment et produisent les événements. Ils peuvent être des systèmes d'entreprise, des services appartenant aux processus métier, des bases de données ou des composants du réseau. CEP : 13 : est le c ur composant du EDA il est utilisé dans l'extraction des nouvelles informations. Le CEP analyse un grand nombre d'événements qui se produisent durant une période de temps an de les corréler et déduire d'autres informations utiles pour l'entreprise. Les CEP peuvent aussi être utilisés au-dessus de SOA -si on rajoute aux services la possibilité d'émettre des événements-. Cela permet de réaliser une analyse du processus métier en temps réel. [Mic06]Fig Publish and Subscribe 13. Complex Event Processing 22

24 1.6 Conclusion Figure 1.4 Architecture EDA L'EDA est une extension du SOA, le besoin de passer d'une architecture basée sur les services vers une architecture basée sur les événements dépend de la nature des informations qui circulent dans l'entreprise et du type de traitement de ces informations. Quand le temps et le volume sont de grands enjeux pour l'entreprise, l'utilisation de l'eda semble la plus adaptée. Quand le business est basé sur un traitement séquentiel une architecture SOA répond alors à ce besoin. Utiliser en plus un BRE permet de gérer la logique du métier d'une manière exible. D'autre part l'eda facilite l'intégration du CEP qui permet d'extraire d'un ux important d'événements, les informations qui permettent d'adapter les stratégies du business. 23

25 Chapitre 2 Les moteurs d'inférence BRE Sommaire 2.1 Historique Dénition des Business Rules Engine Dénition des règles Intérêt de BRE BRE et SOA Architecture BRE La base des règles Le moteur d'inférence Le chainage avant Le chainage arrière RETE Caractéristiques des BRE Performance Déterminisme Standardisation Produits BRE Conclusion Historique Les BRE 1 peuvent être vus comme les successeurs des Systèmes Experts (ES). Ces derniers sont apparus dans les années 80 alors que les BRE ont vu le jour dans les années 90. Les systèmes experts sont des systèmes fermés 1. Business Rules Engine 24

26 qui n'interagissent pas avec le réseau, ils étaient construits pour des tâches spéciques, contrairement aux BRE qui sont connectés et génériques. Les systèmes experts sont développés pour une expérience utilisateur, alors que les BRE sont plus adaptés pour l'automatisation de la décision. Par ailleurs, les diérents mécanismes d'inférences ont subi des améliorations ce qui rend les BRE plus ecaces que les SE. Dans les années 2000, les BRE ont à leur tour connu une évolution pour devenir BRMS enrichis avec d'autres fonctionnalités pour la gestion et le maintien des règles. La fonction du BRE se limite à l'exécution des règles et il ne permet pas leurs gestions. 2.2 Dénition des Business Rules Engine Un BRE (ou moteur de règles d'inférence) est une application dont le rôle consiste à eectuer des liaisons entre des données, des faits et des règles métier. Le BRE exécute une ou plusieurs règles selon les données qu'il reçoit. Ces règles peuvent être des règles législatives de l'entreprise ("un employé recruté doit avoir une certaine expérience "), ou bien des stratégies de l'entreprise (un client "gold" est un client qui fait plus de 1000 euro d'achat). Étant seulement le moteur d'inférence le BRE n'ore pas la gestion des règles métier, par conséquent, il est intégré à un BRMS Business Rules Management System. Parmi les fonctionnalités qui se rajoutent au BRE pour donner un BRMS nous citant : l'enregistrement des nouvelles règles métier, la vérication de la consistance des règles et la dénition des relations entre ces derniers. [Chi07]] La base de fonctionnement des BRE est l'application d'un ensemble de règles si/alors. L'objectif est de séparer les règles business fréquemment modiées du reste du code. Ces règles seront stockées sous une forme compréhensible, ce qui facilite leur maintient et évite aux développeurs d'aller les chercher dans les codes source à chaque modication et éventuellement refaire les tests. A titre d'exemple, le calcul de la valeur de réduction qu'une entreprise ore à ses clients est une règle métier, elle peut être mise dans un code du système sous cette forme : if (product.quantity > 100) product.price=product.price-50 L'utilisation du BRE remplace le code précèdent par un appel au moteur d'inférence avec comme entrée, l'identicateur du produit : ruleengine.applyrules(product) La règle est écrite séparément comme suit : Rule Discount When $P :Product(quantity>100) Then P.price =p.price-50 End De cette façon nous avons séparé le calcul de réduction du reste du code, 25

27 cela permet de changer le taux de réduction appliqué sans aecter le reste du système. Bien que cet exemple semble simple, mais il illustre l'avantage de l'utilisation des BRE [Dor05] Avant de continuer il convient de donner une dénition à la règle business. 2.3 Dénition des règles Ce sont des décisions qui dénissent où gèrent une partie du business. Elles contrôlent et inuencent son comportement. Le BRE évalue et exécute ces règles Et chaque règle est exprimée sous forme de si/alors. Elle est composée de deux parties, la condition et l'action : quand la condition est rencontrée, l'action est exécutée. La partie "SI" comporte la ou les conditions exemple (code-produit=100), la deuxième partie comporte l'action (exemple applique une réduction de 5%). Les règles business permettent de : Automatiser une décision (exemple : ce client est un client gold) Lancer une action (exemple : envoyer un mail au manager pour signaler que le stock est vide) Il existe plusieurs guides pour élaborer des règles métier, voici celles données par la société Business Rules Solutions : Atomicité : une règle métier ne peut être divisée sous peine de perte de valeur sémantique Réutilisation : une règle métier n'est pas spécique à une application, mais peut être partagée par plusieurs applications Business : on parle des règles métier qui sont donc destinées à des experts métier. Ce sont donc ces derniers qui doivent les gérer et pour cela, un mode de représentation non technique est requis. Déclarative : par opposition à procédurale, les règles sont présentées de manière déclarative et non sous forme d'une succession de conditions imbriquées les unes dans les autres. 2.4 Intérêt de BRE L'intérêt principal des BRE est de faciliter la mise à jour des règles business et de décrire ces règles dans un langage plus compréhensible. L'utilisation des BRE ore également certains autres avantages : Granularité. L'utilisation des BRE comme des composants augmente la granularité, facilite la maintenance et rend le système plus exible, 26

28 contrairement ou BP 2 qui ne change pas souvent. Synchronisme. Contrairement à la lenteur du BP, le BRE permet de traiter les règle plus rapidement ce qui augmente la possibilité du traitement asynchrone. Statefulness. Les BRE sont développés pour traiter les données en input et d'exécuter les règles ainsi que de changer la base des faits qui décrivent l'état du système ce qui garde un état actuel du système dans cette base. [Fer05] D'autre part L'utilisation des BRMS répond aux questions suivantes : Où peut- on -trouver les règles business? Comment tester ces règles business? Comment réutiliser les règles déjà existantes Comment simuler les règles? [Tib07] 2.5 BRE et SOA Dans une architecture SOA le BRE est déployé comme un service de décision séparé. Ce service accède aux diérentes ressources de l'entreprise et aux autres services par la même infrastructure SOA, il propose des interfaces accessibles aux autres services. Ces derniers remplacent les codes où des règles ont été implémentées par des appels au service de décision qui exécute les actions correspondants aux données entrées Fig Architecture BRE Le nombre des composants d'un BRE dière selon les vendeurs, mais il existe des composants de base qui sont essentiels à son fonctionnement à savoir la base des règles et le moteur d'inférence. Au-dessus de ces deux composants se rajoute souvent le Rules Management Application, qui représente l'interface utilisateur que les experts et développeurs utilisent pour créer et modier les règles La base des règles La base des réglés ou bien le Rules Repository est la collection de règles métier qui peut être modiées à tout moment en utilisant le Rules application management : la base des réglés contient aussi des méta-données qui 2. Busness Process 27

29 Figure 2.1 BRE & SOA dénissent les entités, les attributs et les relations dans les bases de données existantes. Il existe diérentes implémentations du Rules Repository. Ils peuvent être implémentés avec un code similaire à celui utilisé par les applications. Ce code sera appelé à chaque fois par le moteur d'inférence, toutefois, les règles métier étant destinées aux experts métier, la modélisation est un aspect important et doit être accessible à des non développeur. Le langage déclaratif : est un format proche des spécications papier qui permet de facilité la dénition des règles en utilisant un vocabulaire business, avec un éditeur intelligent pour la rédaction des règles. La maintenance sera donc facile, mais de nombreuses incohérences peuvent être générées. Deux standards diérents sont utilisés pour le format de la représentation de règles : PRR (OMG) 3 association américaine de standardisation et RIF (W3C) 4 organisme de standardisation. Par contre, diérents vendeurs de BRE n'exploitent pas les standards existants, mais ils créent un format de représentation de règles spécique à leur solution. La conséquence est une mauvaise interopérabilité entre les diérentes solutions existantes.[mah09] 3. Object Management Group 4. World Wide Web Consortium 28

30 Figure 2.2 Architecture BRE Le moteur d'inférence L'objectif d'un moteur d'inférence est de déterminer quelles sont les règles qui peuvent être appliquées. Un ensemble de faits est injecté dans ce qu'on appel un espace de travail. Ou Working Memory sur la base de ces faits Le BRE produit des règles applicables qu'on appel agenda. Suivant diérents critères, une règle de l'agenda est retenue. Cette étape est appelée résolution du conit. La règle retenue est exécutée ce qui engendre la création de nouveaux faits.. Le moteur d'inférence prend en entrée un ensemble de règles appelée le Rules set Collection les autres entrées sont les objets représentants les données. Le mécanisme de production des faits sur base de règles et d'autres faits est appelé inférence. Il existe trois mécanismes l'inférence : le chaînage avant Le chaînage arrière et L'algorithme RETE Le chainage avant Le chaînage avant est le mécanisme le plus utilisé et le plus évident de l'inférence ainsi il est le mécanisme par défaut de beaucoup de moteurs. Dans ce type d'inférence le moteur scrute toutes les règles à la recherche d'une règle qui possède une partie " SI" qui correspond aux faits, dès qu'une 29

31 règle est trouvée elle sera exécutée et les nouveaux résultats seront rajoutés à la base des faits. La procédure se répète périodiquement jusqu'à ce qu'il ne reste aucune règle qui correspond, évidemment certaines stratégies sont appliquées an d'éviter que les règles s'appliquent plusieurs fois ou l'apparition des boucles Le chainage arrière Contrairement au chaînage avant le chaînage arrière part de l'action vers la condition. Il consiste à chercher la partie Alors de la règle qui est considérée comme le but. La partie condition ou à la partie "SI" sera examinée pour tester si la condition est vériée, si c'est le cas la règle est ajoutée à l'agenda. Dans le cas contraire les littéraux qui ne match pas dans la partie "SI" seront considérés comme de nouveaux but à rechercher et ainsi le processus continue jusqu'à ce que tous les littéraux match les faits ou bien il ne reste plus de règles RETE RETE est un algorithme de recherche des patterns qui augmente son ecacité en sacriant de l'espace. Dans RETE les règles sont décrites sous forme de réseau de n uds. Les faits ou les entées passent par ce réseau et subissent des tests à chaque n ud. Si ces faits arrivent à une feuille du réseau RETE, la règle correspondante est ajoutée à l'agenda. Le réseau RETE est formé de 5 types de n uds : la racine, les n uds Type, les n uds alpha, les n uds bêta et les n uds feuille. Le n ud racine est le point d'entrée de tous les faits il re-copie chaque fait vers toutes ses feuilles qui sont les n uds type. Chacun de ces derniers envoie les faits qui correspondent à son type vers ses n uds alpha Fig2.3. Les n uds alpha représentent les littéraux de la partie condition d'une règle. Si ce littéral match les faits il les envoie au n ud alpha suivant. An d'eectuer des opérations de jointure, multiples n uds bêta sont utilisés. Ces derniers reçoivent comme entrée plusieurs faits et copient en sortant le résultat de l'opération, ainsi la partie condition de la règle est vériée progressivement, si un fait arrive à une feuille alors la condition est satisfaite. Ceci engendre l'ajout de la règle correspondante à l'agenda. La résolution du conit détermine l'ordre dans lequel les règles sont appliquées [Ber02] [Sto]. 30

32 Figure 2.3 Réseau RETE 31

33 2.7 Caractéristiques des BRE Performance La performance du BRE dépend surtout de la structure des règles utilisées. Des règles qui ne respectent pas une bonne granularité vont conduire à un workfow qui est géré dans le BRE. Pour cela il faut respecter la granularité des règles, autrement dit créer des règles les plus courtes possible. En respectant ce principe les moteurs d'inférence basés sur RETE reste très performants Déterminisme Il est important pour un BRE de comprendre quelle est la stratégie de priorité adoptée, sinon nous allons avoir des règles qui s'exécutent dans un mauvais ordre et cela peut aecter leur fonctionnement. Si une règle qui dépend d'une autre s'exécute en retard nous allons avoir de faux résultats. L'une des stratégies pour résoudre ce problème est de dénir la priorité selon l'action que la règle eectue Standardisation L'existence de standard est un point important qui permet à des clients de changer facilement le produit, par exemple, changer le BRE et garder le même Rules Repository ou bien représenter la base des faits par une syntaxe XML. Ceci limite le risque d'investissement pour le client. Une API Application Programming Interface qui permet l'accès au BRE depuis un client JAVA a été spécié dans le JSR94 Java Specication Request for a Java Rules Engine API. Cette spécication dénie les fonctions de base qui sont : ajouter un objet au BRE, exécute une règle et récupère le résultat [Jbo09] Produits BRE Il existe diérentes solutions qui respectent la spécication JSR94 parmi lesquelles nous citons : Produit Open source Jboss busniss Drools oui Oracle busness rule non ILOG JRules oui Jess oui 32

34 2.8 Conclusion Un BRE est un outil qui permet l'adaptation de la stratégie de l'entreprise de manière exible. Toutefois si on utilise un BRE dans une architecture SOA, nous devons savoir à quel moment on exécute les règles, à titre d'exemple invoquer le moteur d'inférence par le BPM le ESB ou bien les WS, par contre dans une architecture orientée évènement le traitement est asynchrone, ainsi l'exécution d'une règle peut être à n'importe quel moment dès qu'un évènement apparaîtra. Pour répondre aux exigences du monde événementielle il existe un autre type de moteurs d'inférence nommé CEP. 33

35 Chapitre 3 Les moteurs d'inférence CEP Sommaire 3.1 Introduction Dénition CEP Motif d'événement Intérêt du CEP Cas d'utilisation Architecture CEP La collecte L'inférence Approche non RETE Approche RETE Diérence entre CEP et BRE Conclusion Introduction Avec l'avènement de l'eda et l'adoption du mode de communication asynchrone qui utilise des événements ou le mode publish/subscibe, les sources d'information se sont multipliées à travers : les contrôleurs RFID, les bases de données, les workow les services... etc. Les contraintes liées au temps de traitement et au volume de données deviennent ainsi variées. Passant d'applications de gestion à faible débit et sources d'événements limités aux applications de la supervision qui reçoivent des événements de diérentes sources et qui exigent un traitement en temps réel. La multiplicité des sources d'événements a rendu complexe la relation entre l'apparition de certains événements d'une part et le traitement associé d'autre part. Par 34

36 opposé au traitement simple où l'action est déterminée après analyse d'un événement indépendant, le traitement complexe nécessite la corrélation de plusieurs événements durant une période de temps plus au moins longue, ceci an de décider de la nature de l'action qui doit être prise. Ce dernier traitement se termine en général par la publication d'un nouveau événement [JSS09]. Les moteurs d'inférence CEP ont été créés pour répondre à ce type de contraintes d'analyse nous les trouvons comme composants responsables du traitement d'événements à un niveau plus haut dans l'architecture EDA. Ils sont donc le cerveau de cette architecture [RSuS09]. 3.2 Dénition CEP Le terme CEP signie le traitement complexe des événements. En d'autres termes ce type de traitement consiste à l'extraction de nouvelles informations non pas par l'analyse des événements simples et indépendants, mais par l'analyse d'un ensemble d'événements. Nous prenons comme exemple les transactions bancaires qui une fois traitées indépendamment peuvent être ordinaires et ne rien révéler, mais l'analyse d'un ensemble de transactions bancaires sur une période de temps peut révéler une tentative de fraude. Le principe de CEP est basé sur un moteur d'inférence qui reçoit des ux d'événements élémentaires, venant par diérentes voies et par volume important. Le traitement consiste à eectuer des corrélations entre ces différents ux an de détecter une séquence d'événements appelée motif. Dans l'exemple précédant le CEP analyse le ux de transactions à la recherche d'un motif de fraude. Les motifs sont dénis par des expressions de syntaxe proche de SQL et sont évalués continuellement par le CEP. Ceci fait la différence entre le traitement traditionnel dans lequel une simple requête est envoyée à une Base de données pour rendre le résultat, généralement après une première évaluation et l'utilisation d'un moteur CEP Fig 3.1. Dans ce dernier cas une évaluation continue des requêtes est faite sur des ux d'événements. Le résultat de la détection d'un motif conduit à l'exécution d'une action qui peut être soit un code à exécuter ou bien une simple notication. En règle générale l'action consiste à la publication d'un nouvel événement. Dans l'exemple précédant un événement de type fraude détecté est publié et de multiples applications peuvent ainsi s'inscrire à cet événement. Il est toujours dit que le CEP est l'opposé du traitement traditionnel : au lieu de stocker les données puis envoyer des requêtes nous stockons les requêtes puis nous envoyons des données. À titre d'exemple si on veut superviser le trac routier nous pouvons dénir un motif pour détecter 35

37 l'augmentation du débit (nombre voiture/minute). Nous pouvons dénir ce motif par une expression qui calcule la moyenne des voitures qui passent pendant une minute et qui notie un opérateur par une alarme, dès que le débit dépasse le seuil (150 voitures/minute). Les événements arrivent, dans ce cas, des puces RFID installées dans les voitures. Dès qu'elle passe, un récepteur déclanche un événement et l'envoie au moteur CEP. L'expression est la suivante Select *, sum(rfidevent) as débit From RFIDEvent(itemName='Véhicule').win :time(60 seconds) Where debit 150 Deux dés existent dans le monde des CEP. Le premier est de pouvoir représenter la situation ou le motif qu'en veut détecter. Cela nécessite l'utilisation d'un langage qui supporte des opérations complexes telles que la jointure, l'agrégation et le ltrage temporel. L'autre dé et de pouvoir supporter la charge d'événements et détecter les motifs tout en respectant les contraintes temporelles. Autrement dit l'algorithme de détection Matching doit être ecace et scalable. Le temps de réponse nécessaire pour trouver le motif qui correspond aux événements ne diverge pas. La scalabilité est évaluée en terme de volume d'événements et en terme de nombre de motifs L'une des utilisations courantes des moteurs CEP est la supervision des réseaux de télé-communication où diérents composants envoient des rapports de leurs états sous forme d'événements. Le moteur CEP en analysant ces événements pourra détecter si un composant est en panne ou bien risque de l'être, ce qui donne au CEP la possibilité de prédire une situation. L'une des utilisations courantes des moteurs CEP est la supervision des réseaux de télé-communication où diérents composants envoient des rapports de leurs états sous forme d'événements. Le moteur CEP en analysant ces événements peut détecter si un composant est en panne ou bien risque de l'être, ce qui donne au CEP la possibilité de prédire une situation. Autre exemple est le système de livraison. Si le CEP supervise des camions de livraison en analysant des événements reçus de leurs puces RFID, précisant leurs positions et leurs temps d'arrivée combinées à des événements venant d'autres ux comme la situation du trac routier. Le CEP pourra ainsi prédire un retard de livraison. Le CEP peut aussi détecter des situations n'en pas par la présence, mais par l'absence d'un événement. Par exemple dans la supervision de la livraison l'absence d'événements venant d'un camion peut révéler une panne. Il existe d'autres domaines où le CEP peut rajouter une agilité et doter le système d'un autre niveau d'intelligence comme dans cet article où le CEP est appliqué dans les ICU pour contrôler l'état des patients 36

38 [TIB09] [Hyd09a]. Figure 3.1 Traitement complexe des événements 3.3 Motif d'événement Le but des motifs est de pouvoir modéliser une situation. Plus précisément modéliser une séquence d'événements parmi tous les événements qui se produisent. Bien que les motifs peuvent être exprimés en utilisant le langage SQL muni de l'extension STREAM, l'expression reste toujours lourde et complexe et les contraintes de temps ne peuvent pas être respectées. Par conséquent le traitement se fait par des moteurs d'inférence optimisés par temps réel et en utilisant un langage déclaratif qui exprime directement les opérations complexes, telle que la jointure temporelle et des opérateurs exprimant la relation entre événement tel que (A se produit pendant B). Comme exemple simple d'un motif : imaginons un systéme de contrôle de transport de bagages dans un aéroport où chaque bagage est doté d'une puce RFID. Le bagage est transporté sur un tapis roulant muni de récepteurs qui signalent le passage du bagage à chaque point : si on dénie l'événement Ai par le passage du bagage A par le récepteur i nous pouvons écrire ce motif 37

39 A3 after A2 after A1 Than E Où E signal l'arrivée du bagage Cet exemple simple dénit un motif E Le moteur CEP reçoit tous les événements du système dès qu'il détecte le passage du bagage A par les trois premiers récepteurs il pourra déjà signaler que le bagage est bien arrivé à sa destination. Bien que tous les motifs soient complexes, ils varient de complexité du moins complexe au plus complexe comme l'indique l'exemple suivant : A3 après (non A2 pendant 10 minutes) après A1 alors D Dans cet exemple le bagage A n'a pas été signalé par le récepteur A2 pendant plus de 10 minutes ce qui peut révéler une situation douteuse le CEP le signale par un avènement D [CJ09]. 3.4 Intérêt du CEP Les grandes entreprises reçoivent des événements de l'ordre de 10 4 ou 10 7 [ref] événements par seconde par exemple réservation de vol, retrait d'argent, Web commerce)analyser et traiter ce volume d'informations dépasse largement les capacités de n'importe quel système traditionnel. Pour cette raison le CEP vient pour résoudre ce type de problème. Autrement dit le premier intérêt du CEP apparaît lorsque l'entreprise génère un grand volume d'informations venant de sources diérentes. Nous avons trouvé déjà une utilisation des CEP où l'application reçoit 4000 événements/heure [Gar09b]. Comme nous l'avons déjà cité dans la dénition le CEP permet l'extraction de nouvelles connaissances à partir de simples événements ce qui augmente l'agilité du système. À titre d'exemple nous trouvons le CEP comme moyen de supervision, en étant à l'écoute de tout ce qui se passe dans le système, il pourra révéler une situation critique ou une opportunité au moment adéquat. Cette agilité lui permet d'être le cerveau dans une architecture de type EDA. Le CEP est alors une clé pour créer un système exible capable de réagir selon son contexte. Pour que cet intérêt apparaît il faut que Comme son nom l'indique- le traitement soit complexe Autrement dit les motifs doivent être complexes et en nombres importants : quelques motifs simples 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

40 lisations pratiques et familières peuvent être énumérés comme suit : détection des épidémies : diérents événements sont analysés tels que le nombre de patients et les symptômes. Ces informations sont corrélées avec d'autres données externes an de détecter des épidémies. La détection des fraudes : ceci est l'une des plus courante utilisation, elle consiste à analyser les diérentes transactions en corrélant diérents événements venant des ATM ou des cartes de crédit an de détecter la possibilité de fraude notons que : une seule transaction ne permet pas de détecter un fraude, au contraire la transaction peut paraître valide et ordinaire, mais l'analyse d'un ensemble de transactions permet de détecter une situation suspecte. La détection d'intrusion : c'est l'application classique des CEP, dans ce cas le CEP reçoit les événements venants du système et détecte les tentatives d'intrusion telles que les requêtes d'authentication venant de diérentes sources sur une période de temps, en d'autres termes passer d'une sécurité de niveau basique à une sécurité intelligente où les tentatives d'intrusion les plus malignes peuvent être divulgués. Dans les entreprises Une société utilise CEP pour traiter les événements dans sa chaîne d'approvisionnement an de vérier ceux qui ont été importants et d'informer les utilisateurs de cette problématique en fonction des règles dénies par l'utilisateur. Une société de logistique utilise CEP pour suivre et contrôler automatiquement les livraisons. Le CEP alerte en cas de problèmes de chargement. Le CEP propose également des voies alternatives ou des résolutions possibles aux problèmes. Une entreprise de télécommunications intègre CEP dans ses n uds de réseau pour gérer les événements et les alertes dans le réseau, recongurer et modier le router en réponse à des problèmes Une autre entreprise de télécommunications utilise CEP pour gérer les accords au niveau de service et pour répondre à des événements et des alertes venant de routage du trac en les orientant vers des équipements basés sur SLA. Ce CEP identie aussi les accords qui ne peuvent pas satisfaire le niveau de service par la notication En trouve d'autres applications dans la gestion du stock avec l'introduction de la technologie RFID. Plusieurs cas d'utilisation existent notamment avec l'adoption de plus en plus d'architecture EDA au sein des organismes [Hag09]. 39

41 3.6 Architecture CEP An de mettre en place une plateforme CEP nous avons d'abord besoin d'une plateforme d'événements. Une architecture EDA facilite grandement la mise en place des CEP. Dans le cas contraire des adaptateurs doivent être développés pour permettre à diérents composants tels que les bases de données des processus, de générer des événements. Une plateforme CEP est composée de deux niveaux fonctionnels, la collecte et l'inférence Fig 3.2. Figure 3.2 Architecture CEP La collecte Ce niveau enveloppe la collecte des événements, le formatage et la normalisation an de l'adapter au contexte CEP. A ce niveau le CEP est en 40

42 contact avec la source d'événements qui peut être : Des équipements physiques : des hub, des détecteurs,rfid.... Etc ; Des bases de données qui génèrent des événements lors de la modication 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 événements reçus seront transformés en un format compréhensible par le moteur d'inférence. La transformation consiste à extraire les informations et les présenter sous le nouveau format. Ce format dépend du moteur CEP choisi, il peut être XML à travers des schémas XSLT ou POJO objet ou autre L'inférence Nous trouvons ici le prétraitement et le matching. Le pré-traitement consiste à appliquer des ltres d'événements et les raner en rajoutant d'autres informations dans leurs entêtes ou dans le payload le responsable du pré-traitement s'appelle EPA Events Preprocessing Agent. Le matching est le c ur composant de la plateforme CEP c'est le moteur d'inférence qui permet de détecter les motifs applicables aux ux d'événements. Nous appelons l'algorithme utilisé par le moteur d'inférence l'algorithme du matching. Comme nous l'avons décrit dans la section précédente l'analyse CEP est en temps réel et traite un grand volume d'événements donc le but ultime est le matching rapide de motifs sachant que les algorithmes correspondants traditionnels (backword chain) ne parviennent pas à atteindre cet objectif en particulier lorsque le volume dépasse le million d'événements [Gar09a] Approche non RETE Les approches actuelles des moteurs d'inférence CEP ne se basent pas sur RETE, elles sont des extensions des moteurs relationnels qui permettent de gérer les contraintes temporelles et des extensions au langage SQL pour permettre l'interrogation de tels moteurs. Nous trouvons entre autres deux célèbres moteurs : StreamCruncher est un moteur qui s'appuie sur une base de données relationnelles pour gérer le CEP [Sit09] Esper, est un CEP connu et qui semble mettre en uvre son propre moteur relationnel, mais le langage utilisé est aussi une extension du langage SQL. [Pag10] 41

43 Dans le domaine propriétaire beaucoup d'entreprises telles que StreamBase, ont opté pour la promotion de leurs propres algorithmes spécialisés. Ces moteurs sont basés autour d'un SQL étendu, appelé "Streaming SQL"qui détecte les motifs dans les ux. Ces moteurs sont basés sur la même technologie que les bases de données relationnelles, mais sont conçus pour traiter des données en temps réel. Ils introduisent une dimension de temps dans le modèle relationnel. On peut toujours appliquer les opérateurs de base (sélection, projection etc.), mais on peut également demander à titre d'exemple l'exécution de requêtes basées sur les données qui appartiennent à un intervalle de temps[hyd09b] Approche RETE L'algorithme le plus dominant qui est en mesure de réaliser la scalabilité est l'algorithme RETE. Dans sa version trois RETE ore une performance très élevée qui peut supporter la charge en terme de volume d'événements, en terme de nombre de motifs ainsi qu'en terme de complexité des motifs. Drools est un exemple des solutions qui ont adopté RETE amélioré pour orir une meilleure performance et pour permettre le traitement d'événements[doo] [KUSS09]. 3.7 Diérence entre CEP et BRE La question fréquemment posée et qui concerne les deux types de moteurs d'inférence existants (BRE et CEP) est la suivante : quelle est la diérence entre un moteur d'inférence de règles métiers (ou BRE) et un moteur d'inférence de type CEP (Complex Event Processing Engine)?. Ceci est particulièrement intéressant, car un moteur basé sur des règles peut être vue comme un CEP. Les événements dans ce cas sont représentés par les faits, les motifs peuvent être vus comme des règles si/alors où la partie condition de la règle n'est rien d'autre que le motif, la partie action consiste à la publication du motif détecté. Si (Motif A) alors publier événements A Bien que le traitement d'événements peut être exprimé dans le style règle, il existe des diérences entre le traitement des événements et des règles, ces diérences sont liées au contexte et aux exigences de chacun d'eux. Nous citons les principaux points de distinction sous forme de tableau [Vin07] [Etz09] : 42

44 Diérence BRE CEP Les entrées Des faits typiquement du genre relations entre entités comme BOB est le chef d'alice et des valeurs d'attributs comme le salaire d'alice=x Les sorties Temps Maintien d'état Stateless/stateful Contraint temps réel D'autres faits inférer des faits d'entrée. Des calcules dérivés des faits tels que la moyenne. Des actions telles qu'un code à exécuter Traitement des faits sans avoir la notion de temps ce qui veut dire considérer l'état actuel du système néanmoins possibilité de traitement temporel simple Principalement dédier à la Prise de décision selon des faits actuels le maintien d'état pour une longue période n'est pas nécessaire Moins d'exigences en termes de rapidité Langage Des expressions si/alors avec des opérateurs proches SQL (select, group by... Scalabilité Intégration Exige une Scalabilité moyenne en termes de nombre de règles Une architecture SOA est un environnement idéal 43 Des événements typiquement armatifs tels que : BOB est promu et qui possèdent un temps d'arrivée et d'expiration Publication de l'événement qui décrit le motif Traitement essentiellement temporel avec la prise en charge de la notion du temps. Possibilité de limiter le traitement dans des intervalles de temp. Fort support des opérateurs temporels (A avant B, C après D...) Un traitement qui dure pendant une période de temps le maintien d'état est nécessaire donc faire appel à des mécanismes de sauvegardes Nécessite un traitement en temps réel et un algorithme ecace Des opérateurs temporels plus complexes du type de (avant, après, pendant... ) Les CEP traitent des ux d'événements importants ce qui demande une scalabilité en terme de nombre d'événements et en termes de nombre de patterns Nécessite une plateforme de génération d'événements tels qu'une architecture EDA

45 3.8 Conclusion Aucun des points précédents n'exclut l'utilisation d'un BRE standard dans les applications CEP. Mais ce qui précède est une indication quant aux extensions qui doivent être ajoutés à un BRE standard pour en faire un moteur CEP., En eet, certains vendeurs BRE le font déjà. A titre d'exemple Drools a étendu son BRE pour inclure la totalité des fonctionnalités CEP avec le module CEP appelé Drools Fusion. Drools a appliqué des extensions à son langage déclaratif et son algorithme an de rencontrer les exigences du traitement complexe des événements. 44

46 Chapitre 4 JSLEE Sommaire 4.1 Introduction Historique Dénition JSLEE Version JSLEE Architecture JSLEE Composants JSLEE Les Service Building Blocks Framework Contrôle et Administration Ressource Adaptors Architecture d'application SLEE Déploiement des services Utilisation JSLEE Implémentations de JSLEE JSLEE mobicents Introduction Caractéristiques JSLEE Mobicents Ressource adaptor Conclusion Introduction La notion de serveur d'application est un concept bien connu dans le monde de développement. Un SA permet le développement rapide d'appli- 45

47 cations. Il assure également de grandes performances. En orant un Framework de travail, il facilite et accélère la création et le déploiement des applications. J2EE AS est le leader mondial des serveurs d'applications. Cette dernière technologie est fortement utilisée dans le domaine des IT son avantage consiste à accroître la productivité et réduire l'eort des développeurs dans la résolution du c ur des problèmes. Pour arriver à ce résultat des entités programmables seront utilisées pour bâtir la solution. L'équivalent de J2EE dans le monde des Télécommunications et des applications ayant des contraintes temps réel s'appelle JSLEE. Dans ce chapitre nous présentons le serveur d'application JSLEE, nous donnons son architecture ses composants ainsi que son principe de fonctionnement. 4.2 Historique En 1998, SUN introduit la plate-forme JAVA au monde de l'industrie des fournisseurs de services en créant la communauté JAIN. Cette communauté comprend environ 80 entreprises (fournisseurs de matériels, d'équipements réseaux, de protocoles et des développeurs de services). JAIN est contrôlé par SUN, qui assure la qualité des APIs, leurs homogénéités et leurs compatibilités. JAIN est un ensemble d'api qui permet un développement rapide de nouveaux services pour des réseaux de télécommunication voix ou données. L'utilisation de JAIN rend le développeur de services indépendant du matériel 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 Dénition JSLEE SLEE 1 désigne une architecture modulaire des applications orientées Télécommunication, basé sur la communication en mode événement, il spécie également la relation entre les diérents modules d'application. La création de cette architecture principalement dédiée aux applications télécoms est due aux exigences de ce type d'application, nous citons à titre d'exemple la connectivité où diérents protocoles sont utilisés, nous citons aussi les exigences temporelles qui font que le temps de traitement est limité et enn le besoin au maintient de charge ou la scalabilité. SLEE dénit également l'environnement dans lequel les applications s'exécutent et évoluent.[sl09] JS- 1. Service Logic Executing Environement 46

48 LEE est la spécication JAVA des serveurs SLEE, elle porte le nom JSR240, il dénit un ensemble d'api qui permet le développement des applications destinées au monde Télécom, il fournit également l'environnement de développement, l'architecture de l'application et la relation entre ses diérents composants. JSLEE permet au développeur de travailler à un niveau plus haut appelé service, sans se préoccuper des réseaux sous-jacents. Le but alors est de rapporter la portabilité aux applications SLEE en utilisant les API JAVA ainsi que la spécication technique. JSLEE ou JAIN SLEE est pour le monde des télécommunications ce que J2EE est pour le monde IT, ce qui lui donne un rôle important dans l'intégration des applications IT et Telecom et ouvre la porte à la création rapide de nouveaux services à valeur ajouté sur le réseau télécom. 4.4 Version JSLEE JSLEE est actuellement en sa version 1.1 celle-ci porte sur la standardisation de la connexion entre les ressources adaptors et SLEE elle révise certains concepts en rajoutant des fonctions et en détaillant ce qui était obscure dans la version 1.0. Cette version rajoute également certains concepts dont les librairies. Cependant, les applications fonctionnant dans la version 1.0 restent compatibles avec la version 1.1 [jai09c]. 4.5 Architecture JSLEE Étant une spécication JSLEE propose un ensemble d'entités fonctionnelles entre liées. L'architecture générale de JSLEE est formée de 4 parties Fig 4.1.Les SBB ce sont les entités qui détiennent le code programmable ou l'intelligence et qui vont coopérer an de fournir le service, les RA Ressource Adapter ce sont les entités qui permettent au JSLEE de communiquer avec le monde extérieur, ils sont constitués d'un ensemble d'api qui donne au SBB la possibilité de communiquer avec les ressources extérieures quel que soit leur nature. Le Framework c'est l'ensemble de fonctionnalités oert par JSLEE au développeur pour faciliter la création des SBB à titre d'exemple le TIMER, le routage d'événement...etc. le CM 2 c'est l'entité qui permet la gestion de l'exécution des services, elle gère la création et l'inscription d'événements. Elle ore également une console pour récolter des statistiques [jai09c][jai09b]. 2. Contrôle Module 47

49 Figure 4.1 Architecture SLEE 4.6 Composants JSLEE Les Service Building Blocks Ce sont les composants qui détiennent le code fonctionnel de l'application elles coopèrent pour fournir le service attendu à titre d'exemple un Service qui ore au client le lieu de restauration le plus proche peut être constitué 48

50 de deux SBB un SBB pour la localisation et un autre pour la recherche du restaurant. Les SBB se communiquent en échangeant des événements à titre d'exemple le SBB de localisation émettra un événement du type "client located "qui va être consommé par le SBB de recherche. Toutefois ; elles peuvent communiquer à travers des interfaces locales. Un SBB est formé d'une classe abstraite qui doit dénir la méthode appelée par JSLEE en cas de réception d'événement, pour chaque événement dont la SBB est liée il existe une telle méthode. Les événements qui seront envoyés à une SBB doivent être mentionnés par leur type dans la SBB ellemême. Dans l'exemple précédant c'est l'événement du type "Client request" qui est envoyé à la SBB de localisation, par conséquent la SBB de localisation doit explicitement s'inscrire à ce ux d'événement. Les SBBs sont organisés dans une architecture de parent ls. Chaque SBB doit mentionner explicitement ses ls ceci donne un graphe formé d'un SBB racine est des SBB ls. Ce graphe modélise le service oert par l'application. Dans l'exemple précédant le graphe est formé de deux SBBs Fig4.2. An de traiter un événement, JSLEE instance une SBB, cette instance est appelée SBB entité, la SBB instancié doit impérativement être un SBB racine d'un graphe qui modélise un service. La SBB racine instance ensuite le reste des SBB du graphe[jai09c] Framework JSLEE ore un certain nombre de fonctionnalités utilisables par les SBB telle que : Les proles JSLEE dénie la notion de prole an de sauvegarder les données provisionnées ces prols sont décrits par leur schéma sous forme d'attributs. Les prols sont sauvegardés dans des tables appelées tables de prols à titre d'exemple un prol de droit d'accès est utilisé dans le service précédent de recherche de restaurant. Name Phone number Bob Alice Cesar Activity context Ce concept peut être vue comme une session qui en capsule des attributs liées au ux d'événements les SBB doivent être rattachées à un AC 3 Ce concept peut être vue comme une session qui en-capsule des attributs liées au ux d'événements les SBB doivent être attachés à un AC Activity Context an de recevoir les événements. 3. Activity Context 49

51 Figure 4.2 graphe SBB C'est au SLEE d'attacher les SBBs au AC, quand un événement dit initial auquel elles sont liées apparaît et de la même manière de les détacher avant de supprimer le service. Toutefois, un SBB pourra changer son AC via des méthodes, an de recevoir des événements liés à d'autre AC. Les AC sont représentés dans JSLEE par un ACI activity context Interface. Activiity object Un AO 4 est un objet qui représente un ux d'événements, il ore un ensemble de méthodes qui permet de contrôler le ux d'évènements à titre d'exemple : dans le cas du service de recherche de restaurant un AO représente les requêtes des clients. Cet AO est liée à un AC et il est manipulable par l'adaptateur de ressources décrit par la suite. Autre Fonctionnalités :JSLEE ore d'autres fonctionnalités telles que le Timer, la recherche des services, la recherche d'événements...etc. Ces 4. Activity Object 50

52 fonctionnalités sont accessibles au SBB et au RA. JSLEE inclut la notion de librairie dans sa version 1.1 an de pouvoir remplacer l'utilisation des CLASSPATH. Une librairie est un ensemble de classes qui fournit des fonctionnalités aux composants de JSLEE (RA et SBB). L'utilisation des librairies permet de partager ces classes par diérents composants Contrôle et Administration JSLEE ore une console qui permet le contrôle de l'exécution des applications. An d'administrer les services. JSLEE spécie un ensemble d'opérations qui doivent être oertes par la console nous citons : Lancer / arrêter un service Installer ou désinstaller un service Créer des proles l et les modier Récolter des statistiques Ressource Adaptors le RA 5 Le RA Resource Adaptor est l'entité qui permet au SBB de dialoguer avec le monde extérieur. Le Resource Adaptor est considéré comme l'un des avantages de JSLEE, car il évite au développeur de se préoccuper de la communication externe, ce qui accélère le développement. Chaque type de Resource Adaptor est spécié par un organisme ou un groupe d'experts à travers des interfaces. Les développeurs des RA implémentent ces interfaces pour chaque produit JSLEE. A titre d'exemple un SIP Resource Adapter qui permet à des SBB d'utiliser la ressource SIP. Le Resource Adapter est formé d'un ensemble de classes qui incluent impérativement l'implémentation des interfaces du type de Resource Adaptor cible. L'une des fonctionnalités les plus importantes d'un Resource Adaptor est le transfert des événements au JSLEE an qu'il les achemine à la SBB concernée.[jai09c]. 4.7 Architecture d'application SLEE Une application destinée à JSLEE est formée d'un ensemble de SBB. Le développeur pro-cède à l'identication de l'ensemble des ressources auxquelles il aura besoin dans son appli-cation, à titre d'exemple des Resources Adaptor, d'autre SBB dans le JSLEE ou bien des Proles, ces ressources peuvent exister ou elles sont créés par le développeur. Il dessine ainsi le graphe de 5. Ressource Adaptor 51

53 son service qui déni l'ensemble des SBB et la relation entres elles. La spécication JSLEE exige que les SBB créés doivent être sous forme de classes abstraites. Le serveur JSLEE implémentera ces classes au moment de déploiement. Le développeur rajoute éventuellement un ensemble d'entités à titre d'exemple : Les Local Interface Object qui sont des classes abstraites dénissant un ensemble de méthodes permettant à une SBB d'être appeler par une autre SBB. Ces interfaces sont décrites dans le descripteur du SBB. 4.8 Déploiement des services An de déployer un service JSLEE propose l'utilisation des packages JAR. Ainsi un service est sous forme d'un chier JAR contenant obligatoirement le descripteur de service. Parmi les informations incluses dans le descripteur nous trouvons les diérents descripteurs des entités utilisées par le service notamment les SBB les Resources Adaptor les prols et les événements. Ce mécanisme facilite l'utilisation est le déploiement des services. Le contenu de package JAR est spécié de manière détaillée dans le JSLEE 1.1 [jai09c]. 4.9 Utilisation JSLEE JSLEE est très répondu, dans le monde de IMS beaucoup d'entreprises planie d'utiliser JSLEE comme plateforme des composants IMS par exemple le serveur d'application ou bien le CSCF. Grâce a ces standards JSLEE permet une exibilité de développement et de déploiement des services orientés communication Implémentations de JSLEE L'implémentation de JSLEE doit respecter les contraintes de performance liées au monde de télécommunication. Nous citons la faible latence à titre d'exemple le temps nécessaire pour établir un appel doit être < 500 ms Une deuxième contrainte est le haut débit qui désigne la possibilité de supporter des millions d'appel, l'autre contrainte est la disponibilité, qui doit être de ou bien environ 6 minutes d'indisponibilité par an. Il existe diérent vendeurs d'implémentation JSLEE : jnetx JAIN SLEE, Open Cloud, Mobicents. Alcatel-Lucent. 52

54 4.11 JSLEE mobicents Introduction JSLEE Mobicents est la seule implémentation open source de JSLEE certiée JSLEE 1.1 elle fait partie de la suite Mobicents Communication Plateforme. JEE SIP SERVELET MEDIA SERVER et JSLEE. Mobicents JSLEE est un ensemble de POJO Beans Plain Old Java Object Beans déployés sur un serveur J2EE JBOSS Caractéristiques JSLEE Mobicents Autre que l'avantage d'être disponible gratuitement étant un produit open source Le développeur bénécie de l'aide de la communauté JBOSS. JSLEE Mobicents propose aussi un déploiement facile des applications. Il ore également une console JMX qui permet la conguration et le contrôle des applications SLEE de manière simple [mob09] Ressource adaptor JSLEE Mobicents ore un ensemble de Resource Adaptors parmi eux nous citons : SIP Resource Adaptor -XMPP Resource Adaptor-Asterisk Resource Adaptor -Java Call Control (JCC) Resource Adaptor- Parlay/Parlay-X Resource Adaptor - J2EE/JCA Resource Adaptor- Diameter Resource Adaptor -Media Resource Adaptor -XCAP Client RA Fig Conclusion Nous avons dans cette partie introduit les serveurs d'application JSLEE. que nous avons étudiés et analysés leur architecture et leurs composants. Nous avons également introduit JSLEE Mobicents qui est une implémentation open source de la spécication JSLEE. Par la suite nous allons étudier la possibilité d'utiliser le serveur d'application JSLEE pour concevoir une architecture orientée événement les détails de cette architecture seront présentés dans la deuxième partie de ce travail. 6. EAS JBOSS micro container 53

55 Figure 4.3 plateforme Mobicents 54

56 Deuxième partie Implémentation d'un moteur d'inférence dans une architecture EDA 55

57 Chapitre 5 Extension BRE-CEP Sommaire 5.1 Introduction Extensions d'algorithme d'inférence Quelles sont les extensions BRE? Exemple d'extension d'un BRE Description Drools fusion Les extensions Drools Fusion? Drools Fusion et EDA Conclusion Introduction Dans un précédent chapitre nous avons parlé d'architecture orientée événements et de l'apport qu'une telle architecture apporte au système IT, en l'occurrence l'agilité et la exibilité qu'ore le traitement par événement. Nous avons également décrit ses composants notamment la source d'événement, le collecteur d'événements (Event collector) et le moteur d'inférence CEP. Ce dernier avait fait l'objet d'un chapitre où nous l'avons étudié et comparé aux moteurs d'inférence des règles métiers (BRE) en concluant qu'un BRE standard peut être utilisé dans les applications de type CEP à condition que certaines extensions lui seront appliquées. La question évidente est quelle sont les diérentes extensions qui doivent être appliquées à un moteur d'inférence de type BRE pour qu'il puisse traiter les évènements et jouer le rôle d'un CEP? Dans notre travail nous analysons les extensions qui doivent être appliquées aux BRE an de satisfaire les besoins des applications CEP 56

58 et nous essayons ensuite dans un autre chapitre de proposer une architecture hybride dans laquelle nous intégrons le BRE à une architecture orientée événements de manière à orir un service CEP. 5.2 Extensions d'algorithme d'inférence CEP et RETE L'algorithme dominant dans le monde des moteurs d'inférence orientés règles métier est bien l'algorithme RETE. An de pouvoir utiliser un BRE comme CEP il faut se poser la question suivante : RETE convient-il au traitement complexe d'événements ou bien CEP? Bien qu'il soit utilisé surtout dans les moteurs BRE, RETE est d'abord et avant tout un algorithme de recherche de correspondance (Matching Algorithm). Il est utilisé dans les moteurs de règle et les systèmes experts, mais il n'y a rien qui le limite au règles métier. C'est juste un moyen de compiler si / alors dans une logique permettant le MATCHING de façon optimisé où les objets et les règles sont créé à l'exécution. RETE est sorti de la nécessité de traiter des situations très dynamiques où un système a besoin de s'adapter à l'évolution des événements. Il existe diérentes stratégies pour étendre RETE au traitement d'événements à titre d'exemple le moteur JESS a supprimé le mécanisme d'agenda rendant l'exécution des résultats d'activation immédiate dans le but d'accroître la performance du processus de MATCHING. Certaines autres stratégies consiste à l'extension de l'algorithme RETE lui-même pour permettre la prise en compte de la logique événement. Dans cette perceptive Berstel [Ber00]avait proposé une extension CEP à l'algorithme RETE qui se base sur la modication des n uds de jointure du réseau RETE tout en gardant la même idée de l'espace de travail WM. Dans cette approche, Berstel propose d'utiliser un même WM pour insérer les faits et les événements, la distinction entre les deux est faite au moment de l'insertion. Dans le cas des faits une méthode INSERT est utilisée alors que dans le cas des événements la méthode INSERT-EVENT sera utilisée pour l'événement qui est annoté par un TIMESTAMP. Le principe de recherche des motifs du Berstel consiste à eectuer des tests temporels dans les noeuds de jointure, cela permet à ces n uds de calculer le temps d'expiration d'événement qui servira à la suppression automatique d'événements obsolètes. Le point faible de l'algorithme de Berstel est qu'il n'avait introduit que deux opérations temporelles parmi les 13 connues. ces deux opérateurs sont l'opérateur AFTER et l'opérateur BEFORE[Ber00]. Une autre extension de RETE a été proposée en vue de permettre le trai- 57

59 tement complexe d'événements. Dans cette approche contrairement à Berstel les faits et les événements ont été séparés. Un graphe d'événement responsable de la détection des patterns est introduit à coté du graphe RETE qui continue à être responsable de la détection des règles utilisant les faits. Un graphe racine est également introduit au-dessus des deux graphes (RETE et graphe des événements) qui sera responsable de la détection des règles combinant des faits et des événements. Le graphe d'événement proposé fonctionne de la même manière qu'un réseau RETE il est constitué de plusieurs niveaux hiérarchiques, le plus bas représente les noeuds représentant les types d'événements simples. En montants dans le graphe nous trouvons les événements complexes composés de plusieurs événements jusqu'à ce que nous arrivions aux n uds de plus haut niveau qui représente les eectifs événements complexes. Initialement l'événement rentre dans le graphe à travers le n uds simple correspondant à son type, en-suite selon qu'il a expiré au pas il sera propagé aux n uds complexes, à chaque niveau du graphe les n uds eectuent des tests sur les événements pour décider si un événement doit être propagé au niveau le plus haut ou non, ce qui veut dire que le motif est détecté au fur et à mesure. A la dernière étape le pattern sera entièrement détecté au niveau des noeuds racines. A ce stade l'événement complexe sera transféré au réseau racine pour être éventuellement combiné avec d'autres faits et événements complexes. Une telle extension permet à RETE d'être utilisé pour la recherche des patterns.[ss06] Puisque nous parlons des applications en temps réel. Toutes les variantes de l'algorithme RETE reste performante face à un grand nombre de règles en sacriant de l'espace mémoire ce qui leur permet de sélectionner rapidement les règles à appliquer, mais seulement une variante appelée RETE III résiste bien face aux structures de données complexes.. Pour le moteur d'inférence et dans le cas de CEP. Il est clair que cette performance supplémentaire, face aux structures de données complexes que RETE III apporte, est importante. 5.3 Quelles sont les extensions BRE? D'après notre lecture et analyse, nous avons été en mesure de rédiger une liste d'exigences, à laquelle, un moteur RETE devra se conformer pour être en mesure de traiter les tâches. support des événements comme un type particulier de faits : Alors que les faits sont des éléments d'information de longue vie, les événements ont des exigences particulières temporelles et le moteur doit être capable de travailler avec les deux en même temps, 58

60 Support d'alimentation asynchrone : PPour être conforme au principe de communication par événement le moteur BRE doit accepter les événements qui arrivent à tout moment et à partir de sources multiples, de sorte que le moteur soit asynchrone et prend en charge l'alimentation dite multi-thread des événements. Support de sélection d'événements : uniquement un sous-ensemble des événements passant par le ux est intéressant pour un ensemble donné de règles. Le moteur doit être en mesure d'identier ou bien de sélectionner de tels événements et d'ignorer les autres an de limiter la charge. Un garbage collector en charge des événements : l'événement a toujours une durée de vie. Le moteur doit être en mesure d'identier les événements qui ne sont plus nécessaires ou qui sont obsolètes et de les éliminer. Il est tout simplement impossible de garder des événements indéniment. Idéalement, l'identication et l'élimination seraient automatiques. Support des contraintes temporelles relatives : Une façon de dé- nir la fenêtre d'intérêt dans un ux d'événements est de dénir des motifs d'événements qui commencent et ferme chaque fenêtre. Ces fenêtres seraient dénies par l'utilisation de contraintes temporelles avec des opérateurs tels que SINCE et UNTIL. Un exemple de règle à l'aide de ces restrictions seraient : Since BTSAlarm code = X, watch BSCAlarm UNTIL the BTSAlarm = Y". La règle ci-dessus va commencer à voir d'éventuelles alarmes venant d'un équipement BSC lorsque une alarme du code X est reçue, mais une fois que ceci arrive, elle continuera à les regarder jusqu'à l'arrivée d'une alarme du code Y. Support des contraintes temporelles absolues : le moteur de règles doit mettre en place un pseudo horloge, qui peut ou non (selon les cas d'utilisation) être synchronisé avec l'horloge réelle et de permettre à des contraintes d'être dénies sur la fenêtre de temps par rapport au pseudo horloge. Les événements en dehors de la fenêtre de temps sont invalide et doivent être éliminés. support du raisonnement sur l'absence d'événements : le moteur doit prendre en charge la dénition des règles qui se déclenchent après l'absence d'événements dans le calendrier prévu (relative ou absolue). Exemple : Si des alarmes de coupure de communication arrivent est aucune alarme n'est reçue des BTS dans 10 minutes. Alors réinitialiser la boite qui émet les alarmes de la BTS ". support des agrégations mathématiques des événements : : le traitement complexe nécessite l'agrégation des événements dans le ux. Le moteur doit fournir des fonctions d'agrégation d'événement comme 59

61 la moyenne, max, min,... etc. le support d'événement comme intervalle : la corrélation entre les événements nécessite l'utilisation des relations qui peuvent être simples comme AFTER, BEFORE ou plus complexes tels que DU- RING, OVERLAPS ces derniers ont la spécicité de prendre en compte l'événement non pas comme un point dans le temps, mais plutôt un interval d'une certaine durée supérieur à zéro ainsi un pattern comme E DURING C se traduit comme suit : E.debut > C.debut et E.n < C.n 5.4 Exemple d'extension d'un BRE An d'étudier concrètement l'extension CEP d'un BRE, nous proposons d'étudier un moteur d'inférence BRE open source appelé Drools que nous avons introduit dans un chapitre précèdent. La communauté JBOSS avait procédé à l'extension de son moteur d'inférence basé sur une variante de RETE appelée RETEOO en lui incluant un module CEP appelé Drools fusion. A l'heure actuelle Drools est dans la version 5.1 et il bénécie d'un large support de la communauté JBOSS. Nous proposons d'étudier Drools Fusion en analysant concrètement les extensions que Drools avait appliquées pour le passage au monde des CEP Description Drools fusion Depuis la version 4 de Drools à la version 5, la plateforme a subi quelques améliorations. Il s'agit notamment du support de trois autres techniques de modélisation d'entreprise. Donc, aujourd'hui, Drools n'est pas seulement un moteur de règles, mais bien plus que cela. Une de ces techniques est le traitement des événements. Le module qui ajoute les capacités de traitement d'événements est appelé Drools Fusion. Il ore le traitement complexe d'événement (CEP) An de donner une introduction à Drools Fusion. Dans cette partie, nous allons illustrer les capacités de Drools Fusion à travers un exemple Nous avons décidé d'utiliser un scénario où un opérateur de téléphonie mobile supervise les BTS de son réseau d'accès. Les BTS émettent des alarmes lorsqu`une communication GSM n'aboutit pas où échoue, le superviseur réinitialise la BTS si le nombre des échecs dépasse un seuil xé pour la BTS sur une période de temps. En d'autres termes, si la BTS émet 4 alarmes dans les dernières 20 minutes ce qui est supérieur à son seuil limite de 3 échecs/20 minutes la BTS sera réinitialisée. Drools nous permet de tester ces conditions, en appliquant le concept de fenêtre de temps. Donc, pour obtenir 60

62 le nombre des échecs pendant une période déterminée dans le temps, on va utiliser des fenêtres de temps. Nous commençons par décrire la POJO BTS : 61

63 Listing 5.1 La classe représentant un fait public class BTS { private String number = ""; private int threshold = 0; public BTS () { super (); } public String getnumber () { return number ; } public void setnumber ( String number ) { this. number = number ; } public double getthreshold () { return threshold ; } public void setthreshold ( int threshold ) { this. threshold = threshold ; } Le suivant est l'implémentation de l'événement alarme d'échec POJO : Listing 5.2 La classe représentant l'evenement public class AlarmFailureEvent implements Serializable { private static final long serialversionuid = 1L; public String btsnumber = ""; private int code = 0; private int ID =0; public AlarmFailureEvent ( String BtsNumber, int code,int ID ) { this. btsnumber = BtsNumber ; this. ID = ID ; this. code = code ; } public void setid ( int id ) { this. ID = id ; 62

64 } public int getid () { return this. ID ; } public void setcode ( int code ) { this. code = code ; } public int getcode () { return this. code ; } public void setbtsnumber ( String btsnumber ) { this. btsnumber = btsnumber ; } public String getbtsnumber () { return btsnumber ; } } Cet événement représente un événement alarme lorsqu'une communication GSM de la BTS échoue. L'événement contient le numéro de la BTS et le code d'erreur représentant la cause de l'échec.ces événements, seront alimentés dans le KnowledgeSession comme des faits. Ce qui suit est la mise en uvre des règles, qui joue le rôle du pattern à détecter Ils sont écrits dans le chier (DRL) suivant : Listing 5.3 Les règles écrites en langage DRL import com. mfe. casestudy. pojo. AlarmFailureEvent ; import com. mfe. casestudy. pojo. BTS ; declare end AlarmFailureEvent # declare a fact type as an event, # default is ' fact role ( event ) rule " MaxBtsAlarmrule " dialect " mvel " no - loop true salience

65 when $BTS : BTS () # check if the number of alarms of # last 20 minutes exceed # the BTS threshold $numofalarms : Number ( intvalue > $BTS. threshold ) from accumulate ( AlarmFailureEvent ( btsnumber == $BTS. number, $ID : ID ) over window : time (1200 s) from entry - point BTSAlarmStream, count ( $ID ) ) then System. out. println ( $numofalarms +" alarms received ON BTS "+ $BTS. number " in last 20 minutes " ); System. out. println (" BTS should be restarted " ); end Analysons le chier DRL : 1. Modication de types de faits existants en spéciant que alarmevent est un événement. An de permettre à Drools de traiter les événements, nous devons xer que le fait est de type d'événement Listing 5.4 declaration de l'événement declare end AlarmFailureEvent # declare a fact type as an event, # default is ' fact role ( event ) 2. règle MaxBtsAlarmrule " obtient le total du nombre d'alarme sur une période de (20) minutes et le compare au seuil d'échec de la BTS. Si le retour 64

66 de l'évaluation du pattern est vrai, Un message d'alerte est aché when $BTS : BTS () Listing 5.5 La partie si de la règle # check if the number of alarms of # last 20 minutes exceed # the BTS threshold $numofalarms : Number ( intvalue > $BTS. threshold ) from accumulate ( AlarmFailureEvent ( btsnumber == $BTS. number, $ID : ID ) over window : time (1200 s) from entry - point BTSAlarmStream, count ( $ID ) ) La partie Action Listing 5.6 La partie alors de la règle System. out. println ( $numofalarms +" alarms received ON BTS "+ $BTS. number " in last 20 minutes " ); System. out. println (" BTS should be restarted " ); Ce qui suit est l'extrait de code de la classe Tester où nous montrons comment un événement alarme se charge sur une période de temps dans le ux d'entrée de la session Listing 5.7 Utilisation de la règle public static void main ( String [] args ) { setup (); try { SessionPseudoClock clock = session. getsessionclock (); WorkingMemoryEntryPoint BtsalarmStream = session. getworkingmemoryentrypoint ( ENTRY_POINT ); BtsalarmStream. insert ( new AlarmFailureEvent ( BTS_NUMBER, 12,1)); clock. advancetime (20, TimeUnit. SECONDS ); 65

67 BtsalarmStream. insert ( new AlarmFailureEvent ( BTS_NUMBER, 46,2)); clock. advancetime (5, TimeUnit. SECONDS ); BtsalarmStream. insert ( new AlarmFailureEvent ( BTS_NUMBER, 60,3)); clock. advancetime (5, TimeUnit. SECONDS ); BtsalarmStream. insert ( new AlarmFailureEvent ( BTS_NUMBER, 110,4)); clock. advancetime (20, TimeUnit. SECONDS ); BtsalarmStream. insert ( new AlarmFailureEvent ( BTS_NUMBER, 20,5)); session. insert ( BTS ); session. fireallrules (); } } catch ( Throwable t) { t. printstacktrace (); } Nous avons utilisé un point d'entrée d'événement qui est "BtsAlarmStream". Le Point d'entrée joue un rôle d'une partition dans KnowledgeSession dans Drools. Le partitionnement est également un nouveau concept de Drools qui lui permet d'être multi-thread. Nous pouvons avoir plusieurs points d'entrée et choisir où insérer le fait. Dans le précédent exemple, nous avons utilisé une seule partition (ou point d'entrée). Si nous avons voulu en utiliser plus d'un, pour permettre le multi-partitionnement nous pouvons le faire comme le montre le code suivant : Listing 5.8 Exemple de conguration KnowledgeBaseConfiguration config = KnowledgeBaseFactory. newknowledgebaseconfiguration (); config. setoption ( MultithreadEvaluationOption. YES ); Autre nouveau concept introduit avec Drools Fusion est les pseudo horloge. Nous avons utilisé SessionPseudoClock qui nous permet de tester les règles en publiant des événements dans l'espace de travail ou la session ( KnowledgeSession) sur une période de temps., après chaque événement nous 66

68 faisons avancer l'horlog, ce qui permet de simuler la publication d'événements en temps diérents. Listing 5.9 Pseudo horloge KnowledgeSessionConfiguration sconfig = KnowledgeBaseFactory. newknowledgesessionconfiguration (); sconfig. setoption ( ClockTypeOption. get (" pseudo " )); session = knowledgebase. newstatefulknowledgesession ( sconfig, null ); Le résultat de test est le suivant : Listing 5.10 Pseudo horloge [ echo ] Start running... [ java ] 5 alarms received ON BTS BXL12 [ java ] BTS should be restarted... Dans un réseau d'accès si le BSC émet des alarmes les BTS qui lui sont connectées émettent eux aussi des alarmes similaires qui ne sont que la cause de l'alarme BSC. An d'alléger le processus de supervision nous modions la règle précédente an que le moteur ignore les alarme BTS si le BSC émet des alarmes. Listing 5.11 Modication des règles when $BSC : BSC () $BTS : BTS ( bscnumber == $BSC. number ) $AlarmBscEvent : AlarmBscEvent ( bscnumber == $BSC. number ) from entry - point BTSAlarmStream # check if the number of alarms of last 20 minutes exceed # the BTS threshold and no BSC Alarm $numofalarms : Number ( intvalue > $BTS. threshold ) from accumulate ( AlarmFailureEvent ( btsnumber == $BTS. number, $ID : ID, this not during $AlarmBscEvent ) over window : time (1200 s) from entry - point BTSAlarmStream, count ( $ID ) ) 67

69 then System. out. println ( $numofalarms +" alarms received ON BTS " + $BTS. number " in last 20 minutes " ); System. out. println (" BTS should be restarted " ); end $ Dans la règle précédente l'opérateur NOT DURING permet d'ignorer les alarmes qui surviennent lorsque le BSC émet des alarmes ce qui limite la supervision à l'échec qui par-vient des BTS uniquement Pour conclure, cet exemple nous a donné une vue sur la manière de traiter les événements complexes avec Drools Fusion en utilisant les fenêtres de temps, les ux d'entrées et l'horloge. Il est également possible après l'extension de l'exemple par l'ajout d'autres règles plus complexes dans le chier DRL de superviser tous les équipements du réseau d'accès BTS BSC,... etc Les extensions Drools Fusion? Après avoir montré comment le moteur d'inférence Drools est utilisé pour le traitement complexe d'événements, dans ce qui suit nous essayons de décrire les diérentes extensions que Drools a appliqué an de permettre le traitement complexe d'événements. Introduction du type événement La première extension logique pour le support du CEP est l'annotation d'un fait comme un événement. Les événements sont modélisés comme des types de faits, qui ont des métas donnés supplémentaires, comme l'expiration, la durée et le Timestamp. Celui-ci est essentiel pour maintenir des contraintes temporelles, Cela dit, nous tenons à souligner que tous les événements sont des faits, mais pas tous les faits sont des événements. Une différence fondamentale est que les événements ne connaissent presque jamais de changement d'état dans le moteur Drools (bien qu'il est encore possible de changer l'état de l'événement), par conséquent, ils sont immuables. Tout simplement l'événement détient des informations sur quelque chose qui s'est déjà produite et puisqu'on ne peut pas changer ce qui s'est déjà produit les événements sont donc immuables. D'autre part l'événement est annoté par le temps ce qui permettra aussi l'utilisation de fenêtres de temps. Ou bien de le supprimer de l'espace de 68

70 travail automatiquement après expiration. Le partitionnement Les CEP sont inondés d'événements, d'où il est nécessaire de limiter les événements qui forment le WM des moteurs d'inférence. Drools fusion prévoit deux manières pour ce faire, le partitionnement des entrées et la dénition des fenêtres d'événements. Partitionnement des entrées Pour partitionner l'ensemble des entrées, le développeur peut dénir des points d'entrée, qui fonctionnent comme des canaux nommés, en fournissant des entités qui peuvent recevoir et envoyer des événements. Cela se fait avec la syntaxe suivante : Event from entry-point Channel-Name Par exemple, dans l'exemple de supervision du réseau d'accès la clause suivante informe le moteur que nous sommes intéressés par un événement nommé alarme provenant de la voie BTSAlarm Alarm() from entry-point BTSAlarm A travers ce partitionnement le moteur pourra recevoir les événements par multi-threading et augmentera ainsi sa performance. Partitionnement par fenêtre Drools fusion appui le partitionnement par fenêtrage soit sur la base du temps ou du nombre d'arrivée an de sélectionner un sous ensemble d'événement. Une fenêtre dénit un sous-ensemble d'un ensemble potentiellement inni d'événements. Une fenêtre sur base du temps est déni en termes de temps et une fenêtre basée sur la fréquence est dénie en termes de nombre d'événements. Par exemple, le code suivant informe le moteur que nous nous s'intéressons uniquement aux alarmes des dernières 20 minu-tes : Alarm() over window :time(20m) Si on veut utiliser le nombre d'arrivée au lieu du temps nous pouvons utiliser la clause suivante qui limite la fenêtre aux 20 premières alarmes reçues Alarm() over window :length(50) La recherche des patterns Dans la Drools, le MATCHING où la recherche des patterns d'événement se rapporte à la partie si des règles, les événements sont des faits, par conséquent, Drools à déjà un mécanisme natif et puissant pour faire correspondre les événements grâce d'abord à la logique des prédicats, qui comprennent des opérateurs : AND, OR, EXIST, NOT EXIST, FOR ALL,... etc. En outre, des opérateurs temporels ont été ajoutées tels que : AFTER, BEFORE, COINCI-DES, DURING, FINISHES, INCLUDES, MEETS, OVER- LAPS et START. À titre d'illustration, le pattern suivant décrit les événements BTSALARM qui se produisent après un événement BTS- FAILALARM : BTSAlarm(this after BTSFAILALARM()) Le support de ces opérateurs est basé sur le fait que chaque événement est étiqueté 69

71 avec une horloge, qui peut être soit xé par le producteur d'événements (externe) ou par le moteur d'inférence lui-même Notons aussi la présence d'opérateurs comme DURING ce qui montre que les événements sont pris en compte comme ayant un intervalle et non pas de simples moments de temps. Cela présente de nombreux avantages pour le traitement complexe d'événements notamment la simplicité et l'aisance d'écriture des patterns Dans le monde des CEP nous trouvons des relations de la forme E qui se chevauche avec C En cas d'absence de prise en compte des intervalles par le moteur d'inférence une telle relation sera traduite d'une manière plus compliquée comme suit (E.debut < S.debut) et (E.n >S.debut) et (E.n < S.n) Alors qu'avec Drools il sut d'utiliser l'opérateur OVERLAPS tel que illustré ci-dessous : E ( this OVERLAPS C ) Drools Fusion et EDA Comme nous l'avons vu Drools a presque étendu son moteur d'inférence en satisfaisant les besoins de CEP toutefois, un CEP n'est en général qu'un composant d'une architecture plus général de type EDA. Ceci dit il doit interagir avec tout le système en recevant et publiant des événements. Dans le cas de Drools Fusions, recevoir des événements consiste à insérer des faits dans le WM. En d'autres termes copier les événements dans l'espace de travail WM. Cela ne va pas créer un problème de consistance des données, car les événements sont immutables une fois publiés. Ils ne changent pas. Toutefois, le problème possible est l'augmentation de la taille de l'espace de travail heureusement cela est aussi contrôlé à travers les durées de vie et le mécanisme de ramasse miettes ainsi que les diérentes techniques de partitionnement, que Drools Fusion utilise. Toutefois, des adaptateurs sont nécessaires an de transformer les événements en événements conformes avec le modèle d'événement de Drools cela est du au fait que Drools ne reconnaît que les classes de son modèle. D'autre part il est important de dire que Drools fusion ne possède pas des mécanismes internes pour la publication des événements ce qui est d'un grand intérêt, car comme nous l'avons précisé un CEP est souvent un composant d'architecture orientée événements. Il doit ainsi recevoir des ux d'événements et réciproquement publier d'autres. Ce qui demande la mise en place de fonctions qui sert à la publication d'événements vers les ux extérieurs et qui seront utilisés dans la partie "Alors" des règles. 70

72 5.5 Conclusion Les BRE avec leur caractère déclaratif sont des choix naturels pour la recherche de correspondance d'événements, dans ce cas une logique des prédicats du premier ordre sut pour permettre le traitement complexe d'événements et comme nous l'avons vu, il sut pour cela d'étendre le moteur pour supporter principalement des contraintes temporelles. Toutefois, l'intégration des moteurs d'inférence BRE même ceux étendu comme Drools dans les architectures orientées événements reste un dé, car elle nécessite la prise en compte de la collecte et plus particulièrement de la publication d'événements, qui n'est pas supportée par le moteur Enn nous essayons dans le prochain chapitre de proposer une architecture dans laquelle nous intégrons le moteur Drools à l'architecture EDA de manière à orir un service CEP complet. 71

73 Chapitre 6 Motivations et objectifs Sommaire 6.1 Introduction Pourquoi un BRE à la place d'un CEP? Limiter le nombre de produits Bénécier des outils de gestion BRE : Limiter le temps d'apprentissage du langage Quel obstacle? Les grandes lignes de la solution Conclusion Introduction L'objectif de ce chapitre est de justier le besoin de la conception d'une architecture hybride qui intègre le BRE Drools à EDA orant ainsi le traitement complexe d'événements, Dans ce but nous allons analyser les apports d'une telle intégration en évoquant ensuite ses obstacles en vue de proposer l'architecture hybride comme solution. Cette solution sera détaillée dans le chapitre suivant, mais nous donnons dans cette partie les grandes lignes et les attendus de la solution. 72

74 6.2 Pourquoi un BRE à la place d'un CEP? Limiter le nombre de produits De nombreuses entreprises ont adopté une architecture EDA, parce qu'en plus de sa exibilité et agilité, une architecture orientée événements supporte la charge et permet de bénécier des avantages des technologies de traitement d'événements en intégrant un moteur CEP. Dans les systèmes IT des entreprises de multiples composants logiciel coopèrent an de réaliser le travail, nous trouvons ainsi un moteur de processus métier qui dénit et gère l'exécution des processus, nous trouvons aussi un moteur de règle métier qui permet d'externaliser et centraliser ces règles et nous trouvons également le moteur CEP. Pour Accompagner chacun des trois moteurs cités, un suivi et un support technique sont nécessaires. À titre d'exemple si l'entreprise opte pour Drools comme moteur de règle et Esper comme CEP elle aura besoin d'une équipe de support pour chaque produit. L'intégration du BRE comme moteur CEP restreint le besoin au support technique puisqu'on supprime le composant CEP, par conséquent l'entreprise se contente du support du moteur BRE. à titre d'exemple l'entreprise qui a choisi Drools comme moteur BRE n'aura besoin que d'une seule équipe de support qui prendra en charge le moteur CEP et BRE Bénécier des outils de gestion BRE : La création, le test et la mise à jour des motifs ne posent pas de problème lorsque le nombre est réduit, mais dès que le nombre augmente ce qui est toujours le cas- la relation entre les motifs devient très compliqué et le processus de maintient, de mise à jour et de déploiement devient une tâche fastidieuse. Les moteurs CEP actuels n'ont pas une gestion mature de ce problème. Ayant focalisé leurs travaux principalement sur le processus de recherche des motifs, la gestion de ces derniers n'a pas fait l'objet de beaucoup de progression. Par contre, les moteurs BRE qui ont existé déjà avant les CEP ont atteint leur maturité, la plupart des vendeurs BRE ore en parallèle un système de gestion de règle très avancé qui permet la création de nouvelles règles dans un environnement conviviale rendant possible la mise à jour, le suivi et le test ainsi que le déploiement. A titre d'exemple Drools ore une plateforme de gestion des règles appelée Drools Guvnor. Drools Guvor est un BRMS qui aide à la modélisation, la création, la mise à jour et le test des règles. Il facilite ainsi leur déploiement sous forme de packages. Cela évite de nombreuses incompréhensions, autrement dit ces outils permettent à des spécialistes métiers qui ne sont pas des techniciens de créer leurs propres 73

75 règles et de les tester avant de les déployer. L'adoption de Drools comme CEP permet de proter de ces outils notamment Drools Guvnor pour gérer aussi les motifs de la sorte que des non techniciens peuvent créer, mettre à jour, tester et même déployer des motifs Limiter le temps d'apprentissage du langage L'acquisition d'un moteur d'inférence ou d'un moteur CEP nécessite entre autres d'apprendre un nouveau langage par exemple le langage EPL dans le cas de Esper ou bien le langage déclaratif dans le cas de Drools, cela augment la durée des projets CEP et constitue souvent une tâche onéreuse pour les membres de l'entreprise, d'autre part si l'entreprise possède les deux types de moteur CEP et BRE, cela devient plus compliqué, car il y aura un besoin d'apprendre deux langages diérents. Sachant que les CEP sont une nouvelle technologie, le degré de la maîtrise de son langage sera inférieur à celui du BRE c'est-à-dire qu'il sera plus facile de décrire les motifs avec un langage déjà utilisé dans les BRE qu'avec CEP. L'utilisation du BRE comme CEP résout ce problème en limitant le temps d'apprentissage du langage, autrement dit le développeur des motifs n'aura pas à apprendre une nouvelle syntaxe ou de nouveaux outils pour créer ces motifs. Il pourra toujours utiliser la même syntaxe et les mêmes outils pour la création de règles, cependant, un temps d'apprentissage est nécessaire pour les nouvelles fonctionnalités CEP, Toutefois, ce temps sera réduit, car il se limite à l'apprentissage d'un ensemble réduit de nouveaux mots clés et de nouvelles fonctionnalités qu'il lui permet d'exprimer des motifs. A titre d'exemple les opérateurs temporelles les horloge... etc. Les motifs dans ce cas sont toujours créé en utilisant une logique de prédicats de premier ordre similaire à celle utilisé pour la création des règles. 6.3 Quel obstacle? Nous avons abordé le sujet des BRE et l'extension CEP appliquée à ce type de moteurs d'inférence. Nous avons pris comme exemple le moteur d'inférence Drools que nous avons étudié son extension CEP appelée Drools Fusion. Cette étude nous a permis de voir quelles sont les changements et les fonctionnalités qui ont permi à Drools de jouer le rôle d'un moteur CEP. Et nous avons conclu que Drools Fusion ore réellement les fonctionnalités attendues par le CEP notamment le support du type d'événement et la prise en compte des contraintes temporelles dont l'introduction des opérateurs temporelles ainsi qu'aux techniques de support de charge telles que le mécanisme 74

76 de ramasse miette et le partitionnement par ux ou par les fenêtres glissantes Néanmoins, Drools Fusion actuellement ne possède pas un mécanisme standard qui permet son intégration à une architecture EDA. Bien qu'il répond aux besoins CEP, il lui manque les outils de communication avec le reste des n uds de l'architecture EDA. C'est-à-dire il lui manque un composant pour la collecte et la diusion d'événements. Pour cette raison une architecture EDA doit être conçu pour faciliter son intégration. 6.4 Les grandes lignes de la solution L'architecture proposée est dite architecture hybride, car nous utilisons un BRE pour faire un CEP elle est reprise dans la gure 6.1 : Elle ressemble à un EDA standard dans lequel des agents sont connectés à un collecteur d'événements et un CEP qui permet le traitement d'événements. Par contre, au lieu d'avoir un ESB comme infrastructure de collecte d'événements nous proposons d'utiliser JSLEE AP SERVER. JSLEE APPLICATIION SER- VER est un serveur d'application connu dans le monde des Telecom il est notamment utilisé dans les réseaux NGN pour la convergence des réseaux. Comme nous l'avons déjà décrit dans l'état de l'art JSLEE constitue un environnement de création des services accessibles par tous types de réseaux (IT, TELECOM) et qui fonctionne selon le principe de communication par événements. Une description de JSLEE est donnée dans le chapitre JSLEE. Dans notre architecture nous utilisons la notion d'adaptateur de ressource qui permet à JSLEE de se connecter à tous types de protocoles, mais nous utilisons également JSLEE comme un collecteur d'événements pour permettre de se connecter aux sources d'événements d'une part et au moteur Drools d'autre part. 6.5 Conclusion Nous avons abordé l'utilité d'utiliser un BRE pour faire du CEP et nous avons montré les apports d'une telle approche. Nous avons alors justié le besoin d'intégrer un BRE à une architecture EDA an de réaliser le traitement complexe d'événements. Nous avons ensuite fait apparaître le problème et les obstacles de l'intégration du BRE Drools dans EDA notamment l'absence des mécanismes d'envoie et de réception d'événements, par conséquent nous avons donné les besoins de l'architecture qui doivent permettre de résoudre ce problème. Enn nous avons parcouru les grandes lignes de la solution que nous proposons notamment l'utilisation de JSLEE comme collecteur 75

77 Figure 6.1 Architecture Hybride d'événements Dans la partie suivante de ce travail nous allons détailler cette architecture et donner les scénarios d'acheminement d'événements et la détection des motifs. 76

78 Chapitre 7 Spécication Sommaire 7.1 Introduction Fondements du projet Objectif Les intervenants Utilisateurs du produit Contraintes Contraintes mandatées Glossaire et conventions de dénomination Spécications fonctionnelles Portée de travail Portée de produit Cas d'utilisation Fonctionnalités Spécications non fonctionnelles Utilisabilité Performance Conclusion Introduction Dans ce chapitre, nous décrivons les spécications d'un prototype d'architecture qui intègre un moteur d'inférence à une architecture EDA. Nous décrirons le fondement du projet en indiquant l'objectif, suivie d'une description des acteurs. Nous décrivant ensuite les contraintes mandatées et 77

79 nous donnons un glossaire des termes et acronymes utilisés dans ce document. Nous proposons ensuite des exigences plus détaillées en utilisant des cas d'utilisation, suivie d'une description des exigences non fonctionnelles du système. 7.2 Fondements du projet Objectif Contexte du projet : L'utilisation de multiples outils informatique au sein des entreprises additionné aux besoins de communication entre ces outils a donné naissance à des architectures complexes des systèmes IT. An de rapporter la exibilité et l'agilité à ces derniers, des architectures comme EDA ont été créés où les diérents composants communiquent par envoie d'événements. Au sein de ce type d'architecture un composant essentiel appelé processeurs complexe d'événement ou CEP joue le rôle de contrôleur qui permet d'analyser les événements échangés entre les composants. Le but des CEP est de détecter l'apparition des séquences d'événements décrivant des situations particulières, en vue de réagir à ces apparitions en temps réel. Les CEP sont encore une nouvelle technologie ce qui signie qu'ils sourent de manque de maturité en termes de support et d'outils adjacent qui facilite son intégration et son utilisation ainsi que du manque de standards. D'autre part une technologie en fonctionnement similaire existe, elle s'appelle les moteurs de règles métier ou BRE. Cette dernière est très répondue dans le monde des entreprises et elle bénécie d'un large support et d'outils qui facilitent son utilisation ainsi qu'à l'existence de standards. Nous devons donc alors étudier la possibilité d'utiliser les moteurs de règles métier pour remplacer les moteurs CEP. Ce projet entre dans le cadre d'un mémoire de n d'étude organisé en collaboration entre le laboratoire WTI de l'université libre de Bruxelles et l'entreprise Euranova. But du prototype : Le but du prototype est de démontrer la faisabilité de l'utilisation d'un moteur BRE comme moteur CEP dans une architecture EDA Les intervenants Laboratoire WIT de l'ulb Ce mémoire est encadré par le professeur Esteban Zimanyi, directeur du laboratoire Web & Information Technologies (WIT) du département Computer & Decision Engineering (CoDE) de la Faculté des Sciences Appliquées 78

80 de l'ulb. Euranova Euranova est une société Belge créé depuis le 1er septembre 2008, son secteur d'activité est les technologies de l'information. Les architectures orientées événements sont parmi les axes de son activité de recherche. Ils ont proposé ce mémoire au professeur Esteban Zimanyi de l'ulb. Euranova a également fortement participé à l'encadrement de ce mémoire (en particulier son directeur de Recherche & Développement, Sabri Skhiri) Utilisateurs du produit Les utilisateurs sont toutes les personnes qui interagissent avec le système il existe deux types d'utilisateurs. Dans cette section, nous fournissons une liste d'utilisateurs avec une brève description. Les utilisateurs directs Un expert BRE : ayant connaissance de la technologie BRE est chargé de la conguration des règles. Générateur d'événements : machine ou logiciel capable d'envoyer des événements sous diérents formats par n'importe quels protocoles. Consommateur d'événements : machine ou logiciel capable d'envoyer des événements sous diérents formats par n'importe quels protocoles. Les utilisateurs indirects Étant connectés à d'autres composants, le reste d'utilisateurs du système IT sont des utilisateurs indirect qui interagissent avec le système à travers les outils reliées au système. 7.3 Contraintes Contraintes mandatées Les contraintes exprimées par Euranova sont listées dans cette section. Choix du BRE Le prototype doit être implémenté en utilisant le moteur BRE Drools. 79

81 7.3.2 Glossaire et conventions de dénomination BTS : la BTS ou Base Transceiver Station est un élément de base du système cellulaire de téléphonie mobile GSM, appelé plus communément antenne-relais GSM. Schématiquement, elle est composée essentiellement d'un élément d'interface avec l'élément contrôlant (BSC), d'un émetteur/récepteur et d'une antenne, elle forme ainsi une cellule. BSC : BSC, ou Base Station Controller (Contrôleur de Station de base) est l'un des éléments du réseau GSM. Son rôle est de commander un certain nombre de BTS (jusqu'à plusieurs centaines). CF : Communication Failure un type d'alarme émis par une BTS qui décrit un échec d'établissement de lien entre deux équipements GSM. EPP : Electrical Power Problem un type d'alarme décrivant un problème d'alimentation électrique au niveau du BTS. PL : Power Level une alarme qui donne l'état de l'alimentation électrique d'une BTS 7.4 Spécications fonctionnelles An de démontrer la faisabilité de l'utilisation du BRE comme CEP. Le prototype simule une procédure de supervision du réseau d'accès de Telecom.. La procédure de supervision consiste à l'analyse de diérents types d'alarmes venants des composants du réseau Telecom tels que les BSCs et les BTSs, dans le but de détecter de possibles pannes Portée de travail La portée de travail est reprise dans la gure 7.1. Elle consiste à un générateur qui simule la source d'événements, l'infrastructure CEP responsable de la détection des motifs ou bien les séquences particulières d'évènements, un récepteur qui simule le consommateur des événements détectés : Portée de produit La portée du prototype est reprise dans la gure 7.2. Nous décrivons le diagramme des cas d'utilisation, l'interaction du prototype avec les diérents acteurs ainsi que la nature de cette interaction. 80

82 7.4.3 Cas d'utilisation Figure 7.1 Prtée de travail An d'illustrer l'utilisation de prototype nous avons choisi le scénario de supervision du réseau Telecom d'accès suivant, Cas d'utilisation I Dénir des règles de détection des pannes : Résumé Dans ce cas un expert déni une règle dans le moteur CEP. Le but de la règle dénie est de détecter les possibles BTS en panne. Elle est dénie par exemple comme suit Si un équipement BTS émet 3 alarmes de type CF pendant 1 minute sans qu'une alarme de l'équipement BSC est active, alors notier un opérateur de contrôle par un message sur son monitor de type BTS en panne. Utilisateur Expert BRE Description Dénir une règle dans le CEP 81

83 Figure 7.2 diagramme des cas d'utilisation Scénario L'expert écrit la règle dans le langage déclaratif utilisé par le BRE. L'architecture permet à l'expert de rajouter les nouveaux motifs,si Le générateur émet des alarmes dans laquelle des séquences sont éventuellement conforment à un motif déni,l'architecture détecte le motif et déclenche les actions associés. 82

84 Cas d'utilisation 2 Ajouter une nouvelle source d'alarmes. Résumé : Dans ce cas un expert décide de rajouter une nouvelle source d'événements par exemple des équipements BTS. Dans ce cas des nouveaux motifs sont éventuellement dénis par example : Si une alarme de type PL est absente pendant 1 minute une alarme de type EP est généré. L'architecture est capable de prendre en charge les nouvelles sources d'événements. Utilisateur Expert BRE Description Rajouter une source d'événements Scénario L'expert dénit les motifs dans le langage déclaratif utilisé par le BRE. Le générateur émet des alarmes dans lesquelles des séquences sont éventuellement conforment aux motifs dénis. Les nouvelles source d'événement envoie leurs événements dans les formats et par les protocoles appropriés à eux. Cas d'utilisation 3 Détecter des motifs Résumé Dans ce cas l'architecture détecte des motifs écrits en langage déclaratif utilisant les opérateurs suivant : (Before, After, Overlap, During, AND, OR) Utilisateur Générateur d'événements Description Détecter une séquence d'événements dans un ux. 83

85 Scénario La machine ou le composant logiciel envoie au moteur BRE ses événements en utilisant son protocole. L'architecture ore à chaque composant le moyen d'envoyer et de recevoir des événement avec le protocole approprié. Analysant ensuite ces événements le moteur détecte les séquences dénies par des motifs. Cas d'utilisation 4 Déclencher des actions Résumé Dans ce cas l'architecture déclenche des actions après détection de motifs. Ces actions peuvent faire appel à des composants logiciel externe. Utilisateur Consommateur d'événements Description Déclencher des actions suite à la détection des motifs. Scénario Après la détection d'un motif l'architecture publie un événement qui sera reçus dans le format et par le protocole approprié des consommateurs Fonctionnalités Routage et transformation L'architecture doit pouvoir faciliter le routage et la transformation des événements venant de tous les composants dans l'architecture EDA. Les agents (composant EDA) peuvent insérer leurs événements générés dans un des ux destinés au BRE, Le principe de découplage doit être maintenu, c-à-d les multiples sources ou agents ne doivent pas se soucier de la transformation des événements dans le format attendu par BRE. L'ajout de nouvelles sources ou la modication doit se faire de manière exible. 84

86 Publication d'événement La détection d'un motif d'événements résulte à la publication d'un autre événement, à titre d'exemple quand 3 alarmes venant d'un même équipement réseau BTS indiquent une panne, le moteur d'inférence CEP détecte ce motif et publie l'événement panne détecter. D'autre part un agent reçoit l'événement publié et initie ainsi un processus par exemple l'envoie de message à un technicien. An de permettre cela L'architecture doit pouvoir orir au BRE la possibilité de publier des événements vers d'autres composants conformément au principe publish/subscribe la partie action des règles doit avoir une fonction de la forme publish(event). 7.5 Spécications non fonctionnelles Utilisabilité Facilité d'utilisation Un motif d'événement est sujet de mise à jour et de modication à titre d'exemple : Un opérateur de téléphonie mobile décidera d'installer de nouvelles BTS qui possèdent de nouveaux capteurs émettant d'autres types d'événements comme la température interne. Ce qui nécessite de créer et de mettre à jour les motifs an de prendre en compte ces événements Bien que la plateforme BRE ore des outils pour la gestion de ces modi- cations. L'architecture doit permettre de reéter ces mises à jour des motifs de manière facile cela en apportant le minimum de modications sur les composants Performance Scalabilité et temps réel Par sa dénition le moteur CEP traite des ux d'événements de diérentes sources et par volume important, un CEP se distingue aussi d'un BRE par sa contrainte de traitement en temps réel. Le CEP doit alors supporter la charge, autrement dit, détecter en temps réel les motifs apparaissant dans des ux d'événements de volume important. Nous avons analysé dans un chapitre précédant la performance de l'algorithme RETE face à cette charge, mais nous n'avons pas abordé la transformation et le routage d'un grand volume d'événements, cela signie que cela doit être géré par l'architecture. 85

87 L'architecture proposée doit ainsi supporter cette charge d'événements en permettant le routage et la transformation en temps réel. 7.6 Conclusion Après avoir vu la spécication du prototype et exprimé les attendus de la solution, nous allons dans le chapitre suivant proposer une architecture permettant de satisfaire les besoins exprimés que nous allons implémenter. Nous pouvons ensuite démontrer sa conformité aux spécications en utilisant les scénarios décrits dans la section cas d'utilisations. 86

88 Chapitre 8 Analyse et conception Sommaire 8.1 Introduction Les composants de l'architecture Agent EDA JMS-RA Proxy service Le BRE-RA Le moteur d'inférence L`agent DROOLS La base des règles L'agent X Fonctionnement Diagramme de séquence du cas d'utilisation Diagramme de séquence du cas d'utilisation Déploiement Dénition d'événement L'architecture répond-t-elle aux attendus? Conclusion Introduction Dans cette partie nous proposons notre solution aux problèmes abordés au chapitre précédant à savoir l'intégration d'un moteur BRE à une architecture orientée événement. Nous proposons ainsi une architecture hybride dans 87

89 laquelle un moteur Drools s'intègre à une architecture EDA dans le but d'offrir un service CEP. Cette architecture permet d'intégrer Drools de manière à orir la possibilité d'ajouter des sources d'événements de manière exible tout en respectant le principe de communication par pubilsh/subscribe. Nous avons déjà donné les grandes lignes de notre architecture en proposant d'utiliser le serveur d'applications JSLEE comme collecteur d'événements. L'architecture choisie est reprise dans la gure 16. Un serveur d'application JSLEE qui lui, connecté à un agent EDA via un adaptateur de ressources permet la collecte d'événements. Le serveur JSLEE héberge un service Proxy qui reçoit les événements venants de l'agent EDA et qui les insèrent ensuite dans la base de connaissances Drools via un adaptateur de ressources nommé BRE-RA. Le moteur d'inférence Drools publie les événements suite à la détection des motifs via un Agent connecté à l'adaptateur de ressources BRE-RA. 8.2 Les composants de l'architecture Agent EDA Les agents EDA sont les sources d'événements ils sont la liaison entre les services web ou autres et l'infrastructure EDA. Chaque service possède un Agent qui lui permet d'envoyer et de recevoir des événements. Leur rôle essentiel est de transformer les requêtes en événements ayant un type et un ensemble de propriétés. Les agents EDA dans notre architecture ont une classe qui transforme les événements en message JMS et les envoie à JSLEE. Dans notre architecture les messages JMS ont une forme canonique où chaque message contient le type d'événement et la liste des propriétés. Toutefois, bien que nous avons utilisé JMS tout autre protocole de communication est possible à condition qu'il existe un adaptateur JSLEE adéquat JMS-RA Nous avons déjà abordé dans le chapitre JSLEE la dénition d'un adaptateur de ressources, nous avons également décrit son rôle. L'adaptateur de ressource est le point d'entrée à JSLEE. Tous les composants extérieurs (agents EDA, équipements réseaux), communiquent avec JSLEE à travers l'adaptateur de ressources, Dans notre architecture un adaptateur de ressources de Type JMS reçoit les messages publiés par les agents EDA et les transforme en événements JSLEE. Une multitude d'autres adaptateurs de ressources existent déjà et peuvent transformer d'autres types de messages tels que SIP ou SOAP en événement JSLEE. 88

90 8.2.3 Proxy service Figure 8.1 Architecture hybride Dans la spécication JSLEE deux adaptateurs de ressources ne peuvent pas communiquer entre eux, par conséquent un service doit être conçu an 89

91 de jouer le rôle du Proxy entre d'une part la source d'événements et d'autre part le BRE-RA. Les sources d'événements peuvent être les diérents adaptateurs de ressources ou bien les autres services hébergés dans JSLEE. Il est à noter que le service ne contient aucune logique de traitement. Lorsque deux occurrences d'un même événement arrivent, le service les traite de la même manière à savoir les insérer dans la base de connaissances à travers les interfaces de l'adaptateur de ressource BRE-RA : Insert(Event, stream). Cette interface insert les événements dans un ux d'événements. Le ux dans lequel l'événement sera inséré est déduit de l'événement lui-même à travers une propriété indiquant sa destination. Toutefois, nous pouvons dénir des règles au sein de la base des règles Drools qui s'occupe du routage d'événement. A titre d'exemple une fois l'événement inséré dans un point d'entée commun, une règle de routage le réinsère dans un autre ux suivant les propriétés de l'événement. Bien que cela peut engendrer une charge supplémentaire pour le moteur, mais cela permet de respecter le principe de découplage en séparant l'événement et la destination. Le service Proxy n'a pas besoin de garder un état ni de faire un accès vers des données extérieurs, il peut donc être considéré comme un service Stateless. L'implémentation d'un service qui ne maintien pas d'état (Stateless) permet d'augmenter l'ecacité en supprimant le besoin d'accès vers un état et en libérant les ressources (les objets) an de servir le plus d'événements. Le service Proxy est conçu pour recevoir un type d'événement particulier appelé Generic Event qui représente tout les types d'événements cet événement est décrit dans la partie suivante. Le traitement consiste à insérer l'objet de l'événement reçu GenericEvent dans la base de connaissances Drools à travers les interfaces de l'adaptateur des ressources BRE - RA, ce dernier est responsable de l'extraction de l'événement réel avant l'insertion dans la base de connaissances. Le choix d'utiliser un seul événement représentant tous les événements a pour but de faciliter l'ajout de nouveaux types d'événements sans avoir à dénir ce type dans JSLEE et sans avoir alors à redéployer le service Proxy Le BRE-RA Le c ur composant de l'architecture est l'adaptateur de ressource Drools c'est là où nous trouvons la base de connaissances et la base des règles, son architecture est présentée dans la gure 8.2 : L'adaptateur de ressources de type BRE, ore donc multiples interfaces, Insert (EVENT) : permet l'insertion des événements dans la base de connaissances. Publish (Event : permet l'insertion des événements dans JSLEE. 90

92 Figure 8.2 Architecture du resource adaptor BRE Drools An de permettre la portabilité des moteurs d'inférence BRE d'autres interfaces sont dénies : JsrInsert (EVENT) : permet l'insertion des événements dans la base de connaissances en utilisant les API JSR24 JsrPublish (Event) permet l'insertion des événements dans JSLEE en utilisant les API JSR24 Ces deux dernières interfaces permettent de substituer le moteur d'inférence Drools par un autre moteur d'inférence qui implémente les API de la spéci- cation JSR24 Puisque nous utilisons un BRE comme CEP nous avons besoin d'insérer et de rétracter des faits dans la base de connaissances. Nous proposons de gérer ça dans la base des règles. Une règle simple doit être écrite pour insérer un fait lorsque qu'un événement d'un type particulier est inséré. L'adaptateur de ressources ne se soucie pas de ce problème il traite tout comme événement. Bien que cela représente une charge supplémentaire pour le moteur d'inférence il permet plus de exibilité lors de l'ajout des événements, car il 91

93 sut de rajouter des règles sans avoir à redéployer l'adaptateur de ressource BRE-RA Le moteur d'inférence Le moteur d'inférence Drools inclut un compilateur qui transforme les règles fournies en entrée en réseau RETE. Toutefois, Drools ore la possibilité d'utiliser le moteur d'inférence ainsi que son compilateur et de construire la base des règles à l'extérieur de l'environnement Drools. Drools ore aussi la possibilité d'utiliser un agent qui relie la base des règles à un dépôt extérieur où les règles sont créés et testées. L'agent procède à la synchronisation de la base des règles et à leur dépôt, dès que le déploiement est ordonné. Ce modèle est celui que nous avons choisi, car il permet la mise à jour de la base des règles en ligne sans avoir à redéployer l'adaptateur de ressources L`agent DROOLS An de permettre à Drools d'envoyer des événements à JSLEE, un agent est rajouté dans le modèle de Drools. Il permet d'utiliser des fonctions d'envoie dans la partie si de la règle telle que Send (Event) La base des règles Elle représente les règles traduites en réseau. Cette base de règles est recréer à chaque mise à jour des règles. Cette opération est coûteuse, mais elle permet de mettre à jour les règles en ligne L'agent X Ils implémentent la partie action. C'est le consommateur d'événements détectés. C'est un Service JSLEE qui a inscrit à l'événement et qui détient la logique de traitement associé. Il peut lui-même implémenter la logique ou renvoyer l'événement vers un agent externe à travers les adaptateurs de ressources. JSLEE est un environnement standardisé qui permet la création de services de manière rapide, ce qui facilite la création des agents. 8.3 Fonctionnement Nous avons décrit dans le chapitre spécication 4.3 des cas d'utilisation qui consiste à la dénition d'une nouvelle règle dans le système et l'ajout 92

94 d'une nouvelle source d'événements. An de mieux comprendre le fonctionnement nous décrivons dans ce qui suit les diagrammes des séquences associés à ces cas d'utilisation : Diagramme de séquence du cas d'utilisation 1 Dans ce cas l'expert utilise un éditeur pour écrire les règles il les ajoutes ensuite à l'agent de synchronisation à travers un chier XML. Pour faciliter la rédaction des règles, l'expert peut utiliser l'éditeur intégré à Drools Guvnor qui lui génère une URL à envoyer à l'agent de synchronisation. Figure 8.3 diagramme de séquence du cas d'utilisation Diagramme de séquence du cas d'utilisation 2 Dans ce cas l'ajout des dénitions de nouveaux événements est nécessaire. Pour cela l'expert doit rajouter dans le Resource Adapter Drools la dénition des événements simples ou bien des événements générés par la nouvelle source. Cela revient à faire une copie identique des classes d'événements dans le Jar contenant le Resource Adapter. L'expert créera ensuite des événements 93

95 SLEE représentant les événements complexes an de les déployer dans le serveur SLEE. Le déploiement des composants SLEE est discuté dans le chapitre SLEE 4.8. Enn pour permettre au Resource Adapter Drools de déclencher les événements complexes détectés, l'expert les déclare dans le descripteur du Resource Adapter ce qui revient à ajouter une balise dans un chier XML. Figure 8.4 diagramme de séquence du cas d'utilisation Déploiement Le diagramme de la gure 8.5 présente le déploiement physique de l'architecture, pour des raisons de simplication nous n'avons présenté que les éléments de base. Dans ce diagramme les événements complexes sont inclus dans le jar complex-events.jar. 94

96 95 Figure 8.5 diagramme de déploiement

97 8.5 Dénition d'événement La dénition des événements est un point important dans l'architecture EDA Dans le cas du traitement CEP il existe multiples types d'événements dans le système qui doit être routés vers le CEP. An de permettre une exibilité nous utilisons dans JSLEE un seul type d'événement. Cet événement en-capsule tous les autres types. Il possède entre autres deux propriétés essentielles EventType qui consiste au type d'événement ayant été reçu, ce type est représenté par le nom de la classe de l'événement. La deuxième propriété est un tableau contenant la liste des noms des attribues, leurs valeurs et leurs types. L'utilisation d'un événement générique permet de rajouter des événements sans pour autant avoir à redéployer le service Proxy, qui lui ne reconnaît que ce type. La transformation des événements dans cette forme canonique est assuré par l'agent EDA ce qui permet d'envoyer des événements dont JSLEE ne connaît pas leur dénition. L'adaptateur de ressource transforme tous les événements, reçues sous forme canonique, en évènements génériques. Par contre, comme Drools ne reconnaît que les classes de son modèle la dénition des événements doit être fourni au BRE-RA qui instancié les événements avant de les insérer dans la base des connaissances. Cela implique simplement que nous devons dénir les événements de manière identique dans les agents et le CEP l'ajout d'un autre événement implique l'ajout d'une autre dénition dans le BRE-RA. Ce qui implique la nécessité de redéployer le BRE-RA cependant, le changement se limite à l'ajout de la dénition d'événement uniquement. 8.6 L'architecture répond-t-elle aux attendus? Dans cette architecture hybride le serveur d'application JSLEE joue le rôle d'un collecteur d'événements qui relie le moteur Drools à l'architecture EDA est vice versa. Ce choix d'utilisation de JSLEE pour la collecte d'événements est justié parce que nous l'avons déni comme besoin au routage et transformation ainsi qu'à la publication d'événements. Ce besoin consiste à la capacité de récolter les événements de multiples sources et par multiples formats, JSLEE bénécie pour cela de la notion des RA qui lui permet de se connecter à plusieurs sources d'événements. Étant à la base destinée à la convergence des réseaux IT et TELECOM il intègre déjà la notion de multiples sources permettant ainsi d'étendre la collecte d'événements à tout types de protocoles. Le deuxième point que nous avons déni est le support de la charge ceci est hérité des exigences des moteurs CEP ou le volume 96

98 important d'événements et les fortes contraintes temporelles sont l'une des principales caractéristiques sur ce point aussi JSLEE est parfaitement adéquat. Étant un serveur d'application conçue dans le monde des Telecom où les contraintes temporelles et le volume d'échange sont plus importants, il est alors optimisé pour le support de la charge. Ainsi il répond parfaitement aux besoins de la collecte d'événements. L'une des spécicités de JSLEE qui lui permet le support de la charge est la possibilité d'être installé sur des clusters et partagé ainsi les contextes entre éléments du cluster. La exibilité est égale à la portabilité qui est un autre point important que nous avons déni lors de notre analyse de la solution attendue ceci est important dans le but de limiter les risques. Dans ce cas JSLEE est toujours le bon choix, car il est principalement une spécication implémentée par plusieurs vendeurs. Cela veut dire que JSLEE est complètement standardisé. La modication ou le changement du produit n'a pas un grand impact sur l'architecture. Les services conçus sous JSLEE fonctionnent sur toutes les implémentations JSLEE et à l'avenir les adaptateurs de ressources seront interchangeables entre toutes les implémentations JSLEE. Cette portabilité est d'un grand intérêt qui représente une motivation pour le choix de JSLEE comme infrastructure de collecte d'événements. à titre d'exemple étant spéci- é et interchangeable l'adaptateur de ressources destiné à contenir le moteurs Drools peut être substitué par un autre adaptateur de ressources dédier à un autre moteur BRE ce qui permet d'atteindre la exibilité attendue. 8.7 Conclusion Dans ce chapitre nous avons présenté notre architecture EDA hybride basée sur le serveur d'application JSLEE qui joue le rôle d'un collecteur d'événements. Autre que la exibilité qu'elle ore par la possibilité de changement de produit JSLEE elle bénécie de la richesse des sources d'événements par l'utilisation des adaptateurs de ressources. Cette architecture répond bien aux attendus de la solution elle permet de prendre avantage de la notion d'adaptateur de ressource et de la robustesse et abilité de JSLEE face à la charge d'événements, elle permet aussi d'implémenter la partie action des CEP sous forme de SBB. Augmentant ainsi la productivité et la portabilité. An de concrétiser les notions théoriques. Nous allons dans la partie suivante discuter l'implémentation d'un prototype de cette architecture. 97

99 Chapitre 9 Implémentation Sommaire 9.1 Introduction L'événement générique Le Resource Adaptor Drools RA TYPE BRE RA BRE DROOLS Déploiement des règles Le service Proxy Agent EDA Agent X Exemple d'exécution Dénition des événements Dénition des règles générateur d'événements consommateur d'événements Observations Conclusion Introduction Dans ce chapitre nous décrivons l'implémentation d'un prototype de notre architecture décrite dans le chapitre précédant. Nous commençons par décrire la manière avec laquelle nous avons implémenté les diérents composants de l'architecture. Nous montrons ensuite comment nous utilisons ces éléments pour orir le service CEP enn nous donnons un exemple d'utilisation. 98

100 9.2 L'événement générique L'événement générique encapsule tous les types d'événements dans JS- LEE il contient 2 propriétés importantes : Le type d'événement qui représente le nom complet de la classe de l'événement. Un tableau associatif qui comporte les noms des champs, leurs types et leurs valeurs. Cet événement est déployé sous forme d'événement JSLEE, autrement dit l'événement générique comporte un POJO et un descripteur. Un tel événement est déclenché dans JSLEE par les Resource Adapters qui connectent JSLEE au monde extérieur. A titre d'exemple JMS-RA convertit les événements qu'il reçoit en événements génériques. La conversion est possible grâce à l'introspection java et l'utilisation de la librairie Refelction, pour cela une classe Converter joue le rôle du convertisseur. La gure 9.1 montre un exemple de conversion entre un événement de type BTSALARM et un événement générique. Notons que le déclenchement de l'événement dans JSLEE se fait par une seule ligne de code. Figure 9.1 Le JMS Resource Adapter RA Pour permettre à d'autres Resource Adapters de déclencher l'événement générique il sut d'utiliser la classe Converter ou bien d'écrire un autre 99

101 convertisseur et déclarer ensuite l'événement générique dans le descripteur du Resource Adapter, Cela ce fait facilement comme le montre ce code : Dans le cadre de ce prototype nous avons utilisé le serveur JMS oert par JBOSS AS nommé Messaging JBOSS pour cette raison nous n'avions pas besoin d'un JMS-RA pour JSLEE Mobicents. Par contre, dans d'autres environnements JSLEE ou un service JMS externe doit être utilisé le JMS- RA devient nécessaire. Le descripteur de l'événement générique est donné dans. Listing 9.1 Descripteur de l'événement générique <event -jar > < event - definition > < description /> <event - type - name > ulb. mfe. srabre. GenericEvent </ event - type - name > <event - type - vendor > ulb. mfe. srabre </ event - type - vendor > <event - type - version >V1 </ event - type - version > <event - class - name > ulb. mfe. srabre. event. GenericEventEvent </ event - class - name > </ event - definition > </ event -jar > 9.3 Le Resource Adaptor Drools Conformément a la spécication JSLEE tous Resource Adaptor doit avoir un type. Dans notre cas le Resource Adaptor est de type Resource Adaptor BRE. Nous avons alors développé un RE TYPE BRE RA TYPE BRE Le diagramme de classe de RA TYPE BRE est donné dans

102 Figure 9.2 Diagramme de classe du Resource Adaptor Type Il comporte deux classes : Le RAInterface cette classe doit être implémentée par le Resource Adaptor Drools, il représente les interfaces exposées par le Resource Adaptor aux services JSLEE ou plus précisément aux SBBs constituants les services. Dans ce cas la seule interface est Insert(GenericEventEvent) cette interface insert dans la base de connaissance l'événement encapsulé dans le genericeventevent. La classe BREActivity : est une classe imposé par la spécication JSLEE an de pouvoir déclencher des événements. Cette classe représente la session qui englobe les informations communes dédiées à une séquence d'événements tels que les événements échangés pendant un appel téléphonique. Dans notre cas nous n'avons pas besoin d'établir des sessions. Toutefois, nous devons dénir cette classe an de permettre au RA BRE DROOLS de déclencher des événements dans JSLEE. Le descripteur de RA BRE TYPE est le suivant : 101

103 Listing 9.2 Déclaration d'un evenement dans Le RA Type <event - type -ref > <event - type - name > ulb. mfe. srabre. event. BTSFailure </ event - type - name > <event - type - vendor > ulb. mfe. srabre </ event - type - vendor > <event - type - version >1.0 </ event - type - version > </ event - type -ref > Notons que lorsque nous rajoutons des événements complexes c'est dans ce descripteur qu'il faut les déclarer, à titre d'exemple dans le descripteur précédant nous avons déclaré un événement de type BTSFailure comme étant un événement complexe déclenché par le Resource Adaptor. Lorsque Drools détecte le pattern associé à cet événement le Resource adapter Drools le déclenche dans JSLEE RA BRE DROOLS An de pouvoir utiliser le moteur BRE DROOLS nous avons développé Un Resource Adaptor Drools, ce dernier est de type Resource Adaptor BRE, il implémente les interfaces de la classe BREInterface et la classe BREActivity Le diagramme de classes du Resource Adaptor est donné dans la gure

104 Figure 9.3 Diagramme de classe du Resource Adapter Drools 103

105 Le Resource Adaptor implémente la méthode Insert de la classe BREInterface, cette méthode est utilisée par le SBB proxy pour insérer l'événement générique reçue dans la base de fait Drools, Notons que cette base est créée au moment du déploiement du RA, la manière de création est abordée par la suite. An de pouvoir extraire les événements encapsulés dans l'evenement générique, une classe EventConverter qui utilise L'API Reection est incluse dans le RA BRE DROOLS. elle joue le rôle d'un convertisseur semblable à celui décrit dans la section evenement générique. La conversion dans ce cas est de l'événement générique vers l'événement encapsulé, cela implique que le RA doit posséder la dénition de l'événement simple, ce qui est nécessaire aussi pour le moteur Drools, car ce dernier ne reconnaît que les classes de son modèle. Toutefois, cette dénition se réduit à une copie identique de la classe de l'événement. Dans le jar contenant le RA. La classe DroolsAgent joue le rôle de l'agent de publication des événements complexes détectés. Cet agent ore une interface au moteurs Drools Publish pour publier les événements complexes, la référence vers cet agent est passé à Drools via le mécanisme de variables globales. Le moteur Drools est déployé en mode Compiler c-à-d qu'il inclut non seulement le moteur d'inférence qui implante l'algorithme du Matching, mais aussi un compilateur qui permet de compiler les règles écrites sous forme de chier DRL ou autres et de créer le réseau RETE correspondant Déploiement des règles Comme nous l'avons déjà décrit le moteurs Drools est déployé en mode compilateur cela dit que les règles ou les patterns peuvent êtres écrites sous diérents formats. Nous avons alors choisi de déployer les règles sous forme de chier DRL, ce chier peut être inclut dans le Deployable Unit du RA BRE DROOLS. Au moment de la création du RA BRE DROOLS par le serveur JSLEE, le RA compile le DRL en créant ainsi la base de règles. Cela signie qu'an de changer une règle nous devons modier ce chier. Pour faciliter la tâche nous utilisons un agent de synchronisation Drools qui mis dynamiquement à jour la base de règles. Cet agent scan en mode pull le descripteurs des sources an de mettre ajour la base de règles. Le descripteur g est un chier XML contenant un ensemble d'url de chier DRL contenant les règles. Les règles sont dans ce cas crées et testées dans un environnement dédié tel que Drools Guvnor. Cela signie que l'ajout d'un nouvel ensemble de règles se limite à l'ajout d'une URL dans le descripteur. 104

106 Figure 9.4 Exemple déploiement des règles Toutefois, comme la dénition des événements simples est faite dans le RA l'ajout d'un nouveau type d'événement simple nécessite que cet ajout soit de manier identique dans le RA. Cela se fait facilement. Par opposé l'ajout d'un nouveau événement complexe nécessite de le dénir dans le serveur JSLEE lui-même, an qu'il puisse être déclenché. Cependant, créer un événement et le déployer dans JSLEE ne pressente aucun problème et peut se faire de manière facile. 9.4 Le service Proxy Le service Proxy Figure 9.5 est un service JSLEE le diagramme de classes du service est présenté dans la gure suivante. Ce service représente le point d'entrée vers le le moteur Drools il récolte les événements GenericEventEvent venant de diérentes sources et les transfert au RA BRE DROOLS. Conformément à la spécication JSLEE le service Proxy contient un SBB Root qui est ProxySBB. Le ProxySBB est un SBB sans état ou stateless. Cela libère plus de ressources (Objet) et permet d'augmenter la performance de traitement des événements. Conformément au spécication JSLEE le service Proxy contient un SBB root qui est ProxySBB. Le ProxySBB est un SBB sans état ou stateless. Cela libère plus de ressources (Objet) est permet d'augmenter la performance de traitement des événements. Figure 9.5 Exemple Service Proxy 105

107 Le ProxySBB 9.6ne reconnaît que le type d'événement générique et ignore le reste cela dit que l'ajout de nouveau événement ou de nouvelle source d'événement ne nécessite pas la modication du Service Proxy. Figure 9.6 Diagramme de classe du SBB Proxy La classe ProxySBB utilise le BRE RA DROOLS Entity pour pouvoir insérer les événements encapsulés dans l'événement générique pour cela elle fait appel à la fonction Insert. 9.5 Agent EDA Jusqu'au là nous avons notre service CEP Drools qui collecte des événements enveloppés dans un événement générique et qui détecte les patterns. An de pouvoir tester notre service nous avons besoin d'un Similateur qui joue le rôle d'un producteur d'événement ou Agent EDA Nous avons alors choisi de créer un service JSLEE qui joue ce rôle, ce service comporte un générateur d'événements et un Agent qui joue le rôle de convertisseur d'événement qui encapsule l'événement dans un événement générique. Dans ce cas c'est le service lui-même qui déclenche les événements dans JSLEE. 106

108 9.6 Agent X Pour compléter l'architecture nous avons créé un Service consommateur sous forme d'un service SLEE. Dans notre implémentation ce service est abonné à tous les événements complexes et associe un traitement a chacun d'entre eux en utilisant la méthode eventhandleer décrite dans la spécication JSLEE. Dans un autre environnement plusieurs services peuvent être développés. 9.7 Exemple d'exécution Nous avons maintenant notre architecture implémentée, il ne nous reste que de la tester pour cela nous avons choisi un exemple qui est la supervision du réseau d'accès. La supervision de réseau d'accès consiste à la détection des pannes possibles dans les composants du réseau d'accès. Ces pannes sont décrites par une suite d'événements exemple : une BTS envoie plus de 3 événements d'échec d'établissement de communication pendant moins de 20 minutes. Un CEP est responsable de la détection de ces séquences et de les notier à l'administrateur Nous proposons d'utiliser notre architecture an de réaliser un outil de monitoring du réseau d'accès Figure 9.7. Figure 9.7 Schéma de l'exemple 107

109 9.7.1 Dénition des événements Pour cet exemple nous dénissons deux types d'événements Le premier est de type AlarmFailureEvent signie un échec d'établissement de communication entre deux équipements GSM. Le deuxième type d'alarmes est AlarmBscEvent il signie un problème au niveau d'équipement BSC. Ce dernier est généré par un BSC Dénition des règles Le pattern à détecter est le suivant : si plus de 3 événements de type AlarmFailureEvent surviennent dans moins de 20mn sans qu'un événement AlarmBscEvent ne soit actif alors envoyer un événement de type BTSAlarm à l'administrateur. Ce pattern est exprimé sous forme de deux règles Drools. Listing 9.3 présence d'une alarme AlarmBscEvent when $BSC : BSC () $BTS : BTS ( bscnumber == $BSC. number ) $AlarmBscEvent : AlarmBscEvent ( bscnumber == $BSC. number ) from entry - point BTSAlarmStream $numofalarms : Number ( intvalue > 2 ) from accumulate ( AlarmFailureEvent ( btsnumber == $BTS. number, $ID : ID, this not during $AlarmBscEvent ) over window : time (1200 s) from entry - point BTSAlarmStream, count ( $ID ) ) then BTSAlarm alarm = new BTSAlarm ( $BTS. btsnumber ); Object ev = alarm ; Agent. publish ( ev ); end $ 108

110 Listing 9.4 absence d'une alarme AlarmBscEvent when $BSC : BSC () $BTS : BTS ( bscnumber == $BSC. number ) not ( AlarmBscEvent ( bscnumber == $BSC. number ) from entry - point BTSAlarmStream ) $numofalarms : Number ( intvalue > $BTS. threshold ) from accumulate ( AlarmFailureEvent ( btsnumber == $BTS. number, $ID : ID ) over window : time (1200 s) from entry - point BTSAlarmStream, count ( $ID ) ) then BTSAlarm alarm = new BTSAlarm ( $BTS. btsnumber ); Object ev = alarm ; Agent. publish ( ev ); end générateur d'événements Un générateur simule les événements venant du réseau d'accès et les publie dans JSLEE. Il est implémenté sous forme de service JSLEE consommateur d'événements Le consommateur d'événements est un Agent EDA qui s'abonne à un sujet Test au niveau de serveur JMS, ce qui lui permet de recevoir tous les événements publiés dans ce sujet. Dans notre exemple le serveur JMS est JBOSS Messaging et le service qui publie l'événement c'est un service JSLEE. L'agent est connecté à une interface graphique qui permet d'acher les événements reçus

111 9.7.5 Observations Figure 9.8 Interface application Client Les résultats d'exécution de notre exemple ont été très satisfaisante, elles montrent comment notre architecture permet facilement de créer et de gérer des motifs complexes. Néanmoins, des testes de performances peuvent être envisagés pour évaluer l'ecacité de la combinaison JSLEE Mobicents et Drools, an de les comparer dans le futur avec d'autres combinaisons possibles. 9.8 Conclusion Nous avons présenté dans ce chapitre notre implémentation de l'architecture hybride. Nous avons commencé par décrire l'événement générique qui encapsule tous les autres événements, nous avons ensuite donné les digrammes de classes et les descripteurs des composants de l'architecture (BRE RA TYPE, BRE RA, Service Proxy, Agent EDA, Agent X. Nous avons ensuite présenté un exemple d'utilisation de notre architecture dans la supervision des réseaux d'accès. Enn nous avons conclu par un ensemble d'observations. 110