Tema 19. Arquitectura Java EE/Jakarta EE y plataforma.NET: componentes, persistencia y seguridad. Características, elementos, lenguajes y funciones en ambos entornos. Desarrollo de interfaces.

1. Arquitectura Java EE/Jakarta EE y plataforma

1. Arquitectura Java EE/Jakarta EE y plataforma

🎯 Idea clave

• Jakarta EE es una plataforma de especificaciones abiertas para aplicaciones empresariales Java, no un producto o servidor concreto.
• Provee servicios horizontales como transacciones, seguridad, persistencia y mensajería mediante contenedores que ejecutan componentes.
• La plataforma evolucionó desde Java EE hasta Jakarta EE bajo la Eclipse Foundation, sustituyendo el espacio de nombres javax.* por jakarta.*.
• Las aplicaciones se empaquetan en formatos JAR, WAR y EAR, y la plataforma se organiza en perfiles como Web Profile y Core Profile.
• Es fundamental en la Administración General del Estado española para sistemas backend de organismos como AEAT, Dirección General de Tráfico y Seguridad Social.
• La portabilidad entre servidores requiere uso estricto de APIs estándar verificadas mediante el Technology Compatibility Kit.

📚 Desarrollo

Definición y naturaleza. Jakarta EE constituye la especificación abierta principal para desarrollar aplicaciones empresariales sobre la plataforma Java. No debe entenderse como un producto software específico ni como un único servidor, sino como un conjunto de especificaciones que diversos proveedores implementan mediante servidores de aplicaciones y runtimes compatibles, garantizando interoperabilidad y estándares comunes.

Evolución histórica y denominación. Originariamente conocida como J2EE y posteriormente como Java EE bajo el ecosistema Oracle y el Java Community Process, la plataforma fue transferida a la Eclipse Foundation adoptando el nombre Jakarta EE. Este cambio implicó la modificación del espacio de nombres de paquetes, pasando de javax.* a jakarta.* en las APIs modernas, manteniendo la nomenclatura anterior en código legado.

Arquitectura multicapa y servicios. La plataforma define un conjunto coherente de APIs y contratos entre componentes y contenedores, ofreciendo servicios horizontales como gestión de transacciones, seguridad, persistencia, mensajería, inyección de dependencias y comunicaciones. Esta arquitectura permite construir aplicaciones distribuidas, escalables, mantenibles y seguras, organizadas en capas lógicas de presentación, servicios web, negocio e integración.

Relevancia en la Administración Pública. Su importancia para las Administraciones Públicas españolas es de primer orden, ya que una parte significativa de los sistemas backend de la Administración General del Estado se ha construido sobre esta plataforma. Organismos como la AEAT, la Dirección General de Tráfico y la Seguridad Social mantienen sistemas críticos desarrollados en Java EE/Jakarta EE, frecuentemente combinados con frameworks como Spring y publicados como software de fuentes abiertas.

Empaquetado y perfiles. Las aplicaciones Jakarta EE se empaquetan tradicionalmente mediante formatos JAR, WAR y EAR, aunque los runtimes modernos pueden simplificar estos despliegues. La plataforma se organiza en la plataforma completa y perfiles específicos como el Web Profile y el Core Profile, permitiendo adaptar la funcionalidad a las necesidades concretas del proyecto.

Portabilidad y verificación. La portabilidad entre diferentes implementaciones depende del uso estricto de APIs estándar y la evitación de extensiones propietarias innecesarias. El Technology Compatibility Kit verifica que una implementación cumple efectivamente con una especificación o perfil determinado, garantizando la compatibilidad entre servidores como GlassFish, WildFly, Payara, Open Liberty, WebLogic o WebSphere.

Requisitos técnicos actuales. La versión Jakarta EE 11, estable y vigente, requiere como mínimo Java SE 17 o superior para su ejecución. La migración desde versiones anteriores de Java EE exige atender específicamente al cambio de espacio de nombres en las importaciones y dependencias del proyecto.

🧩 Elementos esenciales

