Suche
Unsere Interview-Serie zu Jakarta EE: Werner Keil, Java-EE-Experte und Agile Coach

Jakarta EE im Klartext: „In einer perfekten Welt könnten sich mehrere Microservices eine gemeinsame SSO-Lösung teilen“

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 Werner Keil, Java-EE-Experte und Agile Coach. 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 Werner Keil, Java-EE-Experte und Agile Coach. Ab geht die Reise ins Jakarta-EE-Universum!

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

Werner Keil: Ja, zumindest wäre es gut, einige Teile zu übernehmen. Vermutlich aber nicht komplett, denn es gibt durchaus Dinge in MicroProfile, die eher nicht zum Standard taugen. Dazu zähle ich vor allem Dinge, die nur eine bestimmte Lösung unterstützen, etwa FailSafe im Gegensatz zu anderen Technologien wie Hystrix usw. MicroProfile Metrics (bei dem ich mich beratend im Hinblick auf die Messeinheiten engagiert habe) ist außerdem Dropwizard Metrics sehr ähnlich, lediglich der Unit Support hilft beim Beliefern von Prometheus mit Daten.

Man sollte möglichst bald den REST Client von MicroProfile in den JAX-RS-Standard übernehmen.

Ein sehr populäres, aber eben nicht standardisiertes System wie Prometheus zu unterstützen, macht eine Standardisierung von Dropwizard Metrics eher fraglich. Config hingegen diente als eine Art Inkubator für ein JSR, ist etwa Hibernate nicht unähnlich, muss aber das MicroProfile Config API und JSR 382 gleichzeitig unterstützen. Das sorgt für eine gewisse Problematik für alle an diesem Projekt Beteiligten, da sie mindestens zwei Code Repositorys zur gleichen Zeit verwalten müssen. Wenn man dann noch DeltaSpike Config und Geronimo Config ins Spiel bringt, sind es schon vier Repositorys. Im Zuge des JSR sollte man möglichst bald, gemäß des neuen Spezifikationsprozesses, ein Early Draft Review (EDR) veröffentlichen.

Der MicroProfile REST Client ist hingegen etwas, dass man möglichst bald in den JAX-RS-Standard übernehmen sollte. Eigentlich hätte das schon längst Teil von JAX-RS sein sollen, denn sonst riskiert man Redundanzen und Inkompatibilität zwischen Jakarta EE und MicroProfile, von denen beide nicht profitieren können.

Neben dem „Full Profile“ und dem „Web Profile“ muss bald wenigstens ein weiteres, gut abgestimmtes und sehr viel kleineres Profil geben. Ob man das nun „Micro Profile“ oder irgendwie anders benennt, ist Aufgabe des Marketings. Schön wäre auch ein Do-it-yourself-System wie JHipster, aber es wird schwer, wenn nicht gar unmöglich, im Hinblick darauf Kompatibilität zu garantieren. Allerdings könnten die Nutzer dann die Jakarta-EE-Standards mit Funktionen aus anderen Stacks kombinieren – je nach Bedarf.

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?

Werner Keil: Nun, Cloud-native ist sowohl ein Buzzword als auch ein großes Sammelsurium von Technologien, Methodologien und Architekturebenen. Mit Cloud-native ist es das Gleiche wie mit dem ehemaligen Anspruch, SOA zu unterstützen. Man könnte genauso gut sagen, Jakarta EE müsse „agile“ machen.

Die eben erwähnten Ebenen sind nur der Anwendungsteil, nicht die unterliegende Infrastruktur. Von API Gateways abgesehen lassen sich alle Ebenen mit Java EE 7 oder 8 durchaus erstellen. Sie machen das Betreiben von Self-contained Systems (SCS) leichter, nicht jedoch von vollkommen unabhängigen Microservices – jedenfalls nicht ohne etwas Overhead. Auch das Kombinieren von zwei oder mehr Anbietern für die Implementierung und von Containern ist noch immer sehr mühsam.

API Summit 2018
Christian Schwendtner

GraphQL – A query language for your API

mit Christian Schwendtner (PROGRAMMIERFABRIK)

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

Werner Keil: Es gibt verschiedene Deployment-Arten in Bezug auf die Cloud: on premise, IaaS, PaaS, SaaS – Letztere basieren auf Java, wobei die Endnutzer das oft nicht merken oder überhaupt Interesse daran haben. On premise und bei Infrastructure as a Service (IaaS) hat man die volle Kontrolle über Sicherheits-Features, idealerweise über Standards wie JSR 375/Enterprise Security. Bei Platform as a Service Cloud-Lösungen (PaaS) kann das allerdings anders aussehen, wenn diese Features vom Anbieter verwaltet und kontrolliert wird. Weder OAuth noch JWT sind automatisch portierbar, denn beide erlauben viele Einstellungen und Details können je nach Anbieter deutlich variieren. Bei unserer Arbeit am Projekt Agorava haben wir gelernt, dass OAuth sich nicht immer auf gleiche Weise nutzen lässt, wenn man eine Anwendung über viele Social APIs verbindet.

