Lectura pública del tema
1. Arquitectura de sistemas cliente/servidor y multicapas: componentes y operación
1. Arquitectura de sistemas cliente/servidor y multicapas: componentes y operación
🎯 Idea clave
- La arquitectura cliente/servidor es un modelo de computación distribuida donde los clientes actúan como demandantes de servicios y los servidores como proveedores mediante el intercambio de mensajes a través de una red.
- El cliente inicia la comunicación presentando la interfaz, recogiendo datos y enviando peticiones, mientras que el servidor atiende estas solicitudes ejecutando la lógica y accediendo a recursos.
- La arquitectura multicapa o n-tier supone una evolución del modelo clásico que descompone el sistema en niveles específicos para presentación, lógica de negocio y acceso a datos.
- Esta separación de responsabilidades entre capas proporciona mayor capacidad para escalar, mantener y evolucionar las aplicaciones a lo largo del tiempo.
- Una capa lógica no siempre equivale a un servidor físico independiente, aunque permite dimensionar cada nivel según la carga específica que soporta.
- La operación del sistema incluye el ciclo de petición-respuesta, autenticación, autorización, validación y la coordinación de transacciones entre los diferentes niveles.
📚 Desarrollo
Definición del paradigma. La arquitectura cliente/servidor constituye un modelo de organización de sistemas distribuidos en el que uno o varios clientes solicitan servicios y uno o varios servidores los proporcionan. Esta separación funciona como la base de la computación moderna, permitiendo distribuir responsabilidades entre diferentes equipos, procesos y redes conectadas.
Funciones del cliente. El cliente inicia normalmente la comunicación y desempeña funciones de presentación de la interfaz, recogida de datos, envío de peticiones y recepción de respuestas. El concepto de cliente es amplio y no se limita a aplicaciones web, pudiendo tratarse de navegadores, aplicaciones móviles, programas de escritorio, terminales, otros servidores, procesos automáticos o clientes de API.
Funciones del servidor. El servidor atiende las peticiones recibidas, ejecuta la lógica de negocio necesaria, accede a recursos, coordina datos y devuelve resultados al solicitante. Puede adoptar diversas formas como servidor web, de aplicaciones, de base de datos, de autenticación, de ficheros, broker de mensajería o servicio especializado, siendo la relación funcional lo esencial: un componente consumidor solicita una capacidad y otro componente la ofrece mediante una interfaz definida.
Evolución hacia multicapa. El modelo multicapa, también conocido como arquitectura n-tier, representa una evolución natural del cliente/servidor clásico. Mientras que la arquitectura de dos capas concentra la lógica y puede exponer excesivamente la base de datos, la arquitectura de tres capas separa claramente la presentación, la lógica de aplicación o negocio, y los datos, aunque una capa lógica no siempre implique un servidor físico distinto.
Responsabilidades por capas. La capa de presentación debe limitarse a la interfaz de usuario sin concentrar reglas de negocio ni acceder directamente a datos. La capa de negocio coordina los casos de uso, reglas, validaciones y transacciones. La capa de datos gestiona la persistencia y el acceso a la información almacenada. Esta distribución permite que cada nivel evolucione y escale de forma independiente según sus necesidades específicas.
Proceso operativo. La operación incluye el ciclo completo de petición-respuesta, incorporando mecanismos de autenticación, autorización, validación de entradas, acceso a datos y formulación de la respuesta. La escalabilidad mejora cuando se puede dimensionar cada capa individualmente según su carga, mientras que la disponibilidad requiere evitar puntos únicos de fallo y probar los mecanismos de recuperación ante incidentes.
Seguridad y observabilidad. La seguridad exige defensa en profundidad y el principio de no confiar en el cliente, implementando controles en todas las capas. La observabilidad resulta imprescindible para diagnosticar fallos entre los diferentes niveles del sistema distribuido. Aunque las arquitecturas multicapa aportan orden y capacidad de escalado, también introducen complejidad adicional que debe gestionarse adecuadamente.
🧩 Elementos esenciales
- Cliente: Componente demandante de servicios que inicia la comunicación, presenta la interfaz y puede adoptar la forma de navegador, aplicación móvil, escritorio, terminal, otro servidor o proceso automático.
- Servidor: Componente proveedor que atiende peticiones, ejecuta lógica, accede a recursos y coordina datos, pudiendo ser web, de aplicaciones, de base de datos, de autenticación, de ficheros o especializado.
- Arquitectura de dos capas: Modelo más simple donde cliente y servidor interactúan directamente, pero que puede concentrar excesiva lógica y exponer la base de datos.
- Arquitectura de tres capas: Separación clara entre presentación, lógica de negocio y datos que mejora la organización del sistema.
- Capa de presentación: Nivel encargado de la interfaz de usuario que no debe contener reglas de negocio ni realizar accesos directos a la base de datos.
- Capa de negocio: Nivel intermedio que coordina casos de uso, reglas, validaciones y transacciones entre la presentación y los datos.
- Capa de datos: Nivel encargado de la gestión de la persistencia y el acceso a la información almacenada.
- Escalabilidad: Capacidad de dimensionar cada capa de forma independiente según la carga específica que soporta, optimizando recursos.
- Disponibilidad: Requisito que obliga a evitar puntos únicos de fallo y a probar los mecanismos de recuperación ante incidentes.
- Defensa en profundidad: Estrategia de seguridad que implica no confiar en el cliente y proteger cada nivel de la arquitectura.
🧠 Recuerda
- El cliente siempre inicia la comunicación en el modelo cliente/servidor.
- Un cliente puede ser cualquier consumidor de servicios, desde un navegador hasta otro servidor o proceso automático.
- La separación en capas mejora el mantenimiento y la escalabilidad, pero aumenta la complejidad operativa.
- La capa de presentación debe limitarse a la interfaz, sin incluir lógica de negocio ni consultas directas a base de datos.
- Una capa lógica no necesita corresponderse necesariamente con un servidor físico independiente.
- La observabilidad es crucial para diagnosticar fallos en sistemas distribuidos entre múltiples capas.
- La seguridad requiere validaciones en todas las capas, no solo en el lado del cliente.
- La arquitectura multicapa permite escalar horizontalmente los niveles que soportan mayor carga.
- El servidor ejecuta la lógica y coordina el acceso a recursos, independientemente de su implementación específica.
- La relación funcional entre consumidor y proveedor mediante interfaz definida es el núcleo del modelo.
2. Arquitecturas de servicios web y protocolos asociados
2. Arquitecturas de servicios web y protocolos asociados
🎯 Idea clave
- Un servicio web es una capacidad software accesible mediante interfaces estandarizadas sobre HTTP o HTTPS que permite la comunicación entre aplicaciones heterogéneas.
- HTTP define la base protocolaria con métodos, códigos de estado y semántica de mensajes para la interacción cliente-servidor.
- REST es un estilo arquitectónico que organiza recursos mediante URIs y utiliza los verbos HTTP con su semántica correspondiente.
- SOAP constituye un protocolo de mensajería XML formal definido por W3C que emplea contratos WSDL y extensiones WS-* para seguridad y fiabilidad.
- Las APIs modernas utilizan frecuentemente JSON por su ligereza, mientras que XML permanece en entornos SOAP y validaciones formales.
- La seguridad en servicios web requiere HTTPS, autenticación, autorización y mecanismos como OAuth 2.0 y OpenID Connect.
📚 Desarrollo
Definición operativa. Un servicio web es una porción funcional de software expuesta a través de un protocolo estándar de red, habitualmente HTTP, mediante un contrato que describe operaciones, datos de entrada y salida. Esta definición posibilita que sistemas heterogéneos, escritos en lenguajes distintos y ejecutados sobre diferentes plataformas, intercambien información sin compartir código ni infraestructura.
Interoperabilidad administrativa. En el ámbito de la Administración Pública, el paradigma de servicios web adquiere rango normativo mediante las Normas Técnicas de Interoperabilidad. La Plataforma de Intermediación de Datos articula la consulta entre administraciones utilizando estos servicios para integrar portales, sedes electrónicas, sistemas de identidad y registros.
Protocolo HTTP. HTTP y HTTPS constituyen la base más habitual de los servicios web actuales. El protocolo define métodos como GET, POST, PUT, PATCH, DELETE, HEAD y OPTIONS, cada uno con propiedades de idempotencia y seguridad específicas. Los códigos de estado se organizan en familias: 2xx para éxito, 3xx para redirecciones, 4xx para errores del cliente y 5xx para errores del servidor.
Arquitectura REST. REST es un estilo arquitectónico definido por Roy Fielding en 2000 que impone seis restricciones: cliente-servidor, stateless, cacheable, interfaz uniforme, sistema en capas y código bajo demanda opcional. Una API RESTful organiza recursos mediante URIs y emplea los métodos HTTP según su semántica específica, siendo JSON el formato más extendido aunque también puede utilizarse XML.
Protocolo SOAP. SOAP es un protocolo de mensajería basado en XML definido por W3C, con versión 1.2 publicada en 2003. Su estructura incluye un Envelope compuesto por Header y Body, permitiendo extensiones para seguridad y fiabilidad. Se describe mediante contratos WSDL y ha sido ampliamente utilizado en integraciones empresariales formales donde se requieren contratos estrictos.
Nuevas arquitecturas. Además de REST y SOAP, existen alternativas como GraphQL, que utiliza queries declarativas sobre un schema tipado y un único endpoint POST para evitar over-fetching. gRPC, desarrollado por Google, implementa RPC sobre HTTP/2 con Protocol Buffers, soportando streaming unario y bidireccional ideal para microservicios. WebSocket ofrece comunicación full-duplex sobre TCP según RFC 6455, mientras que la mensajería asíncrona emplea AMQP, Apache Kafka o MQTT para IoT.
🧩 Elementos esenciales
- Servicio web: aplicación accesible por protocolo estándar de red con contrato bien definido que habilita interoperabilidad entre sistemas heterogéneos.
- REST: estilo arquitectónico con seis restricciones que utiliza URIs para recursos y métodos HTTP con semántica específica.
- SOAP: protocolo XML W3C basado en mensajes con estructura Envelope, descrito por WSDL y extensible mediante WS-Security, WS-Addressing y WS-ReliableMessaging.
- HTTP: protocolo base que define verbos, códigos de estado por familias y semántica de mensajes para la comunicación.
- JSON: formato ligero y legible predominante en APIs modernas frente a XML que se mantiene en SOAP y documentos estructurados.
- GraphQL: lenguaje de consulta declarativa con schema tipado y único endpoint que evita la sobrecarga de datos.
- gRPC: framework RPC sobre HTTP/2 que utiliza Protocol Buffers y soporta streaming unario y bidireccional entre microservicios.
- WebSocket: protocolo full-duplex sobre TCP definido en RFC 6455 para comunicación bidireccional persistente.
- Mensajería asíncrona: patrones de comunicación mediante AMQP, Apache Kafka, MQTT y similares para desacoplar sistemas.
- OpenAPI: especificación para describir contratos de APIs HTTP en JSON o YAML, anteriormente conocida como Swagger.
- Seguridad: HTTPS protege la comunicación pero no sustituye mecanismos de autenticación y autorización como OAuth 2.0 y OpenID Connect.
- Idempotencia: propiedad de ciertos métodos HTTP que permite reintentar operaciones de forma segura sin efectos secundarios adicionales.
🧠 Recuerda
- REST es un estilo arquitectónico, no un protocolo estándar.
- SOAP utiliza XML obligatoriamente mientras que REST puede emplear JSON o XML.
- HTTPS cifra la comunicación pero requiere complementarse con autenticación y autorización.
- GET es seguro e idempotente; POST no es idempotente; PUT y DELETE son idempotentes.
- Los códigos 2xx indican éxito, 4xx errores del cliente y 5xx errores del servidor.
- OpenAPI documenta APIs REST mientras que WSDL describe servicios SOAP.
- GraphQL utiliza un único endpoint POST y schema tipado.
- gRPC está optimizado para comunicación entre microservicios mediante HTTP/2.
- La mensajería asíncrona desacopla emisores y receptores mediante brokers o logs distribuidos.
- El versionado de APIs evita romper clientes existentes cuando evoluciona el contrato.
- La observabilidad, documentación y gobernanza son esenciales para operar servicios web en producción.