Middleware orientado a objetos
El concepto clave que diferencia al middleware orientado a objetos del resto de tipos de middleware es el de interfaz. Los servicios ofrecidos son accedidos a trav´es de interfaces, sin necesidad de conocer ning´un detalle de implementaci´on desde el lado cliente. Es una caracter´ıstica heredada de la orientaci´on a objetos, y al igual que ´esta, la mayor parte de las caracter´ısticas de este paradigma son tambi´en propias de este tipo de middleware, como la equivalencia intuitiva de conceptos reales que intervienen en el proceso con los elementos de programaci´on.
El funcionamiento del middleware orientado a objetos queda reflejado en la figura 3.2. El componente clave es el ORB (Object Request Broker), una capa software encargada de
comunicar los objetos remotos. Cada objeto remoto publica su interfaz; los usuarios acceden a los servicios definidos en este interfaz f´acilmente, como si se tratara de objetos locales. Esta abstracci´on se consigue mediante la creaci´on de objetos proxy locales, encargados de suplantar al objeto remoto en el entorno local. Su responsabilidad es redirigir la invocaci´on al ORB que se encargar´a, a su vez, de realizar las acciones oportunas para que la petici´on llegue al objeto remoto real y sea ejecutada. El mecanismo es similar al de llamada a procedimiento remoto (RPC), pero desde una perspectiva orientada a objetos.
Las caracter´ısticas propias del middleware orientado a objetos son:
Paradigma P2P: no hay diferencia entre clientes y servidores, s´olo objetos que proveen servicios y que reciben otros servicios de otros objetos. Todo objeto puede actuar como proveedor y receptor de servicios.
Transparencia de localizaci´on: gracias a la utilizaci´on de los objetos proxy.
Flexibilidad: los objetos pueden ser distribuidos en funci´on de la carga y de los recursos disponibles. La independencia de la localizaci´on permite realizar esta tarea de manera transparente a los usuarios.
Escalabilidad: Los sistemas basados en objetos distribuidos son f´acilmente escalables. No es necesario modificar la estructura interna o la arquitectura; simplemente se re- quiere agregar m´as objetos al middleware.
Independencia de la plataforma hardware/software: El concepto clave de los middle- ware orientados a objetos es el interfaz. La implementaci´on de los servicios ofrecidos en el interfaz es completamente independiente de ´este. La especificaci´on de interfaz es utilizada para generar stubs de cliente y esqueletos de servidor en cualquier len- guaje de programaci´on, sistema operativo y plataforma hardware mediante programas procesadores de este lenguaje (figura 3.3).
CORBA
De las alternativas de productos middleware orientados a objetos distribuidos existentes CORBA es, sin lugar a dudas, la m´as importante1. CORBA es el acr´onimo de Common Object Request Broker Architecture, una arquitectura e infraestructura abierta para facilitar el trabajo conjunto de aplicaciones a trav´es de redes de ordenadores. El est´andar es propiedad de OMG (Object Management Group), una organizaci´on abierta sin ´animo de lucro que produce y mantiene especificaciones relativas a la industria inform´atica. A dicha organizaci´on pertenece la pr´actica totalidad de grandes y medianas empresas del sector, con un total de m´as de 800 miembros representando el espectro completo de la industria inform´atica. La excepci´on m´as notable es Microsoft, que compite con la OMG con su propio est´andar de
1En aplicaciones puramente Java, SUN ofrece una alternativa m´as simple y mejor integrada en este lenguaje: RMI (Remote Method Invocation). La filosof´ıa es an´aloga a la de CORBA, pero la particularizaci´on al lenguaje de programaci´on Java hace que su utilizaci´on sea m´as intuitiva y sencilla.
objetos distribuidos (DCOM). Para el resto de la industria, el est´andar de referencia en middleware de objetos distribuidos es CORBA.
CORBA es un est´andar abierto y din´amico, capaz de evolucionar con los cambios de necesidades en la industria dado el enorme n´umero de miembros pertenecientes a la OMG. La aceptaci´on universal de CORBA motiva que sea soportado por la mayor´ıa de fabricantes inform´aticos. Esta b´usqueda de universalidad est´a presente desde la creaci´on del est´andar, para el que siempre se ha tenido en cuenta la necesidad de trabajar en un entorno heterog´eneo. De esta manera, CORBA cuenta con la capacidad de soportar la mayor parte de plataformas, sistemas operativos y lenguajes de programaci´on.
CORBA es ´util en muchas situaciones. Dada la facilidad con la que CORBA integra m´aquinas de muy diversos fabricantes y caracter´ısticas, es el middleware m´as usado en gran- des proyectos. La escalabilidad y tolerancia a fallos soportadas por el est´andar le hace apro- piado para la gesti´on de ´estos. Pero su uso no se limita a grandes aplicaciones; existen versiones especializadas de CORBA para la creaci´on de sistemas de tiempo real y peque˜nos sistemas embebidos.
CORBA define un modelo basado en el concepto de objeto. En dicho modelo, el objeto tiene dos vistas claramente diferenciadas:
Desde el punto de vista del cliente, un objeto define una interfaz de creaci´on e iniciali- zaci´on, de utilizaci´on y manejo.
Desde el punto de vista del servidor, un objeto est´a implementado de una manera determinada para realizar las operaciones ofrecidas al cliente.
Los objetos CORBA ofrecen servicios desde cualquier punto de una red. Est´an encapsu- lados como componentes binarios a los que los clientes remotos pueden acceder invocando m´etodos. Los clientes no requieren conocer la localizaci´on del objeto o el sistema operativo en el que se ejecuta. Pueden estar en el mismo proceso o en otra m´aquina situada en cualquier punto de la red. Tampoco es necesario que los clientes conozcan como est´a implementado el objeto, ni que lenguaje de programaci´on y compilador fueron usados para generarlo. Los objetos pueden estar implementados como un conjunto de clases C++ o como un mill´on de lineas COBOL; el cliente no puede ver la diferencia. La ´unica caracter´ıstica que los clientes deben conocer es el interfaz de dicho objeto.
En CORBA el interfaz se declara utilizando el lenguaje IDL (Interface Definition Langua- ge), en el que se especifican por completo los servicios del objeto. Este lenguaje es puramente declarativo, i.e. no contiene detalle alguno acerca de la implementaci´on. Permite definir inter- faces de programaci´on de manera concisa y cubre aspectos importantes como el tratamiento de errores. Las interfaces IDL especifican completamente el interfaz y los par´ametros reque- ridos por cada operaci´on, i.e. toda la informaci´on necesaria para escribir clientes que utilicen las operaciones ofrecidas por el objeto. La implementaci´on de los m´etodos definidos puede ser realizada e invocada desde cualquier lenguaje soportado por CORBA (la pr´actica totalidad, incluyendo C, C++, Ada, Smalltalk y Java). Los programadores se enfrentan a CORBA a trav´es de las construcciones propias del lenguaje de programaci´on que elijan. Gracias al IDL cliente y servidores escritos en diferentes lenguajes de programaci´on pueden interactuar de manera transparente.
La transparencia ofrecida por IDL es llevada a cabo por el elemento clave de CORBA: el ORB (Object Request Broker). El ORB permite a los objetos realizar peticiones a otros objetos locales o remotos de manera transparente(figura 3.3) de manera que el cliente no es consciente de los mecanismos utilizados para comunicarse con, activar o almacenar los objetos servidores. Las caracter´ısticas del ORB definido en la especificaci´on CORBA son:
Invocaci´on de m´etodos est´atica y din´amica: El ORB permite definir las invocaciones a objetos remotos de manera est´atica (i.e. en tiempo de compilaci´on) y tambi´en permite descubrir y utilizar servicios de manera din´amica (i.e. en tiempo de ejecuci´on). Cada alternativa tiene sus ventajas; la invocaci´on est´atica es m´as intuitiva y se beneficia de las comprobaciones del compilador mientras que la programaci´on de invocaciones din´amicas es intr´ınsecamente compleja pero otorga una gran flexibilidad.
Programaci´on de alto nivel: La independencia entre interfaz e implementaci´on permite ofrecer interfaces de muy alto nivel y muchas veces muy alejadas de la implementaci´on real. En contraste, otros tipos de middleware ofrecen librer´ıas de bajo nivel y espec´ıficas del lenguaje de dif´ıcil utilizaci´on e integraci´on en aplicaciones de alto nivel.
Sistema autodescriptivo: CORBA ofrece metadatos en tiempo de ejecuci´on que des- criben los interfaces existentes en el sistema. El servicioInterface Repository contiene informaci´on en tiempo real describiendo las funciones que los servidores ofrecen y sus par´ametros. Los clientes usan esta informaci´on para descubrir y utilizar servicios en tiempo de ejecuci´on.
Transparencia de localizaci´on: Un ORB puede trabajar en modo local en una sola m´aquina o puede interconectarse con otros ORBs existentes en la red. La especificaci´on de CORBA 2.0 establece un protocolo de comunicaci´on est´andar entre ORBs de manera que se garantiza el entendimiento entre ORBs de diferentes fabricantes (IIOP). De esta manera, un ORB puede comunicar objetos del mismo proceso, de procesos diferentes en la misma m´aquina o de procesos diferentes en m´aquinas separadas, siempre de manera completamente transparente.
Polimorfismo: En contraposici´on con otras formas de middleware, un ORB no realiza una simple invocaci´on a funci´on remota, sino que invoca un m´etodo de un objeto remoto. ´Esto tiene una serie de consecuencias relacionadas con las propiedades de los objetos. La misma llamada puede tener diferentes efectos dependiendo del objeto que la recibe.
Coexistencia con sistemas existentes: La separaci´on interfaz/implementaci´on es un pa- radigma perfecto para el encapsulamiento de aplicaciones existentes. Usando IDL, se puede hacer que un c´odigo ya existente parezca un objeto en el contexto del ORB, aunque ´este estuviera implementado en un lenguaje no orientado a objetos.
La figura 3.4 muestra la estructura de un middleware CORBA 2.0. El concepto clave que permite entender esta estructura es la consideraci´on de que CORBA, al igual que SQL,
Local Proxy B Objeto A ORB Remoto esqueleto B Objeto B ORB
Figura 3.2: Funcionamiento general del middleware orientado a objetos.
C C++ Java Ada IDL ORB Stub cliente C C++ Java Ada Esqueleto servidor
Figura 3.3: Independencia de localizaci´on y plataforma hardware/software en middleware orientado a objetos. El papel del IDL es de capital importancia en este modelo.
Esqueletos estáticos Esqueletos estáticos Stubs Cliente (IDL) Stubs Cliente (IDL) Stubs Cliente (IDL) Core ORB Implementación Interfaz ORB Invocación Dinámica Adaptador Objetos Invocación Dinámica Esqueletos estáticos Cliente
ofrece interfaces tanto est´aticos como din´amicos a sus servicios. El propio nombre de CORBA (Arquitectura Com´un ORB) hace referencia a este hecho; “Com´un” se refiere precisamente a este soporte para ambos tipos de interfaces, est´atica y din´amica.
Los stubs IDL de cliente ofrecen el interfaz est´atico de los servicios. ´Estos definen la manera en que los clientes invocan los servicios correspondientes en los servidores. Elstubes un m´odulo precompilado que representa al objeto remoto en el entorno local. Su interfaz es id´entica a la del objeto remoto, pero carece de implementaci´on real. Todos sus m´etodos son meros redirectores de la invocaci´on hacia el servidor remoto. El interfaz se define mediante el lenguaje IDL; a partir de ´este y mediante un compilador de IDL se generan losstubsde cliente y servidor. Elstubincluye c´odigo para realizarmarshaling2. Elstubtambi´en incluye archivos
de cabecera que permiten la invocaci´on de m´etodo de objeto remoto desde un lenguaje de programaci´on de alto nivel, sin preocuparse acerca de los protocolos subyacentes o del mismo proceso de marshalling. La llamada local al stubdesencadena el proceso de llamada remota. El interfaz din´amico de invocaci´on permite descubrir m´etodos a invocar en tiempo de ejecuci´on. CORBA define un API para la b´usqueda de metadatos que definen el interfaz del objeto servidor. Tambi´en ofrece un API para ayudar a generar din´amicamente los par´ametros necesarios, realizar la llamada y obtener los resultados de vuelta. Este proceso de b´usqueda din´amica se apoya en el repositorio de interfaces (Interface Repository), una base de datos distribuida que contiene versiones binarias de los interfaces definidos en el IDL. Esta base de datos contiene la descripci´on de los interfaces registrados, los m´etodos que ofrecen y los par´ametros requeridos (method signature).
La existencia de ambos m´etodos de invocaci´on en CORBA le da una importante ventaja comparativa respecto a otros tipos de middleware. Las invocaciones est´aticas son f´aciles de programar y r´apidas. Las invocaciones din´amicas ofrecen m´axima flexibilidad a costa de una programaci´on m´as compleja.
En el lado servidor no se puede establecer la diferencia entre invocaciones est´aticas y din´amicas; ambas utilizan la misma sem´antica de mensajes para comunicar la invocaci´on. El ORB invoca el m´etodo remoto a trav´es del stub de servidor (skeleton o esqueleto en la nomenclatura CORBA). Los esqueletos IDL ofrecen interfaces est´aticas a los servicios del objeto y son creados, como en el caso cliente, a partir del compilador IDL.
Al m´etodo de invocaci´on est´atica se debe a˜nadir el interfaz de esqueleto din´amico (Dy- namic Skeleton Interface), que posibilita el enlace din´amico de servidores que carecen de un esqueleto est´atico precompilado. A trav´es del Interfaz de esqueleto din´amico se permite ver los valores de los par´ametros de una invocaci´on y, de esta manera, decidir a qu´e objeto y a qu´e m´etodo iba dirigido. Es el equivalente al interfaz din´amico de invocaci´on en el cliente. Puede recibir tanto invocaciones est´aticas como din´amicas.
El adaptador de objetos se encuentra entre el n´ucleo ORB y las implementaciones. Se encarga de aceptar las peticiones en representaci´on de los objetos servidor. Ofrece servicios como la generaci´on de referencias a objetos, invocaci´on de m´etodos, seguridad, activaci´on y desactivaci´on de objetos, o registro de implementaciones. Tanto en el lado cliente como en el
2Marshalling es el proceso por el que se codifica una operaci´on y sus par´ametros a un mensaje plano que puede ser enviado a trav´es de la red. La decodificaci´on de ´este mensaje en las estructuras binarias correspondientes en el servidor recibe este mismo nombre.
servidor se tiene acceso al interfaz ORB, un API a servicios locales del ORB que pueden ser de utilidad a las aplicaciones (e.g. conversi´on entre referencias y cadenas de caracteres, . . . ).