14 KiB

Raw Blame History

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

14 KiB Raw Blame History