L’architecture orientée événements

L’EDA (Event Driven Architecture, pour Architecture Dirigée par les Événements) est un type d’architecture de SI dans lequel certains composants sont dirigés par les événements et communiquent au moyen des événements. Les architectures EDA ont été popularisées avec l’apparition de standards pour les places de marchés et les systèmes de vente aux enchères.

De par sa nature, une architecture dirigée par les événements est couplée de façon extrêmement lâche et est hautement distribuée [Michelson, 2006] [Josuttis, 2007]. Le créateur (source) de l’événement sait seulement que l’événement est apparu. Le créateur n’a aucune connaissance du traitement ultérieur de l’événement ou des parties intéres- sées, dans le sens où il ne sait pas quels sont les consommateurs finaux de l’événement qu’il a généré. D’autre part, les consommateurs de l’événement s’abonnent aux types d’événements qui les intéressent : or les instances de ces types d’événements peuvent être des événements dérivés. Les consommateurs n’ont aucun moyen de savoir si l’évé- nement qu’ils consomment est un événement « original » simplement filtré ou s’il est dérivé. La traçabilité d’un événement à travers un réseau multi événements dynamique peut être difficile dans ce contexte. Ainsi, les architectures dirigées par les événements sont mieux utilisées pour les flux asynchrones de travail et d’information. Le couplage entre services est un couplage lâche et les communications sont toutes asynchrones.

Figure II.13 – Principe du mécanisme Publication/Souscription [Maréchaux, 2006] L’EDA utilise les échanges de messages peut permettre à deux processus ou plus de communiquer ensemble. La communication est initiée par un événement. Ce déclencheur correspond typiquement à une occurrence métier quelconque. Tous les abonnés au type d’événement correspondant à l’instance émise sont alors notifiés et donc activés. C’est ce qu’on appelle le mécanisme Publish/Subscribe (Publication/Souscription) de l’EDA, représenté dans la Figure II.13.

La Table II.5 résume les propriétés fondamentales d’une architecture dirigée par les événements.

Propriété Description

Couplage lâche Les producteurs (sources) d’événements ne sont pas au cou- rant de l’existence de leurs abonnés

Communication n-m Le mécanisme Publication/Souscription permet qu’un seul événement spécifique puisse avoir un impact sur plusieurs abonnés

Déclencheur basé sur les événements

Le flux de contrôle est déterminé par le destinataire, sur la base de l’événement reçu

Asynchrone Les opérations asynchrones sont rendues possibles via les

événements

Table II.5 – Principales caractéristiques de l’EDA

Le Complex Event Processing Le CEP (Complex Event Processing, pour Traite-

ment d’Événements Complexe) est une technologie de réseau émergente8 _{qui déclenche}

des actions et créé de la connaissance à propos de la situation à partir de systèmes dis- tribués basés sur les messages, de bases de données et d’applications en temps réel. Le CEP s’occupe de l’évaluation d’une confluence d’événements et d’une prise de mesures, sur des périodes temporelles (ou fenêtres) de durées variables. Cette corrélation d’événe- ments peut être causale, temporelle, ou spatiale. Le CEP requiert l’emploi d’interprètes d’événements sophistiqués, de définition de motifs et de correspondance d’événements. Le CEP est communément utilisé au sein des organisations pour détecter et répondre aux anomalies métiers, aux menaces et opportunités en surmontant la complexité et l’hétérogénéité de leurs réseaux.

Notons que le CEP fait généralement référence au traitement des événements qui sup- pose un nuage d’événements9_{comme entrée, et ne peut donc faire aucune hypothèse sur}

l’ordre d’arrivée des événements, contrairement à un flux d’événements10_.

