6 DE SEPTIEMBRE DEL 2003

CLIENTE- SERVIDOR EQUIPO

Introducción

Es un hecho que la información es el capital más importante que las empresas poseen. Las nuevas tecnologías permiten digitalizar la mayoría de los servicios y seguramente esta tendencia seguirá en aumento.

Las tareas deben de ser controladas por la aplicación cliente / servidor y deben ser consideradas como parte del desarrollo, no resulta fácil dado el rápido cambio de estas tecnologías y la gran cantidad de conceptos involucrados.

            Entre las primeras cosas que hay que decir de la arquitectura cliente /servidor, es que estamos frente a la plataforma abierta por excelencia.

Esta arquitectura permite distribuir físicamente los procesos y los datos en forma más eficiente lo que en computación distribuida afecta directamente el tráfico de la red, reduciéndolo grandemente.

Se requieren conocimientos de varias áreas y que las decisiones tomadas respecto del diseño deben ser las adecuadas.

            La tecnología cliente / servidor es el procesamiento cooperativo de la información por medio de un conjunto de procesadores, en el cual múltiples clientes, distribuidos geográficamente, solicitan requerimientos a uno o más servidores centrales.

En un modelo cliente / servidor el cliente envía un mensaje solicitando un determinado servicio a un servidor y este envía uno o varios mensajes con la respuesta. Tanto clientes como servidores son entidades independientes que operan conjuntamente a través de una red para realizar una tarea.

- Se establece una relación entre procesos distintos, los cuales pueden ser ejecutados en la misma máquina o en máquinas diferentes distribuidas a lo largo de la red.

- Existe una clara distinción de funciones basada en el concepto de “servicio”, que se establece entre clientes y servidores.

- La relación establecida pude ser de mucho a a uno, en la que un servidor puede dar servicio a muchos clientes, regulando su acceso a recursos compartidos.

- Los clientes corresponden a procesos activos en cuanto a que son éstos los que hacen peticiones de servicios a los servidores. Estos últimos tienen un carácter pasivo ya que esperan las peticiones de los clientes.

- No existe otra relación entre clientes y servidores que no sea la que se establece a través del intercambio de mensajes entre ambos. El mensaje es el mecanismo para la petición y entrega de solicitudes de servicio.

- Las plataformas de software y hardware entre clientes y servidores son independientes. Una de las principales ventajas de ésta arquitectura es la posibilidad de conectar clientes y servidores independientemente de sus plataformas.

-  El concepto de escalabilidad tanto horizontal como vertical es aplicable a cualquier sistema cliente / servidor. La escalabilidad horizontal permite agregar más estaciones de trabajo activas sin afectar el rendimiento. La escalabilidad vertical permite mejorar las características del servidor o agregar múltiples servidores.

Componentes del modelo Cliente/Servidor

Cliente

•          Administrar la interfaz de usuario.

•          Interactuar con el usuario.

•          Procesar la lógica de la aplicación y hacer validaciones locales.

•          Generar requerimientos de bases de datos.

•          Recibir resultados del servidor.

•          Formatear resultados.

Servidor

•          Aceptar los requerimientos de bases de datos que hacen los clientes.

•          Procesar requerimientos de bases de datos.

•          Formatear datos para trasmitirlos a los clientes.

•          Procesar la lógica de la aplicación y realizar validaciones a nivel de bases de datos.

Middleware .- Modelo intermedio que actúa como conductor entre 2 módulos de software.

» Por tamaño de componentes

Este tipo de clasificación se basa en los grados de libertad que brinda el modelo cliente/servidor para balancear la carga de proceso entre los niveles de presentación, aplicación y base de datos. Dependiendo de que segmento de las capas de software tenga que soportar la mayor o menor carga de procesamiento, se habla de Fat Cliente (Thin Server) o Fat server (Thin Client).

» Por planos o capas (Tier)

Una de las más comunes y discutidas distinciones entre las diferentes arquitecturas cliente/servidor se basan en la idea de planos (tier), la cual es una variación sobre la división o clasificación por tamaño de componentes (clientes grandes y servidores amplios). 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 que 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.

» Por tamaño de componentes

* Fat Client (Thin Server)

En este esquema de arquitectura el grueso de la aplicación es ejecutada en el cliente, es decir, el nivel de presentación y el nivel de aplicación corren en un único proceso cliente, y el servidor es relegado a realizar las funciones que provee un administrador de base de datos.

*Fat Server (Thin Client)

Este es el caso opuesto al anterior, el proceso cliente es restringido a la presentación de la interfaz de usuario, mientras que el grueso de la aplicación corre por el lado del servidor de aplicación.

En general este tipo de arquitectura presenta una flexibilidad mayor como para desarrollar un gran espectro de aplicaciones, incluyendo los sistemas de misión crítica a través de servidores de transacciones.

» Por planos o capas (Tier)

-Planos a niveles 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.

1.  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.

*Ventajas:

- Presenta una estructura de desarrollo bastante simple por cuanto el programador típicamente maneja un único ambiente de desarrollo.

*Desventajas:

- La gran cantidad de información que viaja al cliente congestiona demasiado el tráfico de red, lo que se traduce en bajo rendimiento.

2.  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.

*Desventajas:

- Se pierde flexibilidad y escalabilidad en las soluciones implantadas

- No existen dos implementaciones de proveedores iguales.

- Se pierde la independencia entre el código de la aplicación (conocimiento y reglas del negocio) y los datos.

Cliente/Servidor Tres Planos.

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 de la estructura en dos planos).

- 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.

- Dado que mejora el rendimiento al optimizar el flujo de información entre componentes, permite construir sistemas críticos de alta confiabilidad.

- 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.

Desventajas:

- Dependiendo de la elección de los lennguajes 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.

Planos a niveles de hardware.

Cliente/Servidor Dos Planos.

Como se ve en la figura, 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.

Cliente/Servidor Tres Planos.

Como se ve en la figura, 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.

Cliente/Servidor Múltiples Planos.

Este esquema permite que las PCs clientes puedan conectarse directamente a un servidor de bases de datos, pasando por alto a los servidores locales, los cuales son utilizados como simples servidores de archivos.

Servidores de Bases de Datos

Esta relacionado con la arquitectura en dos planos, descrita anteriormente. Obviamente la creación de aplicaciones cliente/servidor está asociada a la utilización de servidores de bases de datos relacionales SQL, y dependiendo de los requerimientos y restricciones se debe elegir entre una arquitectura dos o tres planos. Pero una arquitectura centrada en un servidor de bases de datos, cualquiera de las modalidades dos planos, permite que un proceso cliente solicite datos y servicios directamente a un servidor de bases de datos. El servidor debe proveer un acceso compartido a los datos con los mecanismos de protección necesarios, así como proveer mecanismos para seleccionar resultados dentro de un conjunto de datos, posibilitando un ahorro en procesos de comunicación. El servidor debe también proveer mecanismos de concurrencia, seguridad y consistencia de datos, basado principalmente en el concepto de transacción en el que todo se realiza, y por lo tanto se hace permanente, o todo falla, anulándose la transacción en tal caso.

Los servidores de bases de datos actuales son una mezcla de SQL estándar más otras extensiones propias de cada proveedor. Por ejemplo casi todas las bases de datos están provistas con procedimientos almacenados (stored procedures), desencadenantes (triggers) y restricciones (constraints) pero presentan diferencias importantes en su implementación. Es claro que esto obedece a presiones comerciales para tratar de extender los mecanismos de bases de datos para que realicen más funciones de las que corresponden a un servidor SQL relacional, con el objeto de tener una mayor participación en el espectro de los sistemas cliente/servidor por parte de los proveedores de bases de datos y como una manera de diferenciar sus productos.

Procedimientos Almacenados

Una de las posibilidades de implementar de mejor forma un sistema cliente/servidor en dos planos (two-tier), sin olvidar todas sus restricciones y limitaciones, es a través de procedimientos almacenados, que son funciones que agrupan un conjunto de instrucciones y lógica de procedimientos SQL, los cuales son compilados y almacenados en la misma base.

El rol principal de los procedimientos almacenados es proveer la parte servidora de la lógica de una aplicación cliente/servidor, es decir vendría a reemplazar al servidor de aplicaciones en una arquitectura tres planos (three-tier). Con todo, si bien los procedimientos almacenados permiten a un servidor brindar servicios aptos para OLTP (On Line Transaction Proccesing), no se compara con los rendimientos alcanzados por una arquitectura en tres planos con TP pesado.

Desencadenantes :  Son mecanismos que permiten realizar acciones automáticamente sobre los datos, las cuales están asociadas a algún evento definido. Normalmente son implementados a través de procedimientos almacenados. Los eventos a los cuales se hace referencia están asociados a las actualizaciones de tablas mediante sentencias delete, insert o update, y son llamados implícitamente al suceder cualquiera de estos eventos, a diferencia de los procedimientos almacenados que son llamados explícitamente por un proceso cliente.

Restricciones : Al igual que los desencadenantes, son acciones que se realizan asociadas a algún evento determinado y están orientadas a llevar a cabo validaciones más simples de datos. Los tipos de eventos son los mismos que para los desencadenantes como son sentencias delete, insert o update.

Servidores de transacciones

Estos tipos de sistemas se pueden implementar con cualquiera de las modalidades cliente/servidor en dos o tres planos, pero incorporan un elemento principal sobre el cual se elabora y basa toda la fortaleza de este modelo, el concepto de transacción.

Tal cual se explica mediante los conceptos de planos, tamaños de componentes y servidores de bases de datos, con un servidor de transacciones el proceso cliente llama a funciones, procedimientos o métodos que residen en el servidor, ya sea que se trate de un servidor de bases de datos o un servidor de aplicaciones. Lo importante es que el intercambio a través de la red se realiza mediante un único mensaje de solicitud/respuesta, es decir, independientemente de que se necesite ejecutar una o más funciones, una o más instrucciones o sentencias SQL, éstas son agrupadas en una unidad lógica llamada transacción; evitando así el intercambio a través de la red de un mensaje solicitud/respuesta por cada sentencia SQL, el cual es el caso de los sistemas cliente/servidor dos planos, implementados a través de SQL remoto. Estas aplicaciones denominadas OLTP (On Line Transaction Proccesing) están orientadas a dar soporte a los procedimientos y reglas de los sistemas de misión crítica.