PDF de programación - ORBit2 como middleware para una aplicación multicapa, usando el servicio de nombres CORBA

ORBit2 como middleware para una aplicacion

multicapa, usando el servicio de nombres CORBA

Alejandro Garca Castro, Juan Jose Sanchez Penas

Igalia Gutenberg, 34B 2o, Polgono de A Grela { 15008 A Coruña

[email protected], [email protected]

Resumen ORBit2 es el ORB utilizado en el proyecto GNOME para la co-
municacion de componentes en el escritorio; es la tecnologa que integra
las aplicaciones y les permite colaborar. Fisterra es un proyecto de softwa-
re libre cuyo objetivo es la creacion de una plataforma para el desarrollo
de aplicaciones de gestion empresarial con tecnologa GNOME. Nuestro
interes por el proyecto GNOME, tanto en su vertiente tecnologica como
de comunidad, para el desarrollo de soluciones, nos ha llevado a la se-
leccion de ORBit2 para la integracion no unicamente del interfaz, sino
tambien de los componentes no visuales del proyecto, planteando su uso
como middleware de comunicaciones dentro de la arquitectura multicapa
de Fisterra. En este artculo presentamos nuestra experiencia en el uso
de ORBit2 como middleware de comunicaciones para la creacion de una
aplicacion cliente/servidor, los problemas que nos hemos encontrado, y
las soluciones aplicadas. El principal problema encontrado para cumplir
los requisitos impuestos por un entorno como Fisterra, fue la ausencia
en ORBit2 de un sistema para la referencia de objetos CORBA mediante
una referencia ja, que haga mas comodo el uso del servicio de nombres
(CORBA Nameservice). Con la colaboracion de varios hackers de ORBit2
creamos un sistema que permite referenciar a un objeto por un nom-
bre jo y legible. Finalmente, plantearemos nuestras conclusiones tras
el desarrollo de esta solucion, discutiendo las posibilidades de trabajo
futuro.

1.

Introduccion

La viabilidad de la utilizacion de software libre en el sector empresarial de-
pende muchas veces de la disponibilidad de software de gestion de negocio. En
nuestra experiencia profesional esto se ha manifestado como imprescindible para
diversas empresas e incluso para instituciones publicas. Una empresa de desa-
rrollo de software libre necesita generar una comunidad sucientemente grande
de usuarios de las tecnologas con las que trabaja, una comunidad de clientes
capaces de mantener un volumen adecuado de nanciacion de nuevos desarrollos.
Para conseguir esta comunidad, es necesario plantear la creacion de un entorno
de desarrollo de software de gestion abierto e integrado con tecnologas de escri-
torio, que permita desarrollar este tipo de aplicaciones y mantener un repositorio
de soluciones reutilizables. Por estas razones, conando en GNOME como opcion

mas interesante para el escritorio, se crea el proyecto Fisterra 1[1,2,3] en mayo
de 2003. Dentro del proyecto, la idea de crear aplicaciones de gestion usando
interfaces GNOME evoluciono de una propuesta inicial menos ambiciosa hasta
una arquitectura compleja, capaz de soportar aplicaciones muy diversas creadas
por una comunidad de desarrolladores grande con requisitos heterogeneos.

La arquitectura propuesta para Fisterra contempla la existencia de multiples
capas, algo basico para el desarrollo de aplicaciones de este tipo, tal y como
propone Martin Fowler[4]. Nuestra propuesta basa la arquitectura completa del
proyecto en tecnologas GNOME, es decir, desde las capas de objetos de servicios,
que no son visuales, hasta los interfaces y la integracion con el escritorio. Las
herramientas de GNOME eran sucientes para permitir el desarrollo, la unica
particularidad era realizar un uso diferente de alguna de sus partes. Se asumio el
posible coste de adaptacion de estas tecnologas suponiendo que las ventajas de
integracion a la hora de desarrollar seran mayores, habiendo antes evaluado que
las dicultades de crear esta plataforma sobre esta tecnologa no eran grandes.

Una de las mayores ventajas de la tecnologa GNOME de cara a afrontar
nuestra propuesta era la completa integracion con un middleware de comunica-
ciones CORBA [5], que inclua los servicios basicos y daba una implementacion del
estandar con un rendimiento muy elevado: ORBit2. ORBit2 se utiliza principal-
mente en GNOME para la gestion de componentes2, siendo la tecnologa que se
encarga de la integracion de interfaces. En nuestro caso adaptamos este compor-
tamiento para el acceso a objetos remotos, lo que mezclado con que glib permite
el desarrollo de objetos sin estar atado a caractersticas de interfaz, nos permi-
tio crear un diseño de arquitectura similar a la descrita en el libro de M. Fowler,
usando GNOME. Fisterra en la actualidad incluye una serie de bibliotecas de so-
porte, implementadas sobre GNOME, que ofrecen las funcionalidades necesarias
para estos objetos, como la de de persistencia, los llamados barnacles[6].

A la hora de usar ORBit2, tuvimos que afrontar una serie de problemas debido
a las limitaciones causadas por el desarrollo orientado unicamente a la gestion de
componentes de escritorio con el que ha crecido este ORB (Object Request Broker ).
La principal necesidad era la utilizacion de corbalocs jos, para permitir que los
clientes se pudiesen congurar indicando la URL del objeto servidor de nombres
sin tener que cogerla de un servicio externo, lo que añadira una complejidad
innecesaria al sistema. Para ello se implemento la posibilidad de registro de ese
tipo de nombres en el ORB, mediante el uso de un mensaje de redireccion de
localizacion de CORBA.

En este artculo presentaremos la arquitectura propuesta usando ORBit2 en
Fisterra y su funcionamiento, explicando las necesidades basicas con respecto
al middleware de comunicaciones, y expondremos las modicaciones realizadas
en ORBit2 para lograr solucionar nuestras necesidades. Ademas, expondremos
nuestras perspectivas de futuro en el trabajo con ORBit2.

1 http://www.sterra.org
2 http://www.djcbsoftware.nl/projecten/nluug-bonobo/

2.

CORBA como middleware de comunicaciones

CORBA es un estandar que permite la integracion de componentes software,
fue creado por la OMG(Object Management Group 3) en 1989 y su uso es muy
comun en la creacion de grandes sistemas.

El estandar dene un sistema para que los objetos puedan enviar y recibir
peticiones de otros objetos en un entorno distribuido de forma transparente. En
este sentido, CORBA es un middleware de comunicaciones que dene un protocolo
utilizado para el intercambio de los mensajes entre los objetos, y que es total-
mente transparente para los desarrolladores. La base de esta comunicacion es el
ORB, esta capa es la responsable de encapsular las peticiones y enviarlas al objeto
que implementa el servicio deseado. Es decir, en un entorno de funcionamiento
normal de CORBA, un objeto encapsula los servicios que suministra un software
y que se hacen accesibles para otros objetos CORBA a traves de la interfaz que
publica el ORB.

Sobre el ORB se denen e implementan objetos para el desarrollo de software,
estos objetos pueden crearse utilizando diferentes lenguajes de programacion.
Para la denicion del interfaz de estos objetos se usa un lenguaje especial de-
nominado IDL(Interface Denition Language), y se usa ademas un compilador
para ese lenguaje que genera el codigo necesario para implementar comodamente
los objetos.

ORBit2 es una implementacion de CORBA (version 2.4), que incluye un ORB, un
compilador de interfaces (genera codigo para la implementacion de los servicios
a partir de un lenguaje de denicion de interfaces) y un servicio de nombres
(permite localizar objetos usando un sistema sencillo de nombrado).

3. Arquitectura multicapa, el proyecto Fisterra

Como ya hemos indicado, las propuestas actuales para la solucion de apli-
caciones de gestion se basan en diseños de arquitectura con multiples capas. La
solucion mas habitual para sistemas de mediana entidad es la de tres capas. En
esta propuesta se separan los interfaces para los clientes de la logica de negocio
y de la base de datos. Las implementaciones de estas arquitecturas en la actuali-
dad utilizan un middleware para la comunicacion entre los componentes que las
forman. Estos componentes se apoyan en un sistema contenedor para poder eje-
cutarse y proveer los servicios que implementan. El contenedor es una aplicacion
que da facilidades a los objetos que se ejecutan sobre ella, suele incluir soporte
para comunicaciones, gestion de informacion, persistencia, transacciones, etc.

Fisterra es un proyecto diseñado segun los patrones marcados por este tipo
de arquitecturas, e implementado usando las tecnologas GNOME. Se ha inten-
tado evitar usar tecnologas externas a GNOME para conseguir un desarrollo
totalmente integrado.

Las partes principales de la implementacion son:

3 http://www.omg.org/

Cliente: es una aplicacion de ventanas, desarrollada como cualquier otra apli-
cacion de escritorio GNOME, que se encarga de interaccionar con el usua-
rio. Tiene un diseño interno basado principalmente en una estruct