Tema 6: Arquitectura cliente/servidor y servicios web

El modelo cliente-servidor

El modelo cliente-servidor es una arquitectura de red en la que un programa (el cliente) solicita servicios o recursos a otro programa (el servidor), que los proporciona desde un sistema centralizado. Su propósito principal es precisamente ese: permitir que los clientes soliciten y reciban servicios de un sistema centralizado, es decir, que un programa solicite servicios o recursos de otro programa. Constituye una estructura de red en la que los clientes solicitan servicios a un servidor central.

La relación se establece habitualmente a través de una red de área local (LAN) o una red de área amplia (WAN), y la comunicación se apoya en protocolos independientes de la plataforma. Por eso los datos pueden transferirse entre clientes y servidores aunque estén basados en distintos sistemas operativos: la transferencia se realiza mediante protocolos cliente-servidor independientes de la plataforma, lo que aumenta la compatibilidad entre diferentes sistemas operativos.

Cliente (front-end) y servidor (back-end)

En esta arquitectura los términos tienen equivalencias fijas que conviene memorizar:

Así, el término cliente se refiere al front-end, y front-end es sinónimo de cliente. La realización de peticiones HTTP pertenece al nivel cliente. El servidor suele materializarse mediante un daemon (en inglés daemon, a veces escrito "daemond"): un proceso en segundo plano que espera solicitudes de clientes y las atiende cuando llegan.

Ventajas: centralización y seguridad

Una de las grandes ventajas del modelo es la arquitectura centralizada, que es precisamente el aspecto que facilita la protección de datos y la implementación de políticas de seguridad: al concentrar los recursos en el servidor, resulta más sencillo aplicar controles, copias de seguridad y políticas homogéneas. No obstante, con el cambio en los patrones de tráfico de red, el enfoque actual en la administración de la seguridad tiende hacia un modelo de seguridad descentralizado centrado en controlar el acceso de usuarios individuales (filosofía próxima al zero trust).

Desventajas: sobrecarga y denegación de servicio

La principal desventaja del modelo cliente-servidor está ligada a la cantidad de solicitudes: el servidor puede sobrecargarse si hay demasiadas solicitudes simultáneas. Un alto número de solicitudes simultáneas puede provocar denegación de servicio, y la sobrecarga del servidor tiene como consecuencia congestión en la red y posibilidad de denegación de servicio (DoS). Este es el punto débil frente a arquitecturas más distribuidas.

Patrones de tráfico: norte-sur

El tráfico norte-sur (north-south) es el patrón en el que clientes remotos solicitan contenido web y los servidores de los centros de datos lo proporcionan; es decir, tráfico que entra y sale del centro de datos hacia los usuarios. Se contrapone al tráfico este-oeste (entre servidores dentro del propio centro de datos).

Sistemas distribuidos

Una característica esencial de los sistemas distribuidos es la escalabilidad: la capacidad computacional y de procesamiento puede escalarse hacia arriba según sea necesario cuando se añaden máquinas adicionales. Esto permite crecer horizontalmente sin rediseñar la aplicación.

La familia TCP/IP: TCP frente a IP

El modelo cliente-servidor se apoya en la pila TCP/IP. Los dos protocolos cumplen funciones complementarias:

• TCP (Transmission Control Protocol) es un protocolo orientado a la conexión. Su función principal consiste en determinar cómo dividir los datos de la aplicación en paquetes y gestionar el control de flujo y la retransmisión de los paquetes descartados o dañados, reordenándolos en destino. Según RFC 9293 (que obsoleta a RFC 793), TCP detecta pérdidas mediante números de secuencia, corrige mediante retransmisión e incorpora control de flujo.

• IP (Internet Protocol) es un protocolo sin conexión (connectionless, RFC 791). Por ello cada paquete se trata como una unidad de datos independiente, sin relación con las demás: IP no mantiene una conexión continua entre los puntos finales, de modo que cada datagrama se encamina por separado.

La diferencia clave, por tanto, es que TCP es orientado a la conexión, mientras que IP es sin conexión.

Sockets

