Manual de Programación de...

Manual de Programación deGmodulo

Manual de Programación de Gmodulo$Date: 2003/10/15 18:07:59 $

Copyright © 2003 Carlos MartínCopyright © 2003 Universidad de Salamanca

Publicado por: UNIVERSIDAD DE SALAMANCA

Se concede permiso para copiar, distribuir y/o modificar este documento bajo los términos de la GNU Free Documentation License (GFDL), Versión 1.1 u otra versión posterior publicada por la Fundación de Software Libre sin cambios en las secciones, cubiertas o contracubiertas. Usted puede encontrar una copia de la licencia GFDL en esta dirección o en el archivo COPYING-DOCS distribuido con este manual.

Este manual forma parte de la colección de manuales de GNOME distribuidos bajo licencia GFDL. Si desea distribuir este manual independientemente de la colección, puede hacerlo añadiendo una copia de la licencia al manual, tal y como se describe en la sección 6 de la licencia.

Muchos de los nombres usados por compañías para identificar sus productos y servicios constituyen marcas registradas. En aquellos lugares en los que aparezcan estos nombres, y siempre que se tenga conocimiento de que dichos nombres son marcas registradas, los nombres aparecerán en mayúsculas o seguidos del símbolo ™.

DOCUMENT AND MODIFIED VERSIONS OF THE DOCUMENT ARE PROVIDED UNDER THE TERMS OF THE GNU FREE DOCUMENTATION LICENSE WITH THE FURTHER UNDERSTANDING THAT:

1. DOCUMENT IS PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, WARRANTIES THAT THE DOCUMENT OR MODIFIED VERSION OF THE DOCUMENT IS FREE OF DEFECTS MERCHANTABLE, FIT FOR A PARTICULAR PURPOSE OR NON-INFRINGING. THE ENTIRE RISK AS TO THE QUALITY, ACCURACY, AND PERFORMANCE OF THE DOCUMENT OR MODIFIED VERSION OF THE DOCUMENT IS WITH YOU. SHOULD ANY DOCUMENT OR MODIFIED VERSION PROVE DEFECTIVE IN ANY RESPECT, YOU (NOT THE INITIAL WRITER, AUTHOR OR ANY CONTRIBUTOR) ASSUME THE COST OF ANY NECESSARY SERVICING, REPAIR OR CORRECTION. THIS DISCLAIMER OF WARRANTY CONSTITUTES AN ESSENTIAL PART OF THIS LICENSE. NO USE OF ANY DOCUMENT OR MODIFIED VERSION OF THE DOCUMENT IS AUTHORIZED HEREUNDER EXCEPT UNDER THIS DISCLAIMER; AND

2. UNDER NO CIRCUMSTANCES AND UNDER NO LEGAL THEORY, WHETHER IN TORT (INCLUDING NEGLIGENCE), CONTRACT, OR OTHERWISE, SHALL THE AUTHOR, INITIAL WRITER, ANY CONTRIBUTOR, OR ANY DISTRIBUTOR OF THE DOCUMENT OR MODIFIED VERSION OF THE DOCUMENT, OR ANY SUPPLIER OF ANY OF SUCH PARTIES, BE LIABLE TO ANY PERSON FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF GOODWILL, WORK STOPPAGE, COMPUTER FAILURE OR MALFUNCTION, OR ANY AND ALL OTHER DAMAGES OR LOSSES ARISING OUT OF OR RELATING TO USE OF THE DOCUMENT AND MODIFIED VERSIONS OF THE DOCUMENT, EVEN IF SUCH PARTY SHALL HAVE BEEN INFORMED OF THE POSSIBILITY OF SUCH DAMAGES.

Para informar sobre fallos o sugerencias relacionadas con Gmodulo, remita un correo a la dirección de correo electrónico [email protected].

Contenidos

Parte I Introducción al desarrollo de Gmodulo

1 Primeros pasos en Gmodulo 9Introducción 9

Objetivo 9Ámbito 10Referencias 10Resumen 10

Nociones básicas sobre la arquitectura de Gmodulo 10Estructura de la solución 11Dependencias. Integración con gnome 13

Un caso particular: gtk-doc 14Otro caso no tan particular: pkg-config 15

Licencias de uso y distribución 15Localización y acceso al código fuente 15

¿Qué versión? 15Obtención de paquetes compilados mediante apt 16Acceso al servidor de desarrollo: cvs 17

Acceso anónimo al servidor 17Acceso para desarrolladores 18

Compilación de los archivos fuente 19Herramientas de manejo de paquetes y compilación 19

Manejo de paquetes gnu 19Pasos a seguir: Aspectos a tener en cuenta 20

Distribución de los sistemas: ¿Clientes o Servidores? 21Opciones de configuración 22

Opciones disponibles en gmodulo-provider 22

3

Opciones disponibles para gmodulo-monkey 23Opciones para gmodulo-shell 23¿Qué hay de la documentación? 23

Instalando Gmodulo 24Antes de empezar 24Instalación de los paquetes 25

Buscando un puerto 25El archivo gpd.passwd 26Puesta en marcha del demonio GPD 26

hacking Gmodulo 26Organización de la documentación 26

Documentación de desarrollo 28Manual de Desarrollo 28Manual de Programación 28

Guía de estilo y normas de codificación 28Normas de identificación (Naming conventions) 28

Identificación de clases 29Identificación de archivos 29Identificación de funciones externas 30Identificación de funciones estáticas 30Identificación de estructuras y enumeraciones 30Identificación de macros y constantes 30

Normas para la organización del código 30Espacios y tabuladores 31Manejo de bloques de código 31Política de paréntesis 32Declaración de funciones e implementación 32Comentarios 33

Declaración de variables 33Estructura de los archivos fuente 33

Archivos de cabecera 34Archivos “.C” 35Uso de sutructuras privadas 37

Estructura de directorios 37Creación de parches 38

Estilo de diff 38Uso de pach y diff 39Antes de enviar 39

4 octubre 2003

Valgrind 39

2 Proveedores. La estructura remota de Gmodulo 41Introducción 41

Objetivo 42Ámbito 42Referencias 42Resumen 42

Mecanismos de comunicación distribuida entre procesos 43Llamadas a procedimientos remotos, rpc 43

Procedimiento 44Java™ Remote Method Invocarion, rmi 45

Procedimiento 45rmi-iiop 46

Sistemas remotos de invocación orientados a caracter 46xml-rpc 47Simple Object Acess Protocol: soap 47

Common Object Request Broker Architecture, corba 48Objetos en sistemas distribuidos 48

iiop: interoperatibilidad en corba 49Formato de las cadenas ior 50

Representación de una cadena ior 51Internet Inter-ORB Protocol, iiop 51

Formato de los mensajes en iiop 52Mensaje Request 53Mensaje Reply 55Otro tipo de mensajes de la especificación 56

ORBit. corba para gnome 57Objetos remotos con gnome 57

Motivación 58Bonobo 59Bonobo Activation 59

Gmodulo Provider: Una posible solución 60Concepto de Proveedor 61Seguridad de las comunicaciones 62Localización e instanciación proveedores 63

Servicio de Nombres 63Object Activating Framework, oaf 64

Contenidos 5

Instanciación de proveedores 65Registro de proveedores 68

Archivo de registro de proveedores (arp) 69Servicio de notificación 69Comportamiento de los proveedores 69

Desarrollo de plugins para la arquitectura de Gmodulo Provider 70Concurrencia 70Modelo de vida de los objetos 71

Activación bajo demanda (Transient Objects) 71Extension Beans Definition Language 72

Glosario 73

Bibliografía 75

6 octubre 2003

PARTE I

Introducción al desarrollo de Gmodulo

IIntroducción al desarrollo de GmoduloUna de las grandes carencias en lo referente al desarrollo de softwere libre, sobre todo para GNOME, es la ausencia de documentación de desarrollo. A pesar de que existen mecanismos que permiten la generación de documentación automática y actualizada, esta resulta insuficiente desde el punto de vista de la ingeniería del software, que requiere documentación acerca de la arquitectura y del proceso de desarrollo producto.

Los capítulos en esta sección tratan de solucionar este problema, describiendo el proceso de desarrollo y las motivaciones que condujeron a las decisiones tomadas, pero tratando de no seguir la disciplina de una metodología en particular. De este modo, facilitamos la comprensión de la solución al programador, al no necesitar el conocimiento previo de dicha metodología para comprender la información contenida en esta parte del manual.

Los capítulos de esta sección descubren los siguientes aspectos:

■ Primeros pasos en Gmodulo

Lea este capítulo para conocer los aspectos más relevantes de Gmodulo. Si no tiene intención de leer nada más de este manual, lea este capítulo.

■ Proveedores. La estructura remota de Gmodulo

Este capítulo describe las características específicas del módulo gmodulo-provider y su participación dentro de la arquitectura global de Gmodulo.

7

8 octubre 2003

CAPÍTULO 1

Primeros pasos en Gmodulo

1Primeros pasos en GmoduloLa información contenida en este capítulo describe qué es Gmodulo, qué partes lo componen y cómo contribuir al proyecto.

■ “Introducción” en la página 9■ “Nociones básicas sobre la arquitectura de Gmodulo” en la página 10■ “Localización y acceso al código fuente” en la página 15■ “Compilación de los archivos fuente” en la página 19■ “Instalando Gmodulo” en la página 24■ “hacking Gmodulo” en la página 26

IntroducciónCompilar y trabajar en el desarrollo de Gmodulo puede resultar algo complicado y frustrante inicialmente. Desafortunadamente, este manual no hará que la curva de aprendizaje sea un poco mas suave o un poco menos abrupta, pero al menos si servirá como punto de partida inicial a la solución.

Este manual asume que usted está utilizando una versión de un sistema Linux ™ razonablemente actualizado.

ObjetivoHabitualmente, comenzar el desarrollo de aplicaciones con unas determinadas librerías suele ser una tarea ardua de acometer si no se dispone de la documentación apropiada. Mas aún, colaborar en el desarrollo de esas librerías, se convierte en una auténtica pesadilla sin la documentación técnica que nos guíe en esas primeras horas de desarrollo. Este capítulo trata de facilitar esa andadura con Gmodulo.

9

Nuestro objetivo es responder al menos a las siquientes preguntas:

■ Cómo obtener Gmodulo.■ Cómo compilarlo e instalarlo.■ Cómo depurarlo.■ Cómo escribir y enviar un parche.

ÁmbitoEste capítulo forma parte del manual de referencia de Gmodulo. Los procesos aquí descritos se limitan exclusivamente al desarrollo de esta aplicación.

Referencias■ GNU coding standrdads, v2003, Free Software Foundation.■ GTK Library (GLIB), v1.2, Gtk Team.■ Extension Beans Data Language (EBDL), v1.0, Universidad de Salamanca.■ Advanced Packing Tool (APT), v0.55, Debian Community.

ResumenGmodulo es una solución para la gestión distribuida de módulos. Esta aplicación es capaz de ejecutarse en la mayor parte de sistemas UNIX™ en los que se encuentre disponible GNOME. Así mismo, el uso de CORBA en la parte remota de la solución, hace posible que podamos administrar aquellas plataformas que, sin necesidad de soportar GNOME, puedan hacer uso de las librerías ORBit, Glib y EBDL.

Nociones básicas sobre la arquitectura de GmoduloGmodulo es una aplicación con una arquitectura multicapa. En concreto, tres son las capas en las que se dividió:

■ Gmodulo Provider.■ Gmodulo Monkey.■ Gmodulo Shell.

10 Nociones básicas sobre la arquitectura de Gmodulo • octubre 2003

Este nivel de fraccionamiento fue el resultado de aplicar dos principios básicos de la ingenieria del software:

La sección “Estructura de la solución” en la página 11 describe con mayor detalle esta división y las razones que condujeron a tomar esta decisión.

Estructura de la soluciónCORBA es un framework que permite la comunicación entre diferentes aplicaciones de forma independiente tanto a la plataforma en la que se encuentran el cliente y el servidor, como al lenguaje utilizado para construirlos. Gmodulo hace uso de este framework para:

■ Separar la lógica del dominio del problema de la implementación concreta a cada plataforma.

■ Separar ese dominio del problema de la interfaz utilizada para manejar la información proporcionada por el dominio.

Dadas las necesidades1 que debía satisfacer Gmodulo y la tecnología disponible, se decidió por utilizar una arquitectura multicapa que utiliza CORBA como mecanismo de comunicación entre las mismas.

La figura “Vista de la Arquitectura de Gmodulo” en la página 12 muestra la arquitectura de Gmodulo y las relaciones existentes entre las diferentes capas.

TABLA 1-1 Paquetes de Gmodulo

Principio Descripción

Modularidad Propiedad que tiene un sistema que ha sido descompuesto en un conjunto de módulos cohesivos y débilmente acoplados [Booch, 1993]. Esto facilita la implementación y depuración, al reducir la complejidad y ,por consiguiente, aumentar la claridad del software.

Encapsulamiento Técnica de modelado e implementación que separa los aspectos externos de un objeto de los detalles internos de implementación de un objeto [Rumbaugh, et al., 1996]. la utilización de Gtk permite crear una barrera conceptual sobre la información y servicios de los objetos, haciendo que estos permanezcan juntos.

1. Para obtener mas información acerca de estas necesidades y de los requisitos que la aplicación debía satisfacer, consultar el documento visión.

Capítulo 1 • Primeros pasos en Gmodulo 11

FIGURA 1-1 Vista de la Arquitectura de Gmodulo

Como puede verse en la imagen, no existe dependencia implícita de la capa de servicio de Gmodulo con un servidor X Window.

La tabla “Paquetes de Gmodulo” en la página 12 describe los paquetes que conforma el universo de Gmodulo.


Paquete Descripción

Gmodulo Provider Contienen lo que comúnmente conocemos como servidor. Se compone de un servidor http encargado de proporcionar referencias CORBA de los sirvientes registrados en este servidor. Estos sirvientes implementan la funcionalidad necesaria para permtir operar del mismo modo en todos aquellos equipos que actuen como servidores, independientemente de su naturaleza hardware o software.

Gmodulo Monkey

Gmodulo Provider

PluginsServidor de Referencias

Peticiones Locales Peticiones Remotas iModule iSearch

Servicios Principales

Seguridad EBDL

Cache

Lógica del Modelo

KnowledgeModel

CORBAGateways

Monikers

Gmdl<<moniker>>

BonoboComps.

Gmodulo Shell

Empotrables Shell

Resumen Sistemas Granjas

iShellView

iShellModelo Vista

iShellComponent


La plataforma actual de desarrollo la constituyen las librerías de GNOME versión 1.4. La sección “Dependencias. Integración con gnome” en la página 13, describe estas dependencias con el entorno GNOME y cómo estas dependencias han afectado al diseño de la solución.

Dependencias. Integración con GNOME

Desde un primer momento, se ha tenido en cuenta que dada la magnitud del proyecto, uno de los principales riesgos para su consecución era la evolución de las librerías de las que podría depender Gmodulo. Teniendo esto en cuenta, se han utilizado dos criterios diferentes a la hora de elegir las librerías de las que dependería la aplicación:

■ Mantenimiento a cargo de empresas del sector o desarrolladores conocidos.■ Portabilidad y dependecias de las mismas.

Además de estas condiciones, y dado que gmodulo-provider debía soportar el mayor numero posible de plataformas, se concluyó que para esta parte de la plataforma se limitase al máximo el numero de dependencias con respecto a las librerías de GNOME, facilitando de este modo la migración a otras plataformas o a nuevas revisiones de las librerías de las que dependa.

El resto de los paquetes encargados principalmente de contener la lógica de la aplicación y de la interacción con el usuario, hacen uso de las librerías de GNOME. Con esto se consigue, desde el punto de vista del usuario, una cohesión de la aplicación con el resto del entorno, y desde el punto de vista del desarrollador, se evita la necesidad de crear nuevas rutinas para el desarrollo de tareas comunes, al reutilizarse las existentes en las librerías de desarrollo de GNOME.

Gmodulo Monkey Constituye el núcleo de la aplicación. Es la capa encargada de comunicarse y operar con los equipos remotos mediante el uso de las interfaces servidas por Gmodulo Provider. Esta es la librería de la que los programadores se servirán para desarrollar aplicaciones que hagan uso de la funcionalidad aportada por Gmodulo.

Esta librería depende de GNOME y es local al cliente.

Gmodulo Shell Interfaz gráfica totalmente integrada con el escritorio GNOME. Hace uso del modelo de componentes Bonobo que permite extender fácilmente su funcionalidad. Depende de Gmodulo Monkey directamente para acceder a la información distribuida entre los servidores.




La tabla “Principales dependencias de Gmodulo” en la página 14 contiene una descripción de las dependencias de los diferentes librerías que dan forma a Gmodulo.

Gmodulo tiene otras dependencias no mencionadas anteriormente, entre las que destacan las utilizadas para desarrollar paquetes conformes al estándard GNU en GNOME 1.4.

Un caso particular: gtk-docgtk-doc es un sistema de docuemntación automática para Gtk. Mediante un sistema de plantillas y de inserciones en el código fuente, gtk-doc se encarga de trasladar cada cambio realizado en el código y que pueda ser reflejado, a la documentación.

TABLA 1-3 Principales dependencias de Gmodulo


Glib Una librería de proposito general, compuesta de una serie de utilidades no específicas a una interfaz gráfica. GLib provee con tipos de datos simples y abstractos, macros, utilidades para manejar archivos y cadenas, así como un bucle de eventos.

libXML Esta librería implementa la funcionalidad necesaria para manejar flujos de cadena XML, XSL y XSLT, tal y como se describe en la recomendación XML. Incluye una interfaz DOM y SAX para manejar estas cadenas.

ORBit Implementación de la especificación CORBA versión 2.2, utilizando para ello el perfil definido para el lenguaje“C”. ORBit constituye una de las implementaciones libres más rápidas de la especificación.

Gtk Librería en lenguaje “C” que permite el desarrollo de aplicaciones orientadas a objetos. En la versión utilizada (versión 1.2) implementa un sistema de tipos y un conjunto de widgets que facilitan el desarrollo de interfaces gráficas para X window.

Bonobo Añade a CORBA la gestión del ciclo de vida de los componentes y poporciona un conjunto de interfaces para la interacción de los mismos, todo ello a través de Gtk. En resumen, facilita el desarrollo de componentes al estilo de la librería OLE.

GAL Implementa una serie de widgets que pueden utilizarse para realizar interfaces gráficas más completas.

GtkHTML Implmenta un widget que permite la visualización de paginas HTML. También permite modificar código HTML.


Como resultado, se obtiene una serie de documentos en formato DocBook a partir de los cuales, y mediante hojas de estilo apropiadas, es posible obtener documentos en formato HTML o PDF, por ejemplo.

Otro caso no tan particular: pkg-configpkg-config es un sistema que permite la gestión de los parametros de compilación y enlazado de librerías para ser usado en combinación de automake y autoconf. Reemplaza los scripts de configuración que venian utilizándose con anterioridad, obteniendo la información de archivos con metadatos acerca de las librerías. Esto facilita enormemente la obtención de los parámetros necesarios para compilar y enlazar las librerías.

Desafortunadamente, pkg-config no se usa de un modo consistente para versiones previas a GNOME 2.0, estando presente sólo en las distribuciones de algunos vendedores, con lo que debemos prescindir de su uso.

Licencias de uso y distribuciónGmodulo se distribuye mayoritariamente bajo la licencia GNU General Public License GNU GPL. No obstante, parte de las librerías son distribuidas bajo licencia GNU Lesser General Public License o GNU LGPL lo que permite que aplicaciones propietarias puedan enlazar con las liberías de Gmodulo. Todas ellas, tienen una arquitectura orientada a objetos basada en el lenguaje “C”, siendo la flexibilidad y la facilidad de desarrollo de bindings para otros lenguajes, una de sus principales cualidades.

Localización y acceso al código fuentePara familiarizarse y poder asimilar con mayor facilidad los conceptos de Gmodulo, se hace necesario obtener el código fuente de la aplicación. Esta sección detalla las diferentes opciones disponibles para ello.

¿Qué versión?Es posible acceder a diferentes versiones del código fuente de Gmodulo en función del grado de estabilidad del mismo:

■ Paquetes TAR.GZ o RPM, si se desea un grado de estabilidad del código alta.


■ Mediante el acceso directo al servidor CVS del proyecto, si se desea obtener el código más reciente, pero también más inestable.

La elección de una u otra fuente depende del intereés que se tenga en el proyecto. Si lo que se desea es contribuir a este, entonces deberá utilizar siempre una versión actualizada del código del servidor CVS. En cualquier otro caso, es más recomendable el uso de código preempaquetado en cualquiera de los formatos disponibles.

Obtención de paquetes compilados mediante APT

APT (Advanced Package Tool) es bien conocido por los usuarios de la distribución Debian™ dado que es utilizado como sistema de distibución de paquetes por defecto junto con DPKG. APT ha sido portado por Conectiva™ para que funcione con paquetes del tipo RPM, y lo han estado utilizando durante algún tiempo en su distribución GNU/Linux™.

Las buenas noticias son que APT para RPM puede ser usado en cualquier distribución que haga uso del sistema de paquetes RPM. Todo lo que se necesita es la herramienta APT para RPM y un repositorio desde el que poder descargar los paquetes RPM y los metadatos necesarios para que APT pueda funcionar. En la dirección http://www.freshrpms.net/apt puede encontrarse más información acerca de APT y las versiones precompiladas de esta herramienta.

Gmodulo cuenta con su propio repositorio de paquetes compilados para RedHat™, desde las versiones 6.2 en adelante. Destacar aquí que sólo se encuentran disponibles todos los paquetes para aquellas distribuciones que soportan GNOME 1.4 o superior. En el resto de los casos, sólo está disponible el paquete gmodulo-provider, de modo que sistemas que tengan estas distribuciones instaladas puedan ejercer de servidores para la aplicación.

Una vez instalado APT en el sistema, los clientes pueden utilizar el repositorio de Gmodulo poniendo las siguientes entradas en el archivo /etc/apt/sources.list:

rpm http://gmodulo.sf.net/apt redhat/Versión/en/i386 gmodulo-deps gmodulo-release

rpm-src http://gmodulo.sf.net/apt redhat/Versión/en/i386 os gmodulo-deps gmodulo-release

En las entradas anteriores, substituir la cadena Versión por la versión de su distribución.

En el caso de que lo que deseemos sean los paquetes de desarrollo, deberemos remplazar gmodulo-release de la siguiente forma:

rpm http://gmodulo.sf.net/apt redhat/Versión/en/i386 gmodulo-deps gmodulo-snapshots

16 Localización y acceso al código fuente • octubre 2003

rpm-src http://gmodulo.sf.net/apt redhat/Versión/en/i386 os gmodulo-deps gmodulo-snapshots

Una ver hecho esto, ya podemos descargar los paquetes que conforman la aplicación Gmodulo. Para actualizar la información de los repositorios escriba:

# apt-get update

Para instalar el paquete deseado introduzca:

# apt-get install gmodulo-package

En donde gmodulo-package puede ser gmodulo-provider, gmodulo-monkey o gmodulo-shell. APT automáticamente se encargará de resolver las dependencias y de instalar los paquetes necesarios para su correcto funcionamiento. También puede utilizarse el paquete gmodulo-universe para descargar todos los paquetes de Gmodulo, incluyéndose enre estos, los de desarrollo.

Acceso al servidor de desarrollo: CVS

CVS es una aplicació cliente-servidor encargada del control de los cambios realizados al código fuente. CVS mantiene un historial del arbol de código, en términos de una serie de cambios. Marca cada cambio con el tiempo en que se realizó, y el usuario que lo llevó a cabo. Habitualmente, esta persona añade un pequeño texto explicativo de los cambios realizados y la razón por la que se realizan los mismos. Con esta información, CVS puede ayudar a los desarrolladores a responder preguntas del tipo:

■ ¿Quién llevó a cabo un cambio?■ ¿Cuando lo hizo?■ ¿Porqué lo hizo ?■ ¿Qué otros cambios realizo en ese instante de tiempo?

Dado que Gmodulo está siendo desarrollado en la actualidad para un entorno técnicamente obsoleto (GNOME 1.4), se han definido dos versiones disponibles de Gmodulo, las cuales se corresponden con dos ramas en el repositorio CVS. Estas ramas pueden identificarse siguiendo las recomendaciones que aparecen en el el GEP4 o en el documento de control de cambios.

La rama actual de desarrollo se corresponde con el desarrollo para GNOME 1.4. En el momento en que se hayan cumplido los requisitos esenciales de la aplicación se creará una rama de esta versión para realizar correciones y solucionar fallos, mientras que en la rama principal comenzará la conversión a GNOME2.

Acceso anónimo al servidorEs posible acceder al servidor CVS mediante acceso anónimo. Para ello escriba en la consola:


$ cvs -d:pserver:[email protected]:/cvsroot/gmodulo login

$ cvs -d:pserver:[email protected]:/cvsroot/gmodulo -z3 co modulename

El módulo al que se desea acceder debe ser especificado como modulename. El servidor contiene los módulos de desarrrollo de Gmodulo y de los paquetes de soporte para el desarrollo, como la documentación. En concreto, además de los previamente mencionados, gmodulo-provider gmodulo-monkey y gmodulo-shell, podemos encontrar los siguientes:

Cuando la aplicación cliente pregunte por la palabra de paso simplemente presione la tecla Enter. Una vez hecho esto, tan sólo nos queda esperar a que los archivos se hayan descargado en el equipo y ya podremos trabajar con estos.

También es posible acceder con el navegador de internet a los módulos mencionados anteriormente a través de la interfaz web del repositorio CVS, accesible desde la página principal del proyecto.

Acceso para desarrolladoresUna de las formas de contribuir al proyecto 1 es trabajando directamente en los archivos fuente. Para poder llevar a cabo estas modificaciones directamente, es necesario estar


gmodulo-doc Documentación de desarrollo, de acuerdo a lo especificado en el Proceso Unificado de Desarrollo.

gmodulo-report Memoria del proyecto, contenida en dos manuales:■ Manual de Desarrollo. También continene una pequeña

memoria sobre el proyecto.■ Manual de Programación.

gmodulo-vicious-scripts Scripts de todo tipo: Generación de los paquetes compilados, actualización de la web, grabación automática de todos los modulos del servidor CVS en un medio físico, etc.

gmodulo-art Imágenes creadas tanto para la solución, como para la página web.

gmodulo-media Archivos necesarios para la grabación en un soporte físico de toda la infraestructura de Gmodulo.

gmodulo-web La página web de Gmodulo

1. Consulte La sección “Creación de parches” en la página 38 para ver otras formas de contribuir al proyecto

18 Localización y acceso al código fuente • octubre 2003

dado de alta como usuario en el servidor y contar con un cliente SSH. Consulte la información disponible sobre el control y gestión de cambios para obtener más información.

Compilación de los archivos fuenteAntes de entrar en detalles de cómo compilar Gmodulo, se debe mencionar que es posible encotrar versiones precompiladas de Gmodulo para RedHat™ y Debian™. Existen repositorios de versiones de desarrollo y de versiones estables a su disposición en la página web de Gmodulo. En ambos casos, es posible utilizar APT para obtener estos paquetes. Dispone de más información acerca de esta herramienta en La sección “Obtención de paquetes compilados mediante apt” en la página 16.

Estos paquetes son de gran utilidad si el único objetivo es desarrollar aplicaciones utilizando las librerías de Gmodulo, o si simplemente desea probar el software. Si por el contrario, su intención es participar en el desarrollo, es recomendable, como ya se mencionó con anterioridad, que acceda directamente al código fuente de desarrollo.

Herramientas de manejo de paquetes y compilaciónGmodulo hace uso del modelo estándard de compilación de GNU propuesto en [FSF, 2003], esto es, el uso de autoconf para la configuración de los paquetes, automake para la generación de los archivos Makefile y libtool para el enlazado de las librerías.

Si usted está compilando Gmodulo desde los paquetes fuente, entonces no necesita que estas herramientas estén disponibles en su sistema, al estar ya incluidas en los paquetes. No obstante, es útil saber un poco acerca del uso y funcionamiento de estas herramientas y del modo en que interactúan con los archivos de código fuente.

Manejo de paquetes GNU

Un paquete de fuentes se distribuye como un archivo de tipo tar.gz el cual es descomprimido en un directorio que contiene todos los archivos fuente como sigue:

$ tar xvzf gmodulo-0.1.tar.gz

En el directorio raiz creado a partir de la sentencia anterior, se encuentra una shell script denominada configure, la cual será invocada para transformar las plantillas de archivos Makefile.in en archivos Makefile adaptados a nuestro sistema operativo. A este script se le pueden pasar una serie de argumentos para determinar cómo debe


compilarse el paquete, y cómo debe instalarse en nuestro sistema. Las opciones disponibles de uso más habitual son:

Nota - Existen otras posibilidades para la compilación de los fuentes. Si su distribución es capaz de manejar paquetes del tipo DPKG o RPM, entonces es recomendable que utilice dichas herramientas para compilar los paquetes. De este modo, garantiza que los archivos generados durante la compilación se instalarán en los directorios apropiados para su distribución.

Para instalar un paquete en /opt/gmodulo, invoque configure como sigue:

$ ./configure --prefix=/opt/gmodulo

Puede obtener una lista completa de opciones llamando a configure con el argumento --help. Por lo general, los valores por defecto suelen ser correctos. Después de que usted haya invocado configure, ejecute el comando make para compilar el paquete e instalarlo.

$ make

$ make install

Si no tiene permisos para escribir en el directorio en el que se va a realizar la instalación, tiene la oportunidad de cambiar eventualmente a root antes de invocar make install.

$ su root

Password: ******

# make install

En el caso de que esté realizando la instalación en un directorio del sistema, también deberá, en algunos sistemas como Linux™, llamar a ldconfig después de invocar a make install demodo que las nuevas librerías instaladas puedan ser encotrardas.

Pasos a seguir: Aspectos a tener en cuentaGmodulo es complejo. Es por esto, que previamente a iniciar la compilación de todos los fuentes que conforman la solución, se deben tener en cuenta una serie de aspectos:

Opción Descripción

--prefix Determina en qué parte del sistema se van a instalar los archivos.

--sysconfdir Indica en qué lugar se encuentran los archivos de configuración del sistema.

20 Compilación de los archivos fuente • octubre 2003

■ Distribución física de los sistemas. Presencia de Firewalls.■ Distribución lógica de los sistemas.■ Dependencias de la aplicación.

Estas decisiones previas determinarán qué partes de la aplicación deben instalarse en cada sistema, y en consecuencia, que argumentos deben pasarse a los scripts de configuración.

Distribución de los sistemas: ¿Clientes o Servidores?Es posible establecer diferentes modelos de configuración de los sistemas en los que se vaya a implantar Gmodulo. Atendiendo a la localización de los sistemas que van a actuar en este escenario como servidores podemos distinguir dos modos de configuración:

