© Enkel/Shutterstock.com
Runtimes im Überblick

Konkurrenz belebt das Geschäft


Im folgenden Artikel geben wir einen Überblick über die MicroProfile Runtimes, die das Technology Compatibility Kit (TCK) für die jüngeren MicroProfile-Releases zum Stand Mitte Dezember bestanden haben: Thorntail, TomEE, Payara Micro, Open Liberty, KumuluzEE und Helidon. Zahlreiche weitere Runtimes, die die Spezifikation nur in Teilen erfüllen, berücksichtigen wir hierbei nicht.

Seit etwas über zwei Jahren treibt die Eclipse Foundation die MicroProfile-Spezifikation in einem schwindelerregenden Tempo voran: Seit Version 1.0 im Jahr 2017 wurden bereits zehn Releases veröffentlicht. Die Maintainer der gängigen MicroProfile Runtimes müssen dieses Tempo mitgehen, eine Spezifikation ohne Implementierungen kann schließlich von niemandem verwendet werden. Bei den meisten dieser Implementierungen handelt es sich um Ableger von Application-Servern, die im Schnitt nur alle drei bis vier Jahre eine neue Java-EE-Spezifikation unterstützen mussten. Ein gründlicher Blick auf die Runtimes lohnt sich, bevor man mit MicroProfile loslegen möchte: Wie reaktionsschnell sind die Projekte? Welche aktuellen MicroProfile-Versionen unterstützen sie? Wer treibt die Entwicklung voran, und wie sieht es mit Support aus?

Warum so viele Runtimes?

Um zu verstehen, warum solch eine hohe Zahl von MicroProfile Runtimes existiert, muss man sich noch einmal in Erinnerung rufen, dass MicroProfile selbst keine lauffähige Implementierung ist. Es handelt sich vielmehr, ähnlich wie bei Jakarta EE, um eine Sammlung von Spezifikationen, die zu einer übergreifenden Spezifikation zusammengefasst sind. Genau wie bei Jakarta EE müssen Projekte diese Spezifikationen implementieren, um sie für Benutzer verfügbar zu machen. Das Ziel dahinter ist, Benutzern eine Vielzahl von Alternativen und damit eine Auswahl anzubieten. Während sich Entwickler bei der Benutzung von Spring an die einzige existierende Implementierung binden, können Sie als Nutzer des MicroProfile-Standards von der Implementierung unabhängig bleiben. Verliert beispielsweise ein Betreiber das Interesse daran, seine Runtime weiterzuentwickeln, ist es mit verhältnismäßig wenig Aufwand möglich, seine Applikation zu einer anderen Implementierung umzuziehen.

Es ist gängige Praxis, dass Applikationen lediglich über eine provided-Abhängigkeit gegen MicroProfile verfügen und von der eigentlichen Runtime getrennt sind (Listing 1). Diese stellt dann die Implementierungen der einzelnen Spezifikationen zur Laufzeit bereit. Hierfür gibt es zwei Möglichkeiten: Entweder wird die Applikation zusammen mit der jeweiligen Implementierung in ein ausführbares Fat JAR gepackt oder sie wird zu einem WAR gepackt und nachträglich auf einer MicroProfile Runtime deployt. Nach dieser Theorie sollte es also möglich sein, eine MicroProfile-Anwendung ohne Anpassungen mit verschiedenen Runtimes zu betreiben. Die meisten Runtimes liefern Funktionalitäten mit, die weit über MicroProfile hinausgehen. Oft sind das Implementierungen zu Jakarta-EE-Spezifikationen wie JPA, Bean Validation oder EJB. Die Nutzung dieser Features in der Applikation kann sich unter Umständen als praktisch erweisen, schränkt aber natürlich die Portierbarkeit zu Lösungen anderer Anbieter ein.

Listing 1

<dependency> <groupId>org.eclipse.microprofile</groupId> <artifactId>microprofile</artifactId> <version>3.2</version> <type>pom</type> <scope>provided</scope> </dependency>

Thorntail – und Swarm, SmallRye und Quarkus

Um die aktuelle Situation von Thorntail [1] zu verstehen, müssen wir ein wenig ausholen. Die Entstehungsgeschichten von Thorntail, WildFly Swarm, Smallrye und Quarkus sind nämlich eng miteinander verknüpft. Thorntail startete, ursprünglich noch unter dem Namen WildFly Swarm, im Jahr 2015 als Ableger des WildFly Application Server unter der Apache Public License 2.0, um Entwicklern das Erstellen von Microservices als einzelne ausführbare JARs zu ermöglichen. Das zu Red Hat gehörende JBoss versuchte damit, auf die wachsende Kritik an den schwerfälligen Application-Servern zu reagieren und den Stack auch für die Entwicklung kleinerer Services interessant zu machen. Dass WildFly Swarm schon früh die ersten MicroProfile-Versionen unterstützte, ist nicht verwunderlich, schließlich gehörte Red Hat zu den Gründungsmitgliedern der MicroProfile-Initiative, die ebenfalls versuchte, die EE-Spezifikationen für Microservices zu standardisieren. 2018 wurde der Name in Thorntail geändert – der Begriff „Swarm“ wurde den Maintainern von zu vielen anderen Projekten genutzt. Gleichzeitig sah man den neuen Namen als Chance, sich vom großen Bruder WildFly abzugrenzen, mit dem die Gemeinsamkeiten in den letzten drei Jahren immer geringer ausfielen. Zur gleichen Zeit wurde auf Anregung von Ken Finnigan das SmallRye-Projekt gestartet. Dieses hat zum Ziel, für jede einzelne MicroProfile-Spezifikation eine Implementierung bereitzustellen, ohne diese zu einer lauffähigen Einheit zusammenzufassen. Diese Implementierungen können von anderen MicroProfile-Implementierungen wiederverwendet werden. Dass diese Rechnung aufgegangen ist, sieht man bei einem Blick in die Abhängigkeiten von Thorntail: Die Implementierungen sämtlicher MicroProfile-Spezifikationen sind SmallRye Dependencies.

Um ein neues MicroProfile-Projekt mit Thorntail zu starten, benötigt man eine Java-Version zwischen 8 und 11. Die momentan höchste unterstützte MicroProfile-Version ist 3.2. Für Entwickler wur...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang