Jakarta EE

AMPLIADO (el enunciado oficial del tema es literalmente «Java EE / Jakarta EE», así que el cambio de nombre y sus consecuencias no pueden faltar). La edición empresarial de Java ha cambiado de nombre y de propietario dos veces, y el examen pregunta por ello.

La donación tuvo una consecuencia que no es cosmética. Oracle cedió el código y las especificaciones, pero conservó la marca «Java», de modo que la plataforma tuvo que renombrarse y, con ella, sus paquetes: lo que se llamaba javax pasó a llamarse jakarta. El cambio se hizo efectivo en Jakarta EE 9 y obliga a tocar los ficheros fuente al migrar una aplicación antigua, porque cambian las importaciones.

// aplicación antigua, Java EE
import javax.servlet.http.HttpServlet;
import javax.persistence.Entity;

// la misma aplicación, Jakarta EE 9 o posterior
import jakarta.servlet.http.HttpServlet;
import jakarta.persistence.Entity;

Las especificaciones ya no se elaboran con el proceso de Oracle, sino con el propio de la fundación, el JESP (Jakarta EE Specification Process), que es abierto y en el que participan los fabricantes que después implementan la plataforma.

Solo se renombraron los paquetes de la edición empresarial. En Java SE siguen existiendo javax.sql, javax.xml.parsers o javax.naming: escribir «jakarta.sql» es un error, no una modernización.

La plataforma no se entrega en un solo bloque. Un servidor no tiene por qué implementarlo todo: puede certificarse para un perfil, que es un subconjunto de especificaciones pensado para un tipo de aplicación. Así una aplicación sencilla no arrastra el peso de servicios que no va a usar.

Junto a la plataforma existe MicroProfile, un conjunto de especificaciones complementarias orientadas a microservicios: comprobaciones de salud, métricas, tolerancia a fallos, configuración externa, autenticación con tokens y documentación de la API. Se apoya en el Core Profile, de modo que no es una alternativa a Jakarta EE sino una capa que se le añade cuando la aplicación se despliega como un conjunto de servicios pequeños en lugar de como una aplicación única.

Jakarta EE es un conjunto de especificaciones, no un programa. Quien las implementa es el servidor de aplicaciones, y ahí está la idea central de todo el subtema: la aplicación no se ejecuta sola, se despliega dentro de un servidor que le da hecho lo que necesita. El programador escribe componentes y el servidor los crea, los llama, los vigila y los destruye. Ese reparto tiene nombre: inversión del control.

Dentro del servidor hay contenedores, que son los entornos donde viven los componentes. El contenedor web sabe de HTTP: recibe la petición, decide a qué componente corresponde y llama al código Java, y es donde se alojan las piezas de presentación. El contenedor de EJB alberga los componentes de negocio y les aporta transacciones, seguridad y concurrencia sin que haya que programarlas.

Que la plataforma sea una especificación tiene una consecuencia práctica muy visible: hay varios productos compatibles entre los que elegir, y una aplicación bien escrita se puede llevar de uno a otro.

• Apache TomEE, la variante de Tomcat con los servicios empresariales añadidos.
• Eclipse GlassFish, la implementación de referencia.
• WildFly y su versión con soporte comercial, JBoss Enterprise Application Platform, de Red Hat.
• IBM WebSphere Liberty.
• Oracle WebLogic Server. Aparece a veces citado como «BEA WebLogic»: BEA fue la empresa que lo creó, comprada por Oracle en 2008.
• Payara, derivado de GlassFish con soporte comercial.

Un servidor web y un servidor de aplicaciones no son lo mismo. El primero sirve contenido por HTTP; el segundo implementa además las especificaciones de la plataforma y ofrece transacciones, mensajería, persistencia y seguridad a los componentes que aloja.

Una aplicación Jakarta EE se organiza en capas, y cada capa tiene sus componentes. Los componentes son las piezas que programa el desarrollador; los servicios, que se ven en el punto siguiente, son lo que le da hecho el servidor.

En la capa de presentación, la más cercana al cliente, viven los componentes que hablan HTTP y generan la respuesta.

• Servlet: recibe la petición HTTP y encamina el flujo hacia el resto de la aplicación. Es el componente de control.
• Filtro: se coloca delante de los servlets y trata aspectos transversales, como comprimir, validar o comprobar la autenticación.
• Jakarta Pages (las clásicas JSP): una página HTML en la que se intercalan trozos de código Java y objetos predefinidos.
• JSTL, la biblioteca de etiquetas estándar: sustituye ese código Java incrustado por etiquetas, de modo que la página vuelve a parecer una página.
• Jakarta Faces (JSF): un marco de componentes de interfaz ya construidos, que se colocan en la página como etiquetas y llevan asociado su propio comportamiento.

En la capa de negocio viven los Enterprise Beans (EJB), que son los componentes donde se programa la lógica de la aplicación. Los de sesión son los habituales: el servidor garantiza que sus métodos se ejecuten dentro de una transacción, de manera que si algo falla se deshace todo el trabajo sin escribir una línea para ello. Los hay sin estado, que no recuerdan nada entre llamadas y por eso el servidor puede reutilizar cualquier instancia para cualquier cliente, con estado, que sí guardan información entre llamadas de un mismo cliente, y de instancia única.

Hay un segundo tipo de bean que conviene distinguir: el dirigido por mensajes. En lugar de esperar a que alguien lo llame, se queda escuchando una cola de mensajes, y cuando llega uno el contenedor lo despierta y le pasa el contenido. Es la forma de programar procesos asíncronos: quien envía el mensaje no espera respuesta y sigue con lo suyo. Todos los servidores de la plataforma traen un gestor de colas incorporado.

La tercera vía de entrada a la capa de negocio son los servicios web, que exponen funcionalidad para que la consuman otras aplicaciones, en sus dos estilos: SOAP y REST.

Además de definir los componentes, la plataforma define servicios: capacidades que el servidor tiene la obligación de ofrecer y que la aplicación se limita a usar. Esta es la lista que hay que reconocer, con la sigla histórica por la que se sigue preguntando y el nombre actual, ya sin la marca Java.

La inyección de dependencias merece un momento aparte porque es la que explica el resto. Un objeto declara qué necesita y el contenedor se lo entrega ya construido, en lugar de que el objeto lo cree por su cuenta. De ahí sale la frase que resume la plataforma: la aplicación no hace el new, lo hace el servidor.

Cada servicio se usa a través de unos pocos objetos o anotaciones, y son justamente los que aparecen en las preguntas de detalle. Casi todos los crea el servidor y la aplicación se limita a pedirlos.

Dos matices que se preguntan con frecuencia. El primero: una sentencia preparada no solo se compila una vez y se reutiliza, sino que separa la sentencia de los valores, y por eso es la defensa estándar contra la inyección de SQL. El segundo: con una cola, muchos productores pueden publicar pero cada mensaje lo consume uno solo; para que un mismo mensaje llegue a varios receptores hace falta un tema.