El número de sistemas presentes en la solución, es un elemento que también debe tenerse en cuenta. Es posible establecer dos configuraciones diferentes en función del número de clientes que se vayan a utilizar:

TABLA 1-4 Clasificación de sistemas según su localización

Localización Descripción

Local El sistema que actua como servidor, es decir, sobre el que se van a realizar las operaciones, también actua como cliente. Esta configuración se da típicamente cuando el cliente y el servidor son las misma máquina.

Remoto En este caso, el servidor esta separado físicamente del cliente. Esta configuración se da cuando deseamos controlar diferentes equipos, los cuales estan conectados al cliente que utilizaremos para controlarlos mediante una red.

TABLA 1-5 Despliegue de la solición

Relación Descripción

1:N Sólo hay un cliente y múltiples servidores. Esta es la configuración mas común para este tipo de soluciónes. Su implementación resulta sencilla al no ser necesario tener en cuenta problemas de concurrencia, siendo necesario solamente el control del acceso a los servidores.

N:M En este caso, están presentes en la solución un numero indeterminado de clientes. Pueden presentarse problemas de concurrencia si multiples clientes acceden simultaneamente a un servidor determinado.


Inicialmente, Gmodulo sólo dará soporte inicial al primer modelo de despliegue. La presencia de multiples clientes que puedan acceder de forma simultanea a los servidores, no se contempla en los requisitos iniciales. No obstante, es previsible su implementación en proximas revisiones de la solución.

Opciones de configuraciónA continuación se pasa a describir las diferentes opciones de compilación disponibles para los diferentes paquetes que forman parte de Gmodulo. Como ya se mencionó con anterioridad, Gmodulo utiliza las herramientas sugeridas por la Free Software Foundation para la compilación de los archivos fuentes. Entre las opciones mas comunes se encuentran:

Si desea conocer el resto de las opciones comunes disponibles, consulte [FSF, 2003] para obtener más información.

Opciones disponibles en gmodulo-provider

Los argumentos definidos para gmodulo-provider se utilizan principalmente para configurar gpd de acuerdo a los scripts de inicio de la distribución Linux™ en que se va a instalar el software.

TABLA 1-6 Opciones comunes de compilación

Argumento Descripción

--prefix Especifica el directorio en el cual se va a realizar la instalación de los archivos independienes de la arquitectura. Según [LSB, 2003] este directorio es típicamente /usr.

--sysconfdir Directorio de solo lectura en el cual se pueden instalar los archivos de configuración. Según [LSB, 2003] este directorio es típicamente /etc.

TABLA 1-7 Argumentos de compilación de gmodulo-provider


--enable-debug Activa el modo de depuración aumentando el nivel de verbosidad del programa. Esto facilita la traza del programa y la detección de problemas durante la ejecución.

--with-init-script-type Permite especificar el script que se utilizará para el arranque del demonio gpd. Por defecto, el sistema se configura para instalarse en sistemas RedHat™, pero es posible especificar otro tipo de distribuciones.

22 Compilación de los archivos fuente • octubre 2003

Consulte la salida del script configure para obtener más información sobre estos parámatros.

Opciones disponibles para gmodulo-monkey

Los argumentos que pueden especificarse durante la compilación de gmodulo-monkey permiten especificar el modo de acceso a los proveedores.

Las opciones de --enable-provider permiten especificar si el proveedor se localiza en la propia máquina que actuará como cliente, o el proveedor se encuentra en otro sistema diferente. Esto afecta principalmente al rendimiento y al modo de acceso al proveedor.

Opciones para gmodulo-shell

No existen opciones especificas para este paquete de la solución. Consulte La tabla “Opciones comunes de compilación” en la página 22 para ver las opciones disponibles.

¿Qué hay de la documentación?

Gmodulo utiliza gtk-doc para generar la documentación de programación de los diferentes paquetes disponibles en la solución. Aunque es posible obtener esta información compilando cada uno de los paquetes, es preferible utilizar la documentación ya generada en la página del proyecto. Puede obtener mas información acerca de cómo obtener la documentación directamente en La sección “Un caso particular: gtk-doc” en la página 14 y en http://www.gtk.org/rdp.

TABLA 1-8 Argumentos de compilación de gmodulo-monkey


--enable-debug Activa el modo de depuración aumentando el nivel de verbosidad del programa. Esto facilita la traza del programa y la detección de problemas durante la ejecución.

--enable-provider Especifica el modo de acceso que se utilizará para acceder a los proveedores.


Instalando GmoduloEsta sección es un extracto del capítulo con el mismo nombre que puede encontrarse en el Manual de Usuario de Gmodulo. Consulte el Wiki del proyecto para más información.

Antes de empezarLa opción más sencilla para instalar Gmodulo es, de lejos, hacer uso de los paquetes compilados en formato DEB o RPM. Si no existieran para su distribució, entonces, tendrá que instalar el software compilando directamente los archivos fuente. Puede obtener información de cómo realizar esta operación en La sección “Compilación de los archivos fuente” en la página 19.

Actualmente, existen paquetes compilados para las siguientes distribuciones:

TABLA 1-9 Distribuciones soportadas por Gmodulo

Distribución Versión Módulos soportados

RedHat™ 9 Existen paquetes precompialdos para todos los módulos.

8.x Existen paquetes precompialdos para todos los módulos.

7.3 Existen paquetes precompialdos para todos los módulos. Se necesitan versiones especiales de los paquetes:

■ libgal-0.21■ gnet-1.1.4

7.2 Existen paquetes precompialdos para todos los módulos. Se necesitan versiones especiales de los paquetes:

■ libgal-0.21■ gtkhtml-1.0.4■ gnet-1.1.4■ bonobo-conf-0.14

6.2 Paquetes disponibles:

■ gmodulo-provider

Debian Woody 3.0p1 Existen paquetes precompialdos para todos los módulos.

24 Instalando Gmodulo • octubre 2003

Nota - gmodulo-provider depende también de una librería desarrollada conjuntamente con este proyecto, denominada EBDL. Los aspectos ténicos acerca de esta librería quedan fuera del alcance de este manual.

Puede obtener el código, ya sea compilado o no, en la zona de descargas de Gmodulo. Si desea más información acerca de la localización del código, o de las herrramientas disponibles para su instalación, consulte La sección “Localización y acceso al código fuente” en la página 15.

Instalación de los paquetesA continuación pasaremos a describir los pasos a seguir para instalar Gmodulo en una distribución RedHat™. Para instalar Gmodulo en Debian™, consulte la documentación disponible sobre DPKG en la página web del proyecto Debian.

El proceso para instalar los paquetes sencillo. En este caso utilizaremos la configuración básica, en la que un sólo equipo actua tanto como cliente y como servidor.Para ello, cambiar eventualmente a root y ejecute el commando rpm como sigue:

$ su root

Password: ******

# rpm -ivh gmodulo-*.rpm

En el caso de que esté actualizando una versión previa de Gmodulo, invoque rpm de este modo:

# rpm -Uvh gmodulo-*.rpm

Nota - Si las dependencias de alguno de los paquetes no han sido previamente satisfechas, la operación no tendra éxito. Instalelas, o bien, utilice la herramienta apt-get para resolverlas. Consulte La sección “Obtención de paquetes compilados mediante apt” en la página 16 para más información.

Si todo transcurrió con normalidad, ya sólo queda configurar el servidor.

Buscando un puertogmodulo-provider hace uso del puerto 666 para establecer conexiones remotas con los clientes. Por el momento no se ha establecido un procedimiento para cambiar esta configuración por defecto y sólo es posible pasando por la linea de comandos el puerto que se desea utilizar:


# gpd -p port

Nota - Tenga en cuenta que debe tener permisos administrativos para poder ejecutar correctamente gpd. Existe una discusión acerca de la seguridad en el Wiki de Gmodulo y en capítulos posteriores.

El archivo gpd.passwdEste archivo restringe el acceso a los servicios ofertados por los sistemas que actuan como servidor. Esto permite que usuarios que no tengan permisos administrativos puedan tener acceso total a dichos equipos. Consulte el archivo para saber qué capacidades están disponibles para los usuarios y el modo de añadirlos.

Puesta en marcha del demonio GPDPara iniciar el demonio, es recomendable utilizar el script disponible para tal efecto. En el caso de RedHat™, este se incova utilizando la orden service:

# service gpd start

Si desea que Gmodulo esté disponible desde el momento en que se inicia el sistema, utilice chkconfig para configurar los runlevels en que deber´ iniciarse el demonio:

# chkconfig --level 345 gpd on

Consulte el manual de referencia de RedHat™ para saber más acerca de estas herramientas.

hacking GmoduloA pesar de la documentación disponible, su tamaño y complejidad hacen que programar en Gmodulo sea difícil inicialmente. No obstante, sólo son necesarios algunos conocimientos en “C” y CORBA y sobre todo, un poco de paciencia para poder contribuir al proyecto.

Organización de la documentaciónLa principal fuente de información sobre el desarrollo, son los documentos técnicos creados durante las diferentes iteracciones del proceso. Estos documentos responden a

26 hacking Gmodulo • octubre 2003

los que cabría de esperar en un proyecto que sigue el proceso unificado de desarrollo RUP.

Estos documentos pueden obtenerse del módulo gmodulo-doc en el servidor CVS. La estructura de dicho modulo sigue las recopmendaciones en cuanto a estructura de documentación que aparece en la metodología:

Ademaás de estos documentos, existen dos manuales que resumen o, en algunos casos, amplian esta información. Estos dos manuales son:

■ Manual de Desarrollo.■ Manual de Programación

Consulte La sección “Documentación de desarrollo” en la página 28 para obtener más informació sobre estos manuales.

TABLA 1-10 Estructura del módulo gmodulo-doc

Directorio Descripción

System Requirements Contiene la información relativa al análisis de la solución:

■ Modelos y diagramas de Casos de Uso.■ Bases de datos con los requisitos de la solución.■ Documentos de analisis: Visión (VIS), Especificación de

Casos de Uso (UCS) y Especificación de Casos de uso Suplementarias (SUPP).

Esta información también se encuentra disponible en el manual de desarrollo.

System Design and Implementation

Contiene los modelos de diseñ y los documentos desarrollados durante la fase de diseño. Puede obtener más información sobre los documentos generados en esta fase consultando el documento Proceso de Desarrollo.

System Management Básicamente, contiene los planes que describen el desarrollo del proyecto, como son:

■ Plan de Iteración.■ Lista de Riesgos.■ Proceso de Desarrollo.■ Plan de Gestión de Cambios.■ Plan de Gestión de Requisitos.■ Plan de Desarrollo del Software.

Existe la posibilidad de consultar esta información en el manual de desarrollo, o en la página web del proyecto.


Documentación de desarrolloSe han creado dos manuales para facilitar el aprendizaje y mantenimiento de Gmodulo y para recoger el proceso de desarrollo, y los aspectos técnicos del mismo desde el punto de vista de la ingenieria del software.

Manual de Desarrollo

Recoge los aspectos de desarrollo desde un punto de vista técnico. Este manuaal esta pensado para aquellos que deseen conocer las decisiones tomadas durante el desarrollo, y los procedimientos y pasos seguidos durante la ejecución del mismo. Se compone de dos partes:

■ Una memoria, que contiene informació sobre el entorno de desarrollo, las librerís utilizadas, la metodología y las dificultades surgidas durante este tiempo.

■ La documentación tecnica del proyecto, agrupada según el tipo de persona al que se destina, el usuario o el desarrollador.

La versión más actual puede leerse On line en la dirección http://gmodulo.sf.net/docs/html/manual. También es posible descargar la versión en formato PDF en la sección de documentación de la página web del proyecto.

Manual de Programación

Contiene un breve tutorial sobre la estructura de Gmodulo y el API de programación. Puede encontrarse también en la sección de documentación de la página web del proyecto.

Guía de estilo y normas de codificaciónEsta sección define un estilo de codificación mediante un conjunto de normas y recomendaciones. Con esto se pretende facilitar el mantenimiento, la manejabilidad y la comprensión del código fuente.

Nota - Debe tenerse en cuenta que cualquier código que no siga estas recomendaciones, no será incluido en Gmodulo. Cerciónese de ello antes de enviar cualquier tipo de parche.

Normas de identificación (Naming conventions)El esquema de nombres varía según el módulo en el que estemos trabajando. De este modo resulta más sencillo identificar el módulo al que pertence una función. Localizar


la definición o implementación de una función, una enumeración o una clase, se realiza simplemente buscando el nombre de la misma.

Identificación de clases

Los nombres de clases deben ir precedidos con un prefijo que identifique a que módulo pertenecen. Este prefijo correnpondería a lo que en otros lenguajes se conoce como espacio de nombres o namespace.

EJEMPLO 1-1 Nombres de clases

Class GShellView

Class GmAccountabilityType

La tabla “Esquema de nombres para las clases de Gmodulo” en la página 29 define los prefijos definidos y utililizados por Gmodulo.

Identificación de archivos

Gmodulo sigue el esquema utilizado por GNOME para nombrar los ficheros. Este esquema se define como sigue:

■ No se permite el uso de mayúsculas.

■ Utilizar un guión bajo (“_”) para separar ls palabras.

■ Añadir como prefijo gp y gpd para las librerías de gmodulo-provider, gm y gmb para gmodulo-monkey y g y gs para gmodulo-shell.

EJEMPLO 1-2 Nombres de archivo

gm-object.c

g-shell.h

TABLA 1-11 Esquema de nombres para las clases de Gmodulo

Paquete Prefijos utilizados

Gmodulo Shell ■ G para las clases de la librería libgshell.■ Gs para las clases de la librería libgs-component.■ Aunque el nombre de la clase sea un nombre compuesto,

no se usarán guiones ("_") en los nombres.

Gmodulo Monkey ■ Gmb para las clases de la librería libgm-core.■ Gm para las demás librerías.■ Aunque el nombre de la clase sea un nombre compuesto,

no se usarán guiones ("_") en los nombres.

Gmodulo Provider ■ Gpd para las clases de la librería libgp-daemon.■ Gp para las demás librerías.■ Aunque el nombre de la clase sea un nombre compuesto,

no se usarán guiones (“_”) en los nombres.


g-shell-view.c

gp-provider.h

Identificación de funciones externas

Las funciones externas deben ser nombradas como el archivo al que pertenecen, pero sustityuendo el guión simple (“-”) por un guión bajo (“_”).

EJEMPLO 1-3 Nombres de funciones externas

g_shell_create_view (...)

gmb_module_load (...)

Identificación de funciones estáticas

Usan el mismo esquema que las funciones externas. Para mantener la coherencia se mantiene el prefijo, pero deberán utilizar la palabra reservada static.

Identificación de estructuras y enumeraciones

Enumeraciones y estructuras siguen el mismo esquema de identificación que las clases.

EJEMPLO 1-4 Normas para enumeraciones y estructuras

typedef enum {

GM_MODULE_STATE_LOAD,

GM_MODULE_STATE_UNLOAD,

GM_MODULE_STATE_FLOATING

} GmModuleState;

Se aplica el mismo ejemplo para las estructuras.

Identificación de macros y constantes

Macros y constantes deben identificarse del mismo modo que las funciones, pero utilizando letras mayúsculas en lugar de minúsculas.

EJEMPLO 1-5 Nombres para macros y constantes

#define GM_TYPE_PARTY (gm_party_get_type ())

#define G_IS_SHELL_VIEW(obj) (GTK_CHECK_TYPE ((obj),G_TYPE_SHELL_VIEW))

Normas para la organización del códigoCon el fin de que el código sea mas fácil de leer, se han definido una serie de reglas para formatear y organizar el código que deben ser seguidas. El principal objetivo de estas normas es aumentar la legibilidad del código.


Espacios y tabuladores

El indentado debe ser realizado utilizando tabuladores, teniendo en cuenta que un tabulador tiene ocho espacios de ancho.

EJEMPLO 1-6 Espaciado y tabulación

GmParty *

gm_module_new (const gchar *name)

{

GmParty *module;

module = GM_MODULE (gtk_object_new (GM_TYPE_MODULE, "Name", name, NULL));

return module;

}

Este proyecto usa el mismo estilo usado en GNOME y por los desarrolladores del kernel de Linux™.

Manejo de bloques de código■ Todas las sentencias if-, while-, do-, for- deben usar llaves, incluso las

compuestas de una sola línea. Con ello se consigue que sea más fácil determinar donde comienza y termina la sentencia y dado que no es necesario comprobar que se tienen llaves, es más sencillo añdir nuevas líneas.

EJEMPLO 1-7 Uso de llaves en sentencias de bloque

if (i >= 0) {

/* do something */

}

■ Para ese tipo de sentencias, la llave abierta debe situarse en la misma línea que la sentencia, con un espacio entre la sentencia y la llave abierta.

EJEMPLO 1-8 Sentencias de una línea

for (i = 0; i < len; ++i) {

/* my one-line */

}

■ En el caso de las funciones, la llave abierta debe situarse debajo de la función.

EJEMPLO 1-9 Uso de llaves con funciones

void static

my_function (void)

{

/* do something */

}

■ Sentencias del tipo If-elseif-else deben usar el siguiente formato.

EJEMPLO 1-10 Sentencias If-elseif-else

if (...) {

/* do something */


}

else if (...) {

/* do something else */

} else {

/* do yet another thing */

}

Política de paréntesis

La regla para los paréntesis es sencilla. Siempre que sea posible, debe introducirse un espacio antes del paréntesis de apertura.

EJEMPLO 1-11 Normas para los paréntesis

gm_named_object_set_name (GM_NAMED_OBJECT (aobject), "aName");

Declaración de funciones e implementación

Unos consejos básicos acerca de cómo escribir funciones.

■ En declaraciones, poner siempre un argumento por cada archivo y alinear las funciones, tipos y argumentos para facilitar su lectura.

EJEMPLO 1-12 Declaración de funciones

void gm_module_load (GmModule *module,

GmSystem *machine,

gboolean local);

GList *gm_module_get_dependences (GmModule *module);

■ Cuando se implementa la función, se debe tratar de ajustar todos los argumentos en una línea, siempre que no exceda de ochenta caracteres. Si se diese el caso, entonces poner cada argumento en una línea. Poner un espacio entre el tipo del argumento más largo y los argumentos.

EJEMPLO 1-13 Implementación de funciones

void

gm_module_load (GmModule *module, GmSystem *machine, gboolean local)

{

/* ... */

}

gboolean

gm_system_set_pool (GmSystem *Machine,

GmPool *pool,

gchar *name,

gboolean private)

{

/* ... */

}

■ Si entre los argumentos hay punteros con * o ** , estos deben alinearse con el argumento, no con el tipo.


EJEMPLO 1-14 Alineación de argumentos de punteros

gboolean

gm_shell_view_do_command (GShellView *view,

const gchar *uri,

gboolean force,

GError **error)

{

/* ... */

}

Comentarios

Como norma, la implementación de las funciones deberán estar comentadas, siguiendo para ello el estilo de comentarios utilizado para el API de gtk y GNOME.

EJEMPLO 1-15 Comentario de una función

/**

* gm_stream_fs_new_with_fd_and_bounds:

* @fd: a file descriptor

* @start: the first valid position in the file

* @end: the first invalid position in the file, or GM_STREAM_UNBOUND

*

* Returns a stream associated with the given file descriptor and bounds.

* When the stream is destroyed, the file descriptor will be closed.

*

* Return value: the stream

**/

Todos los comentarios, como puede apreciarse en los ejemplos vistos hasta el momento, deben realizarse en inglés, de modo que otros desarrolladores puedan participar en el desarrollo código.

Declaración de variablesLas variables deben alinearse del mismo modo que los argumentos de las funciones. Poner un espacio entre el tipo más largo y los argumentos y alinear con * y ** del mismo modo que en los argumentos de las funciones.

Estructura de los archivos fuenteTodos los archivos fuentes deben comenzar con la cabecera usada en Gmodulo. En ellos deberán figurar el nombre del autor del archivo fuente y una dirección de correo electrónico de contacto.


EJEMPLO 1-16 Cabecera comuún para los archivos fuente

/* -*- Mode: C; indent-tabs-mode: t; c-basic-offset: 8; tab-width: 8 -*- */

/*

* filename:

*

* Copyright (C) 2003 Su nombre.

* Copyright (C) 2003 Universidad de Salamanca.

*

* This library is free software; you can redistribute it and/or

* modify it under the terms of version 2 of the GNU General Public

* License as published by the Free Software Foundation.

*

* This program is distributed in the hope that it will be useful,

* but WITHOUT ANY WARRANTY; without even the implied warranty of

* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the gnu

* General Public License for more details.

*

* You should have received a copy of the GNU General Public

* License along with this program; if not, write to the

* Free Software Foundation, Inc., 59 Temple Place - Suite 330,

* Boston, MA 02111-1307, USA.

*

* Author: Su nombre <mi@direccion_de_correo.com>

*/

la primera línea es para que todos aquellos desarrolladores que usen Emacs utilicen el espacio de tabulación y el modo de programación adecuado.

Archivos de cabeceraLos archivos de cabecera se construyen de la siguiente manera.

EJEMPLO 1-17 Archivos de cabecera

/* -*- Mode: C; indent-tabs-mode: t; c-basic-offset: 8; tab-width: 8 -*- */

/*

* gm-object.h

*

* Copyright (C) 2003 Carlos Martín

* Copyright (C) 2003 Universidad de Salamanca.

*

* This library is free software; you can redistribute it and/or

* modify it under the terms of version 2 of the GNU General Public

* License as published by the Free Software Foundation.

*

* This program is distributed in the hope that it will be useful,

* but WITHOUT ANY WARRANTY; without even the implied warranty of

* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the gnu

* General Public License for more details.

*

* You should have received a copy of the GNU General Public


* License along with this program; if not, write to the

* Free Software Foundation, Inc., 59 Temple Place - Suite 330,

* Boston, MA 02111-1307, USA.

*

* Author: Carlos Martín <[email protected]>

*/

#ifndef __GM_OBJECT_H__

#define __GM_OBJECT_H__

#include <gm-debug.h>

#include <gtk/gtkobject.h>

G_BEGIN_DECLS

#define GM_OBJECT_TYPE (gm_object_get_type ())

#define GM_OBJECT(obj) (GTK_CHECK_CAST ((obj), GM_OBJECT_TYPE, GmObject))

#define GM_IS_OBJECT(obj) (GTK_CHECK_TYPE ((obj), GM_OBJECT_TYPE))

#define GM_IS_OBJECT_CLASS(klass) (GTK_CHECK_CLASS_TYPE ((klass), GM_OBJECT_TYPE))

#define GM_OBJECT_GET_CLASS(obj) (GM_OBJECT_CLASS (GTK_OBJECT (obj)->klass))

typedef struct _GmObject GmObject;

typedef struct _GmObjectPrivate GmObjectPrivate;

typedef struct _GmObjectClass GmObjectClass;

struct _GmObject {

GtkObject parent;

GmObjectPrivate *priv;

};

struct _GmObjectClass {

GtkObjectClass parent_class;

gboolean (*equals) (GmObject *object1,

GmObject *object2);

};

/* Method declarations */

GtkType gm_object_get_type (void) G_GNUC_CONST;

gboolean gm_object_equals (GmObject *object1,

GmObject *object2);

G_END_DECLS

#endif /* __GM_OBJECT_H__ */

Archivos “.C”la cabecera del archivo es idéntica a la utilizada para los archivos de cabecera.

EJEMPLO 1-18 Archivo “C”

/* misma cabecera que el archivo de cabecera */


/* Declaraciones de estructuras o enumeraciones privadas aparecen

* antes de las funciones internas, dado que parte de las funciones internas

* pueden necesitas esas estructuras o enumeraciones

*/

#ifdef HAVE_CONFIG_H

# include <config.h>

#endif

#include <gm-cache.h>

#include <gm-set.h>

#include <gm-queue.h>

#include <gm-system.h>

#include <gm-url.h>

/* Constantes */

#define QUEUE_SIZE 20

/* Propiedades */

enum {

PROP_0,

PROP_LAST

};

/* Declaración de variables globales internas */

static GmCache *cache = NULL;

static GmObjectClass *parent_class = NULL;

/* implementación de funciones internas */

static GmCacheItem *

gm_cache_item_new (const gchar *ior,

const gchar *auth_type,

const gchar *expires,

const gchar *token)

{

/* ... */

}

/* Funciones por defecto para el sistema de objetos de Glib/Gtk */

static void

gm_cache_class_init (GmCacheClass *klass)

{

/* ... */

}

static void

gm_cache_init (GmCache *cache)

{

/* ... */

}


GtkType

gm_cache_get_type (void)

{

/* ... */

}

/* funciones externas */

void

gm_cache_add (GmCache *cache, GmParty *party)

{

/* ... */

}

La razón para establecer este orden es que resulta más sencillo localizar la zona del archivo en que se encuentra definida una función. Siempre que sea posible, mantener un orden alfabético en la implementación de las funciones.

Uso de sutructuras privadasSiguiendo los principios de la POO recomendamos como norma el uso de strucutras privadas tal y como muestra el ejemplo anterior. Esto la encapsulación del cóodigo y garantiza que no se usan variables internas directamente.

Estructura de directoriosGmodulo sigue la estrucutra de directorios recomendada por GNU y que se encuentra en la mayor parte de los proyectos de GNOME.

TABLA 1-12 Estructura común de los paquetes de Gmodulo


tests Contiene pruebas unitarias para cada una de las clases de los paquetes, utilizando para ello un framework de pruebas basado en la arquitectura xUnit.

macros Macros estándard de GNOME 1.4 para su uso en combinación de autoconf y automake.

src Contiene el código fuente del paquete.

idl Interfaces CORBA exportadas por los sirvientes que se implementan en cada uno de los paquetes.

debian Archivos necesarios para crear paquetes binarios en formato DEB.

man Páginas de manual.


El módulo gmodulo-shell además continene los siguientes de directorios:

Nota - Tenga en cuenta que, dado que Gmodulo se encuentra en pleno desarrollo, esta estructura puede variar. Consulte los archivos README presentes en cada uno de los módulos para obtener más información.

Creación de parchesLa forma mas fácil para crear parches es usando el servidor CVS. Antes de crear el parche, asegúrese de que tiene los últimos cambios realizados al código invocando:

# cvs -z3 update -Pd

Los parches pueden ser remitidos enviándolos a la lista de correo de Gmodulo o al repositorio de bugs en Sourceforge™ como un attachment, indicando en el asunto el problema que resuelve el parche.

Estilo de diffSiempre use diffs unificados mediante cvs -z3 diff -u, dado que estos son mas sencillos de leer, y consecuentemente, de aplicar a la rama de desarrollo.

docs Docuemntos generados durante la compilación. En concreto, contiene todo el API de programación del paquete.

TABLA 1-13 Estructura de directorios de gmodulo-shell


help Documentación de usuario, tutoriales y manuales en línea.

po Contiene las cadenas de internacionalización de la interfaz.

components Componentes empotrables en la shell de Gmodulo.

data Información de integración con GNOME.

TABLA 1-12 Estructura común de los paquetes de Gmodulo



Uso de pach y diffpatch/diff son unas maravillosas herramientas, no obstante, amenudo su uso puede resultar un poco complicado debido a informaciones confusas aportadas por terceros. A continuación se enumeran algunos consejos que demistifican su uso:

■ Si se está del todo inseguro, invocar pach primero con --dry-run. Esto simula invocar el comando, pero realmente no lo hace. Como consecuencia se pueden obtener estraños resultados sobre interdependencia de parches, pero aún asi es extremadamente útil.

■ Mayormente utilice patch -p0. Esta opción controla cómo deben interpretarse los nombres de los archivos del parche. El valor “0” indica que el nombre del archivo debe utilizarse sin modificación alguna encuanto al camino indicado en cada nombre de archivo.

■ Si se equivoca y tiene parte del parche aplicado, puede retornar al estado anterior eleminando los archivos e invocando cvs -z3 update. También puede volver a aplicar el parche con la opción “R”, para invertir el parche.

■ En algunas ocasiones, el uso de diff entre los módulos en los que muchos de los cambios son espacios en blanco, hace que el parche sea dificil de leer.La opción “-w” aplicada a diff (en el cvs) facilita su lectura.

Antes de enviarVerifique que el parche no va a producir ninguna clase de inestabilidad. Para ello, someta al parche a algún depurador de memoria y cerciónese de que este se acompaña de los correspondientes casos de prueba para verificar la integridad del mismo. La sección “Valgrind” en la página 39 describe uno de los mejores depuradores de memoria disponibles para GNU/Linux™ de caracter libre.

Valgrind

Valgrind es una herramienta de depuración que facilita la búsqueda de problemas de gestión de memoria en los programas. Cuando un programa se invoca bajo la supervisión de Valgrind, todas las operaciones de lectura y escritura de memoria son chequeadas, asi como las operaciones de adquisición de memoria dinámica mediante funciones el tipo malloc, new, free o delete.

Puede obtener más información acerca de esta herramienta en la dirección http://developer.kde.org/~sewardj/ y en el HOWTO sobre las misma.


CAPÍTULO 2

Proveedores. La estructura remota de Gmodulo

1Proveedores. La estructura remota de GmoduloEste capítulo describe las características específicas del módulo gmodulo-provider y su participación dentro de la arquitectura global de Gmodulo.

■ “Introducción” en la página 41■ “Mecanismos de comunicación distribuida entre procesos” en la página 43■ “Common Object Request Broker Architecture, corba” en la página 48■ “iiop: interoperatibilidad en corba” en la página 49■ “ORBit. corba para gnome” en la página 57■ “Objetos remotos con gnome” en la página 57■ “Gmodulo Provider: Una posible solución” en la página 60■ “Desarrollo de plugins para la arquitectura de Gmodulo Provider” en la página 70■ “Extension Beans Definition Language” en la página 72

IntroducciónGmodulo, mas allá de ser una aplicación que permita administrar un conjunto de módulos, constituye un marco de desarrollo para aplicaciones cliente-servidor que requieran acceder a objetos remotos, sin comprometer por ello la seguridad desde el punto de vista de la autentificación y el control de acceso.

Este capítulo constituye una breve introducción a los entresijos concretos de este marco de desarrollo en general y de Gmodulo en particular, siendo de gran interés para programadores o analistas con conocimientos en CORBA y patrones de software. Más información sobre estos temas en La sección “Gmodulo Provider: Una posible solución” en la página 60 y en La sección “Desarrollo de plugins para la arquitectura de Gmodulo Provider” en la página 70.

41

ObjetivoEste capítulo no pretende substituir a lo que comunmente se conoce como Documento de la Arquitectura del Software o SAD, sino complementarlo. El objetivo es presentar y justificar las decisiones que han condicionado el diseño de esta parte de la aplicación, pero sin entrar en los detalles de todas y cada una de las clases que lo conforman. Como se ha mencionado con anterioridad, esta información puede encontrarse en el Documento de la Arquitectura del Software.

El objetivo es responder al menos a las siquientes cuestiones:

■ Qué razones justifican la existencia de esta capa en la arquitectura de la Gmodulo.■ Cual es el alcance de CORBA dentro de la aplicación.■ Cómo se puede extender la funcionalidad de Gmodulo.

ÁmbitoEste capítulo forma parte del manual de referencia de Gmodulo. Los procesos aquí descritos se limitan exclusivamente al desarrollo de esta aplicación.

Referencias■ Refactoring: Improving the design of existing code.■ Analysis Patterns: Reusable Object Models.■ Design Patterns: Micro-architectures for Reusable Object-oriented Software.■ Patterns of Enterprise Application Architecture.■ AIX Version 4.3 Communications Programming Concepts.

ResumenGmodulo es una solución para la gestión distribuida de módulos. Más concretamente, Gmodulo Provider permite implementar sirvientes CORBA que requieran de autentificación de forma independiente al mecanismo utilizado para dicha tarea.

El reducido numero de librerías de las que depende esta parte de Gmodulo facilita que esté disponible como marco de trabajo en la mayor parte de sistemas UNIX™ que soporten básicamente ORBbit y Glib.

Gmodulo Provider se distribuye bajo la licencia GNU Lesser General Public License GNU LGPL.

42 octubre 2003

Mecanismos de comunicación distribuida entre procesosSe puede hablar de sistemas distribuidos, si es posible la comunicación entre procesos corriendo en diferentes espacios de direcciones, estando estos muy probablemente en diferentes máquinas. Es posible construir un sistema básico de comunicación mediante el uso de sockets, los cuales son lo suficientemente flexibles para establecer dicha comunicación. Sin embargo, su uso implica la necesidad de implementar un protocolo que permita el intercambio de información entre los procesos, siendo esto un obstaculo, al ser necesario su diseñ junto con los procesos que van a comunicarse entre si.

Esta necesidad técnica, unida al fuerte crecimiento de Internet, supuso un incremento dramático en el número de tecnologías disponibles para la comunicación entre procesos:

■ Remote Procedure Call, RPC.■ Java™ Remote Method Invocation, RMI.■ Simple Object Acess Protocol, SOAP.■ Common Object Request Architecture and Specification, CORBA.

Estos mecanismos facilitaban enormemente la aplicación de técnicas de procesamiento distribuido, las cuales permitían solventar un gran número de problemas.

Llamadas a procedimientos remotos, RPC

Se trata de uno de los protocolos de comunicación entre procesos más antiguos y conocidos de los que aún se siguen utilizando. Define un mecanismo por el cual, un proceso ejecutándose en un host invoca la ejecución de un fragmento de código en otro host sin necesidad de que el programador escriba código explícitamente para ello. define las principales características de este protocolo.

TABLA 2-1 Características del protocolo RPC

Concepto Descripción

Independencia del protocolo de transporte

El modo en que se pasan los mensajes entre los procesos no implica diferencia en las operaciones que RPC que se deben invocar. El protocolo sólo aborda cuestiones relacionadas con la especificación e interpretación de los mensajes.

Independencia semántica Esta viene especificada por el protocolo de transporte utilizado para realizar la comunicación via RPC.

Capítulo 2 • Proveedores. La estructura remota de Gmodulo 43

ProcedimientoEl protocolo RPC funciona de un modo similar al de una llamada a un procedimiento local. En el modo local, El cliente especifica una serie de argumentos a un procedimiento en una localización concreta, como un registro. Entonces, el cliente pasa el control de ejecución a la subrutina. Una vez ejecutada, se extrae el resultado del procedimiento y continua la ejecución del programa.

RPC funciona de un modo similar, salvo que el hilo de control se alterna, como es logico entre dos procesos, el cliente y el servidor:

■ El cliente envia un mensaje al servidor que incluye los parametros necesarios para invocar un procedimiento concreto en la máquina remota.

■ El cliente se mantiene a la espera de un mensaje de respuesta por parte del servidor.

■ Un proceso del servidor, que estaba dormido hasta la llegada del mensaje del cliente, extrae los parámetros del procedimiento del mensaje, realiza las operaciones pertinentes con ellos y envia el resultado en un mensaje de respuesta. El servidor se mantiene a la espera del siguiente mensaje del cliente.

■ Finalmente, un proceso del cliente recive el mensaje de respesta, extrae el resultado y el cliente continua la ejecución.

FIGURA 2-1 Procesamiento de una llamada en RPC

Autentificación y control de acceso

RPC sólo soporta autenticación. Si se desea controlar el acceso a servicios individuales, cada uno de estos deberá implementar su propia política de control de acceso y reflejar dicha política en los valores de estdo del protocolo devueltos al realizar la llamada.

TABLA 2-1 Características del protocolo RPC

Concepto Descripción

Client

RPC Runtime Library

Client Stub

Manager Procedures

Server Stub

RPC Runtime Library

Interface

Apparent Flow

call

return

call return

call return return call

return call

Networkmessages

Client process Server process

Remote ProcedureCall Flow

44 Mecanismos de comunicación distribuida entre procesos • octubre 2003

El protocolo RPC no hace restricción alguna acerca del modelo de concurrecia implementado, con lo que son posibles otros modelos diferentes al anteriormente expuesto. Es posible, por ejemplo, utilizar un modelo asíncrono de modo que el cliente pueda continuar trabajando mientras espera la respuesta del servidor.

A pesar del salto cualitativo que supuso su uso respecto al empleo directo de sockets, RPC presenta una serie de inconvenientes que no lo hace apropiado para las necesidades de Gmodulo:

Otro problema que presenta RPC, es la dificultad para adaptarse adecuadamente a sistemas distribuidos de objetos, en los que es necesaria la comunicación entre objetos a nivel de programa residiendo en diferentes zonas de memoria. Para facilitar la semántica propia de los lenguajes orientados a objetos, Se necesita un sistema de invocación remota de métodos, en los cuales, la responsabilidad de invocar se delega en un objeto local a dicha máquina, conocido como stub.

Java™ Remote Method Invocarion, RMI

Java™ RMI es un mecanismo que permite a una aplicación invocar métodos de un objeto que existen en otro espacio de direcciones. Este a su vez puede localizarse a su vez en la misma máquina o en otra remota. Este mecanismo es básicamente, equivalente al anteriormente descrito, RPC, con la salvedad de ser orientado a objetos.

Java™ RMI difiere de CORBA en un número de aspectos:

■ CORBA es independiente del lenguaje de programación.■ Incluye otros mecanismos en el estándard, que no se encuentran presentes en RMI.■ No existe un elemento semejante al object request broker en Java™ RMI.

ProcedimientoEl funcionamiento de RMI es como sigue:

El cliente Java™ comienza la invocación remota pidiendo al registro la localización de dicho objeto. Una vez que se tiene esta localización, RMI descarga un stub que puede

TABLA 2-2 Inconvenientes del protocolo RPC

Problema Descripción

Instanciación de procesos. RPC no aporta ningún control sobre el ciclo de vida del proceso remoto.

Independencia de plataforma. Uno de los principales inconvenientes de RPC es el número de variaciones y extensiones entre las implementaciones disponibles. El resultado es una amplia variedad de versiones diferentes e incompatibles del protocolo RPC.


usar para llamar a los métodos remotos del objeto. Esta característica es la que le diferencia del resto de mecanismos que utilizan esta aproximación y que requieren que el stub resida de forma local previamente a cualquier tipo de invocación remota. La figura “Vista general de la arquitectura rmi” en la página 46 muestra un esquema del funcionamiento de este mecanismo.

FIGURA 2-2 Vista general de la arquitectura RMI

En la imagen se aprecia la dependencia de RMI de un registro y de cómo se produce la comunicación cliente-servidor.

Lo que hace de este mecanismo interesante es que recientemente ha evolucionado para lograr un mayor grado de compatibilidad con CORBA. En concreto, existe una nueva clase de RMI conocida como RMI/IIOP que usa IIOP como protocolo de comunicaciones. Puede obtenerse más información acerca de RMI-IIOP en La sección “rmi-iiop” en la página 46 y sobre iiop en La sección “iiop: interoperatibilidad en corba” en la página 49.

RMI-IIOP

RMI/IIOP aporta la posibilidad de escribir aplicaciones CORBA para la plataforma Java™ sin necesidad de utilizar el lenguaje de definición de interfaces de CORBA, IDL. RMI-IIOP incluye toda la funcionalidad de un ORB con lo que es posible escribir aplicaciones Java™ compatibles con CORBA utilizando el API de RMI.

Sistemas remotos de invocación orientados a caracterEn los últimos años, el “boom” de internet y la expansión de los medios de red han permitido la aparición de mecanismos de comunicación distribuidos orientados a caracter. Estos se caracterizan por utilizar por utilizar normalmente infraestructura ya disponible, al utilizar HTTP como capa de transporte y utilizar los servidores web para proveer sus servicios. Dos son los protocolos de estas características que vamos a estudiar a continuación:

■ XML-RPC.

RMI Registry

Transport Layer

Remote Reference Layer

Client stub

Client application-level code

Transport Layer

Remote Reference Layer

Server(object) skeleton

Server objectsimplementation

TCP/IP Socket

Application Objectprogramming level

Remotingarchitecture level

Wire-protocollevel

Client Server

46 Mecanismos de comunicación distribuida entre procesos • octubre 2003

■ Simple Object Acess Protocol, SOAP.

XML-RPC

XML-RPC es una versión renovada del ya vetusto RPC. En este caso, se usa HTTP como medio de transporte y XML como herramienta para la codificación de los datos. XML-RPC fue diseñado para ser los mas simple posible, pero a la vez, con la capacidad necesaria para procesar y enviar estructuras de datos complejas.

Un mensaje XML-RPC se procesa como una petición POST en HTML. El cuerpo del mensaje está formado por un árbol XML. Cuando es recivido por el servidor, el cuerpo del mensaje es procesado por el procedimineto correspondiente y el valor de retorno es devuelto también como un árbol XML. Los parámetros del procedimiento pueden ser escalares, números, cadenas, fechas, etc, así como listas, estructuras o tuplas de datos.

La figura “Funcionamiento del protocolo xml-rpc” en la página 47 detalla el funcionamiento de este protocolo.

FIGURA 2-3 Funcionamiento del protocolo XML-RPC

Puede observarse que la simplicidad es el punto fuerte de este protocolo.

Simple Object Acess Protocol: SOAP

Apareció por primera vez en septiembre de 1999, como solución a la idea de crear un mecanismo que permitiese la comunicación en un entorno distribuido de sistemas mediante el intercambio de ́ rboles XML utilizando para ello un protocolo de transporte ampliamente difundido.

Aunque inicialmente se pensó en HTTP como medio de transporte, a diferencia de XML-RPC la especificación evolucionó para poder soportar otros protocolos.

XML-RPC encoding

XML-RPC decoding

Send to Server

Send to Client

Transport Layer

XML Remote Procedure CallFlow

Native Language Request

Native Language Request

XML-RPC encoding

XML-RPC decoding

Method dispatch

Server LayerClient Layer


Las ventajas más destacadas de este protocolo son:

■ Recolector automático de basura.■ Comunicación bidireccional.■ Objetos por referencia.■ Activación remota de objetos.

Puiede obtener mas nformación acerca de este protocolo en [Scribner, et al, 2000] y en la dirección http://www.w3.org/TR/SOAP/.

Common Object Request Broker Architecture, CORBALos lenguajes de programación modernos emplean en la actualidad el paradigma orientado a objetos para estructurar el procesamiento de información dentro de un único proceso, en un único sistema. El siguiente paso lógico consiste en distribuir este procesamiento en múltiples procesos en una e incluso en diferentes sistemas.

Dado que el paradigma orientado a objetos se adapta perfectamente al desarrollo y mantenimientos de grandes aplicaciones, parece pues razonable su aplicación para los entornos de proceso distribuido. CORBA facilita esta tarea, al permitir que objetos distribuidos en diferentes sistemas dentro de un entorno de red, puedan comunicarse entre ellos mediante el intercambio de mensajes.

Objetos en sistemas distribuidosEs un hecho que sistemas pertenecientes a un entorno de red difieran en arquitectura, hardware, sistema operativo, software y lenguajes de programación utilizados para implementar estos objetos. Es lo que se conoce como un entorno heterogeneo de red. Para permitir la comunicación entre objetos en semejante entorno, se necesita una capa de software que se encargue de abstraer dichas diferencias. A esta pieza de software se la conoce como middleware.

48 Common Object Request Broker Architecture, corba • octubre 2003

CORBA o mas extensamente, Common Object Request Broker Architecture es una especificación de dicha plataforma propuesta por Object Management Group o OMG. Los objetivos que trata de satisfacer son:

CORBA es un estándard abierto en el sentido de que cualquiera puede obtener la especificación e implementarla si lo desea. Además de sus características técnicas, esta es, probablemente, una de las más ventajosas frente a soluciones propietarias de otros vendedores.

IIOP: interoperatibilidad en CORBALa especificación sobre interoperatibilidad de CORBA define tanto el mecanismo por el cual los clientes establecen comunicación con un servidor, como los detalles acerca de la codificación de los datos y el formato de los mensajes.

En esta sección se tratan dos aspectos fundamentales sobre la especificación CORBA que deben ser comprendidos para establecer los criterios que deben aplicarse para garantizar la seguridad en Gmodulo:

■ IOR: Principal nexo de conexión entre clientes y servidores, tal y como se discute en La sección “Formato de las cadenas ior” en la página 50.

■ IIOP: Formato de los mensajes y codificación de los datos. La sección “Internet Inter-ORB Protocol, iiop” en la página 51 introduce las pesquisas básicas sobre el protocolo.

TABLA 2-3 Principales características de CORBA

Objetivo Descripción

Orientación a objetos Son los principales bloques de construcción de aplicaciones CORBA.

Independencia de localización Un cliente usa siempre los mismos mecanismos para invocar un método en un objeto remoto, independientemente de si este se encuentra localizado en el mismo espacio de direcciones, en el mismo host o en un host remoto.

Independencia de hardware, lenguaje o sistema operativo

Los objetos CORBA pueden ser implementados usando diferentes lenguajes de programación, diferentes tipos de hardware, o diferentes sistemas operativos.

Independencia del vendedor Versiones de CORBA implementadas por diferentes vendedores que se ajusten al estándard pueden interopertar entre si.


IIOP aporta un protocolo que permite a un cliente contactar con un servidor remoto así como llamar a métodos remotos en ese servidor. Es posible el intercambio de datos entre ambos en forma de parámetros, pero nada, a diferencia de lo que sucede en Java™ RMIes ejecutado en el lado del cliente.

Esta sección es un extracto del cápitulo tercero de la guía de administración del producto Orbix Wanderwall. Puede obtener más informació acerca del mismo en la página web del fabricante.

Formato de las cadenas IOR

Para identificar objetos en un entorno distribuido, CORBA utiliza el concepto de referencia a un objeto. Dicha referencia contiene toda la información necesaria para que una aplicación pueda establecer una comunicación remota con dicho objeto e invocar sus métodos.

Desde el punto de vista del programador, el concepto de referencia a un objeto es opaco. No obstante, como parte de la infraestructura del protocolo de interoperatibilidad, CORBA especifica un formato universal que pueda utilizarse para identificar estas referencias a objeto, de modo que esta pueda comunicarse directamente a los clientes. Este formato se conoce como Interoperable Object Reference o IOR.

