Qu'est-ce que l'Event-driven Architecture ?
L'event-driven architecture (EDA) est un modèle de conception logicielle qui permet à une organisation de détecter des « événements » ou des moments importants pour l'entreprise (tels qu'une transaction, une visite du site, l'abandon d'un panier d'achat, etc.) et de les transformer en actions, en temps réel et quasi-réel. Ce modèle remplace l'architecture traditionnelle « demande/réponse » dans laquelle les services devaient attendre une réponse avant de pouvoir passer à la tâche suivante. Le flux de l'event-driven architecture est géré par les événements et est conçu pour y répondre ou pour effectuer une action en réponse à un événement.
L'event-driven architecture est souvent appelée communication « asynchrone ». Cela signifie que l'expéditeur et le destinataire n'ont pas besoin d'attendre l'autre pour passer à la tâche suivante. Les systèmes ne dépendent pas de ce seul message. Par exemple, un appel téléphonique est considéré comme synchrone ou plus proche de l'architecture traditionnelle « demande/réponse ». Quelqu'un vous appelle et vous demande de faire quelque chose, le demandeur attend pendant que le répondant accomplit la tâche, puis les deux parties raccrochent. Un exemple asynchrone serait la messagerie textuelle. Vous envoyez un message et dans certains cas, vous ne savez même pas à qui vous l'envoyez ou si quelqu'un vous écoute, mais vous n'attendez pas de réponse.
L'évolution de l'event-driven architecture
Au cours des dernières années, on est passé de la concentration sur les données au repos (service-oriented architecture) à la concentration sur les événements (event-driven architecture). Nous passons de l'accumulation de données et des lacs de données à la concentration sur les données en vol et à leur suivi pendant qu'elles se déplacent d'un endroit à l'autre. Traditionnellement, la plupart des systèmes fonctionnent dans ce que l'on pourrait appeler le modèle centré sur les données, où les données sont la source de vérité. Le passage à l'architecture événementielle signifie que l'on passe d'un modèle centré sur les données à un modèle centré sur les événements. Dans le modèle événementiel, les données sont toujours importantes, mais les événements deviennent le composant le plus important. Alors que dans le modèle orienté services, la priorité absolue était de s'assurer que l'on ne perdait pas de données. Avec l'event-driven architecture, la priorité est de s'assurer que vous répondez aux événements dès qu'ils se produisent. En effet, il existe une loi des rendements décroissants en ce qui concerne les événements : plus ils vieillissent, moins ils ont de valeur. Cependant, aujourd'hui, les service-oriented architecture et event-driven architecture sont souvent utilisées ensemble.
L'event-driven architecture utilise souvent l'analogie du journal pour garder la trace des choses. Les analystes parlent des événements comme de choses immuables qui se sont produites. Et si vous voulez comprendre ce qui s'est passé dans le passé, vous pouvez revenir en arrière et relire le journal. Alors que dans le modèle centré sur les données, on se concentre principalement sur l'état des données tel qu'il est en ce moment. Enfin, la dernière analogie utilisée par les analystes pour décrire la différence entre les architectures centrées sur les données et les architectures centrées sur les événements est qu'ils les comparent souvent à un référentiel d'informations et à un système nerveux qui transporte les messages dans l'entreprise.
Lorsque vous utilisez une event-driven architecture, vous avez des producteurs d'événements qui génèrent et envoient des notifications d'événements et vous pouvez avoir un ou plusieurs consommateurs d'un événement, où la réception de l'événement déclenche une logique de traitement. Par exemple, disons que Netflix vient de mettre en ligne un nouveau film. Il peut y avoir plusieurs applications qui écoutent ou attendent cette notification et qui déclenchent ensuite leurs propres systèmes internes pour publier leurs propres informations sur cet événement à leurs utilisateurs. La différence avec la messagerie traditionnelle de type demande-réponse réside dans le fait que les applications sont toujours en cours d'exécution et que, même si elles sont à l'écoute de cet événement, elles ne sont pas paralysées par cette attente. Et elles sont en mesure de répondre lorsque le message est publié. Ainsi, de nombreux services peuvent fonctionner en parallèle.
Qu'est-ce qu'un événement ?
Un événement est défini comme le changement d'état d'un système commercial clé. Par exemple, quelqu'un achète un produit, quelqu'un d'autre s'enregistre pour un vol ou un car arrive en retard quelque part. Et si l'on y réfléchit, les événements existent partout et se produisent constamment, quel que soit le secteur d'activité. Ils sont omniprésents dans toute entreprise. Ainsi, tout ce qui crée un message en étant produit, publié, détecté ou consommé est considéré comme un événement. L'événement est distinct du message, car si l'événement est l'occurrence, le message est la notification itinérante qui relaie l'occurrence. Dans une event-driven architecture, un événement est susceptible de déclencher une ou plusieurs actions ou processus en réponse à son occurrence. Voici un exemple d'événement :
- Il est reçu une demande de réinitialisation d'un mot de passe.
- Un paquet arrivé a été livré à sa destination.
- Un entrepôt d'épicerie met à jour son inventaire.
- Une tentative d'accès non autorisé a été refusée.
Chacun de ces événements est susceptible de déclencher une ou plusieurs actions ou processus en réponse. Une réponse peut être simplement d'enregistrer l'événement à des fins de surveillance. D'autres pourraient être :
- Un e-mail de réinitialisation du mot de passe est envoyé au client.
- Le ticket de vente est fermé.
- Une commande de laitues supplémentaire (ou de tout autre produit en voie d'épuisement) est placée.
- Un compte est verrouillé et le personnel de sécurité en est informé.
Avec une event-driven architecture, lorsqu'une notification d'événement est envoyée, le système saisit que quelque chose s'est produit, comme un changement d'état, et attend d'envoyer la réponse à la personne qui l'a demandée, quand elle l'a demandée. L'application qui a reçu ce message peut soit répondre, soit attendre de répondre jusqu'à ce que le changement d'état qu'elle attend se produise.
Les applications construites autour d'une event-driven architecture permettent des applications commerciales numériques plus agiles, plus évolutives, plus contextuelles et plus réactives.
Comment fonctionne l'event-driven architecture ?
Une event-driven architecture peut comprendre trois parties : le producteur, le consommateur et le courtier. Le courtier peut être facultatif, en particulier lorsque vous avez un seul producteur et un seul consommateur qui sont en communication directe l'un avec l'autre et que le producteur envoie simplement les événements au consommateur. Un exemple serait un producteur qui envoie uniquement les événements à une base de données ou à un entrepôt de données afin que les événements soient collectés et stockés pour être analysés. Le plus souvent, dans les entreprises, vous avez plusieurs sources qui envoient tous les types d'événements avec un ou plusieurs consommateurs intéressés par certains ou tous ces événements.
Prenons un exemple. Si vous êtes un détaillant, vous recueillez peut-être tous les achats effectués dans tous vos magasins du monde entier. Vous les introduisez dans votre event-driven architecture qui surveille les fraudes et les envoie à un processeur de carte de crédit ou prend toute autre action nécessaire. Dans le cas d'un fabricant, vous disposez de toutes sortes de données provenant de vos équipements qui vous indiquent des faits tels que la température et la pression, de sorte que vous pouvez surveiller ces événements en temps réel et prendre des mesures telles que la prévision des pannes ou la programmation de l'entretien, en fonction de ce que les données vous indiquent.