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

Le concept de Message est abstrait, les types de messages plus concrets sont Event et Command.

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 (dans le futur).

Answer 2

Tel que joliment dit dans cet article, pour comprendre la conception événementielle, au lieu de regarder ce qu'elle présente, nous devons observer ce qu'elle cache et cela n'est rien de plus que la base même de la programmation; la "Pile d'appels".

Dans la conception événementielle, la définition de l'invocation de méthode disparaît. Il n'y a plus d'appelant et d'appelé. C'est une adieu au séquence d'appel 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 mémoire partagé, 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 être capable d'associer une fonctionnalité à un nom de méthode.

Les applications orientées messages viennent par défaut avec l'élimination de la mémoire partagée. Le éditeur et le abonné n'ont pas besoin de partager un espace mémoire. D'un autre côté, toutes les autres caractéristiques (c'est-à-dire l'ordre, l'association de nom de méthode, etc.) ne sont pas des nécessités.

Si le passage de messages est conçu conformément aux axiomes de l'architecture événementielle, ils pourraient être considérés comme identiques. Sinon, il y a une énorme différence entre eux.

Answer 3

Si nous utilisons une approche basée sur les événements, nous voulons généralement envoyer l'objet source dans cet événement - le composant qui a publié l'événement. Ainsi, dans le subscriber, nous pouvons obtenir non seulement les données, mais également 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 le subscriber. Dans ce cas, nous pouvons même ajouter un traitement en arrière-plan, modifier le composant source - par exemple, ajouter une animation à cette Vue source.

Lorsque nous utilisons une approche basée sur les messages, nous voulons publier uniquement le message avec des données. Peu importe pour le subscriber qui a publié ce message, nous voulons simplement recevoir les données et les traiter de quelque manière que ce soit.

Answer 4

L'architecture orientée événements et l'architecture orientée messages sont deux choses différentes et résolvent deux problèmes différents.

L'architecture orientée événements se concentre sur la manière dont le système est déclenché pour fonctionner. La majorité des déclencheurs considérés comme des événements dans le contexte de l'AEO sont les événements générés par des moyens autres que le clavier et la souris. Il s'agit d'une AEO si cela nous amène à penser explicitement au générateur d'événements, au canal d'événements, au moteur de traitement des événements.

Le clavier et la souris sont des générateurs d'événements évidents, cependant le traitement de ces événements est déjà pris en charge par divers cadres ou exécutions et en tant qu'architecte nous n'avons pas besoin de nous en préoccuper. Il y a d'autres événements spécifiques à certains domaines auxquels l'architecte est censé réfléchir. Par exemple, les événements de gestion de la chaîne d'approvisionnement - prise en charge, emballage, expédition, distribution, détaillant, vendu, etc. Du point de vue technique pour les applications de l'IoT industriel, les événements sont - Lecture RFID, Lecture biométrique, Données des capteurs, Scan de codes-barres, les événements générés par le système sont les événements qui doivent être pris explicitement en charge car ces événements entraînent le fonctionnement du système.

L'architecture orientée messages vise à intégrer les systèmes distribués en faisant passer des messages d'un module à d'autres modules du système à l'aide d'un logiciel Middleware orienté messages standard.

Answer 5

En OO , c'est interactif de manière message entre appelant et appelé... En GUI, nous disons toujours Événementiel. Nous pouvons voir que si nous avons besoin de gérer la relation à la fois éditeur et abonné, nous devrions utiliser l'approche Événementiel. Si nous gérons en amont et en aval de façon plus abstraite sans dépendances fortes (comme en amont qui ne connaît pas l'aval), nous devrions utiliser l'approche Message. Ainsi, dans le contexte d'une Middleware basée sur les messages, il n'y a pas de distinction claire, c'est plutôt une différence de construction plutôt que de conception.