- Architecture Orientée Evènements
-
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 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 « service» 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).
Sommaire
Exemple
On peut citer Sotheby's, qui 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,...) qui prend en charge à la fois le réseau intranet et les sollicitations de son site web et de son plateau téléphonique.
Les Concepts
Le couplage entre services est un couplage lâche et les communications sont toutes 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).
L'annuaire de services
L'annuaire de services référence l'ensemble des services et leurs événements (et des contrats associés) disponibles au sein du SI, il participe ainsi activement à la mise en œuvre d'une cartographie dynamique du SI.
Le bus Publish & Subscribe
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.
L'événement
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
Un événement comprend 2 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).
Voir aussi
- Event-driven programming
- Architecture Orientée Services
- Complex Event Processing
Articles
- 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
- ↑ K. Mani Chandy Event-Driven Applications: Costs, Benefits and Design Approaches, California Institute of Technology, 2006
- ↑ a et b 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
- Elemental Links: Event-Driven Architecture Overview — blog post by Brenda Michelson
- [1] Esper: An Event Stream Processing (ESP) and event correlation engine (CEP, Complex Event Processing) available for Java and .NET
Portail de l’informatique
Catégories : Architecture logicielle | Gestion de projet | Services web
Wikimedia Foundation. 2010.
