Komponentenbasierte Softwaretechnik: Was ist heute noch geblieben?
Während ältere Komponentenmodelle wie CORBA, DCOM und JavaBeans mittlerweile an Bedeutung verlieren, erleben Microservice-Architekturen gerade einen Höhenflug.
![](https://heise.cloudimg.io/width/610/q85.png-lossy-85.webp-lossy-85.foil1/_www-heise-de_/imgs/18/3/0/4/8/5/3/2/shutterstock_1080430937__2_-ef9540b603c2db49.jpeg)
(Bild: Shutterstock)
- Dr. Lofi Dewanto
- Manuel Klein
Welche Rolle spielt heute noch ein Oldie wie die komponentenbasierte Softwaretechnik? Ist sie noch relevant, mittlerweile irrelevant oder aber selbstverständlicher Bestandteil jedes Softwareprojekts? Während ältere Komponentenmodelle wie CORBA, DCOM und Java Beans mittlerweile bedeutungslos sind, erlebt der Ansatz mit Microservice-Architekturen gerade einen neuen Höhenflug.
Allgemein formuliert ist eine Softwarekomponente ein Element, das zu einem Komponentenmodell konform ist. Sie lässt sich unabhängig und ohne Modifikation weitergeben, in einer Komponentenlaufzeitumgebung installieren und zusammensetzen. Ein solches Modell ermöglicht Interaktionen und Kompositionen zwischen Komponenten. Abbildung 1 zeigt die Definition mit der Verwendung von Komponenten aus beispielsweise einer E-Learning-Domäne [1].
Das Hauptziel für die Erstellung und Verwendung von Softwarekomponenten war und ist immer noch die Wiederverwendung. Somit sollen Effizienz, Qualität und Wartung in der Softwareentwicklung verbessert und vereinfacht werden. Die genannten Ziele sind bis heute leider schwer zu erreichen, sodass die Wiederverwendbarkeit der Softwarekomponenten uns seit über 30 Jahren stets begleitet. Viele Trends in der Informatik versuchen, die Lösung aller dieser Probleme zu finden, Buzzword zu diesem Thema sind seit einigen Jahren die Microservices.
Wiederverwendbare Komponenten entwickeln
Wieso ist es eigentlich Kompliziert, wiederverwendbare Komponenten zu entwickeln? Ein erstes Hindernis stellt die Sprach- und Betriebsumgebung betreffende Verwendbarkeit der Komponente dar. Eine Java-Klasse ist beispielsweise nicht ohne weiteres in einem C#-Projekt (wieder-)verwendbar. Das funktioniert nur, wenn sich ein kleinster gemeinsamer Nenner bezüglich einer Schnittstelle zwischen den Programmierumgebungen finden lässt. Die Schnittstelle darf allerdings nicht einschränkend hinsichtlich des Funktionsumfangs sein, muss einfach in die genutzten Programmierumgebungen integrierbar sein und darf bei der Nutzung auch keinen signifikanten Einfluss auf die Geschwindigkeit haben.
Komponentenbibliotheken wie die DLL-Dateien unter Windows oder JAR-Archive in der Java-Welt haben zudem durch das Thema der Versionierung manchen Entwickler zur Verzweiflung getrieben. Bibliotheken sind leider nicht grundsätzlich abwärtskompatibel, in vielen Komponentenbibliotheken bestehen Abhängigkeiten der Form "Bibliothek A ist mit Komponente X in den Versionen 1.4 bis 2.7 nutzbar". Möchte man in seinem Projekt gleichzeitig eine Bibliothek B einsetzen, die die Komponente X in Version 2.9 erfordert, wird es kompliziert.
Als ein weiterer Stolperstein sinnvoller wiederverwendbarer Komponenten sei hier die Größe der selbigen genannt. Es dürfte weitgehend Einigkeit darüber herrschen, dass eine Java-Klasse von der Funktionalität zu klein ist, eine Bibliothek aber auch viel zu groß werden kann. Java selbst hatte in Version 2 noch 1520 Klassen, in Version 11 sind es 4410 Klassen – und das, nachdem mit Jigsaw umfangreiche Aufräumarbeiten durchgeführt wurden. Die Bereinigung in der API von Java 11 führte dazu, dass ältere Java-Programme, die ausgefallene APIs nutzen, nicht mehr laufen.
Zeitliche Entwicklung der Komponentenmodelle
Historisch gesehen gibt es bereits einige Komponentenmodelle auf dem Markt, die kamen und zum großen Teil auch wieder in der Bedeutungslosigkeit versunken sind: darunter CORBA (Common Object Request Broker Architecture), COM, DCOM, COM+, ActiveX, Enterprise JavaBeans, JavaBean, Webservices, SpringBean, Eclipse-Plug-ins, HTML-, JSF- (JavaServer Faces), Vue.js- und SwiftUI-Komponenten sowie WebComponents. Abbildung 2 veranschaulicht die Entwicklung der Komponentenmodelle in der Zeitschiene.
Aus Verteilungssicht gibt es Komponentenmodelle, die in einem Prozess laufen müssen, wie COM und Eclipse-Plug-ins. Hierzu kommen Modelle, die in verteilten Prozessen kommunizieren, beispielsweise CORBA, DCOM und Webservices. In der Zeit der Microservices gilt folgende Komponentendefinition als State of the Art:
- Laufzeitumgebung: Docker/Kubernetes auf einem Betriebssystem
- Modell: REST-APIs/Graph-APIs/Webhooks in Microservices
- Komponenten: Warenkorb Microservice, Kunden Microservice
Somit bringen Microservices aus der Komponentensicht keine neuen Erkenntnisse – ausschließlich neue technologische Spezifikationen und Produkte werden hierbei vorgestellt und eingeführt. Das Einführen neuer Technologien kann jedoch nicht zu unterschätzende Überarbeitungen mit sich bringen. Ein selbstheilendes System mit Kubernetes ist für Anwendungen mit einem globalen Zugriff mit Millionen von Benutzerzugriffen sicherlich sinnvoll. Ob dann die Komplexität von Kubernetes für eine Anwendung mit lediglich hundert Nutzern zu vertreten ist, ist fraglich. Allerdings hat man in vielen Fällen anfangs keine Ahnung von der späteren Anzahl der Nutzer. Eine Pro-Microservices-Argumentation ist es, dass sich ein Zoo an Microservices mit den bestehenden Infrastruktur-werkzeugen leichter administrieren lässt, als der Monolith aus dem vorletzten Jahrzehnt, der nur noch dem "Dinosaurier-Entwickler" aus dem Keller bekannt und somit beherrschbar ist.