Vorteile eines "Message Passing" -Systems gegenüber einem "Event Based" -System

Meine Frage kommt aus einer etwas ungebildeten Perspektive.

Was sind die relativen Vorteile eines " Message Passing " -Systems gegenüber einem " Event Based " -System ?

Warum sollte man eine über die andere wählen? Was sind ihre Stärken und Schwächen?

Ich möchte nicht nur "in der Theorie" wissen, sondern auch "in der Praxis".

BEARBEITEN:

Spezifisches Problem :

Ich möchte ein System aus steckbaren Komponenten aufbauen, die sich wie kleine Dienste verhalten (die jeweils eine kleine Aufgabe ausführen oder Informationen bereitstellen).

Die Dienste können:

• geschichtet sein, so dass die Ausgabe eines Dienstes als eine der Eingaben für einen anderen fungieren kann
• Containment-Hierarchien haben, so dass ein Service von einem anderen ohne eine bestimmte Eingabe-Ausgabe-Beziehung enthalten sein kann, wie im vorherigen Satz erwähnt

Das Ziel des Systems besteht darin, einen einzelnen Fluss von Ereignissen auf niedriger Ebene in einem anderen System in Informationen und Funktionen auf höherer Ebene umzuwandeln und darüber hinaus dem anderen System einen Rückkanal bereitzustellen, der eine einzelne Reihe von Ereignissen bereitstellt.

Ich kann mehr Details angeben, wenn dies nicht ausreicht.

Nachdem ich mich noch ein bisschen umgesehen habe. Dies und das beschreibt wahrscheinlich meine Situation besser.

Dies sieht so aus, als würde es gut zu meiner Situation passen: http://akka.io/

Nach meiner Erfahrung besteht der einzige spezifische Unterschied darin, dass der Absender der Nachricht in den meisten Nachrichtenübermittlungssystemen weiß (und oft angibt), wer der Empfänger der Nachricht ist.

Anstatt ein Ereignis auszulösen und jeder, der dem Ereignis zugeordnet ist, das es abruft, definiert der Absender eine ID des beabsichtigten Empfängers oder der logischen Gruppe von Empfängern und sendet die Nachricht dann entweder direkt an ihn oder geht über einen Nachrichtenbroker (obwohl das Betriebssystem in einem ereignisbasierten System als Nachrichtenbroker angesehen werden kann).

Offensichtlich gibt es den Fall von Threading, den Telastyn bei der Implementierung von Ereignissen in C # erwähnt, aber Sie können immer noch Ihr eigenes Pub / Sub-Modell erstellen, das auf verschiedenen Threads ausgeführt wird.

Das sind Äpfel und Orangen:

Ein ereignisgesteuertes System kann auf Ereignisse reagieren, die als Nachrichten übergeben wurden (Nachrichten in diesem Kontext sind unveränderliche, nicht gemeinsam genutzte Daten ), wenn die Ereignisse ausgelöst werden. Dies ist eine rein architektonische Gestaltung.

Ein Message Passing-System kann von Ereignissen gesteuert werden , mit denen Nachrichten erstellt und weitergeleitet werden. Dies ist ein reines Implementierungsdesign.

Die beiden schließen sich nicht aus.

Beispiel: Sie können ein ereignisgesteuertes Design in einer beliebigen Sprache implementieren, die auch eine Nachrichtenübermittlungsumgebung wie in Erlang sein kann.

Ein Großteil der Verwechslungen zwischen "Message Passing" und "Event Based" hat mit Details zu Architektur und Implementierung zu tun. Ich habe ereignisgesteuerte Systeme gesehen (und geschrieben), die tatsächlich vom Betriebssystem bereitgestellte Meldungen für ihre Implementierung verwenden. Ich vermute, Sie beziehen sich wirklich auf architektonische Ideen.

Wie viele Leute bereits darauf hingewiesen haben, sind "Message Passing" und "Event Based" nicht gut genug, um Mehrdeutigkeiten zu vermeiden.

Was sind die relativen Vorteile eines "Message Passing" -Systems gegenüber einem "Event Based" -System?

Message Passing

Ich gehe zunächst davon aus, dass Sie, wenn Sie ein "Message Passing" -System sagen, von einem System sprechen, bei dem ein Objekt eine Nachricht an ein bestimmtes anderes Objekt ausgibt. Wenn ich an ein System denke, das auf diesem Paradigma basiert, dann denke ich allgemeiner an ein System, in dem ein Objekt, das etwas erkennt, weiß, wem etwas erzählt werden muss. (Ich gebe nicht an, woher es weiß, nur dass es weiß.)

Diese Art von Architektur eignet sich sehr gut für Systeme, bei denen Hersteller und Verbraucher bekannt sind. Entweder weiß der Produzent einer Nachricht, wer sie empfangen muss, oder der Konsument muss wissen, von wem er die Nachricht erhält.

Wenn Sie einen Bankenantrag schreiben, würde man erwarten, dass Sie wirklich wissen möchten, an wen Sie Ihre Transaktionen senden und von wem sie kommen.

Ereignisbasiert

Das andere System, an das Sie denken, wenn Sie sagen, ein "ereignisbasiertes" System ist eines, bei dem ein Objekt ein "Ereignis" auslöst, ohne zu wissen, wer (wenn jemand) darauf reagiert.