Un socket es un punto final (endpoint) de comunicación entre dos máquinas, definido por la combinación de dirección IP + número de puerto. Es importante no confundir el concepto: un socket NO es simplemente un número de puerto (esta afirmación es incorrecta); el puerto es solo uno de sus componentes.

En Java 7, para implementar un socket cliente se debe importar la clase java.net.Socket (paquete java.net). Según la documentación oficial de Oracle, esta clase implementa los sockets de cliente y representa el endpoint local, del que se obtienen la dirección IP (getInetAddress()) y el puerto (getPort()).

Middleware

El middleware es un software que se sitúa entre el sistema operativo y las aplicaciones que se ejecutan sobre él, actuando como capa intermedia que facilita la comunicación, la interoperabilidad y los servicios comunes (mensajería, transacciones, acceso a datos). Son ejemplos de middleware los monitores de transacciones, los ORB/CORBA, los servidores de aplicaciones y los sistemas de colas de mensajes. Por el contrario, DOOM (el videojuego) no es un middleware: es una aplicación, no una capa intermedia entre sistema operativo y aplicaciones.

Fuentes

• Oracle, Java Platform SE 7 API — Class Socket (java.net.Socket): https://docs.oracle.com/javase/7/docs/api/java/net/Socket.html

• IETF, RFC 9293 — Transmission Control Protocol (TCP): https://www.rfc-editor.org/info/rfc9293/

• IETF, RFC 791 — Internet Protocol (IP): https://www.rfc-editor.org/info/rfc791

Arquitecturas multicapa

Una arquitectura multicapa (multi-tier o n-tier) es un patrón de diseño que descompone una aplicación en capas o niveles independientes, cada uno con una responsabilidad bien delimitada, de modo que puedan desarrollarse, desplegarse y evolucionar por separado. Es la evolución natural de la arquitectura cliente/servidor, orientada a mejorar la escalabilidad, el mantenimiento y la reutilización del software frente a los esquemas monolíticos.

Del modelo de 2 capas al modelo de 3 capas

En el modelo cliente/servidor de 2 capas la aplicación se reparte entre un cliente y un servidor. Según dónde resida la lógica de negocio se habla de:

• Cliente grueso (fat/thick client) - servidor fino: el cliente ejecuta la presentación y buena parte de la lógica de negocio; el servidor se limita, típicamente, a los datos.

• Cliente fino (thin client) - servidor grueso (fat server): el cliente solo gestiona la presentación y la lógica de negocio reside en el servidor.

Para implantar una arquitectura cliente/servidor del tipo "cliente fino - servidor grueso" con el modelo de 2 capas se necesitan como mínimo 2 equipos: uno que actúe como cliente (presentación) y otro que actúe como servidor (lógica + datos). El reparto físico es intrínseco al modelo cliente/servidor: cliente y servidor son roles que se ejecutan en máquinas distintas.

El modelo de 3 capas

El modelo de 3 capas hace referencia a que las aplicaciones se separan en tres capas, estableciendo:

1. Capa de Lógica de Presentación (presentation tier): la interfaz de usuario. Recoge la entrada del usuario y muestra los resultados. No contiene reglas de negocio.

2. Capa de Lógica de Negocio (business/application tier): el núcleo funcional. Aplica las reglas de negocio, valida, procesa y coordina; actúa de intermediario entre la presentación y los datos.

3. Capa de Datos o de Persistencia (data tier): gestiona el almacenamiento y la recuperación de la información, habitualmente mediante un SGBD.

La característica esencial es que la capa de presentación nunca accede directamente a la capa de datos: siempre lo hace a través de la capa de lógica de negocio. Esto favorece la modularidad: se puede cambiar la base de datos sin tocar la interfaz, o rediseñar la interfaz sin alterar las reglas de negocio.

Ventajas del modelo de 3 capas

• Mayor escalabilidad: cada capa puede desplegarse en servidores independientes y replicarse según la carga.

• Mantenimiento y reutilización: al estar la lógica centralizada en la capa intermedia, los cambios se localizan y la lógica de negocio puede reutilizarse desde distintos clientes.

• Seguridad: la capa de datos queda aislada tras la capa de negocio, no expuesta al cliente.

• Flexibilidad tecnológica: cada capa puede usar tecnologías distintas.

• Balanceo de carga y tolerancia a fallos: al separar físicamente las capas se pueden repartir peticiones y aplicar redundancia.

Desventaja: NO reduce el tráfico de red

El punto clave que suele evaluarse: entre las supuestas ventajas de la arquitectura en 3 capas, la que NO es cierta es que "reduzca el tráfico en la red frente a una arquitectura de dos capas". Al contrario: al introducir una capa intermedia entre la presentación y los datos, se añade un salto adicional de comunicación por red (cliente → servidor de aplicaciones → servidor de datos), de manera que estas soluciones incrementan el tráfico de red y requieren más balanceo de carga y tolerancia a fallos. Por tanto, es FALSA cualquier afirmación que sostenga que la arquitectura de tres capas reduce el tráfico de red o que no lo incrementa. Reducir el tráfico de red no es una ventaja de las tres capas; es, de hecho, una de sus contrapartidas.

El modelo de 3 capas se generaliza en las arquitecturas n-capas, donde la capa de negocio se subdivide (por ejemplo, en servidor web y servidor de aplicaciones), muy comunes en las aplicaciones web y en las arquitecturas de servicios.

La arquitectura ANSI/SPARC de bases de datos

Un caso paradigmático de arquitectura multicapa aplicado a las bases de datos es la arquitectura ANSI/SPARC (también ANSI/X3/SPARC), propuesta en 1975. Establece tres niveles (tres niveles de abstracción) para organizar una base de datos:

Los tres niveles definidos son, por tanto: Nivel Externo, Nivel Conceptual y Nivel Interno.

Propósito de ANSI/SPARC

El objetivo principal de la arquitectura ANSI/SPARC es proporcionar una separación clara de la vista de los usuarios respecto de la representación física, ocultando la complejidad de la base de datos y los detalles físicos de almacenamiento. Persigue precisamente ocultar la complejidad de la base de datos y los detalles físicos de almacenamiento al usuario, que solo interactúa con su vista externa.

Independencia de datos

La separación en tres niveles habilita la independencia de datos, en dos formas:

• Independencia Lógica: capacidad de modificar el esquema conceptual sin alterar los esquemas externos (las vistas de usuario ni las aplicaciones). Es la que permite añadir campos o entidades al modelo lógico sin romper las vistas existentes.

• Independencia Física: capacidad de modificar el esquema interno (estructuras de almacenamiento, índices) sin alterar el esquema conceptual.

En resumen, tanto en el diseño de aplicaciones (3 capas: presentación, negocio, datos) como en el diseño de bases de datos (ANSI/SPARC: externo, conceptual, interno), la filosofía multicapa persigue el mismo fin: desacoplar responsabilidades para ganar independencia, mantenibilidad y flexibilidad, asumiendo a cambio un mayor coste de comunicación e infraestructura.

Fuentes

• ANSI-SPARC Architecture — Wikipedia. https://en.wikipedia.org/wiki/ANSI-SPARC_Architecture

• The Three-Level ANSI-SPARC Architecture — GeeksforGeeks. https://www.geeksforgeeks.org/dbms/the-three-level-ansi-sparc-architecture/

• Chapter 2: Database Environment (Connolly & Begg, Pearson) — CCS Northeastern University. https://www.ccs.neu.edu/home/kathleen/classes/cs3200/ch02C.pdf

• Comparing Two-Tier and Three-Tier Networks — WWT. https://www.wwt.com/article/comparing-two-tier-three-tier-data-center-networks

• Portal de Administración Electrónica (MÉTRICA v3), Gobierno de España. https://administracionelectronica.gob.es/pae_Home/pae_Documentacion/pae_Metodolog/pae_Metrica_v3.html

Servicios web SOAP

Un servicio web es un conjunto de métodos y estándares que permite que aplicaciones heterogéneas se comuniquen entre sí a través de Internet, con independencia de la plataforma y del lenguaje de programación. Los servicios web clásicos («big web services») se apoyan en una pila de estándares basados en texto y XML: SOAP para el transporte de mensajes, WSDL para describir la interfaz y UDDI para publicar y localizar servicios. El uso de estándares basados en texto aporta la ventaja de la legibilidad e interoperabilidad, pero supone un inconveniente de rendimiento, ya que obliga a convertir los datos primitivos a texto y a validar y parsear documentos XML.

