Unsere Interview-Serie zu Jakarta EE: Arjan Tijms, Projektleiter für Eclipse Mojarra und Tech Lead bei Payara

Jakarta EE im Klartext: „Kubernetes macht das Ausführen mehrerer Anwendungen auf einem einzigen Server fast unnötig“

Dominik Mohilo, Gabriela Motroc

© Shutterstock / LuckyN (modifiziert)

Na, auch ein wenig den Anschluss in Sachen Jakarta EE verloren? Das macht nichts. In unserer Interview-Reihe sprechen Experten der Enterprise-Java-Szene Klartext darüber, was sich im Laufe der letzten Wochen und Monate verändert hat und in welche Richtung sich Jakarta EE entwickelt. Zentrales Thema ist dabei unter anderem, wie Jakarta EE zum neuen Zuhause für Cloud-native Java werden soll. Unser heutiger Gast ist Arjan Tijms, Projektleiter für Eclipse Mojarra und Tech Lead bei Payara. Ab geht die Reise ins Jakarta-EE-Universum!

Es ist wahrlich kein leichtes Unterfangen, dieser Umzug der Java-EE-Technologie von Oracle zur Eclipse Foundation. Die Marke „Jakarta EE“ entwickelt sich prächtig und schnell. Zeit, für einen Moment innezuhalten und all die Pläne und Veränderungen Revue passieren zu lassen, um die Technologie fit für die neuen Herausforderungen in Sachen Cloud, Containern, Microservices, Serverless und reaktiver Programmierung zu machen.

Die Vision der technischen Zukunft von Jakarta EE beinhaltet Folgendes:

  • Eine verbesserte Unterstützung von Microservices-Architekturen.
  • Der Weg hin zu Cloud-native Java, was unter anderem die bessere Integration mit Technologien wie Docker und Kubernetes bedeutet.
  • Das Beschleunigen der Innovationsgeschwindigkeit.
  • Den Aufbau einer aktiven und engagierten Entwickler-Community.
  • Das Bereitstellen von produktionsreifen Referenzimplementierungen.

Immer auf dem Laufenden zu bleiben, was in Sachen Jakarta EE gerade in und was gerade out ist, bleibt ein kontinuierlicher Prozess. Mit Sicherheit können allerdings die bereits akzeptierten und in der Eclipse Foundation offiziell verorteten Projekte identifiziert werden. Unsere Liste von bereits angenommenen Projektvorschlägen hilft dabei, sich einen Überblick über den Status Quo zu verschaffen, aber das ist natürlich nur die Spitze des Eisbergs.

Welchen Herausforderungen sieht sich Jakarta EE derzeit gegenüber? Welche werden wohl in naher Zukunft aufkommen? Wohin geht die Reise überhaupt und wie wird die Zukunft von Enterprise Java aussehen? Mit unserer Interview-Serie wollen wir euch helfen, die aktuellen Entwicklungen im Blick zu behalten. Unsere Experten beleuchten die Hintergründe und klären darüber auf, wie es um die Zukunft der Technologie bestellt ist und wie man plant, Jakarta EE als neues Zuhause für Cloud-native Java zu etablieren.

Unsere Interview-Reihe: Jakarta EE im Klartext

In unserer Interview-Reihe sprechen Experten der Enterprise-Java-Szene Klartext darüber, was sich im Laufe der letzten Wochen und Monate verändert hat und in welche Richtung sich Jakarta EE entwickelt. Zentrales Thema ist dabei unter anderem, wie Jakarta EE zum neuen Zuhause für Cloud-native Java werden soll.

Ab geht die Reise ins Jakarta-EE-Universum mit unseren Experten!

Unser heutiger Experte ist Arjan Tijms, Projektleiter für Eclipse Mojarra and Tech Lead bei Payara. Ab geht die Reise ins Jakarta-EE-Universum!

JAXenter: Hallo, Arjan! Glaubst du, es wäre eine gute Idee, Eclipse MicroProfile mit Jakarta EE zu verschmelzen?

Arjan Tijms: Auf jeden Fall. Das MicroProfile API baut bereits stark auf einer EE-Basis auf und wird hauptsächlich von EE-Programmierern verwendet, die EE-Produkte einsetzen (wie z.B. Payara Server oder Payara Micro, WildFly, Liberty usw.). MicroProfile APIs werden auch von den gleichen Organisationen und Personen implementiert, die auch die EE APIs implementieren.

