fb
Enterprise Integration 5 Minuten

API-Gateway vs. ESB

ESB: von API-Gateways überholt? Oder immer noch praktisch in der Integrationslandschaft?

Yenlo
Integration Experts
Blog API Gateway vs ESB
Scrollen

Enterprise Service Bus (ESB), einst eine gefeierte Lösung für die Komplexität des Protokolls der serviceorientierten Architektur. Aber sind die Tage der zentralisierten Integration von Anwendungen gezählt? Und wird die Entwicklung von API-Gateways und Microservices ausreichen, um alle möglichen Anwendungsfälle für Unternehmensintegrationen zu bewältigen? Werfen wir einen Blick auf API Gateway vs. ESB.

Was ist ein API-Gateway und was ist ESB?

Was ist ein API-Gateway?

Ein API-Gateway ist ein Server, der die Anfragen für APIs (Application Programming Interface) bearbeitet. Ein API-Gateway ist ein Proxy, der für den Client bereitgestellt wird. API-Gateway bietet dem Client eine einheitliche Schnittstelle, unabhängig von Änderungen im internen System. Es ermöglicht dem internen System, sich zu ändern, ohne dass dies Auswirkungen auf den Client hat. Das API-Gateway kann auch konsistente übergreifende Belange wie Sicherheitsprotokollierung, Berichtswesen und API-Analysen bereitstellen.

Was ist ein ESB?

Wie ein API-Gateway ist auch ein ESB (Enterprise Service Bus) ein Ansatz zur Verbindung von Diensten. Dabei handelt es sich um ein Architektur-Muster, bei dem eine zentralisierte Softwarekomponente die Integration zwischen Anwendungen durchführt. Ein ESB bietet die Möglichkeit der Kommunikation von Service zu Service, indem er Datenmodelle umwandelt, Verbindungen herstellt, Nachrichten weiterleitet und Kommunikationsprotokolle umwandelt.

Welche Funktionalitäten haben API-Gateways und ESBs?

Beim Vergleich zwischen ESB und API-Gateway ist es wichtig, die Funktionen beider Systeme zu betrachten. Vor allem, was beide gut können, um herauszufinden, worin sie sich voneinander unterscheiden. Hier erklären wir die Funktionen, die sowohl in API-Gateways als auch in ESBs zu finden sind.

Routing

Was ist Routing? Eine eingehende Anfrage wird von Ihrem Server gelesen und auf der Grundlage der angegebenen Parameter auf URL-Ebene an die gewünschte API weitergeleitet.

Authentication

Was ist Authentication? Bei der Authentication wird festgestellt, ob ein Benutzer oder ein bestimmtes System gültig ist und akzeptiert werden kann.

Authorization

Was ist Authorization? Die Funktionalität der Authorization bezieht sich darauf, ob ein bestimmtes System oder ein Benutzer eine bestimmte Operation durchführen darf. Ein bestimmter Benutzer gehört zum Beispiel zu einer bestimmten Gruppe. Und nur diese Gruppe ist berechtigt, Daten zu erstellen oder zu aktualisieren. 

Policy Management

Was ist Policy Management? Policy Management definiert, wie auf einen Webdienst zugegriffen werden soll. Und darüber hinaus, auf welche Teile eines Webdienstes der Benutzer auf welche Weise zugreifen soll. 

Payload Transform

Was ist Payload Transform? Nachrichten kommen in unterschiedlichen Größen und Formaten auf Ihrem Server an. Payload ist im Grunde das Containerformat der Nachricht. Bei der Nutzdatenumwandlung geht es also darum, das Format der eingehenden Nachricht so umzuwandeln, dass es mit dem Format übereinstimmt, das Ihr Webdienst lesen kann. Ein Beispiel: Eine Anfrage kommt bei Ihrem API-Gateway oder ESB in einem XML-Format an, und Ihr Webdienst basiert auf dem JSON-Format. Sobald die Anforderung eingeht, wandelt Ihr API-Gateway oder ESB diese XML-Meldung in ein JSON-Format um.

Common Protocol

Was ist ein Common Protocol? Unter Common Protocol versteht man die Kommunikation zwischen verschiedenen heterogenen wie auch homogenen Systemen. Ein Common Protocol könnte also sein, dass alle Systeme zum Beispiel HTTP, TFTP oder SMTP verwenden. 

Validation & Enrichment of Payload

