Ein Nachrichtenbroker ist eine Software, die es Anwendungen, Systemen und Diensten ermöglicht, miteinander zu kommunizieren und Informationen auszutauschen. Der Nachrichtenbroker bewerkstelligt dies durch das Übersetzen von Nachrichten zwischen formalen Messaging-Protokollen. Dadurch können voneinander abhängige Dienste direkt miteinander „sprechen“, auch wenn sie in verschiedenen Sprachen geschrieben oder auf unterschiedlichen Plattformen implementiert wurden.

Nachrichtenbroker sind Software-Module innerhalb von Messaging-Middleware- oder Message-Oriented-Middleware-Lösungen (MOM). Dieser Middleware-Typ stellt Entwicklern ein standardisiertes Mittel zur Verfügung, um den Datenfluss zwischen den Komponenten einer Anwendung zu verarbeiten, damit sie sich auf ihre Basislogik konzentrieren können. Sie kann als verteilte Kommunikationsschicht dienen, die es Anwendungen, die mehrere Plattformen umfassen, ermöglicht, intern zu kommunizieren.

Nachrichtenbroker können Nachrichten validieren, speichern, weiterleiten und an die entsprechenden Ziele zustellen. Sie dienen als Vermittler zwischen anderen Anwendungen und ermöglichen es Sendern, Nachrichten auszugeben, ohne zu wissen, wo die Empfänger sind, ob sie aktiv sind oder nicht, oder wie viele von ihnen es gibt. Dies erleichtert die Entkopplung von Prozessen und Services innerhalb von Systemen.

Um eine zuverlässige Speicherung von Nachrichten und eine garantierte Zustellung zur Verfügung zu stellen, stützen sich Nachrichtenbroker häufig auf eine Unterstruktur oder Komponente, die als Nachrichtenwarteschlange bezeichnet wird und die Nachrichten speichert und ordnet, bis die konsumierenden Anwendungen sie verarbeiten können. In einer Nachrichtenwarteschlange werden die Nachrichten genau in der Reihenfolge gespeichert, in der sie übermittelt wurden, und bleiben in der Warteschlange, bis der Empfang bestätigt wird.

Asynchrone Nachrichtenübermittlung (15:11) bezieht sich auf die Art der anwendungsübergreifenden Kommunikation, die Nachrichtenbroker ermöglichen. Sie verhindert den Verlust wertvoller Daten und ermöglicht es, dass Systeme auch bei unterbrochener Konnektivität oder Latenzproblemen, die in öffentlichen Netzen häufig auftreten, weiter funktionieren. Die asynchrone Nachrichtenübermittlung garantiert, dass Nachrichten einmal (und nur einmal) in der richtigen Reihenfolge im Verhältnis zu anderen Nachrichten zugestellt werden.

Nachrichtenbroker können Warteschlangenmanager umfassen, um die Interaktionen zwischen mehreren Nachrichtenwarteschlangen zu handhaben, sowie Dienste, die Datenrouting, Nachrichtenübersetzung, Persistenz und Clientstatus-Management-Funktionen bereitstellen.

Nachrichtenbroker bieten zwei grundlegende Nachrichtenverteilungsmuster oder Messaging-Arten:

Punkt-zu-Punkt-Messaging: Dies ist das Verteilungsmuster, das in Nachrichtenwarteschlangen mit einer Eins-zu-Eins-Beziehung zwischen dem Absender und dem Empfänger der Nachricht verwendet wird. Jede Nachricht in der Warteschlange wird an nur einen Empfänger gesendet und nur einmal konsumiert. Punkt-zu-Punkt-Messaging wird aufgerufen, wenn auf eine Nachricht nur einmal reagiert werden muss. Beispiele für geeignete Anwendungsfälle für diesen Messaging-Stil sind die Verarbeitung von Lohnbuchhaltung und Finanztransaktionen. In diesen Systemen benötigen sowohl Absender als auch Empfänger eine Garantie, dass jede Zahlung einmal (und nur einmal) gesendet wird.