MicroProfile APIs füllen Lücken in den APIs von Jakarta EE, die letztendlich sowieso dort behoben worden wären. MicroProfile spezifiziert beispielsweise einen JWT-Authentifizierungsmechanismus. Grundsätzlich war genau derselbe Mechanismus auch für die Aufnahme in das EE Security API geplant (bis zu dem Punkt, dass sogar bereits einige Prototypen dafür entwickelt wurden). Es würde nicht viel Sinn machen, einen weiteren JWT-Authentifizierungsmechanismus in Jakarta EE einzuführen, der auch eine Authentifizierung auf Basis von JWT durchführt, nur auf eine andere Weise.

MicroProfile APIs füllen Lücken in den APIs von Jakarta EE, die letztendlich sowieso dort behoben worden wären.

Andererseits musste MicroProfile manchmal auf Basis von Vermutungen weiterentwickelt werden, da Funktionalität benötigt wurde, aber die Grundlage dafür noch nicht vollständig vorhanden war. Schaut man sich beispielweise noch einmal JWT an, sieht man, dass es keine echte Sicherheitsgrundlage in MicroProfile gibt. Es wird größtenteils angenommen, dass es etwas gibt, aber was dieses „Etwas“ genau ist und wie es funktioniert, ist nicht spezifiziert. Die MP-JWT-Spezifikation, die lediglich den Authentifizierungsmechanismus selbst hätte spezifizieren sollen, musste notgedrungen eine Sicherheitsgrundlage aus dem Boden stampfen. MicroProfile und Jakarta EE zu mergen, würde bedeuten, dass MP-JWT von diesen Vermutungen ablassen kann und das ausgereifte und solide Sicherheitsfundament von Jakarta EE nutzen kann (auf der Payara Platform basiert MP-JWT bereits vollständig auf dem EE Security API).

JAXenter: Der Pfad, den man mit Jakarta EE beschreiten möchte, wurde bereits klar definiert und nennt sich Cloud-native Java. Wie erreicht man dieses Ziel?

Arjan Tijms: Ich bin mir nicht so sicher, ob „bereits definiert“ hier die richtige Terminologie ist. Der Spezifizierungsprozess und die Arbeit an Jakarta EE stehen noch weitgehend in den Startlöchern, da der Transfer von Oracles Java EE zu Jakarta EE bei der Eclipse Foundation noch im Gange ist.

Abgesehen davon ist ein wichtiger Aspekt von Cloud-native, dass man unabhängige Anwendungsarchive hat. Ganz im Gegensatz zu Archiven mit ungelösten Abhängigkeiten, welche dann zur Zeit des Deployments von einem „Deployer“ bereitgestellt werden müssten. Diese ungelösten Abhängigkeiten sind beispielsweise der Identity Store für die Sicherheit, Datenquellen für den Zugriff auf Datenbanken und so weiter. Für das lokale Deployment von Software, die in das Intranet einer Büroumgebung integriert werden muss, sind solche ungelösten Abhängigkeiten oft genau das Richtige. Für Cloud Deployments, bei denen man eine einzelne Anwendung (die intern aus Microservices bestehen kann) einsetzt, ist dies nicht immer ideal.

Allerdings bedeutet „unabhängige Anwendungsarchive“ nicht, dass das Archiv dann zur Blackbox wird: Ganz im Gegenteil, die vom Anwendungsarchiv genutzten Ressourcen werden immer noch über die (Cloud-)Konsole oder das CLI der Laufzeit konfiguriert und verwaltet.

JAXenter: Wie kann Jakarta EE die Cloud-bezogenen Bedürfnisse der Nutzer befriedigen?

Arjan Tijms: Ein wichtiger Punkt ist, dass es für Jakarta-EE-Anwendungen die Möglichkeit gibt, bei Bedarf ihre Konfiguration auch aus einer externen Quelle zu beziehen. Dies scheint dem Ziel der Unabhängigkeit zwar entgegen zu stehen, aber das ist nicht der Fall. In traditionellen Java-EE-Anwendungen müssen die ungelösten Abhängigkeiten zum Zeitpunkt des Deployments aufgelöst werden, was für Cloud-Implementierungen schmerzhaft ist. Um das Ganze Cloud-freundlicher zu machen, werden die Ressourcen in erster Linie innerhalb des Archivs angegeben, aber ihre Konfiguration stammt aus den Konfigurationsquellen. Diese Quellen können entweder intern (im Anwendungsarchiv) oder extern (in der Laufzeit bzw. dem Server, auf dem Dateisystem oder von einem zentralen Konfigurationsserver und so weiter) sein.

