Nachricht angetrieben vs. Ereignis Ansätze zur Integration von Anwendungen getrieben

Question

Ich frage mich, ob es eine klare Unterscheidung zwischen Nachricht angetrieben und Ereignis-Umgebungen betrieben, wenn wir zu SOA oder Middleware und in der Regel in Fällen von Anwendungs- und Unternehmensintegration beziehen. Ich verstehe, dass eine Benutzeroberfläche ein Event Driven-Modell, wo unser System fängt Aktion durch den Benutzer ähnelt.

Auch ist es klar, dass Messaging unterstützt Systeme auf Basis von Publish / Subscribe, sychronous oder asynchroner Kommunikation, Transaktionen usw.

Aber gibt es einen Unterschied in der Middleware / soa / Anwendung intergration Kontext? (Architektur-Ebene). Ich versuche, Quellen, wie wikipedia ( hier und hier ), aber ich bin immer noch ein wenig verwirrt. Wann sollte eine Lösung über den anderen Entwickler bevorzugen?

Gibt es Beispiele oder Fälle, in denen ein Ansatz mehr Sinn als der andere macht? Oder irgendwelche umfassenden Ressourcen und Führungen jede Implementierung?

Vielen Dank für jede Einsicht.

Answer 1

Kurze Antwort auf „ist es eine klare Unterscheidung“ wäre „nein“.

Die Begriffe sind nicht ganz austauschbar, aber die gleiche grundlegende Architektur bedeuten -. Insbesondere, dass Sie weg von Ereignissen oder Nachrichten Auslösung werden

Der erste Artikel, den Sie ist über die Low-Level-Sanitär-Referenz, die MOM oder Pub-Sub „Bus“, der die Nachrichten in Ihrem Namen transportiert. Die ereignisgesteuerte Architektur ist das, was Sie am Anfang dieses Rahmens zu bauen.

Der Begriff ereignisgesteuert, während auch GUI-Code angewandt wird, ist nicht wirklich auf dem gleichen Niveau der Abstraktion. In diesem Fall ist es ein Muster in-the-klein im Vergleich zu Ihrem gesamten Unternehmen entlang Nachricht / Event Driven Linien zu bauen.

Answer 2

Hier ist ein Typesafe / Reactive Sicht auf die Frage von Jonas Boner. Ab dem dritten Absatz von rel="noreferrer">:

  

Der Unterschied ist, dass die Nachrichten gerichtet sind, Ereignisse nicht - eine Meldung einen klaren adressierbare Empfänger hat, während ein Ereignis nur für die andere passiert (0-N), sie zu beobachten

.

Answer 3

Diese Frage wurde vor langer Zeit gefragt. Ich denke, eine modernere und klare Antwort von der rel="noreferrer"> in Message-Driven (im Gegensatz zu ereignisgesteuerten) :

  

Eine Nachricht ist ein Element von Daten, die zu einem bestimmten Ziel gesendet wird. Ein Ereignis ist ein Signal von einer Komponente emittiert wird, auf einen gegebenen Zustand zu erreichen. In einer Message-Driven System erwarten adressierbare Empfänger die Ankunft von Nachrichten und auf sie zu reagieren, sonst schlummert. In einem ereignisgesteuerten System Benachrichtigung Hörer sind mit den Ereignisquellen angebracht, dass sie aufgerufen werden, wenn das Ereignis abgegeben wird. Das bedeutet, dass ein ereignisgesteuertes System auf adressierbare Ereignisquellen konzentriert, während ein Message-Driven System auf adressierbare Empfänger konzentriert. Eine Nachricht kann ein codiertes Ereignis als seine Nutzlast enthalten.

Answer 4

Veranstaltungen angetrieben Architekturen können mit oder ohne Messaging implementiert werden. Messaging ist eine Möglichkeit, Ereignisse von den Produzenten zu den Verbrauchern eine zuverlässige, garantierte Weise erhöht zu kommunizieren. Vor allem, wenn Produzenten und Konsumenten sind wirklich entkoppelt und können auf verschiedenen Servern / VMs / Umgebungen gehostet werden und haben keinen direkten Zugriff auf alle gemeinsam genutzten Speicher.

Doch in bestimmten Fällen - wenn der Verbraucher des Ereignisses eine Funktion / Rückruf innerhalb derselben Anwendung registrierte selbst, oder wenn die Verbraucher synchron ausgeführt werden muss, dann Ereignisse-Abonnement kann ohne Messaging implementiert wird

.

Answer 5

Angenommen, Sie bauen einen Payment Service für eine E-Commerce-Website. Wenn ein Auftrag erteilt wird, wird der Bestellservice Ihren Payment Service stellt die Kundenkreditkarte zu autorisieren. Erst wenn die Kreditkarte wurde der Bestellservice den Auftrag an das Lager für Verpackung und Versand senden.

zugelassen wird

Sie müssen sich mit dem Team arbeitet an dem Bestellservice auf, wie dieser Antrag für Kreditkartenautorisierung vereinbaren ist von ihrem Dienst zu Ihnen geschickt. Es gibt zwei Möglichkeiten.

• Message-driven : Wenn ein Auftrag erteilt wird, sendet der Bestellservice zu Ihrem Zahlungsdienst eine Genehmigungsanfrage. Ihr Service verarbeitet die Anforderung und gibt Erfolg / Misserfolg an den Bestellservice. Die ursprüngliche Anforderung und das Ergebnis gesendet synchron oder asynchron werden.
• Event-Driven : Wenn ein Auftrag erteilt wird, der Bestellservice veröffentlicht eine NewOrder Veranstaltung. Ihr Zahlungsdienst abonniert hat diese Art der Veranstaltung, so dass es ausgelöst wird. Ihr Service bearbeitet die Anfrage und entweder veröffentlicht einen AuthorizationAccepted oder ein AuthorizationDeclined Ereignis. Der Bestellservice abonniert diesen Ereignistyp. Alle Veranstaltungen sind asynchron.