La Figure II.14 résume les principaux concepts du CEP [Fülöp et al., 2010]. Les mêmes concepts peuvent s’appliquer à l’Event Stream Processing, en remplaçant le nuage d’événements par un flux continu d’événement, et un traitement continu des événements. Le traitement des événements s’applique sur un Système d’Information, qui est capable de recevoir des événements. Ces événements proviennent du monde extérieur à travers des capteurs, un ERP, une CRM, etc. (exemples : décollage d’un avion, arrivée d’un

8. Définie pour la première fois comme telle par David Luckham dans les années 90.

9. Un nuage d’événements est un ensemble d’événements partiellement ordonné, qu’il soit borné ou non, où les ordres partiels sont imposés par la causalité, le temps ou tout autre relation entre les événements.

10. Un flux d’événements une séquence ordonnée et linéaire d’événements (de type potentiellement différents). Habituellement, les flux sont ordonnés par le temps, par exemple l’heure d’arrivée.

Figure II.14 – Concepts de CEP d’après [Fülöp et al., 2012]

bus, confirmation d’une commande, une alerte aux orages dans une prévision météorolo- gique, etc.) mais aussi du SI lui-même (exemples : réalisation d’une activité, production d’un rapport, etc.). Ces événements sont récupérés sous forme de nuage par les EPA qui vont (par exemple) les filtrer avant de les transmettre au moteur qui va traiter les événements. Si un motif d’événements ou une règle sont satisfaits par les événements entrants, le moteur le notifie à l’administrateur (ou à un composant du SI) qui réagira en conséquence. Cette notification (dans notre cas) se fait grâce à l’émission de nouveaux événements émis par le moteur de CEP, suite au déclenchement des motifs d’événements ou des règles.

L’intérêt de la mise en place d’une architecture EDA faisant appel à un moteur CEP est donc de pouvoir découvrir de nouvelles données en identifiant les événements signifi- catifs dans le nuage d’événements générés par le SI et le monde extérieur. Par déduction, analyse et corrélations de ces événements, le CEP peut créer des événements complexes qui mettent en valeur cette découverte de données. Ces événements sont dits complexes

car on ne peut pas les détecter directement dans la situation observée : c’est la combi- naison d’autres événements qui permet de les révéler.

Par exemple, dans une forêt, plusieurs stations de mesures météorologiques sont dissé- minées : elles mesurent la température de l’air ambiant, la vitesse et la direction du vent, et ont chacune une position GPS précise. En début de matinée, 10 capteurs situés au nord de la forêt génèrent les événements : « Température air ambiant supérieure à 80 degrés Celsius », « Vent fort direction sud-ouest ». La combinaison de ces événements —température anormale dans le secteur nord à cette heure de la journée, vent fort— permet de détecter deux nouveaux événements qui sont « Incendie de forêt au nord » et « Risque de propagation au sud-ouest ». Ces deux événements sont des événements complexes. Même s’il n’y a pas d’observation directe du fait que les flammes commencent à dévorer le nord de la forêt (comme pourrait le permettre une observation par un être humain sur les lieux, une photo, une vidéo surveillance, etc.), il a été possible de déduire la situation par la combinaison d’autres événements et de faire état de cette situation en générant des événements complexes.

Ces événements complexes sont mis à disposition des parties intéressées (les utilisa- teurs et le SI) qui vont exploiter ces données afin de réagir en temps réel.

L’EDA et le CEP trouvent donc tout naturellement leur intérêt dans le cas de nos travaux. La capacité de déduction d’une nouvelle situation à partir d’événements simples permet d’obtenir des données plus intéressantes et pertinentes au regard des besoins des utilisateurs et du SI concerné. Cet apport de nouvelles données qui sont de fait filtrées, triées, analysées permet d’alimenter les représentations de la situation collaborative à un instant t, à travers la mise à jour des modèles terrain et attendu.

Les Event Processing Languages et les moteurs associés Qu’il s’agisse d’ESP

ou de CEP, habituellement un EPE (Event Processing Engine, pour Moteur de Trai- tement des Événements) est utilisé dans l’infrastructure. Les événements sont fournis à l’EPE par les EPA, qui vont par exemple filtrer les événements. Ensuite, l’EPE va traiter les événements et éventuellement notifier à l’administrateur de l’EPE l’existence de correspondances avec des motifs ou des règles (établies au préalable par l’adminis- trateur). Ce motif ou cette règle peut être définie dans un langage de traitement des événements et via lequel on peut s’abonner à certains motifs d’événements. Quand il est notifié par l’EPE de la détection de certains motifs d’événements, l’administrateur exécute les actions appropriées sur le système d’information. Ces actions peuvent être automatisées en utilisant le modèle d’ECA (Event Condition Action), dans lequel l’action est automatiquement réalisée sur le système d’information si la condition est vraie.

