ESBs (Enterprise Service Bus) sollten Abhilfe schaffen, indem sie einen zentralen Bus für die Integration von Anwendungen bereitstellen. Ursprünglich geplant war, auf diese Weise den ESB zu einem zentralen, monolithischen Integrationspunkt auszubauen.
Doch die Welt hat sich verändert. Statt alles in einer monolithischen Lösung zu konsolidieren, begannen Unternehmen damit, unzählige Anwendungen in ihre Abläufe zu integrieren, die sie sowohl on-premise als auch aus der Cloud beziehen. Lightweight-Web-APIs bilden oft die Basis für mobile oder Rich-Web-Anwendungen. Doch wo würde in diesem Fall ein ESB sitzen? Wie würde sich ein ESB, der nicht für Web-APIs gebaut ist, in der neuen API-orientierten Welt verhalten? Plötzlich sind ESBs Teil des Problems und nicht mehr Teil der Lösung.
Den Bus abhängen
Foto: Axway
Beim herkömmlichen IT-Architekturmodell ist die webbasierte Darstellungsschicht mit einem Gateway in der DMZ und dann über einen ESB mit einer Datenserviceschicht verbunden. Das sind jede Menge Hops, das heißt: Der Weg von einem Netzknoten zum nächsten ist relativ lang. Diese komplizierte Infrastruktur sorgt für zusätzliche Komplexität sowie Verzögerungen und widerspricht dem Wesen einer guten Unternehmensarchitektur vollkommen.
Beim Übertragen der herkömmlichen Architektur auf die mobile Welt wird das Problem offensichtlich. Jeder Enterprise-Architekt wird sich fragen, warum es so viele Hops gibt.
Foto: Axway
Eine Alternative für das Management der heutigen Architektur ist die Verwendung eines API-Servers. Er ermöglicht den Application Stack der nächsten Generation: Apps am Front-End, eine Verbindung zur API-Schicht und Datenservices am Back-End. Der API-Server vereinfacht die API-Schicht, indem er den API-Kontakt mit der eigentlichen Bereitstellung der API kombiniert. Die Folge sind weniger bewegliche Teile, geringere Kosten und weniger Sicherheitsaufwand. Im Gegensatz zu einem ESB, der nicht in der DMZ platziert werden kann, ist ein API-Server als erster Kontaktpunkt für Apps ausgelegt. Der API-Server fungiert dann nicht einfach nur als Gateway, sondern bedient die API selbst.
Die API-Welt für Cloud-basierte Services
Einen ESB abzuschaffen bedeutet nicht, auf seine Funktion zu verzichten - diese wird lediglich auf den API-Server übertragen. Der API-Server hat einen entscheidenden Mehrwert: Er kann nicht nur mit internen Services arbeiten, wie es ein ESB tut, sondern auch Cloud-basierte Services umfassen. Denn längst ist es Realität, dass Unternehmen Cloud-basierte Dienste über APIs ebenso stark nutzen wie On-Premise-Services.
|
Merkmal |
Enterprise Service Bus |
API-Server |
|
API-fähig |
Nein |
Ja |
|
Sicherheitsfähig |
Nein |
Ja |
|
Mobile-API-fähig |
Nein |
Ja |
|
Servicevirtualisierung |
Ja |
Ja |
|
OAuth-Unterstützung |
Nein |
Ja |
|
REST-Unterstützung |
Nein |
Ja |
|
Protokollvermittlung |
Ja |
Ja |
|
Messaging & Routing |
Ja |
Ja |
Der API-Server wurde für die API-Welt entwickelt, der ESB hingegen nicht. Deshalb bietet ein ESB zwar Funktionen wie Messaging und Vermittlung, ist aber weder API- noch Mobile-API-fähig.
Kosten im Blick behalten
Ein weiterer Aspekt, der berücksichtigt werden muss, sind die Kosten des ESB. Oftmals leistet der ESB nicht mehr als Virtualisierungs- und Umwandlungsdienste. Die zusätzlichen Kosten und Wartungsgebühren sind also kaum zu rechtfertigen. Organisationen sollten die API-Technologie nutzen, um veraltete ESBs auszumustern. Die Zeit ist reif, sie durch etwas zu ersetzen, was für die neue API-Welt konzipiert wurde und native Unterstützung für REST und Web-Services sowie die native Unterstützung für OAuth bietet.
Provisorische ESB-Notlösungen helfen heute kaum mehr. Darüber hinaus ermöglicht es der API-Server Organisationen, die Governance von der SOA-Welt auf APIs zu erweitern. Dies ist ein wesentlicher Aspekt, den Gartner als "Application Service Governance" bezeichnet und den ESBs nicht bieten können.
Fazit
IT-Architekten sollten die Anwendungen von heute nicht länger mithilfe der Infrastruktur von gestern - dem ESB - bereitstellen. Es ist Zeit, ernsthaft über den Nutzen von ESBs nachzudenken und eine API-orientierte Alternative in Betracht zu ziehen. (hal)