SOA: arquitectura orientada a servicios

La arquitectura orientada a servicios (SOA) es un modelo orientado a la reutilización de los servicios en entornos de sistemas distribuidos, que permite crear servicios de datos escalables y flexibles. Sus elementos esenciales se articulan en tres funciones o actores:

• Proveedor de servicios (service provider): publica e implementa el servicio.

• Agente o registro de servicios (service registry/broker): actúa como directorio para localizar las funcionalidades disponibles en la red.

• Usuario o consumidor del servicio (service requester): quien lo busca e invoca.

SOAP representa la principal forma de comunicación entre estos tres actores clave de una SOA. Conviene recordar que SOA no se implementa con HTML5, CSS3 y JavaScript (eso corresponde al front-end web, no a la integración de servicios): su propósito es facilitar la integración de servicios empresariales.

El protocolo SOAP

SOAP (Simple Object Access Protocol) es un protocolo estándar, y una recomendación del W3C, que define cómo dos objetos situados en procesos diferentes pueden comunicarse mediante el intercambio de datos XML. Es una especificación para el intercambio de información estructurada en un entorno distribuido y descentralizado, cuyo propósito principal es intercambiar información entre aplicaciones.

Estructura del mensaje SOAP

Un mensaje SOAP se compone de tres partes bien definidas:

El Header es el elemento opcional; si aparece, debe ser el primer hijo del Envelope. El Web Service Listener es el componente que recibe y envía los mensajes en formato SOAP entre el consumidor y el proveedor.

WSDL: descripción del servicio

WSDL (Web Services Description Language) es un lenguaje XML, recomendación del W3C, para describir servicios web: es el estándar básico donde se describen los formatos y requisitos del mensaje necesarios para interactuar con el servicio, especificando su interfaz. WSDL 2.0 permite describir el servicio a partir de un modelo abstracto de lo que ofrece. Sus elementos principales son:

• <types>: define los tipos de datos (esquema XML) que utiliza el servicio.

• <interface> (WSDL 2.0; portType en WSDL 1.1): describe las operaciones abstractas.

• <binding>: define el protocolo y el formato de los datos para cada tipo de puerto.

• <service>: agrupa los puntos de acceso (endpoints).

WSDL no tiene por objetivo definir un alojamiento (hosting) para los servicios web, ni recoge el «enlace lógico con la implementación concreta» como elemento propio de su descripción.

UDDI, WS-I y seguridad

• UDDI (Universal Description, Discovery and Integration) es un servicio de registro y directorio de servicios web, en XML, donde un proveedor publica su servicio y un consumidor lo busca. Es un estándar de OASIS.

• WS-I (Web Services Interoperability Organization) es una organización independiente creada para fomentar la interoperabilidad de los servicios web sobre cualquier plataforma, sistema operativo y lenguaje (perfiles Basic Profile).

• SAML (Security Assertion Markup Language) es un estándar abierto que define un esquema XML para el intercambio de datos de autenticación y autorización; se emplea como elemento de seguridad en los servicios web.

Las organizaciones responsables de la arquitectura y reglamentación de los servicios web son OASIS y W3C. Entre los estándares del W3C se cuentan SOAP y WSDL; el propósito de la arquitectura de servicios web según el W3C es facilitar la comunicación entre el proveedor y el consumidor de servicios.

Implementaciones Java: JAX-RPC, JAX-WS, Axis y CXF

• JAX-RPC proporciona las API básicas para el desarrollo y despliegue de servicios web en la plataforma Java (Java EE), con el fin de desarrollar servicios web interoperables.

• JAX-WS es el modelo de programación de próxima generación que complementa a JAX-RPC, ofreciendo mayor independencia de plataforma.

• Apache Axis es un framework de código abierto basado en XML para desplegar aplicaciones de servicios web; es un motor nuclear de servicios web.