Diese Art von ereignisgesteuerter Architektur eignet sich sehr gut für Systeme, bei denen es dem Produzenten nicht wichtig ist, wer das Ereignis produziert, oder bei denen es dem Verbraucher nicht wichtig ist, wer das Ereignis produziert hat.

Im Allgemeinen eignen sich diese Systeme hervorragend, wenn Sie die Beziehung zwischen Verbrauchern und Produzenten nicht kennen und eine dynamische Beziehung erwarten.

Ein System, in dem ich dies verwendet habe, war ein System, in dem die Anwendung tatsächlich aus dynamisch konfigurierten Modulen (Plug-Ins) bestand, die zur Laufzeit geladen wurden. Wenn ein Modul geladen wurde, wurde es für die Ereignisse registriert, die es betrafen. Das Ergebnis war ein System, bei dem es sehr einfach war, die Funktionalität zu erweitern.

Angenommen, Bedingung A hat das Ereignis EA ausgelöst, das normalerweise die Antwort RA verursacht hat. Das Objekt, das die Antwort RA ausgelöst hat, hat sich einfach registriert, um das Ereignis EA zu empfangen, und hat darauf reagiert, als es ankam. Angenommen, wir möchten EA eine neue Antwort mit dem Namen RA_1 hinzufügen. Dazu fügen wir einfach ein neues Objekt hinzu, das nach EA sucht und die Antwort RA_1 generiert.

Hier sind einige Beispiele (unter Verwendung Ihrer Terminologie):

• "message passing" : Ihr Chef fordert Sie auf, Ihr Arbeitszeitblatt auszufüllen.
• "ereignisgesteuert" : Der Abteilungssekretär sendet eine E - Mail an alle, die daran erinnern, dass ihre Arbeitszeitnachweise heute fällig sind.

In SOA haben Sie das Konzept der Befehlsmeldungen und Ereignismeldungen. Beides ist notwendig.

Befehlsnachrichten weisen jedoch eine höhere Verhaltenskopplung zum Empfängerendpunkt auf, da der Endpunkt explizit aufgefordert wird, eine Funktion auszuführen. Es muss nicht an einen bestimmten Endpunkt gebunden sein (dies kann zur Laufzeit konfiguriert oder festgelegt werden).

Ereignisnachrichten weisen andererseits keine Verhaltenskopplung zwischen dem Absender / Empfänger auf, da der Absender keine Ahnung hat, was ein Empfänger mit der Nachricht tun wird. Es weiß nicht einmal, ob jemand die Veranstaltung abonniert hat.

Für weitere Hintergrundinformationen können Sie gerne meine Servicebusseite hier einsehen: http://www.servicebus.co.za

Meiner Erfahrung nach besteht der größte Unterschied zwischen beiden darin, dass Nachrichten in einem Nachrichtenübergabesystem erstklassige Objekte sind, während Ereignisse in ereignisgesteuerten Systemen viel einfacher sind. Nachrichten neigen dazu, Informationen zu enthalten, und diese Informationen können transformiert, gespeichert, abgerufen und erneut gesendet werden. Ereignisse enthalten in der Regel kleinere, fokussiertere Informationen, die sofort verbraucht und anschließend verworfen werden. Sie werden in der Regel von einer Ereignisquelle direkt an eine oder mehrere Ereignissenken gesendet, wohingegen Nachrichten häufiger zwischen mehreren Empfängern weitergeleitet werden und an jedem Punkt der Route konvertiert / übersetzt / umbrochen oder auf andere Weise verarbeitet werden können. Sie verwenden ähnliche Technologien (Busse, Warteschlangen, Filter usw.), aber sie sind wirklich unterschiedliche Bestien.

Aus praktischer Sicht werden Nachrichten in der Regel als Speicherblock implementiert, der aus dem Adressraum des Absenders in den Adressraum des Empfängers kopiert wird (oder auf andere Weise als unveränderliches Objekt erzwungen wird), sodass Sie sofort Thread-Sicherheit erhalten.

In einigen Fällen von Nachrichtenübergabe muss der Absender den Empfänger angeben, in anderen Fällen können Sie jedoch einfach eine Nachricht an eine Mailbox senden und jeder kann Nachrichten in dieser Mailbox abhören, sodass die enge Kopplung flexibel ist. Natürlich können Sie ein Postfach haben, in dem der Vertrag lautet "Ich werde eine Nachricht an dieses Postfach senden, wenn dieses Ereignis eintritt."

Bei Ereignissen registrieren Sie einen Delegierten oder einen Rückruf beim Eigentümer des Ereignisses. Bei der objektorientierten Programmierung bedeutet dies, dass der Ereigniseigentümer einen Verweis auf das Objekt behält, das für den Empfang des Ereignisses registriert wurde. Dies kann manchmal zu Albträumen bei der Buchhaltung führen und den Versuch unternehmen, herauszufinden, welches Objekt vergessen hat, die Registrierung seines Ereignishandlers aufzuheben. Dies bedeutet, dass das Ziel erst dann müllsammelbar ist, wenn der Ereigniseigentümer müllsammelbar ist, selbst wenn das Ziel nichts Nützliches mehr tut.

Persönlich würde ich die Nachrichtenübermittlung über Ereignisse wählen, außer in Fällen, in denen Ereignisse für Sie erzwungen werden, wie z. B. die Windows-GUI-Programmierung usw.