Curso CORBA: Lenguaje OMG/IDL
En esta nueva entrega del curso vamos a describir como se afronta la solucin a un problema utilizando una perspectiva orientada hacia CORBA.
Para ello vamos a describir las fases de anlis y diseo de una aplicacin, la cual utilizaremos como ejemplo a lo largo del curso.
Posteriormente y a partir del diseo veremos que reflejar este diseo dentro de CORBA utilizando el lenguaje OMG/IDL. Para poder este lenguaje por completo utilizaremos el compilador de OMG/IDL a Java de una herramienta de libre distribucin conocida como JavaORB, la cual implementa el estandar CORBA 2.3.


Anlisis de la aplicacin

Como en todo desarrollo software en la fase de anlisis debemos de capturar todo lo que se espera que nuestra aplicacin haga.
Para ello debemos ir buscando toda la funcionalidad requerida. Inicialmente vamos a describir el escenario de funcionamiento y despues vamos a utilizar casos de uso del sistema para capturar mas requerimientos del sistema.
De cualquier modo esta parte de A&D (Anlisis y Desarrollo) no ser ni mucho menos formal, ya que el objetivo del curso es aprender CORBA y no A&D de sistemas, un tema demasiado complejo y amplio como para ser cubierto en tan poco espacio.
El objetivo de esta seccin es dar unas pinceladas de A&D y ver como se ajustan estos procesos a CORBA. 
Escenario
El problema que se nos plantea es: <<una organizacin quiere agilizar las comunicaciones internas entre sus empleados. Para ello est evaluando diferentes soluciones y entre ellas han pensado en un servicio de envo de mensajes sncrono, es decir, en un servicio al que estn de forma contnua conectados sus empleados y por el que se puedan comunicar, en comunicaciones uno a uno, uno a varios o varios a varios > 
Partimos de la hiptesis de que todos los empleados tienen un ordenador con el que trabajan, por lo que en principio este va a ser la herramienta a travs de la cual se comunicarn.
Al ser una organizacin grande hay ordenadores de muchos tipos, y segn el tipo de trabajo unos empleados trabajan en un tipo de ordenador u otro. En concreto se han detectado: mquinas Linux en la zona de desarrollo software, mquinas MacOS en la zona de diseo y mquinas con Windows en departamentos como los de gestin.
Por lo tanto, la solucin que demos debe de funcionar en todas estas plataformas, es decir, los binarios que se generen deben de soportar varias plataformas. Por ello todo apunta a que en los clientes vamos a utilizar Java como lenguaje de desarrollo.
El nmero de empleados de la empresa en bastante elevado, del orden de 10000 personas, por lo que el trfico de comunicaciones puede ser muy elevado. Como hay que soportar comunicaciones entre varios empleados simultneamente parece que vamos a necesitar un servidor central que coordine estas comunicaciones, ya que sino la complejidad en los clientes podra ser demasiado elevada. Dicho servidor deber soportar una carga elevada de conexiones y nuestra experiencia nos decanta a utilizar C++ como lenguaje de implementacin, aunque queremos dejar las puertas abiertas a otros lenguajes.
No se descarta la posibilidad de conexiones directas entre clientes sin tener que pasar por el servidor, para poder evitar congestiones dentro del servidor. 
Es una aplicacin que claramente tiene su mayor complejidad en las comunicaciones. Por ello se ha pensado en el uso de CORBA como "middleware" ya que as CORBA se encargara de gestionar dichas comunicaciones, permitiendo incluso la conexin de redes con diferentes protocolos. 
El servicio ha de ser gestionable, permitiendo definir polticas de conexin y existiendo unos operadores del servicio con una funcionalidad mayor a la de los clientes. 
Como resumen del escenario: 
* Existe un servidor central al que se conectarn los clientes. Posiblemente estar desarrollado en C++. 
* Varios clientes se conectarn al servidor de forma simultnea. El lenguaje de implementacin ser Java por la necesidad de ser multiplataforma. 
* Existirn clientes "operadores" con posibilidades adicionales. 
* Se utilizar CORBA para gestionar las comunicaciones 
* Deber existir una interfaz de gestin del servicio 
Objetos de la aplicacin
Del escenario podemos deducir que en la aplicacin van a existir los siguientes objetos: 
1. Objeto servidor: Se va a encargar de ir recibiendo las diferentes conexiones de los clientes. Adems debe permitir conexiones de los operadores autenticadas, los cuales podrn gestionar el servicio. Deber ofrecer el servidor una interfaz de gestin. Debe tambin recibir los mensajes de los diferentes clientes y enviarlos a todos los dems, as como facilitar las conexiones directas entre clientes. 
2. Objeto cliente: Debe de permitir al usuario conectarse al servicio y enviar mensajes. Debe permitir tambin establecer conexiones directas entre usuarios. 
3. Objeto operador: Es un objeto cliente ampliado con operaciones de gestin y de informe del funcionamiento del servicio. 
Una vez identificados los objetos que van a participar en el sistema, y tener su funcionalidad definida, podemos ya definir las interfaces IDL de cada uno de ellos, interfaces que deben cubrir toda la funcionalidad descrita. 