• Apache CXF es un framework completo de código abierto para servicios web y la librería utilizada para implementar la API Java JAX-WS.

XML, DTD, XML Schema, DOM/SAX y XPath

XML reduce el tiempo de desarrollo al facilitar la representación de datos con una tecnología sencilla y conocida, aunque su rendimiento se ve penalizado por la conversión de datos primitivos a texto y por la validación y el parseo.

• DTD (Document Type Definition): define la estructura de elementos de un documento XML. Un DTD externo se invoca con <!DOCTYPE archivoExterno SYSTEM "archivoExterno.dtd">. Sus componentes son Elements, Attributes, Entities, PCDATA y CDATA.

• XML Schema: para un elemento opcional y sin límite de ocurrencias se usa <xs:element name="description" type="xs:string" minOccurs="0" maxOccurs="unbounded" />.

• DOM vs SAX: DOM lee el documento y construye un árbol en memoria con toda su estructura; SAX es un parser basado en eventos que no construye ese árbol (por eso es falso atribuir a SAX la construcción del árbol en memoria).

• XPath: lenguaje que permite construir expresiones que recorren y procesan un documento XML (p. ej. /Usuarios/usuario[numIntentos>3]/apellidos). Sintaxis típica: //nombreEtiqueta[@atributo='valor']. Distingue XPath absoluto (ruta directa desde la raíz) y relativo (desde un punto intermedio del DOM). No permite «cambiar la ruta» del elemento.

• XHTML: todos los valores de los atributos deben ir entre comillas, sin excepción para los numéricos.

Fuentes

• W3C — SOAP Version 1.2 Part 1: Messaging Framework: https://www.w3.org/TR/soap12-part1/

• W3C — SOAP Version 1.2 Part 0: Primer: https://www.w3.org/TR/soap12-part0/

• W3C — WSDL Version 2.0 Part 1: Core Language: https://www.w3.org/TR/wsdl20/

• W3C — WSDL 2.0 Part 0: Primer: https://www.w3.org/TR/2007/REC-wsdl20-primer-20070626/

• OASIS — UDDI Specification: https://www.oasis-open.org/committees/uddi-spec/

• OASIS — SAML (Security Services TC): https://www.oasis-open.org/committees/security/

• OASIS — WS-I Member Section: https://www.oasis-open.org/2017/12/21/oasis-announces-successful-completion-of-web-services-interoperability-ws-i-member-section/

• W3C — XML 1.0 y XPath: https://www.w3.org/TR/xml/ y https://www.w3.org/TR/xpath-31/

• W3C — XML Schema: https://www.w3.org/TR/xmlschema11-1/

• Oracle — SOA and Web Services (JAX-RPC/JAX-WS): https://www.oracle.com/technical-resources/articles/javase/webservices-protocols.html

• Apache CXF: https://cxf.apache.org/ · Apache Axis: https://axis.apache.org/

Servicios web REST y APIs

REST (Representational State Transfer, Transferencia de Estado Representacional) es un estilo de arquitectura para sistemas distribuidos definido por Roy Fielding en su tesis doctoral (2000). No es un protocolo ni un estándar oficial, sino un conjunto de principios de diseño para construir servicios web sobre el protocolo de aplicación HTTP. Un servicio o API que cumple estos principios se denomina RESTful. En este contexto, REST es una definición de arquitectura para el intercambio y manejo de datos a través de servicios web y, a la vez, una interfaz para conectar sistemas basada en HTTP: cuando se necesita conectar sistemas basados en HTTP, la respuesta natural es una interfaz REST.

El papel de una API REST

Una API REST actúa como capa que almacena y gestiona la lógica de negocio y sirve datos a través de recursos identificados por URL. Cada entidad del sistema (un usuario, un pedido, un documento) es un recurso con su propia URL, y el cliente opera sobre él mediante los métodos del protocolo HTTP. Su funcionamiento se basa íntegramente en HTTP, lo que la convierte en su característica más distintiva.

Restricciones arquitectónicas

Las propiedades fundamentales de REST son:

