Un programme émetteur ou consommateur de notifications d’évènements est un paradigme d’architecture logicielle, nommé une architecture basée sur les évènements (event-driven architecture, EDA). Le terme « notifications d’évènements » est plus approprié que « évènement », car il y a un système de transfert de données (les évènements). L’EDA donne essentiellement un couplage lâche entre les composants (quasiment pas d’interaction entre eux). Il offre des possibilités de haute performance (multithreading ou scalabilité horizontale), de haute tolérance aux pannes (continue à fonctionner malgré des erreurs), ou d’interopérabilité (fonctionne avec beaucoup de produit). Il peut compléter une architecture orientée service en déclenchant les services à partir d’évènements.
Ce paradigme repose sur des évènements choisis volontairement dans une application, comme un client qui reçoit un document à signer dans son espace, et sur la distribution des évènements aux consommateurs pour agir, par exemple un qui envoie un SMS et un autre qui envoie un mail.
Les émetteurs d’évènement détectent (requiers une signature dans l’exemple) et recueillent (un évènement de type document à signer) les évènements, puis les transfèrent dans un canal, une voie de communication. Isolés, ces agents ne savent pas qui reçoit l’évènement (peut-être aucun), et quelles actions sont déclenchées par la suite. De l’autre côté, les consommateurs d’évènement ou éviers agissent ou réagissent dès qu’un évènement survient. Ils peuvent exécuter entièrement une action ou alors transférer l’évènement à un autre consommateur après un filtrage et une transformation. Entre les agents et les éviers, il y a les canaux d’évènement. Ils savent distribuer les évènements entre les émetteurs et les consommateurs.
Il existe deux topologies dans l’EDA. Dans une topologie broker, la communication entre les composants n’utilise pas d’orchestrateur. Il faudra transmettre les évènements avec une solution personnalisée. Avec l’aide de Spring Application Events en Java par exemple. À l’inverse, la topologie mediator utilise un orchestrateur qui contrôle et achemine les évènements, à l’instar d’un intergiciel à messages (message-oriented middleware).
Les EDA sont plus ou moins complexes. Une application peut simplement générer quelques évènements importants, et les consommateurs agissent immédiatement dans leur contexte. Il peut y avoir beaucoup plus d’évènements, ordinaires et importants, pour être contrôlé et trié directement dans les canaux. Plus compliquées, des techniques de corrélation peuvent s’ajouter afin de détecter des évènements « complexes ». Plusieurs styles pour choisir ce puissant paradigme…
