https://cesguiro.es/ 2026-10-22T16:25:02+00:00 https://cesguiro.es/ https://cesguiro.es/ttps://cesguiro.es/lib/tpl/bootstrap3/images/favicon.ico text/html 2026-10-21T10:21:52+00:00 Anonymous (anonymous@undisclosed.example.com) https://cesguiro.es/doku.php/clase/daw/dws/1eval/api_first?rev=1792570912&do=diff 02 - API First La API es el contrato entre una aplicación y quienes la consumen. Define operaciones, datos de entrada y salida y respuestas posibles. Este tema se centra en el contrato HTTP; la misma idea de contrato explícito aplica a la comunicación entre módulos internos, que se desarrolla en el tema 04. text/html 2026-10-03T10:20:23+00:00 Anonymous (anonymous@undisclosed.example.com) https://cesguiro.es/doku.php/clase/daw/dws/1eval/arquitecturas?rev=1791015623&do=diff 01 - Arquitecturas de software Una aplicación puede clasificarse según distintos criterios. Por ejemplo, puede desplegarse como monolito modular y organizarse internamente por capas con inversión de dependencias. 1. Principios de arquitectura limpia text/html 2026-10-21T11:45:30+00:00 Anonymous (anonymous@undisclosed.example.com) https://cesguiro.es/doku.php/clase/daw/dws/1eval/concurrencia?rev=1792575930&do=diff 11 - Concurrencia: bloqueante, reactiva y Loom Los temas anteriores han convivido con la concurrencia sin explicarla: Tomcat reparte las peticiones entre un pool de hilos y el MDC (tema 09) aprovecha que cada petición vive en un hilo; el procesamiento asíncrono de eventos (tema 08) salta a otro hilo. Este tema explica qué sostiene esa concurrencia y los tres modelos disponibles hoy: el tradicional con hilos de plataforma, la programación reactiva y los hilos virtuales de text/html 2026-10-21T10:27:21+00:00 Anonymous (anonymous@undisclosed.example.com) https://cesguiro.es/doku.php/clase/daw/dws/1eval/eventos?rev=1792571241&do=diff 08 - Eventos de aplicación y mensajería La llamada a la API pública de otro módulo es comunicación síncrona: quien llama necesita el resultado para continuar. Los eventos de aplicación permiten la comunicación inversa: un módulo anuncia que algo ha ocurrido y otros módulos reaccionan, sin que el emisor los conozca. text/html 2026-10-21T10:25:11+00:00 Anonymous (anonymous@undisclosed.example.com) https://cesguiro.es/doku.php/clase/daw/dws/1eval/jpa?rev=1792571111&do=diff 05 - Persistencia: Spring JPA En 1.º DAW la persistencia se implementó con JDBC: SQL explícito, PreparedStatement y mapeo manual de ResultSet a modelo. JPA (*Java Persistence API*) sustituye esa capa por un mapeo objeto-relacional gestionado: las entidades se declaran con anotaciones y el proveedor genera el SQL. text/html 2026-10-21T10:35:22+00:00 Anonymous (anonymous@undisclosed.example.com) https://cesguiro.es/doku.php/clase/daw/dws/1eval/jwt?rev=1792571722&do=diff 06 - Login con JWT El login con JWT mantiene la idea del par de tokens: un token de acceso de vida corta y un refresh token de vida larga. La diferencia está en el token de acceso: es autocontenido y verificable sin conservar estado en el servidor. text/html 2026-10-21T11:35:47+00:00 Anonymous (anonymous@undisclosed.example.com) https://cesguiro.es/doku.php/clase/daw/dws/1eval/lambda?rev=1792575347&do=diff 10 - Serverless: Lambdas en local El monolito modular con un único despliegue cubre el flujo principal de la aplicación, pero no toda la relación con el exterior. Los proveedores de nube ofrecen FaaS (*Function as a Service*): funciones pequeñas, sin servidor que administrar, activadas por eventos y facturadas por ejecución. En text/html 2026-10-21T11:35:32+00:00 Anonymous (anonymous@undisclosed.example.com) https://cesguiro.es/doku.php/clase/daw/dws/1eval/logs?rev=1792575332&do=diff 09 - Logs e instrumentación En 1.º DAW ya se usa el sistema de logs de Spring Boot: el evento de log con su nivel, la fachada SLF4J, la implementación Logback de serie y el nivel por paquete en application.properties. Esas bases bastaban con la aplicación en el equipo local: la consola lo mostraba todo y cada fallo se reproducía a mano. Una vez desplegada, la misma aplicación corre en un servidor o contenedor donde la consola es efímera, el acceso es remoto y las peticiones se solapan: el regis… text/html 2026-10-21T10:24:10+00:00 Anonymous (anonymous@undisclosed.example.com) https://cesguiro.es/doku.php/clase/daw/dws/1eval/modulith?rev=1792571050&do=diff 04 - Monolito modular: módulos y Spring Modulith En un monolito modular, cada módulo protege su interior y expone un contrato. Este tema define qué vive dentro de un módulo, cómo ofrece su API pública, cómo la consume otro módulo y cómo se verifica que se respetan los límites. Los conceptos son independientes del framework; text/html 2026-10-21T10:27:03+00:00 Anonymous (anonymous@undisclosed.example.com) https://cesguiro.es/doku.php/clase/daw/dws/1eval/spring_security?rev=1792571223&do=diff 07 - Integración con Spring Security En 1.º DAW el login con tokens se implementó con un filtro Servlet propio: extraer el token, autenticar, dejar el Principal en el contexto de la petición y comprobar los roles. Spring Security ofrece esa infraestructura hecha: una cadena de filtros, gestión del contexto de seguridad y reglas de autorización declarativas. El flujo de autenticación no cambia; lo que cambia es quién construye y orquesta la maquinaria. text/html 2025-01-02T10:57:18+00:00 Anonymous (anonymous@undisclosed.example.com) https://cesguiro.es/doku.php/clase/daw/dws/1eval/start?rev=1735811838&do=diff 1º Evaluación 1eval index text/html 2026-10-21T10:22:26+00:00 Anonymous (anonymous@undisclosed.example.com) https://cesguiro.es/doku.php/clase/daw/dws/1eval/validacion?rev=1792570946&do=diff 03 - Validación e invariancias Una petición puede rechazarse por dos motivos distintos: incumple el formato del contrato o propone un estado inválido para el negocio. Son preguntas diferentes, que se responden en lugares diferentes y con mecanismos diferentes. Mezclarlas produce los errores clásicos: reglas de negocio escritas en el