Definici´ on y propiedades de un middleware

La heterogeneidad de sistemas y su inherente incompatibilidad ha motivado la generaci´on del concepto de middleware, que representa la opci´on m´as com´un para la construcci´on de sistemas inform´aticos distribuidos en la actualidad, e.g. sistemas de gesti´on de bases de datos, servidores web, servidores de aplicaciones, sistemas de gesti´on del contenido. Se puede definir como la capa de software necesaria para garantizar el soporte de interacciones entre clientes y servidores en dichos sistemas, aunque su definici´on puede ser particularizada a cada uno de los diferentes contextos en los que se utiliza.

El middleware queda comprendido en un espacio, de fronteras muchas veces difusas, entre el cliente y el servidor. A pesar de no pertenecer a ninguno de ellos, se ejecuta en ambas

partes de la aplicaci´on cliente/servidor como queda patente en la definici´on del consorcio ObjectWeb

En un sistema inform´atico distribuido, se define el middleware como la capa de software existente entre el sistema operativo y las aplicaciones en cada parte del sistema.

Esta capa intermedia se encarga de ofrecer a los usuarios la visi´on de un sistema ´unico, ocultando la complejidad subyacente. De esta tarea se responsabilizan las partes m´as impor- tantes de un middleware, el sistema operativo de red, Network Operating System (NOS), y la pila de transporte, Transport Stack. MedianteNOS el middleware facilita al usuario los siguientes niveles de transparencia:

Transparencia de localizaci´on: permite acceder a un recurso sin conocer su localizaci´on exacta (en t´erminos del nombre de la m´aquina en la que reside).

Transparencia de espacio de nombres: permite utilizar la misma convenci´on de nombres para acceder a cualquier recurso del sistema, con independencia del tipo de recurso o fabricante.

Transparencia de identificaci´on: permite utilizar la misma informaci´on de identificaci´on para el acceso a todos los recursos del sistema.

Transparencia de redundancia: permite utilizar los recursos sin conocer el n´umero de instancias que existen de ´este ni del estado de sincronizaci´on entre ellas.

Transparencia de acceso local o remoto: permite utilizar cualquier recurso del sistema, remoto o no, como si fuera local.

Transparencia temporal: permite obtener informaci´on temporal sincronizada con el resto de componentes del sistema.

Transparencia de errores: permite ocultar errores en el acceso a ciertos recursos, por ejemplo mediante la redirecci´on a un recurso redundante.

Para lograr esta lista de objetivos de transparencia y dar la imagen de un sistema ´unico, elNOS ofrece a las aplicaciones interfaces de comunicaci´on para acceder a servicios y recur- sos. Las formas m´as cl´asicas de acceso son las llamadas a procedimientos remotos (RPC) y las colas de mensajes (MOM). Estas interfaces de programaci´on otorgan al middleware las siguientes propiedades:

Son interfaces de alto nivel que facilitan la tarea de programar la comunicaci´on de red en cada aplicaci´on, una tarea compleja y muy propensa a errores, ofreciendo un capa fiable y ya implementada.

Permiten independizar las aplicaciones de la pila de comunicaciones utilizada para realizar la comunicaci´on a nivel f´ısico (TCP/IP, NetBEUI, SPX/IPX, . . . ).

Dicha independencia permite facilitar, adem´as, la heterogeneidad del sistema a nivel de hardware, de sistema operativo, de protocolos de red y de capa de transmisi´on f´ısica. Permiten mejorar la escalabilidad del sistema, gracias a las propiedades anteriores. La popularidad de los lenguajes orientados a objetos, en especial por el auge de Java, ha motivado la creaci´on de paradigmas middleware orientados a objetos, una abstracci´on en la que el elemento principal son los objetos distribuidos. Esta metodolog´ıa permite que un conjunto de objetos distribuidos trabajen en com´un a trav´es de las fronteras de redes y m´aquinas para crear una soluci´on cliente/servidor. Las propiedades de los objetos cl´asicos se conservan en su versi´on distribuida: polimorfismo, herencia y encapsulamiento. Sin embargo, mientras que los objetos cl´asicos viven en el contexto de un programa determinado y son s´olo reutilizables por el compilador con el que fueron creados, los objetos distribuidos a˜naden a la abstracci´on la posibilidad de habitar en cualquier lugar de la red y ser accesibles por clientes remotos a trav´es de invocaciones de m´etodos, con independencia del lenguaje con el que se crearon, su localizaci´on o el sistema operativo en el que se ejecutan.

En el paradigma de programaci´on a objetos cl´asico, el usuario utiliza los servicios de diferentes objetos para realizar una tarea determinada. La divisi´on de la tarea en el conjunto de objetos viene dada por la analog´ıa real de lo que dichos objetos representan en el sistema software, que se encuentra enormemente facilitada por las caracter´ısticas de la orientaci´on a objetos. En resumen, la uni´on de los servicios de los objetos permite la realizaci´on de tareas. Esta caracter´ıstica se conserva en el modelo de objetos distribuidos; la abstracci´on es id´entica para el usuario de los objetos, que utiliza los servicios de cada uno de ellos para realiza la tarea. La diferencia en este caso es que los objetos no se encuentran en el nodo local; su localizaci´on es desconocida para el programador y el programa es, de hecho, independiente de ella. De manera natural, el programador est´a consiguiendo distribuir el proceso global utilizando la misma abstracci´on que le permit´ıa realizar el proceso de manera local. Los objetos distribuidos expanden las propiedades de los objetos cl´asicos de manera natural, permitiendo la descentralizaci´on transparente del proceso en diferentes localizaciones. Esta coincidencia de paradigmas, para los casos cl´asico y distribuido, es una de las principales razones que ha motivado el desarrollo de la tecnolog´ıa de middleware orientado a objetos.