Définissez votre architecture logicielle grâce aux standards reconnus

Dans ce chapitre, nous allons aborder l'architecture pilotée par les événements (event-driven architecture) et les situations où c’est la solution parfaite. À la fin du chapitre, je vous montrerai un exemple concret (RNC), puis vous résoudrez un cas similaire en appliquant ce que vous avez appris. C’est parti !

Qu'est-ce que l'architecture pilotée par les événements ? 

Avez-vous déjà voulu acheter quelque chose sur un site pour vous rendre compte que l'article en question dépassait largement votre budget ? Heureusement, certains sites web proposent de vous envoyer une alerte lorsque le prix d'un article baisse en dessous d’une certaine valeur. Il suffit d'ajouter une alerte sur le site web : « Si l'article atteint le prix X, veuillez m'en informer. » C'est comme si on disait au site : « Si l’événement X se produit, alors faites ceci. »

L'architecture pilotée par les événements fonctionne selon le même principe : elle produit, détecte et agit selon les événements du système pertinents pour les utilisateurs. Si aucun événement ne se produit, rien ne se passe dans le système. Cette architecture définit ces événements indispensables comme des déclencheurs. Lorsque ces déclencheurs s’activent, ils provoquent des comportements spécifiques, comme l'envoi d'une alerte lorsque le prix de l'article que vous voulez baisse.

En général, les clients indiquent pour quels types d’événements ils veulent être informés, et ce qu'ils veulent que le système fasse quand ces événements se produisent. Par exemple :

• Si le prix de l'action X atteint 40 $ (déclencheur), veuillez m'envoyer un courriel (comportement).

• Si, dans notre entreprise, un vendeur saisit un bon de commande (déclencheur), alors affichez un message sur l'écran initial du gestionnaire de dépôts lorsqu'il se connecte au système (comportement).

• Si un client achète un billet sur notre compagnie aérienne pour un vol donné et que le paiement est approuvé (déclencheur), il faut immédiatement marquer le siège réservé sur le vol correspondant comme « occupé » (comportement).

Quelle est la structure de l'architecture pilotée par les événements ? 

Voyons à quoi cela ressemble :

Comme vous pouvez le voir dans le diagramme ci-dessus, une architecture pilotée par les événements habituelle comporte au moins les composants suivants :

• Le bus d'événements (Event Bus) : Il s'agit d'une ligne de communication qui relie tous les utilisateurs aux événements. Cette ligne n'est pas un câble physique mais fait référence à une connexion logique, similaire à celle qui existe entre votre ordinateur portable et un site web que vous visitez. Les événements sont transportés par ce bus d'événements abstrait et atteignent tous les utilisateurs du système. Le bus n'existe pas réellement, mais il sert à décrire l'échange de données entre de nombreux composants ou utilisateurs. 

• Le canal d'événements (Event Channel) : Un canal d'événements est une étiquette pour le type d'événements auxquels les utilisateurs s'abonnent. Par exemple, le canal « ventes » publiera tous les événements concernant les ventes à tous les utilisateurs abonnés. Sur Twitter, un hashtag comme #awesomejapan est un canal qui rassemble tous les tweets publiés par d'autres utilisateurs et contenant ce même hashtag. Si un utilisateur est abonné à un canal donné, il recevra tous les messages qui s'y rapportent. 

• Le traitement des événements (Event Processing) : Toutes les actions entreprises après un événement donné sont exécutées dans le module de traitement des événements. Ce module agit selon un événement donné pour servir l'utilisateur. Par exemple : « Si je reçois ce type de message, faites ceci », ou de façon plus concrète : « Si je reçois un message de nouvel achat, alors facturez le client ».

Comment cela fonctionne-t-il en pratique ? Reprenons nos exemples précédents et examinons comment une architecture pilotée par les événements prend en charge leur fonctionnalité :

• Si le prix de l'action X atteint 40 $, envoyez-moi un e-mail. Comment cela se passe-t-il ? L'utilisateur dispose d'une liste d'actions pour lesquelles il souhaite recevoir une notification. L'utilisateur choisit l'action X et sélectionne une condition (supérieur à 40 $). L'utilisateur sélectionne une option dans un menu des possibilités comme « Envoyez-moi un e-mail », « Alertez-moi lorsque je me connecte au système », « Envoyez-moi un SMS », etc. Lorsque l'événement correspondant se produit, il est publié dans le bus d'événements, le système y réagit et les utilisateurs abonnés reçoivent un message.

