Une grande partie de la confusion entre le «passage de message» et «basé sur un événement» a à voir avec les détails architecturaux et de mise en œuvre. J'ai vu (et écrit) des systèmes pilotés par les événements qui utilisent réellement des messages fournis par le système d'exploitation pour leur implémentation. Je suppose que vous faites vraiment référence aux idées architecturales.
Comme beaucoup de gens l'ont déjà fait remarquer, «passer des messages» et «basé sur des événements» ne sont pas vraiment des termes assez bons pour éviter toute ambiguïté.
Quels sont les avantages relatifs d'un système de "transmission de messages" par rapport à un système "basé sur des événements".
Passage de message
Je vais commencer par deviner que lorsque vous dites un système de "passage de message", vous parlez d'un système dont un objet dépense un message à un autre objet spécifique. Quand je pense à un système basé sur ce paradigme, je pense plus généralement à un système où un objet qui détecte quelque chose sait à qui il faut en parler. (Je ne précise pas comment il sait, juste qu'il sait.)
Ce type d'architecture est très bon pour les systèmes où les producteurs et les consommateurs sont bien connus. Soit le producteur d'un message sait qui doit le recevoir, soit le consommateur doit savoir de qui recevoir le message.
Si vous écrivez une application bancaire, on peut s'attendre à ce que vous vouliez vraiment savoir à qui vous envoyez vos transactions et à qui elles viennent.
Basé sur l'événement
L'autre système auquel je pense que vous pensez lorsque vous dites qu'un système "basé sur un événement" est un système où un objet déclenche un "événement" sans savoir qui (le cas échéant) y répondra.
Ce type d'architecture événementielle est très bon pour les systèmes où le producteur ne se soucie pas de qui consomme l'événement ou où le consommateur ne se soucie pas vraiment de qui a produit l'événement.
En général, ces systèmes sont excellents lorsque vous ne connaissez pas la relation entre les consommateurs et les producteurs et lorsque vous vous attendez à ce que la relation soit dynamique.
Un système dans lequel j'ai utilisé ceci était un système où l'application était en fait composée de modules configurés dynamiquement (plug-ins) qui étaient chargés au moment de l'exécution. Lorsqu'un module était chargé, il s'inscrivait pour les événements auxquels il tenait. Le résultat était un système dans lequel il était très facile d'étendre la fonctionnalité.
Par exemple, disons que la condition A a déclenché l'événement EA qui a normalement provoqué la réponse RA. L'objet qui a provoqué la réponse RA s'est simplement enregistré pour recevoir l'événement EA et a réagi à son arrivée. Supposons maintenant que nous voulons ajouter une nouvelle réponse à EA, appelée RA_1. Pour ce faire, nous ajoutons simplement un nouvel objet qui recherche EA et génère une réponse RA_1.
Voici quelques exemples (en utilisant votre terminologie):
- "message passant" : votre patron vous demande de remplir votre feuille de temps.
- "événementiel" : le secrétaire du département envoie un mail à chacun pour lui rappeler que ses feuilles de temps sont attendues aujourd'hui.