Unsere Interview-Serie zu Jakarta EE: Ondrej Mihalyi

Jakarta EE im Klartext: „MicroProfile ebnet den Weg für eine bessere Unterstützung von Microservices im Jakarta-EE-Ökosystem“

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 Ondrej Mihalyi, Support Engineer bei Payara, Softwareenwickler und Consultant. 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 Ondrej Mihalyi, Support Engineer bei Payara, Softwareenwickler und Consultant. Ab geht die Reise ins Jakarta-EE-Universum!

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

Ondrej Mihalyi: MicroProfile ist bei der Eclipse Foundation als Projekt bereits etabliert und regelmäßige Updates werden durchgeführt. Das trifft auf Jakarta EE noch lange nicht zu. Ein Merge der beiden Projekte würde nur dann nicht schaden, wenn sie beide einem ähnlichen Prozess im Hinblick auf das Hinzufügen von neuen Features unterliegen würden. Bis dies soweit ist, sollte man die Projekte meiner Meinung nach getrennt voneinander entwickeln. Das bedeutet nicht, dass man nicht eng zusammenarbeiten kann, sodass MicroProfile vielleicht der etwas innovativere Zweig von Jakarta EE wird. So würden kollaborative Experimente möglich, bevor man das Endergebnis schließlich in den Jakarta-EE-Standard implementiert.

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?

Mit einer gemeinsamen Vision fällt es leichter, bessere Tools zu schaffen und bestehende Specs zu verbessern.

Ondrej Mihalyi: Für die Beantwortung der Frage muss zunächst klar sein, was Cloud-native denn eigentlich bedeutet. Es gibt ein Manifest dafür, was reaktive Anwendungen sind und das Agile Manifesto definiert die agile Softwareentwicklung, bzw. ihre Techniken. Nichts dergleichen existiert für die Definition von „Cloud-native“. Das was dem noch am nächsten kommt, ist die 12-Faktor-Methodologie. Jakarta EE ist eine gemeinsame Plattform, deren Community nach allgemein akzeptierten Definitionen suchen sollte, um die Bedürfnisse der Industrie zu beschreiben und deren Erfüllung zu beschleunigen.

Mit einer gemeinsamen Vision fällt es leichter, über Möglichkeiten zu sprechen, wie bessere Tools geschaffen und bereits existierende Spezifikationen verbessert werden können. Innerhalb der Community gibt es bereits exzellente Ideen, aber wir müssen klare Ziele definieren, um diese so effektiv wie möglich zu verwirklichen.

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

Ondrej Mihalyi: Jakarta EE ist so etwas wie ein Schirm unter dem eine große Anzahl von Spezifikationen angesiedelt sind. Auch wenn viele davon separat genutzt werden können, funktionieren sie am besten, wenn man sie alle gemeinsam nutzt. Mit Jakarta EE sollte als Orientierungshilfe für die einzelnen Spezifikationen dienen und wie gesagt eine gemeinsame Vision verkörpern. Auf diese Weise sollten die Spezifikationen einfacher im Verbund genutzt und effektiver kombiniert werden können, um gewisse Aufgaben (unter anderem eben Cloud Deployments) zu durchzuführen. Damit das Ganze funktioniert, muss Jakarta EE sich zu einer allgemein akzeptierten und offenen Plattform entwickeln, die das Interesse einflussreicher Unternehmen und von Experten der Industrie weckt. Nur so ist es möglich, dass genug Fachwissen und Führungsstärke den Standard vorantreiben.

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?

MicroProfile ebnet den Weg für eine bessere Unterstützung von Microservices im Jakarta-EE-Ökosystem.

Ondrej Mihalyi: MicroProfile ebnet bereits den Weg für eine bessere Unterstützung von Microservices im Jakarta-EE-Ökosystem. Allerdings benötigen Microservices sehr oft erst einmal Standards, die über die Java-Welt hinausgehen. Es ist sehr schwer mit Microservices zu arbeiten, wenn man nicht auf Container, Continuous Integration und das ganze Tooling zurückgreifen kann, das der Unterstützung der verteilten Natur von Microservices Rechnung trägt.

