Ya estoy aquí de nuevo. Después de hablar sobre Programación procedural clásica (PP) vs Programación orientada a objectos (POO), en esta ocasión vamos a hablar de sistemas cliente-servidor, basados en 2 capas, y sistemas multi-capa, formados habitualmente por 3 capas, aunque los de 5 capas también están en auge.

Pero… ¿qué es eso de las capas? Definamos primero ese concepto para que se pueda entender todo mejor. Se habla de capas en la programación cuando queremos separar los componentes que permiten el funcionamiento de un programa en diferentes partes. Por ejemplo, cuando hablamos de dos capas habitualmente se refiere a la capa de presentación-negocio por un lado y a la de base de datos por el otro.

Vamos a partir del concepto actual de capas para que podáis entender mejor a qué me refiero. El modelo de tres capas, en el que hoy se basan casi todos los programas nuevos, consta de lo siguiente (extraído de la wikipedia):

1. Capa de presentación: es la que ve el usuario (también se la denomina “capa de usuario”). Presenta el sistema al usuario, le comunica la información y captura la información que proporciona el usuario en un mínimo de proceso (realiza un filtrado previo para comprobar que no hay errores de formato y poco más). Esta capa se comunica únicamente con la capa de negocio. También es conocida como interfaz gráfica, y debe tener la característica de ser “amigable” (entendible y fácil de usar) para el usuario.
2. Capa de negocio: es donde residen los programas que se ejecutan, se reciben las peticiones del usuario y se envían las respuestas tras el proceso. Se denomina capa de negocio (e incluso de lógica del negocio) porque es aquí donde se establecen todas las reglas que deben cumplirse. Esta capa se comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base de datos bien para almacenar, bien recuperar datos allí contenidos.
3. Capa de datos: es donde residen los datos, y es la encargada de acceder a los mismos. Está formada por uno o más gestores de bases de datos que realizan todo el almacenamiento de datos y reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio.

En los albores de la informática (Mackuskey creo que os lo podrá confirmar), todo se hacía en una única capa (quizá no sea exactamente la expresión correcta, pero lo voy a expresar así). Digo esto porque el programador se encargaba de todo: imprimía los caracteres en pantalla, hacía los cálculos necesarios para cada proceso y, finalmente, grababa a mano los datos en los ficheros correspondientes, mejor dicho, emitía las órdenes de lectura o escritura exactas en los ficheros (no, no había bases de datos -en el resto del artículo, BDs- relacionales hasta los años 80), gestionando incluso los índices en algunos casos. Vamos, un auténtico “yo me lo guiso y yo me lo como todito”. ^[1]

Afortunadamente en los 80 llegó dBase (y Clipper más tarde), que ya eran sistemas gestores de bases de datos (aunque no usaban SQL) y permitían al programador usar sentencias parecidas a las actuales, tales como “carga/graba/borra este registro”. Quizá podríamos considerar ese momento como el paso a las dos capas, porque el programador ya no tenía que gestionar todo ”a mano”: por un lado tenía una BD, y por otro su capa negocio/interface. Ya en los 90 se popularizaron (porque hasta esa época era algo reservado al uso en los grandes ordenadores) las BDs relacionales. Y con esa popularización se empezaron a diseñar miles de programas usando la tecnología “cliente-servidor” (varios ordenadores con el mismo programa ”atacaban” una base de datos única). Y con esto llegamos al punto del tema en cuestión. No voy a ahondar demasiado en los conceptos porque, con una visita a la wikipedia, tenéis todas las definiciones que necesitéis sobre ello. Creo que con explicar lo básico se entiende la idea.

Así pues, yo definiría comunmente un sistema cliente-servidor como un sistema en el cuál tenemos una base de datos centralizada (la capa de datos) y un programa instalado en diferentes ordenadores que gestiona la capa de presentación y la de negocio a la vez (de ahí que se llame de dos capas). Por ejemplo, el clásico programa que emplean en un taller oficial de reparación de vehículos (supongo que habréis visto alguno al llevar el coche a la revisión). Estos suelen ser programas que acceden a los datos de la casa madre (eso, ahora que hay internet, porque antes era off-line y se cargaban los datos por la noche) y que el programa gestiona todo lo referente a los procesos y el interfaz de usuario (suelen estar hechos en Visual Basic, Delphi o similares). O también los programas que usan los cajeros de los bancos suelen ser así. Otro ejemplo serían las páginas web: los datos están en internet y el navegador sería el “programa” que visualiza y ejecuta (con javascript) las operaciones necesarias. Pero, por otro lado, también hay otro tipo de sistemas cliente-servidor en los que se mezclan la capa de datos y de negocio, y en la parte cliente tenemos la capa de presentación. De nuevo, una página web sirve como ejemplo, sólo que en este caso no usaría javascript para realizar los cálculos, sino que se harían en la propia BD (como, por ejemplo un procedimiento almacenado en la BD para realizar, digamos, la suma de las ventas de un mes).

En cambio, como se dijo anteriormente, un sistema de tres capas separa las dos que se juntan en el “cliente” de una forma que, en principio, trae numerosas ventajas, aunque veremos que luego no todo es tan bonito, como suele pasar siempre. La estructura habitual de instalación en un sistema de tres capas es: un servidor de bases de datos, un servidor de aplicaciones (capa de negocio) y una interface de usuario (capa de presentación), que suele ser tonta, es decir, se limita a trasladar las acciones del usuario en la pantalla a llamadas a la capa de negocio para que sea ahí donde se realicen los cálculos pertinentes. Esta arquitectura se puso de moda con la llegada de Java y sus aplicaciones multiplataforma.

Ahora llega la parte práctica del asunto: ¿y cuál me interesa a mi usar? Pues para saber eso hay que conocer los puntos fuertes y débiles de cada tecnología, así que veámoslos primero.

Cliente-servidor: ventajas e inconvenientes

(Capa de negocio en el cliente, también llamado cliente rico o pesado)

Como tecnología bien conocida, por el tiempo que lleva en producción, es ampliamente usada. Lo cierto es que para la mayoría de aplicaciones comunes es más que suficiente, pero empieza a cojear cuando se tienen muchos clientes atacando al servidor (y se espera una respuesta rápida, lógicamente). Las mayores ventajas son:

1. Aplicaciones cliente ricas en contenido y rápidas: el hecho de tener todo, menos los datos, en la propia aplicación hace que, disponiendo de un puesto cliente con el hardware adecuado, todo en la aplicación fluya con rapidez (siempre que los datos estén disponibles). Las operaciones que se realizan sobre los datos son instantáneas (no hay que esperar a que lo haga otro servidor y esperar su respuesta). Por ejemplo, si recordáis al principio de internet cuando las páginas web tenían, digamos, un desplegable de provincias y ciudades (donde las ciudades dependen del contenido de la provincia), cuando pinchabas una provincia, la página web llamaba al servidor, éste obtenía las ciudades relacionadas con la provincia y devolvía la página nuevamente para seleccionar la ciudad. Esto era, obviamente, hiperlento. La otra posibilidad era tener un código javascript (capa de negocio) que ya tuviese todos los valores de provincias y ciudades grabadas y, en ese caso, todo era instantáneo. A cambio, la página era mucho más pesada de cargar (cliente rico o pesado). La velocidad de ejecución del javascript dependía en este caso de la potencia del cliente.
2. Actualizaciones independientes: diferentes clientes pueden tener versiones diferentes de la aplicación a la vez funcionando, lo cual sirve, por ejemplo, para actualizar sólo una parte de todos tus clientes, a modo de conejillos de indias, y ver si lo nuevo realmente funciona en real.
3. Fácil escalabilidad en los clientes: es muy fácil añadir nuevos clientes, ya que sólo van a necesitar una conexión para obtener los datos, lo cual no incrementa en mucho las necesidades del servidor. Ahora bien, si la aplicación precisa continuamente de datos del servidor, lógicamente éste se verá sobrecargado muy rápidamente conforme crece el número de clientes.
4. Servidor normal: ya que sólo se va a encargar de los datos, aún siendo estos muy importantes, no es preciso un súper-servidor para tener esos datos disponibles. La CPU apenas va a estar ocupada, sólo va a ser necesaria para el gestor de la BD. Eso sí, el sistema de discos es aquí crítico.

Como inconvenientes yo citaría los siguientes:

1. Los clientes deben tener ciertos requisitos de hardware: evidentemente, el hecho de que los cálculos se realicen siempre en el cliente obliga a que el hardware pueda llevarlos a cabo con solvencia. Todos recordaréis los “requisitos mínimos” que suelen pedir los programas para instalarse.
2. Instalaciones de los clientes engorrosas: hay que ir cliente a cliente instalando la aplicación, al menos la primera vez, ya que suele traer muchos ficheros de los que depende (baste ver una clásica instalación de Visual Basic para darse cuenta). Las famosas DLLs de las que dependen muchos programas son parte causante de esto. Una vez hecho esto, y si no se añaden nuevas dependencias al programa, las actualizaciones son más fáciles (habitualmente, copiar un único archivo).
3. Red de la empresa congestionada: suele haber mucha información, sobre todo resultados de consultas SQL, fluyendo por la red, desde el servidor a cada cliente y viceversa. Esto no es así (en realidad depende) con las tres capas, ya que ahí solo fluyen los resultados a mostrar en pantalla, mientras que en tecnología cliente-servidor cada cálculo necesita de unos datos que son pedidos y llevados al cliente, para efectuar sus operaciones (muchas veces son muchos datos, como por ejemplo, obtener la lista del todos los clientes o productos, y hacer operaciones con ellos). El hecho de que las operaciones se realicen en el cliente implica que si para obtener, por ejemplo, el resultado de compras+ventas-devoluciones necesito obtener esos datos cada vez y calcularlos en el cliente, las tres informaciones van hasta el cliente, realiza la operación y envía el resultado para ser grabado. Si estas mismas operaciones se hacen en el servidor, nada viaja por la red, salvo el resultado.

Cliente-servidor: ventajas e inconvenientes

(Capa de negocio en el servidor, también llamado cliente ligero)

Aquí la parte de negocio se mezcla con la de acceso a los datos para obtener una respuesta que luego será enviada al cliente (y éste la mostrará en pantalla, esperando una acción por parte del usuario). Ésta es, a mi entender, una mala filosofía de programación, puesto que mucha parte del negocio se encuentra en la propia BD en forma de procedimientos almacenados o triggers, lo que hace totalmente dependiente el producto software resultante de la BD en la que se desarrolle. Suele ser, además, un compromiso mixto, ya que otra parte pequeña del negocio se debe situar en el cliente casi siempre (los lenguajes de BD suelen ser limitados) y, entre los dos, consiguen llevar a cabo sus acciones. En este caso las ventajas son:

1. Rendimiento del sistema: normalmente, la misma operación realizada en el cliente o en el servidor (atendiendo a cálculos con datos) se ejecuta mucho más rápido en el servidor, dado que las propias BDs tienen los procedimientos compilados y, además, es posible que si una operación es muy solicitada permanezca en la caché del sistema, siendo aún más rápida.
2. Actualizaciones automáticas: cualquier cosa cambiada en el servidor (a nivel de negocio o datos) repercute automáticamente en el cliente sin tener que hacer nada. El paraíso para los administradores de sistemas.
3. Requerimientos de ordenador casi inexistentes: dado que el cliente no hace más que visualizar cosas, apenas hay requerimientos hardware.
4. Instalaciones/actualizaciones sencillas: incluso inexistentes, si estamos hablando de páginas web.
5. Red de la empresa menos sobrecargada: todas las operaciones se realizan en el servidor, al cliente solo se le envía lo que tiene que ver.

Como inconvenientes yo citaría los siguientes:

1. La instalación de los clientes debe estar controlada: dada su facilidad de expansión, meter muchos clientes sin tener dimensionado el servidor para ese número ralentizará el sistema, llegando incluso a colapsarlo.
2. Actualizaciones cuidadosas en el servidor: hay que tener mucho cuidado con las actualizaciones, ya que todos los clientes cambiarán simultáneamente de comportamiento y, en caso de error, ninguno funcionará correctamente. Lo normal en un programa es que la parte más cambiante esté en la capa de negocio y, al estar ésta en el servidor, será habitual que haya actualizaciones, lo cual es siempre un punto crítico en cualquier sistema.
3. Servidor muy potente: Será el servidor quién se encargue de todos los procesos (y también de los datos, habitualmente), por tanto debe ser lo suficientemente potente como para soportar todas las peticiones y procesos que le sean requeridos.
4. El más importante bajo mi punto de vista, imposibilidad de cambio de motor de BD: una vez que se empieza a trabajar con el lenguaje de programación específico de una BD y que el programa crece y crece (para variar), el día que se decida cambiar de BD (por ejemplo, migrar de SQL Server a Oracle para ganar en rendimiento) será absolutamente imposible sin reescribir toda la capa de negocio de nuevo. Ya sólo por este motivo yo soy partidario de elegir un cliente-servidor pesado.

3 capas: ventajas e inconvenientes

Y llegamos al modelo de moda. Es un modelo que, técnicamente, parece perfecto. Además, sobre el papel debería funcionar mejor que nada… aunque la experiencia me dice que no siempre es así.

Tal como vimos al principio, en un modelo de 3 capas tenemos todo separado, lo cual nos proporciona muchísimas ventajas y apenas incovenientes. Veamos ambos.

Ventajas:

1. Aplicaciones cliente ligeras: ya vimos algunas de sus ventajas en los clientes ligeros, a saber: actualizaciones automáticas (siempre que no sean de la interfaz), requerimientos mínimos del cliente, instalaciones sencillas, red poco cargada. El programador en este caso tan sólo debe preocuparse del aspecto gráfico de la misma y de llamar/recibir a los eventos que el usuario puede disparar.
2. Modelo de procesos independiente: si algo está mal, si queremos añadir funcionalidades, nuevos cálculos, … cualquier cosa que el programador quiera hacer la puede hacer y actualizar sin interferir apenas con los usuarios o con la BD. Una vez que todo esté correcto bastará subir los cambios a un único sitio y, como por arte de magia, todos los clientes disfrutarán de un nuevo programa.
3. Alta escalabilidad del sistema: esto, que se dice mucho y se entiende poco al principio, significa que podemos agregar/quitar al sistema tantos clientes y servidores como necesitemos si el volumen de trabajo crece o decrece. Por ejemplo, imaginemos que teníamos un único servidor de aplicaciones que da soporte a 10 clientes simultaneos pero de repente entran 10 más por picos de trabajo puntuales. Si el sistema se resiente, como es previsible, bastará con añadir un segundo servidor de aplicaciones (capa 2, la de negocios) y un balanceador de carga para que las peticiones de los clientes se repartan automáticamente entre los dos servidores de aplicaciones. Los clientes también crecen pero el servidor de datos se mantiene (si estuviésemos en el caso de cliente (ligero)-servidor sólo cabría aumentar la RAM del servidor, mejorar el procesador (raro-raro) y rezar para que con eso fuese suficiente. En caso de no serlo… tocaría cambiar de servidor).
4. Fácil mantenimiento: al estar todo separado, cualquier operación es más sencilla de realizar dada la especificidad de las funciones en cada capa. Vamos, que si empieza a fallar, digamos, el servidor de aplicaciones, se prepara otro enseguida y se puede cambiar en “ná-y-menos”.
5. Alta tolerancia a fallos: es fácil construir un sistema 24/7^[2] de alta disponibilidad, basta redundar (duplicar) cada capa y meter un sistema balanceador de cargas que detecte cuándo se cae un servidor para pasar las peticiones al otro. Cuando un sistema se monta así, estamos hablando de un clúster con diversos nodos.
6. Bases de datos como simple almacén: no ejercen más labor que la de almacén de datos, lo que posibilita la migración en caso de ser necesario, tanto entre versiones de la misma BD como entre diferentes motores de BD.

Inconvenientes:

1. Red de la empresa más cargada: esta desventaja es relativa, puesto que sólo ocurre cuando la instalación de la capa de aplicaciones está separada de la de la capa de datos (sí, es posible perfectamente instalar en el mismo servidor físico la capa de negocio y de datos, pero se pierde alguna ventaja como la tolerancia a fallos, por ejemplo). Si es así, las peticiones van desde el cliente a la capa de negocio, y desde la capa de negocio a la BD (y el camino opuesto), moviendo más información por la red que si tuviésemos una aplicación cliente-servidor.
2. Programación más compleja: el hecho de que tu programa dependa de varios servidores hace que sea un poco más complicado tanto el desarrollo como los test. Más piezas en la ecuación, más posibles puntos de fallo. No hablemos ya de la detección/corrección de errores…
3. Servidores especializados, y más caros por tanto. Todo depende, como siempre, de cuánta seguridad quieras, pero si se quiere cierta tolerancia a fallos hay que tener al menos dos servidores y algo que los sincronice. Además, ya estamos hablando de un servidor aplicacional y otro para BD, lo cual requiere de mayores conocimientos (tanto en su gestión como en la programación) que para un clásico programa cliente-servidor.
4. En general, respuesta más lenta en los clientes: y éste es el punto por el que yo no siempre elegiría este modelo. Todo es muy bonito en el papel, pero, como resultado de todo este entramado, lo que obtenemos son peticiones a servidores de aplicaciones y respuestas de estos. Por muy rápido que sea el proceso, siempre va a tener que ir y volver, como mínimo, y aunque para la web los servidores aplicacionales son muy rápidos (porque es la velocidad de la conexión la que acaba determinando la velocidad), para un cliente una espera de un segundo puede ser todo un mundo, dependiendo de lo que necesite.

Entonces, ¿cuál es mejor?

Pues como casi todo en la informática, eso va a depender de varios factores, eso sí, algunos de ellos totalmente determinantes. Por ejemplo, ¿necesito un sistema muy escalable? Pues amigo, ni te lo pienses, como las 3 capas no encontrarás uno mejor. ¿Sistema 24/7 de alta disponibilidad? Bien, en realidad esto también lo tienes con cliente-servidor en sus “dos modalidades”: basta redundar el SGBD de forma que si cae un servidor se active el otro (todo de forma transparente para el cliente). Quitando ciertos factores determinantes, como la escalabilidad, si lo único que es fundamental es la experiencia del usuario (cliente) yo me inclinaría por un sistema cliente(pesado)-servidor, donde los procesos se ejecutan casi al instante, y os voy a comentar un caso real (conozco más, pero con uno llega) que ocurre actualmente para apoyar esta afirmación.

Uno de mis conocidos tiene una empresa en la que tenía su sistema de gestión de toda la vida, una BD Informix que era atacada por un programa realizado en Multibase. No es que no estuviesen contentos con el sistema, que sí lo estaban, pues hacía lo que tenía que hacer y lo hacía bien. Pero llegó una empresa consultora de esas que tanto abundan hoy que convenció al gerente (mi amigo) de que 15 años con el mismo programa era de dinosaurios, que había que actualizar los equipos porque si fallaba alguno luego a ver quién le montaba un servidor nuevo con esa versión de Informix, que si esto, que si lo otro… vamos, la cantata de siempre de “actualícese, so dinosaurio, que todos tenemos que comer“. El caso es que este hombre aceptó, incauto de él, pensando, como Don Hilarión, que “la ciencia avanza que es una barbaridad” y que a peor no podría ir: ¡¡un sistema con 15 años tiene que ser mucho más lento que uno de hoy en día, vamos hombre!!

