From 65eb08213455fba2dd6b445694f0c7f8df21980d Mon Sep 17 00:00:00 2001 From: Tatiana Date: Wed, 13 May 2026 17:40:32 +0200 Subject: [PATCH 1/5] Actualizacion del temario --- src/main/resources/temas/bloque3/B3T3.md | 25 +++++++++++-------- .../resources/templates/admin/usuarios.html | 8 +++--- 2 files changed, 19 insertions(+), 14 deletions(-) diff --git a/src/main/resources/temas/bloque3/B3T3.md b/src/main/resources/temas/bloque3/B3T3.md index 6c6c1de..0aaeb96 100644 --- a/src/main/resources/temas/bloque3/B3T3.md +++ b/src/main/resources/temas/bloque3/B3T3.md @@ -9,18 +9,21 @@ → Lenguaje estándar para interactuar con bases de datos relacionales. **Sublenguajes de SQL** -- DDL – Definición (CREATE, ALTER, DROP) -- DML – Manipulación (SELECT, INSERT, UPDATE, DELETE) -- DCL – Control (GRANT, REVOKE) -- TCL – Transacciones (COMMIT, ROLLBACK, SAVEPOINT) +| Nombre | Tipo | COMANDOS | DESCRIPCIÓN | +| :--- | :--- | :--- | :--- | +| **DDL** | Definición | CREATE
ALTER
DROP | Permite crear y modificar la estructura de la base de datos | +| **DML** | Manipulación | SELECT
INSERT
UPDATE
DELETE | Permite gestionar los datos contenidos en las tablas | +| **DCL** | Control | GRANT
REVOKE | Controla el acceso y permisos de los usuarios | +| **TCL** | Transacciones | COMMIT
ROLLBACK
SAVEPOINT | Gestiona los cambios realizados por las sentencias DML | -**Objetos avanzados** -- Vistas (VIEW) -- Índices (INDEX) -- Procedimientos almacenados -- Funciones de usuario -- Disparadores (TRIGGER) -- Eventos +| Objeto | Definición Breve | Se ejecuta cuando... | +| :--- | :--- | :--- | +| **VIEW** | Tabla virtual | Se consulta (`SELECT`) | +| **INDEX** | Optimizador de búsqueda | Se busca o filtra información | +| **PROCEDURE** | Bloque de código reutilizable | Se llama explícitamente (`CALL`) | +| **FUNCTION** | Cálculo que devuelve un valor | Se usa en una expresión o `SELECT` | +| **TRIGGER** | Reacción automática | Se modifica una tabla
(`INSERT`, `UPDATE`, `DELETE`) | +| **EVENT** | Tarea programada | Llega una fecha o
intervalo de tiempo | --- diff --git a/src/main/resources/templates/admin/usuarios.html b/src/main/resources/templates/admin/usuarios.html index a2a0046..2104f7e 100644 --- a/src/main/resources/templates/admin/usuarios.html +++ b/src/main/resources/templates/admin/usuarios.html @@ -15,9 +15,11 @@ ADMIN From f0c307b82faa868ca95138a72ca63a4c93a401e1 Mon Sep 17 00:00:00 2001 From: Tatiana Villa Date: Thu, 14 May 2026 10:45:12 +0200 Subject: [PATCH 2/5] Audios --- scripts/sync_audios.sh | 3 ++- src/main/resources/application.properties | 6 ++++++ 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/scripts/sync_audios.sh b/scripts/sync_audios.sh index 9138102..791517d 100755 --- a/scripts/sync_audios.sh +++ b/scripts/sync_audios.sh @@ -15,7 +15,8 @@ set -euo pipefail SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" PROJECT_DIR="$(dirname "$SCRIPT_DIR")" -PYTHON="${PYTHON:-python3}" +PYTHON="/home/tatiana/desarrollo/html/taiage-spring/.venv/bin/python3" +#PYTHON="${PYTHON:-python3}" LOG_PREFIX="[$(date '+%Y-%m-%d %H:%M:%S')]" echo "$LOG_PREFIX ── sync_audios.sh iniciado ──────────────────────────" diff --git a/src/main/resources/application.properties b/src/main/resources/application.properties index 710b87a..0fe4040 100644 --- a/src/main/resources/application.properties +++ b/src/main/resources/application.properties @@ -15,6 +15,12 @@ spring.jpa.open-in-view=false # ── Thymeleaf ─────────────────────────────────────────────────── spring.thymeleaf.cache=false +# ── Recursos estáticos ────────────────────────────────────────── +# Los audios se generan en el filesystem (no van en el JAR), se sirven desde ahí. +# La ruta "file:src/main/resources/static/" permite que el cron actualice mp3 sin +# necesidad de recompilar. "classpath:/static/" mantiene el resto de estáticos (css, js…) +spring.web.resources.static-locations=file:src/main/resources/static/,classpath:/static/ + # ── Stripe ────────────────────────────────────────────────────── stripe.secret-key=${STRIPE_SECRET_KEY} stripe.webhook-secret=${STRIPE_WEBHOOK_SECRET} From d388724d3072b7945fb710da5fc3d91c5ce3a034 Mon Sep 17 00:00:00 2001 From: Tatiana Villa Date: Thu, 14 May 2026 12:05:17 +0200 Subject: [PATCH 3/5] Actualizacion de temario y audios --- src/main/resources/temas/bloque3/B3T4.md | 519 ++++++++++++++++- src/main/resources/temas/bloque3/B3T5.md | 521 +++++++++++------- .../resources/temas/bloque3/B3T5_audio.md | 132 ++++- src/main/resources/temas/bloque3/B3T6.md | 455 ++++++++------- .../resources/temas/bloque3/B3T6_audio.md | 158 ++++++ src/main/resources/temas/bloque3/B3T7.md | 4 + 6 files changed, 1353 insertions(+), 436 deletions(-) diff --git a/src/main/resources/temas/bloque3/B3T4.md b/src/main/resources/temas/bloque3/B3T4.md index 9fe4c27..ac78bb2 100644 --- a/src/main/resources/temas/bloque3/B3T4.md +++ b/src/main/resources/temas/bloque3/B3T4.md @@ -1,28 +1,497 @@ +# Bloque 3 · Tema 4 # Diseño y programación orientada a objetos. Elementos y componentes software: objetos, clases, herencia, métodos, sobrecarga. Ventajas e inconvenientes. Patrones de diseño y lenguaje de modelado unificado (UML). -## POO --Herencia --Polimorfismo --Acoplamiento +--- -## Patrones -- MVC -- GRASP - - Controller - - Low Coupling (bajo acoplamiento) - - High Cohesion (Alta cohesión) - - Polymorphism (Polimorfismo) - -## UML (Lenguaje de modelado unificado) -- Diagrama de clase -- Diagrama de objetos (instancia de una clase) -- Diagrama de componentes (servicio web, ejecutable, libreria, etc) -- Diagrama de paquetes -- Diagrama de despliegue - - Nodos - - Artefactos (librerias, bases de datos) - - Conexiones -- Diagrama de casos de uso -- Diagrama de actividades -- Diagrama de comunicación -- Diagrama de Gantt +# Esquema resumen + +**POO — Pilares fundamentales** +- Abstracción +- Encapsulación +- Herencia +- Polimorfismo + +**Elementos principales** + +| Elemento | Descripción | +|---|---| +| Clase | Plantilla / molde | +| Objeto | Instancia de una clase | +| Atributo | Variable de una clase | +| Método | Función de una clase | +| Constructor | Inicializa el objeto al crearlo | +| Interfaz | Contrato sin implementación | +| Clase abstracta | No instanciable; puede tener métodos sin implementar | + +**Relaciones entre clases** + +| Relación | Tipo | Ejemplo | +|---|---|---| +| Herencia | Es-un | `Perro` es un `Animal` | +| Composición | Tiene-un (fuerte) | `Motor` forma parte de `Coche` | +| Agregación | Tiene-un (débil) | `Alumno` pertenece a `Clase` | +| Dependencia | Usa-un | `Pedido` usa `Producto` | + +**Patrones de diseño (GoF)** + +- Creacionales: Singleton, Factory Method, Abstract Factory, Builder, Prototype +- Estructurales: Adapter, Facade, Decorator, Composite, Proxy +- De comportamiento: Observer, Strategy, Template Method, Iterator, Command + +**GRASP** — Patrones de asignación de responsabilidades: +Controller, Creator, Information Expert, Low Coupling, High Cohesion, Polymorphism, Indirection, Pure Fabrication, Protected Variations + +**UML — Diagramas estructurales** +Clases, Objetos, Componentes, Paquetes, Despliegue, Compuesto + +**UML — Diagramas de comportamiento** +Casos de uso, Actividades, Estados, Secuencia, Comunicación + +--- + +# 1. Programación orientada a objetos + +## 1.1 Concepto y origen + +La **programación orientada a objetos (POO)** es un paradigma de programación que organiza el software en torno a **objetos**, que combinan datos (atributos) y comportamiento (métodos). + +Surgió en los años 60 con **Simula 67** y se popularizó con **Smalltalk** en los 70. Hoy es el paradigma dominante, presente en Java, Python, C++, C#, Ruby, etc. + +--- + +## 1.2 Pilares de la POO + +### Abstracción + +Consiste en representar solo las características esenciales de un objeto, ocultando los detalles internos no relevantes. + +Ejemplo: al modelar un `Coche` para una app de parking, nos interesa la matrícula, la marca y el color; no el número de cilindros. + +--- + +### Encapsulación + +Agrupa los datos y los métodos que los manejan dentro de una misma clase, y restringe el acceso directo desde el exterior. + +Se implementa mediante **modificadores de acceso**: + +| Modificador | Acceso | +|---|---| +| `public` | Desde cualquier clase | +| `protected` | Desde la misma clase y sus subclases | +| `private` | Solo desde la propia clase | +| (sin modificador) | Solo desde el mismo paquete (Java) | + +Los atributos suelen ser `private` y se exponen con métodos `getX()` / `setX()` (getters y setters). + +--- + +### Herencia + +Permite que una clase (**subclase** o clase hija) adquiera los atributos y métodos de otra clase (**superclase** o clase padre). + +- Favorece la **reutilización de código**. +- Modela la relación **"es-un"**: un `Perro` es un `Animal`. +- En Java la herencia es **simple** (solo un padre directo). En C++ es **múltiple**. + +**Sobreescritura (override)**: la subclase redefine un método heredado para adaptar su comportamiento. + +```java +class Animal { + public String sonido() { return "..."; } +} +class Perro extends Animal { + @Override + public String sonido() { return "Guau"; } +} +``` + +--- + +### Polimorfismo + +Capacidad de un mismo método o referencia de comportarse de distinta forma según el tipo real del objeto. + +Tipos: + +| Tipo | Mecanismo | Cuándo se resuelve | +|---|---|---| +| **Polimorfismo de subtipos** | Herencia + sobreescritura | En tiempo de ejecución (dinámico) | +| **Sobrecarga (overloading)** | Mismo nombre, distintos parámetros | En tiempo de compilación (estático) | + +**Sobrecarga**: varios métodos con el mismo nombre pero diferente firma (número o tipo de parámetros). + +```java +class Calculadora { + int sumar(int a, int b) { return a + b; } + double sumar(double a, double b){ return a + b; } + int sumar(int a, int b, int c) { return a + b + c; } +} +``` + +--- + +## 1.3 Elementos de una clase + +| Elemento | Descripción | +|---|---| +| **Atributo (campo)** | Variable que almacena el estado del objeto | +| **Método** | Función que define el comportamiento | +| **Constructor** | Método especial que se ejecuta al crear el objeto (`new`) | +| **Destructor** | Libera recursos al destruirse el objeto (en Java: `finalize`; en C++: `~Clase()`) | +| **Método estático** | Pertenece a la clase, no a instancias concretas | +| **Atributo estático** | Valor compartido por todas las instancias | + +--- + +## 1.4 Clases abstractas e interfaces + +**Clase abstracta**: +- No puede instanciarse directamente. +- Puede tener métodos con y sin implementación (abstractos). +- Una subclase debe implementar todos los métodos abstractos. +- En Java: `abstract class Animal { abstract void sonido(); }` + +**Interfaz**: +- Define un **contrato**: lista de métodos que una clase debe implementar. +- No tiene atributos de instancia (solo constantes). +- Una clase puede implementar **varias interfaces** (solución a la falta de herencia múltiple). +- En Java: `interface Volador { void volar(); }` + +| | Clase abstracta | Interfaz | +|---|---|---| +| Instanciable | No | No | +| Herencia | Simple | Múltiple | +| Implementación de métodos | Puede tenerla | Solo desde Java 8 (`default`) | +| Atributos de instancia | Sí | No | + +--- + +## 1.5 Relaciones entre clases + +| Relación | Descripción | Símbolo UML | +|---|---|---| +| **Herencia** (generalización) | La subclase extiende la superclase | Flecha con triángulo hueco | +| **Realización** | Una clase implementa una interfaz | Flecha punteada con triángulo hueco | +| **Composición** | El objeto hijo no puede existir sin el padre | Rombo relleno | +| **Agregación** | El objeto hijo puede existir sin el padre | Rombo hueco | +| **Asociación** | Relación genérica entre clases | Línea | +| **Dependencia** | Una clase usa temporalmente otra | Flecha punteada | + +--- + +## 1.6 Acoplamiento y cohesión + +**Acoplamiento**: grado de dependencia entre clases. +- **Bajo acoplamiento** → deseable: cambios en una clase afectan poco a otras. + +**Cohesión**: grado en que los elementos de una clase están relacionados entre sí. +- **Alta cohesión** → deseable: cada clase tiene una responsabilidad clara y bien definida. + +> Regla de oro: **alta cohesión + bajo acoplamiento**. + +--- + +## 1.7 Ventajas e inconvenientes de la POO + +**Ventajas:** +- Reutilización de código (herencia, composición). +- Modularidad y mantenimiento más sencillo. +- Modelado más natural del mundo real. +- Facilita el trabajo en equipo. +- Encapsulación protege la integridad de los datos. + +**Inconvenientes:** +- Mayor complejidad inicial frente a la programación estructurada. +- Peor rendimiento en sistemas de bajo nivel (overhead de objetos). +- Diseño incorrecto puede llevar a jerarquías de herencia rígidas. +- Curva de aprendizaje más pronunciada. + +--- + +### Miniresumen + +La POO se basa en **abstracción, encapsulación, herencia y polimorfismo**. Sus elementos clave son **clases, objetos, atributos y métodos**. Favorece la reutilización y el mantenimiento, a cambio de mayor complejidad inicial. + +--- + +# 2. Patrones de diseño + +## 2.1 Qué es un patrón de diseño + +Un **patrón de diseño** es una solución reutilizable a un problema recurrente en el diseño de software. No es código concreto, sino una **plantilla conceptual** que describe cómo resolver una situación. + +El catálogo más conocido es el del libro **"Design Patterns: Elements of Reusable Object-Oriented Software"** (1994), de los llamados **Gang of Four (GoF)**: Gamma, Helm, Johnson y Vlissides. + +--- + +## 2.2 Clasificación GoF + +Los 23 patrones GoF se dividen en tres categorías: + +### Patrones creacionales +Gestionan el proceso de **creación de objetos**. + +| Patrón | Descripción | +|---|---| +| **Singleton** | Garantiza que solo exista **una instancia** de una clase | +| **Factory Method** | Define una interfaz para crear objetos; las subclases deciden qué clase instanciar | +| **Abstract Factory** | Crea familias de objetos relacionados sin especificar sus clases concretas | +| **Builder** | Construye objetos complejos paso a paso | +| **Prototype** | Crea nuevos objetos **clonando** uno existente | + +--- + +### Patrones estructurales +Definen cómo se **componen** clases y objetos. + +| Patrón | Descripción | +|---|---| +| **Adapter** | Convierte la interfaz de una clase en otra que el cliente espera | +| **Facade** | Proporciona una interfaz simplificada a un subsistema complejo | +| **Decorator** | Añade responsabilidades a un objeto dinámicamente | +| **Composite** | Trata objetos individuales y composiciones de objetos de forma uniforme | +| **Proxy** | Proporciona un sustituto o representante de otro objeto | +| **Bridge** | Desacopla una abstracción de su implementación | +| **Flyweight** | Comparte objetos para soportar grandes cantidades de objetos de grano fino | + +--- + +### Patrones de comportamiento +Gestionan la **comunicación** entre objetos. + +| Patrón | Descripción | +|---|---| +| **Observer** | Un objeto notifica automáticamente a sus dependientes cuando cambia de estado | +| **Strategy** | Define una familia de algoritmos intercambiables en tiempo de ejecución | +| **Template Method** | Define el esqueleto de un algoritmo; las subclases rellenan los pasos | +| **Iterator** | Accede secuencialmente a los elementos de una colección sin exponer su estructura | +| **Command** | Encapsula una acción como objeto, permitiendo deshacer/rehacer | +| **Chain of Responsibility** | Pasa una petición a través de una cadena de objetos hasta que uno la procesa | +| **State** | El comportamiento de un objeto cambia según su estado interno | +| **Mediator** | Centraliza la comunicación entre objetos para reducir dependencias | + +--- + +## 2.3 Patrón MVC + +**Model-View-Controller** es un patrón arquitectónico que separa la aplicación en tres capas: + +| Capa | Responsabilidad | Ejemplo | +|---|---|---| +| **Model** | Datos y lógica de negocio | Entidades, acceso a BD | +| **View** | Presentación al usuario | HTML, plantillas Thymeleaf | +| **Controller** | Recibe peticiones y coordina Model y View | Controladores REST/web | + +Ventajas: separación de responsabilidades, facilita el testing, permite cambiar la vista sin tocar el modelo. + +--- + +## 2.4 Patrones GRASP + +**General Responsibility Assignment Software Patterns** — definen cómo asignar responsabilidades a clases y objetos. + +| Patrón | Principio | +|---|---| +| **Information Expert** | Asigna la responsabilidad a la clase que tiene la información necesaria | +| **Creator** | Asigna la creación de objetos a la clase que los agrega, contiene o usa | +| **Controller** | Asigna el manejo de eventos del sistema a una clase controladora | +| **Low Coupling** | Minimiza las dependencias entre clases | +| **High Cohesion** | Cada clase tiene una responsabilidad bien definida | +| **Polymorphism** | Usa polimorfismo para manejar comportamientos alternativos | +| **Pure Fabrication** | Crea clases artificiales para mantener alta cohesión y bajo acoplamiento | +| **Indirection** | Introduce un intermediario para reducir el acoplamiento directo | +| **Protected Variations** | Protege los elementos de las variaciones en otros, usando interfaces estables | + +--- + +## 2.5 Principios SOLID + +Aunque no son patrones, suelen examinarse junto a ellos: + +| Letra | Principio | Descripción | +|---|---|---| +| **S** | Single Responsibility | Una clase, una única responsabilidad | +| **O** | Open/Closed | Abierto a extensión, cerrado a modificación | +| **L** | Liskov Substitution | Las subclases deben poder sustituir a sus superclases | +| **I** | Interface Segregation | Mejor varias interfaces específicas que una general | +| **D** | Dependency Inversion | Depender de abstracciones, no de implementaciones concretas | + +--- + +### Miniresumen + +Los patrones GoF se dividen en **creacionales** (cómo crear), **estructurales** (cómo componer) y **de comportamiento** (cómo comunicar). Los más importantes en el examen son: **Singleton, Factory, Adapter, Facade, Observer y Strategy**. MVC es el patrón arquitectónico más usado en aplicaciones web. + +--- + +# 3. UML — Lenguaje de Modelado Unificado + +## 3.1 Qué es UML + +**UML (Unified Modeling Language)** es un lenguaje estándar de modelado visual para describir, especificar, diseñar y documentar sistemas software. + +- Desarrollado en los 90 por Booch, Rumbaugh y Jacobson en Rational Software. +- Estandarizado por el **OMG (Object Management Group)** en 1997. +- Versión actual: **UML 2.x**. +- No es un lenguaje de programación: es un **lenguaje de modelado**. + +--- + +## 3.2 Clasificación de diagramas UML + +UML 2 define **14 tipos de diagramas**, divididos en dos grandes grupos: + +### Diagramas estructurales (qué ES el sistema) + +| Diagrama | Descripción | +|---|---| +| **Clases** | Muestra clases, atributos, métodos y relaciones | +| **Objetos** | Instancias concretas de clases en un momento dado | +| **Componentes** | Módulos software (ejecutables, librerías, servicios web) y sus interfaces | +| **Paquetes** | Agrupación lógica de elementos del modelo | +| **Despliegue** | Infraestructura física: nodos, artefactos y conexiones | +| **Estructura compuesta** | Colaboración interna de una clase o componente | +| **Perfil** | Extensión del metamodelo UML para dominios específicos | + +--- + +### Diagramas de comportamiento (qué HACE el sistema) + +| Diagrama | Descripción | +|---|---| +| **Casos de uso** | Funcionalidades del sistema desde el punto de vista del usuario (actores) | +| **Actividades** | Flujo de trabajo o proceso; similar a un diagrama de flujo | +| **Máquina de estados** | Estados de un objeto y transiciones entre ellos | +| **Secuencia** | Interacción entre objetos ordenada en el tiempo (eje vertical) | +| **Comunicación** | Interacción entre objetos con énfasis en los enlaces (sin eje temporal) | +| **Tiempos** | Comportamiento en función del tiempo; usado en sistemas en tiempo real | +| **Resumen de interacción** | Combinación de diagramas de actividades y de interacción | + +--- + +## 3.3 Diagrama de clases (el más importante) + +### Representación de una clase + +``` +┌─────────────────────┐ +│ Empleado │ ← Nombre de la clase +├─────────────────────┤ +│ - id: int │ ← Atributos (visibilidad nombre: tipo) +│ - nombre: String │ +│ # salario: double │ +├─────────────────────┤ +│ + getNombre(): String│ ← Métodos (visibilidad nombre(): tipo_retorno) +│ + calcularNomina() │ +└─────────────────────┘ +``` + +Visibilidad: `+` público, `-` privado, `#` protegido, `~` paquete. + +### Relaciones en el diagrama de clases + +| Relación | Representación | +|---|---| +| Herencia (generalización) | Línea continua + triángulo hueco en el padre | +| Realización (interfaz) | Línea punteada + triángulo hueco | +| Asociación | Línea continua (con multiplicidad) | +| Composición | Línea + rombo **relleno** en el todo | +| Agregación | Línea + rombo **hueco** en el todo | +| Dependencia | Línea punteada + flecha abierta | + +### Multiplicidad + +| Notación | Significado | +|---|---| +| `1` | Exactamente uno | +| `0..1` | Cero o uno (opcional) | +| `*` o `0..*` | Cero o muchos | +| `1..*` | Uno o muchos | +| `2..5` | Entre dos y cinco | + +--- + +## 3.4 Diagrama de casos de uso + +Muestra **qué puede hacer** el sistema desde el punto de vista del usuario. + +Elementos: +- **Actor**: entidad externa que interactúa con el sistema (persona, otro sistema). Se representa como un muñeco. +- **Caso de uso**: funcionalidad ofrecida. Se representa como una elipse. +- **Sistema**: rectángulo que enmarca los casos de uso. + +Relaciones entre casos de uso: +- `«include»`: un caso de uso incluye obligatoriamente otro. +- `«extend»`: un caso de uso puede extender opcionalmente otro. +- Generalización: un actor o caso de uso hereda de otro. + +--- + +## 3.5 Diagrama de secuencia + +Muestra la **interacción entre objetos** ordenada temporalmente (de arriba a abajo). + +Elementos: +- **Línea de vida** (lifeline): línea vertical punteada que representa un objeto. +- **Activación**: rectángulo sobre la línea de vida que indica cuándo está activo. +- **Mensaje**: flecha horizontal entre líneas de vida. + - Síncrono: flecha rellena (espera respuesta). + - Asíncrono: flecha abierta (no espera). + - Respuesta: flecha punteada. + +--- + +## 3.6 Diagrama de despliegue + +Muestra la **arquitectura física** del sistema. + +| Elemento | Descripción | +|---|---| +| **Nodo** | Recurso físico o virtual (servidor, dispositivo, VM) — cubo 3D | +| **Artefacto** | Elemento software desplegado (JAR, WAR, script, BD) | +| **Asociación** | Canal de comunicación entre nodos | + +--- + +## 3.7 Diagrama de actividades + +Similar a un diagrama de flujo; modela el **flujo de trabajo** de un proceso o algoritmo. + +Elementos: +- Nodo inicial (círculo relleno). +- Actividad (rectángulo redondeado). +- Decisión / bifurcación (rombo). +- Barra de sincronización (barra gruesa horizontal) para concurrencia (fork/join). +- Nodo final (círculo relleno dentro de otro círculo). +- **Carriles (swimlanes)**: dividen las actividades por responsable o sistema. + +--- + +### Miniresumen + +UML define **14 tipos de diagramas** agrupados en estructurales (qué es) y de comportamiento (qué hace). Los más relevantes para el examen TAI son: + +| Diagrama | Para qué se usa | +|---|---| +| **Clases** | Diseño lógico del sistema | +| **Casos de uso** | Requisitos desde el punto de vista del usuario | +| **Secuencia** | Interacción entre objetos en el tiempo | +| **Despliegue** | Arquitectura física e infraestructura | +| **Actividades** | Flujos de trabajo y procesos | + +--- + +# Miniresumen final del tema + +| Punto | Idea clave | +|---|---| +| **POO** | Paradigma basado en objetos; pilares: abstracción, encapsulación, herencia, polimorfismo | +| **Elementos** | Clase (molde), objeto (instancia), atributo (dato), método (comportamiento) | +| **Herencia/Sobrecarga** | Herencia: reutilización jerárquica. Sobrecarga: mismo nombre, distintos parámetros | +| **Ventajas POO** | Reutilización, modularidad, modelado natural. Inconveniente: mayor complejidad | +| **Patrones GoF** | Creacionales (Singleton, Factory), estructurales (Adapter, Facade), comportamiento (Observer, Strategy) | +| **GRASP** | Patrones de asignación de responsabilidades: Low Coupling, High Cohesion, Controller… | +| **MVC** | Patrón arquitectónico: Model (datos), View (presentación), Controller (coordinación) | +| **SOLID** | 5 principios de diseño: S, O, L, I, D | +| **UML** | 14 diagramas; más importantes: Clases, Casos de uso, Secuencia, Despliegue, Actividades | diff --git a/src/main/resources/temas/bloque3/B3T5.md b/src/main/resources/temas/bloque3/B3T5.md index a0f9c07..08c4ddc 100644 --- a/src/main/resources/temas/bloque3/B3T5.md +++ b/src/main/resources/temas/bloque3/B3T5.md @@ -1,358 +1,455 @@ -# Arquitectura Java EE/Jakarta EE y plataforma .NET -## Componentes, persistencia y seguridad. Características, lenguajes y desarrollo de interfaces +# Bloque 3 · Tema 5 +# Arquitectura Java EE/Jakarta EE y plataforma .NET. Componentes, persistencia y seguridad. Características, lenguajes y desarrollo de interfaces. --- -# 1. Esquema general del tema +# Esquema resumen -- Arquitectura Java EE / Jakarta EE - - Servidor de aplicaciones - - APIs principales - - Persistencia (JDBC, ORM, JPA) - - Seguridad +**Java EE / Jakarta EE — APIs principales** -- Plataforma .NET - - Componentes - - Persistencia - - Seguridad +| API | Función | +|---|---| +| **Servlet** | Gestión de peticiones HTTP | +| **JSP** | Páginas HTML con Java incrustado | +| **EJB** | Componentes de lógica de negocio | +| **JSF** | Framework de interfaces web por componentes | +| **JPA** | Persistencia estándar (ORM) | +| **JTA** | Transacciones distribuidas (ACID) | +| **CDI** | Inyección de dependencias | -- Comparativa Java EE vs .NET +**Persistencia en Java** -- Desarrollo de interfaces - - Tecnologías front-end - - Comunicación cliente-servidor +| Tecnología | Tipo | Características | +|---|---|---| +| **JDBC** | Acceso directo SQL | Control total; mucho código manual | +| **JPA** | API estándar ORM | Mapeo objeto-relacional con anotaciones | +| **Hibernate** | Implementación JPA | ORM más popular; JPQL | ---- +**Plataforma .NET — Equivalencias con Java EE** -# 2. Arquitectura Java EE / Jakarta EE +| .NET | Java EE | +|---|---| +| CLR | JVM | +| C# | Java | +| ASP.NET Core | Servlet + Spring MVC | +| ADO.NET | JDBC | +| Entity Framework | JPA + Hibernate | -## 2.1. Definición +**Desarrollo de interfaces** -Plataforma de desarrollo para aplicaciones empresariales en Java. +- Front-end: HTML, CSS, JavaScript +- Frameworks: Angular, React, Vue +- Comunicación: REST (JSON) / SOAP (XML) -- Java EE (Oracle) -- Jakarta EE (Eclipse Foundation) + +# 1. Arquitectura Java EE / Jakarta EE + +## 1.1 Definición y origen + +**Java EE (Java Enterprise Edition)** era la plataforma de Oracle para el desarrollo de aplicaciones empresariales en Java. + +En **2017** Oracle donó la plataforma a la **Eclipse Foundation**, que la renombró como **Jakarta EE**. A partir de la versión 9, todos los paquetes cambiaron del prefijo `javax.*` al prefijo `jakarta.*`. Permite crear aplicaciones: - Web - Distribuidas - Escalables -Se ejecuta sobre un servidor de aplicaciones. - -Ejemplos: -- WildFly -- GlassFish -- WebLogic +Se ejecuta sobre un **servidor de aplicaciones** que implementa las APIs de la especificación. --- -## 2.2. Servidor de aplicaciones +## 1.2 Servidor de aplicaciones -Software que proporciona servicios a aplicaciones empresariales: +Software que proporciona los servicios de infraestructura necesarios a las aplicaciones empresariales. -Funciones: -- Ejecución de aplicaciones web +**Funciones:** +- Ejecución de aplicaciones web (Servlets, JSP…) - Gestión de transacciones - Seguridad -- Gestión de conexiones a base de datos -- Gestión de sesiones +- Pool de conexiones a base de datos +- Gestión de sesiones y clustering -Idea clave: -El servidor implementa las APIs de Jakarta EE. +**Servidores de aplicaciones Jakarta EE:** + +| Servidor | Fabricante | Licencia | +|---|---|---| +| **WildFly** (antes JBoss) | Red Hat | Open source | +| **GlassFish** | Eclipse Foundation | Open source | +| **WebLogic** | Oracle | Comercial | +| **WebSphere** | IBM | Comercial | +| **TomEE** | Apache | Open source | + +> **Nota:** Apache Tomcat **no es** un servidor Jakarta EE completo; solo implementa Servlets y JSP. --- -## 2.3. APIs principales +## 1.3 APIs principales ### Servlet -Gestiona peticiones HTTP. +Componente Java que gestiona peticiones y respuestas HTTP. -- Métodos: GET, POST, PUT, DELETE +- Métodos soportados: `GET`, `POST`, `PUT`, `DELETE`, `HEAD`, `OPTIONS` +- Ciclo de vida: `init()` → `service()` → `destroy()` - Base del desarrollo web en Java -Flujo: -Cliente → Servlet → Respuesta +``` +Cliente → petición HTTP → Servlet → procesa → respuesta HTTP → Cliente +``` --- ### JSP (JavaServer Pages) -- Páginas HTML con código Java incrustado -- Generación dinámica de contenido +Páginas HTML con código Java incrustado que se compilan a un Servlet en el servidor. -Uso actual: -Limitado, sustituido por frameworks modernos. +- Etiquetas especiales: `<% %>` (scriptlet), `<%= %>` (expresión), `<%! %>` (declaración) +- Uso disminuido en favor de Thymeleaf, FreeMarker, etc. --- ### EJB (Enterprise JavaBeans) -Componentes de lógica de negocio. +Componentes de lógica de negocio con servicios gestionados automáticamente por el contenedor. -Características: -- Gestión automática de transacciones -- Seguridad -- Concurrencia - -Uso actual: -Menor en aplicaciones modernas. +| Tipo | Descripción | +|---|---| +| **Session Bean Stateless** | Sin estado entre llamadas; escalable | +| **Session Bean Stateful** | Mantiene estado para un cliente concreto | +| **Message-Driven Bean** | Procesa mensajes asíncronos (JMS) | --- ### JSF (JavaServer Faces) -Framework de interfaces web basado en componentes. +Framework estándar de Jakarta EE para interfaces web basadas en **componentes**. Sigue el patrón MVC. --- ### JPA (Java Persistence API) -API estándar para persistencia. +API estándar para la **persistencia de objetos** en bases de datos relacionales. -Permite: -- Mapear objetos a tablas -- Consultas orientadas a objetos +- Mapea clases Java a tablas mediante anotaciones. +- Consultas en **JPQL** (orientado a objetos) o Criteria API. +- Implementaciones: **Hibernate** (la más usada), EclipseLink, OpenJPA. + +**Anotaciones básicas:** + +| Anotación | Uso | +|---|---| +| `@Entity` | Marca la clase como entidad persistente | +| `@Table(name="...")` | Nombre de la tabla | +| `@Id` | Clave primaria | +| `@GeneratedValue` | Generación automática del ID | +| `@Column` | Mapeo de columna | +| `@OneToMany`, `@ManyToOne`, `@ManyToMany` | Relaciones entre entidades | --- ### JTA (Java Transaction API) -Gestión de transacciones distribuidas. +Gestión de **transacciones distribuidas**. Garantiza las propiedades **ACID**: -Propiedades ACID: -- Atomicidad -- Consistencia -- Aislamiento -- Durabilidad +| Propiedad | Descripción | +|---|---| +| **Atomicidad** | Toda la transacción se ejecuta o ninguna parte | +| **Consistencia** | La BD pasa de un estado válido a otro | +| **Aislamiento** | Las transacciones concurrentes no se interfieren | +| **Durabilidad** | Los cambios confirmados son permanentes | --- -## 2.4. Persistencia +### CDI (Contexts and Dependency Injection) -### JDBC +Framework de inyección de dependencias de Jakarta EE. -Acceso directo a base de datos mediante SQL. - -Patrón asociado: -DAO (Data Access Object) - -Ventajas: -- Control total - -Desventajas: -- Mucho código manual +- Gestiona el ciclo de vida de los objetos (beans). +- Permite inyectar dependencias mediante `@Inject`. +- Favorece bajo acoplamiento. --- -### ORM (Object Relational Mapping) +### Miniresumen -Mapeo objeto-relacional: -- Tablas → Clases -- Registros → Objetos - -Tecnologías: -- JPA (estándar) -- Hibernate (implementación) - -Lenguaje: -JPQL (Java Persistence Query Language) +Jakarta EE se ejecuta sobre servidores de aplicaciones como WildFly o GlassFish. Sus APIs clave son: **Servlet** (HTTP), **JSP** (páginas dinámicas), **EJB** (lógica de negocio), **JPA** (persistencia), **JTA** (transacciones) y **CDI** (inyección de dependencias). --- -## 2.5. Documentación +# 2. Persistencia en Java -- JavaDoc: documentación del código Java -- Swagger / OpenAPI: documentación de APIs REST +## 2.1 JDBC y patrón DAO + +**JDBC (Java Database Connectivity)** es la API estándar de Java para el acceso directo a bases de datos relacionales mediante SQL. + +Pasos de uso: +1. Cargar el driver del SGBD. +2. Establecer la conexión (`DriverManager.getConnection()`). +3. Crear un `Statement` o `PreparedStatement`. +4. Ejecutar la consulta SQL. +5. Procesar el `ResultSet`. +6. Cerrar la conexión. + +| | JDBC | +|---|---| +| **Ventajas** | Control total sobre el SQL; rendimiento máximo | +| **Inconvenientes** | Código repetitivo (boilerplate); acoplamiento al SGBD | + +**Patrón DAO (Data Access Object):** encapsula la lógica de acceso a datos en una capa separada, aislando la lógica de negocio del mecanismo de persistencia. --- -## 2.6. Seguridad +## 2.2 ORM, JPA e Hibernate -Tipos de seguridad: +**ORM (Object-Relational Mapping):** técnica que mapea el modelo de objetos con el modelo relacional. -### Seguridad declarativa -- Configuración mediante ficheros o anotaciones -- Basada en roles +| Concepto relacional | Concepto OO | +|---|---| +| Tabla | Clase | +| Fila (registro) | Objeto (instancia) | +| Columna (campo) | Atributo | +| Clave primaria | Identificador (`@Id`) | +| Clave foránea | Referencia a otro objeto | -### Seguridad programática -- Implementada mediante código +**JPA** es la especificación estándar. **Hibernate** es su implementación más popular. + +**JPQL (Java Persistence Query Language):** +- Similar a SQL pero orientado a objetos. +- Opera sobre entidades y atributos, no sobre tablas y columnas. + +```java +// JPQL +SELECT e FROM Empleado e WHERE e.departamento.nombre = :dept + +// SQL equivalente +SELECT * FROM empleados e JOIN departamentos d ON e.dept_id = d.id WHERE d.nombre = ? +``` + +**Spring Data JPA:** genera automáticamente las consultas a partir del nombre del método. + +```java +List findByDepartamentoNombre(String nombre); +``` + +**Documentación:** +- **JavaDoc**: documentación del código Java. +- **Swagger / OpenAPI**: documentación de APIs REST. --- -### Spring Security +### Miniresumen -Framework para seguridad en aplicaciones Java: - -Funciones: -- Autenticación -- Autorización -- Control de accesos -- Protección CSRF +La persistencia en Java usa **JDBC** para acceso SQL directo o **JPA/Hibernate** (ORM) para mapeo objeto-relacional. Las consultas se escriben en **JPQL**. Spring Data JPA simplifica el acceso generando consultas automáticamente. --- -# 3. Plataforma .NET +# 3. Seguridad en Java EE -## 3.1. Definición +## 3.1 Tipos de seguridad -Plataforma de Microsoft para desarrollo de aplicaciones. - -Permite crear: -- Aplicaciones web -- Aplicaciones de escritorio -- Servicios - -Actualmente: -.NET moderno es multiplataforma. +| Tipo | Mecanismo | Cuándo usarlo | +|---|---|---| +| **Declarativa** | Anotaciones (`@RolesAllowed`, `@PermitAll`, `@DenyAll`) o ficheros de config | Lógica simple basada en roles | +| **Programática** | Código Java (`SecurityContext`, `isUserInRole()`) | Lógica de seguridad compleja | --- -## 3.2. Componentes +## 3.2 Spring Security -- CLR (Common Language Runtime) -- Framework de clases base -- ASP.NET para aplicaciones web +Framework de seguridad estándar de facto en el ecosistema Java. + +**Funcionalidades:** +- **Autenticación**: verificar la identidad (usuario + contraseña, JWT, OAuth2…) +- **Autorización**: controlar el acceso según roles o permisos +- **Protección CSRF**: evita ataques de falsificación de solicitudes entre sitios +- **Gestión de sesiones** +- **Cifrado de contraseñas**: BCrypt, Argon2… + +**Mecanismos de autenticación soportados:** + +| Mecanismo | Descripción | +|---|---| +| Form Login | Formulario HTML clásico | +| HTTP Basic | Cabecera `Authorization: Basic ...` | +| **JWT** | Token firmado sin estado (stateless) | +| **OAuth2 / OIDC** | Delegación a proveedor externo (Google, GitHub…) | +| LDAP | Directorio corporativo | --- -## 3.3. Lenguajes +### Miniresumen -- C# (principal) -- VB.NET -- F# +La seguridad en Java EE puede ser **declarativa** (anotaciones) o **programática** (código). **Spring Security** gestiona autenticación, autorización, protección CSRF y soporta JWT y OAuth2. --- -## 3.4. Persistencia +# 4. Plataforma .NET -### ADO.NET +## 4.1 Definición y componentes -Acceso directo a bases de datos. +**.NET** es la plataforma de desarrollo de Microsoft para crear aplicaciones web, de escritorio, servicios y aplicaciones móviles. -### Entity Framework +**Evolución:** +- **.NET Framework** (2002): solo Windows. +- **.NET Core** (2016): multiplataforma (Windows, Linux, macOS). +- **.NET 5+** (2020): unificación bajo el nombre ".NET". -ORM de .NET equivalente a JPA/Hibernate. +**Componentes principales:** + +| Componente | Descripción | Equivalente Java EE | +|---|---|---| +| **CLR** (Common Language Runtime) | Máquina virtual; ejecuta código IL | JVM | +| **BCL** (Base Class Library) | Librerías base del framework | Java SE | +| **ASP.NET Core** | Framework web | Servlet + Spring MVC | +| **Entity Framework Core** | ORM | JPA + Hibernate | + +**Proceso de compilación:** +``` +Código C# → compilador → IL (Intermediate Language) → CLR (JIT) → código nativo +``` --- -## 3.5. Seguridad +## 4.2 Lenguajes de .NET -Características: -- Integrada en el framework -- Basada en roles +Todos compilan a **IL** y se ejecutan en el CLR: -Métodos de autenticación: -- Windows Authentication -- JWT -- OAuth +| Lenguaje | Paradigma | Uso principal | +|---|---|---| +| **C#** | Orientado a objetos | Aplicaciones empresariales, web, escritorio | +| **VB.NET** | Orientado a objetos | Aplicaciones legacy Windows | +| **F#** | Funcional | Análisis de datos, computación científica | --- -# 4. Comparativa Java EE vs .NET +## 4.3 Persistencia en .NET -| Característica | Java EE / Jakarta EE | .NET | -|----------------|---------------------|------| -| Propietario | Eclipse Foundation | Microsoft | -| Lenguaje | Java | C# | -| Servidor | WildFly, GlassFish | IIS, Kestrel | -| ORM | JPA / Hibernate | Entity Framework | -| Multiplataforma | Sí | Sí | -| Seguridad | Spring Security | Integrada | +**ADO.NET:** +- Acceso directo a bases de datos mediante SQL. +- Equivalente a JDBC. +- Clases: `SqlConnection`, `SqlCommand`, `SqlDataReader`, `DataSet`. -Conclusión: -Ambos son frameworks empresariales equivalentes. +**Entity Framework (EF Core):** +- ORM de .NET; equivalente a JPA + Hibernate. +- Tres enfoques: + - **Code First**: se definen las clases; EF genera la BD. + - **Database First**: se parte de la BD existente; EF genera las clases. + - **Model First**: se diseña el modelo visual; EF genera BD y clases. +- Consultas con **LINQ (Language Integrated Query)**: tipadas directamente en C#. + +```csharp +var empleados = context.Empleados + .Where(e => e.Departamento.Nombre == "TIC") + .OrderBy(e => e.Apellidos) + .ToList(); +``` --- -# 5. Características comunes +## 4.4 Seguridad en .NET -- Arquitectura en capas: - - Presentación - - Negocio - - Persistencia +- Integrada en ASP.NET Core mediante middleware. +- Basada en **claims** y **roles**. -- Aplicaciones distribuidas -- Escalabilidad -- Seguridad integrada -- Uso de servicios web +| Método | Descripción | +|---|---| +| Windows Authentication | Integración con Active Directory / dominio | +| **JWT** | Token sin estado; estándar en APIs REST | +| **OAuth2 / OpenID Connect** | Delegación a proveedor externo | +| Cookie Authentication | Sesión basada en cookies | + +--- + +### Miniresumen + +.NET es la plataforma de Microsoft, multiplataforma desde .NET Core. Componentes clave: **CLR** (máquina virtual), **ASP.NET Core** (web), **ADO.NET** (SQL directo) y **Entity Framework** (ORM). Lenguaje principal: **C#**. + +--- + +# 5. Comparativa Java EE vs .NET + +| Característica | Java EE / Jakarta EE | .NET (Core / 5+) | +|---|---|---| +| **Gestor** | Eclipse Foundation | Microsoft | +| **Lenguaje principal** | Java | C# | +| **Máquina virtual** | JVM | CLR | +| **Servidor web** | WildFly, GlassFish, Tomcat | Kestrel, IIS | +| **Framework web** | Spring MVC, JSF | ASP.NET Core | +| **ORM** | JPA / Hibernate | Entity Framework Core | +| **Acceso SQL directo** | JDBC | ADO.NET | +| **Seguridad** | Spring Security | ASP.NET Core Identity | +| **Inyección de dependencias** | CDI, Spring DI | DI nativo en ASP.NET Core | +| **Multiplataforma** | Sí (JVM) | Sí (desde .NET Core) | +| **Licencia** | Open source (mayoría) | Open source (MIT) | + +> **Conclusión:** ambas son plataformas empresariales equivalentes. La elección depende del ecosistema y el perfil del equipo. --- # 6. Desarrollo de interfaces -## 6.1. Front-end +## 6.1 Tecnologías front-end -Tecnologías principales: -- HTML -- CSS -- JavaScript +El **front-end** es la parte de la aplicación que se ejecuta en el navegador del usuario. -Frameworks: -- Angular -- React -- Vue +**Tecnologías base:** + +| Tecnología | Función | +|---|---| +| **HTML** | Estructura y contenido de la página | +| **CSS** | Presentación y diseño visual | +| **JavaScript** | Comportamiento e interactividad | + +**Frameworks de front-end:** + +| Framework | Fabricante | Paradigma | +|---|---|---| +| **Angular** | Google | Framework completo (TypeScript) | +| **React** | Meta | Librería de UI (JSX) | +| **Vue** | Comunidad | Framework progresivo | --- -## 6.2. Back-end +## 6.2 Comunicación cliente-servidor -Java: -- Jakarta EE -- Spring +**Protocolo:** HTTP / HTTPS. -.NET: -- ASP.NET +**Arquitecturas de API:** + +| Arquitectura | Formato | Características | +|---|---|---| +| **REST** | JSON | Sin estado; orientado a recursos; HTTP nativo | +| **SOAP** | XML | Protocolo formal con WSDL; entornos corporativos | +| **GraphQL** | JSON | El cliente especifica exactamente los datos que necesita | +| **WebSocket** | Binario / texto | Comunicación bidireccional en tiempo real | --- -## 6.3. Comunicación cliente-servidor +## 6.3 Tipos de aplicaciones web -Protocolos: -- HTTP / HTTPS - -Formatos: -- JSON -- XML - -Arquitecturas: -- REST -- SOAP +| Tipo | Descripción | Tecnología | +|---|---|---| +| **MPA** (Multi-Page Application) | Cada acción genera una página nueva desde el servidor | Thymeleaf, JSP, Razor | +| **SPA** (Single-Page Application) | Una sola página; contenido actualizado dinámicamente | Angular, React, Vue | +| **PWA** (Progressive Web App) | SPA con capacidades offline y notificaciones push | Service Workers | +| **SSR** (Server-Side Rendering) | El servidor renderiza la página inicial | Next.js, Nuxt.js | --- -## 6.4. Tipos de aplicaciones +### Miniresumen -- Aplicaciones web tradicionales -- SPA (Single Page Applications) -- Aplicaciones móviles con API backend +El front-end usa **HTML, CSS y JavaScript**. Los frameworks más usados son **Angular, React y Vue**. La comunicación con el back-end se realiza mediante **APIs REST con JSON** sobre HTTPS. Las SPA son el modelo más habitual en aplicaciones modernas. --- -# 7. Conceptos importantes de examen +# Miniresumen final del tema -- Servlet: gestión de peticiones HTTP -- JSP: páginas dinámicas (uso limitado hoy) -- JPA: estándar de persistencia -- Hibernate: implementación de ORM -- Entity Framework: ORM de .NET -- Spring Security: seguridad en Java - ---- - -# 8. Miniresumen final - -Java EE/Jakarta EE y .NET son plataformas de desarrollo empresarial. - -Java EE usa: -- Servlets, JSP, EJB, JPA - -.NET usa: -- ASP.NET, C#, Entity Framework - -Ambos: -- Arquitectura multicapa -- Seguridad integrada -- Persistencia mediante ORM o acceso directo -- Desarrollo de aplicaciones web y servicios \ No newline at end of file +| Punto | Idea clave | +|---|---| +| **1. Java EE / Jakarta EE** | Plataforma empresarial Java; APIs: Servlet, JSP, EJB, JSF, JPA, JTA, CDI | +| **2. Persistencia en Java** | JDBC (SQL directo) o JPA/Hibernate (ORM); consultas en JPQL | +| **3. Seguridad Java EE** | Declarativa (anotaciones) o programática; Spring Security: autenticación, autorización, JWT, OAuth2 | +| **4. .NET** | Plataforma Microsoft; CLR, C#, ASP.NET Core, Entity Framework (EF Core) | +| **5. Comparativa** | Plataformas equivalentes; Java EE usa JVM y Spring; .NET usa CLR y ASP.NET Core | +| **6. Interfaces** | HTML + CSS + JS; frameworks Angular/React/Vue; comunicación REST/JSON | \ No newline at end of file diff --git a/src/main/resources/temas/bloque3/B3T5_audio.md b/src/main/resources/temas/bloque3/B3T5_audio.md index 75ebfc4..d256af4 100644 --- a/src/main/resources/temas/bloque3/B3T5_audio.md +++ b/src/main/resources/temas/bloque3/B3T5_audio.md @@ -1,6 +1,136 @@ ## Bloque 3 Tema 5. Arquitectura Java EE/Jakarta EE y plataforma .NET. Componentes, persistencia y seguridad. Características, lenguajes y desarrollo de interfaces. -Este tema estudia las dos grandes plataformas de desarrollo empresarial: Java EE con su sucesor Jakarta EE, y la plataforma .NET de Microsoft. +Este tema estudia las dos grandes plataformas de desarrollo empresarial: Jakarta EE, sucesor de Java EE, y la plataforma .NET de Microsoft. También estudia la persistencia, la seguridad y el desarrollo de interfaces en ambos entornos. + +--- + +## 1. Arquitectura Java EE / Jakarta EE + +### 1.1. Definición y origen + +Java EE, o Java Enterprise Edition, era la plataforma de Oracle para el desarrollo de aplicaciones empresariales en Java. En 2017 Oracle donó la plataforma a la Eclipse Foundation, que la renombró como Jakarta EE. A partir de la versión 9, todos los paquetes cambiaron del prefijo javax al prefijo jakarta. Permite crear aplicaciones web, distribuidas y escalables, que se ejecutan sobre un servidor de aplicaciones que implementa las APIs de la especificación. + +--- + +### 1.2. Servidor de aplicaciones + +Un servidor de aplicaciones es el software que proporciona los servicios de infraestructura necesarios a las aplicaciones empresariales. Sus funciones son la ejecución de aplicaciones web mediante Servlets y JSP, la gestión de transacciones, la seguridad, el pool de conexiones a base de datos y la gestión de sesiones. El servidor implementa las APIs de Jakarta EE. Los servidores más conocidos son WildFly, antes llamado JBoss, que es de Red Hat y es de código abierto; GlassFish de la Eclipse Foundation; WebLogic de Oracle; y WebSphere de IBM. Es importante saber que Apache Tomcat no es un servidor Jakarta EE completo, porque solo implementa Servlets y JSP, sin el perfil completo de la especificación. + +--- + +### 1.3. APIs principales + +Los Servlets son componentes Java que gestionan peticiones y respuestas HTTP. Soportan los métodos GET, POST, PUT, DELETE, HEAD y OPTIONS. Su ciclo de vida tiene tres fases: init para la inicialización, service para el procesamiento de peticiones, y destroy para la liberación de recursos. Son la base del desarrollo web en Java. + +Las JSP o JavaServer Pages son páginas HTML con código Java incrustado que se compilan a un Servlet en el servidor para generar contenido dinámico. Su uso ha disminuido en favor de motores de plantillas modernos como Thymeleaf. + +Los EJB o Enterprise JavaBeans son componentes de lógica de negocio con servicios gestionados automáticamente por el contenedor del servidor: transacciones, seguridad y concurrencia. Existen tres tipos: Session Bean sin estado, que es escalable y no conserva información entre llamadas; Session Bean con estado, que mantiene el estado para un cliente concreto; y Message-Driven Bean, para el procesamiento de mensajes asíncronos mediante JMS. + +JSF o JavaServer Faces es el framework estándar de Jakarta EE para interfaces web basadas en componentes. Sigue el patrón MVC. + +JPA o Java Persistence API es la API estándar para la persistencia de objetos en bases de datos relacionales. Permite mapear clases Java a tablas mediante anotaciones como Entity, Table, Id, Column y las relaciones OneToMany, ManyToOne y ManyToMany. Las consultas se escriben en JPQL, el Java Persistence Query Language, que opera sobre entidades y atributos en lugar de tablas y columnas. La implementación más popular es Hibernate. + +JTA o Java Transaction API gestiona las transacciones distribuidas garantizando las propiedades ACID: atomicidad, que significa que toda la transacción se ejecuta o ninguna parte; consistencia, que asegura que la base de datos pasa de un estado válido a otro; aislamiento, que evita interferencias entre transacciones concurrentes; y durabilidad, que garantiza que los cambios confirmados son permanentes. + +CDI o Contexts and Dependency Injection es el framework de inyección de dependencias de Jakarta EE. Gestiona el ciclo de vida de los objetos y permite inyectar dependencias mediante la anotación Inject, favoreciendo el bajo acoplamiento y la modularidad. + +En resumen: Jakarta EE se ejecuta sobre servidores de aplicaciones como WildFly o GlassFish. Sus APIs clave son Servlet para HTTP, JSP para páginas dinámicas, EJB para lógica de negocio, JPA para persistencia, JTA para transacciones y CDI para inyección de dependencias. + +--- + +## 2. Persistencia en Java + +### 2.1. JDBC y patrón DAO + +JDBC, o Java Database Connectivity, es la API estándar de Java para el acceso directo a bases de datos relacionales mediante SQL. Los pasos de uso son: cargar el driver del SGBD, establecer la conexión mediante DriverManager, crear un Statement o PreparedStatement, ejecutar la consulta SQL, procesar el ResultSet y cerrar la conexión. Sus ventajas son el control total sobre el SQL y el máximo rendimiento. Sus desventajas son el código repetitivo conocido como boilerplate y el acoplamiento al SGBD concreto. El patrón DAO, o Data Access Object, encapsula la lógica de acceso a datos en una capa separada, aislando la lógica de negocio del mecanismo de persistencia. + +--- + +### 2.2. ORM, JPA e Hibernate + +El ORM u Object-Relational Mapping es una técnica que mapea el modelo de objetos con el modelo relacional de la base de datos. Una tabla se convierte en una clase, una fila en un objeto, una columna en un atributo, la clave primaria en el identificador marcado con la anotación Id, y la clave foránea en una referencia a otro objeto. + +JPA es la especificación estándar y Hibernate su implementación más popular. JPQL es similar a SQL pero orientado a objetos: opera sobre entidades y atributos en lugar de tablas y columnas, lo que hace las consultas más portables entre distintos gestores de base de datos. Spring Data JPA añade una capa de abstracción sobre JPA que genera automáticamente las consultas a partir del nombre del método: por ejemplo, un método llamado findByDepartamentoNombre genera la consulta correspondiente sin necesidad de escribirla. Para la documentación del código Java se usa JavaDoc. Para la documentación de APIs REST se usa Swagger u OpenAPI. + +En resumen: la persistencia en Java puede gestionarse con JDBC para acceso SQL directo, o con JPA e Hibernate como ORM. JPA mapea clases a tablas mediante anotaciones y las consultas se escriben en JPQL. Spring Data JPA simplifica el acceso generando consultas automáticamente. + +--- + +## 3. Seguridad en Java EE + +### 3.1. Tipos de seguridad + +La seguridad en Java EE puede configurarse de dos formas. La seguridad declarativa se configura mediante anotaciones como RolesAllowed, PermitAll o DenyAll, o mediante ficheros de configuración. No requiere código adicional en la lógica de negocio y el servidor de aplicaciones gestiona el control de acceso basándose en los roles del usuario. La seguridad programática se implementa directamente en el código Java para casos más complejos, utilizando el SecurityContext o métodos como isUserInRole del HttpServletRequest. + +--- + +### 3.2. Spring Security + +Spring Security es el framework de seguridad estándar de facto en el ecosistema Java. Proporciona autenticación, que es la verificación de la identidad del usuario mediante contraseña, token JWT u OAuth2; autorización, que controla el acceso a recursos según los roles y permisos; protección contra CSRF o Cross-Site Request Forgery; gestión de sesiones; y cifrado de contraseñas mediante algoritmos seguros como BCrypt. Los mecanismos de autenticación soportados son: formulario HTML clásico; HTTP Basic mediante la cabecera Authorization; JWT o JSON Web Token, que es un token firmado sin estado especialmente útil en APIs REST; OAuth2 y OpenID Connect para delegación a proveedores externos como Google o GitHub; y LDAP para directorios corporativos. + +En resumen: la seguridad en Java EE puede ser declarativa mediante anotaciones o programática mediante código. Spring Security gestiona autenticación, autorización, protección CSRF y soporta JWT y OAuth2. + +--- + +## 4. Plataforma .NET + +### 4.1. Definición y componentes + +.NET es la plataforma de desarrollo de Microsoft para crear aplicaciones web, de escritorio, servicios y aplicaciones móviles. Evolucionó desde .NET Framework en 2002, que solo funcionaba en Windows, pasando por .NET Core en 2016 que lo hizo multiplataforma para Windows, Linux y macOS, hasta la unificación bajo el nombre .NET a partir de la versión 5 en 2020. Sus componentes principales son: el CLR o Common Language Runtime, que es la máquina virtual equivalente a la JVM de Java y compila el código IL justo a tiempo con el compilador JIT; la BCL o Base Class Library, que son las librerías base del framework; ASP.NET Core para el desarrollo web; y Entity Framework Core como ORM. + +--- + +### 4.2. Lenguajes de .NET + +Todos los lenguajes de .NET compilan a IL o Intermediate Language y se ejecutan en el CLR. El lenguaje principal es C#, que es orientado a objetos y se usa para aplicaciones empresariales, web y de escritorio. VB.NET es el sucesor del clásico Visual Basic y se usa principalmente en aplicaciones legacy de Windows. F# es un lenguaje funcional orientado al análisis de datos y la computación científica. + +--- + +### 4.3. Persistencia en .NET + +ADO.NET es el acceso directo a bases de datos mediante SQL, equivalente a JDBC en Java. Sus clases principales son SqlConnection para la conexión, SqlCommand para ejecutar comandos, SqlDataReader para leer resultados y DataSet para almacenar datos en memoria. Entity Framework Core es el ORM de .NET, equivalente a JPA e Hibernate. Ofrece tres enfoques: Code First, en el que se definen primero las clases y Entity Framework genera la base de datos a partir de ellas; Database First, en el que se parte de una base de datos existente y Entity Framework genera las clases automáticamente; y Model First, en el que se diseña el modelo visual y Entity Framework genera tanto la base de datos como las clases. Las consultas se escriben con LINQ, o Language Integrated Query, que permite escribir consultas tipadas directamente en C# con verificación de tipos en tiempo de compilación, de forma similar a JPQL pero integrada en el lenguaje. + +--- + +### 4.4. Seguridad en .NET + +La seguridad en .NET está integrada en ASP.NET Core mediante middleware. Se basa en claims y roles. Los métodos de autenticación soportados son: Windows Authentication para la integración con Active Directory y dominios corporativos; JWT o JSON Web Token para APIs REST sin estado; OAuth2 y OpenID Connect para delegación a proveedores externos; y autenticación basada en cookies para aplicaciones web tradicionales. + +En resumen: .NET es la plataforma de Microsoft, multiplataforma desde .NET Core. Sus componentes clave son el CLR como máquina virtual, ASP.NET Core para web, ADO.NET para acceso SQL directo y Entity Framework Core como ORM. El lenguaje principal es C#. + +--- + +## 5. Comparativa Java EE vs .NET + +Tanto Java EE como .NET son plataformas empresariales maduras con componentes equivalentes. Java EE usa la JVM como máquina virtual mientras que .NET usa el CLR. El lenguaje principal de Java EE es Java y el de .NET es C#. Para el desarrollo web, Java EE usa Spring MVC o JSF y .NET usa ASP.NET Core. Para la persistencia, Java EE usa JPA e Hibernate y .NET usa Entity Framework Core. Para el acceso SQL directo, Java EE usa JDBC y .NET usa ADO.NET. Para la seguridad, Java EE suele usar Spring Security y .NET tiene seguridad integrada en ASP.NET Core. Ambas plataformas son multiplataforma en sus versiones modernas, ambas son principalmente de código abierto, y la elección entre una y otra depende del ecosistema de la organización y del perfil del equipo de desarrollo. + +--- + +## 6. Desarrollo de interfaces + +### 6.1. Tecnologías front-end + +El front-end es la parte de la aplicación que se ejecuta en el navegador del usuario. Se desarrolla con tres tecnologías base: HTML para la estructura y el contenido de la página, CSS para la presentación y el diseño visual, y JavaScript para el comportamiento y la interactividad. Los frameworks de front-end más usados son Angular de Google, que es un framework completo que usa TypeScript; React de Meta, que es una librería de interfaz de usuario que usa JSX; y Vue, que es un framework progresivo mantenido por la comunidad. + +--- + +### 6.2. Comunicación cliente-servidor + +La comunicación entre el front-end y el back-end se realiza mediante HTTP o HTTPS. Las arquitecturas de API más habituales son REST, que usa JSON como formato de datos, no mantiene estado entre peticiones y se apoya en los verbos HTTP; SOAP, que usa XML con un contrato formal definido mediante WSDL y se usa en entornos corporativos con requisitos estrictos de interoperabilidad; GraphQL, en el que el cliente especifica exactamente los datos que necesita, reduciendo el tráfico innecesario; y WebSocket, que permite comunicación bidireccional en tiempo real entre cliente y servidor. + +--- + +### 6.3. Tipos de aplicaciones web + +Las aplicaciones web pueden clasificarse en varios tipos. Las MPA o Multi-Page Applications generan una nueva página completa desde el servidor en cada acción del usuario, usando tecnologías como Thymeleaf, JSP o Razor. Las SPA o Single-Page Applications cargan una única página inicial y actualizan el contenido dinámicamente mediante llamadas a una API, usando frameworks como Angular, React o Vue. Las PWA o Progressive Web Apps son SPA con capacidades adicionales como funcionamiento offline y notificaciones push, implementadas mediante Service Workers. Las SSR o Server-Side Rendering, como Next.js o Nuxt.js, combinan ambos modelos renderizando la página inicial en el servidor para mejorar el rendimiento y el posicionamiento en buscadores. + +En resumen: el front-end usa HTML, CSS y JavaScript. Los frameworks más usados son Angular, React y Vue. La comunicación con el back-end se realiza principalmente mediante APIs REST con JSON sobre HTTPS. Las SPA son el modelo más habitual en aplicaciones modernas. + +--- + +## Miniresumen final del tema + +Este tema cubre las dos grandes plataformas empresariales de desarrollo. Jakarta EE es la evolución de Java EE, gestionada por la Eclipse Foundation, que se ejecuta sobre servidores de aplicaciones como WildFly o GlassFish. Sus APIs principales son Servlet para gestionar HTTP, JPA para la persistencia mediante ORM con consultas en JPQL, JTA para las transacciones con propiedades ACID, y Spring Security para la autenticación y autorización. La persistencia en Java usa JDBC para acceso SQL directo o JPA e Hibernate como ORM. .NET es la plataforma de Microsoft con CLR como máquina virtual, C# como lenguaje principal, ASP.NET Core para web, ADO.NET para acceso SQL directo y Entity Framework Core como ORM con consultas en LINQ. Ambas plataformas son equivalentes y multiplataforma en sus versiones modernas. El desarrollo de interfaces usa HTML, CSS y JavaScript en el front-end, frameworks como Angular, React y Vue, y comunicación REST con JSON entre cliente y servidor. --- diff --git a/src/main/resources/temas/bloque3/B3T6.md b/src/main/resources/temas/bloque3/B3T6.md index 8b6833d..2baf891 100644 --- a/src/main/resources/temas/bloque3/B3T6.md +++ b/src/main/resources/temas/bloque3/B3T6.md @@ -1,259 +1,318 @@ -/* Apuntes de clase */ - -Comunicacion -- Sincrona -- Asincrona - -WS - -# Tema 6 – Arquitectura cliente/servidor y multicapas. Servicios web y protocolos +# Bloque 3 · Tema 6 +# Arquitectura cliente/servidor y multicapas. Servicios web y protocolos. --- -## 1. Esquema general +# Esquema resumen -1. Arquitectura cliente/servidor -2. Arquitectura multicapas (n-tier) -3. Componentes principales -4. Funcionamiento (operación) -5. Arquitecturas de servicios web -6. Protocolos asociados +**Modelos arquitectónicos** + +| Modelo | Descripción | Característica clave | +|---|---|---| +| **Cliente/servidor** | Cliente solicita, servidor responde | Separación de roles | +| **2 capas** | Cliente + servidor | Cliente pesado o ligero | +| **3 capas** | Presentación + lógica + datos | Forma más habitual | +| **N capas** | Multicapas con capa de servicios o integración | Aplicaciones complejas | + +**Servicios web** + +| Tecnología | Tipo | Formato | Descripción | +|---|---|---|---| +| **SOAP** | Protocolo | XML | Formal, contrato WSDL, empresarial | +| **REST** | Estilo arquitectónico | JSON | Ligero, verbos HTTP, API modernas | +| **GraphQL** | Lenguaje de consulta | JSON | Cliente define qué campos necesita | +| **gRPC** | Protocolo RPC | Protobuf | Alta eficiencia, microservicios | +| **WebSocket** | Protocolo bidireccional | Cualquiera | Tiempo real, persistente | + +**Protocolos principales** + +| Protocolo | Capa | Función | +|---|---|---| +| **HTTP/HTTPS** | Aplicación | Petición/respuesta web; HTTPS cifra con TLS | +| **TCP** | Transporte | Entrega fiable y ordenada | +| **IP** | Red | Direccionamiento y enrutamiento | +| **TLS** | Sesión/Presentación | Cifrado del canal; sucesor de SSL | +| **DNS** | Aplicación | Resolución de nombres a IPs | +| **FTP** | Aplicación | Transferencia de ficheros | +| **SMTP** | Aplicación | Envío de correo electrónico | --- -## 2. Desarrollo +# 1. Arquitectura cliente/servidor -### 2.1 Arquitectura cliente/servidor +## 1.1. Definición y elementos -**Definición** -Modelo en el que un cliente solicita servicios y un servidor los proporciona. +La arquitectura cliente/servidor es el modelo fundamental de distribución de aplicaciones. Un **cliente** realiza peticiones de servicios o recursos, y un **servidor** los proporciona. Ambos se comunican a través de una **red**. -**Elementos** -- Cliente: realiza peticiones -- Servidor: responde y gestiona recursos -- Red: medio de comunicación - -**Características** -- Separación de funciones -- Centralización de recursos -- Escalabilidad -- Comunicación por red - -**Tipos** -- Modelo de 2 capas -- Cliente pesado (thick client) -- Cliente ligero (thin client) - -**Ejemplo** -- Navegador web (cliente) -- Servidor web (servidor) +Sus características principales son: +- **Separación de funciones**: el cliente gestiona la presentación; el servidor gestiona los datos y la lógica. +- **Centralización de recursos**: los recursos compartidos (BD, ficheros, servicios) están en el servidor. +- **Escalabilidad**: se pueden añadir más servidores o clientes sin reestructurar la arquitectura. +- **Heterogeneidad**: cliente y servidor pueden usar plataformas distintas si se comunican mediante protocolos estándar. --- -### 2.2 Arquitectura multicapas (n-tier) +## 1.2. Tipos de cliente -**Definición** -Modelo que divide la aplicación en varias capas independientes. +| Tipo | Descripción | Ejemplo | +|---|---|---| +| **Cliente pesado** (thick/fat client) | Mayor parte de la lógica en el cliente; el servidor solo aporta datos | Aplicación de escritorio con BD remota | +| **Cliente ligero** (thin client) | Casi toda la lógica en el servidor; el cliente solo gestiona la presentación | Navegador web con servidor de aplicaciones | +| **Cliente mixto** | Reparte la lógica entre cliente y servidor | SPA (Angular/React) con API REST | -**Capas principales** -1. Capa de presentación - - Interfaz de usuario -2. Capa de lógica de negocio - - Procesamiento y reglas -3. Capa de datos - - Acceso a bases de datos - -**Capas adicionales (opcional)** -- Capa de servicios -- Capa de integración - -**Ventajas** -- Modularidad -- Mantenimiento sencillo -- Escalabilidad -- Reutilización - -**Importante** -Cliente/servidor es un modelo general, mientras que multicapas define la estructura interna de la aplicación. +Los clientes ligeros son los más habituales en entornos empresariales actuales porque facilitan el mantenimiento centralizado. --- -### 2.3 Componentes principales +# 2. Arquitectura multicapas (n-tier) -**En cliente/servidor** -- Cliente -- Servidor -- Red +## 2.1. Capas principales -**En multicapas** -- Front-end (presentación) -- Back-end (lógica) -- Base de datos -- Middleware +La arquitectura multicapas divide la aplicación en capas independientes, cada una con una responsabilidad bien definida. La separación de responsabilidades facilita el mantenimiento, la escalabilidad y la reutilización. + +**Tres capas clásicas:** + +| Capa | Responsabilidad | Tecnologías típicas | +|---|---|---| +| **Presentación** | Interfaz de usuario | HTML/CSS/JS, Thymeleaf, React, Angular | +| **Lógica de negocio** | Procesamiento y reglas de la aplicación | Java EE, Spring, .NET | +| **Datos** | Persistencia y acceso a la BD | JDBC, JPA, SQL, ORM | + +**Capas adicionales:** +- **Capa de servicios**: expone funcionalidad como servicios web (REST/SOAP). +- **Capa de integración**: adapta la comunicación con sistemas externos. +- **Middleware**: software intermediario que actúa entre capas (MOM, ESB). + +**Ventajas:** +- Modularidad: cada capa puede desarrollarse y desplegarse de forma independiente. +- Mantenimiento: los cambios en una capa no afectan a las demás si se respeta el contrato. +- Escalabilidad: se puede escalar cada capa de forma independiente. +- Seguridad: las capas actúan como barreras entre el exterior y los datos. --- -### 2.4 Funcionamiento (operación) – Comunicación síncrona y asíncrona +## 2.2. Relación con cliente/servidor -**Comunicación síncrona** -- El cliente envía una petición y **espera la respuesta** del servidor. -- La ejecución queda bloqueada hasta recibir respuesta. -- Es el modelo clásico en HTTP. +Cliente/servidor y multicapas no son excluyentes: un sistema puede ser cliente/servidor (dos extremos que se comunican) y a la vez estar organizado en múltiples capas internamente. -**Ejemplo** -- Un navegador solicita una página web y espera a que el servidor responda. +| Concepto | Alcance | +|---|---| +| **Cliente/servidor** | Modelo general de comunicación entre dos extremos | +| **Multicapas** | Organización interna de la aplicación | -**Ventajas** -- Simplicidad -- Fácil de implementar - -**Inconvenientes** -- Menor rendimiento en sistemas distribuidos -- Bloqueo del cliente +Un navegador web actúa de cliente; el back-end (organizado en 3 capas) actúa de servidor. --- -**Comunicación asíncrona** -- El cliente envía una petición y **no espera inmediatamente la respuesta**. -- Puede seguir ejecutando otras tareas. -- La respuesta llega posteriormente (callback, cola, eventos). +# 3. Comunicación síncrona y asíncrona -**Ejemplo** -- Sistemas de mensajería (colas de mensajes) -- Notificaciones push -- Procesos en segundo plano +## 3.1. Comunicación síncrona -**Ventajas** -- Mayor escalabilidad -- Mejor rendimiento -- No bloquea procesos +En la comunicación síncrona el cliente envía una petición y **queda bloqueado** hasta recibir la respuesta del servidor. Es el modelo clásico de HTTP. -**Inconvenientes** -- Mayor complejidad -- Gestión de estados más difícil +| Aspecto | Detalle | +|---|---| +| **Comportamiento** | Bloqueante: el cliente espera | +| **Modelo** | Petición → bloqueo → respuesta | +| **Ejemplo** | Navegador solicita una página; espera la respuesta | +| **Ventaja** | Simplicidad, fácil de implementar y depurar | +| **Inconveniente** | Bloqueo; menor rendimiento en alta concurrencia | --- -**Clave de examen** -- HTTP tradicional → síncrono -- Sistemas distribuidos modernos → combinan síncrono y asíncrono -- La asincronía es clave en arquitecturas escalables (microservicios, colas, eventos) +## 3.2. Comunicación asíncrona y colas de mensajes + +En la comunicación asíncrona el cliente envía una petición y **no bloquea**: puede seguir ejecutando otras tareas. La respuesta llega posteriormente mediante un callback, un evento o una cola de mensajes. + +| Aspecto | Detalle | +|---|---| +| **Comportamiento** | No bloqueante | +| **Mecanismos** | Callbacks, eventos, colas de mensajes, WebSocket | +| **Ventaja** | Mayor escalabilidad y rendimiento | +| **Inconveniente** | Mayor complejidad; gestión de estado más difícil | + +**Sistemas de colas de mensajes (MOM — Message-Oriented Middleware):** +- **JMS** (Java Message Service): API estándar de Jakarta EE para mensajería asíncrona. +- **RabbitMQ**: broker de mensajes con soporte AMQP. +- **Apache Kafka**: plataforma de streaming de eventos de alto rendimiento. + +Los patrones de mensajería más comunes son: +- **Punto a punto** (Queue): un productor envía a una cola; un consumidor la lee. +- **Publicación/suscripción** (Topic): un productor publica en un topic; múltiples consumidores suscritos lo reciben. + +Clave de examen: HTTP es síncrono; microservicios y arquitecturas de eventos combinan síncrono y asíncrono; la asincronía es fundamental para la escalabilidad. --- -### 2.5 Arquitecturas de servicios web – WS (Web Services) +# 4. Servicios web -**WS (Web Services)** -Son **servicios web** que permiten la comunicación entre aplicaciones a través de una red, independientemente del lenguaje o sistema. +## 4.1. SOAP + +**SOAP** (Simple Object Access Protocol) es un **protocolo** de comunicación entre aplicaciones basado en XML. Es el modelo clásico de servicios web empresariales. + +| Elemento | Descripción | +|---|---| +| **SOAP** | Protocolo de mensajería en XML | +| **WSDL** | Web Services Description Language; describe la interfaz del servicio (operaciones, parámetros, tipos) en XML | +| **UDDI** | Universal Description, Discovery and Integration; registro para descubrir servicios web | +| **WS-Security** | Extensión de seguridad: cifrado, firma y autenticación a nivel de mensaje | + +**Estructura de un mensaje SOAP:** +- **Envelope**: elemento raíz obligatorio. +- **Header**: cabeceras opcionales (seguridad, transacciones). +- **Body**: contenido del mensaje (petición o respuesta). +- **Fault**: información de error. + +**Características:** +- Protocolo formal y estricto. +- Independiente del transporte (puede ir sobre HTTP, SMTP, TCP). +- Soporte nativo para transacciones distribuidas y seguridad a nivel de mensaje. +- Adecuado para integraciones B2B y entornos que requieren contratos formales. --- -**Características** -- Interoperabilidad (distintos sistemas se comunican) -- Uso de estándares abiertos -- Comunicación a través de red (normalmente HTTP) -- Orientados a servicios +## 4.2. REST + +**REST** (Representational State Transfer) es un **estilo arquitectónico**, no un protocolo. Lo definió Roy Fielding en su tesis doctoral de 2000. Una API que cumple los principios REST se denomina **RESTful**. + +**Principios REST (restricciones):** + +| Principio | Descripción | +|---|---| +| **Sin estado** (stateless) | Cada petición contiene toda la información necesaria; el servidor no guarda estado de sesión | +| **Interfaz uniforme** | Recursos identificados por URI; representaciones estándar (JSON, XML) | +| **Sistema en capas** | El cliente no sabe si hay intermediarios (proxy, caché, balanceador) | +| **Caché** | Las respuestas pueden ser cacheables para mejorar el rendimiento | +| **Cliente/servidor** | Separación clara entre cliente y servidor | +| **Código bajo demanda** (opcional) | El servidor puede enviar código ejecutable al cliente (JS) | + +**Verbos HTTP en REST:** + +| Verbo | Operación CRUD | Ejemplo | +|---|---|---| +| **GET** | Read (lectura) | `GET /usuarios/1` → obtener usuario 1 | +| **POST** | Create (creación) | `POST /usuarios` → crear usuario | +| **PUT** | Update completo | `PUT /usuarios/1` → reemplazar usuario 1 | +| **PATCH** | Update parcial | `PATCH /usuarios/1` → modificar campo | +| **DELETE** | Delete | `DELETE /usuarios/1` → eliminar usuario 1 | + +**Códigos de estado HTTP:** + +| Rango | Categoría | Ejemplos | +|---|---|---| +| **2xx** | Éxito | 200 OK, 201 Created, 204 No Content | +| **3xx** | Redirección | 301 Moved Permanently, 304 Not Modified | +| **4xx** | Error del cliente | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found | +| **5xx** | Error del servidor | 500 Internal Server Error, 503 Service Unavailable | + +**Diferencias SOAP vs REST:** + +| Aspecto | SOAP | REST | +|---|---|---| +| Tipo | Protocolo | Estilo arquitectónico | +| Formato | XML obligatorio | JSON (principalmente), XML, otros | +| Contrato | WSDL | OpenAPI/Swagger (recomendado) | +| Transporte | HTTP, SMTP, TCP... | HTTP/HTTPS | +| Estado | Puede ser con estado | Sin estado (stateless) | +| Uso | Empresarial, B2B, legado | APIs modernas, microservicios, móvil | --- -**Tipos de Web Services** +## 4.3. Otras arquitecturas de servicios -**1. SOAP (Web Services clásicos)** -- Basados en XML -- Protocolo formal y estricto -- Utilizan: - - SOAP → formato de mensajes - - WSDL → descripción del servicio -- Más pesados pero más estandarizados +**GraphQL:** +- Desarrollado por Meta (Facebook) en 2015. +- El cliente especifica exactamente qué campos necesita: evita el overfetching (recibir más datos de los necesarios) y el underfetching (necesitar múltiples llamadas). +- Una única URL de endpoint; las consultas se envían como `query` en el cuerpo de la petición. +- Adecuado para aplicaciones con clientes variados (web, móvil) que necesitan datos distintos. + +**gRPC:** +- Desarrollado por Google; usa HTTP/2 y Protocol Buffers (Protobuf) como formato binario. +- Muy eficiente y de bajo latencia; adecuado para comunicación entre microservicios internos. +- Los contratos se definen en ficheros `.proto`. +- Admite streaming bidireccional. + +**WebSocket:** +- Protocolo que establece una conexión persistente y bidireccional entre cliente y servidor sobre TCP. +- A diferencia de HTTP (sin estado, petición/respuesta), la conexión se mantiene abierta. +- Usos típicos: chat en tiempo real, notificaciones push, juegos online, dashboards en vivo. --- -**2. REST (estilo arquitectónico)** -- Más ligero -- Usa HTTP directamente (GET, POST, PUT, DELETE) -- Datos en JSON (principalmente) -- Más utilizado actualmente +# 5. Protocolos asociados + +## 5.1. HTTP/HTTPS + +**HTTP** (HyperText Transfer Protocol) es el protocolo de la capa de aplicación que define cómo se comunican cliente y servidor en la web. Opera sobre TCP. + +| Versión | Características clave | +|---|---| +| **HTTP/1.1** | Conexiones persistentes; pipeline; cabeceras en texto | +| **HTTP/2** | Multiplexación de streams; cabeceras comprimidas (HPACK); mayor rendimiento | +| **HTTP/3** | Basado en QUIC (UDP); menor latencia; conexiones más rápidas | + +**Cabeceras HTTP relevantes:** +- `Content-Type`: tipo MIME del cuerpo (application/json, text/html). +- `Authorization`: credenciales (Bearer token, Basic auth). +- `Cache-Control`: directivas de caché. +- `Cookie` / `Set-Cookie`: gestión de sesiones. + +**HTTPS** = HTTP + **TLS**. Garantiza confidencialidad (cifrado), integridad (no manipulación) y autenticación del servidor (certificado). --- -**Ejemplo sencillo** +## 5.2. TCP/IP y SSL/TLS -Una aplicación pide datos de un usuario: +**TCP/IP** es el conjunto de protocolos base de internet. Corresponde a las capas 3 y 4 del modelo OSI. -- Cliente → petición HTTP (REST) -- Servidor → devuelve JSON con los datos +| Protocolo | Capa | Función | +|---|---|---| +| **IP** | Red (3) | Direccionamiento y enrutamiento de paquetes | +| **TCP** | Transporte (4) | Transmisión fiable, orientada a conexión, ordenada | +| **UDP** | Transporte (4) | Transmisión no fiable, sin conexión, más rápida | + +TCP garantiza la entrega mediante el mecanismo de three-way handshake (SYN, SYN-ACK, ACK) y la retransmisión de paquetes perdidos. HTTP, HTTPS, FTP y SMTP usan TCP. DNS y algunos servicios de streaming usan UDP. + +**TLS** (Transport Layer Security) es el protocolo que proporciona seguridad en la comunicación: +- **Confidencialidad**: cifrado asimétrico para el intercambio de claves, simétrico para el flujo de datos. +- **Integridad**: MAC (Message Authentication Code) para detectar modificaciones. +- **Autenticación**: certificados X.509 firmados por una CA (Autoridad Certificadora). + +TLS 1.2 y TLS 1.3 son las versiones actuales; SSL está obsoleto y no debe usarse. --- -**Relación con el temario** -- WS = forma de implementar **arquitectura cliente/servidor distribuida** -- Muy usado en arquitecturas multicapas -- Base de APIs modernas +## 5.3. Otros protocolos de aplicación + +| Protocolo | Puerto | Función | +|---|---|---| +| **FTP** | 21 (control), 20 (datos) | Transferencia de ficheros | +| **SFTP** | 22 | FTP seguro sobre SSH | +| **SMTP** | 25 / 587 | Envío de correo electrónico | +| **IMAP** | 143 / 993 | Acceso a buzón de correo (sincronizado) | +| **POP3** | 110 / 995 | Descarga de correo (local) | +| **DNS** | 53 | Resolución de nombres de dominio a IPs | +| **LDAP** | 389 / 636 | Directorio de usuarios (Active Directory) | +| **SSH** | 22 | Acceso remoto seguro a servidores | --- -**Trampas típicas de examen** -- WS no es solo SOAP → REST también es Web Service -- SOAP = protocolo -- REST = estilo arquitectónico (no protocolo) -- JSON → típico de REST -- XML → típico de SOAP +# Miniresumen final del tema ---- - -**Resumen rápido** -- WS = comunicación entre aplicaciones -- SOAP (XML, pesado, formal) -- REST (JSON, ligero, actual) - ---- - -### 2.6 Protocolos asociados - -**HTTP / HTTPS** -- Protocolo principal de la web -- Modelo petición/respuesta -- HTTPS añade seguridad mediante cifrado - -**TCP/IP** -- Base de las comunicaciones en red -- TCP: transmisión fiable -- IP: direccionamiento - -**SSL/TLS** -- Protocolos de seguridad -- Proporcionan cifrado - -**Otros protocolos** -- FTP: transferencia de archivos -- SMTP: envío de correo -- DNS: resolución de nombres - ---- - -## 3. Ejemplo práctico - -Aplicación web: - -- Cliente: navegador -- Presentación: HTML, CSS, JavaScript -- Lógica: servidor de aplicaciones -- Datos: base de datos - -Flujo: -1. Usuario realiza una acción -2. Se envía una petición HTTP -3. El servidor procesa la lógica -4. Consulta la base de datos -5. Devuelve la respuesta - ---- - -## 4. Miniresumen - -- Cliente/servidor: el cliente solicita y el servidor responde -- Multicapas: separación en presentación, lógica y datos -- Ventajas: modularidad, mantenimiento y escalabilidad -- Servicios web: comunicación entre aplicaciones -- REST es el modelo más utilizado actualmente -- Protocolos clave: HTTP/HTTPS, TCP/IP, SSL/TLS \ No newline at end of file +| Concepto | Clave | +|---|---| +| **Cliente/servidor** | Cliente solicita, servidor responde; comunicación por red | +| **Cliente pesado** | Lógica en el cliente | +| **Cliente ligero** | Lógica en el servidor; ej. navegador | +| **Multicapas (3 capas)** | Presentación + lógica de negocio + datos | +| **Comunicación síncrona** | Bloqueante; modelo HTTP clásico | +| **Comunicación asíncrona** | No bloqueante; colas JMS, RabbitMQ, Kafka | +| **SOAP** | Protocolo; XML; WSDL; formal; empresarial | +| **REST** | Estilo arquitectónico; JSON; verbos HTTP; stateless | +| **GraphQL** | Cliente define los campos que necesita; Meta | +| **gRPC** | RPC binario (Protobuf); HTTP/2; microservicios | +| **WebSocket** | Bidireccional; tiempo real; conexión persistente | +| **HTTP** | Protocolo web; petición/respuesta; sobre TCP | +| **HTTPS** | HTTP + TLS; cifrado, integridad, autenticación | +| **TLS** | Seguridad del canal; sucesor de SSL | +| **TCP** | Transporte fiable y ordenado | \ No newline at end of file diff --git a/src/main/resources/temas/bloque3/B3T6_audio.md b/src/main/resources/temas/bloque3/B3T6_audio.md index b16af8b..d8a54a9 100644 --- a/src/main/resources/temas/bloque3/B3T6_audio.md +++ b/src/main/resources/temas/bloque3/B3T6_audio.md @@ -6,6 +6,164 @@ Este tema estudia los modelos arquitectónicos de las aplicaciones distribuidas, ## 1. Arquitectura cliente/servidor +### 1.1. Definición y elementos + +La arquitectura cliente/servidor es el modelo fundamental de las aplicaciones distribuidas. En este modelo un cliente solicita servicios o recursos y un servidor los proporciona, comunicándose a través de una red. + +Los tres elementos de esta arquitectura son el cliente, que realiza las peticiones; el servidor, que responde y gestiona los recursos; y la red, que es el medio de comunicación entre ambos. + +Sus características principales son la separación de funciones entre cliente y servidor, la centralización de los recursos en el servidor, la escalabilidad porque se pueden añadir más clientes o servidores sin reestructurar la arquitectura, y la heterogeneidad porque cliente y servidor pueden usar plataformas distintas si se comunican mediante protocolos estándar. + +--- + +### 1.2. Tipos de cliente + +El modelo de dos capas es la forma básica de cliente/servidor. A partir de ahí se distinguen dos tipos de cliente. + +El cliente pesado o thick client es aquel en el que la mayor parte de la lógica reside en el cliente. El servidor solo aporta los datos. Un ejemplo es una aplicación de escritorio que se conecta a una base de datos remota. Este modelo requiere instalar y mantener el software en cada equipo cliente. + +El cliente ligero o thin client es aquel en el que casi toda la lógica está en el servidor y el cliente solo gestiona la presentación. El ejemplo más claro es el navegador web junto a un servidor de aplicaciones. Es el modelo más habitual en entornos empresariales actuales porque facilita el mantenimiento centralizado en el servidor. El cliente mixto reparte la lógica entre cliente y servidor, como ocurre en las SPA que combinan Angular o React con una API REST. + +En resumen: en el modelo cliente/servidor el cliente solicita y el servidor responde. El cliente ligero, cuyo ejemplo es el navegador web, es el más habitual hoy en día. + +--- + +## 2. Arquitectura multicapas (n-tier) + +### 2.1. Capas principales + +La arquitectura multicapas divide la aplicación en capas independientes, cada una con una responsabilidad bien definida. La separación de responsabilidades facilita el mantenimiento, la escalabilidad y la reutilización. + +Las tres capas clásicas son las siguientes. La capa de presentación gestiona la interfaz de usuario y se implementa con tecnologías como HTML, CSS, JavaScript o frameworks como React, Angular o Thymeleaf. La capa de lógica de negocio contiene el procesamiento y las reglas de la aplicación y se implementa con Java EE, Spring o .NET. La capa de datos gestiona la persistencia y el acceso a la base de datos mediante JDBC, JPA u ORM. + +A estas tres capas se pueden añadir otras opcionales: la capa de servicios expone la funcionalidad como servicios web REST o SOAP; la capa de integración adapta la comunicación con sistemas externos; y el middleware actúa como intermediario entre capas, como un bus de mensajes o un ESB. + +Las ventajas son la modularidad, porque cada capa puede desarrollarse de forma independiente; el mantenimiento, porque los cambios en una capa no afectan a las demás si se respeta el contrato entre ellas; la escalabilidad, porque se puede escalar cada capa por separado; y la seguridad, porque las capas actúan como barreras entre el exterior y los datos. + +--- + +### 2.2. Relación con cliente/servidor + +Cliente/servidor y multicapas no son excluyentes. Un sistema puede ser cliente/servidor, con dos extremos que se comunican, y a la vez estar organizado internamente en múltiples capas. + +La diferencia clave es el alcance: cliente/servidor es un modelo general que describe la interacción entre dos extremos; la arquitectura multicapas define la organización interna de la aplicación. Un navegador web actúa como cliente ligero; el back-end que le responde puede estar organizado en tres o más capas internas. + +En resumen: la arquitectura multicapas organiza la aplicación en tres capas fundamentales: presentación, lógica de negocio y datos. Se complementa con cliente/servidor porque define la estructura interna del servidor. + +--- + +## 3. Comunicación síncrona y asíncrona + +### 3.1. Comunicación síncrona + +En la comunicación síncrona el cliente envía una petición y queda bloqueado hasta recibir la respuesta del servidor. Es el modelo clásico de HTTP: un navegador solicita una página web y espera hasta que el servidor la devuelve completa. La ejecución del cliente no continúa hasta haber recibido la respuesta. + +Sus ventajas son la simplicidad y la facilidad para implementar y depurar. Su principal inconveniente es el bloqueo: si la respuesta tarda, el cliente no puede hacer nada más. Esto reduce el rendimiento en sistemas con alta concurrencia o respuestas lentas. + +--- + +### 3.2. Comunicación asíncrona y colas de mensajes + +En la comunicación asíncrona el cliente envía una petición y no bloquea: puede seguir ejecutando otras tareas mientras la respuesta llega posteriormente mediante un callback, un evento o una cola de mensajes. + +Su ventaja es la mayor escalabilidad y rendimiento porque el sistema no se detiene a esperar. Su inconveniente es la mayor complejidad para gestionar el estado y coordinar los resultados. + +Los sistemas de colas de mensajes, también llamados MOM o Message-Oriented Middleware, son la tecnología principal para la comunicación asíncrona. JMS es la API estándar de Jakarta EE para mensajería asíncrona. RabbitMQ es un broker de mensajes que soporta el protocolo AMQP. Apache Kafka es una plataforma de streaming de eventos de alto rendimiento muy usada en microservicios. + +Los patrones de mensajería más comunes son dos. En el patrón punto a punto o queue, un productor envía mensajes a una cola y un único consumidor los lee. En el patrón publicación y suscripción o topic, un productor publica en un topic y todos los consumidores suscritos reciben el mensaje. + +La clave para el examen es que HTTP es síncrono; las arquitecturas de microservicios y sistemas distribuidos modernos combinan síncrono y asíncrono; y la asincronía es fundamental para la escalabilidad. + +--- + +## 4. Servicios web + +### 4.1. SOAP + +SOAP, que son las siglas de Simple Object Access Protocol, es un protocolo de comunicación entre aplicaciones basado en XML. Es el modelo clásico de servicios web empresariales. + +SOAP se compone de varios elementos. El propio protocolo SOAP define el formato de los mensajes en XML. WSDL, o Web Services Description Language, es el lenguaje que describe la interfaz del servicio: sus operaciones, parámetros y tipos de datos. Es el contrato formal del servicio. UDDI, o Universal Description Discovery and Integration, es un registro para publicar y descubrir servicios web. WS-Security es la extensión que añade seguridad a nivel de mensaje: cifrado, firma digital y autenticación. + +La estructura de un mensaje SOAP tiene cuatro partes: el Envelope es el elemento raíz obligatorio que envuelve todo el mensaje; el Header contiene cabeceras opcionales para seguridad o transacciones; el Body contiene el contenido real de la petición o la respuesta; y el Fault proporciona información de error cuando algo falla. + +Sus características son que es un protocolo formal y estricto, es independiente del transporte porque puede viajar sobre HTTP, SMTP o TCP, y soporta transacciones distribuidas y seguridad a nivel de mensaje. Es adecuado para integraciones entre empresas y entornos que requieren contratos formales y auditoría. + +--- + +### 4.2. REST + +REST, que son las siglas de Representational State Transfer, es un estilo arquitectónico, no un protocolo. Lo definió Roy Fielding en su tesis doctoral del año 2000. Una API que cumple los principios REST se denomina RESTful. + +Los principios REST son los siguientes. El principio sin estado o stateless establece que cada petición contiene toda la información necesaria y el servidor no guarda estado de sesión entre peticiones. La interfaz uniforme define que los recursos se identifican por URI y se intercambian mediante representaciones estándar como JSON o XML. El sistema en capas significa que el cliente no sabe si hay intermediarios entre él y el servidor. La caché indica que las respuestas pueden marcarse como cacheables para mejorar el rendimiento. La separación cliente/servidor establece una separación clara entre ambos extremos. + +Los verbos HTTP en REST se corresponden con las operaciones CRUD: GET para leer un recurso, POST para crearlo, PUT para reemplazarlo completamente, PATCH para modificarlo parcialmente y DELETE para eliminarlo. + +Los códigos de estado HTTP se agrupan en rangos. Los códigos 2xx indican éxito: 200 OK, 201 Created para una creación exitosa, 204 No Content cuando no hay cuerpo de respuesta. Los códigos 3xx indican redirección. Los códigos 4xx indican errores del cliente: 400 Bad Request, 401 Unauthorized cuando no hay credenciales, 403 Forbidden cuando las credenciales no tienen permiso, 404 Not Found. Los códigos 5xx indican errores del servidor: 500 Internal Server Error, 503 Service Unavailable. + +Las diferencias clave entre SOAP y REST para el examen son las siguientes: SOAP es un protocolo y REST es un estilo arquitectónico; SOAP usa XML obligatoriamente y REST usa principalmente JSON; SOAP tiene un contrato formal en WSDL y REST se documenta opcionalmente con OpenAPI o Swagger; SOAP puede viajar sobre distintos transportes y REST usa HTTP; y SOAP se usa en entornos empresariales y legados mientras que REST es el estándar en APIs modernas y microservicios. + +--- + +### 4.3. Otras arquitecturas de servicios + +GraphQL fue desarrollado por Meta en 2015 y es un lenguaje de consulta para APIs. Su característica diferencial es que el cliente especifica exactamente qué campos necesita en la respuesta, lo que evita el overfetching, que es recibir más datos de los necesarios, y el underfetching, que es necesitar múltiples llamadas para obtener todos los datos. Usa un único endpoint URL y las consultas se envían en el cuerpo de la petición. + +gRPC fue desarrollado por Google y usa el protocolo HTTP/2 y el formato binario Protocol Buffers, también llamado Protobuf, como formato de serialización. Es muy eficiente y de baja latencia, lo que lo hace adecuado para la comunicación interna entre microservicios. Los contratos se definen en ficheros con extensión proto. Admite streaming bidireccional. + +WebSocket es un protocolo que establece una conexión persistente y bidireccional entre cliente y servidor sobre TCP. A diferencia de HTTP, que es sin estado y sigue el modelo petición y respuesta, la conexión WebSocket se mantiene abierta y tanto cliente como servidor pueden enviar mensajes en cualquier momento. Sus usos típicos son el chat en tiempo real, las notificaciones push, los juegos online y los dashboards con datos en vivo. + +En resumen: SOAP es el protocolo clásico con XML y WSDL. REST es el estilo arquitectónico moderno con JSON y verbos HTTP. GraphQL da control al cliente sobre los datos que recibe. gRPC es eficiente y binario para microservicios. WebSocket proporciona comunicación bidireccional en tiempo real. + +--- + +## 5. Protocolos asociados + +### 5.1. HTTP/HTTPS + +HTTP, o HyperText Transfer Protocol, es el protocolo de la capa de aplicación que define cómo se comunican cliente y servidor en la web. Opera sobre TCP. Ha evolucionado en tres versiones principales. + +HTTP 1.1 introdujo las conexiones persistentes que evitan abrir una nueva conexión TCP por cada recurso, y el pipeline para enviar múltiples peticiones seguidas. Las cabeceras se transmiten en texto plano. + +HTTP 2 introdujo la multiplexación de streams, que permite enviar múltiples peticiones y respuestas en paralelo por la misma conexión TCP sin bloqueos. Las cabeceras se comprimen con el algoritmo HPACK, lo que reduce el tráfico significativamente. + +HTTP 3 se basa en el protocolo QUIC que funciona sobre UDP en lugar de TCP. Esto reduce la latencia y acelera el establecimiento de conexiones porque combina el handshake TCP y el handshake TLS en un único paso. + +Las cabeceras HTTP más relevantes son Content-Type para el tipo MIME del cuerpo de la respuesta, Authorization para las credenciales del cliente, Cache-Control para las directivas de caché, y Cookie y Set-Cookie para la gestión de sesiones. + +HTTPS es HTTP con cifrado TLS. Garantiza tres propiedades: la confidencialidad mediante el cifrado de los datos en tránsito, la integridad para detectar cualquier manipulación del mensaje, y la autenticación del servidor mediante su certificado digital. + +--- + +### 5.2. TCP/IP y SSL/TLS + +TCP/IP es el conjunto de protocolos base de internet. IP se encarga del direccionamiento y el enrutamiento de paquetes en la capa de red. TCP garantiza la transmisión fiable, ordenada y orientada a conexión en la capa de transporte mediante el mecanismo three-way handshake: el cliente envía SYN, el servidor responde SYN-ACK y el cliente confirma con ACK. Si se pierde un paquete TCP lo retransmite. UDP es el protocolo alternativo de transporte, no fiable pero más rápido y sin conexión, usado por DNS y servicios de streaming. + +TLS, o Transport Layer Security, es el protocolo que proporciona seguridad en el canal de comunicación. Garantiza la confidencialidad mediante cifrado asimétrico para el intercambio de claves y simétrico para el flujo de datos; la integridad mediante un código de autenticación de mensaje; y la autenticación mediante certificados digitales X.509 firmados por una Autoridad Certificadora. TLS 1.2 y TLS 1.3 son las versiones actuales. SSL está obsoleto y no debe usarse. + +--- + +### 5.3. Otros protocolos de aplicación + +Los protocolos de aplicación más relevantes para el examen son los siguientes. FTP o File Transfer Protocol usa el puerto 21 para el control y el 20 para los datos, y sirve para la transferencia de ficheros. SFTP es FTP seguro sobre SSH en el puerto 22. SMTP usa el puerto 25 o 587 y es el protocolo para el envío de correo electrónico. IMAP usa el puerto 143 o 993 cifrado y permite acceder al buzón de correo de forma sincronizada, manteniendo los mensajes en el servidor. POP3 usa el puerto 110 y descarga los mensajes al cliente local. DNS usa el puerto 53 y resuelve los nombres de dominio en direcciones IP. LDAP usa el puerto 389 o 636 cifrado y da acceso a directorios de usuarios como Active Directory. SSH usa el puerto 22 y proporciona acceso remoto seguro a servidores. + +En resumen: HTTP es el protocolo de la web, opera sobre TCP y HTTPS añade TLS para cifrado e integridad. TCP garantiza la entrega fiable y UDP es más rápido pero sin garantías. TLS reemplaza a SSL. Los puertos más importantes para el examen son 80 HTTP, 443 HTTPS, 21 FTP, 22 SSH, 25 SMTP, 53 DNS. + +--- + +## Miniresumen final del tema + +Este tema cubre los fundamentos de las arquitecturas distribuidas. La arquitectura cliente/servidor separa el cliente que solicita del servidor que responde, comunicándose por red. El cliente ligero, cuyo ejemplo es el navegador web, es el modelo más habitual hoy en día. La arquitectura multicapas organiza la aplicación en tres capas: presentación, lógica de negocio y datos. Ambos modelos son complementarios. + +La comunicación puede ser síncrona, en la que el cliente bloquea y espera como en HTTP clásico, o asíncrona, en la que el cliente no bloquea y la respuesta llega mediante colas como JMS, RabbitMQ o Kafka con los patrones queue y topic. + +En cuanto a los servicios web, SOAP es un protocolo formal que usa XML y WSDL; REST es un estilo arquitectónico que usa JSON y verbos HTTP; GraphQL permite al cliente definir los campos que necesita; gRPC usa Protobuf y HTTP/2 para comunicación eficiente entre microservicios; y WebSocket proporciona comunicación bidireccional en tiempo real. La diferencia clave para el examen es que REST es un estilo arquitectónico, no un protocolo. + +Los protocolos principales son HTTP sobre TCP en el puerto 80, HTTPS con TLS en el puerto 443, TCP para transporte fiable, TLS como sucesor de SSL para cifrado, y DNS en el puerto 53 para resolución de nombres. + +--- + +## 1. Arquitectura cliente/servidor + La arquitectura cliente/servidor es el modelo fundamental de las aplicaciones distribuidas. En este modelo un cliente solicita servicios y un servidor los proporciona, comunicándose a través de una red. Los elementos de esta arquitectura son tres: el cliente, que realiza las peticiones; el servidor, que responde y gestiona los recursos; y la red, que es el medio de comunicación entre ellos. diff --git a/src/main/resources/temas/bloque3/B3T7.md b/src/main/resources/temas/bloque3/B3T7.md index 6c5185b..945dfad 100644 --- a/src/main/resources/temas/bloque3/B3T7.md +++ b/src/main/resources/temas/bloque3/B3T7.md @@ -1,5 +1,9 @@ # Bloque 3. Tema 7. # Aplicaciones web +# Desarrollo web front-end y en servidor, multiplataforma y multidispositivo. +# Lenguajes: HTML, XML y sus derivaciones. +# Navegadores y lenguajes de programación web. +# Lenguajes de script. ## 1. Concepto de aplicación web From 4fbcee2f668d74d67a38c14f30545515feca0aca Mon Sep 17 00:00:00 2001 From: Tatiana Villa Date: Thu, 14 May 2026 12:16:48 +0200 Subject: [PATCH 4/5] Actualizacion de temario y audios --- src/main/resources/temas/bloque3/B3T7.md | 479 ++++++++++++------ .../resources/temas/bloque3/B3T7_audio.md | 166 ++++-- 2 files changed, 455 insertions(+), 190 deletions(-) diff --git a/src/main/resources/temas/bloque3/B3T7.md b/src/main/resources/temas/bloque3/B3T7.md index 945dfad..b80f73d 100644 --- a/src/main/resources/temas/bloque3/B3T7.md +++ b/src/main/resources/temas/bloque3/B3T7.md @@ -1,242 +1,399 @@ -# Bloque 3. Tema 7. -# Aplicaciones web -# Desarrollo web front-end y en servidor, multiplataforma y multidispositivo. -# Lenguajes: HTML, XML y sus derivaciones. -# Navegadores y lenguajes de programación web. -# Lenguajes de script. - -## 1. Concepto de aplicación web - -Una aplicación web es un software accesible mediante un navegador, que se ejecuta en Internet o en una intranet. - -### Características -- No requiere instalación en el equipo del usuario. -- Acceso mediante navegador web. -- Actualización centralizada en el servidor. -- Compatible con múltiples sistemas operativos. -- Arquitectura cliente/servidor. +# Bloque 3 · Tema 7 +# Aplicaciones web. Desarrollo web front-end y en servidor. HTML, XML y derivaciones. Navegadores. Lenguajes de script. Validación de datos. --- -## 2. Desarrollo web front-end +# Esquema resumen -El desarrollo front-end es la parte de la aplicación que se ejecuta en el navegador del usuario. +**Tecnologías front-end** -### Tecnologías principales -- HTML: estructura del contenido. -- CSS: presentación y diseño. -- JavaScript: comportamiento e interactividad. +| Tecnología | Función | +|---|---| +| **HTML** | Estructura del contenido; etiquetas semánticas | +| **CSS** | Presentación y diseño; diseño responsivo | +| **JavaScript** | Comportamiento e interactividad | +| **TypeScript** | Superset tipado de JavaScript | +| **AJAX** | Peticiones asíncronas sin recargar la página | +| **WebSocket** | Comunicación bidireccional en tiempo real | -### Funciones del front-end -- Mostrar información al usuario. -- Gestionar la interacción. -- Validación básica de formularios. -- Adaptación a distintos dispositivos. +**Lenguajes de marcado** + +| Lenguaje | Propósito | Clave | +|---|---|---| +| **HTML5** | Estructura de páginas web | Semántica; etiquetas header, nav, article, footer | +| **XML** | Intercambio y almacenamiento de datos | Extensible; jerárquico; sin presentación | +| **XHTML** | HTML basado en XML | Más estricto que HTML | +| **SVG** | Gráficos vectoriales escalables | Derivación de XML | +| **JSON** | Intercambio de datos ligero | No XML; basado en objetos JS | + +**Back-end: lenguajes y frameworks** + +| Lenguaje | Frameworks / Entorno | +|---|---| +| Java | Jakarta EE, Spring Boot | +| C# | ASP.NET Core | +| PHP | Laravel, Symfony | +| Python | Django, Flask, FastAPI | +| JavaScript | Node.js, Express | + +**Navegadores y motores** + +| Navegador | Motor renderizado | Motor JS | +|---|---|---| +| Chrome / Edge | Blink | V8 | +| Firefox | Gecko | SpiderMonkey | +| Safari | WebKit | JavaScriptCore | --- -## 3. Desarrollo web en servidor (back-end) +# 1. Concepto de aplicación web -El back-end es la parte que se ejecuta en el servidor. +## 1.1. Definición y características -### Funciones principales -- Procesamiento de peticiones. -- Gestión de bases de datos. -- Lógica de negocio. -- Generación de respuestas (HTML, JSON, XML). +Una aplicación web es un software accesible mediante un navegador que se ejecuta en Internet o en una intranet corporativa. Sus características principales son: -### Lenguajes habituales -- Java (Jakarta EE) -- C# (.NET) -- PHP -- Python -- JavaScript (Node.js) +- **Sin instalación**: el usuario accede solo con un navegador. +- **Actualización centralizada**: los cambios se despliegan en el servidor y llegan a todos los usuarios inmediatamente. +- **Multiplataforma y multidispositivo**: funciona en cualquier SO y dispositivo que tenga navegador. +- **Arquitectura cliente/servidor**: el navegador es el cliente y el servidor gestiona la lógica y los datos. +- **Escalabilidad**: se puede escalar el servidor sin modificar los clientes. --- -## 4. Lenguajes de marcado +## 1.2. Tipos de aplicaciones web -### 4.1 HTML -HTML (HyperText Markup Language) es el lenguaje estándar para crear páginas web. - -### Características -- Define la estructura del contenido. -- Utiliza etiquetas. -- Es interpretado por el navegador. - -### Ejemplo -

Título

-

Párrafo de ejemplo

+| Tipo | Descripción | Ejemplo | +|---|---|---| +| **MPA** (Multi-Page Application) | El servidor genera una página completa en cada petición | Aplicaciones con Thymeleaf, JSP, PHP | +| **SPA** (Single-Page Application) | Se carga una única página; el contenido se actualiza sin recarga completa | Angular, React, Vue | +| **PWA** (Progressive Web App) | SPA con capacidades offline y notificaciones push | Google Maps, Twitter Lite | +| **SSR** (Server-Side Rendering) | La página inicial se renderiza en el servidor para SEO y rendimiento | Next.js, Nuxt.js | --- -### 4.2 XML -XML (eXtensible Markup Language) es un lenguaje de marcado para almacenar e intercambiar datos. +--- -### Características -- Estructura jerárquica. -- No define presentación. -- Es extensible. +# 2. Desarrollo web front-end -### Ejemplo - - Tatiana - 54 - +## 2.1. HTML5 + +**HTML** (HyperText Markup Language) es el lenguaje estándar para definir la **estructura** del contenido de una página web. HTML5 es la versión actual e introduce mejoras importantes: + +**Etiquetas semánticas** (HTML5): + +| Etiqueta | Significado | +|---|---| +| `
` | Cabecera del documento o sección | +| `

Planning de repaso TAI

-

Mayo 2026 · Examen: sábado 23 de mayo

+

Mayo 2026 · Examen: sábado 23 de mayo + +

@@ -179,5 +181,6 @@
Fin de semana
+ \ No newline at end of file