Ein Vorteil des ereignisgesteuerten Ansatzes ist, dass andere Dienstleistungen als auch zu den verschiedenen Veranstaltungen abonnieren können. Zum Beispiel könnte es ein RevenueReporting Dienst sein, der zu AuthorizationAccepted Ereignisse abonniert und erstellten Berichte für das Finanzteam.

Ein Nachteil der ereignisgesteuerten Ansatz ist, dass das System als Ganzes ein wenig schwieriger zu verstehen wird. Zum Beispiel, sagen sie, das Team auf dem Bestellservice arbeitet, fragen Sie das AuthorizationDeclined Ereignis mit verschiedenen Veranstaltungen zu ersetzen, je nach, warum die Kreditkarte abgelehnt wurde (kein Geld, Konto geschlossen, Rechnungsadresse falsch, etc). Wenn Sie AuthorizationDeclined Ereignisse veröffentlichen stoppen, wird die andere Dienste brechen da draußen? Wenn Sie viele Veranstaltungen und Dienstleistungen haben, kann dies schwierig sein, nach unten zu verfolgen.

Answer 6

Wie es schön in diesem Artikel gesetzt wird, um Event-Driven Design zu verstehen anstatt zu schauen, was es präsentiert müssen wir beobachten, was es verbirgt, und das ist nichts anderes als die sehr einfache Programmierung; die "Call Stack".

In Event Driven Design der Definition des Methodenaufrufes geht nach rechts aus dem Fenster. Es gibt keine mehr Anrufer und Angerufenen. Das ist ein Abschiedskuss Sequenz und Ordnung zu rufen. System muss nicht wissen, in welcher Reihenfolge die Dinge geschehen sind. Daher, gemeinsam genutzten Speicherraum, die eine Voraussetzung für Call Stack ist, unnötig wird.

In einem Call-Stack-Umgebung jedoch nicht nur der Anrufer muss wissen, was als nächstes passiert, aber es muss in der Lage sein, eine Funktionalität zu einem Methodennamen zuzuordnen.

Nachrichtenorientierte Anwendungen standardmäßig kommen mit der Entfernung von Shared Memory. Publisher und Teilnehmer brauchen keinen Speicherplatz zu teilen. Auf der anderen Seite, sind alle anderen Funktionen (das heißt Ordnung, Methodennamen Kupplung und so weiter) sind nicht Notwendigkeiten.

Wenn Message Passing befähigt ist, um mit den Axiomen der ereignisgesteuerten Architektur zu erfüllen, könnten sie als identisch angesehen werden. Ansonsten gibt es einen großen Unterschied zwischen ihnen.

Answer 7

Wenn wir ereignisgesteuerten Ansatz verwenden, wollen wir in der Regel das Quellobjekt in diesem Fall senden - Komponente, die das Ereignis veröffentlicht. Also Teilnehmer können wir nicht nur die Daten erhalten, sondern auch zu wissen, wer diese Veranstaltung veröffentlicht. Z.B. in der mobilen Entwicklung erhalten wir die Ansicht, die Taste sein kann, Bild oder eine benutzerdefinierte Ansicht. Und je nach Art dieser Ansicht können wir verschiedene Logik Teilnehmer verwenden. In diesem Fall können wir sogar einige Back-Verarbeitung hinzuzufügen, Quellkomponente ändern - z.B. hinzufügen Animation jener Quelle ansehen.

Wenn wir Message-Driven Ansatz verwenden, wollen wir nur die Nachricht mit einigen Daten veröffentlichen. Es spielt keine Rolle für Teilnehmer, die diese Nachricht veröffentlicht, wir wollen nur die Daten empfangen und es irgendwie zu verarbeiten.

Answer 8

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

Event Driven Architecture Fokus liegt darauf, wie System ausgelöst wird, funktionieren. Die Mehrheit der Auslöser, die als Ereignisse im Zusammenhang mit der EDA gedacht sind, sind die durch andere Mittel als Tastatur und Maus generierte Ereignisse. Es ist ein EDA, wenn diese uns ausdrücklich über Ereignisgenerator, Ereigniskanal, Event-Processing-Engine macht denken.

Tastatur und Maus sind offensichtlich Ereignisgeneratoren jedoch diese Ereignisse Handhabung wird bereits von verschiedenen Frameworks oder Runtimes und als Architekt betreut wir nicht brauchen, um es zu sorgen. Es gibt auch andere Ereignisse, die auf bestimmte Domäne spezifisch sind, was Architekt, darüber nachzudenken, wird erwartet. Beispiel - Supply Chain Management Events - Pick, Pack, Versand, Vertrieb, Händler, verkauft usw. Aus technischer Sicht für Industrie IoT Art der Anwendungen, die Ereignisse sind - RFID Read, Bio-metric lesen, Sensordaten, Barcode-Scan, System generiert Ereignisse die Ereignisse, die gepflegt explizit werden muss, da diese Ereignisse die Funktionalität des Systems fahren.

Message Driven Architecture Fokus ist es, die verteilte Systeme zu integrieren, indem sie Nachrichten von einem Modul zum anderen Module des Systems unter Verwendung von Standard Message Oriented Middleware übergeben.

Answer 9

Das Meldekonzept ist abstrakt, konkretere Nachrichtentypen sind Ereignis und Befehl.

Während Nachrichten überhaupt keine besondere Absicht haben, Ereignisse über etwas informieren, das geschehen ist und bereits abgeschlossen ist (in der Vergangenheit). Befehle auslösen etwas, was (in der Zukunft) geschehen soll.