MODELOS CLIENTE/SERVIDOR
Una de las clasificaciones mejor conocidas de las arquitecturas Cliente/Servidor se basa en la idea de planos (tier), la cual es una variación sobre la división o clasificación por tamaño de componentes. Esto se debe a que se trata de definir el modo en que las prestaciones funcionales de la aplicación serán asignadas, y en qué proporción, tanto al cliente como al servidor. Dichas prestaciones se deben agrupar entre los tres componentes clásicos para Cliente/Servidor: interfaz de usuario, lógica de negocios y los datos compartidos, cada uno de los cuales corresponde a un plano. Ni que decir tiene que la mala elección de uno u otro modelo puede llegar a tener consecuencias fatales.
Dentro de esta categoría tenemos las aplicaciones en dos planos (two-tier), tres planos (three-tier) y multi-planos (multi-tier). Dado que este término ha sido sobrecargado de significados por cuanto se lo utiliza indistintamente para referirse tanto a aspectos lógicos (Software) como físicos (Hardware), aquí se esquematizan ambas acepciones.
A NIVEL DE SOFTWARE
Este enfoque o clasificación es el más generalizado y el que más se ajusta a los enfoques modernos, dado que se fundamenta en los componentes lógicos de la estructura Cliente/Servidor y en la madurez y popularidad de la computación distribuida. Por ejemplo, esto permite hablar de servidores de aplicación distribuidos a lo largo de una red, y no tiene mucho sentido identificar a un equipo de hardware como servidor, si no más bien entenderlo como una plataforma física sobre la cual pueden operar uno o más servidores de aplicaciones.
Este enfoque o clasificación es el más generalizado y el que más se ajusta a los enfoques modernos, dado que se fundamenta en los componentes lógicos de la estructura Cliente/Servidor y en la madurez y popularidad de la computación distribuida. Por ejemplo, esto permite hablar de servidores de aplicación distribuidos a lo largo de una red, y no tiene mucho sentido identificar a un equipo de hardware como servidor, si no más bien entenderlo como una plataforma física sobre la cual pueden operar uno o más servidores de aplicaciones.
MODELO CLIENTE/SERVIDOR 2 CAPAS
Esta estructura se caracteriza por la conexión directa entre el proceso cliente y un administrador de bases de datos. Dependiendo de donde se localice el grupo de tareas correspondientes a la lógica de negocios se pueden tener a su vez dos tipos distintos dentro de esta misma categoría:
IMPLEMENTADO CON SQL REMOTO
En este esquema el cliente envía mensajes con solicitudes SQL al servidor de bases de datos y el resultado de cada instrucción SQL es devuelto por la red, no importando si son uno, diez, cien o mil registros. Es el mismo cliente quien debe procesar todos los registros que le fueron devueltos por el servidor de base de datos, según el requerimiento que él mismo hizo. Esto hace que este tipo de estructura se adecue a los requerimientos de aplicaciones orientadas a los sistemas de apoyo y gestión, pero resultan inadecuados para los sistemas críticos en que se requieran bajos tiempos de respuesta.
Esta estructura se caracteriza por la conexión directa entre el proceso cliente y un administrador de bases de datos. Dependiendo de donde se localice el grupo de tareas correspondientes a la lógica de negocios se pueden tener a su vez dos tipos distintos dentro de esta misma categoría:
IMPLEMENTADO CON SQL REMOTO
En este esquema el cliente envía mensajes con solicitudes SQL al servidor de bases de datos y el resultado de cada instrucción SQL es devuelto por la red, no importando si son uno, diez, cien o mil registros. Es el mismo cliente quien debe procesar todos los registros que le fueron devueltos por el servidor de base de datos, según el requerimiento que él mismo hizo. Esto hace que este tipo de estructura se adecue a los requerimientos de aplicaciones orientadas a los sistemas de apoyo y gestión, pero resultan inadecuados para los sistemas críticos en que se requieran bajos tiempos de respuesta.
Ventajas:
Presenta una estructura de desarrollo bastante simple ya que el programador maneja un único ambiente de desarrollo (es más simple respecto al Cliente/Servidor en tres planos, puesto que reduce una capa de programación, como se verá más adelante).
Inconvenientes:
La gran cantidad de información que viaja al cliente congestiona demasiado el tráfico de red, lo que se traduce en bajo rendimiento.
Por su bajo rendimiento esta estructura tiene un bajo espectro de aplicación, limitándose a la construcción de sistemas no críticos.
Presenta una estructura de desarrollo bastante simple ya que el programador maneja un único ambiente de desarrollo (es más simple respecto al Cliente/Servidor en tres planos, puesto que reduce una capa de programación, como se verá más adelante).
Inconvenientes:
La gran cantidad de información que viaja al cliente congestiona demasiado el tráfico de red, lo que se traduce en bajo rendimiento.
Por su bajo rendimiento esta estructura tiene un bajo espectro de aplicación, limitándose a la construcción de sistemas no críticos.
IMPLEMENTADO CON PROCEDIMIENTOS ALMACENADOS
En este esquema el cliente envía llamadas a funciones que residen en la base de datos, y es ésta quien resuelve y procesa la totalidad de las instrucciones SQL agrupadas en la mencionada función.
Ventajas: Presenta las mismas ventajas de una arquitectura dos planos con procedimientos almacenados, pero mejora considerablemente el rendimiento sobre ésta, dado que reduce el tráfico por la red al procesar los datos en la misma base de datos, haciendo viajar sólo el resultado final de un conjunto de instrucciones SQL.
Inconvenientes: Si bien la complejidad de desarrollo se ve disminuida, se pierde flexibilidad y escalabilidad en las soluciones implantadas. Obliga a basar el peso de la aplicación en SQL extendido, propios del proveedor de la base de datos que se elija. Debiera considerarse que sí bien los procedimientos almacenados (stored procedures), los desencadenantes (triggers) y las reglas (constraint) son útiles, en rigor son ajenos al estándar de SQL
En este esquema el cliente envía llamadas a funciones que residen en la base de datos, y es ésta quien resuelve y procesa la totalidad de las instrucciones SQL agrupadas en la mencionada función.
Ventajas: Presenta las mismas ventajas de una arquitectura dos planos con procedimientos almacenados, pero mejora considerablemente el rendimiento sobre ésta, dado que reduce el tráfico por la red al procesar los datos en la misma base de datos, haciendo viajar sólo el resultado final de un conjunto de instrucciones SQL.
Inconvenientes: Si bien la complejidad de desarrollo se ve disminuida, se pierde flexibilidad y escalabilidad en las soluciones implantadas. Obliga a basar el peso de la aplicación en SQL extendido, propios del proveedor de la base de datos que se elija. Debiera considerarse que sí bien los procedimientos almacenados (stored procedures), los desencadenantes (triggers) y las reglas (constraint) son útiles, en rigor son ajenos al estándar de SQL
MODELO CLIENTE/SERVIDOR 3 CAPAS
Esta estructura se caracteriza por elaborar la aplicación en base a dos capas principales de software, más la capa correspondiente al servidor de base de datos. Al igual que en la arquitectura dos capas, y según las decisiones de diseño que se tomen, se puede balancear la carga de trabajo entre el proceso cliente y el nuevo proceso correspondiente al servidor de aplicación.
En este esquema el cliente envía mensajes directamente al servidor de aplicación el cual debe administrar y responder todas las solicitudes. Es el servidor, dependiendo del tipo de solicitud, quien accede y se conecta con la base de datos.
Ventajas:
Reduce el tráfico de información en la red por lo que mejora el rendimiento de los sistemas (especialmente respecto a la estructura en dos planos).
Brinda una mayor flexibilidad de desarrollo y de elección de plataformas sobre la cual montar las aplicaciones. Provee escalabilidad horizontal y vertical.
Se mantiene la independencia entre el código de la aplicación (reglas y conocimiento del negocio) y los datos, mejorando la portabilidad de las aplicaciones.
Los lenguajes sobre los cuales se desarrollan las aplicaciones son estándares lo que hace más exportables las aplicaciones entre plataformas.
Dado que mejora el rendimiento al optimizar el flujo de información entre componentes, permite construir sistemas críticos de alta fiabilidad.
El mismo hecho de localizar las reglas del negocio en su propio ambiente, en vez de distribuirlos en la capa de interfaz de usuario, permite reducir el impacto de hacer mantenimiento, cambios urgentes de última hora o mejoras al sistema.
Disminuye el número de usuarios (licencias) conectados a la base de datos.
Inconvenientes:
Dependiendo de la elección de los lenguajes de desarrollo, puede presentar mayor complejidad en comparación con Cliente/Servidor dos planos.
Existen pocos proveedores de herramientas integradas de desarrollo con relación al modelo Cliente/Servidor dos planos, y normalmente son de alto costo.
Esta estructura se caracteriza por elaborar la aplicación en base a dos capas principales de software, más la capa correspondiente al servidor de base de datos. Al igual que en la arquitectura dos capas, y según las decisiones de diseño que se tomen, se puede balancear la carga de trabajo entre el proceso cliente y el nuevo proceso correspondiente al servidor de aplicación.
En este esquema el cliente envía mensajes directamente al servidor de aplicación el cual debe administrar y responder todas las solicitudes. Es el servidor, dependiendo del tipo de solicitud, quien accede y se conecta con la base de datos.
Ventajas:
Reduce el tráfico de información en la red por lo que mejora el rendimiento de los sistemas (especialmente respecto a la estructura en dos planos).
Brinda una mayor flexibilidad de desarrollo y de elección de plataformas sobre la cual montar las aplicaciones. Provee escalabilidad horizontal y vertical.
Se mantiene la independencia entre el código de la aplicación (reglas y conocimiento del negocio) y los datos, mejorando la portabilidad de las aplicaciones.
Los lenguajes sobre los cuales se desarrollan las aplicaciones son estándares lo que hace más exportables las aplicaciones entre plataformas.
Dado que mejora el rendimiento al optimizar el flujo de información entre componentes, permite construir sistemas críticos de alta fiabilidad.
El mismo hecho de localizar las reglas del negocio en su propio ambiente, en vez de distribuirlos en la capa de interfaz de usuario, permite reducir el impacto de hacer mantenimiento, cambios urgentes de última hora o mejoras al sistema.
Disminuye el número de usuarios (licencias) conectados a la base de datos.
Inconvenientes:
Dependiendo de la elección de los lenguajes de desarrollo, puede presentar mayor complejidad en comparación con Cliente/Servidor dos planos.
Existen pocos proveedores de herramientas integradas de desarrollo con relación al modelo Cliente/Servidor dos planos, y normalmente son de alto costo.
A NIVEL DE HARDWARE
Esta clasificación del modelo Cliente/Servidor se basa igualmente en la distribución de los procesos y elementos entre sus componentes, pero centrándose en la parte física del mismo, en el que la administración de la interfaz gráfica se asocia a los clientes PC y la seguridad e integridad de los datos quedan asociados a ambientes mainframe o por lo menos a servidores locales y/o centrales.
Esta clasificación del modelo Cliente/Servidor se basa igualmente en la distribución de los procesos y elementos entre sus componentes, pero centrándose en la parte física del mismo, en el que la administración de la interfaz gráfica se asocia a los clientes PC y la seguridad e integridad de los datos quedan asociados a ambientes mainframe o por lo menos a servidores locales y/o centrales.
MODELO CLIENTE / SERVIDOR 2 CAPAS
Los clientes son conectados vía LAN a un servidor de aplicaciones local, el cual, dependiendo de la aplicación puede dar acceso a los datos administrados por él.
MODELO CLIENTE / SERVIDOR 3 CAPAS
Los clientes son conectados vía LAN a un servidor de aplicaciones local, el cual a su vez se comunica con un servidor central de bases de datos. El servidor local tiene un comportamiento dual, dado que actúa como cliente o servidor en función de la dirección de la comunicación.
Los clientes son conectados vía LAN a un servidor de aplicaciones local, el cual, dependiendo de la aplicación puede dar acceso a los datos administrados por él.
MODELO CLIENTE / SERVIDOR 3 CAPAS
Los clientes son conectados vía LAN a un servidor de aplicaciones local, el cual a su vez se comunica con un servidor central de bases de datos. El servidor local tiene un comportamiento dual, dado que actúa como cliente o servidor en función de la dirección de la comunicación.
MODELOS CLIENTE / SERVIDOR SEGÚN EL REPARTO DE FUNCIONES ENTRE CLIENTE Y SERVIDOR.
Separación de funciones.
Las distintas arquitecturas cliente/servidor presentan variaciones acerca de cómo son distribuidas las diferentes funciones de las aplicaciones de sistemas entre el cliente y el servidor, sobre la base de los conceptos de los tres componentes generales de cualquier SI:
La lógica de acceso a datos. Funciones que gestionan todas las interacciones entre el SW y los almacenes de datos (archivos, bases de datos, etc.) incluyendo recuperación/consulta, actualización, seguridad y control de concurrencia.
La lógica de presentación. Funciones que gestionan la interfaz entre los usuarios del sistema y el SW, incluyendo la visualización e impresión de formas y reportes, y la posibilidad de validar entradas del sistema.
La lógica de negocio o lógica de la aplicación. Funciones que transforman entradas en salidas, incluyendo desde simples sumas hasta complejos modelos matemáticos, financieros, científicos, de ingeniería, etc.
Según cómo se distribuyan las funciones correspondientes a estas tres lógicas o funciones de un sistema entre cliente, middleware y servidor (los principales componentes de un sistema con arquitectura distribuída) nos podemos encontrar con los siguientes tipos de arquitectura cliente / servidor (conforme a la célebre clasificación hecha por el Gartner Group):
Presentación Distribuida.
Presentación remota.
Acceso a datos remoto.
Lógica o procesamiento distribuídas.
Bases de datos distribuídas.
La importancia de esta clasificación radica en que permite jugar con el ancho de banda de la red y con la capacidad de proceso de los componentes hardware del sistema para repartir entre ellos la carga de proceso de las lógicas de la aplicación. Seguidamente entraremos en más detalle sobre estos tipos de arquitectura.
Presentación distribuída.
El cliente asume parte de las funciones de presentación de la aplicación, ya que siguen existiendo programas en el servidor dedicados a esta tarea. El resto de funciones de la aplicación (negocio, acceso a datos) residen en el servidor.
Esta arquitectura se utiliza para construir emuladores de terminal, aplicaciones de control remoto, front ends gráficos de aplicaciones que residen en un host, etc. Algunos ejemplos de productos que siguen esta filosofía son VLC, Microsoft Terminal Server, Cytrix Metaframe, emulador de host para sistemas operativos modernos como Windows, etc.
La gran ventaja de esta arquitectura es que permite revitalizar sistemas antiguos. Así, las aplicaciones antiguas que funcionaban en entornos host pueden ser empleadas desde modernas estaciones de trabajo Windows o Microsoft (que solamente hacen la función de términal del host incrustada en un entorno de trabajo de escritorio moderno).
El principal problema es que no se elimina la dependencia del host, no siendo posible la aplicación de los conceptos de downsizing o rightsizing.
Presentación remota.
Toda la lógica de negocio y acceso a datos se ejecuta en el servidor, que en esta ocasión no realiza ninguna función relacionada con la presentación. Todas las funciones de presentación son ejecutadas en el cliente. Un ejemplo de este tipo de aplicaciones son las aplicaciones web, las de los terminales de cajeros automáticos, etc.
La principal ventaja es que la interfaz de usuario se adapta bien a las capacidades del entorno cliente (en la presentación distribuída el servidor tenía que ejecutar funciones dentro de un entorno que podría no ser el más apropiado para el cliente). La principal desventaja es que toda la información necesaria para la presentación tiene que circular por la red desde el servidor al cliente.
Lógica o proceso distribuído.
La lógica de los procesos se divide entre los distintos componentes del cliente y del servidor. El diseñador de la aplicación debe definir los servicios y las interfaces del sistema de información de forma que los papeles de cliente y servidor sean intercambiables, excepto en el control de los datos que es responsabilidad exclusiva del servidor. En este tipo de situaciones se dice que hay un proceso distribuido o cooperativo.
La principal ventaja de esta arquitectura es que cada uno de los nodos/servidores puede especializarse en un área determinada, de forma que cada proceso se ejecutará en el nodo más apropiado. Además, se pueden reutilizar los sistemas ya existentes (es una especie de antesala delconcepto de SOA).
En contrapartida, este tipo de sistemas son más dificiles de diseñar, de mantener y de probar.
Acceso a datos remoto.
El cliente realiza tanto las funciones de presentación como los procesos. Por su parte, el servidor almacena y gestiona los datos que permanecen en una base de datos centralizada. En esta situación se dice que hay una gestión de datos remota.
La principal ventaja de esta arquitectura radica en su sencillez de uso, y su proliferación al ser adaptada por lenguajes de cuarta generación (como Oracle Forms). La desventaja es la latencia de red introducida. Al descargarse toda la lógica de proceso en los aplicativos clientes, estos necesitan descargar los datos necesarios (entradas al proceso) que circulan por la red.
Bases de datos distribuídas.
Este modelo es similar al de Acceso a Datos Remoto, pero además el gestor de base de datos divide sus componentes entre el cliente y el servidor. Las interfaces entre ambos están dentro de las funciones del gestor de datos y, por lo tanto, no tienen impacto en el desarrollo de las aplicaciones. En este nivel se da lo que se conoce como bases de datos distribuidas.
La principal ventaja de este modelo es que facilita el acceso a los datos desde entornos heterogéneos. Los componentes de acceso a datos ubicados en el cliente permiten independizar la base de datos del entorno en el que corren las aplicaciones cliente. Además, permite implementar la "transparencia de ubicación". Este sistema presenta dos importantes inconvenientes:
Las bases de datos distribuídas son más difíciles de implementar, y son dependientes del gestor de base de datos (siempre que no existan acuerdos y estándares)
La integridad de los datos puede verse comprometida.
Separación de funciones.
Las distintas arquitecturas cliente/servidor presentan variaciones acerca de cómo son distribuidas las diferentes funciones de las aplicaciones de sistemas entre el cliente y el servidor, sobre la base de los conceptos de los tres componentes generales de cualquier SI:
La lógica de acceso a datos. Funciones que gestionan todas las interacciones entre el SW y los almacenes de datos (archivos, bases de datos, etc.) incluyendo recuperación/consulta, actualización, seguridad y control de concurrencia.
La lógica de presentación. Funciones que gestionan la interfaz entre los usuarios del sistema y el SW, incluyendo la visualización e impresión de formas y reportes, y la posibilidad de validar entradas del sistema.
La lógica de negocio o lógica de la aplicación. Funciones que transforman entradas en salidas, incluyendo desde simples sumas hasta complejos modelos matemáticos, financieros, científicos, de ingeniería, etc.
Según cómo se distribuyan las funciones correspondientes a estas tres lógicas o funciones de un sistema entre cliente, middleware y servidor (los principales componentes de un sistema con arquitectura distribuída) nos podemos encontrar con los siguientes tipos de arquitectura cliente / servidor (conforme a la célebre clasificación hecha por el Gartner Group):
Presentación Distribuida.
Presentación remota.
Acceso a datos remoto.
Lógica o procesamiento distribuídas.
Bases de datos distribuídas.
La importancia de esta clasificación radica en que permite jugar con el ancho de banda de la red y con la capacidad de proceso de los componentes hardware del sistema para repartir entre ellos la carga de proceso de las lógicas de la aplicación. Seguidamente entraremos en más detalle sobre estos tipos de arquitectura.
Presentación distribuída.
El cliente asume parte de las funciones de presentación de la aplicación, ya que siguen existiendo programas en el servidor dedicados a esta tarea. El resto de funciones de la aplicación (negocio, acceso a datos) residen en el servidor.
Esta arquitectura se utiliza para construir emuladores de terminal, aplicaciones de control remoto, front ends gráficos de aplicaciones que residen en un host, etc. Algunos ejemplos de productos que siguen esta filosofía son VLC, Microsoft Terminal Server, Cytrix Metaframe, emulador de host para sistemas operativos modernos como Windows, etc.
La gran ventaja de esta arquitectura es que permite revitalizar sistemas antiguos. Así, las aplicaciones antiguas que funcionaban en entornos host pueden ser empleadas desde modernas estaciones de trabajo Windows o Microsoft (que solamente hacen la función de términal del host incrustada en un entorno de trabajo de escritorio moderno).
El principal problema es que no se elimina la dependencia del host, no siendo posible la aplicación de los conceptos de downsizing o rightsizing.
Presentación remota.
Toda la lógica de negocio y acceso a datos se ejecuta en el servidor, que en esta ocasión no realiza ninguna función relacionada con la presentación. Todas las funciones de presentación son ejecutadas en el cliente. Un ejemplo de este tipo de aplicaciones son las aplicaciones web, las de los terminales de cajeros automáticos, etc.
La principal ventaja es que la interfaz de usuario se adapta bien a las capacidades del entorno cliente (en la presentación distribuída el servidor tenía que ejecutar funciones dentro de un entorno que podría no ser el más apropiado para el cliente). La principal desventaja es que toda la información necesaria para la presentación tiene que circular por la red desde el servidor al cliente.
Lógica o proceso distribuído.
La lógica de los procesos se divide entre los distintos componentes del cliente y del servidor. El diseñador de la aplicación debe definir los servicios y las interfaces del sistema de información de forma que los papeles de cliente y servidor sean intercambiables, excepto en el control de los datos que es responsabilidad exclusiva del servidor. En este tipo de situaciones se dice que hay un proceso distribuido o cooperativo.
La principal ventaja de esta arquitectura es que cada uno de los nodos/servidores puede especializarse en un área determinada, de forma que cada proceso se ejecutará en el nodo más apropiado. Además, se pueden reutilizar los sistemas ya existentes (es una especie de antesala delconcepto de SOA).
En contrapartida, este tipo de sistemas son más dificiles de diseñar, de mantener y de probar.
Acceso a datos remoto.
El cliente realiza tanto las funciones de presentación como los procesos. Por su parte, el servidor almacena y gestiona los datos que permanecen en una base de datos centralizada. En esta situación se dice que hay una gestión de datos remota.
La principal ventaja de esta arquitectura radica en su sencillez de uso, y su proliferación al ser adaptada por lenguajes de cuarta generación (como Oracle Forms). La desventaja es la latencia de red introducida. Al descargarse toda la lógica de proceso en los aplicativos clientes, estos necesitan descargar los datos necesarios (entradas al proceso) que circulan por la red.
Bases de datos distribuídas.
Este modelo es similar al de Acceso a Datos Remoto, pero además el gestor de base de datos divide sus componentes entre el cliente y el servidor. Las interfaces entre ambos están dentro de las funciones del gestor de datos y, por lo tanto, no tienen impacto en el desarrollo de las aplicaciones. En este nivel se da lo que se conoce como bases de datos distribuidas.
La principal ventaja de este modelo es que facilita el acceso a los datos desde entornos heterogéneos. Los componentes de acceso a datos ubicados en el cliente permiten independizar la base de datos del entorno en el que corren las aplicaciones cliente. Además, permite implementar la "transparencia de ubicación". Este sistema presenta dos importantes inconvenientes:
Las bases de datos distribuídas son más difíciles de implementar, y son dependientes del gestor de base de datos (siempre que no existan acuerdos y estándares)
La integridad de los datos puede verse comprometida.