• Cliente-servidor: REST separa cliente y servidor, de modo que ambos evolucionan de forma independiente. El cliente no necesita conocer la implementación interna del servidor y viceversa; esta separación de responsabilidades es una de sus ventajas principales.

• Sin estado (stateless): el servicio no almacena información sobre el estado del cliente entre peticiones. Cada solicitud debe contener toda la información necesaria para ser procesada. Por ello es INCORRECTO afirmar que REST es un protocolo cliente/servidor con estado: precisamente es sin estado.

• Cacheable, sistema en capas e interfaz uniforme completan el conjunto de restricciones.

Métodos (verbos) HTTP

REST utiliza los métodos (verbos) estándar de HTTP para realizar operaciones. Los cuatro más habituales, asociados al patrón CRUD, son GET, POST, PUT y DELETE:

Según RFC 9110, HEAD es idéntico a GET salvo que el servidor no debe enviar contenido en el cuerpo, y TRACE realiza una prueba de bucle de mensaje (message loop-back) a lo largo del camino al recurso objetivo, lo que permite depurar la ruta. PATCH (RFC 5789) se distingue de PUT en que aplica modificaciones parciales en lugar de sustituir el recurso entero.

Conviene recordar que Send NO es un método HTTP soportado por una API REST: no existe tal verbo en la especificación.

Paso de parámetros con GET

Con el método GET, las variables se concatenan en la cadena de consulta de la URL. Tras el interrogante ? se colocan pares clave=valor unidos por el carácter &. Ejemplo correcto:

http://www.opositatest.com/index.php?page=mia&variable2=valor2&variable3=valor3

Sobre GET y POST, es INCORRECTA la afirmación de que «el método GET no permite almacenamiento en la memoria caché»: precisamente las respuestas a GET sí son cacheables, a diferencia de POST.

Códigos de estado HTTP

La API comunica el resultado mediante códigos de estado. Los más relevantes para una API RESTful son:

• 400 Bad Request: el servidor no puede procesar la petición por un error del cliente; p. ej., un POST que espera ciertos parámetros vía JSON pero recibe otros distintos.

• 403 Forbidden: el servidor entiende la petición pero rechaza otorgar respuesta porque el cliente no posee los permisos necesarios.

• 404 Not Found: el servidor no pudo encontrar el contenido solicitado.

Formato de datos: JSON frente a XML

Actualmente el formato de datos más utilizado en REST es JSON (JavaScript Object Notation), por ser más ligero (liviano) y legible (fácil de leer) que XML, lo que mejora especialmente el rendimiento en aplicaciones móviles. REST admite tanto XML como JSON.

REST frente a SOAP

Una diferencia principal es que SOAP es más complejo y solo trabaja con XML, mientras que REST es más sencillo y trabaja con XML y JSON. Frente a SOAP, REST ofrece mejor rendimiento y ligereza, especialmente en aplicaciones móviles. Su principal desventaja es que no existe un estándar oficial que imponga cómo realizar los métodos HTTP: REST usa métodos HTTP estándar pero no impone reglas estrictas sobre cómo aplicarlos, lo que puede generar inconsistencias entre implementaciones.

Además, NO es característica de los servicios REST usar la especificación UDDI para publicar y localizar servicios web: UDDI pertenece al mundo de los servicios web SOAP/WSDL, no a REST.

Arquitectura sin servidor (serverless)

Complementariamente, la arquitectura sin servidor (serverless) es un modelo de computación donde el proveedor del cloud gestiona la infraestructura de servidor, y los desarrolladores solo necesitan preocuparse por el código de su aplicación. Es un modelo habitual para desplegar APIs REST sin administrar máquinas.

Fuentes

• IETF, RFC 9110 HTTP Semantics (métodos GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE y códigos de estado 400/403/404): https://www.rfc-editor.org/rfc/rfc9110.html

• IETF, RFC 5789 PATCH Method for HTTP: https://www.rfc-editor.org/rfc/rfc5789.html

• R. T. Fielding, Architectural Styles and the Design of Network-based Software Architectures (tesis, capítulo 5: REST): https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

• MDN Web Docs, HTTP request methods (W3C/WHATWG referencia): https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods