Cliente servidor/Middleware

MODELO CLIENTE SERVIDOR

El modelo cliente-servidor de un sistema distribuido es el modelo más conocido y más ampliamente adoptado en la actualidad. Hay un conjunto de procesos servidores, cada uno actuando como un gestor de recursos para una colección de recursos de un tipo, y una colección de procesos clientes, cada uno llevando a cabo una tarea que requiere acceso a algunos recursos hardware y software compartidos. Los gestores de recursos a su vez podrían necesitar acceder a recursos compartidos manejados por otros procesos, así que algunos procesos son ambos clientes y servidores. En el modelo, cliente-servidor, todos los recursos compartidos son mantenidos y manejados por los procesos servidores. Los procesos clientes realizan peticiones a los servidores cuando necesitan acceder a algún recurso. Si la petición es valida, entonces el servidor lleva a cabo la acción requerida y envía una respuesta al proceso cliente.

El termino proceso se usa aquí en el sentido clásico de los sistemas operativos. Un proceso es un programa en ejecución. Consiste en un entorno de ejecución con al menos un thread de control.

El modelo cliente-servidor nos da un enfoque efectivo y de propósito general para la compartición de información y de recursos en los sistemas distribuidos. El modelo puede ser implementado en una gran variedad de entornos software y hardware. Las computadoras que ejecuten los programas clientes y servidores pueden ser de muchos tipos y no existe la necesidad de distinguir entre ellas; los procesos cliente y servidor pueden incluso residir en la misma maquina.

En esta visión simple del modelo cliente-servidor, cada proceso servidor podría ser visto como un proveedor centralizado de los recursos que maneja. La provisión de recursos centralizada no es deseable en los sistemas distribuidos. Es por esta razón por lo que se hace una distinción entre los servicios proporcionados a los clientes y los servidores encargados de proveer dichos servicios. Se considera un servicio como una entidad abstracta que puede ser provista por varios procesos servidores ejecutándose en computadoras separadas y cooperando vía red.

El modelo cliente-servidor se ha extendido y utilizado en los sistemas actuales con servicios manejando muchos diferentes tipos de recursos compartidos – correo electrónico y mensajes de noticias, ficheros, sincronización de relojes, almacenamiento en disco, impresoras, comunicaciones de área extensa, e incluso las interfaces gráficas de usuario. Pero no es posible que todos los recursos que existen en un sistema distribuido sean manejados y compartidos de esta manera; algunos tipos de recursos deben permanecer locales a cada computadora de cara a una mayor eficiencia – RAM, procesador, interfaz de red local -. Estos recursos clave son manejados separadamente por un sistema operativo en cada maquina; solo podrían ser compartidos entre procesos localizados en el mismo ordenador.

Aunque el modelo cliente-servidor no satisface todos los requisitos necesarios para todas las aplicaciones distribuidos, es adecuado para muchas de las aplicaciones actuales y provee una base efectiva para los sistemas operativos distribuidos de propósito general.

MIDDLEWARE

El término middleware se discute en [Lewandosky 1998]. El software distribuido requerido para facilitar las interacciones cliente-servidor se denomina middleware. El acceso transparente a servicios y recursos no locales distribuidos a través de una red se provee a través del middleware, que sirve como marco para la comunicaciones entre las porciones cliente y servidor de un sistema.

El middleware define: el API que usan los clientes para pedir un servicio a un servidor, la transmisión física de la petición vía red, y la devolución de resultados desde el servidor al cliente. Ejemplos de middleware estándar para dominios específicos incluyen: ODBC, para bases de datos, Lotus para groupware, HTTP y SSL para Internet y CORBA, DCOM y JAVA RMI para objetos distribuidos.

El middleware fundamental o genérico es la base de los sistemas cliente-servidor. Los servicios de autentificación en red, llamadas a procedimiento remoto, sistemas de ficheros distribuidos y servicios de tiempo en red se consideran parte del middleware genérico. Este tipo de middleware empieza a ser parte estándar de los sistemas operativos modernos como Windows NT. En sistemas donde no se disponga deberá recurrirse a middlware del tipo OSD DCE (Distributed Computing Environment) [OSF 1994]. El middleware especifico para un dominio complementa al middlware genérico de cara a aplicaciones mucho mas especificas.

El protocolo de comunicaciones mas usado por el middlware, tanto genérico como especifico, es TCP/IP. Esto se debe a su amplia difusión en todos los sistemas operativos del mercado y en especial en los ordenadores personales.

MIDDLEWARE PARA SISTEMAS CLIENTE-SERVIDOR

Un servicio proporcionado por un servidor no es más que un conjunto de operaciones disponibles para los clientes. El acceso al servicio se realiza mediante un protocolo de peticiones respuesta con llamadas bloqueantes. Ejemplo: Un servicio de ficheros. El servidor mantiene como recurso compartido los ficheros. Sobre el recurso compartido se pueden realizar diversas operaciones: Crear, Abrir, Leer, etc.

Los mecanismos RPC persiguen que los clientes se abstraigan e invoquen procedimientos remotos (operaciones) para obtener servicios. Así, el procedimiento llamado se ejecuta en otro proceso de otra maquina (servidor). El objetivo de RPC es mantener la semántica de la llamada a procedimiento normal en un entorno de implementación totalmente distinto. La ventaja esta en que el desarrollador se preocupa de los interfaces que soporta el servidor. Para especificar dichos interfaces se dispones de un IDL (lenguaje de definición de interfaces).

Los sistemas RPC disponen de mecanismos de RPC integrados en un lenguaje de programación particular que incluye además una notación para definir interfaces entre clientes y servidores (IDL especifico). Un IDL permite definir el nombre de las operaciones soportadas por el servidor y sus parámetros (tipo y dirección). También se deben proveer mecanismos para manejo de excepciones, garantizar la ejecución de las operaciones, así como la detección de fallos. Todo ello de la forma mas transparente posible.

El software (middleware) que soporta RPC tiene tres tareas fundamentales:

1. Procesamiento relacionado con los interfaces: Integrar RPC en el entorno de programación, empaquetamiento (marshalling)/desempaquetamiento (unmarshalling) y despachar las peticiones al procedimiento adecuado.
2. Gestionar las comunicaciones
3. Enlazado (Binding): Localizar al servidor de un servicio.

La interfaz no es mas que un numero de procedimiento acordado entre cliente y servidor. Este numero viaja dentro del mensaje RPC transmitido por la red. En la parte cliente existe un procedimiento de ‘stub’ encargado de empaquetar/desempaquetar los argumentos de la llamada, convertir la llamada local en una llamada remota. Esto supone enviar un mensaje, esperar la respuesta y retornar los resultados. En la parte del servidor esta el despachador, junto con el conjunto de procedimientos de stub de servidor, que tienen una misión similar a los de la parte cliente. El despachador selecciona el procedimiento de stub adecuado a partir del numero de procedimiento requerido.

El compilador de IDL genera los procedimientos de stub de cliente y de servidor, las operaciones de empaquetamiento y desempaquetamiento así como los ficheros de cabecera necesarios.

Las peticiones de los clientes son con respecto a un nombre de servicio. En ultima instancia deben ser dirigidas a un puerto en el servidor. En un sistema distribuido un binder es un servicio separado que mantiene una tabla que contiene correspondencias de nombres de servicios con puertos de servidor. Se trata, como veremos más adelante, de un servicio de nombres. Importar un servicio es pedir al binder que busque el nombre del interfaz y retorne el puerto del servidor. Exportar un servicio es registrarlo de cara el binder. El binder deberá estar en un puerto bien conocido o, al menos, se le podrá localizar.

Una implementación bastante habitual de RPC es la de SUN. Incorpora todo un conjunto de primitivas para trabajar con RPC en lenguaje C. Dispone de una representación neutral de los datos para su empaquetamiento, XDR (External Data Representation). XDR también se denomina al IDL que se proporciona.

El compilador de IDL, que se denomina rpcgen, genera los procedimientos de stub, el procedimiento main del servidor y el despachador, el código de conversión de los parámetros a XDR, así como los ficheros de cabecera correspondientes.

El binder recibe el nombre de port mapper. Cuando se activa un servidor en una máquina remota ésta se registra con el port mapper, obteniendo un puerto de comunicación a través del cuál escuchar. Cuando se quiere acceder a un servicio hay que contactar con el port mapper de la máquina remota, preguntándole por el nombre de un determinado servicio, devolviéndose el puerto de comunicación en el que está a la escucha el servidor correspondiente. Por tanto para acceder a una determinada operación de un servicio hace falta la siguiente información: [host:servicio:procedimiento].

SERVIDORES PESADOS VS CLIENTES PESADOS

[Lewandowsky 1008] realiza una discusión de este concepto dentro del marco de los sistemas cliente-servidor. Los especialistas en sistemas de información califican como ‘pesada’ (fat) una parte de un sistema con una cantidad de funcionalidad desproporcionada. Por el contrario, una parte de sistema se considera ligera (thin) si tiene menos responsabilidades [Orfali 1996].

En un sistema cliente-servidor la porción del servidor casi siempre mantiene los datos, mientras que la porción del cliente es responsable de la interfaz de usuario. El desplazamiento de la lógica de la aplicación constituye la distinción entre clientes ‘pesados’ y servidores ‘pesados’. Los sistemas servidores ‘pesados’ delegan más responsabilidad de la lógica de la aplicación en los servidores, mientras que los clientes ‘pesados’ dan al cliente mayor responsabilidad. Ejemplo de servidor pesado es un servidor Web, mientras que muchos de los clientes en sistemas de bases de datos constituyen clientes ‘pesados’.

Aunque los sistemas basados en servidores ‘pesados’ han sido los más utilizados en el pasado, en la actualidad muchos diseñadores prefieren sistemas con clientes ‘pesados’, debido a que son más fáciles de implementar. Los clientes ‘pesados’ permiten a los usuarios crear aplicaciones y modificar los front-end del sistema fácilmente, pero a costa de reducir la encapsulación de los datos; cuanta más responsabilidad se coloque en un cliente, el cliente requerirá un conocimiento más intimo de la organización de los datos del servidor.

Por otra parte, un servidor ‘pesado’ es más fácilmente explotable, esto es, más fácil de explotar. Además este tipo de servidor asegura una mayor compatibilidad entre clientes y servidores. Pro ejemplo, una pagina Web diseñada bajo este modelo supondría que no hay disponibilidad de applets de Java, plugins o ActiveX’s debido a que el usuario esta usando un cliente ‘ligero’, (un navegador básico), y el servidor estaría restringido al estándar HTML 2.0. El uso de este modelo de cliente ‘ligero’ asegura que todos los usuarios visualizan una pagina “aceptable”, aunque no se pueden proveer las características avanzadas disponibles con un cliente ‘pesado’.