Suche
Unsere Interview-Serie zu Jakarta EE: Emily Jiang, Ian Robinson, Kevin Sutter & Alasdair Nottingham

Jakarta EE im Klartext: „MicroProfile ist der Sportwagen, Jakarta EE der Minibus“

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. Unsere heutigen Gäste sind die IBM-Entwickler Emily Jiang, Ian Robinson, Kevin Sutter und Alasdair Nottingham. 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!

Unsere heutigen Experten sind die IBM-Entwickler Emily Jiang, Ian Robinson, Kevin Sutter und Alasdair Nottingham. Ab geht die Reise ins Jakarta-EE-Universum!

JAXenter: Hallo ihr vier! Glaubt ihr, es wäre eine gute Idee, Eclipse MicroProfile mit Jakarta EE zu verschmelzen?

Emily Jiang: Es ist kein guter Zeitpunkt, um diesbezüglich Entscheidungen zu treffen. Jakarta EE ist noch in Arbeit, während MicroProfile bereits gut funktioniert und 6 Releases innerhalb von 2 Jahren fertiggestellt wurden, die 8 brandneue Spezifikationen umfassten. Wir können MicroProfile als den Sportwagen und Jakarta EE als Minibus betrachten. Sie haben beide einen Eigenwert und ergänzen sich gegenseitig.

Da sowohl MicroProfile als auch Jakarta EE von Eclipse Foundation verwaltet werden, konnten die unter MicroProfile definierten Spezifikationen (z.B. MicroProfile Fault Tolerance) an Jakarta EE übermittelt und schließlich standardisiert werden. Jakarta EE könnte dann alle von MicroProfile definierten Spezifikationen einbinden und umgekehrt.

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?

Innovativ, effizient und flexibel zu bleiben sowie regelmäßige Releases sind der Schlüssel zu Cloud-native.

Emily Jiang: Innovativ, effizient und flexibel zu bleiben sowie regelmäßige Releases sind der Schlüssel zu Cloud-native, denn Cloud-native entwickelt sich schnell. Neue Probleme treten auf. Cloud-native erfordert, dass Probleme schnell gelöst werden und die Lösungen überall funktionieren. Manchmal kann dabei das Erstellen einer neuen Spezifikation nötig werden. Daher sind Innovation und Flexibilität wichtige Faktoren.

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

Ian Robinson: Die Bedürfnisse Cloud-nativer Java-Anwendungen wurden nur teilweise von der Java-EE-Plattform abgedeckt, aus der die Jakarta EE hervorging. Bei diesen Anwendungen handelt es sich typischerweise um isolierte Microservices, die möglicherweise in einem Docker-Container ausgeführt werden, in dem sie mit einer leichtgewichtigen Java-Laufzeitumgebung und den Frameworks, von denen sie abhängen, verpackt werden.

Java EE hinkte hinterher, den Anforderungen für diese Art von Umgebung gerecht zu werden und so Probleme wie externalisierbare Konfigurationen, Healthchecks und das Monitoring – alles Grundanforderungen Microservices – aus der Plattformperspektive zu adressieren. Und dann geht es auch um die effiziente Erstellung und Verwendung von Sicherheits-Token, die leicht auf Java-EE-Ressourcen abgebildet werden können. Das alles fehlt, da Java EE nach EE7 in den Winterschlaf versetzt wurde.

Infolgedessen wurden Bemühungen wie Spring Boot und Eclipse MicroProfile unternommen, um die Lücken zu schließen – wobei ersteres das Spring Framework nutzt und letzteres direkt auf Java EE aufsetzt. Jakarta EE kommt wie Java EE aus dem Winterschlaf und wird durch eine Community vorangetrieben, die durch den (neuerdings) gemeinsamen Besitz der Plattform und die 5 schnellen Releases von Eclipse MicroProfile Starthilfe erhalten hat. Ich erwarte die schnelle Einführung der MicroProfile-Technologien in Jakarta EE, um die Bedürfnisse von Cloud-Anwendern befriedigen zu können.

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ürdet ihr dem nachkommen?

Kevin Sutter: Die Antwort auf die vorhergehende Frage greift einige der wichtigen Aspekte auf. Das Programmiermodell von Eclipse MicroProfile bietet bereits einige Features, die direkt zur Entwicklung von Microservices beitragen: Konfiguration, Fehlertoleranz, Metriken, Healthcheck, typsichere REST Clients, Weitergabe von JWT, Open API und Open Tracing. Der erste Schritt zu einer besseren Unterstützung der Enwicklung von Microservices ist daher, dass Jakarta EE einige dieser bewährten Funktionen aus MicroProfile übernimmt. Allerdings müssen wir, wie in der ersten Antwort bereits angedeutet wurde, diese Integration zum richtigen Zeitpunkt durchführen.

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?

Ian Robinson: Basierend auf den Umfrageergebnissen sollte es wahrscheinlich die zweithöchste Priorität haben 🙂

Kubernetes ist wichtiger Bestandteil einer wachsenden Anzahl von Cloud-Plattformen. Daher ist es sinnvoll, dass die Jakarta-EE-Technologien dort ebenfalls gut funktionieren. Sicherlich nicht fest gekoppelt, allerdings so spezifiziert, dass Implementierungen der Spezifikationen eine natürliche und klar ersichtliche Integration mit Kubernetes-Plattformen wie IBM Cloud oder OpenShift ermöglichen. Einige Implementoren der MicroProfile-Spezifikationen, die Jakarta EE wahrscheinlich übernehmen wird, tun dies bereits – beispielsweise OpenLiberty.

