JAXenter: Moderne Web APIs mit Jakarta EE heißt ein Workshop auf dem API Summit. Beginnen wir mal mit dem ersten Teil des Titels „Moderne Web APIs“. Was machen „moderne“ Web APIs heutzutage aus? Welche Eigenschaften sollten sie erfüllen?

Stephan Müller: Moderne Web APIs zeichnen sich für uns durch die folgenden Eigenschaften aus: Sie sind leicht verständlich, für ihre Benutzer leicht zu bedienen und passend für ihren Einsatzzweck, d.h. neben Request-Response auch Push-Mechanismen und nachrichtenbasierte Kommunikation zu ermöglichen. Des Weiteren nutzen „moderne“ Web APIs die Mechanismen des Web bestmöglich aus und bieten einfache und einheitliche Lösungen für nicht-funktionale Aspekte wie Security und Fehlerbehandlung.

JAXenter: Im Workshop kommt der API-First-Ansatz zur Sprache. Worum geht es dabei?

Stephan Müller: Der API-First-Ansatz stellt das Schnittstellendesign in den Mittelpunkt. Zielsetzung ist es, den Entwicklungsprozess ganz auf das zu realisierende API auszurichten. Man startet quasi auf der grünen Wiese und versucht, existierende Abhängigkeiten z.B. durch Drittsysteme bestmöglich auszublenden. Damit wird der Freiraum geboten, sich beim Schnittstellendesign im ersten Schritt ausschließlich auf die Konsumenten des neuen API zu konzentrieren.

Eine klare Schnittstelle garantiert zusätzlich, dass sowohl das Backend als auch die Clients mit der Gewissheit entwickelt werden können, dass letztlich alle Teile nahtlos zusammen passen.

Zielsetzung des API-First-Ansatzes ist es, den Entwicklungsprozess ganz auf das zu realisierende API auszurichten.

JAXenter: Welche Vorteile bringt es, wenn man den Entwurf des APIs an die erste Stelle rückt?

Stephan Müller: Wir erleben es gerade bei bestehenden Anwendungen, dass oftmals einfach interne Datenmodelle mit Hilfe einer „neuen“ Schnittstellen-Technologie nach außen gereicht werden, ohne ernsthaft darüber nachzudenken, welcher Client die neue Schnittstelle in welcher Form nutzen soll. Das führt z.B. dazu, dass eine mobile App dieselben Daten erhält wie ein Fat-Client, auch wenn sie nur einen Bruchteil davon nutzt.

Beim API-First Ansatz wird eine Schnittstelle iterativ mit dem Fokus auf die Konsumenten des API unter der Einbeziehung ihres Feedbacks entwickelt. Für das daraus resultierende API ist gewährleistet, dass es die Anforderungen erfüllt und einen echten Mehrwert bietet.

JAXenter: Und dann kommen wir zum zweiten Teil des Titels: Jakarta EE – so wird fortan die Java Enterprise Edition genannt. Wie gut ist Jakarta EE für den Bau der gerade beschriebenen modernen Web APIs geeignet?

Sven Kölpin: Die Java-EE-Plattform bietet seit 2010 mit JAX-RS, BeanValidation, CDI und seit Java EE 8 mit JSON-B grundsätzlich alles, was zur Erstellung moderner leichtgewichtiger Web APIs benötigt wird. Unter der Verwendung dieser Techniken lassen sich bereits mit wenigen Code-Zeilen robuste und skalierbare Web-APIs entwickeln. Und genau das wird in dem Workshop gezeigt.

JAXenter: Wo sollte Jakarta EE noch nachlegen?

Sven Kölpin: Die Java Enterprise Edition hat bislang nicht gerade mit kurzen Innovationszyklen geglänzt – andere Frameworks waren bisher meistens schneller, wenn es um die Integration neuer Features oder Konzepte geht. Dafür konnte man bei EE aber immer auf eine Spezifikation zurückgreifen, die durch ihre Standardisierung sehr ausgereift und durchdacht ist. Zudem lassen sich fehlende Features mit überschaubarem Aufwand selbst in die Plattform integrieren. Es bleibt spannend, inwiefern sich die Releasezyklen durch den Umzug der Spezifikation verändern werden.