In einer perfekten Welt sollten sich mehrere Microservices eine gemeinsame SSO-Lösung (etwa Keycloak oder Spring Security) teilen können. Da die Standardisierung von JSR 375 allerdings noch in der Entwicklung ist, zeichnet die Realität ein anderes Bild. Man kann dies mit dem Servlet-Standard in dessen frühen Tagen und den verschiedenen, oftmals komplett inkompatiblen Erweiterungen wie Struts, Spring MVC, Vaadin oder Wicket, um nur ein paar wenige zu nennen. Auch in Bezug auf NoSQL-Datenbanken als Alternative zu klassischen RDBMS gibt es recht wenig Standardisierung. Das Projekt Eclipse JNoSQL, das noch nicht Teil von Jakarta EE ist, hat großes Potential dafür, die Nutzung von Datenbanken mit Jakarta EE über verschiedene Cloud-Umgebungen hinweg weniger umständlich zu machen.

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?

Werner Keil: Jakarta EE sollte modularer werden, als es derzeit noch ist. Das „Web Profile“ war ein guter erster Schritt, auch wenn er etwas zu lange gebraucht hat. Obwohl es sehr leicht ist, eine SCS-Architektur mit Java EE 7 oder 8 umzusetzen, gehen klassische, vollständig unabhängige Microservices mit Hunderten von Services nicht gerade schonend mit der Hardware und anderen Ressourcen um.

Es wäre gut, wenn es so etwas wie ein „Microframework Profile“ in Jakarta EE geben würde.

Einfacher wäre es also, wenn es in einem der nächsten Releases von Jakarta EE so etwas wie ein „Microframework Profile“ gäbe. Natürlich sollte die Unabhängigkeit von den Anbietern gewahrt bleiben, denn ich kann mich an viele Fälle erinnern, bei denen Kunden von einem Portalanbieter zum anderen wechseln mussten. Das war nie einfach, aber immerhin möglich, dank des Java-Portlet-Standards, der auf Java EE aufsetzt. Von Lagom auf Spring Boot umzustellen, ist heutzutage sehr viel schwerer und oft schreibt man am Ende den Großteil des Codes während dieses Umzugs neu. Beide Anbieter sind übrigens nun Mitglied der Jakarta-EE-Initiative und der entsprechenden Working Group, sodass dieses Problem bald hoffentlich behoben sein wird.

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?

Werner Keil: Blöderweise vergleicht die Umfrage Äpfel mit Birnen, insbesondere bei der Frage nach den „Frameworks“ auf Seite 21. Nicht nur, dass OpenShift auf Kubernetes aufbaut. JHipster verwendet beispielsweise auch Technologien wie Spring Boot, es macht also keinen Sinn, diese Tools unabhängig von einander aufzuführen. Dort werden Anwendungs-Frameworks mit Infrastruktur-Elementen vermischt, was das Ganze ziemlich sinnlos macht. Ich kann verstehen, warum man so vorgeht, aber so sind die Zahlen praktisch wertlos.

Die Virtualisierung oder Container-Technologien sind wichtig, aber die Docker- oder Kubernetes-Integration werden vor allem für zukünftige Versionen von Java SE wichtig, mit deren Umsetzung Oracle bereits ab Java 10 begonnen hat. Natürlich können so aber nur neue JVM-Optionen zur Verfügung gestellt werden, das entsprechende Tooling hingegen muss man woanders entwickeln. Das liegt eher in den Händen von Jenkins, Gradle oder Maven, nicht bei Jakarta EE selbst.

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?

Werner Keil: Ein großes Release, bei dem entweder die erste Zahl (wie Java 10, Java 11, Java 12) oder die zweite Zahl (wie Eclipse IDE 4.8, 4.9) der Versionsnummer stetig erhöht wird, könnte einmal pro Jahr veröffentlicht werden. Mehr wäre Wahnsinn, selbst wenn alle Nutzer Cloud-Umgebungen nutzen würden (was allerdings in Europa und speziell in Deutschland eher Zukunftsmusik ist), wo neue Versionen ganz einfach über Container Images installiert werden könnten. Die (frühere – Anm. d. Red.) Release-Kadenz für die Eclipse IDE scheint mir ein guter Kompromiss zu sein: Ein Hauptupdate pro Jahr und dann drei bis vier Upgrades hiernach.