Jakarta EE sollte Ideen von MicroProfile übernehmen und den Weg standardisieren, kleine Services zu erstellen und konfigurieren. Aber es sollte auch mit anderen Projekten kollaborieren und andere Standards übernehmen, sodass eine perfekte Interoperabilität mit anderen Tools des Microservices-Ökosystems gewährleistet ist.

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?

Ondrej Mihalyi: Kubernetes ist eines der am weitesten verbreiteten Tools für das Ausführen von Microservices. Es ist allerdings nicht das einzige Tool für diesen Zweck und es gibt Unterschiede zwischen den verschiedenen Kubernetes-Distributionen der einzelnen Anbieter. Bei Java EE ging es immer um Standards und die Unabhängigkeit von bestimmten Anbietern, was auch für Jakarta EE die höchste Priorität sein sollte. Bei der Cloud Native Computing Foundation wird derzeit daran gearbeitet, Kubernetes zu standardisieren. Ich hoffe, dass diese Standardisierung eines Tages solide genug sein wird, damit man Kubernetes in Jakarta EE guten Gewissens integrieren kann.

Bis dahin ist es sicher besser, wenn Kubernetes innerhalb von MicroProfile und verschiedenen Frameworks unterstützt wird, die mit Jakarta EE kompatibel sind. So wird sichergestellt, dass sich Kubernetes problemlos mit Jakarta EE einsetzen lässt.

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?

Ondrej Mihalyi: Ich denke nicht, dass Updates im Halbjahresturnus irgendeinen positiven Effekt hätten. Es dauert eben eine Weile, um ein neues Feature von allen Seiten zu beleuchten und die Lösung entsprechend zu evaluieren. Sogar bei Java brauchen manche Features mehr als sechs Monate, um zur Veröffentlichung bereit zu sein. Und noch mehr Zeit kostet es, bis die Industrie diese neuen Java-Versionen dann auch einsetzt. Ich könnte mir ein Release pro Jahr vorstellen, während die Entwicklung neuer Features bereits vor der nächsten Jakarta-EE-Version beginnen kann.

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

Es ist nun deutlich einfacher, sich bei Jakarta EE einzubringen, als das noch im Korsett des JCPs möglich war.

Ondrej Mihalyi: Ich bin besonders daran interessiert, die meistgenutzten Spezifikationen von Jakarta EE (etwa JAX-RS und JPA) zu modernisieren. Es ist aber auch wichtig, die vielen verschiedenen Specs ein wenig zu polieren und die Lücken für Standardszenarios zu füllen. Besonders für die Möglichkeiten der reaktiven Programmierung interessiere ich mich, da gibt es bei Jakarta EE noch eine Menge zu vereinfachen und zu verbessern. Eine vereinfachte Concurrency wäre zum Beispiel wichtig, um Nutzer beim Schreiben von reaktivem Code zu unterstützen. Ich bin außerdem dabei, ein Streaming API und ein API für einfaches Messaging in MicroProfile zu integrieren. Es wäre schön, wenn diese auch in Jakarta EE einfließen würden.

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

Ondrej Mihalyi: Mit dem Umzug zur Eclipse Foundation wurde Jakarta EE zu einer unabhängigen Plattform, bei der jeder mitarbeiten kann. Es ist nun deutlich einfacher, sich einzubringen, als das noch im Korsett des JCPs möglich war. Jeder, der den Einsatz von Jakarta EE plant, sollte sich überlegen, ob er nicht auch bei der Richtung, in die sich die Plattform entwickelt, mitreden möchte. Das kann entweder auf einer der Mailing-Listen oder per Beitritt zur Eclipse Foundation sein, durch den man direkt Einfluss auf Jakarta EE nehmen kann.

Ondrej Mihalyi is a Support Engineer at Payara, software developer and consultant specializing in combining standard and proven tools to solve new and challenging problems. He’s been developing in Java and Java EE for nine years. As a Scrum Master and experienced Java EE developer he’s helped companies to build and educate their development teams, improve their development processes and be flexible and successful in meeting client requirements. He loves working with Java EE community and would welcome anyone to contribute to Payara Server, as well as to any other open source project in the Java EE ecosystem.
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: