Curso práctico de Corba en GNU/Linux

El lenguaje OMG/IDL es uno de los pilares de la plataforma OMA de OMG, y en especial de CORBA.

La especificaci�n del lenguaje se puede consultar dentro del est�ndar de CORBA, en el cap�tulo 3. Son un total de 40 p�ginas cuyo �ndice lo pod�is observar en la siguiente figura:

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 m�dulos CORBA, sin ligarnos a ning�n lenguaje concreto.

Adem�s es un lenguaje muy adecuado para el dise�o del sistema ya que permite pensar en el dise�o del sistema, sin tener que descender a detalles de implementaci�n.

Para evitar ambig�edades a nivel de dise�o 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 definici�n de m�dulos 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:

Pasamos a describir el lenguaje con mayor detalle a continuaci�n, as� como ejemplos de los principales traducciones de OMG IDL a lenguajes como C, C++ y Java.

�Descripci�n del lenguaje

OMG/IDL es un lenguaje sencillo al ser declarativo. Una muestra de su sencillez es que su gram�tica est� compuesta de 82 reglas en total, pudi�ndose consultar dicha gram�tica dentro del cap�tulo 3 del est�ndar 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 dise�o de la soluci�n 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: // M�dulo 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 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: 		// Funci�n b�sica 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: };

�M�dulos 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 m�dulos las interfaces. Un m�dulo debe de ser un conjunto de interfaces que proporcionan una funcionalidad concreta dentro del sistema. En nuestro caso este m�dulo es el encargado de definir el m�dulo de Mensajes de una herramienta de trabajo cooperativo.

Dentro del m�dulo 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 tambi�n 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 ning�n tipo de problema.

�Operaciones y tipos de datos

Las funciones se agrupan en interfaces cuando tienen un prop�sito com�n. Dichas funciones tienen par�metros de entrada, con sus tipos correspondientes y par�metros de salida. Es necesario especificar el par�metro de retorno, aunque este sea void.

Es caracter�sticos de OMG/IDL que los par�metros que se pasan a la funci�n pueden ser de tres tipos:

1. in: par�metros que se env�an del cliente al servidor.
2. out: par�metros en los que se reciben datos del servidor.
3. inout: par�metros en los que se env�an datos al servidor y se reciben datos de respuesta del servidor.

Esta caracter�stica de CORBA en el paso de par�metros complica la gesti�n de memoria dentro de la implementaci�n. En los tipos de par�metros in la gesti�n de memoria del par�metro es sencilla: el cliente se encarga de la reserva y liberaci�n de memoria.

Pero en los par�metros out y inout aparece el problema de que, el cliente puede reservar una cantidad de memoria para el par�metro, cantidad que puede ser modificada por el objeto para que entre en el par�metro la respuesta.

En el est�ndar se han dividido 20 tipos de par�metros en 6 tipos de paso de par�metros. Por ejemplo, para par�metros de longitud fija (incluyendo las estructuras), el llamante reserva y libera el espacio excepto en el caso de any.

Las referencias a objetos tambi�n son gestionadas en el cliente. Pero por ejemplo, si el par�metro es inout, la implementaci�n del objeto va a invocar la operaci�n CORBA::Object_release en el valor original para reasignar el par�metro (algo que tambi�n afecta en el lado del cliente). Para guardar el valor original de la referencia al objeto, deberemos utilizar CORBA::duplicate antes de invocar la operaci�n.

Hay casos en los par�metros out y inout en los que la implementaci�n debe de reservar la memoria, pero debe ser liberada en el cliente.

Dentro del est�ndar 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 programaci�n: integer (signed/unsigned long, short), float, double, boolean, octet, any.

Tambi�n 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 l�nea 5. Los atributos al ser procesados por el compilador de IDL generan una funci�n (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 trav�s de estas operaciones.

De todos estos tipos de datos quiz�s merezca menci�n 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 operaci�n, aquellas del tipo oneway. Son operaciones que se invocan sin esperar ning�n valor de retorno, no siendo bloqueantes. Por ello en este tipo de operaciones el tipo de retorno ha de ser void y todos los par�metros han de ser del tipo in. Un ejemplo de este tipo de operaci�n lo observamos en la l�nea 27, donde el servidor env�a las alarmas a los clientes, sin esperar que estos le respondan nada.

�Excepciones

Algo importante en la invocaci�n de operaciones sobre objetos CORBA es que, aunque para el desarrollador sean invocaciones comunes sobre objetos, el mecanismo para sus ejecuci�n 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 invocaci�n 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 invocaci�n de estas operaciones, el ORB nos puede devolver excepciones de diferentes tipo, seg�n el problema aparecido.

Pero es m�s dentro de nuestro c�digo tambi�n podemos crear excepciones para la gesti�n de errores, o para comunicar situaciones excepcionales. Tal es el caso de la funci�n de la l�nea 39, que en el caso de que un usuario no este conectado lo devuelve como una excepci�n.

�Herencia

La herencia es un mecanismo de reutilizaci�n de funcionalidad. En nuestro caso la utilizamos para definir la interfaz de un operador, que es un cliente con una operaci�n m�s, la de recibir informaci�n de conexiones.