Sebastian Daschner Selbstständig

Es ist sehr sinnvoll, wenn in Enterprise-Projekten APIs eingesetzt werden, die den Entwicklern bekannt sind. Die APIs von Java EE sind weit verbreitet, weisen jedoch ein paar Lücken auf, die von MicroProfile-Projekten gefüllt werden können. Damit stellen wir uns MicroProfile als eine Art Erweiterung der bestehenden Java-EE-Standards vor. Softwareentwickler können mit den bekannten APIs die Applikationen weiterentwickeln und sparen sich, bekannte Patterns wie injizierbare Konfiguration oder Circuitbreaker selbst zu implementieren.

Es scheint, dass mehr und mehr Enterprise-Technologien entstehen, die auf Java EE basieren. Es gibt mittlerweile eine Vielzahl von Standards und Quasistandards, aus denen wir wählen können: Java EE, das jetzt Jakarta EE ist, MicroProfile und Kombinationen daraus. Wenn wir uns die verfügbaren Implementierungen und Container anschauen, wächst die Anzahl der Möglichkeiten noch weiter. Auf welche Plattform, Standards und Laufzeitumgebungen sollen wir unsere Applikationen im Jahr 2019 basieren?

Fangen wir mit Java EE an. Es gibt einige Java-EE-Standards, die weite Verbreitung finden, die Entwickler kennen und aus eigener Erfahrung gerne benutzen. Dazu zählen zum Beispiel CDI, JAX-RS, JSON-B oder JPA. Mit diesen und weiteren Technologien können wir mit hoher Produktivität Enterprise-Projekte entwickeln.

Java EE heute

Warum also reicht Java EE nicht aus? In der Welt von Microservices müssen wir bestimmte nichtfunktionale Anforderungen abdecken, die wichtig sind, wenn wir unsere Applikationen auf Produktion laufen lassen wollen. Zu diesen Anforderungen zählen unter anderem Resilienz, Monitoring oder Distributed Tracing. Ein weiterer oft bemängelter Punkt ist, dass Java EE im Standard keine einfach injizierbare Konfiguration mitbringt. Nun könnte man argumentieren, dass diese Aspekte nicht neu sind, sondern in den letzten Jahrzehnten immer nötig gewesen wären. Das ist auch vollkommen richtig, nur werden in der Welt von Microservices, in der Softwaresysteme mehr und mehr verteilt werden, eben diese Anforderungen auch immer wichtiger. Das ist ein Grund, warum sich die Industrie auch immer mehr auf diese Aspekte fokussiert. Besonders Cloudnative-Applikationen erfordern Aspekte wie Resilienz und Observability.

Jakarta EE

Wenn reines Java EE nicht ganz ausreicht, was hat es eigentlich mit Jakarta EE auf sich? Jakarta EE ist der Nachfolger von Java EE unter der Eclipse Foundation. Derzeit wird an dem Prozess gearbeitet, unter dem zukünftig die Vendor-unabhängigen Standards entwickelt und verabschiedet werden. Dabei befinden wir uns noch in der Aufbauphase und es gibt noch keine exklusive, reine Jakarta-EE-Version, die Entwickler verwenden könnten. Deshalb spreche ich im weiteren Verlauf dieses Artikels von Java EE, wenn von den Standards die Rede ist, die heute Teil von Java EE 8 sind.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 3.19 - "Chaos Engineering"

Alle Infos zum Heft
579878102Fürs Unternehmen: Java EE, Jakarta EE oder MicroProfile?
X
- Gib Deinen Standort ein -
- or -