Bonobo
El modelo de componentes
Si lo que hemos visto hasta ahora puede haber dejado gratamente sorprendido al lector por la facilidad del uso de los programas existentes en GNOME, gracias a CORBA, el mundo de Bonobo es mucho más espectacular y gran parte del futuro del software libre, y su equiparación al software cerrado, está en la creación y uso de componentes de la forma más sencilla y flexible posible.
Miguel de Icaza, lider del proyecto Bonobo, cuando buscaba que modelo de componentes a utilizar en GNOME, encontró en OLE2 de Microsoft una especificación documentada de un modelo de componentes como el que quería, por lo que decidió adoptarlo dentro de GNOME. Miguel ha defendido está arquitectura dentro de la comunidad del software libre con éxito, a pesar de estar realizada por Microsoft.
No deja de ser curiosa la combinación de utilizar como "middleware" CORBA y como modelo de componentes OLE2. Recordemos que la plataforma de software distribuido de Microsoft también utiliza OLE2 como modelo de componentes, aunque como "middleware" utiliza COM, el principal competidor de CORBA.
La idea es que un desarrollador disponga entre sus herramientas de trabajo de una paleta de componentes lo más amplia posible, algo que ya es una realidad dentro de Visual Basic o en el mundo de Java con los beans.
Una vez que dispongamos de esos componentes, organizados por paletas de diferente funcionalidad, el desarrollador tan sólo tendrá que crear de cero aquella funcionalidad que no encuentre en los componentes. De esta forma, las aplicaciones pasan a ser un grupo de componentes que colaboran entre sí. Y, ¿cómo sabemos que nos ofrece un componente? Muchas veces esta información nos la da la documentación, pero si dichos componentes tienen interfaces IDL, estas interfaces son la documentación más exacta y útil para el desarrollador, aparte de ser independientes del lenguaje y plataforma de desarrollo. Y esta información puede ser utilizada por herramientas de generación automática de código o para mostrar las funciones dentro de las propiedades de un componente.
Dentro de GNOME parece que el entorno de desarrollo basado en componentes va a ser GLADE, cuya interfaz gráfica la podemos observar en la siguiente figura.
La idea es ir tomando estos componentes y de forma visual y construyendo la interfaz gráfica de nuestra aplicación. Una vez construida la interfaz gráfica se genera el código, que en muchos casos será compilar las interfaces IDL de los componentes y generar los cabos para que podamos acceder a la funcionalidad del componente desde nuestro programa. Este código se podrá generar fácilmente en diferentes lenguajes. Sólo hace falta que ORBit tenga un compilador al lenguaje deseado, ya que CORBA se encarga de que lo demás funciones. De esta forma, la herramienta de desarrollo no nos obliga a utilizar ningún lenguaje y cada uno puede trabajar con el que se sienta más cómodo y sea más adecuado en su proyecto. En la actualidad aún en GLADE no está disponible esta funcionalidad, pero seguro que en los próximos meses la veremos aparecer.
Este modelo de desarrollo es muy parecido al mundo de los componentes de Microsoft, donde los componentes al instalarse en el sistema se registran dentro del Registro del sistema (en GNOME es el GOAD) y desde las herramientas de desarrollo visuales, se pueden utilizar estos componentes, cuya interfaz se define en el IDL de Microsoft, muy similar al de CORBA.
Dentro de GLADE el aspecto que puede tener una interfaz gráfica en desarrollo lo podemos observar en la figura 3.
Desarrollo de componentes
Una de las ideas de los componentes es crear un entorno de trabajo centrado en los documentos. Cuando trabajas en un informe y necesitas insertar una hoja de cálculo, el entorno nos da la posibilidad de introducir dentro de nuestro procesador de textos (un contenedor de componentes) una hoja de cálculo, un componente, y utilizar todas las funcionalidades de la aplicación de hoja de cálculo dentro de nuestro procesador de textos. Un ejemplo de este modelo es como Word incluye hojas de cálculo Excel.
De cara al usuario todo es transparente pero el hacer posible este modelo requiere de unas infraestruturas bastante potentes, que en GNOME las proporciona Bonobo.
Bonobo es un conjunto de interfaces CORBA (definidas en OMG/IDL) que definen lo que es un componente empotrable dentro de un contenedor (contenido) y lo que es un contenedor. Además, Bonobo incluye una implementación por defecto, en C, de estas interfaces para evitar al programador el trabajo de tener que escribir en cada nuevo componente o contenedor el mismo código.
Todas las interfaces de CORBA heredan de GNOME::Unknown, una interfaz que nos permite preguntar a un componente cuáles son las interfaces que implementa y permite llevar cuentas de cuantas veces ha sido referenciado un componente para poder controlar el momento de su destrucción. Aquí vemos la definición en IDL de dicha interfaz.
module GNOME {
interface Unknown {
void ref ();
void unref ();
Object query_interface (in string repoid);
};
};
Es muy importante que cada vez que obtengamos una referencia a un objeto Bonobo llamemos al método ref de ese objeto. De esta forma la implementación del objeto sabe cuantas veces ha sido referenciado, y hasta que este número no llegue a cero, sabe que no se puede eliminar dicho objeto. Dentro de CORBA no hay ningún mecanismo para llevar este control sobre el ciclo de vida de un objeto, por lo que hay que descargar en el programador esta responsabilidad. De igual modo, cuando no vayamos a utilizar más esta referencia, debemos de llamar al método unref, que puede llegar a provocar la liberación del objeto y que nuestra aplicaciónn ocupe menos recursos.
Un objeto Bonobo puede implementar varias interfaces, y por lo tanto, puede ser visto de distintas formas dentro de las aplicaciones, dependiendo de por la interfaz por la que se acceda a él. Cuando obtenemos una referencia a un objeto Bonobo a través del método query_interface podemos pasarle una interfaz. El objeto Bonobo, si la implementa, nos devolverá una referencia CORBA para poder acceder a la implementación de dicha interfaz. En el caso de que no la implemente nos devuelve el objeto nulo. Veamos un pequeño ejemplo de su uso.
CORBA_Object obj_unknown;
CORBA_Object obj_embeddable;
obj_unknown = CosNaming_NameService_resolve (orb, "Word97", &ev);
obj_embeddable = GNOME_Unknown_query_interface
(obj_unknown, "IDL:GNOME/embeddable:1.0", &ev);
Lo primero que hacemos es acceder al servicio de nombrado y obtener el IOR del objeto cuyo nombre es "Word97". Como puede observar el lector, a esta función se le pasa el objeto orb y se utiliza la variable ev para almacenar las posibles excepciones que puedan aparecer en esta llamada. El lector que quiera comprender en profundidad esta sintaxis puede acudir aqui donde se explica con bastante detalle la traducción de OMG/IDL a C.
Una vez que ya tenemos una referencia a un objeto Bonobo, invocamos sobre él el método query_interface para comprobar si implementa la interfaz IDL:GNOME/embeddable:1.0, es decir, si es un objeto empotrable en un contenedor. Si lo implementa, obtenemos una referencia a la implementación de esta interfaz por el objeto y la podemos utilizar para controlar la inserción del objeto dentro del contenedor de nuestra aplicación.
Uno de los usos más flexibles de esta interfaz Unknown es que permite que un objeto sea actualizado sin que afecte para nada a todos los clientes que ya existían de dicho objeto. Basta con mantener en el objeto las interfaces antiguas junto a las nuevas. De esta forma la actualización de objetos siempre asegura la compatibilidad hacia atrás aunque eso sí, hay que tener cuidado de no acabar con interfaces enormes y poco manejables.
Dentro de Bonobo se ha hecho todo lo posible para evitar que el desarrollador tenga que aprender CORBA en profundidad, aunque los conocimientos básicos son necesarios para entender lo que estamos haciendo. Buscando esta facilidad se creó el objeto GnomeObject, que está basado en el objeto raíz GTK, y que implementa por defecto la parte de funcionalidad de un componente Bonobo que es siempre muy parecida. Este objeto GnomeObject es básicamente un recubrimiento de un servant de POA al que se le une la implementación de la interfaz Unknown. Recordar al lector que un servat en CORBA era el código encargado de implementar una interfaz IDL, y que es un concepto perteneciente a POA, al adaptador de objetos portable de CORBA.
Hasta aquí hemos llegado en esta presentación del uso de CORBA pero en el siguiente apartado damos al lector algunas pistas de por dónde continuar para profundizar en el desarrollo de aplicaciones GNOME.
Por dónde seguir
Debido a la extensión que nos llevaría una descripción completa de un contenedor y un componente empotrable no podemos completarla en el presente artículo, y quizás sería ya necesario dedicar una serie completa a este tema.
Si el lector se siente con ganas de seguir avanzando en el desarrollo de aplicaciones GNOME, conociendo las tripas del sistema, algo siempre recomendable, los pasos a seguir son leer los capítulos 7 y 8 del libro de GNOME y CORBA donde se explica cómo se construye un componente embebible desde cero, y como se construye un contenedor.
Una vez que tengamos claro esto podemos pasar a ver cómo se guarda el estado de una aplicación que trabaja con componentes, tema delicado ya que hay que ir componente por componente guardando su estado, de tal forma que cuando arranquemos de nuevo la aplicación y volvamos a la versión guardada del mismo, todo quede en el mismo estado en el que lo habíamos dejado. Lo que se hace básicamente es definir unas interfaces para dar soporte de persistencia, es decir, que el objeto que implemente estas interfaces es capaz almacenar y recuperar su estado. Utilizando sobre todos los componentes que componente nuestra aplicación esta interfaz, podemos almacenar el estado del conjunto de la aplicación de una forma estándar.
Conclusiones
El mundo del software libre estaba muy por detrás del mundo de software cerrado en el mundo de los componentes. Esta distancia se ha acortado de forma espectacular con GNOME y su modelo de componentes Bonobo.
La combinación de CORBA y OLE2 lográn un entorno de desarrollo de componentes potente y sencillo, en el que el programador puede comprender y seguir todos los detalles de la arquitectura, y para el que no se necesitan complejas herramientas de desarrollo.
En el mundo del software libre se avecina una próxima revolución, la de los componentes libres. En cuanto el conjunto de desarrolladores comprendan el modelo de desarrollo basado en componentes, y dispongan de las herramientas adecuadas, veremos surgir una gran variedad de paletas de componentes libres, que podremos utilizar para desarrollar nuestras aplicaciones de forma muy rápida y robusta.
GNOME es un ejemplo práctico del uso de CORBA muy completo e interesante, que puede servir al lector para profundizar en sus conocimientos de CORBA y aprender a desarrollar aplicaciones sencillas y potentes con muy pocas líneas de código.
Tutoriales
