Nachrichtengesteuerte vs. ereignisgesteuerte Ansätze zur Anwendungsintegration

Question

Ich frage mich, ob es eine klare Unterscheidung zwischen meldungsgesteuerten und ereignisgesteuerten Umgebungen gibt, wenn wir uns auf SOA oder Middleware und im Allgemeinen auf Anwendungen und Unternehmensintegration beziehen. Ich verstehe, dass eine Benutzeroberfläche einem ereignisgesteuerten Modell ähnelt, bei dem unser System die Aktion des Benutzers abfängt.

Auch ist es klar, dass Messaging-Systeme unterstützt, basierend auf Publish/Subscribe, sychronous oder asynchrone Kommunikation, Transaktionen usw.

Aber gibt es einen Unterschied in der Middleware/soa/Anwendung intergration Kontext? (Architektur-Ebene). Ich versuche Quellen wie wikipedia (here und here) zu konsultieren, aber ich bin immer noch etwas verwirrt. Wann sollte ein Entwickler eine Lösung der anderen vorziehen?

Gibt es Beispiele oder Fälle, in denen ein Ansatz sinnvoller ist als der andere? Oder umfassende Ressourcen und Anleitungen zur Umsetzung jeder einzelnen?

Vielen Dank für einen Einblick.

Answer 1

Kurze Antwort auf "gibt es eine klare Unterscheidung" wäre "Nein".

Die Begriffe sind nicht ganz austauschbar, aber implizieren die gleiche grundlegende Architektur - speziell, dass Sie Ereignisse oder Nachrichten auslösen.

Der erste Artikel, den Sie referenzieren, handelt von Low-Level-Installationen, dem MOM oder Pub-Sub-Bus, der die Nachrichten in Ihrem Auftrag transportiert. Die ereignisgesteuerte Architektur baut auf diesem Framework auf.

Der Begriff ereignisgesteuert, obwohl er auch für GUI-Code gilt, ist nicht wirklich auf der gleichen Abstraktionsebene. In diesem Fall handelt es sich um ein Muster im Vergleich zum Aufbau Ihres gesamten Unternehmens entlang von Nachrichten-/Ereignislinien.

Answer 2

Ereignisgesteuerte Architekturen können mit oder ohne Messaging implementiert werden. Messaging ist eine Möglichkeit, Ereignisse, die von Produzenten an die Verbraucher weitergegeben werden, zuverlässig und garantiert zu kommunizieren. Vor allem, wenn Hersteller und Verbraucher tatsächlich entkoppelt sind und auf verschiedenen Servern/VMs/Umgebungen gehostet werden und keinen direkten Zugriff auf einen gemeinsamen Speicher haben.

In bestimmten Fällen - wenn der Benutzer des Ereignisses ist eine Funktion/Rückruf innerhalb der gleichen Anwendung registriert, oder wenn der Verbraucher synchron ausgeführt werden muss, dann kann Ereignis-Abonnement ohne Messaging implementiert werden.

Answer 3

Wie es schön in this Artikel geschrieben ist, um Event Driven Design zu verstehen, anstatt zu betrachten, was es präsentiert, müssen wir beobachten, was es verbirgt, und das ist nichts mehr als die Grundlagen der Programmierung; der "Anruf-Stapel".

Im ereignisgesteuerten Design wird die Definition des Methodenaufrufs direkt aus dem Fenster entfernt. Es gibt keinen Anrufer mehr und keinen Anruf mehr. Das ist ein Kuss auf Wiedersehen, um Reihenfolge und Reihenfolge zu nennen. System muss nicht wissen, in welcher Reihenfolge Dinge passieren müssen. Daher wird Shared Memory Space, der eine Voraussetzung für Call Stack ist, unnötig.

In einer Call-Stack-Umgebung muss jedoch nicht nur der Aufrufer wissen, was als nächstes passiert, sondern auch eine Funktionalität mit einem Methodennamen verknüpfen können.

Nachrichtenorientierte Anwendungen sind standardmäßig mit dem Entfernen von gemeinsam genutztem Speicher ausgestattet. Publisher und Abonnent müssen keinen Speicherplatz freigeben.Auf der anderen Seite sind alle anderen Merkmale (d. H. Reihenfolge, Methodennamenkopplung und dergleichen) keine Notwendigkeiten.

