Unterschiede zwischen API-Gateways und ESBs? [geschlossen]

Geschlossen. Diese Frage ist nicht zum Thema . Derzeit werden keine Antworten akzeptiert.

Möchten Sie diese Frage verbessern? Aktualisieren Sie die Frage so dass es beim Thema für Software Engineering Stapel Börse.

Geschlossen vor 5 Jahren .

Das Unternehmen, für das ich arbeite, evaluiert einige Middleware-Lösungen für Governance, Metering und Sicherheit von Webdiensten. Derzeit verwenden wir einen Enterprise Service Bus (ESB) für diesen Zweck, aber einige coole Manager haben beschlossen, eine API Management Middleware bereitzustellen.

Ich habe ein wenig über diese API-Management-Lösungen (auch API-Gateway-Lösungen genannt) recherchiert, konnte aber keinen Unterschied zwischen ihnen und den tatsächlichen ESBs feststellen. Ich habe einige Whitepapers von Mule, WSO2, Oracle usw. bewertet, aber die Funktionen beider Produkte scheinen fast gleich zu sein. Die Frage ist, was ein API-Management kann, was ein ESB nicht kann und umgekehrt. Welchen Mehrwert kann eine IT-Infrastruktur erzielen, indem ein ESB für ein API-Gateway ersetzt wird?

integration middleware

— dliber
quelle

Wie ist die Frage "Was ist der Unterschied zwischen einem API-Gateway und einem ESB?"

— Francisco d'Anconia

Der Grund, warum Sie die Konzepte durcheinander bringen, ist, dass die Anbieter sie in einem Paket verkaufen. Aber es handelt sich definitiv um getrennte Konzepte.

Ein API-Gateway bietet einen zentralen Zugriffspunkt für die Verwaltung, Überwachung und Sicherung des Zugriffs auf Ihre öffentlich zugänglichen Webdienste. Sie können damit auch Dienste auf unterschiedlichen Endpunkten konsolidieren, als stammten sie alle von einem einzigen Host. Angenommen, Sie hatten zehn verschiedene Service-Endpunkte, die alle Teil einer einzigen "Suite" von Services waren. Anstatt die Verbraucher über Ihren Dienst zu informieren, service1.yourcompany.com für einen Dienst und service2.yourcompany.com für einen anderen usw. zu verwenden, können Sie sie alle auf api.yourcompany.com/service1 oder api.yourcompany.com verweisen lassen / service2 und das Gateway sind dafür verantwortlich, die Anforderungen an die entsprechenden Endpunkte umzuleiten.

Ein ESB ist ein interner "Bus", über den Anwendungen und Dienste ungekoppelt miteinander kommunizieren können. Alle Anwendungen können sich in den Bus einhängen und jede Nachricht empfangen, die sie interessiert, wenn sie von einer anderen Anwendung veröffentlicht werden. Sie können auch ihre eigenen Nachrichten veröffentlichen, die eine andere Anwendung abhören und beantworten kann. Die Anwendungen sind nicht für die direkte Verbindung untereinander verantwortlich, sie veröffentlichen ihre Nachrichten im Bus und alle Interessenten hören zu und reagieren.

Logischerweise ist das API-Gateway kein Ersatz für einen ESB, sondern eine Erweiterung für eine serviceorientierte Architektur.

— Michael Brown
quelle

Ich glaube, das Argument für die Verwendung von ESBs ist dasselbe. ESBs sind zentrale Zugriffspunkte und können den Lastenausgleich, die Überwachung, die Erfassung und die Sicherheit von Diensten von verschiedenen Endpunkten aus durchführen. Sie können auch die URL des ESB anstelle der URL der einzelnen Dienste an die Verbraucher weitergeben. Bisher nichts Neues.

— 2.

ESB ist ein internes API-Gateway, das für den externen Gebrauch bestimmt ist. Wenn Sie ein API-Gateway intern anstelle eines ESB verwenden möchten, gibt es vermutlich nichts, das Sie daran hindert.

— Michael Brown

Genau darum geht es. Es gibt eine Überlappung der Funktionen von ESBs und API-Plattformen. Sie können einen ESB für den externen Zugriff oder eine API-Plattform für den internen Zugriff bereitstellen. Welche Vorteile bringt es, wenn beide Funktionen gleich sind? Was macht sie so unterschiedlich, dass Sie eines anstelle des anderen (oder beide zusammen) verwenden und Ihrem Unternehmen einen echten Mehrwert bieten können?

— 4.

Ein ESB ist für hohes Verkehrsaufkommen ausgelegt. Es hat normalerweise ein proprietäres oder nicht internetfreundliches Protokoll. Ein API-Gateway dient zum Übersetzen zwischen Internetprotokollen (SOAP, JSON, XML, HL7) und zum Platzieren der Anforderungen auf dem ESB. Grundsätzlich KÖNNEN Sie das Gateway für die Kommunikation zwischen Ihren internen Diensten verwenden, sodass es nicht unbedingt optimal ist.

— Michael Brown