• Si, dans notre entreprise, un vendeur saisit un bon de commande, alors affichez un message sur l'écran initial du gestionnaire de dépôts lorsqu'il se connecte au système. Comment cela se passe-t-il ? Il existe un canal préexistant dans le système appelé « Purchase_Orders » (Bons de commande). Les utilisateurs qui ont besoin de savoir qu'un nouvel achat a été effectué (gestionnaire des stocks, responsable du marketing, responsable de la logistique, etc.) sélectionnent une option « S'abonner aux canaux » dans un menu et voient tous les canaux possibles prédéfinis par le système. Ils sélectionnent le canal auquel ils veulent s'abonner. Lorsque l'événement correspondant se produit, il est publié dans le bus d'événements, et les utilisateurs abonnés reçoivent un message.

• Si un client achète un billet sur notre compagnie aérienne pour un vol donné et que le paiement est approuvé, il faut immédiatement marquer le siège réservé sur le vol correspondant comme « occupé ». Comment cela se passe-t-il ? Il existe un canal préexistant dans le système appelé « New_Ticket » (Nouveau Billet). Les utilisateurs qui ont besoin de savoir qu'un nouveau billet a été acheté (responsable des opérations, personnel d'assistance au sol, etc.) sélectionnent une option « S'abonner aux canaux » dans un menu et ils voient tous les canaux possibles prédéfinis par le système. Ils sélectionnent le canal auquel ils veulent s'abonner. Lorsqu'un billet est vendu, il est publié dans le bus d'événements et le système y réagit.

 L'utilisation d'une architecture pilotée par les événements présente plusieurs avantages :

• Si vous avez des utilisateurs qui ont besoin d'écouter (de s'abonner à) différents messages sur un sujet spécifique, l'architecture pilotée par les événements est la bonne approche. Cela se produit lorsque le système doit réagir à des événements sans comportement prédictif : par exemple, si je m'abonne à la chaîne « Informations africaines », je n'ai aucun contrôle sur les actualités que je recevrai ni sur leur quantité. Le système n'est pas prédictif ; il réagit aux événements générés par d'autres utilisateurs.

• Si ces utilisateurs sont en dehors de l'organisation, les événements peuvent être transportés dans un bus d'événements publics et atteindre tous les utilisateurs immédiatement.

• De nombreux événements peuvent être traités en même temps, voire des millions.

Il existe également quelques inconvénients majeurs :

• Le bus d'événements peut être surchargé. 

• Si le bus d'événements tombe en panne, tout le système tombe en panne.

• Il n'y a pas de contrôle du flux d'événements : de nombreux événements peuvent se produire en même temps, créant un véritable chaos pour les utilisateurs.

Quand utiliser l'architecture pilotée par les événements ? 

Voici quelques situations où cette architecture peut être utile :

Étude de cas : Résoudre un problème d'entreprise avec l'architecture pilotée par les événements 

Analysons un cas réel où l'architecture pilotée par les événements est utilisée.

RNC est une agence de presse. Voici quelques généralités :

• RNC emploie plus de 12 000 journalistes qui produisent des actualités, des articles et des informations vendus sous forme d'abonnements à des entreprises et des particuliers du monde entier. 

• RNC est une entreprise véritablement mondiale : elle peut atteindre n'importe quel pays ou région du monde en quelques heures si une couverture médiatique est nécessaire.

• Les informations peuvent être réparties en différentes catégories. L'entreprise met en place un système de gestion de contenu pour améliorer la gestion des catégories. Les clients s'abonnent et paient pour ces catégories d’informations et reçoivent un flux constant de mises à jour sur Internet.

• Les catégories peuvent être relatives à des régions : un pays ou une ville spécifique, un continent, un groupe de pays.

• Elles peuvent être classées par thème, par exemple les actualités scientifiques, et elles peuvent être divisées en sous-thèmes : science-médecine, science-physique, etc. 

• Les clients signent un contrat de 12 mois pour recevoir en temps réel les informations liées à une catégorie spécifique.

Quelle est la problématique de l'entreprise ?

RNC doit améliorer la manière dont les informations sont transmises à ses clients dans le monde entier. Le système actuel présente deux problèmes principaux :

1. Des milliers de nouvelles sont produites chaque heure. Le système actuel est lent pour traiter les sujets d'actualité, ce qui retarde la transmission aux clients d'environ cinq minutes.