Darüber hinaus, kann sich Jakarta EE weiterentwickeln, indem es eine Reihe von Cloud-Konnektoren bereitstellt, die im Wesentlichen Plug-ins sind und es Anwendungen ermöglichen, mit ihrer Cloud-Umgebung zu kommunizieren. Der oben genannte JWT-Authentifizierungsmechanismus ist ein solcher Konnektor.

JAXenter: Konzentrieren wir uns auf die Ergebnisse des Jakarta EE Surveys. Über 60 Prozent der Teilnehmer würden eine bessere Unterstützung von Microservices begrüßen. Wie würdest du dem nachkommen?

Arjan Tijms: Zunächst einmal muss erwähnt werden, dass hier verschiedene Umfragen zu unterschiedlichen Ergebnissen kommen. Zum Beispiel schien in der Java-EE-Umfrage von OmniFaces der Wunsch nach Microservices weniger eindeutig.

Wichtig ist auch, dass Microservies nicht für jedes Problem geeignet sind und das man es damit nicht übertreiben sollte. Eine kleine Anwendung in, sagen wir mal, 100 Microservices aufzuteilen, wird die ganze Angelegenheit nicht einfacher machen. Doch andererseits ist es auch keine ideale Lösung, eine monolithische Anwendung mit über 1.000.000 Codezeilen zu bauen, bei der einzelne Teile dieser Anwendung völlig unterschiedliche Dinge machen, die gesamte Anwendung aber bei jeder Änderung komplett deployt werden muss. Hier spielt der gesunde Menschenverstand eine wichtige Rolle.

Außerdem geht es bei Microservices meist darum, einen kohärenten, kleinen (Micro-)Task zu erledigen und diesen Task als (Remote-)Service zur Verfügung zu haben. Technisch gesehen heißt das allerdings nicht, dass die Laufzeit, auf der diese kleinen Services laufen, auch klein oder „micro“ sein muss, was allerdings in der Regel angenommen wird. Wir sehen also, was es heißt, eine falsche Vorstellung zu haben: Wenn man an Java-EE-Server denkt, stellt man sich vor, dass das rießige Server sind (also das sie viele Gigabyte Speicherplatz auf der Festplatte einnehmen) und das ihre Inbetriebnahme ewig dauert (von vielen Minuten bis hin zu Stunden und im Extremfall sogar tagelang). Die meisten Server nehmen jedoch nur etwa 150 MB auf der Festplatte ein und haben eine Startzeit zwischen einer und drei Sekunden. Man kann sich dazu das Beispiel auf Antonio Goncalves‘ Blog dazu ansehen.

Diese falsche Vorstellung zeigt sich auf zwei Weisen:

  1. Es wird angenommen, dass die Laufzeiten für Microservices auch „micro“ sein müssen, aber das ist streng genommen nicht der Fall und
  2. die Leute denken, dass Java-EE-Server absolut riesig sind, obwohl dies auch nicht ganz der Fall ist.

Gleichwohl können Jakarta-EE-Server dem Wunsch nach kleineren Laufzeiten gerecht werden, da sie in der Lage sind, Teile des Servers, die nicht verwendet werden, statisch zu deaktivieren und sogar zu entfernen. Eine Vielzahl von Servern ermöglicht dies bereits in unterschiedlichem Maße, aber es zu standardisieren und zu einem Kernaspekt von Jakarta EE zu machen, wäre sicherlich hilfreich.

Ebenso sollte die, etwa von Payara Micro und WildFly Swarm (Thorntail) verwendete Option Uberjar oder Hollow Jar, wohl auch in irgendeiner Weise standardisiert werden.

JAXenter: Die native Integration von Kubernetes ist ein weiterer wichtiger Faktor, wie die Umfrage gezeigt hat. Sollte dies für Jakarta EE eine Priorität darstellen?

Bei Java EE – und damit auch Jakarta EE – waren Container und Clustering schon immer ein Thema, auch wenn die eigentlichen Spezifikationen nicht viel über das Clustering ausgesagt haben.

Arjan Tijms: Das wäre eine ziemlich interessante Richtung, die man auf jeden Fall erkunden sollte. Bei Java EE – und damit auch Jakarta EE – waren Container und Clustering schon immer ein Thema, auch wenn die eigentlichen Spezifikationen nicht viel über das Clustering ausgesagt haben. Die eigentliche Clustering-Technologie war daher immer eine Sache der einschlägigen Anbieter. Beispielsweise haben GlassFish und frühere Versionen der Payara Platform das Tool Shoal für ihre nativen Clustering-Technologien verwendet. Neuere Versionen der Plattform verwenden Hazelcast. JBoss/WildFly nutzen für das Clustering JGroups und Infinispan und so weiter.

