approches basées sur les messages et sur les événements pour l'intégration des applications
Je me demandais s'il y avait une distinction claire entre les environnements pilotés par les messages et les événements lorsque nous nous référions à SOA ou middleware et généralement dans les cas d'intégration d'applications et d'entreprise. Je comprends qu'une interface utilisateur ressemble à un modèle piloté par les événements où notre système intercepte l'action de l'utilisateur.
Il est également clair que la messagerie prend en charge les systèmes basés sur la publication/abonnement, la communication synchrone ou asynchrone, les transactions, etc.
Mais y a-t-il une différence dans le contexte d'intégration middleware/soa/application? (niveau architecture). J'essaie de consulter des sources telles que wikipedia ( ici , et ici ), mais je suis encore un peu confus. Quand un développeur devrait-il préférer une solution à l'autre?
Y a-t-il des exemples ou des cas où une approche a plus de sens que l'autre? Ou des ressources et des guides complets pour la mise en œuvre de chacun?
Merci beaucoup pour tout aperçu.
Une réponse courte à "existe-t-il une distinction claire" serait "non".
Les termes ne sont pas tout à fait interchangeables, mais impliquent la même architecture de base - en particulier que vous déclencherez des événements ou des messages.
Le premier article auquel vous faites référence concerne la plomberie de bas niveau, le "bus" MOM ou pub-sub qui transporte les messages en votre nom. L'architecture événementielle est ce que vous construisez au-dessus de ce cadre.
Le terme événementiel, tout en s'appliquant également au code GUI, n'est pas vraiment au même niveau d'abstraction. Dans ce cas, c'est un modèle dans le petit par rapport à la construction de votre entreprise entière le long de lignes axées sur les messages/événements.
Voici un Typesafe / Reactive point de vue sur la question de Jonas Bonér. Du troisième paragraphe de ce billet de blog :
La différence étant que les messages sont dirigés, les événements ne le sont pas - un message a un destinataire adressable clair tandis qu'un événement se produit simplement pour que d'autres (0-N) l'observent.
Cette question a été posée il y a longtemps. Je pense qu'une réponse plus moderne et plus claire est donnée par le Manifeste réactif in Message-Driven (contrairement à Event-Driven) :
Un message est un élément de données envoyé à une destination spécifique. Un événement est un signal émis par un composant lorsqu'il atteint un état donné. Dans un système axé sur les messages, les destinataires adressables attendent l'arrivée des messages et y réagissent, sinon ils restent en sommeil. Dans un système basé sur des événements, les écouteurs de notification sont attachés aux sources d'événements de telle sorte qu'ils sont invoqués lorsque l'événement est émis. Cela signifie qu'un système piloté par les événements se concentre sur les sources d'événements adressables tandis qu'un système piloté par les messages se concentre sur les destinataires adressables. Un message peut contenir un événement codé comme charge utile.
Les architectures événementielles peuvent être implémentées avec ou sans messagerie. La messagerie est un moyen de communiquer les événements soulevés par les producteurs aux consommateurs de manière fiable et garantie. Surtout lorsque les producteurs et les consommateurs sont vraiment découplés et peuvent être hébergés sur différents serveurs/VM/environnements et n'ont pas d'accès direct à une mémoire partagée.
Cependant, dans des cas spécifiques - lorsque le consommateur de l'événement est une fonction/rappel enregistrée dans la même application elle-même, ou lorsque le consommateur doit être exécuté de manière synchrone, l'abonnement aux événements peut être implémenté sans messagerie.
Supposons que vous créez un service de paiement pour un site Web de commerce électronique. Lorsqu'une commande est passée, le service Commande demandera à votre service Paiement d'autoriser la carte bancaire du client. Ce n'est que lorsque la carte de crédit a été autorisée que le service des commandes enverra la commande à l'entrepôt pour emballage et expédition.
Vous devez convenir avec l'équipe travaillant sur le service Commande de la manière dont cette demande d'autorisation de carte de crédit est envoyée de leur service à la vôtre. Il y a deux options.
- Message-driven: Lorsqu'une commande est passée, le service Order envoie une demande d'autorisation à votre service de paiement. Votre service traite la demande et renvoie le succès/l'échec au service de commande. La demande initiale et le résultat peuvent être envoyés de manière synchrone ou asynchrone.
- Event-driven: Lorsqu'une commande est passée, le service Order publie un événement NewOrder. Votre service de paiement souscrit à ce type d'événement afin qu'il soit déclenché. Votre service traite la demande et publie un événement AuthorizationAccepted ou AuthorizationDeclined. Le service Order s'abonne à ces types d'événements. Tous les événements sont asynchrones.
n avantage de l'approche événementielle est que d'autres services pourraient également s'abonner aux divers événements. Par exemple, il peut exister un service RevenueReporting qui s'abonne aux événements AuthorizationAccepted et crée des rapports pour l'équipe Finance.
n inconvénient de l'approche événementielle est que le système dans son ensemble devient un peu plus difficile à comprendre. Par exemple, supposons que l'équipe travaillant sur le service Commande vous demande de remplacer l'événement AuthorizationDeclined par différents événements selon la raison pour laquelle la carte de crédit a été refusée (pas de fonds, compte fermé, adresse de facturation incorrecte, etc.). Si vous arrêtez de publier les événements AuthorizationDeclined, cela interrompra-t-il un autre service? Si vous avez de nombreux événements et services, cela peut être difficile à retrouver.
Comme il est bien placé dans l'article this , afin de comprendre la conception pilotée par les événements, au lieu de regarder ce qu'il présente, nous devons observer ce qu'il cache et ce n'est rien de plus que la base de la programmation; le "Call Stack".
Dans la conception événementielle, la définition de l'appel de méthode sort directement de la fenêtre. Il n'y a plus d'appel et d'appelé. C'est un baiser d'adieu pour appeler la séquence et l'ordre. Le système n'a pas besoin de savoir dans quel ordre les choses doivent se produire. Par conséquent, l'espace de mémoire partagée, qui est une condition préalable de la pile d'appels, devient inutile.
Dans un environnement de pile d'appels, cependant, non seulement l'appelant doit savoir ce qui se passe ensuite, mais il doit également pouvoir associer une fonctionnalité à un nom de méthode.
Les applications orientées message par défaut s'accompagnent de la suppression de la mémoire partagée. L'éditeur et l'abonné n'ont pas besoin de partager un espace mémoire. D'un autre côté, toutes les autres fonctionnalités (c'est-à-dire l'ordre, le couplage des noms de méthode et autres) ne sont pas des nécessités.
Si le passage de messages est conçu de manière à respecter les axiomes de l'architecture événementielle, ils pourraient être considérés comme identiques. Sinon, il y a une énorme différence entre eux.
L'architecture pilotée par les événements et l'architecture pilotée par les messages sont deux choses différentes et résolvent deux problèmes différents.
L'architecture événementielle se concentre sur la façon dont le système est déclenché pour fonctionner. La majorité des déclencheurs qui sont considérés comme des événements dans le contexte de l'EDA sont les événements générés par des moyens autres que le clavier et la souris. Il s'agit d'un EDA si cela nous fait penser explicitement au générateur d'événements, au canal d'événements, au moteur de traitement d'événements.
Le clavier et la souris sont des générateurs d'événements évidents, mais la gestion de ces événements est déjà prise en charge par divers cadres ou runtimes et en tant qu'architecte, nous n'avons pas à nous en préoccuper. Il y a d'autres événements qui sont spécifiques à certains domaines, c'est ce à quoi Architect est censé penser. Exemple - Événements de gestion de la chaîne d'approvisionnement - prélèvement, emballage, expédition, distribution, détaillant, vendu, etc. Du point de vue technique pour les applications de type IoT industriel, les événements sont - Lecture RFID, Lecture biométrique, Données de capteur, Balayage de codes à barres, Événements générés par le système sont les événements qui doivent être pris en compte de manière explicite car ces événements pilotent la fonctionnalité du système.
L'architecture axée sur les messages se concentre sur l'intégration des systèmes distribués en transmettant les messages d'un module à d'autres modules du système à l'aide du middleware orienté message standard.
Si nous utilisons une approche événementielle, nous souhaitons généralement envoyer l'objet source dans cet événement - le composant qui a publié l'événement. Ainsi, en abonné, nous pouvons obtenir non seulement les données, mais aussi savoir qui a publié cet événement. Par exemple. dans le développement mobile, nous recevons la vue, qui peut être un bouton, une image ou une vue personnalisée. Et selon le type de cette vue, nous pouvons utiliser une logique différente dans l'abonné. Dans ce cas, nous pouvons même ajouter du rétro-traitement, modifier le composant source - par exemple ajouter une animation à la vue source.
Lorsque nous utilisons une approche basée sur les messages, nous voulons publier uniquement le message avec certaines données. Peu importe l'abonné qui a publié ce message, nous voulons simplement recevoir les données et les traiter d'une manière ou d'une autre.
Le concept de Message est abstrait, les types de messages les plus concrets sont Evénement et Commande.
Alors que les messages n'ont aucune intention particulière, les événements informent sur quelque chose qui s'est produit et est déjà terminé (dans le passé). Les commandes déclenchent quelque chose qui devrait se produire (à l'avenir).