Middleware: Eine API, sie zu knechten

30. Oktober 2019


Die Begriffe Software und Hardware sind längst in den allgemeinen Sprachschatz übergegangen. Anders sieht es mit dem Begriff Middleware aus, der außerhalb der IT-Branche so gut wie gar nicht bekannt ist. Wir versuchen uns an einer auch für Nicht-ITler verständlichen Erklärung.

Was ist Middleware überhaupt?

Ganz allgemein gesprochen ist eine Middleware ein in sich geschlossenes System, das zwischen verschiedenen anderen geschlossenen Systemen angesiedelt ist. Bezogen auf Webanwendungen, wie wir sie entwickeln, ist eine Middleware eine Anwendung, die mehrere andere Anwendungen miteinander verbindet und die Kommunikation bzw. den Datenaustausch zwischen ihnen ermöglicht. Eine solche Middleware kann ausschließlich im Backend (d.h. für den Nutzer unsichtbar) arbeiten, sie kann aber auch eine grafische Benutzeroberfläche besitzen, über die der Nutzer die einzelnen Anwendungen zentral steuert.

Tut es eine normale API nicht auch?

Die Antwort auf diese Frage lautet: Es kommt darauf an. Wenn lediglich Daten aus einer Anwendung A zu einer Anwendung B geschickt werden sollen, dann reicht eine normale API (Schnittstelle) in der Regel aus. Sobald aber eine dritte Anwendung C mit ins Spiel kommt, wird die Sache kompliziert. Besonders dann, wenn die Daten nicht einfach von A nach B und von B weiter nach C geschickt werden sollen, sondern wenn A für die Datenübermittlung nach B zusätzliche Daten aus C abrufen und verarbeiten muss.

In so einem Fall ist es sinnvoller, eine Middleware zu entwickeln, welche sich die Daten aus A und C holt, verarbeitet und das Resultat dann an B ausspielt. Das gilt erst recht, wenn für die Verbindung zwischen den Systemen keine einheitlichen Schnittstellen zur Verfügung stehen. Kurz gesagt: Je mehr Einzelsysteme über verschiedene APIs untereinander Daten austauschen sollen, desto mehr lohnt sich die Entwicklung einer eigenen Anwendung, sprich: einer Middleware.

Ein Beispiel für den Einsatz einer Middleware

Das war jetzt alles sehr theoretisch, also sehen wir uns das doch einfach mal an einem fiktiven Beispiel an.

Ein Großhändler vertreibt seine Waren über einen Webshop. Außer dem Shopsystem sind weitere Anwendungen verschiedener Anbieter im Einsatz: ein Warenwirtschaftssystem, ein CRM und natürlich ein Buchhaltungssystem. Zusätzlich ist das Shopsystem über eine Schnittstelle an die Software des Logistikdienstleisters angebunden. Jedes dieser Systeme besitzt eine eigene Datenbank.

Sobald ein Kunde im Webshop seinen Warenkorb gefüllt und auf „jetzt kaufen“ geklickt hat, müssen die Bestelldaten an die verschiedenen Anwendungen weitergeleitet werden: An das Warenwirtschaftssystem geht die Info über die bestellten Artikel (was, wie viel, …) und die Frage, ob das gewünschte in ausreichender Menge vorrätig ist. Das Buchhaltungssystem muss eine neue Rechnung generieren und buchen. Das CRM muss einen Abgleich starten, ob der Kunde seine Kontaktdaten (Name, Rechnungsadresse, Lieferadresse, Zahlungsart) geändert hat und wenn ja, diese Information an das Buchhaltungssystem und/oder den Lieferdienst weitergeben. Und natürlich muss die Versandabteilung erfahren, dass ein neues Paket gepackt und abgeschickt werden muss.

Diese Datenübertragung muss aber auch anders herum funktionieren: Wenn ein Kunde in einer E-Mail um eine Änderung seiner Lieferanschrift bittet und ein Mitarbeiter diese Änderung ins CRM einträgt, sollte die Änderung auch automatisch in die Datenbank des Shopsystems übernommen werden, um dem Mitarbeiter doppelte Arbeit (zeitaufwändig! fehleranfällig!) zu ersparen. Wenn von einem Artikel nach einer Großbestellung nur noch fünf Stück verfügbar sind, sollte diese Information aus dem Warenwirtschaftssystem ans Shopsystem gehen, um den nächsten Kunden den Hinweis “nur noch wenige Exemplare auf Lager” anzeigen zu können.

grafische Darstellung der Systemarchitektur ohne eine Middleware
Ohne eine Middleware funktioniert der Datenaustausch zwischen den Anwendungen nur über Peer-to-peer-Verknüpfungen

Diese komplexe IT-Architektur ist ein Paradebeispiel für den sinnvollen Einsatz einer Middleware. Anstatt die Daten über zig Peer-to-peer-Verknüpfungen zwischen den einzelnen Anwendungen hin- und her zu schicken, steuert die Middleware im Backend den kompletten Einkaufsprozess. Sobald das Shopsystem ihr die Information über eine neue Bestellung schickt, startet die Middleware eine ganze Reihe von Abfragen und Befehlen an die übrigen Anwendungen: Sie gleicht die Stammdaten des Kunden mit CRM und Buchhaltung ab und informiert die Versandabteilung. Im Warenwirtschaftssystem reserviert sie die bestellten Artikel für den Kunden und prüft bei der Gelegenheit, ob danach noch genug Artikel vorhanden sind (wenn nicht, aktualisiert sie die Verfügbarkeitsanzeige im Shop). Außerdem beauftragt sie das Buchhaltungssystem mit der Rechnungsstellung.

grafische Darstellung der Systemarchitektur mit einer Middleware
Die Middleware steuert alle Anwendungen zentral – damit sind die vielen einzelnen Peer-to-peer-Verknüpfungen überflüssig

Middleware oder Microservices?

Könnte man die oben beschriebenen Prozesse nicht auch durch Microservices abbilden? Grundsätzlich ja. Netflix bildet seine Geschäftsprozesse schon seit einigen Jahren in Microservices ab, und wir selbst machen das intern ja auch. Das bedeutet aber nicht per se, dass eine Middleware damit überflüssig werden würde. Wenn beispielsweise unser fiktiver Großhändler sein bestehendes monolithisches CRM in mehrere Microservices aufteilen würde, dann müsste dieses CRM 2.0 dennoch weiterhin Daten mit den anderen Anwendungen (Shop, Buchhaltung, …) austauschen können. Dafür bräuchte er nach wie vor eine Middleware. Er hätte allerdings die Möglichkeit, diese in einer Microservice-Architektur entwickeln zu lassen.

Denn: Microservices sind eine bestimmte Art der Software-Architektur, während sich eine Middleware über ihre Funktion als solche definiert.