Ob Kubernetes in den Jakarta-EE-Spezifikationen erwähnt oder als Anbietermerkmal belassen werden sollte, muss noch entschieden werden. Für Java-EE-Spezifikationen wurde immer Wert darauf gelegt, sie nicht an bestimmte Produkte zu binden, sondern sie stattdessen als weitgehend unterstützende Standards zu sehen. Die Jakarta-EE-Spezifikationen könnten es einfacher machen, die native Kubernetes-Integration als Anbietermerkmal zu implementieren, indem sie einige Aspekte des Clusterings definieren.

Durch die immer weiter steigende Wichtigkeit von Kubernetes (und Containern bzw. Docker), wird es wohl auch immer weniger wichtig, mehrere Anwendungen auf einem einzigen Jakarta-EE-Server auszuführen. Diese Fähigkeit war einst ein wichtiges Merkmal, insbesondere bei den größeren Java-EE-Servern (damals IBMs WebSphere und BEAs WebLogic).

JAXenter: Würdest du eine höhere Release-Kadenz (wie es nun bei Java der Fall ist) oder lieber größere und langsamere Releases bevorzugen?

Arjan Tijms: Schnellere Releases sind wahrscheinlich, in Verbindung mit vielleicht einem stabilen LTS Release zu bestimmten Zeiten, der richtige Weg. Obwohl die schnellere Veröffentlichung neuer Versionen natürlich attraktiver klingt, müssen wir auch daran denken, dass eine stabile Plattform, auf der andere Bibliotheken (wie PrimeFaces, OmniFaces, DeltaSpike, etc.) und Tools (wie Eclipse, NetBeans, etc.) basieren, auch viel wert ist. Eine sich ständig ändernde Plattform legt besonderen Wert auf diejenigen Anwendungsfälle, bei denen man ständig auf dem neuesten Stand sein muss.

JAXenter: Wie planst du dich in den Entwicklungsprozess von Jakarta EE einzubringen? Gibt es irgendwelche Spezifikationen oder TCKs, die dich besonders interessieren?

Arjan Tijms: Ich bin direkt bei den Sicherheitsspezifikationen (EE Security, JACC und JASPIC) und einigen der Webframework-Spezifikationen (JSF und Expression Language) involviert. Zudem bin ich auch ein Committer für verschiedene andere Spezifikations- und Implementierungsprojekte wie JAX-RS, Jersey, Mojarra, Soteria und so weiter.

Im Auftrag von Payara Services, Ltd. werde ich neue API-Designs für die API-Projekte einbringen und diese in die Implementierungsprojekte implementieren. Ich bin auch an der Implementierung einiger der MicroProfile-Spezifikationen beteiligt, ebenfalls im Auftrag von Payara.

JAXenter: Wie sollte die Community mit den Veränderungen umgehen, die in letzter Zeit stattgefunden haben?

Arjan Tijms: Für die Endanwender von Java-EE-Produkten wird es wahrscheinlich keine großen Veränderungen geben, an die sie sich anpassen müssten. Die nächste größere Version ihres Servers (JBoss, Liberty, die Payara-Plattform, etc.) wird „Jakarta EE 9“ statt „Java EE 9“ unterstützen. Darin enthalten sind die neuen Versionen aller beliebten Java-EE-Spezifikationen gemeint (JPA, CDI, JAX-RS, JSF usw.), aber nicht mehr.

Es gibt endlich keine höhere Kraft mehr, die das Projekt (basierend auf dem Zyklus eines anderen Projekts) in regelmäßigen Abständen öffnet und schließt.

Für die Mitarbeiter der Spezifikationen, APIs und Implementierungen werden sich in manchen Fällen ein paar Dinge ändern, aber andere Dinge bleiben unverändert. Die Leute können etwa immer noch Problem- und Fehlerberichte erstellen, hier hat sich sehr wenig verändert. Die vielleicht wichtigste Änderung ist die, dass es weniger Probleme mit Spezifikationen und API-Projekten geben wird, die vorher „aktiv“ sein mussten. In Java EE und mit dem JCP konnte man zum Beispiel während des Java-EE-8-Zyklus nicht an der Concurrency-Spezifikation arbeiten. Das Problem bestand darin, dass die Concurrency-Spezifikation nicht aktiv war, obwohl es Leute gab, die daran arbeiten konnten und wollten. Die Concurrency-Spezifikation konnte auch nicht aktiv gemacht werden, da es nicht geplant war, dass sie aktiv sein sollte. Und zum Schluss konnte man die Aktivierung nicht einmal mehr planen, da die Planung bereits vorher stattgefunden hatte (irgendwann vor dem Beginn von Java EE 8).

