Cliente/servidor

La arquitectura cliente/servidor es un modelo de reparto en el que una aplicación se divide en dos papeles bien diferenciados. El cliente es el que toma la iniciativa: pide algo. El servidor es el que espera peticiones y las atiende, devolviendo una respuesta. Los dos papeles son roles de software, no máquinas: un mismo ordenador puede ejecutar a la vez un cliente de correo y un servidor de base de datos.

El modelo anterior era el centralizado, con un gran ordenador que hacía todo el trabajo y terminales que solo pintaban caracteres en pantalla. El modelo cliente/servidor rompe eso: el proceso se distribuye entre varias máquinas conectadas por una red, y cada una hace la parte que mejor se le da. Del otro lado está el modelo entre iguales o peer to peer, donde no hay papeles fijos y cada nodo actúa a la vez de cliente y de servidor.

• La comunicación siempre la inicia el cliente. El servidor no llama al cliente por su cuenta: responde.
• Un servidor atiende a muchos clientes a la vez; un cliente puede hablar con varios servidores.
• Las dos partes se acoplan a través de un protocolo o un interfaz, no a través del código interno de la otra.
• El servidor concentra los recursos que conviene compartir y proteger: los datos, la lógica común, la capacidad de cálculo.

Cliente y servidor son papeles, no equipos. Lo que define el modelo es quién pregunta y quién contesta, no dónde está instalado cada programa.

La pregunta que decide el diseño es cuánto trabajo se lleva el cliente. Un cliente pesado (o cliente gordo) ejecuta la presentación y buena parte de la lógica de negocio en el equipo del usuario, y solo va al servidor a buscar o guardar datos. Un cliente ligero se limita a pintar la interfaz y a recoger lo que el usuario teclea: toda la lógica vive en el servidor. Un navegador web es el ejemplo canónico de cliente ligero.

Entre el cliente y el servidor casi nunca hay un cable pelado: hay middleware, que es el software intermedio que se encarga de los detalles feos de la comunicación. Localiza al servidor, transporta la petición, convierte los datos al formato que entiende cada extremo, gestiona las transacciones y devuelve la respuesta. Un servidor de aplicaciones, un gestor de colas de mensajes o el propio motor de un servicio web son middleware.

El middleware existe para que el programador escriba «pídele la nota media al servicio de temario» y no tenga que escribir sockets, reintentos ni conversiones de formato.

El modelo cliente/servidor se impuso porque permite poner cada cosa donde conviene: los datos en una máquina preparada para custodiarlos, el cálculo pesado en una máquina potente, y la interfaz en el equipo del usuario, que es donde está el usuario. Además abarata el crecimiento: para atender al doble de gente no hay que cambiar de ordenador central, basta con añadir servidores.

• A favor: reparto del trabajo, recursos compartidos y controlados en un punto, crecimiento por adición de máquinas, y clientes que pueden ser de tecnologías distintas mientras respeten el protocolo.
• En contra: aparece la red como pieza crítica, con su latencia y sus cortes.
• En contra: el servidor se convierte en un punto único de fallo si no se replica.
• En contra: la administración se complica, porque hay más piezas que vigilar, y la seguridad ya no se resuelve con una puerta cerrada.

Ninguno de esos inconvenientes se elimina, se gestionan: la red con protocolos fiables y tolerancia a fallos, el punto único con réplicas y balanceo de carga, y la seguridad autenticando y cifrando cada petición. Es exactamente el problema que después van a resolver la arquitectura multicapa y los servicios web.

Si en una aplicación se distinguen tres funciones (la presentación, la lógica de negocio y la gestión de los datos), la clasificación clásica de Gartner enumera las cinco formas de repartirlas entre el cliente y el servidor. Se ordenan de menos a más trabajo en el cliente.

1. 1Presentación distribuida: el servidor lo hace todo, incluida la presentación, y el cliente solo la reviste o la reformatea. Es el caso de un emulador de terminal.
2. 2Presentación remota: el cliente se encarga de toda la presentación y el servidor mantiene la lógica y los datos.
3. 3Lógica distribuida: la lógica de negocio se parte entre los dos extremos. Es el modelo más flexible y el más difícil de mantener.
4. 4Gestión de datos remota: el cliente lleva la presentación y toda la lógica, y el servidor solo guarda y sirve los datos. Es el cliente/servidor de dos capas clásico.
5. 5Base de datos distribuida: además de lo anterior, el cliente conserva una parte de los datos, y el conjunto se ve como una única base de datos repartida.

El orden de la lista es el orden en que el trabajo se va mudando del servidor al cliente. Recordando los dos extremos (presentación distribuida es el cliente más tonto, base de datos distribuida el más listo) se reconstruye la escala entera.