Diseo de la aplicacin. Interfaces IDL

En el diseo de la solucin al problema nos vamos a centrar en definir las interfaces IDL que cubran toda la funcionalidad requerida. Del anlisis hemos concluido que necesitamos tres objetos dentro del sistema, por lo que existirn tres interfaces IDL dentro del mismo. 
Toda la aplicacin en s pertenecer a un mdulo comn, al que llamaremos "Mensajes". Dentro de este mdulo se definirn las tres interfaces que hemos detectado. 
Interfaz del servidor

// Interfaz a implementar por el servidor
interface servidor {
    // Conexion de un operador
    string conectar_operador (in operador interfaz, in string clave);
    // Devuelve una cadena con el nombre del servidor
    string conectar (in cliente interfaz);
    // Desconecta un usuario del sistema
    boolean desconectar (in cliente interfaz);
    // Mira si un usuario esta conectado y recibe la interfaz al mismo
    cliente presente (in string nombre) raises (comun::ClienteNoPresente);
    // Devuelve una lista de los usuarios presentes en el sistema
    void listaUsuarios (out comun::lista_usuarios lista);
};
Interfaz del cliente

// Interfaz a implementar por el cliente
interface cliente {
    // Funcin bsica de recepcion de mensajes
    // Devuelve "true" ante recepcion correcta
    boolean recibeMensaje (in string mensaje);
    // Mensajes de aviso especiales del servidor
    boolean recibeAviso (in comun::alarma mensaje);
    // Mensajes directos a otros usuarios
    void enviaMensaje (in comun::usuario destino, in string mensaje);
};
Interfaz del operador

// El operador es informado de accesos al servicio
interface operador:cliente {
    boolean nuevaConexion(in string nombre);
};
Interfaz comn
Para compartir estructuras de datos comunes entre los tres interfaces lo que hacemos es definirnos un interfaz nuevo llamado "comun", en el que declararemos todas las estructuras de datos compartidas por los diferentes interfaces. 

interface comun {
    // Version de la aplicacion
    readonly attribute string version;
    // Nombre de usuario
    typedef string usuario;
    // Lista de usuarios
    typedef sequence<usuario> lista_usuarios;
    // Excepcion de usuario no presente
    exception ClienteNoPresente {usuario nombre;};
    struct alarma {
        unsigned short codigo;
        string mensaje;
    };
}; 
Conclusiones de A&D
Vemos que gracias principalmente al lenguaje OMG/IDL, a la salida de la fase de A&D tenemos ya modularizado y especificado el sistema. A partir de este momento podemos repartir las interfaces a los distintos grupos de desarrollo. Cada grupo se puede encargar de implementar una interfaz, y si se respetan dichas interfaces, la fase de integracin del sistema ser poco costosa.
Por otro lado aadir nueva funcionalidad al sistema resulta sencillo. Se identifica a que modulo pertenece dicha nueva funcionalidad, y se aade a su interfaz IDL. Es ms, dentro de las interfaces queda perfectamente capturado los criterios de diseo, por lo que no se introducirn cambios que deterioren la arquitectura inicial del sistema.
Resumiento podemos destacar las ventajas: 
* OMG/IDL modulariza permitiendo la implementacin en paralelo 
* OMG/IDL asegura que la integracin de los mdulos va a ser poco costosa 
* OMG/IDL permite una mantenibilidad del cdigo 
* OMG/IDL captura de forma concisa el diseo del sistema 


Descripcin del lenguaje OMG/IDL