Publish/Subscribe-Messaging: Bei diesem Nachrichtenverteilungsmuster, das oft als „Pub/Sub“ bezeichnet wird, veröffentlicht der Erzeuger jeder Nachricht diese in einem Thema, und mehrere Nachrichtenkonsumenten abonnieren Themen, von denen sie Nachrichten erhalten möchten. Alle Nachrichten, die zu einem Thema veröffentlicht werden, werden an alle subskribierten Anwendungen verteilt. Hierbei handelt es sich um eine Verteilungsmethode im Broadcast-Stil, bei der eine Eins-zu-viele-Beziehung zwischen dem Publisher der Nachricht und ihren Konsumenten besteht. Wenn eine Fluggesellschaft beispielsweise aktuelle Informationen über die Landezeiten oder Verspätungen ihrer Flüge verbreitet, könnten mehrere Parteien diese Informationen nutzen: Bodenpersonal, das das Flugzeug wartet und auftankt, Gepäckabfertiger, Flugbegleiter und Piloten, die sich auf den nächsten Flug vorbereiten, sowie die Betreiber von Bildschirmen, die die Öffentlichkeit informieren. Ein Publish/Subscribe-Messaging-Stil wäre für die Verwendung in diesem Szenario geeignet.

Cloudnative Anwendungen werden entwickelt, um die inhärenten Vorteile von Cloud Computing zu nutzen, einschließlich Flexibilität, Skalierbarkeit und schneller Bereitstellung. Diese Anwendungen bestehen aus kleinen, diskreten, wiederverwendbaren Komponenten, den so genannten Microservices. Jeder Microservice wird implementiert und kann unabhängig von den anderen ausgeführt werden. Dies bedeutet, dass einer von ihnen ohne Auswirkungen auf andere Services im System aktualisiert, skaliert oder neu gestartet werden kann. Oftmals in Containern verpackt, arbeiten Microservices zusammen, um eine ganze Anwendung zu bilden, obwohl jeder seinen eigenen Stack hat, einschließlich einer Datenbank und eines Datenmodells, das sich von den anderen unterscheiden kann.

Microservices müssen miteinander kommunizieren können, um zusammenarbeiten zu können. Nachrichtenbroker sind ein Mechanismus, mit dem sie dieses gemeinsame Kommunikations-Backbone erzeugen.

Nachrichtenbroker werden häufig zur Verwaltung der Kommunikation zwischen lokalen Systemen und Cloud-Komponenten in Hybrid-Cloud-Umgebungen eingesetzt. Durch die Verwendung eines Nachrichtenbrokers wird die Steuerung der Interservice-Kommunikation erhöht, wodurch sichergestellt wird, dass die Daten sicher, zuverlässig und effizient zwischen den Komponenten einer Anwendung gesendet werden. Nachrichtenbroker können eine ähnliche Rolle bei der Integration von Multicloud-Umgebungen spielen, indem sie die Kommunikation zwischen Workloads und Laufzeiten auf verschiedenen Plattformen ermöglichen. Sie eignen sich auch gut für den Einsatz im Serverless Computing, bei dem einzelne in der Cloud gehostete Dienste bedarfsgerecht und auf Anfrage ausgeführt werden.

REST-APIs werden in der Regel für die Kommunikation zwischen Microservices verwendet. Der Begriff „Representational State Transfer“ (REST) definiert eine Reihe von Prinzipien und Einschränkungen, die Entwickler bei der Erstellung von Web-Services beachten können. Alle Services, die sich daran halten, können über einen Satz einheitlicher, gemeinsam genutzter statusunabhängiger Operatoren und Anfragen kommunizieren. Application Programming Interface (API) bezeichnet den zugrunde liegenden Code, der es den Services ermöglicht, miteinander zu kommunizieren, wenn er den REST-Regeln entspricht.

REST-APIs verwenden Hypertext Transfer Protocol (HTTP) zur Kommunikation. Da es sich bei HTTP um das Standardübertragungsprotokoll des öffentlichen Internets handelt, sind REST-APIs allgemein bekannt, häufig verwendet und weitgehend interoperabel. HTTP ist jedoch ein Anforderungs-/Antwortprotokoll, sodass es am besten in Situationen verwendet wird, die eine synchrone Anforderung/Antwort erfordern. Dies bedeutet, dass Services, die Anforderungen über REST-APIs stellen, so konzipiert sein müssen, dass sie eine sofortige Antwort erwarten. Wenn der Client, der die Antwort empfängt, inaktiv ist, wird der sendende Service blockiert, während er auf die Antwort wartet. Failover und Fehlerbehandlungslogik sollten in beide Services integriert sein.

Nachrichtenbroker ermöglichen die asynchrone Kommunikation zwischen Diensten, sodass der sendende Dienst nicht auf die Antwort des empfangenden Dienstes warten muss. Dies verbessert die Fehlertoleranz und Ausfallsicherheit in den Systemen, in denen sie eingesetzt werden. Darüber hinaus erleichtert die Verwendung von Nachrichtenbrokern die Skalierung von Systemen, da ein Publish/Subscribe-Messaging-Muster eine Änderung der Anzahl von Services ohne Weiteres unterstützen kann. Nachrichtenbroker überwachen auch den Zustand der Verbraucher.