• Especificación abierta: Conjunto de APIs estándar gobernadas por el proceso de Jakarta EE en la Eclipse Foundation, no un producto comercial único.
• Contenedores: Ejecutan componentes y aportan servicios como inyección de dependencias, transacciones, seguridad y gestión de recursos de forma transparente.
• Servicios horizontales: Funcionalidades transversales incluidas transacciones, seguridad, persistencia, mensajería y comunicaciones disponibles para todas las capas.
• Espacio de nombres: Migración progresiva de javax.* (Java EE legado) a jakarta.* (Jakarta EE actual) en las APIs modernas.
• Empaquetados clásicos: JAR para bibliotecas, WAR para aplicaciones web y EAR para aplicaciones empresariales completas.
• Perfiles de plataforma: Web Profile para aplicaciones web, Core Profile para microservicios y plataforma completa para aplicaciones empresariales tradicionales.
• Technology Compatibility Kit (TCK): Conjunto de pruebas que verifican la conformidad de una implementación con la especificación Jakarta EE.
• Implementaciones: GlassFish, WildFly, Payara, Open Liberty, WebLogic y WebSphere son servidores de aplicaciones compatibles.
• Arquitectura multicapa: Separación lógica en presentación, servicios web, lógica de negocio e integración de sistemas.

🧠 Recuerda

• Jakarta EE es especificación, no servidor; la implementación corre en servidores de aplicaciones compatibles.
• El cambio de Java EE a Jakarta EE implicó el traspaso a Eclipse Foundation y el nuevo espacio de nombres jakarta.*.
• Las aplicaciones AGE españolas utilizan extensivamente esta plataforma para sistemas backend críticos.
• JAR, WAR y EAR son los formatos de empaquetado estándar para distribución de componentes.
• El TCK garantiza que un servidor cumple realmente con las especificaciones Jakarta EE.
• Jakarta EE 11 requiere Java 17 o superior como versión mínima del lenguaje.
• La portabilidad exige usar APIs estándar y evitar extensiones propietarias de fabricantes específicos.

2. NET: componentes, persistencia y seguridad

2. NET: componentes, persistencia y seguridad

🎯 Idea clave

• El núcleo de .NET es el Common Language Runtime (CLR), una máquina virtual que gestiona la ejecución del código gestionado mediante recolección de basura, verificación de tipos y compilación JIT o AOT.
• Los ensamblados constituyen las unidades fundamentales de despliegue, conteniendo código compilado a Common Intermediate Language (CIL), metadatos y manifiesto.
• La persistencia se aborda mediante ADO.NET para acceso directo controlado y Entity Framework Core como ORM multiplataforma con unidades de trabajo DbContext y DbSet.
• ASP.NET Core organiza las peticiones mediante una canalización de middleware y patrones de inyección de dependencias con ciclos de vida Singleton, Scoped y Transient.
• La seguridad moderna abandona el antiguo Code Access Security en favor de mecanismos de autenticación, autorización basada en claims y políticas, y protección de datos mediante criptografía.
• La gestión de secretos requiere herramientas específicas como Secret Manager en desarrollo y servicios especializados como Azure Key Vault en producción.

📚 Desarrollo

Arquitectura fundamental. El Common Language Runtime (CLR) constituye el núcleo de la plataforma, proporcionando servicios de gestión automática de memoria mediante recolección de basura generacional, compilación Just-In-Time (JIT) de bytecode a código nativo, y verificación de tipos. En versiones recientes se incorporó Native AOT (Ahead-Of-Time), que permite compilar la aplicación a código nativo durante el build, eliminando la dependencia del JIT y reduciendo tiempos de arranque para escenarios serverless o de microservicios.

Estructura de componentes. Los ensamblados .NET representan las unidades de despliegue básicas, conteniendo código compilado a Common Intermediate Language (CIL), metadatos descriptivos y manifiesto con información de versionado y dependencias. La Base Class Library (BCL) proporciona tipos fundamentales como System o System.IO, mientras que la Framework Class Library (FCL) abarca tecnologías específicas como ASP.NET. La plataforma es multilenguaje gracias al Common Type System (CTS) y la Common Language Specification (CLS).

Patrones de diseño en aplicaciones web. ASP.NET Core organiza el procesamiento de peticiones mediante una canalización de middleware que permite encadenar componentes para autenticación, logging o manejo de errores. La inyección de dependencias integrada gestiona la creación de objetos mediante ciclos de vida definidos: Singleton (instancia única global), Scoped (creada por cada petición HTTP) y Transient (nueva instancia en cada solicitud), facilitando el desacoplamiento y la testabilidad.

Capa de acceso a datos. ADO.NET proporciona acceso directo a bases de datos relacionales mediante un modelo basado en conexiones (DbConnection), comandos (DbCommand), lectores forward-only (DataReader) y contenedores en memoria (DataSet). Sobre esta base opera Entity Framework Core, el ORM principal multiplataforma que soporta SQL Server, PostgreSQL, MySQL, SQLite, Oracle y Cosmos DB, gestionando el seguimiento de cambios, transacciones y migraciones de esquema.

Modelos de persistencia. Entity Framework Core ofrece tres flujos de trabajo: Code-First, donde el modelo se define en código y se generan migraciones automáticas; Database-First, donde se realiza scaffolding del modelo a partir de un esquema existente; y Model-First, hoy en desuso. El DbContext actúa como unidad de trabajo y sesión con la base de datos, mientras que DbSet representa tablas o conjuntos de entidades, permitiendo consultas mediante LINQ que se traducen automáticamente a SQL.

Seguridad moderna y criptografía. La plataforma eliminó el Code Access Security (CAS) por considerarse complejo e ineficaz, delegando permisos en el sistema operativo, contenedores o sandboxes. System.Security.Cryptography ofrece implementaciones de AES para cifrado simétrico, RSA y ECDSA para asimétrica, y SHA para hashing. En Windows, la Data Protection API (DPAPI) cifra datos con claves derivadas de la cuenta de usuario o la máquina.

Autenticación y gestión de secretos. La seguridad actual se centra en ASP.NET Core Identity y mecanismos de autenticación mediante cookies, JWT, OAuth 2.0 u OpenID Connect, junto con autorización basada en roles, claims y políticas. Los secretos nunca deben codificarse en el fuente ni en repositorios, utilizándose el Secret Manager en desarrollo y servicios como Azure Key Vault, AWS Secrets Manager o HashiCorp Vault en producción, accesibles mediante proveedores de configuración.

🧩 Elementos esenciales

• Common Language Runtime (CLR): Máquina virtual que gestiona ejecución, memoria, excepciones y seguridad de tipos mediante recolección de basura y compilación JIT.
• Common Intermediate Language (CIL): Bytecode intermedio al que se compila el código fuente antes de su ejecución por el runtime.
• Native AOT: Compilación Ahead-Of-Time que genera código nativo durante el build, eliminando la necesidad de JIT en runtime.
• Ensamblado: Unidad de despliegue que contiene código CIL, metadatos y manifiesto con información de versión y dependencias.
• Inyección de dependencias: Patrón con ciclos Singleton (instancia única), Scoped (por petición HTTP) y Transient (nueva instancia cada vez).
• ADO.NET: Nivel de acceso directo a bases de datos mediante DbConnection, DbCommand y DataReader sin abstracción ORM.
• Entity Framework Core: ORM multiplataforma donde DbContext es la unidad de trabajo y DbSet representa tablas o entidades.
• LINQ: Lenguaje integrado de consultas que EF Core traduce a SQL para operaciones de filtrado, proyección y agregación.
• Code Access Security (CAS): Mecanismo de seguridad eliminado en .NET Core por considerarse ineficaz frente a amenazas reales.
• Data Protection API: Servicio de cifrado disponible en Windows que utiliza claves ligadas al usuario o la máquina.
• Secret Manager: Herramienta de desarrollo que almacena secretos fuera del repositorio en el perfil del usuario.
• Azure Key Vault: Servicio de producción recomendado para almacenamiento seguro de claves, secretos y certificados.

🧠 Recuerda

• El CLR gestiona automáticamente la memoria mediante recolección de basura generacional sin intervención manual.
• Un ensamblado contiene código compilado a CIL, metadatos descriptivos y manifiesto con información de identidad.
• DbContext nunca debe configurarse como Singleton debido a problemas de concurrencia y estado compartido.
• La denominación correcta actual es .NET, siendo .NET Framework la plataforma histórica principalmente asociada a Windows.
• CAS fue eliminado en .NET Core; la seguridad se delega en el sistema operativo y mecanismos de contenedorización.
• Las contraseñas deben almacenarse exclusivamente con hashing seguro, nunca en texto claro ni con cifrado reversible.
• Los secretos de configuración nunca deben incluirse en repositorios de código ni en archivos versionados.
• ASP.NET Core procesa peticiones mediante middleware encadenado en una canalización configurable.
• Entity Framework Core soporta múltiples proveedores incluyendo SQL Server, PostgreSQL, MySQL, SQLite y Cosmos DB.
• Native AOT reduce el consumo de memoria y tiempo de arranque compilando directamente a código nativo.