2. Chaque journaliste doit étiqueter les informations produites avec un groupe de catégories auxquelles elles sont liées. La règle pour ajouter des étiquettes n'est ni claire ni appliquée. Par conséquent, de nombreuses informations parviennent au système avec seulement une seule catégorie, voire aucune. L'information est alors généralement perdue, puisque, sans catégorie, l'utilisateur ne pourra pas y accéder.

Nous devons utiliser une architecture qui prendra en charge ces besoins commerciaux.

Parfait ! La quantité de données est faramineuse, c’est ce qui constitue le véritable problème :

• Les catégories d’informations sont nombreuses, variées et susceptibles de changer au fil du temps. 

• Il y a plus de 12 000 journalistes qui produisent (probablement) de nombreuses actualités. 

• Plus de 120 000 clients sont abonnés à une offre payante (mensuelle).

Nous avons trois facteurs essentiels :

1. Les catégories.

2. Les journalistes produisant des informations.

3. Les clients qui veulent être informés. 

Une architecture pilotée par les événements est parfaite dans cette situation, car elle relie naturellement ces trois acteurs par le biais de canaux d'événements et d'abonnements, au lieu de devoir prévoir toutes les combinaisons imaginables (ce qui représenterait des millions de possibilités !). 

Dans ce type de système, toutes les catégories sont prédéfinies, et aucun article ne peut être écrit sans étiquette. Cela réduit la quantité de données à gérer (car il n'y a pas de nombre infini de catégories) et c’est plus facile à coder car la portée est limitée. Ainsi, tout ce que le journaliste doit faire est de classer l'information dans au moins une catégorie, celle-ci est alors transmise à tous les utilisateurs abonnés.

Les journalistes génèrent des événements (« J'ai écrit une information dans la catégorie Science-Médecine ») et ils les envoient sur un canal (Science-Médecine). Les clients signent des contrats de service pour être abonnés à un canal. Le client peut alors voir dans son navigateur un flux de canaux contenant des informations en temps réel sur les catégories auxquelles il est abonné.

La véritable amélioration pour RNC serait de produire et de vendre des actualités de la même manière : en les associant à un canal.

Donc, pour résumer :

• Nous savons que nous avons des journalistes, des actualités et des clients.

• Nous savons que certaines informations ne sont pas classées correctement.

• Nous savons que les actualités peuvent avoir du retard avant d’être transmises aux clients.

Quelle est la solution ?

Maintenant que nous avons réfléchi au processus, voyons le schéma d'architecture détaillé :

Détaillons chaque composant du système de gestion de contenu :

• Le bus d'événements : Il s'agit d'une ligne de communication qui relie tous les utilisateurs aux événements. Les événements sont transportés par ce bus d'événements et atteignent tous les utilisateurs du système. Chaque nouvelle information est un événement ; le bus d'événements transporte cette information et la transmet aux utilisateurs qui se sont abonnés à un sujet (canal).

• Le canal d'événements : Un canal d'événement est une étiquette pour certaines catégories d’informations auxquelles les utilisateurs s'abonnent. Par exemple, si un utilisateur souhaite recevoir toutes les informations sur l'Afrique du Sud, il s'abonne au canal « Afrique du Sud ». Chaque information étiquetée « Afrique du Sud » par le journaliste qui l'a écrite est transmise à cet utilisateur.

• Les clients : Ce sont les utilisateurs qui s'abonnent à des canaux et reçoivent les messages correspondants.

Essayez vous-même ! 

Maintenant que vous avez découvert une solution, voyons si vous pouvez appliquer ce que vous avez appris à un autre cas !

Le contexte : Vous travaillez pour un grand courtier en bourse. Vous êtes architecte logiciel et votre patron est Linda, la directrice des systèmes d'information (DSI) de l'entreprise.

Votre mission : On vous a demandé de développer un système logiciel pour gérer les alertes sur les cours de bourse. Ces alertes sont envoyées aux clients.

Voici quelques questions essentielles que vous devriez vous poser : 

1. Les clients définissent les alertes qu'ils souhaitent recevoir, par exemple : « Si l'action X dépasse 40 euros, envoyez-moi un e-mail ». Comment cela peut-il être fait efficacement ?

2. Il existe des milliers d'actions négociées sur le marché. Comment gérer un nombre aussi élevé d'alertes boursières potentielles ?

Pouvez-vous créer un schéma d'architecture pour ce contexte commercial ?

En résumé