Quand choisir les approches event-driven ou message-driven

L’approche message-driven

Les systèmes logiciels modernes dépendent d’architecture distribuées qui fonctionnent sur de nombreux points de terminaison et se connectent via des réseaux d’envergure. Prenons l’exemple d’un client d’une compagnie aérienne qui achète un billet via un navigateur Web. Cette commande peut passer par une API, puis par une série de processus qui renvoient un résultat. La notion de messagerie est souvent utilisée pour désigner ces communications en aller-retour.

Dans une architecture de messaging, ces appels d’API ressemblent beaucoup à des appels de fonction : L’API sait avec quel service elle communique, puis s’attend à un certain résultat. Lorsque le célèbre informaticien Alan Kay a affiné le concept de programmation orientée objet, il s’est concentré sur la messagerie dans le cadre de sa définition. Selon Alan Kay, un message doit contenir les quatre éléments suivants :

• L’identité de l’objet qui reçoit l’appel ;
• le code à exécuter par le destinataire ;
• les arguments pour le code ; et
• la valeur renvoyée.

L’approche event-driven

Cependant, les interactions entre les services et les composants applicatifs sont souvent beaucoup plus complexes. Par exemple, si un pilote n’est pas en mesure d’effectuer la dernière étape d’un vol, la compagnie aérienne peut être amenée à réacheminer les avions, à trouver un nouveau personnel navigant et à gérer les clients dont les billets ont été annulés et replacés. Il peut même s’agir d’émettre des bons de repas et d’hôtel aux passagers qui attendent leur vol toute la nuit, par le biais du système de billetterie de la compagnie ou d’une application mobile.

Nous pouvons appeler ces séries complexes de processus et de transactions des événements. Lorsqu’un système enregistre un événement, il ajoute simplement une note à une file d’attente – ou à un bus de messagerie. Les applications concernées peuvent accéder à ces messages, traiter l’événement associé et, si nécessaire, consulter les anciens événements.

Par exemple, une interface utilisateur pilotée par événements n’a pas de contrôle de flux à proprement parler. Au lieu de cela, des objets tels que des boutons, des menus et des images envoient des notifications lorsque certains événements se produisent. Cliquer sur un bouton peut appeler la méthode onBtnCommand() ; passer la souris invoquera la méthode onImgHover(). L’ordinateur attend qu’un événement particulier se produise, puis exécute le code associé.

De même, dans une architecture orientée événements, un programme notifie aux composants logiciels intéressés que quelque chose s’est survient. Le système événementiel est asynchrone et non bloquant : il permet d’envoyer un message, de passer à autre chose et de se concentrer sur la tâche à accomplir.

Un exemple de système message-driven

Dans une architecture frontale orientée services (SOFEA), les pages Web sont définies en HTML et CSS, mais les données fonctionnelles sont récupérées séparément du serveur. Par exemple, le code JavaScript front-end peut effectuer un appel API qui demande une fonction et attend le résultat.

Cela peut être une requête pour obtenir un identifiant d’utilisateur, une adresse mail ou tout autre élément du profil de l’usager. Des appels API similaires pourraient demander des éléments tels que les résultats d’une recherche, une page de produit particulière ou le contenu actuel d’un panier. Si la page Web peut toujours afficher le GUI en attente, elle ne sera pas en mesure d’exposer le nombre ou la liste des articles dans le panier d’achats tant que l’appel de fonction ne renvoie pas les données.

Dans un cas comme celui-ci, le navigateur Web fait office de système de messagerie. L’authentification peut se faire par le biais d’en-têtes, d’API d’authentification open source ou d’options hébergées, telles que Google Identity ou Facebook Login. Les messages sont formatés pour les protocoles REST et HTTP.

Un exemple de système event-driven

Alors que les actions telles que la recherche, l’affichage des produits et la récupération de paniers d’achats dépendent souvent de communications simples et individuelles, un processus de commande nécessitant une transaction par carte de crédit ne l’est pas forcément. Lorsque cette transaction est effectuée, elle doit se refléter dans un système comptable, un data warehouse et tout autre entrepôt physique nécessaire à la préparation de la commande. L’entreprise peut également disposer de tout un ensemble de conditions pour suivre le colis, comme « reçu », « assemblé », « livré », etc.

Dans le cas d’un processus de commande, une API pourrait déposer une notification d’événement dans un bus de services d’entreprise (ESB) centralisé. Les sous-systèmes connectés à cet ESB s’abonnent à ces notifications et sont ainsi informés de l’apparition d’un nouvel événement. Lorsqu’un système d’entrepôt marque un produit comme « assemblé », le logiciel d’inventaire s’adapte en conséquence, tandis que le système de suivi peut désormais capter l’événement et transmettre des mises à jour sous forme de messages.

Event-driven ou message-driven : comment choisir

L’approche axée sur les messages présente autant d’avantages et d’inconvénients que l’approche orientée événements, mais chacune d’entre elles est propice à certains cas d’usage.

Les messages ressemblent beaucoup aux modèles de programmation classiques : appeler une fonction, attendre un résultat, l’exploiter. En plus d’être bien connue de la plupart des programmeurs, cette structure peut également faciliter les corrections. Autre avantage, les messages sont « bloqués », ce qui signifie que tous les appels et réponses attendent leur tour pour être traités par le destinataire. Les événements, quant à eux, se contentent de faire leur marque dans la file d’attente et permettent aux destinataires de les traiter à leur convenance, tout en passant à l’appel suivant dans la chaîne. Cela apporte beaucoup de souplesse et de rapidité lorsqu’il s’agit de gérer et d’exécuter des volumes de transactions importants.

Si les communications se font généralement de manière individuelle et que la réception de mises à jour ou de confirmations régulières est une priorité, il est préférable d’opter pour une approche basée sur les messages. Toutefois, si les interactions entre les systèmes sont particulièrement complexes et que les retards causés par les confirmations et les mises à jour d’état rendent leur attente irréaliste, une conception orientée événements pourrait être plus appropriée.

Gardez à l’esprit que la plupart des grandes organisations finiront par adopter une stratégie hybride, avec certains appels vers les clients/API utilisant des messages et l’entreprise elle-même utilisant des événements. Considérer qu’il est futile de se familiariser aux deux technologies serait malvenu.