3. Características, elementos, lenguajes y funciones en ambos entornos

3. Características, elementos, lenguajes y funciones en ambos entornos

🎯 Idea clave

• Jakarta EE y .NET son entornos empresariales que resuelven necesidades similares mediante filosofías distintas: especificaciones abiertas frente a plataforma integrada.
• Ambos se basan en código gestionado sobre máquinas virtuales con recolección de basura, tipado fuerte y bibliotecas extensas.
• Java es el lenguaje central de Jakarta EE, mientras que C#, F# y Visual Basic son los principales en .NET.
• Las arquitecturas difieren en el despliegue: servidores de aplicaciones con contenedores web y EJB frente a servidor Kestrel integrado en la aplicación.
• La persistencia, inyección de dependencias y seguridad presentan APIs distintas aunque persigan objetivos empresariales equivalentes.
• La elección técnica debe atender a requisitos de portabilidad, ecosistema, inversión previa y necesidades de interoperabilidad mediante protocolos comunes.

📚 Desarrollo

Naturaleza de las plataformas. Jakarta EE se organiza como una familia de especificaciones abiertas implementadas por distintos proveedores mediante servidores compatibles. .NET se estructura como plataforma, runtime, SDK y frameworks mantenidos principalmente por Microsoft. Esta diferencia fundamental condiciona la portabilidad y el gobierno de cada ecosistema.

Ejecución gestionada. Ambos entornos utilizan código gestionado sobre máquinas virtuales: la JVM en Jakarta EE y el runtime .NET en la plataforma Microsoft, históricamente asociado al CLR. Esta arquitectura proporciona gestión automática de memoria, seguridad de tipos, carga de clases y tratamiento de excepciones, distinguiéndose de los binarios nativos sin runtime gestionado.

Lenguajes de programación. Java lidera el desarrollo en Jakarta EE, acompañado de Kotlin, Scala, Groovy y Clojore sobre la JVM. En .NET, C# es el lenguaje principal junto con F#, VB.NET y C++/CLI sobre el CLR, ofreciendo múltiples paradigmas de programación sobre una base común de compilación JIT con opciones modernas de AOT.

Arquitectura de despliegue. Jakarta EE tradicionalmente emplea servidores de aplicaciones con contenedores web y EJB, empaquetando aplicaciones en JAR, WAR y EAR. Por su parte, .NET integra el servidor Kestrel directamente en la aplicación y distribuye soluciones mediante ensamblados, proyectos, publicaciones y paquetes NuGet.

Tecnologías de persistencia. Jakarta Persistence utiliza EntityManager como API central para el mapeo objeto-relacional, implementado mediante Hibernate o EclipseLink. Entity Framework Core en .NET emplea DbContext como elemento central, siendo ambas tecnologías ORM con modelos de programación distintos aunque objetivos similares.

Seguridad e inyección de dependencias. Jakarta EE proporciona CDI para desacoplamiento de componentes y JAAS para seguridad, mientras que .NET utiliza el contenedor Microsoft.Extensions.DependencyInjection y ASP.NET Core Identity con JWT y OAuth/OIDC. Ambos entornos separan claramente las funciones de autenticación y autorización.

Interoperabilidad y elección. La interoperabilidad entre ambos se logra mediante protocolos y formatos comunes, no compartiendo runtime. La decisión técnica debe considerar requisitos específicos, equipo disponible, soporte, seguridad, interoperabilidad y mantenimiento a largo plazo, además de la inversión previa y cultura del organismo.

🧩 Elementos esenciales