Es ist wichtig, dass Jakarta EE gut mit Kubernetes funktionieren, aber nicht fest daran gekoppelt sind.

Die MicroProfile Config-Spezifikation beschreibt, wie die „Config-Quellen“ für eine Anwendung definiert werden. Kubernetes Secrets und ConfigMaps sind typische Beispiele für Quellen, die Config Values für Anwendungen zur Laufzeit bereitstellen können. In diesem Fall stellt Kube die Quelle bereit und MicroProfile (und zukünftig auch Jakarta EE) stellt das Programmierungsmodell der Anwendung zur Verfügung, um die Config Values verwenden zu können.

HealthCheck ist ein ebenfalls gutes Beispiel – Kubernetes bietet die Möglichkeit, eine Liveness Probe zu konfigurieren und MicroProfiles (zukünftig Jakarta EEs) HealthCheck definiert Java-Annotationen, um einen von der Anwendung bereitgestellten Liveness-Pfad zu kennzeichnen, der deklarativ mit der Kube-Konfiguration verknüpft werden kann.

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

Alasdair Nottingham: Ich denke, es gibt einen großen Unterschied zwischen Java SE und Jakarta EE. Java SE hat eine relativ kleine Anzahl von Implementierungen, vielleicht 2 oder 3, aber Java EE 7 verfügt über 14 verschiedene Implementierungen. Es reicht nicht aus, schnell neue Versionen der Spezifikation zu veröffentlichen, wir brauchen auch die entsprechenden Implementierungen.

Daher denke ich, dass Jakarte EE, zumindest mittelfristig, langsamer sein muss als Java SE. Ich würde jährliche Releases von Jakarta EE bevorzugen. Ich denke, dass dies ein vernünftiges Gleichgewicht zwischen dem Spezifikation-Release und der kompletten Verfügbarkeit von Implementierungen ist. Wenn die Implementierungen schneller werden, dann kann das auch mit dem Release von Spezifikation geschehen, allerdings halte ich es für kontraproduktiv, Spezifikationen zu veröffentlichen, die niemand implementiert.

JAXenter: Wie plant ihr euch in den Entwicklungsprozess von Jakarta EE einzubringen? Gibt es irgendwelche Spezifikationen oder TCKs, die euch besonders interessieren?

Es wäre kontraproduktiv, Spezifikationen zu veröffentlichen, die niemand implementiert.

Emily Jiang: Ich werde mich in GitHub-Diskussion, in Sachen PR und Meetings einbringen. Ich gehöre zur CDI Expert Group und werde mich auch in der Annotaion-Spezifikation einbringen, wenn sie für neue Entwicklungen bereit ist. Ich freue mich darauf, mit meinen Beiträgen zu den neuen Funktionen in APIs, Spezifikationen und TCKs zu beginnen. Ich bin auch Spec Lead für das Config JSR. Wenn das Jakarta-EE-Grundgerüst vollständig funktioniert, können wir die Verschiebung des Config JSRs in Jakarta EE in Angriff nehmen.

Kevin Sutter: Wir wollen unsere Arbeit in Sachen Java Batch in Jakarta EE einbringen. IBM hat die Entwicklung des Java Batch JSRs und des damit verbundenen APIs und TCKs vorangetrieben. Derzeit befinden sie sich in einer eigenständigen Umgebung und Repository. Nun möchten wir sie in das Ökosystem von Jakarta EE einbinden.

IBM hat Vertreter in den meisten Jakarta-EE- bzw. EE4J-Projekten. Wir werden uns auch weiterhin an der Entwicklung der Spezifikationen, APIs, TCKs und Implementierungen beteiligen.

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

Kevin Sutter: Bleibt weiterhin aktiv! Wir haben eine ungeheure Energie und ein enormes Interesse an der Jakarte-EE-Bewegung erlebt. Wir müssen mit dieser Begeisterung weitermachen, um den langfristigen Erfolg dieses Ökosystems sicherzustellen. Aus diesem Grund müssen wir die Community um Geduld und Flexibilität bitten, während wir die verschiedenen Fragen und Probleme behandeln, die während des Migrationsprozesses entstehen. Einige der rechtlichen und lizenzrechtlichen Fragen sind sehr umfangreich und können bei einem so großen Umzug wie von Java EE zur Eclipse Foundation schwierig und kompliziert sein, aber das werden wir schon schaffen.

Am Ende wird Jakarta EE eine Programmiermodell-Plattform sein, die flexibel genug ist, um uns durch die nächsten 20 Jahre zu bringen!

JAXenter: Vielen Dank für das Interview!

Emily Jiang is MicroProfile Development Lead and CDI Architect for IBM. Based at IBM’s Hursley laboratory in the UK, she has worked on WebSphere Application Server since 2006 and heavily involved in JavaEE 7 support in WebSphere Application Server releases. She is an active member of MicroProfile, OSGi Enterprise Expert Group and CDI Expert Group. Emily is currently leading the effort to define Config and Fault Tolerance programming models to be used by microservices in MicroProfile.io. Follow her on Twitter @emilyfhjiang.

 

Ian Robinson is an IBM Distinguished Engineer and Chief Architect of the WebSphere Foundation.
Follow him on Twitter @ian__robinson.
 
 

 

Kevin Sutter s the lead architect for WebSphere’s MicroProfile and Java/Jakarta EE solutions. Follow him on Twitter: @kwsutter.
 
 

 

Alasdair Nottingham is Project Lead for Open Liberty. He works with Java, Java EE and MicroProfile. Follow him on Twitter: @nottycode.
 
 
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: