# Bloque 3 · Tema 6
# Arquitectura cliente/servidor y multicapas. Servicios web y protocolos.

---

# Esquema resumen

**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 |

---

# 1. Arquitectura cliente/servidor

## 1.1. Definición y elementos

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**.

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.

---

## 1.2. Tipos de cliente

| 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 |

Los clientes ligeros son los más habituales en entornos empresariales actuales porque facilitan el mantenimiento centralizado.

---

# 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.

**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.2. Relación con cliente/servidor

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.

| Concepto | Alcance |
|---|---|
| **Cliente/servidor** | Modelo general de comunicación entre dos extremos |
| **Multicapas** | Organización interna de la aplicación |

Un navegador web actúa de cliente; el back-end (organizado en 3 capas) actúa de 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.

| 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 |

---

## 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.

---

# 4. Servicios web

## 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.

---

## 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 |

---

## 4.3. Otras arquitecturas de servicios

**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.

---

# 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).

---

## 5.2. TCP/IP y SSL/TLS

**TCP/IP** es el conjunto de protocolos base de internet. Corresponde a las capas 3 y 4 del modelo OSI.

| 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.

---

## 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 |

---

# Miniresumen final del tema

| 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 |