22 KiB
Bloque 3 Tema 6. Arquitectura cliente/servidor y multicapas. Servicios web y protocolos.
Este tema estudia los modelos arquitectónicos de las aplicaciones distribuidas, los servicios web y los protocolos de comunicación asociados.
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.
Las características principales son la separación de funciones entre cliente y servidor, la centralización de los recursos en el servidor, la escalabilidad y la comunicación a través de la red.
El modelo de dos capas es la forma básica. En el cliente pesado o thick client la mayor parte de la lógica reside en el cliente, que solo accede al servidor para los datos. En el cliente ligero o thin client casi toda la lógica está en el servidor y el cliente solo gestiona la presentación; un navegador web es el ejemplo más claro.
2. Arquitectura multicapas
La arquitectura multicapas o n-tier divide la aplicación en capas independientes, cada una con una responsabilidad específica. La separación de responsabilidades facilita el mantenimiento, la escalabilidad y la reutilización.
Las tres capas principales son las siguientes. La capa de presentación gestiona la interfaz de usuario. La capa de lógica de negocio contiene el procesamiento y las reglas de la aplicación. La capa de datos gestiona el acceso a la base de datos.
Se pueden añadir capas adicionales como la capa de servicios para la lógica de integración o la capa de middleware para intermediar entre componentes.
La relación entre ambos modelos es la siguiente: cliente/servidor es un modelo general que describe la interacción entre dos extremos; la arquitectura multicapas define la estructura interna de la aplicación. Un sistema puede ser cliente/servidor y además estar organizado en múltiples capas.
Los componentes en una arquitectura multicapas son el front-end en la capa de presentación, el back-end en la capa de lógica, la base de datos en la capa de datos y el middleware como elemento intermediario opcional.
3. Comunicación síncrona y asíncrona
La comunicación síncrona es el modelo clásico de HTTP: el cliente envía una petición y espera bloqueado hasta recibir la respuesta del servidor. Es simple de implementar pero bloquea al cliente durante la espera, lo que reduce el rendimiento en sistemas distribuidos.
La comunicación asíncrona no bloquea al cliente: envía la petición y puede seguir ejecutando otras tareas mientras la respuesta llega posteriormente mediante un callback, una cola de mensajes o un evento. Es más escalable y eficiente en sistemas distribuidos, aunque añade complejidad en la gestión del estado. Los sistemas de mensajería, las notificaciones push y los procesos en segundo plano son ejemplos típicos.
La clave para el examen es que HTTP tradicional es síncrono, mientras que las arquitecturas de microservicios y sistemas distribuidos modernos combinan ambos modelos. La asincronía es fundamental para la escalabilidad.
4. Servicios web
Los servicios web son la tecnología que permite la comunicación entre aplicaciones a través de una red, de forma independiente al lenguaje de programación y al sistema operativo. Sus características son la interoperabilidad, el uso de estándares abiertos y la comunicación a través de HTTP.
Existen dos grandes tipos de servicios web.
SOAP o Simple Object Access Protocol es el modelo clásico de servicios web. Usa XML tanto para los mensajes como para la descripción del servicio mediante WSDL, que es el Web Services Description Language. Es un protocolo formal y estricto. Sus mensajes son más pesados pero están muy bien estandarizados y son adecuados para entornos empresariales con requisitos de seguridad y transaccionalidad.
REST o Representational State Transfer es un estilo arquitectónico, no un protocolo, que usa HTTP directamente con sus métodos GET, POST, PUT y DELETE. Los datos se intercambian principalmente en formato JSON, aunque también se puede usar XML. Es más ligero, flexible y es el estándar en las APIs modernas. Es importante distinguir que REST no es un protocolo sino un estilo o conjunto de principios.
Las diferencias clave para el examen son las siguientes: SOAP es un protocolo y REST es un estilo arquitectónico; SOAP usa XML y REST usa principalmente JSON; SOAP es más pesado y formal y REST es más ligero y actual.
5. Protocolos asociados
HTTP o HyperText Transfer Protocol es el protocolo principal de la web. Sigue el modelo petición y respuesta. HTTPS añade cifrado mediante TLS para garantizar la confidencialidad e integridad de las comunicaciones.
TCP/IP es la base de todas las comunicaciones en red. TCP garantiza la entrega fiable y ordenada de los datos. IP se encarga del direccionamiento y el enrutamiento.
SSL y TLS son los protocolos de seguridad que proporcionan el cifrado. TLS es el sucesor de SSL; SSL está obsoleto.
Otros protocolos relevantes son FTP para la transferencia de ficheros, SMTP para el envío de correo electrónico y DNS para la resolución de nombres de dominio.
Miniresumen final del tema
La arquitectura cliente/servidor separa el cliente que solicita y el servidor que responde. La arquitectura multicapas organiza la aplicación en capa de presentación, capa de lógica de negocio y capa de datos. La comunicación síncrona bloquea al cliente hasta la respuesta; la asíncrona no. Los servicios web SOAP usan XML y WSDL; REST usa HTTP y JSON. Clave de examen: REST es un estilo arquitectónico, no un protocolo. Los protocolos asociados son HTTP, HTTPS, TLS y TCP/IP.