• Especificaciones abiertas vs plataforma integrada: Jakarta EE estandariza APIs para múltiples implementaciones; .NET ofrece coherencia entre runtime, SDK y herramientas.
• JVM y CLR: Máquinas virtuales con compilación JIT y opciones AOT modernas como GraalVM Native Image y .NET Native AOT.
• Lenguajes principales: Java en Jakarta EE frente a C#, F# y Visual Basic en .NET.
• Servidores de aplicaciones: GlassFish, WildFly, Payara, Open Liberty, WebLogic y WebSphere implementan Jakarta EE.
• Contenedores vs Kestrel: Jakarta EE usa servidores tradicionales con contenedores web/EJB; .NET integra el servidor dentro de la aplicación.
• Empaquetado diferenciado: JAR, WAR y EAR en Jakarta EE frente a ensamblados y paquetes NuGet en .NET.
• APIs de persistencia: EntityManager en Jakarta Persistence frente a DbContext en Entity Framework Core.
• Inyección de dependencias: CDI en Jakarta EE frente al contenedor integrado de ASP.NET Core y alternativas como Autofac.
• Seguridad: JAAS y Jakarta Security frente a ASP.NET Core Identity, IdentityServer y protocolos OIDC.
• Desarrollo web: Servlet, JSF, JAX-RS y WebSocket frente a ASP.NET Core MVC, Web API, Razor Pages, Blazor y SignalR.
• Estandarización: Jakarta EE bajo Eclipse Foundation; .NET con estándares ECMA para C# y CLR aunque sus APIs superiores no son estándares abiertos equivalentes.

🧠 Recuerda

• Jakarta EE busca portabilidad entre servidores mediante especificaciones abiertas.
• .NET prioriza la integración coherente de herramientas, runtime y frameworks evolucionados conjuntamente.
• Ambos usan código gestionado y recolección de basura sobre máquinas virtuales.
• EntityManager y DbContext son APIs centrales ORM pero no equivalentes directos.
• CDI y el contenedor de ASP.NET Core persiguen desacoplamiento con modelos arquitectónicos distintos.
• Jakarta Servlet no es equivalente al middleware de ASP.NET Core aunque ambos procesan HTTP.
• La interoperabilidad requiere protocolos estándar, no compatibilidad de runtime.
• La elección debe considerar inversión previa, plantilla técnica disponible y cultura organizativa.
• Ambos separan autenticación y autorización como preocupaciones de seguridad distintas.
• La gestión segura de configuración, secretos y dependencias es obligatoria en ambos entornos.

4. Desarrollo de interfaces

4. Desarrollo de interfaces

🎯 Idea clave

• La interfaz de usuario presenta información y captura entradas sin concentrar la lógica de negocio, que debe residir en capas independientes.
• HTML, CSS, JavaScript y HTTP constituyen los fundamentos tecnológicos de las interfaces web independientemente de la plataforma utilizada.
• Jakarta Faces ofrece un framework MVC de componentes específico para el desarrollo de interfaces web de servidor en Jakarta EE.
• ASP.NET Core proporciona múltiples modelos de desarrollo que incluyen MVC tradicional, Razor Pages y Blazor.
• La validación de datos en cliente mejora la experiencia de usuario pero la validación en servidor resulta imprescindible para garantizar la seguridad.
• La elección tecnológica debe considerar requisitos funcionales, accesibilidad, internacionalización, rendimiento y mantenibilidad del sistema.

📚 Desarrollo

Fundamentos web universales. El desarrollo de interfaces empresariales se sustenta sobre tecnologías estándar como HTML, CSS, JavaScript y el protocolo HTTP. Estos elementos constituyen la base sobre la cual se construyen las aplicaciones tanto en Jakarta EE como en .NET, independientemente de los frameworks específicos que cada plataforma proporcione.

Separación de responsabilidades. Una interfaz bien diseñada debe limitarse a presentar información y recoger entradas del usuario, evitando la concentración de la lógica de negocio en la capa de presentación. Este principio arquitectónico facilita el mantenimiento, la evolución y la portabilidad de las aplicaciones empresariales a largo plazo.

Jakarta Faces. En el entorno Jakarta EE, Jakarta Faces constituye un framework MVC orientado a componentes para la construcción de interfaces web de servidor. Gestiona el ciclo de vida de componentes, el estado de la interfaz, eventos de usuario, validación de datos, navegación entre vistas, internacionalización y accesibilidad, proporcionando un modelo declarativo de desarrollo.

