JEE y Spring Boot

Teoría

¿Qué es JEE?

JEE (Java Enterprise Edition, hoy llamada Jakarta EE) no es un programa ni un producto: es un conjunto de especificaciones construidas sobre Java SE para resolver los problemas comunes de las aplicaciones empresariales — servicios web, transacciones, seguridad, persistencia, mensajería — sin que cada equipo tenga que reinventarlos. Entre sus especificaciones más conocidas están:

Especificación	Resuelve
Servlet	Recibir y responder peticiones HTTP
JPA	Mapear objetos Java a tablas de una base de datos relacional
EJB	Componentes de negocio con transacciones e inyección de dependencias gestionadas por el servidor
JMS	Mensajería asíncrona entre aplicaciones
CDI	Inyección de dependencias estandarizada
Bean Validation	Validar los datos de un objeto con anotaciones (@NotNull, @Size, …)

Nota

En 2019 Oracle transfirió Java EE a la Eclipse Foundation. Por temas de marca registrada, el proyecto pasó a llamarse Jakarta EE; a partir de la versión 9 los paquetes cambiaron de javax.* a jakarta.* (por ejemplo, javax.persistence.Entity pasó a ser jakarta.persistence.Entity). Si ves las dos formas en código o documentación distintos, es por esto: no son dos tecnologías distintas, es la misma especificación antes y después del cambio de nombre.

Como es una especificación y no un producto, JEE por sí sola no se “usa”: la usa un application server que la implementa — Servlet, JPA, EJB y las demás piezas funcionando juntas dentro de un mismo proceso. Ejemplos de application servers que implementan el paraguas completo de JEE son WildFly, Payara (heredero de GlassFish), Open Liberty, WebLogic y WebSphere.

¿Qué es un application server?

Un application server no es un lugar donde “se guarda” el código, como una carpeta o un repositorio: es un programa que se mantiene corriendo y que ejecuta tu aplicación dentro de sí mismo. Cuando decimos que “hacemos deploy”, esto es lo que pasa:

1. Compilas y empaquetas tu aplicación en un solo archivo: un .war en JEE tradicional, un .jar en Spring Boot.
2. Ese paquete se copia al application server (o, en el caso de Spring Boot, simplemente lo ejecutas: java -jar app.jar, porque el servidor ya viene empaquetado adentro).
3. El servidor arranca tu aplicación dentro de su propio proceso, no como un programa aparte.

Lo interesante ocurre justo después de arrancar. El servidor lee tus clases usando reflexión —la capacidad de Java de inspeccionar en tiempo de ejecución qué clases, métodos y anotaciones existen— y, según lo que encuentra, construye el comportamiento real de la aplicación:

• Si ve una clase anotada con @Entity, sabe que debe mapearla a una tabla de la base de datos.
• Si ve un método anotado con @GetMapping("/books"), registra esa ruta para que las peticiones HTTP a /books lleguen justo a ese método.
• Si ve @Autowired o @Service, crea el objeto —instancia la clase— y lo conecta con quien lo necesita: eso es la inyección de dependencias.
• Muchas veces ni siquiera te entrega tu objeto tal cual: crea una clase proxy que envuelve a la tuya, para poder ejecutar código antes o después de tus métodos. Por ejemplo, con @Transactional el proxy abre la transacción antes de llamar a tu método, y hace commit o rollback después, según si tu código lanzó una excepción o no.

Consejo

Si ya usaste Angular, esta idea no te es del todo ajena: los decoradores de TypeScript (@Component, @Injectable) cumplen un papel parecido al de las anotaciones de Java. En los dos casos, el decorador o la anotación no hacen nada por sí solos —son metadata—; es un motor externo (el compilador de Angular, o el application server) el que los lee y genera, a partir de ellos, el comportamiento real.

flowchart TD
    A["Código fuente con anotaciones<br/>@Entity, @RestController, @Autowired..."] --> B["Compilar y empaquetar<br/>.war o .jar"]
    B --> C["Deploy en el application server<br/>(o arranque de Spring Boot)"]
    C --> D["El servidor escanea las clases<br/>por reflexión"]
    D --> E["Resuelve las anotaciones:<br/>crea objetos, inyecta dependencias,<br/>genera proxies, registra rutas HTTP"]
    E --> F["Aplicación en ejecución,<br/>lista para recibir peticiones"]

Este es el patrón que vas a encontrar una y otra vez en las próximas páginas: escribes una clase con anotaciones, y es el servidor —Spring Boot, en nuestro caso— quien la convierte en un objeto vivo, conectado con las demás piezas de la aplicación.

Ventajas de JEE

Portabilidad

Una aplicación escrita contra las especificaciones de JEE debería correr, sin cambios, en cualquier application server certificado: WildFly, Payara, WebLogic, etc.

Todo incluido

