it-swarm.com.de

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

Meine Frage kommt aus einer etwas ungebildeten Perspektive.

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

Warum sollte man einen über den anderen wählen? Was sind ihre Stärken und Schwächen?

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

BEARBEITEN:

Spezifisches Problem :

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

Die Dienste können:

  • geschichtet werden, 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 zu übersetzen und zusätzlich einen Kanal zurück zum anderen System bereitzustellen, der eine einzelne Reihe von Ereignissen bereitstellt.

Ich kann mehr Details liefern, wenn dies nicht ausreicht.

Nachdem ich mich noch ein bisschen umgesehen habe. This und this beschreiben wahrscheinlich meine Situation besser.

Dies scheint gut zu meiner Situation zu passen: http://akka.io/

27
sylvanaar

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

Anstatt ein Ereignis auszulösen und jeder, der dem Ereignis zugeordnet ist, das es erhält, 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 als Nachrichtenbroker in einem ereignisbasierten System angesehen werden kann).

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

17
Steven Evers

Das sind Äpfel und Orangen:

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

Ein Message-Passing-System kann gesteuert durch Ereignisse sein, das die Nachrichten erstellt und weiterleitet. Dies ist ein reines Implementierungsdesign.

Die beiden schließen sich nicht gegenseitig aus.

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

21
user7519

Ein Großteil der Verwechslung 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 Nachrichten 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 "ereignisbasierten" System?.

Nachrichtenübermittlung

Ich beginne mit der Vermutung, 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, denke ich allgemeiner an ein System, bei dem ein Objekt, das etwas erkennt, weiß, wer über etwas informiert 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 Verbraucher muss wissen, von wem er die Nachricht erhalten soll.

Wenn Sie einen Bankantrag 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 meiner Meinung nach denken, wenn Sie sagen, dass ein "ereignisbasiertes" System ein System ist, 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 egal ist, wer das Ereignis konsumiert, oder bei denen es dem Konsumenten nicht wirklich wichtig ist, wer das Ereignis produziert.

Im Allgemeinen eignen sich diese Systeme hervorragend, wenn Sie die Beziehung zwischen Verbrauchern und Herstellern nicht kennen und wenn Sie erwarten, dass die Beziehung dynamisch ist.

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 interessierte. Das Ergebnis war ein System, in dem es sehr einfach war, die Funktionalität zu erweitern.

Angenommen, Bedingung A hat ein Ereignis EA ausgelöst, das normalerweise eine Antwort-RA verursacht hat. Das Objekt, das die Antwort RA verursacht 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 einige Beispiele (unter Verwendung Ihrer Terminologie):

  • "Message Passing": Ihr Chef fordert Sie auf, Ihr Arbeitszeitblatt auszufüllen.
  • "ereignisgesteuert": Die Abteilungssekretärin sendet eine E-Mail an alle, die sie daran erinnert, dass ihre Arbeitszeitnachweise heute fällig sind.
11
jwernerny

In SOA haben Sie das Konzept von Command Messages und Event Nachrichten. Es besteht Bedarf an beiden.

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

Ereignismeldungen haben andererseits keine Verhaltenskopplung zwischen dem Absender/Empfänger, da der Absender keine Ahnung hat, was ein Empfänger mit der Nachricht tun wird. Es weiß nicht einmal, ob jemand das Ereignis abonniert hat.

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

2
user23356

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

1
TMN

Aus praktischer Sicht werden Nachrichten normalerweise 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, in denen eine Nachricht weitergeleitet wird, muss der Absender den Empfänger angeben. In anderen Fällen können Sie eine Nachricht einfach an eine Mailbox senden, und jeder kann auf Nachrichten in dieser Mailbox warten, sodass eine gewisse Flexibilität hinsichtlich der engen Kopplung besteht. Natürlich können Sie eine Mailbox haben, in der der Vertrag lautet: "Ich werde eine Nachricht an diese Mailbox senden, wenn dies Ereignis passiert."

Bei Ereignissen registrieren Sie einen Delegaten 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 sich zum Empfang des Ereignisses registriert hat. Dies kann manchmal zu Albträumen in der Buchhaltung führen, in denen versucht wird, herauszufinden, welches Objekt vergessen hat, die Registrierung seines Ereignishandlers aufzuheben. Dies bedeutet, dass das Ziel erst dann mit Müll gesammelt werden kann, wenn der Ereignisbesitzer Müll gesammelt hat, selbst wenn das Ziel nichts Nützliches mehr tut.

Persönlich würde ich Nachrichten wählen, die über Ereignisse übertragen werden, außer in Fällen, in denen Ihnen Ereignisse aufgezwungen werden, wie z. B. Windows-GUI-Programmierung usw.

0
Scott Whitlock