Die Jakarta-Enterprise-Edition (Jakarta-EE), früher Java-Enterprise-Edition (JEE), ist eine Sammlung von Schnittstellen (APIs), die Standards bereitstellen, um Enterprise Anwendung zu implementieren. JEE gibt es bereits seit 1999. JEE legt viel Wert auf Kompatibilität mit früheren Versionen, ein Grund, weshalb es bis zur Version 7, noch vor der Übernahme durch Eclipse, eher schleppend mit der Weiterentwicklung der Standards voran ging. Auch das hat dazu geführt, dass sich der MicroProfile Standard entwickelt hat. Erst als die Eclipse Foundation JEE übernahm, seither nennt man es Jakarta-EE , gab es auch einen Schub bei der Entwicklung in Richtung Cloud-native Anwendungen.
Vorrangig glaubt man, dass Jakarta-EE eher für konventionelle Enterprise Anwendungen zu verwenden ist, wobei wir als Gepardec dieser Annahme nicht vollständig zustimmen können. Sicher ist, dass bei konventionellen mono-/modullithischen Enterprise-Anwendungen Jakarta-EE von großer Bedeutung ist, aber auch bei Cloud-nativen Anwendungen und Frameworks findet man Teile der Jakarta-EE Standards wie z.B.: Context-and-Dependency-Injection (CDI) und RESTful Web Services (JAX-RS). Ohne Jakarta-EE würde es keinen MicroProfile Standard geben, der auf Teile der Jakarta-EE aufbaut, insbesondere CDI und JAX-RS. Auch moderne Microservice Frameworks wie Quarkus oder Payara Micro kommen nicht ohne Jakarta-EE aus, wobei sie teilweise nicht den gesamten Stack benötigen und auf manche Aspekte von Standards wie CDI verzichtet wird. Als Beispiel sei Quarkus angeführt, das den CDI Standard nur teilweise implementiert und sich auf die Teile der CDI Spezifikation beschränkt, die im MicroProfile Standard benötigt werden.
Insbesondere CDI hat sich zu einem essentiellen Teil von Jakarta-EE entwickelt und integriert sich schon jetzt in viele Teile der Jakarta-EE Spezifikationen wie z.B.: Java-Persistence-API (JPA) und wird zukünftig auch in die restlichen Teile von Jakarta-EE integriert, wie z.B.: in die Jakarta-Servlet Spezifikation. CDI ist ein konkurrierendes Komponenten-Modell zu Enterprise-Java-Beans (EJBs), und EJBs können größtenteils durch CDI-Beans ersetzt werden. Trotzdem haben EJBs noch nicht ganz ausgedient und werden z.B. noch bei Jakarta-Messaging-Services (JMS) verwendet.
Jakarta-XML-Services (JAX-WS) aka SOAP Services findet man in der Praxis noch sehr häufig, wir präferieren bei neu geschriebenen Anwendungen JAX-RS, da RESTful Web Services sich de facto als Standard für die Kommunikation zwischen Anwendungen etabliert haben.
Bei Gepardec glauben wir fest an den Weiterbestand von Jakarta-EE und Enterprise Runtimes wie Wildfly, OpenLiberty oder Payara, denn es gibt noch viele mono-/modullithische Anwendungen, die nicht so schnell in Microservice migriert werden können. Teilweise bringt es auch keine Vorteile sie zu migrieren. Auch mit konventionellen Jakarta-EE Runtimes kann man Microservices betreiben, denn über die Zeit haben sich viele Enterprise Runtimes hin zu Single-Applikation-Containern entwickelt. Ob eine Cloud-native Anwendung Quarkus, Micronaut oder eine Jakarta-EE Runtime verwendet, kann der Client oder Kubernetes nicht erkennen, solange sie sich wie eine 12 Faktor App verhält.
Für die Zukunft erwarten wir, dass die Entwicklung der Jakarta-EE Standards weitergeht und sich immer mehr nach dem Paradigma der Cloud-Native-Entwicklung ausrichtet. Das wird z.B.: durch die Spezifikation von CDI-Light erkennbar, die nur mehr diejenigen essentiellen Teile der CDI Spezifikation beinhaltet, die vom MicroProfile Standard benötigt werden.
Wir bieten auch CDI Trainings an, bei denen die CDI Spezifikation und deren Aspekte Entwicklern näher gebracht werden, denn ohne CDI gibt es auch keinen MicroProfile Standard, also keine Cloud-nativen Anwendungen.
