EA2013 RulesEngines EventConditionActin ComplexEventProcessing

From air
Jump to navigation Jump to search

Présentation

Abstract

In computer sciences, there exists different programing paradigm. The event programming is one of them. It opposes itself to the sequential programming because the execution flow of these programs isn't definied beforehand. The program will have to react to the different events it will receive. Some architecture pattern are based on this paradigm. This is the case of the event-driven architecture pattern. We will see an particular instance of this pattern which uses the Rules Engines, and also the Complex-Event Processing, which is one of type of event processing.

Keywords

Event-Driven Architecture, Rules Engine, Complex-Event Processing

Résumé

En informatique, il existe différents paradigme de programmation. La programmation événementielle est l'un d'entre eux. Elle s'oppose à la programmation séquentielle car le fil d'éxècution de ces programmes n'est pas défini à l'avance. Le programme va devoir régair différement aux événements qu'il recevra. Certains pattern d'architecture se basent sur ce paradigme. C'est le cas de l'architecture orientée événements. Nous allons voir une instance particulière de ce pattern utilisant les Rules Engines, ainsi que le Traitement des événements complexes, qui est une manière de traiter les événements.

Mots-clés

Architecture Orientée Evènements, Rules Engine, Traitement des événements complexes, Evènement,

Synthèse

Event-Condition-Action (ECA)

Les éléments à la base des Architectures Orientées Evènnement sont les règles. Elles sont consitutées de la manière suivante :

  • Event : Evènement qui permet d’invoquer la règle
  • Condition : Partie logique pour vérifier que la régle est satisfaite ou non
  • Action : Actions, mise à jour du système
event : IF some condition THEN some action

Ces règles peuvent être écrites dans différents langages, certains d'entres eux sont très proches du langage naturel.

Rules Engine

Définition

Rules Engine
Elements d'un Rules Engine

Les Rules Engines (ou Rules-based System) sont utilisés en informatique, pour interpréter des données en se basant sur plusieurs composants :

  • Base de règles (rules-base) : Elle constitue la "connaissance du système" et est construite grâce à des règles (ECA).
  • Moteur d'inférence (inference engine) : Programme qui va permettre de "raisonner" sur les règles établies dans la base.
  • Memoire de travail (workspace/working memory) : Mémoire qui va permettre au moteur d'inférence d'effectuer son raisonnement.

Ces trois composants sont indépendants. Ce qui signifie que s'ils sont fait de manière à être compatibles, on peut utiliser un moteur d'inférence avec différentes bases de règles.

Système Expert

La manière de construire ces systèmes est finalement proche du fonctionnement du cerveau humain. C'est pourquoi ces sytèmes sont très utilisés en Intelligence Artificielle. On parle alors de "Système Expert". Les sytèmes experts simulent la prise de décision par un expert humain. Ils sont conçus de manière à résoudre des problèmes complexes, en raisonnant sur une base de connaissance de la même manière qu'un expert humain.

Ces sytèmes possèdent de nombreux avantages :

  • Base de règles écrite dans le langage courant : Permet de facilement transmettre de la connaissance au système
  • Réutilisabilité du moteur d’inférence : Gain de temps
  • Fiabilité : Ces systèmes sont capables, si la base de règle a été faite de manière non ambigue, d'arriver toujours à la même interpretation (déterminisme).
  • Evolution : Pour faire évoluer le système il suffit de faire évoluer la base de règles.

Le gros désavantage de ces système est que la base de règles est écrite par des humains. Ce qui signifie dans la cas de base avec beaucoup de règles, beaucoup de temps à passer pour introduire les règles. Mais aussi, que les règles écrites peuvent être fausses, ambigues, ou être en contradiction entre elles. Ce qui peut avoir pour conséquence un système qui ne fonctionne pas correctement.

Event-Driven Architecture

Fonctionnement

L'Event-Driven Architecture est un pattern d'architecture développé autour des actions suivantes : Produire, détecter, consommer et réagir à des évènements.

C'est une architecture qui s'articule autour d'un bus disposant de fonctionnalités d'abonnement et de publication (Publish/Subscribe) et des services. Les services seront producteurs et/ou consommateurs d'événements qu'ils transmettront au bus pour avertir les services abonnées. Le Bus Publish & Subscribe a donc un rôle de médiateur (middleware) entre émetteurs et consommateurs.

Exemple : Le projet RobAIR2013 est un exemple d'utilisation de l'Event-Driven Architecture. En effet, ce projet utilise ROS comme bus de Publish & Subscribe. Ainsi, le contrôle du robot passe par un noeud de communication qui envoie les événements de contrôle du robot via ROS. Ces événements sont utilisés par le module moteur du robot.

Intêrets

  • Couplage faible : Les services ne 'discutant' entre eux que par l'intermédiaire des événements, ils peuvent être très indépendants les uns des autres, être codés en n'importe quel langage et être exécutés sur n'importe quelle plateforme (matérielle et logicielle).

Ce couplage implique en revanche de mettre en place une forte cohérence interne (par l'utilisation d'un format d'échange pivot, le plus souvent XML).

  • Communication asynchrones : Une grande réactivité du programme grâce aux événements.

Traitements des événements

Il existe trois manières de traiter les événements dans un Event-Driven Architecture.

  • Traitement d’évènements simple : Traitement d'événements simple/ponctuel, comme par exemple un changement déclenché par un capteur.
  • Traitement de flux d’évènements (ESP) : Traitement d'un flux d'information dans lequel on a aussi bien des événements notables que des événemnts 'ordinaires'. Les deux types d'événements sont traités chacuns de leur côté et éventuellement remis dans un flux de sortie.
  • Traitement d’évènements complexes (CEP) : Mélange des deux.

Complex Event Processing (CEP)

CEP
Complex Event Processing

En Complex Event Processing, le système va recevoir un nuage d'événements. Le but du CEP, est d'identifier parmi ces événements lesquels sont significatifs et de les associés entre eux pour voir apparaître des événements complexes. Pour cela, il va effectuer des opérations d'analyse, de déduction et de corélation sur les événements.

On distingue deux types de traitements sur les événements :

  • Calcul orienté : Utiliser les données de chaques événements entrant pour faire des calculs. Par exemple, calculer en permanence une moyenne basée sur les données contenues dans les événements entrants.
  • Détection orienté : Utiliser les événements en eux mêmes. Par exemple, détecter une situation par la reconnaissance d'une séquence spécifique d'événements.

Annexes

Retrieved from "https://air.imag.fr/index.php?title=EA2013_RulesEngines_EventConditionActin_ComplexEventProcessing&oldid=13620"