Tecnologías de escritorio. JavaFX se orienta específicamente al desarrollo de interfaces gráficas de escritorio en Java, diferenciándose claramente de las tecnologías web de Jakarta EE. Esta distinción resulta relevante cuando se evalúan las opciones para aplicaciones de cliente pesado frente a soluciones basadas en navegador.

ASP.NET Core. La plataforma .NET ofrece a través de ASP.NET Core diversos modelos para el desarrollo de interfaces: el patrón MVC tradicional para aplicaciones estructuradas, las Razor Pages para páginas dinámicas centradas en el servidor, y Blazor para la construcción de interfaces web interactivas mediante componentes reutilizables.

Declaración de interfaces. Razor permite mezclar HTML con código C# para generar contenido dinámico del lado del servidor de forma eficiente. Para aplicaciones de cliente nativas, .NET MAUI y WPF representan tecnologías relevantes, utilizando XAML como lenguaje declarativo para la definición de interfaces gráficas complejas y adaptativas.

Seguridad y validación. La validación de datos en el lado del cliente mejora la experiencia de usuario pero nunca sustituye a la validación obligatoria en el servidor. Asimismo, ocultar controles de interfaz mediante manipulación del Document Object Model no constituye un mecanismo de autorización válido frente a la protección de recursos en el servidor.

Factores transversales. El desarrollo profesional de interfaces debe incorporar necesariamente la accesibilidad para usuarios con diversidad funcional, la internacionalización para soportar múltiples idiomas y culturas, el rendimiento optimizado en tiempo de respuesta, y la capacidad de prueba automatizada de los componentes visuales.

🧩 Elementos esenciales

• Jakarta Faces: framework MVC de componentes para interfaces web de servidor en Jakarta EE que gestiona estado, eventos, validación, navegación, internacionalización y accesibilidad.
• JavaFX: tecnología orientada exclusivamente a interfaces gráficas de escritorio en Java, no aplicable a aplicaciones web Jakarta EE.
• ASP.NET Core: proporciona tres modelos principales de desarrollo de interfaces: MVC, Razor Pages y Blazor para diferentes arquitecturas y necesidades.
• Razor: sintaxis de plantillas que permite mezclar HTML con código C# para generar contenido dinámico del lado del servidor.
• Blazor: framework para construir interfaces web interactivas mediante componentes reutilizables basados en Razor y ejecutables en navegador.
• XAML: lenguaje declarativo utilizado en diversas tecnologías .NET para definir interfaces gráficas de cliente de forma estructurada.
• .NET MAUI: tecnología multiplataforma para el desarrollo de interfaces de aplicaciones de cliente nativas en el ecosistema .NET.
• WPF: framework específico de Windows para interfaces de escritorio con capacidades gráficas vectoriales avanzadas.
• Validación cliente: mejora la experiencia de usuario inmediata pero resulta insuficiente sin validación servidor que garantice integridad y seguridad.
• Autorización: debe implementarse siempre en el servidor, ya que ocultar controles en la interfaz mediante estilos no constituye protección de recursos.
• Accesibilidad: requisito fundamental del desarrollo profesional de interfaces para garantizar el acceso universal a los sistemas.
• Internacionalización: capacidad de adaptar la interfaz a diferentes idiomas, culturas y convenciones regionales sin modificar el código fuente.

🧠 Recuerda

• La interfaz presenta datos y capta entradas, pero la lógica de negocio debe residir en capas independientes de la presentación.
• HTML, CSS, JavaScript y HTTP son fundamentos válidos y necesarios para ambas plataformas empresariales.
• Jakarta Faces utiliza un modelo de componentes con estado para aplicaciones web de servidor en Jakarta EE.
• ASP.NET Core ofrece MVC tradicional, Razor Pages y Blazor como opciones de desarrollo de interfaces web.
• JavaFX está reservado para aplicaciones de escritorio, no para entornos web corporativos Jakarta EE.
• Razor permite la generación dinámica de HTML mediante integración fluida con código C# del servidor.
• Blazor habilita la creación de componentes web reutilizables e interactivos ejecutables en el navegador del cliente.
• XAML es el estándar declarativo para interfaces de cliente en el ecosistema .NET, incluyendo WPF y MAUI.
• La validación en servidor es imprescindible independientemente de la validación cliente implementada en navegador.
• La accesibilidad, la internacionalización y el rendimiento son requisitos no negociables en el desarrollo profesional de interfaces.