El lenguaje OMG/IDL es uno de los pilares de la plataforma OMA de OMG, y en especial de CORBA.
La especificacin del lenguaje se puede consultar dentro del estndar de CORBA, en el captulo 3. Son un total de 40 pginas cuyo ndice lo podis observar en la siguiente figura:

Figura 1: Indice del captulo 3 del estndar de CORBA sobre OMG/IDL 

Esta es la fuente definitiva que a la que el lector tiene que acudir y de ella vamos a tomar datos del lenguaje a lo largo de este apartado. 
Gracias a este lenguaje descriptivo podemos especificar las interfaces de nuestros mdulos CORBA, sin ligarnos a ningn lenguaje concreto.
Adems es un lenguaje muy adecuado para el diseo del sistema ya que permite pensar en el diseo del sistema, sin tener que descender a detalles de implementacin.
Para evitar ambigedades a nivel de diseo es un lenguaje fuertemente tipado, al estilo de Java.
Es un lenguaje cuya sintaxis est bastante cercana a la de ANSI C++ o Java, al ser orientado a objetos. Tiene facilidades como la definicin de mdulos e interfaces, herencia de interfaces o excepciones.
Es un lenguaje lo suficientemente descriptivo como para poder detallar interfaces de objetos que van a ser distribuidos.
En la siguiente figura podemos observar las palabras claves reservadas en este lenguaje: 

Figura 2: Palabras reservadas de OMG/IDL 

Pasamos a describir el lenguaje con mayor detalle a continuacin, as como ejemplos de los principales traducciones de OMG IDL a lenguajes como C, C++ y Java. 
Descripcin del lenguaje
OMG/IDL es un lenguaje sencillo al ser declarativo. Una muestra de su sencillez es que su gramtica est compuesta de 82 reglas en total, pudindose consultar dicha gramtica dentro del captulo 3 del estndar de CORBA.
La mejor forma de entender el lenguaje es mediante un ejemplo que iremos explicando a lo largo de este apartado.
El ejemplo que utilizaremos ser la interfaz IDL "Mensajes.idl" resultado de la fase de diseo de la solucin que desarrollamos en el apartado anterior. Reproducimos dicha interfaz al completo para que el lector la pueda tener a mano ya que ser utilizada a menudo como referencia. 