Mehr als ein Major Release pro Jahr wäre Wahnsinn.

In der Enterprise-Welt, wo viele Produkt- und Versionszyklen sehr viel langsamer ablaufen, würde ein neues Major Release alle paar Monate für große Aufregung sorgen. Ich kann mir also kein Szenario wie etwa bei Google Chrome oder Mozilla Firefox vorstellen.

Die Umfrage zu Jakarta EE zeigt, dass jeder zehnte Teilnehmer noch Java EE 5/J2EE nutzt. Rund 60 Prozent nutzen noch Java EE 7, obwohl Java EE 8 bereits seit einem Jahr verfügbar ist, 40 Prozent setzen auf Java EE 6. Vergleicht man dies mit Java SE, wird der Unterschied sehr deutlich: Fast 90% nutzen Java SE 8. Man kann also deutlich sehen, dass es unmöglich wäre, monatliche Releases oder sogar nur halbjährliche im Enterprise-Kontext durchzusetzen.

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

Werner Keil: Ich habe an mehrere Jakarta-EE-Spezifikationen mitgearbeitet, als sie noch Teil von Java EE 8 waren. Besonders die JSRs für Security (JSR 375) und JSON-P lagen bei mir im Fokus. Letzteres haben einige von uns am Leben erhalten, bis Dmitry Kornilov, der Spec Lead von JSON-B, sich bereit erklärte, beide JSON JSRs zu übernehmen. Ich bin zudem Committer bei den Messaging-Projekten, bei denen wir hoffen, zumindest das fertig zu stellen, was für Java EE 8 noch nicht fertig wurde. Vielleicht können wir darüber hinaus an den Spezifikationen arbeiten, ich kann mir etwa Synergien zwischen dem Jakarta EE Messaging Stack und dem Internet of Things (Stichwort MQTT) vorstellen.

Als einer von nur zwei Menschen, die in sämtlichen Java EE Umbrella JSRs zwischen EE 6 und EE 8 vertreten waren, habe ich darum gebeten, dem Jakarta-EE-Umbrella-Projekt beitreten zu dürfen. Das wurde mir gestattet. Das TCK-Projekt wurde bereits vorher erstellt und viele TCKs waren bislang nicht Open Source – wer an diesen als Committer mitarbeiten will, muss von anderen Committer vorgeschlagen und dann von den anderen Committern bestätigt werden. Da ich eines der wenigen modularen Open Source TCKs (und mehrere kleinere „Profile“ für JSR 363) geschrieben habe, würde ich gerne mit dieser Erfahrung bei den Jakarta EE TCKs helfen. Egal, ob es nun drei oder mehr solcher Profile geben wird, könnte ich mir vorstellen, dass eine solche Flexibilität nicht schaden kann.

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

Meine Empfehlung an die Community: Folgt den Mailing-Listen!

Werner Keil: Die Community sollte allen Kanälen folgen, die verfügbar sind. Das gilt insbesondere für die Mailing-Listen, die generell für Jakarta EE bzw. speziell für einzelne Specs und Projekte existieren. Es gibt natürlich viele Akteure wie die Eclipse Foundation, die Apache Software Foundation oder die Cloud Native Alliance, um nur einige wenige zu nennen. Auch Oracle bleibt ein Aktivposten, obwohl sie massiv auf PaaS-Ansätze wie AWS Lambda oder Project Fn bauen.

Die JavaOne existiert nicht mehr, höchstens vielleicht untegeordnet als kleiner Teil der Angebote rund um „Cloud Native“ und zwischen duzenden von Sprachen bei der Oracle Code One. Die Konferenz fand zudem, aus Zufall oder Ungeschick, genau zur gleichen Zeit statt, wie die EclipseCon Europe. Dies ist die größte Konferenz der Eclipse Foundation, unter deren Dach nun Jakarta EE weiterentwickelt wird. Natürlich war dort Jakarta EE und dessen Bestandteile auch Thema. Nicht jeder der Community kann beide Konferenzen besuchen.

JAXenter: Vielen Dank für das Interview!

Werner Keil is an Agile Coach, Java EE and IoT/Embedded/Real-Time expert. He has helped Global 500 companies from all industries and leading IT companies for 25 years as a program manager, coach, software architect and consultant. Werner is an Eclipse and Apache committer and JCP member in JSRs such as 333 (JCR), 342 (Java EE 7), 354 (Money), 358/364 (JCP.next), Java ME 8, 362 (Portlet 3), 363 (Units and Spec Lead), 365 (CDI 2), 375 (Java EE Security) and member of the Executive Committee.
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: