Architecture orientée événements
L'architecture orientée événements (de l'anglais event driven architecture, ou EDA) est une forme d'architecture de médiation qui est un modèle d'interaction applicative mettant en œuvre des services (composants logiciels) répondant à des sollicitations externes :
- avec une forte cohérence interne (par l'utilisation d'un format d'échange pivot, le plus souvent JSON ou XML),
- et des couplages externes lâches (par l'utilisation d'événements)
Par opposition à l'architecture orientée services (SOA) où un « fournisseur » rend un service à la demande d'un consommateur; en architecture EDA, un composant prévient par émission d'un événement qu'il a réalisé une opération donnée. C'est aux Clients potentiels de traiter cet événement.
Avec la SOA c'est une réponse très efficace aux problématiques que rencontrent les entreprises en termes de réutilisabilité, d'interopérabilité et de réduction de couplage entre les différents systèmes qui implémentent leurs systèmes d'information.
Les architectures EDA ont été popularisées avec l'apparition de standards pour les places de marchés et les systèmes de vente aux enchères.
Elles mettent en application une partie des principes d'urbanisation.
Une architecture orientée événements repose principalement sur un bus disposant de fonctionnalités d'abonnement et de publication (publish and Subscribe).
Exemple
[modifier | modifier le code]Sotheby's a mis en place une architecture de type EDA pour son système de gestion des enchères : inscription des acheteurs, gestion des enchères avec alertes… Elle prend en charge à la fois le réseau intranet et les sollicitations de son site web et de son plateau téléphonique.
Concepts
[modifier | modifier le code]Le couplage entre composants est un couplage lâche et les communications sont en général asynchrones.
Le service peut :
- être codé dans n'importe quel langage,
- s'exécuter sur n'importe quelle plateforme (matérielle et logicielle).
Le service doit :
- s'abonner aux événements qu'il souhaite traiter
- traiter les événements auquel il est abonné sans préjuger d'un quelconque ordre et émettre un événement compte rendu de l'action qu'il vient de réaliser
- fournir les événements qu'il est susceptible d'émettre dont les structures sont publiées,
- être autonome (disposer de toutes les informations nécessaires à son exécution : pas de notion d'état)
- respecter un ensemble de contrats (règles de fonctionnement).
Annuaire de services
[modifier | modifier le code]L'annuaire de services référence l'ensemble des services et leurs événements (et des contrats associés) disponibles au sein du système d'information, il participe ainsi activement à la mise en œuvre d'une cartographie dynamique du système d'information.
Bus publish-subscribe
[modifier | modifier le code]Dans une architecture EDA, le bus a un rôle de médiateur (middleware entre le service émetteur de l'événement et les consommateurs potentiels, il permet ainsi de réaliser le couplage lâche. Le bus peut aussi fournir une gamme de services :
- sur la base des patterns EIP (Enterprise Integration Pattern), fournir des fonctionnalités de split, combine, etc. permettant de combiner l'appel sur plusieurs services,
- des fonctionnalités de versioning de service,
- des fonctionnalités de supervision et contrôle (avec SLA) des services.
Événement
[modifier | modifier le code]Un événement peut être défini comme « un changement significatif d'état »[1]. Par exemple, quand un client achète un tableau, le tableau passe de l'état « à vendre » à l'état « vendu » et le système de facturation va, sur réception de cet événement, déclencher l'émission de la facture, le même état sera traité par le service commission pour calculer les honoraires du commissaire priseur.
Ce modèle d'architecture est très souple et avec un couplage très lâche. Les consommateurs d'un événement doivent s'abonner (subscribe) à un intermédiaire de gestion d'événement (le bus) et le producteur de l'événement doit le publier auprès de ce gestionnaire (le bus). Quand le gestionnaire d'événement reçoit un événement d'un producteur, il le diffuse (forward) aux consommateurs concernés. Si le consommateur est injoignable, le gestionnaire peut conserver le message et le diffuser ultérieurement. Ce moyen de transmission d'événements repose sur un bus de message store and forward[2].
Concevoir un système d'information reposant sur une architecture orientée événements permet à ses applications d'être construites de manière plus réactive, plus souple et plus flexible.
L'architecture EDA complète l'architecture orientée services (SOA) car les services peuvent être activés par des triggers que sont les événements[2],[3].
Structure d'un événement
[modifier | modifier le code]Un événement comprend deux parties, un en-tête (event header) et le message (event body). L'en-tête comprend des informations comme son nom, son type, et un horodatage (timestamp de l'événement). Le message est la partie qui décrit la cause de l'événement (le tableau X a été vendu pour un prix Y à l'acheteur Z).
Articles connexes
[modifier | modifier le code]Articles
[modifier | modifier le code]- Article donnant les différences entre EDA et SOA : How EDA extends SOA and why it is important by Jack van Hoof.
Références
[modifier | modifier le code]- K. Mani Chandy Event-Driven Applications: Costs, Benefits and Design Approaches, California Institute of Technology, 2006
- Jeff Hanson, Event-driven services in SOA,Javaworld, January 31, 2005
- Carol Sliwa Event-driven architecture poised for wide adoption , Computerworld, May 12, 2003
Liens externes
[modifier | modifier le code]- Elemental Links: Event-Driven Architecture Overview — blog post by Brenda Michelson
- Esper : An Event Stream Processing (ESP) and event correlation engine (CEP, Complex Event Processing) available for Java and .NET