1: // Mdulo de intercambio de mensajes entre usuarios
2: module Mensajes {
3: 	interface comun {
4: 		// Version de la aplicacion
5: 		readonly attribute string version;
6: 
7: 		// Nombre de usuario
8: 		typedef string usuario;
9: 		// Lista de usuarios
10: 		typedef sequence<usuario> lista_usuarios;
11: 
12: 		// Excepcion de usuario no presente
13: 		exception ClienteNoPresente {usuario nombre;};
14: 
15: 		struct alarma {
16: 			unsigned short codigo;
17: 			string mensaje;
18: 		};
19: 	}; 
20: 	
21: 	// Interfaz a implementar por el cliente
22: 	interface cliente {
23: 		// Funcin bsica de recepcion de mensajes
24: 		// Devuelve "true" ante recepcion correcta
25: 		boolean recibeMensaje (in string mensaje);
26: 		// Mensajes de aviso especiales del servidor
27: 		boolean recibeAviso (in comun::alarma mensaje);
28: 		// Mensajes directos a otros usuarios
29: 		void enviaMensaje (in comun::usuario destino, in string mensaje);
30: 	};
31: 
32: 	// El operador es informado de accesos al servicio
33: 	interface operador:cliente {
34: 		boolean nuevaConexion(in string nombre);
35: 	};
36: 
37: 	// Interfaz a implementar por el servidor
38: 	interface servidor {
39: 		// Conexion de un operador
40: 		string conectar_operador (in operador interfaz, in string clave);
41: 		// Devuelve una cadena con el nombre del servidor
42: 		string conectar (in cliente interfaz);
43: 		// Desconecta un usuario del sistema
44: 		boolean desconectar (in cliente interfaz);
45: 		// Mira si un usuario esta conectado y recibe la interfaz al mismo
46: 		cliente presente (in string nombre) raises (comun::ClienteNoPresente);
47: 		// Devuelve una lista de los usuarios presentes en el sistema
48: 		void listaUsuarios (out comun::lista_usuarios lista);
49: 	};
50: 
51: };
Mdulos e interfaces
Este ejemplo es bastante completo y nos va a permitir profundizar en diferentes aspectos de OMG IDL.
La primero que observamos es la forma de encapsular en mdulos las interfaces. Un mdulo debe de ser un conjunto de interfaces que proporcionan una funcionalidad concreta dentro del sistema. En nuestro caso este mdulo es el encargado de definir el mdulo de Mensajes de una herramienta de trabajo cooperativo.
Dentro del mdulo hemos definido dos interfaces: una para los clientes y otra para el servidor central. La arquitectura sigue los esquemas centralizados, es decir, que un servidor central controla la forma de interactuar entre los diferentes clientes. Pero tambin se pueden obtener las interfaces a otros clientes y comunicarnos con ellos de forma directa.
Comprobamos aqu que CORBA se adapta sin problemas a paradigmas como el de cliente/servidor o de igual a igual sin ningn tipo de problema. 
Operaciones y tipos de datos
Las funciones se agrupan en interfaces cuando tienen un propsito comn. 
Dichas funciones tienen parmetros de entrada, con sus tipos correspondientes y parmetros de salida. Es necesario especificar el parmetro de retorno, aunque este sea "void". 
Es caractersticos de OMG/IDL que los parmetros que se pasan a la funcin pueden ser de tres tipos: 
* in: parmetros que se envan del cliente al servidor 
* out: parmetros en los que se reciben datos del servidor 
* inout: parmetros en los que se envan datos al servidor y se reciben datos de respuesta del servidor. 
Esta caracterstica de CORBA en el paso de parmetros complica la gestin de memoria dentro de la implementacin. En los tipos de parmetros "in" la gestin de memoria del parmetro es sencilla: el cliente se encarga de la reserva y liberacin de memoria.
Pero en los parmetros "out" y "inout" aparece el problema de que, el cliente puede reservar una cantidad de memoria para el parmetro, cantidad que puede ser modificada por el objeto para que entre en el parmetro la respuesta.
En el estndar se han dividido 20 tipos de parmetros en 6 tipos de paso de parmetros. Por ejemplo, para parmetros de longitud fija (incluyendo las estructuras), el llamante reserva y libera el espacio excepto en el caso de "any".
Las referencias a objetos tambin son gestionadas en el cliente. Pero por ejemplo, si el parmetro es "inout", la implementacin del objeto va a invocar la operacin CORBA::Object_release en el valor original para reasignar el parmetro (algo que tambin afecta en el lado del cliente). Para guardar el valor original de la referencia al objeto, deberemos utilizar CORBA::duplicate antes de invocar la operacin.
Hay casos en los parmetros "out" y "inout" en los que la implementacin debe de reservar la memoria, pero debe ser liberada en el cliente.
Dentro del estndar estas detallados todos los casos y hay que ser cuidadoso para evitar agujeros de memoria en nuestras aplicaciones.
Los tipos de estos datos son los que solemos encontrarnos en cualquier lenguaje de programacin: integer (signed/unsigned long, short), float, double, boolean, octet, any.
Tambin tenemos tipos estructurados como: struct, discriminated union, enumerations, sequence, string y array.
Un tipo especial de datos son los atributos. Un ejemplo de su uso lo encontramos en la lnea 5. Los atributos al ser procesados por el compilador de IDL generan una funcin (get) si son de solo lectura (como en nuestro caso), o dos funciones (get y set) si son de lectura y escritura. El acceso al atributo se ha de realizar de forma obligatoria a travs de estas operaciones. 
De todos estos tipos de datos quizs merezca mencin especial el tipo "any" en el que podemos meter cualquier otro tipo de dato de OMG/IDL. Un tipo de datos muy flexible que no solemos encontrar en los lenguajes usuales.
Por ltimo comentar que existe un tipo especial de operacin, aquellas del tipo "oneway". Son operaciones que se invocan sin esperar ningn valor de retorno, no siendo bloqueantes. Por ello en este tipo de operaciones el tipo de retorno ha de ser "void" y todos los parmetros han de ser del tipo "in". Un ejemplo de este tipo de operacin lo observamos en la lnea 27, donde el servidor enva las alarmas a los clientes, sin esperar que estos le respondan nada. 
Excepciones
Algo importante en la invocacin de operaciones sobre objetos CORBA es que, aunque para el desarrollador sean invocaciones comunes sobre objetos, el mecanismo para sus ejecucin es complejo: han de pasar por los cabos del cliente, por el ORB, por el adaptador de objetos, encontrar el objeto adecuado, viajar por los cabos del servidor, realizar la invocacin sobre el objeto y recorrer el mismo viaje de vuelta.
Es sencillo que en todo este trasiego puedan aparecer problemas. Y para informar al cliente de dichos problemas aparecen las excepciones. Ante problemas en la invocacin de estas operaciones, el ORB nos puede devolver excepciones de diferentes tipo, segn el problema aparecido. 
Pero es ms dentro de nuestro cdigo tambin podemos crear excepciones para la gestin de errores, o para comunicar situaciones excepcionales.
Tal es el caso de la funcin de la lnea 39, que en el caso de que un usuario no este conectado lo devuelve como una excepcin.
Herencia
La herencia es un mecanismo de reutilizacin de funcionalidad. En nuestro caso la utilizamos para definir la interfaz de un operador, que es un cliente con una operacin ms, la de recibir informacin de conexiones. 