Total, pasamos de un sistema cliente-servidor (donde los usuarios pulsaban intro para llegar a la casilla donde querían ir, al viejo estilo DOS) a un flamante sistema de 3 capas con su servidor de BD IBM con Oracle 10g, otro servidor aplicacional con Tomcat 5.5 y un bonito programa hecho en flash con la tecnología FlashRemoting (es como un programa normal de flash que se ejecuta como un EXE cualquiera en vez de en un navegador web, de hecho es un EXE). La verdad es que lo vi y era precioso, con sus botones redondos y sus animaciones tan bonitas… era precioso, digo, hasta que lo vi funcionando. No estaba nada mal, ojo, más o menos hacía las cosas bien, tenía ciertas ventajas, cosas mejoradas respecto a lo que tenían antes (si no, apaga y vámonos), etc, pero era… LENTO. O sea, LENTO. No es que la pantalla fuese lenta al teclear, ni cosas así, lo que era lento es la transición entre pantallas: entrabas en un cliente y tardaba 2 segundos en mostrar los datos, desde ahí accedías a sus pedidos y tardaba otros 2 segundos en mostrarlos (siempre aparecía un relojito indicando la “petición” de los datos al servidor), y así, de pantalla en pantalla, a razón de 2 segundos (o más, pero nunca menos).

Dos segundos pueden parecer una tontería, pero cuando el usuario estaba acostumbrado a pulsar intro y que en medio segundo apareciesen los datos, hacer intro 3 veces más (ya de memoria) para llegar a donde quería, escribir lo que procediese y pulsar intro para grabar y llegar al pedido, y todo esto en menos de 3 segundos, y ahora este mismo proceso le cuesta 2s + ratón a la casilla de destino y escribir el valor (X segundos) + 2s, y esto repetido en el día docenas o centenares de veces, pues… mal vamos.  El usuario final se enfada, la empresa pierde rendimiento del trabajador y, encima, le ha costado dinero (y más que le costará, y si no, al tiempo). Mi amigo ahora desconfía de las consultoras (como es lógico), y está con un cabreo de tres pares (como es lógico, también).

Con esto quiero dar a entender que las tecnologías no deben adoptarse porque sí, deben adoptarse porque mejoran lo que hay, si no, es un sinsentido. Realmente las 3 capas traen muchas ventajas, sobre todo para los administradores de sistemas, pero hay que pensar bien dónde se aplican, ya que la velocidad de la aplicación no es tan buena como la de un cliente-servidor. Por ejemplo, ahora es muy típico que en la Administración (o sea, el Gobierno central, autonómico, municipal y demás) te pidan que todas las aplicaciones que tú les vendas tengan una arquitectura de 3 capas. Es más, si no es así ya no entras siquiera a concurso. Imponen la tecnología a emplear. Luego salen churros infumables (no todos, lógicamente) y no siempre la empresa es la culpable, es que la han obligado a hacer las cosas con una tecnología inadecuada para el propósito buscado.

En fin, espero que os haya gustado este artículo. Todo lo que aquí digo no es más que mi propio conocimiento basado en mi experiencia de estos años. Puedo haberme equivocado en algo, en cuyo caso no dudéis en decírmelo y, si es menester, corregiré el artículo para que sea lo más correcto y lo menos técnico posible.

El último artículo de mi lista es Servicios web (WS), Arquitectura orientada a servicios (SOA) y demás zarandajas de la “globalización” de los programas. Ahí os espero.

1. Nota de Macluskey, por alusiones: Confirmo que era así, sin duda. Hasta los años 70 no existían bases de datos de ningún tipo, y hasta mediados, más bien fines, de los 80, no existieron las primeras bases de datos relacionales. La primera de ellas operativa fue SQL/DS, de IBM para VSE, seguida al poco por DB2 para MVS, ambas en ambiente mainframe de IBM, lo que tras varios cambios de nombre ahora se llama z/OS [↩]
2. 24/7 indica disponibilidad de 24 horas al día y 7 días a la semana [↩]

The Informática: esos locos, con sus locos cacharros – Sistemas cliente-servidor vs Sistemas multi-capa by Manuel Conde Vendrell, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 2.5 Spain License.