Architecture événementielle
Dans une architecture événementielle, des composants signalent des événements auxquels les autres peuvent réagir indépendamment.
Un changement déclenche d’autres tâches
L’architecture événementielle organise la collaboration par des événements : des notifications de faits déjà survenus. Les producteurs les publient ; les consommateurs intéressés les traitent via un canal d’événements. Dans un exemple fictif, une application signale l’approbation d’un devis. La planification et le reporting peuvent réagir par des tâches différentes.
Le producteur n’a pas à appeler directement chaque destinataire. Ce découplage exige cependant un sens clair pour les événements, des responsabilités et une gestion des erreurs. Les doublons, retards et questions d’ordre peuvent compter. La publication d’un événement ne prouve pas que tous les travaux suivants sont terminés. Pour un flux simple, un appel direct peut entraîner moins de travail d’exploitation.
Sources
Termes associés
- Cohérence à termeLa cohérence à terme autorise des états de données temporairement différents qui doivent converger dans les conditions prévues.
- Courtier de messagesUn courtier de messages accepte les messages et les achemine vers les destinataires selon des règles définies.
- Publication-abonnementLa publication-abonnement distribue les messages publiés aux abonnés intéressés sans que l’émetteur contacte chacun directement.
- Inbox transactionnelleUne inbox transactionnelle utilise des enregistrements durables de messages pour protéger le traitement local contre les livraisons en double.
- Acquittement de messageUn acquittement indique au courtier de messages qu’une livraison a été reçue ou traitée selon la règle convenue.
- Délai aléatoire avant réessaiLe jitter fait varier aléatoirement les délais pour étaler les nouvelles tentatives de plusieurs clients.
Articles sur le sujet
Interfaces & intégration avec ASES
ERP, CRM et boutique bien connectés