Les EPAs peuvent être exprimés dans de nombreux EPL (Event Processing Lan- guage, pour Langage de Traitement d’Événements). A l’heure actuelle, de nombreux types d’EPL coexistent. On y trouve [Etzion and Niblett, 2010] :

• Les langages de règles. Ici, plusieurs types de règles sont recouverts par ces lan- gages :

— Les règles de production, ou d’inférence [Vianu, 1997]. Ce type de règles est utilisé pour représenter les comportements de type SI condition ALORS ac-

tion. Les règles s’enchaînent en cascade et la conclusion (action) résultant

d’une règle n devient la condition de la règle n + 1 (principe du chaînage avant). Si ces règles sont normalement basées sur les changements d’état et non sur les événements, certains langages les étendent et permettent le traite- ment des événements. Les événements sont alors modélisés comme des parties des conditions des règles. Le traitement des événements se fait à travers un processus d’inférence. Exemple : Drools Rule Language (qui se base sur l’al- gortihme RETE), TIBCO Business Events.

— Les règles actives, aussi connues sous le nom de règles ECA (Event Condition Action). Les moteurs de règles actives détectent et réagissent aux événements entrants et exécutent des motifs d’événements. Exemple d’EPL basé sur les règles ECA : IBM WebSphere Business Events, RAPIDE,

— Les règles basées sur la programmation logique. La programmation logique est un style de programmation basé sur les assertions logiques (Prolog est le langage de ce type le plus connu). Exemple d’EPL relevant de cette catégorie : ETALIS.

• Les langages de programmation impératifs : les opérations sont décrites en termes de séquences d’instructions élémentaires exécutables par le processeur pour mo- difier l’état du programme. Il s’agit du type de programmation le plus répandu parmi l’ensemble des langages existants. Exemples : FORTRAN, COBOL, BA- SIC, Pascal, C, Ada, Perl, Python, PHP, Java (liste non exhaustive). Ces langages peuvent servir d’EPL,

• Les langages orientés flux qui sont des extensions de SQL (et souvent vaguement basés sur SQL), aussi appelés Streaming SQL. Ils permettent d’effectuer des re- quêtes sur les flux d’événements. Exemples : Esper EQL (Event Query Language), Oracle CQL (Continuous Query Language), CCL (Continuous Computation Lan- guage).

• D’autres langages orientés flux mais non typés SQL. Exemple : SPADE ( [Gedik et al., 2008]).

Les langages de type Streaming SQL représentent la plus grand part des EPL à l’heure actuelle.

Le choix d’un EPL n’est pas trivial. Si certains spécialistes tels Luckham persistent et arguent qu’un seul EPL est valable parmi ceux existants (ex. : Rapide a la préférence de Luckham)11_{, d’autres spécialistes tels qu’Etzion sont beaucoup plus nuancés et préfèrent}

penser que le choix qu’un EPL dépend essentiellement des besoins et des contraintes de l’environnement concerné par le choix de l’EPL [Etzion, 2008]. Il faut également que l’EPL soit compatible avec un moteur de CEP. Cela va relativement de soi quand on choisit un EPL commercial (on achète le moteur de CEP qui est livré avec son EPL), 11. On peut douter de l’impartialité de Luckham dont le choix est quelque peu biaisé puisque Luckham a dirigé le groupe de travail de Stanford qui a développé Rapide.

mais est moins évident dans le cas des EPL académiques où certaines initiatives n’ont pas été implémentées.

Dans notre cas (travaux de thèse), un EPL open source et gratuit, qui soit compatible avec un CEP lui-même libre et gratuit, et toujours maintenu sont nos critères majeurs de choix. Nous avons effectué un comparatif des solutions existantes (voir Annexe C). En regardant de plus près les différents EPL et CEP cités dans notre comparatif, seul Esper EQL et son implémentation dans Esper Engine répondaient à ces critères au moment du lancement du développement du prototype en 2011. En outre, la possibilité de décrire les événements à l’aide d’objets Java ou de flux XML était un atout appréciable afin de faciliter l’intégration du CEP avec les autres composants du prototype (ESB, abonnement aux événements, etc.).