Wenn die Nachrichtenübergabe so konzipiert ist, dass sie den Axiomen der ereignisgesteuerten Architektur entspricht, können sie als identisch betrachtet werden. Ansonsten gibt es einen großen Unterschied zwischen ihnen.

Answer 4

Wenn wir ereignisgesteuerten Ansatz verwenden, möchten wir normalerweise das Quellobjekt in diesem Ereignis senden - Komponente, die das Ereignis veröffentlicht hat. So können wir im Abonnenten nicht nur die Daten abrufen, sondern auch wissen, wer dieses Ereignis veröffentlicht hat. Z.B. In der mobilen Entwicklung erhalten wir die Ansicht, die Button, Image oder eine benutzerdefinierte Ansicht sein kann. Und abhängig vom Typ dieser View können wir unterschiedliche Logik im Abonnenten verwenden. In diesem Fall können wir sogar eine gewisse Rückverarbeitung hinzufügen, Quellkomponente modifizieren - z. Fügen Sie dieser Quellansicht eine Animation hinzu.

Wenn wir Message-Driven-Ansatz verwenden, möchten wir nur die Nachricht mit einigen Daten veröffentlichen. Für Abonnenten, die diese Nachricht veröffentlicht haben, spielt es keine Rolle, wir möchten nur die Daten empfangen und sie auf irgendeine Weise verarbeiten.

Answer 5

Hier ist eine Typesafe/Reactive Sicht auf die Frage von Jonas Bonér. Aus dem dritten Absatz von this blog post: "Der Unterschied ist, dass Nachrichten gerichtet sind, Ereignisse sind nicht - eine Nachricht hat einen klar adressierbaren Empfänger, während ein Ereignis nur für andere passieren (0-N), um es zu beobachten."

Answer 6

Event Driven Architecture und Message Driven Architecture sind zwei verschiedene Dinge und lösen zwei verschiedene Probleme.

Event Driven Architecture Fokus ist, wie das System ausgelöst wird, um zu funktionieren. Die Mehrheit der Trigger, die als Ereignisse im Kontext von EDA betrachtet werden, sind die Ereignisse, die mit anderen Mitteln als Tastatur und Maus erzeugt werden. Es ist eine EDA, wenn uns dies explizit über Ereignisgenerator, Ereigniskanal, Ereignisverarbeitungsmodul denken lässt.

Tastatur und Maus sind offensichtliche Ereignisgeneratoren, aber die Handhabung dieser Ereignisse wird bereits von verschiedenen Frameworks oder Laufzeiten übernommen und als Architekt brauchen wir uns nicht darum zu kümmern. Es gibt andere Ereignisse, die spezifisch für eine bestimmte Domäne sind, worüber Architect voraussichtlich nachdenken wird. Beispiel - Supply Chain Management-Ereignisse - Kommissionierung, Verpackung, Versand, Verteilung, Einzelhändler, Verkauf usw. Aus technischer Sicht für industrielle IoT-Anwendungen sind die Ereignisse - RFID-Lesen, biometrisches Lesen, Sensordaten, Barcode-Scan, systemgenerierte Ereignisse sind die Ereignisse, die explizit beachtet werden müssen, da diese Ereignisse die Funktionalität des Systems steuern.

Message Driven Architecture Fokus ist die Integration der verteilten Systeme durch die Weitergabe von Nachrichten von einem Modul zu anderen Modulen des Systems mit Standard Message Oriented Middleware.

Answer 7

Diese Frage wurde schon vor langer Zeit gestellt. Ich denke, eine modernere und klare Antwort von den Reactive Manifesto in Message-Driven (in contrast to Event-Driven) gegeben:

Eine Nachricht ein Element von Daten, die zu einem bestimmten Ziel gesendet wird. Ein Ereignis ist ein Signal, das von einer Komponente bei Erreichen eines bestimmten Zustands emittiert wird. In einem nachrichtengesteuerten System warten adressierbare Empfänger auf die Ankunft von Nachrichten und reagieren darauf, ansonsten ruhend. In einer ereignisgesteuerten Systembenachrichtigung werden Listener an die Quellen von Ereignissen angehängt, so dass sie beim Auslösen des Ereignisses aufgerufen werden. Dies bedeutet, dass ein ereignisgesteuertes System sich auf adressierbare Ereignisquellen konzentriert, während sich ein nachrichtengesteuertes System auf adressierbare Empfänger konzentriert. Eine Nachricht kann ein verschlüsseltes Ereignis als Nutzlast enthalten.