Die Enterprise-Plattform ist darauf ausgerichtet, dass die Abarbeitung eines Requests innerhalb eines Threads vorgenommen wird.

Die Enterprise-Plattform ist momentan noch stark darauf ausgerichtet, dass die Abarbeitung eines Requests innerhalb eines Threads vorgenommen wird. Das erschwert die Integration von non-blocking und reaktiven Konzepten.

Stephan Müller: Wir erhoffen uns viel mehr eine größere Breite und Wahlmöglichkeit. Für Java EE 8 wurde mit MVC 1.0 bereits ein Schritt in diese Richtung versucht, auch wenn es MVC letztlich leider nicht in das Release geschafft hat. Selbiges wünschen wir uns z.B. auch für MQTT und AMQP als Alternative zum JMS.

JAXenter: Wie ist generell der Übergang von Java EE nach Eclipse zu beurteilen? Birgt das nicht die Gefahr, dass gewisse Spezifikationen des traditionellen Java EE nicht mehr genügend Mitstreiter finden werden?

Stephan Müller: Grundsätzlich positiv, der gefühlte Stillstand in den letzten Jahren wird jetzt hoffentlich durch einen neuen Schwung ersetzt.

Dass die neue Entwicklung eine Gefahr für traditionelle Spezifikationen birgt, sehen wir erstmal nicht, da viele Spezifikationen schon seit Jahren auch maßgeblich von der Community vorangetrieben werden. Sollte irgendwann doch mal eine Spezifikation aussortiert werden, so wird dies keine einsame Entscheidung gewesen sein, sondern von der breiten Masse mitgetragen werden.

JAXenter: Moderne Web- bzw. Cloud-Anwendungen baut man auch mit JavaScript, Go, Docker, Kubernetes, OpenShift, AWS Lambda, etc. Vieles davon Technologien, die man mitunter als „Cloud-native“ bezeichnet hat. Wie steht Jakarta EE im Vergleich zu diesen Technologien da? Hat Jakarta EE da einen Nachholbedarf?

Stephan Müller: Wir sehen z.B., dass sich Technologien wie Docker, Kubernetes und OpenShift rasend schnell in Unternehmen verbreiten, die nahezu ausschließlich auf die Java-EE-Plattform setzen. Entwicklung wie Betrieb haben die Vorteile dieser Technologien erkannt und wollen das Beste beider Seiten für sich nutzen.

Sven Kölpin: Nachholbedarf hat Jakarta EE aus unserer Sicht vor allem bei non-blocking und reaktiven Konzepten sowie der Möglichkeit, Java-EE-Anwendungen ohne Application Server auszuführen. Beim zweiten Punkt werden sicherlich die MicroProfiles eine gewichtige Rolle spielen, die diesen Aspekt sowie die Integration von Quasi-Standards wie JWT und Metrics zum Ziel haben.

Nachholbedarf hat Jakarta EE vor allem bei non-blocking und reaktiven Konzepten.

JAXenter: Welche Vor- und Nachteile bietet die Nutzung von Jakarta EE? Warum nicht gleich auf Cloud-native Technologien setzen?

Stephan Müller: Viele Unternehmen setzen seit mehr als 10, manche seit 20 Jahren auf die Java-Enterprise-Plattform, daher wird Jakarta EE ihnen weiterhin die benötigte langfristige Planbarkeit bieten. In Kombination mit Docker, Kubernetes und OpenShift werden diese Unternehmen gut für die Zukunft aufgestellt sein.
Ein vollständiger Wechsel zu Cloud-native Technologien wird für manche jedoch ein sehr großer Schritt, da sie immer noch dabei sind, ihre Cobol- und Host-Entwickler auf Java umzuschulen. Des weiteren behindern aktuell Vorbehalte und/oder Vorschriften den Betrieb von Anwendungen außerhalb des eigenen Rechenzentrums. Hier müssen die bestehenden Strukturen erst langsam aufgebrochen und Erfahrungen gesammelt werden. Wir gehen aber davon aus, dass sich auch in diesem Bereich in den nächsten Jahren eine Menge tun wird.

JAXenter: Vielen Dank für dieses Interview!

Geschrieben von: Hartmut Schlosser

Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. SEO und KPIs isst er zum Frühstück. Satt machen ihn kreative Aktionen, die den Leser bewegen.