Traducciones de OMG/IDL a C, C++ y Java
Mapping a C
Al no tener el lenguaje C objetos ni excepciones, en el mappping de OMG/IDL a C en todas las operaciones aparecen el objeto sobre el que se va a invocar, y una variable de contexto para recoger informacin sobre las excepciones.
La carencia en C de espacios de nombres obliga a nombres de la forma "CORBA_object" y con ello, aparece el problema de posibles colisiones de nombres.
Un ejemplo de mapping sencillo podra ser: 

interface ejemplo {
	long operacion (in string arg);
};
Este interfaz en IDL genera en C (partes relevantes):
typedef CORBA_Object ejemplo;
extern CORBA_long operacion (
			ejemplo o, CORBA_string arg, CORBA_Enviroment *ev);
Queda patente del ejemplo como en cada operacin, hay que especificar el objeto sobre el que se va a ejecutar la operacin, as como el entorno por el que se pasarn las excepciones.
Los tipos bsicos no se traducen directamente a tipos en C, ya que los tipos en C pueden variar de una arquitectura a otra (nmero de bits, forma de ordenacin de los bytes ...). Por ello por ejemplo el tipo IDL "long" se mapea a "CORBA_long" en C, y no a un long directamente.
Para traducir el mecanismo de herencia lo que se hace, como en C no existe la herencia, es incluir dentro de la traduccin todos los elementos de la interfaz, y todos los de las interfaces de los que hereda. 
Como ya dijimos el manejo de excepciones se realiza utilizando variables de entorno "CORBA_Enviroment". Este mismo mecanismo es el que se utiliza en el caso de los compiladores de C++ que an no tuvieran soporte para excepciones. 
Mapping a C++
La traduccin de OMG/IDL es ms directa a C++ que a C, a pesar de que en cuando se public el mapping de OMG/IDL a C++ an no estaba aprobado el estndar ANSI C++, lo que oblig a dar rodeos para aspectos (p.e. string) que hoy seran mucho ms sencillo.
Siguiendo con el mismo ejemplo anterior: 

interface ejemplo {
	long operacion (in string arg);
};
Este interfaz en IDL genera en C++ (partes relevantes):
class ejemplo : virtual public CORBA::Object {
	virtual CORBA::Long operacion( const char* arg ) = 0;
}
Todos las interfaces se convierten en objetos CORBA por el mecanismo de la herencia, hecho que muestra que todos los objetos CORBA tienen una funcionalidad comn, con operaciones como: 
* _duplicate 
* _narrow 
* _nil 
Recordemos que los objetos CORBA en nuestra aplicacin son tipos abstractos, es decir, no podemos interpretar su representacin. Estas operaciones comunes nos permiten copiar referencias, ver si una referencia apunta a un objeto vlido, o hacer un "casting" de particularizacin.
Normalmente C++ mos proporciona el "casting" de generalizacin. Con la operacin de _narrow podemos transformar un "CORBA::Object" en un objeto concreto.
Como vemos la operacin de la interfaz es definida como una operacin abstracta pura, es decir, que para implementar este objeto estamos obligados a implementar esta operacin. Normalmente para implementar la interfaz lo que se hace es heredar de la clase ejemplo (class ejemploImp:virtual public ejemplo) e implementar la operacin. 
Como comentamos en la introduccin a IDL, uno de los problemas a la hora de desarrollar con CORBA era la gestin de memoria, en concreto con los parmetros "inout" y "out".
En C++ este problema se alivia un poco gracias a que los tipos de datos que no son bsicos (long, short, float, double) reciben un tratamiento especial. Un tipo "T" reciben traduccin sobre "T" y "T_var". El tipo "T_var" incluye mecanismos de gestin automtica de memoria, por lo que si utilizamos estos tipos, nos vemos liberados de reservar y liberar memoria. 
Dentro de los ejemplos profundizaremos ms en el uso de IDL en C++, como se implementan los interfaces y como se usan los objetos. 
Mapping a Java
El mapping a Java es el ltimo que se produjo, finales de 1997, y es quizs el ms directo de todos, debido al soporte que da Java a la programacin orientada a objetos, el uso de interfaces, ... 
Tomando el ejemplo anterior tenemos: 

interface ejemplo {
	long operacion (in string arg);
};
Este interfaz en IDL genera en Java (partes relevantes):
public interface ejemplo extends org.omg.CORBA.CORBject {
  int operacion(java.lang.String arg);
}
Este ejemplo es muy parecido al de C++, pero como Java tiene la construccin sintctica "interface" la traduccin es todava ms inmediata.
Uno de los problemas que presenta Java es que no soporta la herencia mltiple. Esto obliga a que por ejemplo, si la clase que implementa la interfaz ya hereda de alguna otra, no podemos heredar de nuevo de la clase ejemplo (no heredamos directamente de la interfaz "ejemplo" si no de la clase "ejemploStub").
Cuando OMG defini como se pasaba de IDL a Java, Java estaba ya prcticamente estandarizado por lo que el "mapping" fue sencillo.
Los problemas de gestin de memoria aqu no aparecen ya que, Java gestiona de forma automtica la memoria con el recolector de basura.
Resumen
Hasta el momento hemos hecho una introduccin a como se traduce de OMG/IDL a C, C++ o Java. Hemos visto que el soporte de objetos de C++ y Java facilita su traduccin.
A continuacin pasamos a describir las herramientas bsicas que utilizaremos para desarrollar los ejemplos, para a continuacin pasar a programar utilizando Java. 

Implementacin de CORBA 2.2 en Java: JavaORB

Figura 3: Distributed Object Group 

JavaORB, desarrollado por el DOG, es una herramienta que nos permite desarrollar utilizando CORBA 2.2, por lo que tiene implementados sistemas como POA.
Lo primero que debemos tener en nuestra mquina GNU/Linux es tener instalada la versin de JDK 1.1.x, siendo recomendable la JDK 1.1.7.
El JDK para GNU/Linux se puede obtener de http://www.blackdown.org.
Es importante no utilizar la versin JDK 1.2 ya que esta incluye su propio ORB y hay que configurar JavaORB de una forma especial para que no colisionen ambos ORBs. Esto es posible y se detalla dentro de la pgina web de JavaORB, pero no se va a cubrir en este artculo.
Una vez instalado el JDK 1.1 en nuestro sistema la instalacin de JavaORB es muy sencilla. Lo primero que debemos hacer es ir al servidor de web del grupo que lo ha desarrollado (http://www.multimania.com/dogweb) y obtener el fichero "JavaORB_1.2.4.zip" que constituye la implementacin de CORBA. Atencin que cuando el lector acceda a este web pueden existir versiones nuevas, y su instalacin aunque muy parecida a la que aqu se describe, puede diferir.
Tras ello ejecutamos la orden: 

unzip JavaORB_1.2.4.zip
Una vez descomprimido el fichero nos vamos al directorio "Release/JavaORB" y dentro de l tenemos en el fichero "README.txt" las instrucciones de instalacin. Bsicamente, si no utilizamos JDK 1.2, en cuyo caso el lector debe leer dicho fichero, lo nico que hay que hacer es aadir al CLASSPATH el fichero "JavaORBv1_2_4.jar". El CLASSPATH es una variable de entorno que utiliza el JDK para encontrar las clases.
Una vez hecho esto ya disponemos de todo lo necesario para desarrollar aplicaciones CORBA basadas en Java.
En nuestro caso lo nico que vamos a hacer de momento es utilizar el compilador de IDL que proporciona la herramienta, para que el lector pueda empezar a trabajar con el lenguaje IDL y comprobar que utiliza de forma correcta el lenguaje.
Para utilizar dicho compilador encontramos dentro del directorio "Release/JavaORB/bin" el ejecutable "idl2java" (al ser una distribucin para entornos MSDOS estos ficheros no tienen permiso de ejecucin. El lector debe modificar esto con la orden "chmod 755 idl2java").
Este ejecutable lo que hace es lanzar un programa Java que es el que pasa del lenguaje IDL a Java. El compilador genera tanto los cabos (stubs) del cliente como los esqueletos (skeletons) del servidor. Tambin genera las interfaces que debe implementar el servidor.
Pero de momento no vamos a entrar en estos detalles y nos vamos a centrar en el compilador "idl2java". Para su uso, definimos nuestras interfaces en un fichero ".idl", en nuestro caso "Mensajes.idl", y ejecutamos: 

idl2java Mensajes.idl
Para ello puede el lector crearse un directorio "idl" dentro de su cuenta, copiar all el fichero Mensajes.idl y poner en el PATH el directorio donde se encuentra el ejecutable "idl2java".
Si no utilizamos ningn parmetro del compilador, el resultado de dicha invocacin es la creacin de un directorio "corba_pkg" con todas las clases necesarias para los clientes y servidores CORBA.
Todas las opciones disponibles del compilador son: 

bash-2.01$ idl2java             


#################################################
#                     Java ORB                  #
#                -----------------              #
#              (c) 1997, 1998, 1999             #
#################################################
# Java IDL Compiler, Release 1.6                #
#################################################


Options
-------
        -release
                Show version number
        -nopackage
                Don't use corba_pkg directory as a package
        -outdir:
                Provide a way to specify the ouput dir. This option
                will not use the corba_pkg directory.
                For example :
                        idl demo.idl -outdir:/home/me/
        -package: package_name
                Generate files in package_name
                Example:
                        idl demo.idl -package:exemple
        -I
                Allow specification of include directory
                Example:
                  idl demo.idl -I/home/me/idl -I../autre
        -D
                Define a symbole. It is equivalent to #define
        -nostub
                Don't generate stub.
        -noskeleton
                Don't generate skeleton.
        -tie
                Generate TIE files to delegation mode.
        -user
                Generate code for user
        -pidl
                Consider the IDL file as PIDL description. It generates
                mapping but no stub, no skeleton.
        -native: native name = native mapping 
                Define native type mapping.
                For example : 
                        idl     demo.idl -native:cookie=java.lang.Object
                        this command implies the mapping of
                        cookie in java.lang.Object.
        -poa
                Generate skeleton for POA
De ellas destacar el parametro "-poa" que generar los esqueletos necesarios para utilizar POA como adaptador de objetos de CORBA. Las dems opciones sern descritas a lo largo de las prximas entregas del curso.
Quizs el lector quiera comenzar a utilizar un interfaz ms sencillo e ir poco a poco complicndolo. Un buen punto de partida es: 

interface echo {
        string repite (in string mensaje);
};
Para el lector avanzado podemos indicarle que consulte el fichero "corba_pkg/echoOperations.java" donde encontrar la interfaz Java que es traduccin directa de la interfaz OMG/IDL. 

Conclusiones

A lo largo de este artculo hemos podido ver la importancia del lenguaje OMG/IDL.
Todo proceso de diseo software orientado a objetos debe acabar definiendo de forma clara las interfaces de comunicacin de los objetos de la aplicacin. Y estas se describen en el mundo CORBA utilizando el leguaje OMG/IDL
OMG/IDL es un lenguaje sencillo, basado fundamentalmente en Java, y con algunas extensiones para reflejar mecanismos de comunicacin.
A partir de l se obtiene de forma automtica los cabos (stubs) y esqueletos (skeletons) que permitirn a nuestros clientes y servidores comunicarse a travs del ORB.
Hemos visto por ltimo la herramienta JavaORB, una implementacin de CORBA 2.2 que incluye un compilador de IDL a Java con el que podemos empezar a trabajar. 

Prxima entrega

Por fin en la prxima entrega del curso empezaremos a desarrollar una aplicacin CORBA, una vez sentados los principios de CORBA.
Ser un ejemplo sencillo pero que demostrar la potencia de esta arquitectura para desarrollo distribuido de objetos. 

Referencias

* Pgina del curso: http://www.angelfire.com/al/acs 
* JavaORB: http://www.multimania.com/dogweb 
* OMG: http://www.omg.org 
* Direccin de correo de CORBA en Future Space: corba@futurespace.es 
