Event services
Les « event services », ou services événementiels, sont des composants logiciels qui communiquent en émettant et en recevant des événements, selon le modèle de l’architecture orientée événements (en anglais Event-Driven Architecture, EDA). Au lieu d’appeler directement un autre service et d’attendre sa réponse, un service signale qu’un fait s’est produit, et les services intéressés y réagissent. L’expression désigne aussi, dans un autre domaine, les prestations d’organisation d’événements ; cet article traite de son sens en informatique de gestion.
Qu’est-ce qu’un événement ?
Un événement est la notification d’un changement d’état significatif pour l’entreprise : une commande a été passée, un paiement a été reçu, un colis a été expédié, un stock est passé sous un seuil. Il est émis par un producteur, transporté par une infrastructure de messagerie, puis reçu par un ou plusieurs consommateurs qui décident chacun de la suite à donner. Le producteur n’a pas besoin de savoir qui écoute.
Les briques d’une architecture orientée événements
- Les producteurs : applications ou services qui publient les événements.
- Le courtier d’événements (bus ou broker) : intermédiaire qui reçoit, conserve et distribue les événements selon un modèle de publication et d’abonnement. Apache Kafka et RabbitMQ sont des exemples courants de tels outils.
- Les consommateurs : services qui s’abonnent aux types d’événements qui les concernent et lancent les traitements correspondants.
- L’annuaire des services et des événements : catalogue qui répertorie les services, les événements disponibles et leurs contrats, c’est-à-dire la structure exacte des messages. Il donne une cartographie dynamique du système d’information.
EDA et SOA : deux approches complémentaires
Dans l’architecture orientée services (SOA), un consommateur adresse une demande à un service fournisseur et attend sa réponse : l’échange est le plus souvent synchrone, sur le modèle question-réponse. Dans l’architecture orientée événements, un service se contente d’annoncer ce qui s’est passé, de façon asynchrone, et ne dépend pas de la disponibilité de ceux qui réagiront. Les deux approches coexistent souvent dans une même entreprise : la SOA convient aux interrogations précises (consulter un compte client), l’EDA aux réactions en chaîne (déclencher la facturation, la livraison et la mise à jour du stock après une commande).
Avantages
- Faible couplage : on peut ajouter un nouveau consommateur sans modifier le producteur.
- Réactivité : les traitements se déclenchent dès que l’événement se produit.
- Montée en charge : les consommateurs peuvent être multipliés pour absorber les volumes.
- Réutilisabilité et interopérabilité : un même événement sert à plusieurs applications.
Limites à connaître
Cette souplesse a un prix. Comme les traitements sont asynchrones, les différentes parties du système ne sont pas toujours à jour au même instant : on parle de cohérence à terme. Il faut gérer les messages reçus en double ou dans le désordre, en concevant des traitements qui supportent la répétition, et suivre le parcours d’un événement à travers de nombreux services pour diagnostiquer une panne. Une gouvernance rigoureuse des contrats d’événements, tenue dans l’annuaire, évite que la modification d’un message ne casse les consommateurs qui en dépendent.
vous devez être connecter pour déposer un commentaire connecter