Transacciones distribuidas, seguridad declarativa, mensajería, persistencia e inyección de dependencias vienen resueltos por el servidor: no hay que ensamblarlos por separado.

Estandarización por comité

Las especificaciones las define un proceso abierto (el Jakarta EE Working Group), no un solo proveedor, lo que reduce la dependencia de una empresa en particular.

Uso típico de JEE

JEE aparece sobre todo en aplicaciones empresariales grandes: sistemas bancarios, aseguradoras, entidades de gobierno o corporativos que ya tienen infraestructura corporativa alrededor de un application server (por ejemplo WebLogic o WebSphere), y que necesitan transacciones distribuidas robustas, alta disponibilidad, clustering e integración con sistemas legados —colas de mensajería empresariales, por ejemplo— certificados y con soporte comercial.

Desventajas de JEE

• Complejidad histórica. Las primeras versiones de EJB (1.x/2.x) exigían mucho código repetitivo y configuración en XML solo para lograr algo tan simple como persistir un objeto.
• Application servers pesados. Instalarlos, configurarlos y desplegar en ellos consume más recursos y tiempo que levantar una aplicación autocontenida.
• Ciclos de especificación lentos. Como cada cambio requiere consenso entre varios proveedores, adoptar prácticas nuevas del ecosistema Java toma más tiempo que en un framework de un solo equipo.
• Modelo de despliegue rígido. El empaquetado tradicional en WAR/EAR sobre un servidor compartido no encaja naturalmente con contenedores y microservicios, aunque las versiones recientes de Jakarta EE y proyectos como MicroProfile buscan cerrar esa brecha.

Spring Boot: la aproximación que usamos en el curso

Spring nació como reacción a esa complejidad: en vez de EJBs pesados, propuso construir la lógica de negocio con objetos Java simples (POJOs) a los que el framework les agrega, por fuera, inyección de dependencias, transacciones y AOP. Por eso a Spring se lo describe históricamente como una alternativa más liviana al JEE de EJB, no como un reemplazo del application server tradicional.

Spring Boot lleva esa idea un paso más allá: empaqueta Spring con configuración automática (auto-configuration) y un servidor Servlet embebido (Tomcat, por defecto), para que una aplicación se ejecute como un .jar independiente —java -jar app.jar— sin necesidad de instalar ni desplegar en un application server externo.

Una precisión importante

Spring Boot no es una implementación certificada de la plataforma Jakarta EE completa — no pasa el TCK (Technology Compatibility Kit) que sí pasan WildFly, Payara o WebLogic. Lo que hace es usar piezas concretas de esas especificaciones: JPA (con Hibernate como proveedor), Servlet (con Tomcat embebido), Bean Validation. Por eso conviene decir que Spring Boot construye sobre especificaciones de JEE/Jakarta EE, más que decir que es una implementación de JEE.

Spring Boot es, con distancia, el framework más usado hoy para construir APIs REST en Java, y es el que usamos en este curso. No es el único con ese espíritu: Quarkus (Red Hat) y Micronaut (Object Computing) siguen la misma idea —arranque rápido, poca configuración, aplicación autocontenida— optimizando además para contenedores y serverless; Helidon (Oracle) va en la misma línea y además puede correr directamente sobre especificaciones de MicroProfile.

Autoevaluación

1. ¿Qué es JEE (Jakarta EE), exactamente?

Un application server específico que se instala y configuraUn conjunto de especificaciones para aplicaciones empresariales en JavaUn lenguaje de programación distinto de Java

2. Cuando el application server arranca tu aplicación, ¿qué hace además de simplemente ejecutar el punto de entrada del programa?

Nada más: solo ejecuta el código tal cual está escritoEscanea las clases por reflexión, resuelve las anotaciones y crea los objetos, proxies y rutas HTTP necesariosConvierte automáticamente todo el código Java a HTML

3. ¿Por qué se dice que Java EE pasó a llamarse Jakarta EE?

Porque Oracle dejó de dar soporte a Java por completoPorque Oracle transfirió el proyecto a la Eclipse Foundation y no pudo ceder la marca 'Java'Porque es una tecnología completamente distinta, sin relación con Java EE

4. ¿Cuál de estas es una desventaja real, históricamente asociada a JEE?

No permite hacer transacciones distribuidasLos application servers tradicionales son pesados de instalar, configurar y desplegarNo tiene ninguna especificación para persistencia de datos

5. ¿Por qué no es del todo preciso decir que 'Spring Boot es una implementación de JEE'?

Porque Spring Boot no usa ninguna especificación de JEEPorque Spring Boot usa piezas de JEE (JPA, Servlet) pero no es un application server certificado contra el TCK completoPorque Spring Boot es anterior a la creación de JEE

6. ¿Cuál de estos frameworks comparte el mismo espíritu de Spring Boot (arranque rápido, poca configuración, aplicación autocontenida)?

WebLogicQuarkusEJB 2.1

Comprobar