Was ist eine Validation und Enrichment of Payload? Betrachten wir zunächst die Validation of Payload. Es gibt zwei Arten von Validation: 1. Format Validation und 2. Content Validation. Die Format Validation stellt fest, ob die Struktur der Anfrage richtig oder falsch ist, wie vom Policy Management definiert. Content Validation bedeutet, ob das Format einen gültigen Wert enthält oder nicht. Diese beiden Arten der Validation können sowohl auf API-Gateway- als auch auf ESB-Ebene durchgeführt werden. Der Begriff Enrichment bedeutet, dass Sie beim Eingang einer Anfrage zusätzliche Werte hinzufügen können, vielleicht im Body, vielleicht im Header-Bereich.

FunctionalityAPIESB
Routing
Authentication
Authorization
Policy Management
Payload Transform
Common Protocol
Validation & Enrichment of Payload

Wann sollte man ESB und wann API Gateway einsetzen?

Wenn man sich die obige Tabelle ansieht, könnte man behaupten, dass sie beide die gleichen Funktionen zur Handhabung von Integrationen ausführen. Warum also zu einem moderneren Ansatz mit API-Gateways wechseln?

Die letzten drei Funktionen – Payload Transform, Common Protocol und Validation & Enrichment of Payload – betreffen hauptsächlich die Änderung der geschäftlichen Logik. Die Geschäftslogik ist die Menge der benutzerdefinierten Regeln oder Algorithmen, die den Informationsaustausch zwischen einer Datenbank und der Benutzeroberfläche regeln. Diese eignen sich viel besser für eine zentralisierte Komponente (ESB) als für ein API-Gateway.

Warum sollten Sie die Geschäftslogik nicht in den API-Gateway integrieren? Sobald Sie dem Gateway Geschäftslogik hinzufügen, verhält es sich wie ein ESB. Das bedeutet, dass zentralisierte Datenaggregation und Business-Transformation, die manuell geschriebenen Code erfordern, im Gateway implementiert werden. Jedes Stück Code verursacht CPU-Zyklen. Dies beeinträchtigt die Leistung, belastet die teamübergreifende Kommunikation und führt zu zusätzlichen Wartungs- und Supportproblemen.

Auf der anderen Seite gibt es eine Reihe von Nachteilen bei einem ESB. Er ist schwerfällig, was die Ressourcennutzung angeht. Er ist weniger schnell oder skalierbar – insbesondere bei der Verwendung von Microservices. Das Hauptproblem ist, dass ESBs einen Single Point of Failure (SPOF) haben, so dass Sie mehrere ESBs benötigen, was die Komplexität und Infrastruktur erhöht. Dies führt letztlich zu größeren Teams und steigenden Kosten.

Beim Vergleich von API-Gateway und ESB sollte man sich also idealerweise für ein API-Gateway entscheiden, das aber nicht die Nutzung aller Funktionen des Servers ermöglicht. Oder gäbe es eine andere Lösung?

Abschließend: ESB, API Gateway oder eine Kombination für Ihre Integrationslösung?

Der einfachste Weg wäre, eine Kombination aus ESB und API-Gateway zu wählen. Routing, Authorization, Authentication und Policy Management im API Gateway und die restlichen drei im ESB. Nur müssten Sie dann (teilweise) eine zentrale Architektur aufbauen, aber Microservices und APIs laufen lieber in verteilten Architekturen.

Die Lösung? Sie könnten einen Microservice als Smart Endpoint erstellen, der die Funktionalität eines ESB nachahmt und die Aufgaben Payload Transform, Common Protocol und Validation & Enrichment of Payload nutzt. Anschließend können Sie die Geschäftslogik in diesem Smart Endpoint haben. In diesem speziellen Architektur-Setup sehen Sie zwei verschiedene Arten von Microservices: Composite Microservice und Base Microservice. Der Composite Microservice fungiert als ESB und der Base Microservice tut das, was Microservices tun sollen. Ihr Setup verfügt dann über alle Funktionalitäten, die Sie für einen Server benötigen, und da es sich innerhalb eines API-Gateways befindet, sind Sie für eine API-first digitale Transformation bestens gerüstet.

Sie möchten mehr über API Gateways erfahren und wissen, was die richtige Einrichtung für Ihr Unternehmen ist? Kontaktieren Sie unser Team. Und finden Sie heraus, wie Yenlo’s Integration-Platform-as-a-Service ‚Connext Platform‚ und Integration-as-a-Service Lösung ‚Connext Go!‚ Ihnen helfen kann, in Ihrer Branche führend zu sein.