Copyright � 2002 Rodrigo Moya
Se otorga permiso para copiar, distribuir y/o modificar este documento bajo los t�rminos de la Licencia de Documentaci�n Libre GNU, versi�n 1.1 o cualquier versi�n posterior publicada por la Free Software Foundation. No hay Secciones Invariantes ni Textos de Portada o Contraportada. Puedes consultar una copia de la licencia en http://www.gnu.org/copyleft/fdl.html.
Resumen
Este documento constituye la propuesta para un taller (2 o m�s horas) sobre el uso de CORBA en GNOME, de forma que pueda servir para ver lo sencillo que es usar esta potente tecnolog�a en aplicaciones desarrolladas para el proyecto GNOME. Dicho taller ser�a impartido por Rodrigo Moya y Diego Gonzalez.
Tabla de contenidos
CORBA es una tecnolog�a con una extremada potencia, que permite el desarrollo de aplicaciones distribuidas. Sin embargo, si bien potente, el acceso a ella es, cuando menos, algo dificultoso en el inicio, debido a la gran variedad de t�rminos y conceptos con que debe enfrentarse quien se acerca a CORBA por primera vez.
Debido a estas dificultades, mucha gente sufre de p�nico ante la idea de usar CORBA en sus aplicaciones. Por esta raz�n, en el proyecto GNOME siempre se ha buscado el hacer lo m�s sencillo posible el uso de esta potent�sima tecnolog�a, en la que se basa una buena parte del proyecto GNOME, y para ello, se han creado nuevas interfaces que hacen el acceso a la tecnolog�a de CORBA un juego de ni�os. En este taller, vamos a intentar quitar los miedos a usar CORBA, mediante el uso de ejemplos pr�cticos de uso de dicha tecnolog�a en aplicaciones GNOME.
La teor�a de CORBA est� repleta de nuevos t�rminos que, en muchas ocasiones, no hacen sino crear confusi�n. Pero, una vez analizada dicha teor�a, se encuentran multitud de parecidos con la terminolog�a habitual de la programaci�n orientada a objetos.
El ORB (Object Request Broker) es la parte del est�ndar CORBA que se encarga la implementaci�n, tanto de las comunicaciones, como de los mapeos a los distintos lenguajes de programaci�n soportados. Es la parte b�sica de la arquitectura CORBA, y es totalmente imprescindible.
CORBA define, como protocolo de comunicaciones entre los distintos objetos, el GIOP, que especifica el formato de las comunicaciones CORBA sin especificar ning�n transporte espec�fico. Para eso se define IIOP, que no es m�s que GIOP sobre TCP/IP.
Estos protocolos son unos protocolos de comunicaciones muy eficientes, pensados para aligerar las comunicaciones lo m�s posible. En �l, simplemente se define el formato de los mensajes, y luego, cada ORB (implementaci�n de CORBA) es responsable de convertir dichos mensajes en datos para la m�quina en la que se est� ejecutando, permitiendo as� la interacci�n entre distintas implementaciones de CORBA ejecut�ndose en m�quinas distintas, con sistemas operativos distintos, e, incluso, con representaci�n de datos distinta.
A la hora de desarrollar aplicaciones CORBA, uno de los primeros pasos que es escribir los interfaces IDL de la aplicaci�n. IDL es un lenguaje que permite definir una serie de interfaces para la comunicaci�n entre dos o m�s aplicaciones. El IDL se escribe en un fichero, normalmente con la extensi�n IDL, en el cual se definen los interfaces y los m�todos (funciones) de esos interfaces.
Un fichero IDL podr�a ser el equivalente a un fichero de cabecera en C++, en el que se definen las clases (el equivalente a los interfaces CORBA) y las propiedades (variables de la clase) y m�todos de esas clases. De hecho, IDL NO ES un lenguaje para implementar interfaces CORBA, sino que es un lenguaje PARA DEFINIR interfaces CORBA, por ello la equivalencia con un fichero de cabecera de C++, donde, normalmente, no se incluye ninguna implementaci�n, sino simplemente definiciones.
Una vez creado el fichero IDL describiendo los interfaces de los objetos, se usa lo que se llama un compilador IDL, que genera los cabos y esqueletos necesarios para el uso e implementaci�n de dichos interfaces. Los cabos son el c�digo generado para ser usado desde la parte cliente (la aplicaci�n que va a hacer uso del objeto CORBA), mientras que los esqueletos son, valga la redudancia, el esqueleto de la implementaci�n del objeto.
Existen compiladores IDL para distintos lenguajes de programaci�n, por lo que, una vez escrito el fichero IDL, se pueden generar los cabos y esqueletos, y por tanto implementar cada una de las partes, en cualquier lenguaje de programaci�n que soporte CORBA, ayudando de esta forma a la transparencia del lenguaje de implementaci�n de cada una de las partes que componen la aplicaci�n.
Existe tambien la posibilidad de saltarse el paso de compilaci�n del fichero IDL, y generar esos cabos y esqueletos en tiempo de ejecuci�n, a partir de dicho fichero IDL. Esto es lo que hace orbit-perl, por ejemplo, que permite el uso de ORBitSecci�n 1.2 desde el lenguaje Perl.
Como base de todos los desarrollados relacionados con CORBA en GNOME, tenemos a ORBit, el ORB (Object Request Broker) desarrollado por el equipo de programadores de GNOME, en el a�o 1997, ante la falta de implementaciones de CORBA existentes por aquel entonces que cumplieran los tres requisitos que eran precisos para poder ser usados en GNOME: libre, r�pido y ligero. Con el paso del tiempo, ORBit ha demostrado ser una de las mejores implementaciones de CORBA existentes hasta la fecha, no ya dentro de las libres, si no incluyendo las implementaciones no libres tambien. Es especialmente digna de destacar la velocidad y ligereza de ORBit, que gana con diferencia al resto de implementaciones en cuanto a velocidad y rendimiento se refiere.
Si bien no es una implementaci�n completa de CORBA (s�lo implementa uno de los 14 servicios CORBA, aunque hay que destacar que ninguna implementaci�n de CORBA los implementa todos), si es una implementaci�n especialmente indicada para cubrir las necesidades de GNOME Y de muchas otras aplicaciones que no precisen de un uso ultra-extensivo (uso de todos los servicios CORBA, por ejemplo, algo realmente raro) de CORBA. ORBit es capaz de comunicarse con otros ORB's que cumplan el est�ndar CORBA sin ningun problema.
ORBit est� desarrollado en C, y por tanto es este el lenguaje mejor soportado e indicado para el desarrollo de aplicaciones con ORBit, aunque tambien existe soporte para otros lenguajes, como C++, Perl o Python.
Una de las lagunas del est�ndar CORBA es en lo referente a la activaci�n de componentes bajo demanda, de forma que un cliente pueda solicitar la activaci�n de un objeto CORBA sin necesidad de que el proceso que lo implementa tenga que estar ya en ejecuci�n. Esto es una seria limitaci�n para la que el proyecto GNOME desarroll� bonobo-activation. Bonobo-activation es un sistema para la activaci�n de objetos bajo demanda, que funciona mediante la existencia de un demonio (uno por usuario) que lee la informaci�n de los componentes instalados para activar los objetos requeridos por los clientes.
Aparte de esto, incluye caracter�sticas extra, como por ejemplo el lenguaje de consulta (al estilo del SQL), que permite a los clientes obtener informaci�n sobre los componentes instalados en el sistema. Estas consultas se pueden hacer basadas en los interfaces implementados por los objetos, por ejemplo.
Como estrella de todos los desarrollos basados en CORBA en GNOME, tenemos a Bonobo, el sistema de componentes desarrollado por el equipo de programadores de GNOME.
Bonobo, como sistema de componentes, permite, de forma sencilla, lo siguiente:
Implementaci�n de objetos CORBA de una forma mucho m�s sencilla que mediante el uso directo del c�digo generado por orbit-idl. Esto se consigue mediante el objeto BonoboObject.
Implementaci�n y uso de controles, que son el equivalente en GNOME de los Beans de Java o los ActiveX de Windows. Es decir, son controles de pantalla visuales que se exportan entre procesos, de forma que pueden ser reutilizados por otras aplicaciones de una forma sencilla. Esto se consigue mediante los objetos BonoboControl y BonoboWidget.
Documentos compuestos, que son documentos cuyo contenido puede ser editado por varias aplicaciones a la vez, de forma que puedan insertarse los subdocumentos gestionados por una aplicaci�n en un documento maestro gestionado por otra aplicaci�n. Este sistema es la base de GNOME Office.
Env�o de datos entre procesos de forma sencilla, mediante el uso de BonoboStream's y BonoboListener's.
Sistema de activaci�n de objetos de alto nivel, conocido como 'monikers', y que permite una forma mucho m�s sencilla y potente de activar objetos que mediante el uso directo de bonobo-activation.