La tabla “Campos de una cadena ior” en la página 50 muestra el formato de una cadena IOR usada para establecer la comunicación con un servidor mediante el protocolo TCP/IP:

La figura “Estructura de una cadena ior” en la página 51 muestra como estos campos se agrupan dentro de lo que se conoce como un perfil. El numero de perfiles viene determinado por un campo dentro de la cadena IOR.

TABLA 2-4 Campos de una cadena IOR

Sección Descripción

Tipo de objeto Equivale al nombre de la interfaz IDL usado para definir el objeto. En el caso de Gmodulo un identificador valido podría ser IDL:es.usal/Gmodulo/Shell/Component:1.0.

Nombre del host Nombre o dirección del host en que puede encontrarse el objeto. Por ejemplo, tejo.usal.es.

Puerto Número de puerto del servidor de dicho objeto.

Identificador Cadena de bytes que identifican una instancia concreta y que es usada por el servidor para localizar el objeto.

50 iiop: interoperatibilidad en corba • octubre 2003

FIGURA 2-4 Estructura de una cadena IOR

Significado de los bytes de una cadena IOR según las posición que ocupan en la misma.

La información conenida en un perfil es especifica a un protocolo de comunicación. El primer campo indentifica dicho protocolo, en este caso, se usa TCP/IP.

Representación de una cadena IOR

para facilitar la publicación de una cadena IOR, debe poderse convertir a un formato que no esté sujeto a ningún tipo de conversión. Por esta razón, CORBAespecifica un formato de cadena estándard para los IORs.

EJEMPLO 2-1 Ejemplo de cadena IOR

IOR:000000000000000d49444c3a677269643a312e300000000000000001000000000000004c0001000000000015756c7472612e6475626c696e2e696f6e612e696500000963000000283a5c756c7472612e6475626c696e2e696f6e612e69653a677269643a303a3a49523a67726964003a

Esta cadena consiste en una serie de números hexadecimales, precedidos de la cadena IOR:. Cada byte es convertido en dos dígitos hexadecimales. El principal incoveniente de este formato, es la dificultad para realizar su lectura, aunque existen herramientas que convierten esta información en algo más comprensible para el ser humano.

Internet Inter-ORB Protocol, IIOP

el protocolo IIOP es un caso especial del protocolo definido en la especificación General Inter-ORB Protocol o GIOP. En ella se define el marco necesario para la construcción de protocolos específicos para una capa de transporte. El protocolo IIOP es la especialización del protocolo GIOP sobre TCP/IP.

profile

“IDL:Account:1.0”

2

reserved

0

X.Y

“example.com”

1571

“George”

profile

Protocol

Version

Host

Port

Object key

Type Id

Profile Count


La tabla “Elementos de la especificación iiop” en la página 52 define los principales elementos de la especificación IIOP.

El último elemento de la especificación es el formato e los mensajes. La sección “Formato de los mensajes en iiop” en la página 52 describe con mayor detalle la estructura de los mismos.

Formato de los mensajes en IIOP

el protocolo IIOP define siete tipos de mensajes. Estos mensajes permiten a los clientes comunicarse con los servidores y recibir la correspondiente respuesta, que puede ser normal o comunicar un estado de error. También se definen mensajes que permiten gestionar la conexión.

Los dos tipos de mensajes mas importantes son los mensajes Request y Response. Las operaciones definidas en una interfaz IDL en un servidor son invocadas por el cliente mediante un mensaje Request. Salvo que el mensaje haya sido definido como asíncrono en la interfaz, el cliente se mantiene a la espera de la llegada de un mensaje Reply indicando el resultado de la operación.

Los mensajes IIOP pueden tener tres formatos diferentes:

■ Una cabecera GIOP.

■ Una cabecera IIOP seguida por una cabecera de mensaje específica para el tipo de mensaje.

■ Una cabecera IIOP seguida por una cabecera de mensaje y un cuerpo e mensaje específica para el tipo de mensaje.

La figura “Formato de un mensaje giop” en la página 53 ilustra el formato de una cabecera de un mensaje GIOP.

TABLA 2-5 Elementos de la especificación IIOP

Sección Descripción

Requisitos de gestión de la capa de transporte

Define la semántica de inicio y finalización de conexiones. En este nivel se define el papel desempeñado por los clientes y los servidores así como las funciones atribuidas a cada uno de ellos.

Formato de codificación de los tipos e datos

El segundo elemento de la especificación IIOP es lo que se conoce como Common Data Representation o CDR. Especifica la sintaxis de transferencia de todos los tipos de datos definidos en el estándard IDL, a un formato común compuesto por una serie de octetos.


FIGURA 2-5 Formato de un mensaje GIOP

Campos de un mensaje del protocolo GIOP interpretados según la implementación IIOP del mismo.

los campos de la cabecera pueden describirse como sigue:

Esto resume toda la información enviada en una cabecera de un mensaje GIOP. Para una especificación más formal, consulte la especificación CORBA.

Mensaje Request

Este tipo de mensajes permite a un cliente invocar una operación en un servidor remoto. El mensaje contiene toda la información necesaria para la invocación, incluyendo el identificador del objeto, el nombre de la operación y los parámetros asociados a la operación.

El mensaje consiste en una cabecera y un cuerpo. La figura “Composición de una cabecera Request” en la página 54 muestra la composición de la cabecera del mensaje. La tabla “Estructura de la cabecera de un mensaje giop” en la página 53 describe con mayor detalle cada uno de estos campos.

TABLA 2-6 Estructura de la cabecera de un mensaje GIOP

Campo Descripción

GIOP Permiten identificar el protocolo.

Major y Minor Indican el número de versión del protocolo GIOP utilizado para crear el mensaje.

Flags Este byte es utilizado para indicar el tipo de ordenamiento de bits utilizado.

Tipo de mensaje Entero utilizado para indicar el tipo de mensaje.

Tamaño de mensaje Tamaño del mensaje, excluyendo la propia cabecera GIOP.

Message Body

GIOP Header

Message Header

Message Size

GIOP

Major Version

Minor Version

Flags

Message Type


FIGURA 2-6 Composición de una cabecera Request

Además de la cabecera, el mensaje tiene asociado un cuerpo. Este se compone esencialmente de los parámetros de la operación, seguido por cualquier información de contexto asociado a la operación1.

TABLA 2-7 Cabecera de un mensaje Request para el protocolo GIOP

Campo Descripción

Service Context Permite especificar informcación de contexto para la petición. Normalmente, esta información se usa conjuntamente con los servicios CORBA, como por ejemplo, el servicio de transaciones.

Requesting Principal

GIOP header

Service Contexts

RequestId

Response Expected

Reserved

Object Key

Operation


Como puede comprobarse, en la aceptación de la petición, aunque aparezca el nombre del usuario que invoca el servicio, no se especifica ningún tipo de información que puda considerarse relevante para la autentificación y control de acceso, terminos muy a tener en cuenta para Gmodulo.

Esta responsabilidad recae en un protocolo de seguridad definido en el estándard, SAS que utiliza el campo Service Context para transmitir los elementos necesarios para la autentificación y delegación de servicios. Lamentablemente, ese servicio no se encuentra disponible en ninguna de las versiones disponibles de orbit.

Mensaje Reply

Este tipo de mensajes es enviado normalmente en respuesta a un mensaje de petición, Request, por parte de un cliente. El objetivo principal es el de devolverle el valor de retorno de la operación e indicar el resultado de la operación.

Esta cabecera no pasa tanta información como la vista anteriormente en el mensaje request. Consta de los siguientes campos:

1. Estas cadenas de contexto no están relacionadas con los contextos de los servicios o Service Context. Son parametros de las capas inferiores y sólo son pasadas si una sen-tencia de contexto aparece en la definición de una operación en el archivo IDL.

Id Identifica de forma unívoca una petición, de modo que el cliente posteriormente pueda asociarla con su correspondiente respuesta.

Response flag Indica si la petición es asíncrona o no.

Next field Reservad opara un uso futuro.

ObjectId Identificador utilizado que sera utilizado por el servidor para dirigir la operación al objeto adecuado.

Operation Cadena que identifica el nombre de la operación a invocar.

Request principal Nombre del usuario que realiza la petición.

TABLA 2-8 Cabecera de un mensaje Reply para el protocolo GIOP

Campo Descripción

Service Context Similar al caso anterior, permite especificar informcación de contexto para la petición. Normalmente, esta información se usa conjuntamente con los servicios CORBA.

TABLA 2-7 Cabecera de un mensaje Request para el protocolo GIOP

Campo Descripción


El campo de estado, Reply Status, permite diferenciar hasta cuatro valores diferentes, en función del resultado de la operación:

Otro tipo de mensajes de la especificación

Además de los dos mensajes vistos con anterioridad, GIOP define los siguientes tipos de mensajes:

Id Permite asociar la réplica con la petición. Este Id es único para cada cliente.

Reply Status Indica si se ha producido o no alguna condición en el servidor.

TABLA 2-9 Tipos de mensajes reply según el estado evuelto

Status Descripción

NO_EXCEPTION Corresponde con el caso normal. Indica que el mensaje ha sido procesado correctamente.

USER_EXCEPTION Indica que se ha producido una excepción en el servidor. Esta ha sido generada por el método invocado por el cliente.

SYSTEM_EXCEPTION Indica que se ha producido una excepción en el servidor. Esta ha sido generada por el sistema ante una condición extraña.

LOCATION_FORWARD Se trata de un caso especial, en la que se le indica al cliente que el servidor no aloja el objeto al que trata de acceder el cliente. El cuerpo del mensaje contiene una nueva cadena IOR con la localización del objeto. De este modo, el cliente pude resolver de forma trasparente a esta nueva localización.

TABLA 2-10 Tipos de mensajes del protocolo GIOP

Mensaje Descripción

CancelRequest Permite al cliente informar al servidor que ya no se esta interesado en la respuesta del mensaje. Se utiliza para optimización de los servidores, pues no se dconsidera un error el envio del mensaje de respuesta.

LocateRequest Permite averiguar si está disponible un objeto remoto.

TABLA 2-8 Cabecera de un mensaje Reply para el protocolo GIOP

Campo Descripción


ORBit. CORBA para GNOME

Objetos remotos con GNOMETal y como indican sus siglas, GNOME nació con el propósito de convertirse en un entorno de escritorio basado en componenetes distribuidos en un entorno de red. Aunque el primer objetivo se ha cumplido y GNOME dispone de un sistema de componentes basado en CORBA y GObject aún carece del soporte necesario para que dichos componentes puedan ser invocados desde equipos remotos.

LocateReply Se envia en respuesta a un cliente que previamente ah enviado un mensaje del tipo LocateRequest. Hay tres tipos:

■ UNKNOWN_OBJECT.■ OBJECT_HERE■ OBJECT_FORWARD

CloseConnection Enviado al cliente por el servidor para indicarle que intenta cerrar la conexión.

MessageConnection Puede ser enviado por cualquiera de los dos. Dentro el protocolo IIOP, indica que el último mensaje enviado estaba mal formado o era corrupto.

TABLA 2-10 Tipos de mensajes del protocolo GIOP

Mensaje Descripción


FIGURA 2-7 Vista general del escritorio GNOME

La idoneidad del sistema de componentes de GNOME estriba en su flexibilidad, al permitirnos implementar diferentes modelos de vida para los componentes y en su facilidad de uso, al integrar el ciclo de vida de un sirviente CORBA en el ciclo de vida de un objeto GObject. Esta librerií se conoce como Bonobo.

En la actualidad, la responsabilidad de crear y activar componentes implementados con el modelo de componentes Bonobo subyace en la librería Bonobo Activation, conocida anteriormente como OAF. La sección “Bonobo” en la página 59 y La sección “Bonobo Activation” en la página 59 describen con mayor detalle estas librerías.

MotivaciónA medida que crece una aplicación se incrementan los costes de desarrollo. La realización de tareas de mantenimiento adaptativo o perceptivo requieren mayores periodos de tiempo para su consecución.

Añadir complejidad a un aplicación es simple. Una vez que los proyectos inician este camino, la posibilidad de que volunaios participen en el desarrollo del mismo crece inexorablemente: el tiempo que requiere un porogramador para conocer y poder contribuir al proyecto se incrementa. Esto no es valido para un projecto como GNOME, compuesto por multitud de aplicaciones. Es por esto que, el principal factor de calidad del software a tener en cuenta y que debe respetarse para el desarrollo de cualquier aplicación es el de simplicidad, claridad y corrección del código.

El modelo de componentes de Bonobo, nación para paliar estos problemas. El software basado en componentes, ayuda a reducir la complejidad de las aplicaciones al reducir la cantidad de información que un programador necesita conocer acerca de un sistema. Esto se logra implementando una interfaz conocida para cada componente.

58 Objetos remotos con gnome • octubre 2003

BonoboBonobo constituye el marco de GNOME que permite escribir e implementar componentes reusables de software. Un componente, es una pieza de software diseñado para ser usado en cooperación con otros componentes mediante el uso de interfaces conocidas. En el universo Bonobo, CORBA es usado como el medio de comunicación que permite manter el diálogo entre los componentes.

Bonobo, tal y como es distribuido en GNOME, incluye un conjunto de interfaces CORBA y una implementación de las mismas mediante el uso de las librerís GNOME/GTK+. Esta implementación está diseñada para facilitar el uso de componentes en el desarrollo de aplicaciones GNOME/GTK+. El principio básico es ocultar en la medida de lo posible el uso de CORBA, de modo que el programador use valores por defecto para la mayor parte de sus acciones, sin preocuparse de los detalles de interacción de los componentes.

Bonobo ActivationBonobo Activation se diseño como remplazo a la librería libgnorba usada en las versiones de GNOME 1.0.x y 1.2.x para la activación de objetos CORBA. Básicamente, libgnorba permitía inspeccionar y activar los sirvientes CORBA disponibles en el equipo local, (se encontrasen estos en ejecución o no). También mantenía una lista con los sirvientes activos, de modo que si se preguntaba por uno que ya se encuentraba activo, no se iniciaba de nuevo, sino que se reutilizaba el que estuviese activo en ese momento.

Bonobo Activationañade soporte para las siguientes características:

■ Soporte para manejar el caso no local. Es necesario recordar que aún no ha sido implementada esta característica.

■ Integración con el servicio de nombres de CORBA sin necesidad de hacer uso del sistema X para ello.

■ Manejo de peticiones complejas, por ejemplo, petición de activación de componentes que implementen una determinada interfaz.

A pesar de que dispone del API necesario para la activación remota de componentes, Bonobo Activation carece de esta funcionalidad. Lo que se pretende es permitir la existencia de componentes que puedan ser activados de forma transparente desde otros equipos, asi como facilitar que esos componentes aparazcan cuando localmente se interrogue al sistema por los componentes instalados.

Una de las principales razones esgrimidas para el retraso en la implementación la constituyen la seguridad, y la gestión de las sesiones GNOME de forma distribuida. Puede encontrarse mas informació en el documento Gnome Enhacement Proposal 3: Support for remote activation in bonobo-activation GEP-3.


Gmodulo Provider: Una posible soluciónEl principal objetivo que Gmodulo se planteó resolver fue el de establecer una comunicación con uno o varios equipos remotos para realizar operaciones sobre ellos, en concreto, todas aquellas operaciones que puedan resultar de interés para el manejo de módulos, bien sean de uso exclusivo para el kernel de Linux™ o para RTLinux™.

Para establecer esta comunicación se pensó en el uso de un mecanismo independiente de plataforma, y en el desarrollo de una interfaz de usuario que permitiese interactuar con lsa máquinas remotas de un modo agradable para el usuario. Se eligió GNOME y CORBA para ello.

Lamentablemente y tal y como hemos podido comprobar en La sección “Objetos remotos con gnome” en la página 57, Gmodulo, por su naturaleza se encuentra ante el problema de activar diferentes sirvientes para un host remoto. Es por ello que la aplicación debe implementar un mecanismo que solucione esta dificultad, es decir, que permita realizar operaciones en equipos remotos, sin que por ello se vea comprometida la integridad de dichos sistemas.

La sección “Bonobo Activation” en la página 59, describe una de las principales causas por las que aún no ha sido implementada la activación remota de componentes: la autenticación del cliente. Para solventarlo, Gmodulo Provider implementa un

TABLA 2-11 Requisitos de diseño satisfechos por Gmodulo Provider

Requisito Descripción

CORBA Es el mecanismo de comunicación que debe utilizarse para establecer el intercambio de información entre el cliente y el servidor.

Comunicación segura Es necesario disponer de los mecanismos que permitan garantizar la confidencialidad y la seguridad de las comunicaciones entre los sistemas. En concreto, Gmodulo Provider debe dar solución a dos necesidades básicas no cubiertas al menos totalemente por la implmentación de CORBA de la que se va a hacer uso:

■ Autenticación.

■ Control de acceso.

Disponibilidad y flexibilidad de la configuración

Debe corresponder al administrador establecer el grado de disponibilidad de Gmodulo Provider, no estando las decisiones tomadas por este, condicionadas por aspectos de diseño.

60 Gmodulo Provider: Una posible solución • octubre 2003

mecanismo que permite al proveedor especificar el nivel de seguridad necesario para que el cliente pudeda operar sobre un sirviente.

FIGURA 2-8 Vista general de la arquitectura de Gmodulo Provider

Dado que el uso de ORBit era una condición impuesta para la realización de la solución, la discusión de cómo implementar la funcionalidad remota pasa, sobre todo, por determinar primero los riesgos asociados con las carencias o virtudes de CORBA en general y ORBit en particular. En cualquier caso y para esclarecer cualquier tipo de controversia acerca de este asunto, se ha realizado un ´nalisis en la sección de las diferentes opciones a CORBA disponibles para implementar la aplicación, sus ventajas e inconvenientes.

Concepto de ProveedorUn proveedor no es mas que la implementación de un objeto software que permite que equipos remotos puedan acceder a una serie de operaciones1 de un objeto, conocer su estado, y en definitiva, interactuar con el objeto así definido. Esta funcionalidad que podemos considerar básica, puede extenderse aplicando el patrón Observer [Gamma, et al, 1994] de modo que el proveedor pueda notificar a los clientes, (observadores), de los cambios que se produzcan en su estado.

Gmodulo define una serie de proveedores que permiten interactuar con los módulos del sistema, realizar busquedas dentro del sistema de archivos de candidatos a comportarse como módulos, etc. Está previsto que futuras versiones permitan realizar operaciones tales como compilar e instalar nuevas versiones de módulos o notificar de cambios en el estado de estos, por ejemplo.

1. En la terminología de uso en el paradigma orientado a objetos, POO, es más habitual des-cribir las operaciones o funciones como métodos.

Gmodulo Provider

PluginsServidor de Referencias

Peticiones Locales Peticiones Remotas iModule iSearch

Servicios Principales

Seguridad EBDL


Seguridad de las comunicacionesLa seguridad constituye algo extremadamente importante en cualquier sistema distribuido. El mero hecho de que las aplicaciones sean accesibles desde la red, las hace vulnerables a todo tipo de ataques, vengan estos desde dentro o desde fuera del entorno.

El uso de Object Request Brokers (ORB) facilita el desarrollo de objetos distribuidos, siendo estos accesibles desde otro proceso o desde otro sistema. Afortunadamente, CORBA define junto a los protocolos de comunicaciones entre los objetos, un modelo de seguridad cuya implementación puede hacer de nuestras aplicaciones más seguras a la hora de acceder desde cualquier punto.La tabla “Mecanismos de seguridad disponibles en corba” en la página 62 recoge una breve descripción de los mismos1.

Desafortunadamente, Gmodulo no puede hacer uso ni de una canal seguro2 que garantice la confidencialidad de la información transmitida a través de la red, ni del mecanismo descrito anteriormente, dado que la implementación elegida como ORB no

TABLA 2-12 Mecanismos de seguridad disponibles en CORBA

Requisito Descripción

CSIv2 La arquitectura Common Secure Interoperability Specification, Version 2 aporta tres elementos básicos para una comunicación segura entre objetos distribuidos:

■ Integridad y Confidencialidad.■ Autenticación cliente-servidor.■ Delegación de privilegios.

CSIv2 se diseñó para su uso en entornos que dispusieran de seguridad en la capa de transporte, como la disponible con el uso de sockets seguros o SSL, por ejemplo. Para intercambiar la información necesaria para su funcionamiento, CSIv2 hace uso del service context de las cabeceras de mensajes Request y Reply de GIOP.

ATLAS Esta especificación describe el mecanismo de funcionamiento que debe comandar un servicio que permita el intercambio de tokens de autorización entre los servicios de seguridad que pudieran estar disponibles tanto en un cliente, CSS como en un servidor, TSS. La interfaz descrita con esta especificación permite implementar dicho mecanismo, que ha de hacer uso de la arquitectura ocolo anteriormente descrito, CSIv2.

1. Consulte La sección “ORBit. corba para gnome” en la página 57 o las especificación en la pagina web de OMG para obtener más información acerca de CSIV2.

2. ORBit2 permite hacer uso de sockets seguros para la transmisión de los mensajes del protocolo IIOP, no obstante, por motivos de licencia, esta opción no está disponi-ble por defecto.


ha implementado aún este servicio. Podemos adelantar que este supuesto afecta al diseño de la solución pues conlleva una serie de restricciones que condicionan el modo de invocación y el modelo de vida de los componentes.

Localización e instanciación proveedoresComo se mencionó en La sección “Concepto de Proveedor” en la página 61 Gmodulo hace uso de una serie de objetos, proveedores, a los cuales invoca para para poder llevar a cabo tareas administrativas sobre los módulos presentes en los host, tanto locales como remotos. Un problema común es el hecho de la localización de la referencia concreta del objeto que permite a la aplicación llevar a cabo una operación concreta en un host determinado. Para ello CORBA define un servicio conocido como CosNaming Service o Servicio de Nombres, que permite localizar referencias a objetos en aquellos host en los que dicho servicio se encuentre activo..

Servicio de NombresEste servicio proporciona el principal mecanismo para que los clientes puedan encontrar objetos en un entorno de ORBs. El Servicio de Nombres aporta un contexto inicial que actúa como raíz para todos los nombres. Este contexto, permite asociar un nombre a un objeto, de modo que resulta sencillo que los clientes puedan navegar a través del espacio de nombres para localizar un objeto determinado.

El servicio de nombres evolucionó, dando lugar en la especificación CORBA 2.4 a el Interoperable Naming Service. Este nuevo servicio, envolvió la especificación anterior y resolvió algunas de las dificultades mencionadas con anterioridad, añadiendo además las siguientes características:

■ Capacidad para resolver cadenas de nombres.■ Resolver URLs para referencias a objetos, (corbaloc: y corbaname:).■ argumentos de inicialización del ORB (Bootstrapping).

TABLA 2-13 Inconvenientes del Servicio de Nombres de CORBA

Inconveniente Descripción

Resolución de la referencia inicial

El servicio de nombres no especifica claramente el método a seguir para resolver la primera referencia al servicio de nombres. En consecuencia, el mecanismo a seguir depende del vendedor, quien se encarga de decidir el proceso para resolver esta referencia al servicio. Este problema se acentúa cuando es necesario acceder a un servicio de nombres remoto.


Desafortunadamente, ORBIT no implementa esta nueva especificación y la implementada, se encuentra deshabilitada por defecto, en favor de los servicios aportados por OAF.

Object Activating Framework, OAF

OAF se diseño como un substituto de la librerí libgnorba usada en GNOME. libgnorba es la librería responsable en GNOME 1.0.x y 1.2.x de la activación de objetos en el servidor.libgnorba también permitía buscar los sirvientes disponibles en el sistema local, estuviesen estos activos o no. En el caso de encontrarse activos, si un cliente peguntaba por un sirviente, libgnorba proporcionaba la referencia de este, no siendo necesaria la activación de nuevo.

OAF añade además las siguientes características:

■ libgnorba solo permite buscar sirvientes por el nombre completo: No es posible preguntar por un sirviente que implemente un servicio determinado. Sólo es posible por un sirviente conocido que provee el servicio deseado.

■ OAF mantiene un registro de todos los sirvientes CORBA instalados en el sistema local, y está preparado par que en futuras versiones, sea posible realizar consultas tambien en sistemas remotos.

Una de las principales razones que justifican el diseño actual de OAF es la carencia de implementación del servicio de seguridad de CORBA. Una discusión sobre la carencia de soporte para la activación remota de componentes puede encontrarse en la propuesta GEP-3. En la actualidad, esta librerí se ha integrado en el sistema de componentes Bonobo.

TABLA 2-14 Inconvenientes de Object Activation Framework, OAF

Inconveniente Descripción

Demonio de usuario La instanciación de OAF se realiza a nivel de usuario. En consecuencia, cualquier componente que se active con la mediación de OAF puede no ejecutarse con los permisos adecuados. Esto conlleva problemas de interoperatibilidad si la ejecución de un sirviente requiere mayores privilegios de los que posee en la actualidad el usuario.

Sin soporte remoto Aunque presente en la documentación, lo cierto es que no es posible hacer uso de componentes remotos mediante bonobo o CORBA. Al carecer de soporte de red, no es posible especificar un puerto al que puedan llegar peticiones de otros sistemas sobre la presencia de un componente con una funcionalidad concreta.


Instanciación de proveedoresUno de los problemas comunes a las dos soluciones propuestas con anterioridad es la imposiblidad para poder hacer uso de objetos en uno o varios host remotos. En el caso del Servicio de Nombres, los clientes deben iniciar internamente el ORB con la referencia que determine dónde se encuentra el servicio, y como se mencionó con anterioridad en La sección “Servicio de Nombres” en la página 63, ORBit no dispone de soporte para ello. Tampoco OAF es al solución debido a que sólo permite realizar esta operación localemente.

Teniendo en cuenta estas dificultades, se optó finalmente por la implementación de un mecanismo que diera solución a los dos grandes problemas que impedín la consecución del proyecto:

■ Habilitar la instanciación y localización de sirvientes en hosts remotos.

■ Implementar un mecanismo de seguridad que permita que los sirvientes puedan restringir su funcionalidad según el cliente que haga uso de sus servicios.

Este mecanismo se conoce como Gmodulo Provider Daemon o GPD. Se trata de un demonio de acceso público encargado de atender las peticiones de servicio realizadas por cualquier cliente, resolviendo qué proveedor debe ser activado para satisfacer la petición o peticiones del cliente. La tabla “Caracteristicas principales de Gmodulo Provider Daemon” en la página 65 describe con mayor detalles las características de este demonio.

TABLA 2-15 Caracteristicas principales de Gmodulo Provider Daemon

Característica Descripción

Activación remota GPD puede, en respuesta a la petición de un cliente remoto, activar localmente objetos del mismo modo en que lo hace OAF.

Servidor de referencias, IORs En respuesta a una peticion remota, GPD devuelve una referencia al objeto activado en respuesta a la petición. Para servir la referencia, no es necesario que el objeto haya sido activado y existe la posibilidad de que, en función de la política utilizada por el proveedor, sólo se devuelva una referencia al objeto creada a tal efecto.

Autentificación y control de acceso

Si el proveedor requiere que el cliente se autentique previamente a que el demonio sirva una referencia al objeto, este se encargará de generar un token de acuerdo al nivel de seguridad exigido por el proveedor. La autenticación propiamente dicha se delega en el proveedor.


GPD hace uso de dos repositorios diferentes:

■ Cache de referencias

Inicialmente vacio, este almacén alberga referencias de instancias de proveedores para ser servidas en el momento que se necesiten. Esto es posible dado el carácter opaco atribuido a los objetos en CORBA. Dado que, la política utilizada para los proveedores de Gmodulo implica que el objeto sólo sea creado en el momento en que se invoca la acción1 no hay consumo de recursos por el mero hecho de almanenar referencias a objeto en un almacén.

■ Archivo de Registro de Proveedores

Este almacén se abordará con mayor detalle en La sección “Registro de proveedores” en la página 68.

La figura “Vista de despliegue de gpd y Gmodulo Provider” en la página 66 muestra con mayor detalle la arquitectura de la solución propuesta para la implementación de GPD. En ella pueden verse estos dos repositorios y cual es la relación de estos con el resto de GPD.

FIGURA 2-9 Vista de despliegue de GPD y Gmodulo Provider

Cache de proveedores Cada vez que un cliente realiza una petición, GPD se encarga de generar nuevas referencias y almacenarlas en un repositorio interno con sus correspondientes tokens de seguridad, de modo que se agilice el proceso para el siguiente cliente.

Soporte para Transient Objects GPD, puede ser utilizado, a diferencia de las otras opciones disponibles, para registrar y activar proveedores de vida útil corta, esto es, aquellos que definan una modelo de vida del tipoUSE_SERVANT_MANAGER y NO_RETAIN.

1. La sección “Desarrollo de plugins para la arquitectura de Gmodulo Provider” en la página 70 describe con mayor el modelo de vida seguido por los proveedores y las razones que llevaron a elegirla.

TABLA 2-15 Caracteristicas principales de Gmodulo Provider Daemon

Característica Descripción

ARPIOR’s Cache

Gmodulo ProviderDaemon

Cliente

XMLRequest

IORs

Plugins

Cliente Host Remoto


Puede observarse en la ilustración la relación de ambos repositorios con GPD y la dependencia de GPD de un entorno de red para su funcionamiento.

La secuencia que describe la obtención de una referencia por parte de un cliente, servida por GPD es como sigue:

1. El cliente envia a GPD una petición para obtener las referencias necesarias para poder operar sobre uno o varios objetos en el servidor.

2. GPDcomprueba en el ARP los requisitos de seguridad que el cliente debe superar para poder hacer uso de estas referencias.

3. Si el proveedor requiere que el cliente se autentique previamente a que el demonio sirva una referencia al objeto, el demonio se encarga de generar un token deacuerdo al nivel de seguridad exigido por el proveedor.

4. GPD sirve al cliente la referencia IOR a los objetos CORBA solicitados junto a, opcionalmente, la fecha en que las referencias expiran y los tokens para autenticar al cliente.

De esto se deduce que la autenticación se delega en el proveedor, llevándose esta a cabo en el momento en que el cliente invoca un método en el proveedor. Esto permite tener un control muy fino sobre qué métodos de un mismo proveedor puede invocar un cliente.

FIGURA 2-10 Instanciacion de Proveedores

Diagrama de secuencia de Gmodulo Provider. Instanciación de proveedores.

Es resumen, GPD es la solución propuesta por Gmodulo para poder activar objetos CORBA que, gracias a la cache que implementa, puede ser usado para la localización y activación de objetos, tanto de forma remota como local.

HTTP Server

XML Request

POACache

[ If Not IORs ] GetPOA

POA MAnager

GetIORs

IORs

POA Reference

IORs

Create IOR reference

Create

IORs

Store

XML Response

GetIORs

IORs


Registro de proveedoresComo se mencionó en La sección “Instanciación de proveedores” en la página 65 GPD hace uso de un almacén persistente para obtener la información necesaria para localizar y crear instancias de objetos CORBA.

La primera vez que se inicia el demonio, GPD busca en una ubicación conocida los archivos de registro de proveedoress1 (ARP) que describen los atributos característicos de cada uno de los proveedores disponibles:

■ Localización de las librerías.■ Interfaces implementadas.■ Mecanismo de seguridad.■ Adaptador y modelo de vida del proveedor (POA).■ Política de seguridad en el demonio.■ Numero de referencias IOR en la cache de GPD.

Localizado el archivo, se procederá a la verificación de la información que contiene. Hecho esto, el último paso consiste en crear las referencias especificadas en el ARP y almacenar dichas referencias en la cache de GPD.

FIGURA 2-11 Registro de Proveedores

Diagrama de secuencia de Gmodulo Provider: Registro de proveedores.

La sección “Desarrollo de plugins para la arquitectura de Gmodulo Provider” en la página 70 describe los diferentes requisitos que deben satisfacer los plugins de Gmodulo Provider y cómo estos requisitos influyen en su comportamiento y en el contenido del archivo ARP que debe acompañarles.

1. La sección “Archivo de registro de proveedores (arp)” en la página 69 describe los atributos disponibles y su mecanismo de funcionamiento.

GConf PluginsARPGPD

GetPluginsLocatePath

Path

Create

InitPlugin

CheckARP

[If Not Present ] RegisterProviders

GetARPLocation

Path

GetProviders

Providers

POAsCreateRequiredPOAs

CreateIORs

Cache

IORs

Create


Archivo de registro de proveedores (ARP)

Servicio de notificaciónCierto tipo de proveedores, cuya vida útil es muy corta, (en concreto aquellos cuyo periodo de vida expira tras invocar un método del objeto) pueden beneficiarse del sistema de publicación de eventos que provee Gmodulo Provider. Este sistema se basa en el concepto de monitor.

Un monitor es un plugin de proveedor que permite, bajo petición de un cliente, vigilar diferentes aspectos del sistema. Cada vez que se produzca un cambio en un parámetro, el monitor enviará un mensaje a todos aquellos clientes que hayan solicitado ser informados de cambios en ese paráametro1 concreto.

FIGURA 2-12 Servicio de Notificación de Gmodulo Provider

Utilizando este diseño, los clientes de Gmodulo Provider son informados de cualquier cambio que otro cliente u otra aplicación realice sobre la información monitorizada, como podría ser los módulos cargados en el kernel.

Obviamente, el funcionamiento es una adaptación del patrón de software Observer [Gamma, et al, 1994]. Consulte el Documento de Arquitectura del Software para ver con mayor detalle el modelo de clases que describe este servicio.

Comportamiento de los proveedoresEl comportamiento de los proveedores viene definido por el Portable Object Adapter (POA) utilizado. En la actualidad, Gmodulo Provider permite definir hasta cinco modelos de vida de los objetos CORBA definidos en un plugin de proveedor:

1. En realidad, los eventos concretos a los que se subscribe un cliente son especificados en tiempo de ejecución por los proveedores.

Monitor

FamMonitorPollMonitor

iSubject

Client

iObserver


■ Activación explícita de objetos.■ Sirviente único para todos los objetos del mismo tipo.■ Sirviente único para todos los objetos de diferente tipo.■ Activación bajo demanda para un único método.■ >Activación bajo demanda para múltiples métodos.

Esta información se encuentra definida en el atributo POAModel del archivo de registro de proveedores que acompaña al plugin. Para mas información acerca de las diferentes políticas disponibles consultar La sección “Modelo de vida de los objetos” en la página 71.

Desarrollo de plugins para la arquitectura de Gmodulo ProviderHemos podido comprobar en La sección “Comportamiento de los proveedores” en la página 69 que es posible controlar el modelo de vida de los proveedores mediante la elección de un POA adecuado. Dos son los principales aspectos que hay que tener en cuenta a la hora de implementar los plugins de proveedor:

■ Concurrencia.■ Vida del objeto.

Como se ha mencionado con anterioridad, Gmodulo Provider permite elegir diferentes “patrones”1 POA. La elección del POA adecuado dependerá principalmente de la necesidad que tratan de resolver, y del diseño del plugin de proveedor elegido para solventarla.

ConcurrenciaAunque Gmodulo Provider permite definir proveedores con una política multihebra, la realidad es que el ORB escogido para la implementación,ORBit, no soporta este tipo de aplicaciones. En consecuencia, el POA escogido para su implementación es de una única hebra.

1. En [Siegel, 2000] se considera que los modelos de POA utilizados para instanciar obje-tos en COBA responden a cuatro patrones, uno de los cuales cuenta con un par de variantes.

70 Desarrollo de plugins para la arquitectura de Gmodulo Provider • octubre 2003

Modelo de vida de los objetosEntre los diferentes modelos de uso de POA soportados por Gmodulo Provider nos encontramos con dos modelos de vida bien diferenciados:

La sección “Activación bajo demanda (Transient Objects)” en la página 71 describe con mayor detalle el modelo utilizado por los plugins de proveedor desarrollados hasta el momento.

Activación bajo demanda (Transient Objects)Este tipo de objetos se caracteriza por no tener estado, es decir, sólo existen en memoria en el momento en que se activa el objeto mediante la invocación de uno de sus métodos:

■ El sirviente es el encargado de mantener el estado de un objeto en memoria.

■ El objeto se crea en el momento en que el cliente invoca un método.

■ La creación y activación no es llevado a cabo por el POA. El POA delega esta responsabilidad en un códico especificamente creado para tal efecto por el programador.

La pólitica de uso de POA garantiza que sólo un cliente podrá acceder a la ejecución de un método al mismo tiempo y que la creación y activación del objeto sólo se produce en el momento que se invoque un método del objeto.

TABLA 2-16 Modelos de vida de interés para Gmodulo Provider

Modelo de vida Descripción

Persistente Entendiendo como tal, aquellas en las que el tiempo de vida del objeto es controlada por el cliente o es superior a la invocación de un método. En estos casos es el POA encargado de la activación de los sirvientes.

Etérea (Transient) El periodo de vida del objeto se limita a la invocación de un método del objeto. En este caso la activación se produce bajo demanda.


FIGURA 2-13 Activación bajo demanda Gmodulo Provider

Diagrama de secuencia de Gmodulo Provider. Notificación de eventos cliente.

Este patrón constituye una de las mejores posibilidades para la implementación de los plugins de proveedores, por el hecho de que permite crear referencias a objetos sin consumir recursos por ello. Esto permite almacenar las referencias en repositorios o caches, tanto en los clientes como en los servidores, para su posterior uso.

Extension Beans Definition Language

POA

Object Request

Object Request

Servant LocatorPreinvoke ()

PostInvoke ()

Operation ()

Preinvoke ()

PostInvoke ()

Operation ()

Servant

Servant

72 Extension Beans Definition Language • octubre 2003

Glosario

1Glosarioadministrador Persona encargada del mantenimiento de un sistema. Entre sus tareas se

incluyen la instalación de aplicaciones, el mantenimiento de cuentas de usuario y el control de acceso. Este papel puede ser desempeñado varias personas.

archivos fuente Contienen una serie de subrutinas que definen el flujo de un programa. Escritos en un lenguaje de programación, una vez compilados, dan lugar a lo que conocemos como aplicaciones software.

argumentos Información que facilitamos a una aplicación al inicio de su ejecución a través de la línea de comandos. También puede entenderse como tales al conjunto de parámetros que pueden pasarse a un método o subruitina.

autoconf Herramienta desarrollada por la FSF que permite la gestión automática de archivos de configuración. Permite usar una serie de scripts portables que, en combinación con archivos Makefile permiten construir, instalar y distribuir aplicaciones software de acuerdo a los propuesto por [FSF, 2003].

automake Herramienta desarrollada por la FSF que permite la generación de archivos Makefile a partir de unas plantillas creadas por el programador. Junto con la herramienta autoconf, permiten construir, instalar y distribuir aplicaciones software de acuerdo a los propuesto por [FSF, 2003].

Bonobo Inspirado en la tecnología OLE de Microsoft™ e implementado en Gtk, Bonobo constituye la arquitectura de componentes basada en el estándard CORBA para el projecto GNOME.

bugs Literalmente traducido al español como “bichos”, representa un fallo en la programación de una aplicación y manifestado de algún modo al usuario. El uso de este termino se debe a razones históricas.

capa de transporte Atendiendo a la definición dada por el OSI de la ISO constituye un canal de comunicación libre de fallos entre un emisor o cliente y un receptor o

73

servidor. Un ejemplo de protocolo de capa de transporte, es el conocido TCP usado en Internet.

cliente Sistema o aplicación que depende de una serie de servicios para poder operar. Estos servicios son aportados normalmente por otra máquina o aplicación que no tiene porqué estar ubicada físicamente en el mismo lugar que el cliente.

Persona que encarga la construcción de una aplicación software.

cliente-servidor Modelo de arquitectura aparecida a principios de los años ochenta, en la que varios clientes hacen uso de los servicios disponibles en un servidor. Se trataba de una arquitectura centralizada con un ordenador central con una gran potencia de cálculo, el servidor y una serie de equipos más ligeros que eran los clientes. Esta arquitectura a dado paso a otras descentralizadas y de procesamiento distribuido. Hoy en día se suele utilizar el término para definir cualquiera de estos dos modelos de arquitectura.

consola Define coloquialmente al terminal de entrada de datos cuando no se hace uso del modo gráfico.

demonio Programa que se encuentra activo con carácter indefinido. Suele iniciarse al encender el equipo, aunque es posible que sea lanzado por un usuario en un momento dado.

DocBook Definido por OASIS, se trata de un DTD que define un lenguaje de marcas para la realización de textos técnicos. Permite especificar las semántica del documento, sin entrar en los detalles de la representación del mismo.

dpkg Gestor de paquetes utilizado en el proyecto Debian para compilar, instalar verificar y actualizar paquetes de software individuales.

hardware Concepto utilizado para describir el conjunto de partes físicas que forman parte de un ordenador.

html Lenguaje de marcas definido por el consorcio W3 para la creación de páginas web. Actualmente, este lenguaje ha sido substituido por otro que permite crear documentos validos a la recomendación XML: XHTML.

Internet También conocido como la “Red de Redes”, Internet es un conjunto de redes heterogeneas que hacen uso de la tupla de protocolos TCP/IP y que interconecta multitud de redes en todo el mundo.

74 octubre 2003

Bibliografía

1Bibliografía[Booch, 1993] Grady Booch. Object-oriented Analysis and Design with Applications .

Benjamin Cummings, 1993.

Cubre los aspectos fundamentales del paradigma orientado a objetos, adentrándose en los procesos de desarrollo de sistemas en este paradigma, notación, herramientas y lenguajes OO.

[LSB, 2003] Free Standards Group. Linux Standard Base Specification 1.3. Free Standards Group, 2003.

Define un conjunto de normas que permiten especificar una interfaz de sistema disponible para las aplicaciones, así como un conjunto de mínimos que den soporte a scripts de instalación. El objetivo es el desarrollo de un entorno uniforme que permita el desarrollo de aplicaciones estándard.

[FSF, 2003] Richard Stallman. GNU Coding Standards. Free Software Foundation, 2003.

Describe los procesos usados para el desarrollo del sistema GNU, y constituye una guía de programación para el desarrollo de aplicaciones robustas y portables.

[Gamma, et al, 1994] Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides. Design Patterns: elements of reusable object-oriented software. Addison-Wesley, 1994.

Introducción a los patrones de diseño. Muestra, el papel que los patrones pueden desempeñar en el diseño de la arquitectura de sistemas complejos. Esta introducción se acompaña con una colección de patrones.

75

[Siegel, 2000] Jon Siegel. CORBA 3:Fundamentals and programming, second edition. John Wiley & Sons, Inc, 2000.

Vista general de la especificación CORBA 3.0 y de la programación distribuida.

[Scribner, et al, 2000] Kennard Scribner y Mark C. Stiver. Understanding SOAP. Sams Publishing, 2000.

Introducción al protocolo de comunicación SOAP, comparándolo con las tecnologías disponibles, y guía al lector en la implementación del mismo.

76 octubre 2003

Índex

Aadministrador, 73archivos fuente, 73argumentos, 73arquitectura

planificación, 21autoconf, 73automake, 73

BBonobo, 73bonobo, 59bonobo activation, 59bugs, 73

Ccapa de transporte, 73cliente, 74cliente-servidor, 74código fuente, 15

versiónes, 15compilación

cómo, 20herramientas, 19

comunicació distribuida, 43comunicación distribuida

protocolos orientados a caracter, 46SOAP, 47XML-RPC, 47

configuración

compilaciónconfigure, 22gmodulo-provider, 22

consola, 74CORBA, 48

características, 48IIOP, 51IOR, 50

CosNaming Service, 63

Ddemonio, 74DocBook, 74dpkg, 74

EEBDL, 72estilo

guía, 28archivos .C, 35archivos de cabecera, 34declaración de funciones, 32declaración de variables, 33espaciado y tabulación, 31estructura de directorios, 37, 38estructura de los archivos fuente, 33nombres, 28nombres de archivo, 29nombres de clase, 29nombres de funciones estáticas, 30

77

nombres de funciones externas, 30nombres de macros y constantes, 30organización del código, 30política de llaves, 31política de paréntesis, 32

Ffuentes

desarrollo, 18versiones

apt, 16cvs, 17

GGmodulo

arquitecturailustración, 12

compilación, 19gnu

manejo de paquetes, 19guía de programación

ámbito, 10arquitectura, 10

inroducción, 11compilación

configure gmodulo-monkey, 23configure gmodulo-shell, 23configure gtk-doc, 23

dependencias, 13gtk-doc, 14pkg-config, 15

fuentescvs login, 17

inroducción, 9instalación

nombres de structs y enums, 30objectivo, 9referencias, 10resumen, 10

Hhacking, 26

documentación, 26documentación de desarrollo, 28

manual de desarrollo, 28manual de programación, 28

parches, 38consejos de uso, 39diff, 38envio, 39

hardware, 74html, 74

IIIOP, 49, 51

formato de mensajes, 52Cancel Request, 56Close Connection, 56Locate Reply, 56Locate Request, 56Message Connection, 56Reply, 55Request, 53

instalación, 24configuración del entorno

GPD, 26gpd.passwd, 26puerto, 25

paquetes compilados, 25prerequisitos, 24

Internet, 74IOR, 50

estructura, 50formato, 51

Llibgnorba, 64

OOAF, 64Object Activating Framework, 64ORBit, 57

78 octubre 2003

Ppaquetes compilados

instalaci´n, 25proveedores

ámbito, 42comportamiento

POA, 69concurrencia, 70inroducción, 41instanciación, 65localización, 63modelo de vida, 71

transient objects, 71notificación, 69

ilustración, 69objectivo, 42POA, 71referencias, 42registro, 68

ARP, 69resumen, 42

provider, 60arquitectura, 61, 70definición, 61plugins, 70requisitos, 60seguridad, 62

Rremoting, 57

motivación, 58bonobo, 59

RMI, 45interoperatibilidad, 46procedimiento, 45

RPC, 43características, 43conclusiones, 45procedimientos, 44

SServicio de Nombres, 63SOAP, 47

Ttransient objects, 71

Vvalgrind, 39

XXML-RPC, 47

Índice 79

80 octubre 2003

Manual de Programación de...

Documents

Transcript of Manual de Programación de...