Avantages d'un système de "transmission de messages" par rapport à un système "basé sur des événements"
Ma question vient d'un point de vue quelque peu inculte.
Quels sont les avantages relatifs d'un système " passage de messages " par rapport à un système " basé sur des événements ".
Pourquoi choisirait-on l'un plutôt que l'autre? Quelles sont leurs forces et leurs faiblesses?
Je voudrais savoir non seulement "en théorie", mais aussi "en pratique".
ÉDITER:
Problème spécifique :
Je veux construire un système de composants enfichables qui se comportent comme des services à petite échelle (chacun effectuant une petite tâche et/ou fournissant des informations).
Les services peuvent:
- être en couches afin que la sortie d'un service puisse agir comme l'une des entrées d'un autre
- avoir des hiérarchies de confinement afin qu'un service puisse être contenu par un autre sans relation d'entrée-sortie spécifique, comme mentionné dans la phrase précédente
Le but du système est de traduire un flux unique d'événements de bas niveau dans un autre système en informations et fonctionnalités de niveau supérieur, et en plus de fournir un canal vers l'autre système fournissant une seule série d'événements.
Je peux fournir plus de détails si cela ne suffit pas.
Après avoir regardé un peu plus. This and this décrit probablement mieux ma situation.
Il semble que cela puisse convenir à ma situation: http://akka.io/
D'après mon expérience, la seule différence spécifique est que dans la plupart des systèmes de transmission de messages, l'expéditeur du message sait (et déclare souvent) qui est le destinataire du message.
Ainsi, au lieu de déclencher un événement et que quiconque s'y soit inscrit, l'expéditeur définit un identifiant du ou des destinataires ou du groupe logique de destinataires, puis leur envoie directement le message ou passe par un courtier de messages. (bien que le système d'exploitation puisse être considéré comme un courtier de messages dans un système basé sur des événements).
Évidemment, il y a le cas du threading que Telastyn mentionne avec l'implémentation d'événements C #, mais vous pouvez toujours créer votre propre modèle pub/sub qui s'exécute sur différents threads.
Ce sont des pommes et des oranges:
Un système basé sur les événements peut réagir aux événements transmis sous forme de messages (les messages dans ce contexte sont implicites immuables données non partagées) comme les événements sont soulevés. Il s'agit d'une conception purement architecturale.
Un système de transmission de messages peut être piloté par des événements qui créent et transmettent les messages. Il s'agit d'une conception purement mise en œuvre.
Les deux ne s'excluent pas mutuellement.
Exemple: Vous pouvez implémenter une conception pilotée par les événements dans n'importe quelle langue qui peut également être un message passant environnement comme à Erlang.
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à souligné, "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 rédigez une application bancaire, vous vous attendez vraiment à savoir à qui vous envoyez vos transactions et à qui elles proviennent.
Basé sur les événements
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 dit de remplir votre feuille de temps.
- "événementiel": Le secrétaire du département envoie un e-mail à tous pour leur rappeler que leurs feuilles de temps sont dues aujourd'hui.
Dans SOA vous avez le concept de Commande Messages et Événement Messages. Il y a un besoin pour les deux.
Cependant, les messages de commande ont un couplage comportemental plus élevé avec le point de terminaison destinataire car il demande explicitement au point de terminaison d'effectuer une fonction. Il n'a pas besoin d'être lié à un point de terminaison particulier (cela peut être configuré ou déterminé au moment de l'exécution).
Les messages d'événement, d'autre part, n'ont aucun couplage comportemental entre l'expéditeur/le destinataire puisque l'expéditeur n'a aucune idée de ce qu'un destinataire va faire avec le message. Il ne sait même pas si quelqu'un est abonné à l'événement.
Pour plus d'informations, vous pouvez consulter mon site de bus de service ici: http://www.servicebus.co.za
D'après mon expérience, la plus grande différence entre les deux est que les messages dans un système de transmission de messages sont des objets de première classe, tandis que les événements dans les systèmes pilotés par les événements sont beaucoup plus simples. Les messages ont tendance à véhiculer des informations, et ces informations peuvent être transformées, stockées, récupérées et renvoyées. Les événements ont tendance à transporter des informations plus petites et plus ciblées, qui sont immédiatement consommées puis rejetées. Ils ont tendance à être envoyés depuis une source d'événements directement vers un ou plusieurs récepteurs d'événements, tandis que les messages sont plus souvent acheminés entre plusieurs récepteurs et peuvent être convertis/traduits/encapsulés ou autrement traités à tout moment de l'itinéraire. Ils utilisent des technologies similaires (bus, files d'attente, filtres, etc.) mais ce sont vraiment des bêtes disparates.
D'un point de vue pratique, les messages sont généralement implémentés comme un bloc de mémoire qui est copié de l'espace d'adressage de l'expéditeur vers l'espace d'adressage du destinataire (ou qui est autrement imposé pour être un objet immuable) de sorte que vous gagnez immédiatement la sécurité des threads.
Dans certains cas de passage de message, l'expéditeur doit spécifier le destinataire, mais dans d'autres cas, vous pouvez simplement poster un message dans une boîte aux lettres, et n'importe qui peut écouter les messages dans cette boîte aux lettres, il y a donc une certaine flexibilité dans leur couplage serré. Bien sûr, vous pouvez avoir une boîte aux lettres dont le contrat est "Je publierai un message dans cette boîte aux lettres lorsque cela événement se produira."
Dans le cas d'événements, vous inscrivez un délégué ou rappelez-vous avec le propriétaire de l'événement. Dans la programmation orientée objet, cela signifie que le propriétaire de l'événement conserve une référence à l'objet qui s'est inscrit pour recevoir l'événement. Cela peut parfois conduire à des cauchemars de tenue de livres, essayant de comprendre quel objet a oublié de désenregistrer leur gestionnaire d'événements. Cela signifie que la cible ne peut pas être récupérée jusqu'à ce que le propriétaire de l'événement soit récupéré, même si la cible ne fait plus rien d'utile.
Personnellement, je choisirais le passage de messages sur les événements, sauf dans les cas où des événements vous sont imposés, tels que la programmation de l'interface graphique Windows, etc.