Monolithen sind ein alter Zopf und neue Architekturen gewinnen an Bedeutung. Dies betrifft auch die Schnittstellenarchitektur. Neue Ansätze sind gefragt. Weshalb APIs gekapselt werden sollten und was eine API-gesteuerte Verbindungsarchitektur ist, erfahrt ihr hier.
Monolithische Architekturen sind langsam am Aussterben und mit ihnen auch die klassischen Punkt zu Punkt (P2P) Verbindungen. Denn es gab kaum ein Monolith, der nicht irgendwie trotzdem mit einem weiteren System über eine Schnittstelle kommunizieren musste. Für neue moderne Architekturen wie zum Beispiel die Microservice Architektur spielen Programmierschnittstellen (API) eine zentrale Rolle. Nun kann man sich vorstellen, wie unübersichtlich und redundant die Schnittstellenarchitektur bei der klassischen P2P Verbindungsarchitektur aussehen könnte. Eine Lösung hierfür ist eine Middleware, die als eine zentrale Informationsaustausch-Plattform dient. Die folgende Grafik veranschaulicht die unterschiedlichen Verbindungsarchitekturen:
Kapselung von APIs mittels drei Ebenen
Würde man nun innerhalb der Middleware auch wieder P2P Verbindungen bauen, würde der Sinn einer solchen Lösung klar verfehlt werden. Ein wesentlich besserer Ansatz ist deshalb eine API-gesteuerte Verbindungsarchitektur. Dieser Ansatz baut auf drei API Ebenen auf, welche eine Kapselung der APIs erlaubt. Diese Ebenen können zum Beispiel wie folgt aussehen:
System APIs: Eine System API ist direkt mit dem System verbunden. Die Daten werden unbearbeitet vom Backend System weiter an die Process API weitergegeben. Zudem schreibt eine System API auch Daten, die sie von einer Process API erhalten hat in ein Backend System.
Process APIs: In einer Process API können Daten formatiert, transformiert, zusammengeführt, gefiltert und sortiert werden. Ebenfalls kann diese auch als Auslöser für zeitgesteuerte Aufgaben dienen. In dieser Ebene können Daten innerhalb der Process Ebene oder auch mit der System- und Experience Ebene ausgetauscht werden.
Experience APIs: Die Experience API ist gegen aussen publiziert und kann von Endgeräten und oder anderen Systemen angesprochen werden. Der Zugriff auf eine API in der Experience Ebene kann zum Beispiel über ein API-Management gesteuert werden. Eine Experience API tauscht nur Daten mit der Process Ebene aus.
Wo liegen die Vorteile einer API-gesteuerte Verbindungsarchitektur?
- Wiederverwendbarkeit bestehender APIs für andere Systeme
- Redundante Datenhaltung in Systemen kann vermieden werden
- Ausbau der bestehenden Architektur gestaltet sich einfacher
- Schlanker Datenfluss dank konkreten Abfragen möglich
Ist also dieser API-gesteuerte Verbindungsarchitektur-Ansatz eine All-in-One Lösung?
Natürlich nicht, da man dies von Anwendung zu Anwendung betrachten und beurteilen muss. Gerade zu Beginn ist eine solche API-gesteuerte Verbindungsarchitektur nicht unbedingt schlanker als die ursprüngliche P2P Verbindungsarchitektur und Bedarf an grösserem Initialaufwand. Aber umso mehr Systeme dazukommen und je mehr Daten ausgetauscht werden, desto mehr lohnt sich dieser Ansatz. So kann beispielsweise die Schnittstellenimplementierung in neuen Projekten wesentlich verkürzt werden. Dies ist möglich, da bestehende APIs wiederverwendet werden oder falls nötig minimal erweitert werden. In der heutigen Zeit müssen wir zudem schneller auf Veränderungen reagieren können.
Cyrill Raggenbass: Flexibilität ist je länger, je mehr gefragt: auch bei Schnittstellenarchitekturen.
Weiterführende Links zum Thema
GitHub – Solution architecture patterns
Dzone – MuleSoft API Led Connectivity Architectural and Design Patterns
