Message driven vs. event driven approaches to application integration

Question

Je me demandais s'il y a une distinction claire entre les environnements basés sur les messages et les environnements basés sur les événements lorsque nous parlons de l'architecture orientée services (SOA) ou des intergiciels, et généralement dans le cas de l'intégration d'applications et d'entreprises. Je comprends qu'une interface utilisateur ressemble à un modèle basé sur les événements où notre système intercepte l'action de l'utilisateur.

Il est également clair que la messagerie supporte des systèmes basés sur la publication/abonnement, une communication synchrone ou asynchrone, des transactions, etc.

Mais y a-t-il une différence dans le contexte de l'intégration d'intergiciels/SOA/applications (niveau architecture) ? J'essaie de consulter des sources telles que Wikipédia (ici, et ici), mais je suis encore un peu confus. Quand un développeur devrait-il préférer une solution plutôt qu'une autre ?

Y a-t-il des exemples ou des cas où une approche est plus judicieuse que l'autre ? Ou des ressources et guides complets pour mettre en œuvre chacune d'entre elles ?

Merci beaucoup pour toute information.

Answer 1

Voici un point de vue Typesafe/Reactive sur la question de Jonas Bonér. À partir du troisième paragraphe de cet article de blog:

La différence est que les messages sont dirigés, les événements ne le sont pas - un message a un destinataire clairement identifiable tandis qu'un événement se produit simplement pour que les autres (0-N) le remarquent.

Answer 2

Cette question a été posée il y a longtemps. Je pense qu'une réponse plus moderne et claire est donnée par le Manifeste Réactif dans Message-Driven (par opposition à 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 piloté par les messages, les destinataires adressables attendent l'arrivée de messages et y réagissent, sinon ils restent inactifs. Dans un système piloté par les événements, les écouteurs de notifications sont attachés aux sources d'événements de sorte qu'ils soient 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 encodé en tant que charge utile.

Answer 3

Imaginons que vous construisez un service de paiement pour un site web eCommerce. Lorsqu'une commande est passée, le service de Commande demandera à votre service de Paiement d'autoriser la carte de crédit du client. Ce n'est que lorsque la carte de crédit a été autorisée que le service de Commande enverra la commande à l'entrepôt pour l'emballage et l'expédition.

Vous devez vous mettre d'accord avec l'équipe travaillant sur le service de Commande sur la manière dont cette demande d'autorisation de carte de crédit est envoyée de leur service au vôtre. Il existe deux options.

• Basé sur des messages : Lorsqu'une commande est passée, le service de Commande envoie une demande d'autorisation à votre service de Paiement. Votre service traite la demande et renvoie un succès/échec au service de Commande. La demande initiale et le résultat pourraient être envoyés de manière synchrone ou asynchrone.
• Basé sur les événements : Lorsqu'une commande est passée, le service de Commande publie un événement NouvelleCommande. Votre service de Paiement s'abonne à ce type d'événement pour le déclencher. Votre service traite la demande et publie un événement AutorisationAcceptée ou un événement AutorisationRefusée. Le service de Commande s'abonne à ces types d'événements. Tous les événements sont asynchrones.

Un avantage de l'approche basée sur les événements est que d'autres services pourraient également s'abonner aux différents événements. Par exemple, il pourrait y avoir un service de Reporting de Revenus qui s'abonne aux événements AutorisationAcceptée et crée des rapports pour l'équipe financière.

Un inconvénient de l'approche basée sur les événements est que le système dans son ensemble devient un peu plus difficile à comprendre. Par exemple, imaginons que l'équipe travaillant sur le service de Commande vous demande de remplacer l'événement AutorisationRefusée par différents événements en fonction de 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 cessez de publier des événements AutorisationRefusée, est-ce que cela va casser certains autres services? Si vous avez de nombreux événements et services, cela pourrait être difficile à identifier.

Answer 4

La réponse courte à la question "y a-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 que vous référencez concerne la plomberie de bas niveau, le MOM ou le "bus" de publication-abonnement qui transporte les messages en votre nom. L'architecture pilotée par les événements est ce que vous construisez au-dessus de ce cadre.

Le terme piloté par les événements, bien qu'il s'applique également au code GUI, n'est pas vraiment au même niveau d'abstraction. Dans ce cas, c'est un motif au niveau micro par rapport à la construction de l'ensemble de votre entreprise selon des lignes de conduite basées sur les messages/événements.

Answer 5

Les architectures pilotées par les événements peuvent être mises en œuvre avec ou sans messagerie. La messagerie est un moyen de communiquer les événements émis 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 des serveurs / VM / environnements différents et n'ont pas 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é dans la même application elle-même, ou lorsque le consommateur doit être exécuté de manière synchrone, alors l'abonnement aux événements peut être mis en œuvre sans messagerie.