Während Nachrichtenbroker zwei oder mehr Nachrichtenmuster unterstützen können, darunter Nachrichtenwarteschlangen und Pub/Sub, bieten Event-Streaming-Plattformen nur Pub/Sub-artige Verteilungsmuster. Konzipiert für die Verwendung mit hohen Nachrichtenvolumen, sind Event-Streaming-Plattformen leicht skalierbar. Sie sind in der Lage, Datensatzströme in Kategorien zu bestellen, die Themen genannt werden, und sie für eine bestimmte Zeit zu speichern. Im Gegensatz zu Nachrichtenbrokern können Event-Streaming-Plattformen jedoch nicht die Zustellung von Nachrichten garantieren oder nachverfolgen, welche Verbraucher Nachrichten erhalten haben.

Event-Streaming-Plattformen bieten mehr Skalierbarkeit als Nachrichtenbroker, aber weniger Funktionen, die Fehlertoleranz gewährleisten (z. B. erneutes Senden von Nachrichten), sowie eingeschränktere Funktionen für das Nachrichten-Routing und die Warteschlangenbildung.

Erfahren Sie mehr über ereignisgesteuerte Architektur.

Ein Enterprise Service Bus (ESB) ist ein Architekturmuster, das manchmal in serviceorientierten Architekturen verwendet wird, die in Unternehmen implementiert werden. In einem ESB kombiniert eine zentrale Softwareplattform Kommunikationsprotokolle und Datenformate in eine „gemeinsame Sprache“, die alle Services und Anwendungen in der Architektur gemeinsam nutzen können. Sie kann beispielsweise die von einem Protokoll (z. B. XML) empfangenen Anforderungen in ein anderes (z. B. JSON) übersetzen. ESBs transformieren ihre Nachrichtennutzdaten mithilfe eines automatisierten Prozesses. Die zentralisierte Softwareplattform übernimmt auch andere Koordinationslogiken, wie Konnektivität, Routing und Anforderungsverarbeitung.

ESB-Infrastrukturen sind jedoch komplex und können schwierig zu integrieren und teuer in der Wartung sein. Die Fehlerbehebung ist schwierig, wenn in Produktionsumgebungen Probleme auftreten, sie sind nicht einfach zu skalieren und die Aktualisierung ist mühsam.

Nachrichtenbroker sind eine „schlanke“ Alternative zu ESBs, die eine ähnliche Funktion – einen Mechanismus für die Kommunikation zwischen den Diensten – einfacher und kostengünstiger bereitstellen. Sie eignen sich gut für den Einsatz in Microservices-Architekturen, die sich immer mehr durchgesetzt haben, da ESBs nicht mehr so beliebt sind.

Die Implementierung von Nachrichtenbrokern kann für eine Vielzahl von Geschäftsanforderungen in verschiedenen Branchen und in unterschiedlichen Computerumgebungen von Unternehmen eingesetzt werden. Sie sind immer und überall dort nützlich, wo eine zuverlässige Kommunikation zwischen den Anwendungen und eine gesicherte Nachrichtenübermittlung erforderlich sind.

Nachrichtenbroker werden häufig auf folgende Weise eingesetzt:

• Finanztransaktionen und Zahlungsabwicklung: Es ist von entscheidender Bedeutung, dass Zahlungen nur ein einziges Mal getätigt werden. Die Verwendung eines Nachrichtenbrokers zur Verarbeitung dieser Transaktionsdaten bietet die Zusicherung, dass Zahlungsinformationen weder verloren gehen noch versehentlich dupliziert werden, ein Empfangsnachweis erbracht wird und Systeme auch dann zuverlässig kommunizieren können, wenn die intermediären Netze inaktiv sind.
  
  
• E-Commerce Bestellbearbeitung und administrative Abwicklung: Wenn Sie im Online-Geschäft tätig sind, hängt der gute Ruf Ihrer Marke von der Zuverlässigkeit Ihrer Website und Ihrer E-Commerce-Plattform ab. Die Fähigkeit von Nachrichtenbrokern, die Fehlertoleranz zu erhöhen und zu garantieren, dass Nachrichten einmal (und nur einmal) konsumiert werden, macht sie zu einer natürlichen Wahl für die Verarbeitung von Online-Bestellungen.
  
  
• Schutz hochsensibler Daten im Ruhezustand und bei der Übertragung: Wenn Ihre Branche stark reguliert ist oder Ihr Unternehmen mit erheblichen Sicherheitsrisiken konfrontiert ist, sollten Sie sich für eine Messaging-Lösung mit durchgängigen Verschlüsselungsfunktionen entscheiden.