Solche Probleme sollten mit dem Eclipse-Prozess weitaus seltener sein oder gar nicht mehr vorkommen. Wenn ein Committer eine Änderung in einem API-Projekt vornehmen möchte, ist dies jederzeit möglich, aber nur mit der Zustimmung der anderen Committer im gleichen Projekt. Es gibt keine höhere Kraft mehr, die das Projekt (basierend auf dem Zyklus eines anderen Projekts) in regelmäßigen Abständen öffnet und schließt.

JAXenter: Was kommt als nächstes für Eclipse Mojarra?

Arjan Tijms: Eclipse Mojarra wird derzeit auf ein neues Major Release vorbereitet: Version 3.0.

Das Thema dieser Version wird es sein, eine große Menge an Cruft- und Legacy-Dingen loszuwerden. Im vergangenen Jahr, noch vor dem Transfer, haben wir uns darauf konzentriert, das Projekt selbst zu bereinigen und schließlich auf eine normale Maven-Projektstruktur umzustellen. Früher basierte das Mojarra-Projekt auf Apache Ant und mehreren benutzerdefinierten Skripten. Vor einigen Jahren begann Manfred Riem dann mit der Migration des Projekts nach Maven. In Version 2.2 gab es eine Art hybride Struktur, in 2.3 konnte Maven unabhängig voneinander verwendet werden, aber alle Ant-Skripte waren noch vorhanden. Für Version 3.0 wurden nun alle alten Ant-Codes und Skripte entfernt und es gibt nur noch das Maven-Projekt.

Was das API betrifft, so werden wir die JSP-Unterstützung entfernen, die seit geraumer Zeit deprecated ist (seit Version 2.0, die 2009 veröffentlicht wurde). Wir werden auch das nativ verwaltete Bean-System entfernen (das offiziell für Version 2.3 als deprecated markiert wurde, worüber allerdings bereits zu Version 2.0 informiert wurde). Außerdem werden wir die letzten verbliebenen Reste der alten, nativen EL-Unterstützung entfernen, die noch vorhanden aber seit sehr langer Zeit veraltet ist.

Für die Endanwender von Java-EE-Produkten wird es wahrscheinlich keine großen Veränderungen geben.

Das Ergebnis ist, dass 3.0 binär inkompatibel ist, daher die Änderung der Versionsnummer. Die Mehrheit der Anwendungen sollte wenige bis gar keine Probleme haben, aber sehr alte Anwendungen sollten auf 2.3 oder früher bleiben, bis sie vollständig auf 3.0 migriert wurden.

Ein weiterer Plan besteht darin, noch mehr Dinge auf CDI umzustellen. Diese Arbeit begann bereits mit Version 2.3, aber wir möchten diesen Weg auch mit der nächsten Major-Version fortsetzen.

JAXenter: Könntest Du bitte beschreiben, worum es in Eclipse Mojarra geht?

Arjan Tijms: JSF ist ein MVC-pull Framework. Es generiert HTML auf dem Server und sendet es an einen Client (einen Webbrowser), der es rendert. Ein wichtiger Aspekt von JSF ist, dass dessen User Interface komponentenbasiert ist, wobei diese Komponenten von Entwicklern selbst erstellt oder von Komponentenbibliotheken Dritter (z.B. PrimeFaces) bereitgestellt werden können. Als serverseitiges MVC Framework steht JSF im Wettbewerb mit Client-seitigen MVC Frameworks wie Angular. Angular ist hier besonders interessant, da man sich bei dessen Enwicklung scheinbar von JSF hat inspirieren lassen.

Wir glauben, dass sowohl serverseitige Frameworks als auch Client-seitige Frameworks ihre eigenen Vor- und Nachteile haben. Mit JSF versuchen wir, es zu einer sehr guten Alternative für diejenigen zu machen, die ein serverseitiges MVC Framework suchen und gleichzeitig erkennen, dass Client-seitige Frameworks auch einen großen Teil des gesamten MVC-Marktes erfasst haben.

Jaxenter: Vielen Dank für das Interview!

Arjan Tijms is project lead for Eclipse Mojarra and tech lead at Payara. He is also the founder of the OmniFaces project and the zeef.com website.
 
 
 
Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Gabriela Motroc
Gabriela Motroc
Gabriela Motroc ist Online-Redakteurin für JAXenter.com. Vor S&S Media studierte Sie International Communication Management an der The Hague University of Applied Sciences.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: