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 informaci�n 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 podr�a 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 operaci�n, hay que especificar el objeto sobre el que se va a ejecutar la operaci�n, as� como el entorno por el que se pasar�n las excepciones.
Los tipos b�sicos no se traducen directamente a tipos en C, ya que los tipos en C pueden variar de una arquitectura a otra (n�mero de bits, forma de ordenaci�n 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 traducci�n 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 a�n no tuvieran soporte para excepciones.
�Mapping a C++
La traducci�n de OMG/IDL es m�s directa a C++ que a C, a pesar de que en cuando se public� el mapping de OMG/IDL a C++ a�n no estaba aprobado el est�ndar ANSI C++, lo que oblig� a dar rodeos para aspectos (p.e. string) que hoy ser�an mucho m�s 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 com�n, con operaciones como:
- _duplicate
- _narrow
- _nil
Recordemos que los objetos CORBA en nuestra aplicaci�n son tipos abstractos, es decir, no podemos interpretar su representaci�n. Estas operaciones comunes nos permiten copiar referencias, ver si una referencia apunta a un objeto v�lido, o hacer un casting de particularizaci�n.
Normalmente C++ mos proporciona el casting de generalizaci�n. Con la operaci�n de _narrow podemos transformar un CORBA::Object en un objeto concreto.
Como vemos la operaci�n de la interfaz es definida como una operaci�n abstracta pura, es decir, que para implementar este objeto estamos obligados a implementar esta operaci�n. Normalmente para implementar la interfaz lo que se hace es heredar de la clase ejemplo (class ejemploImp:virtual public ejemplo) e implementar la operaci�n.
Como comentamos en la introducci�n a IDL, uno de los problemas a la hora de desarrollar con CORBA era la gesti�n de memoria, en concreto con los par�metros inout y out.
En C++ este problema se alivia un poco gracias a que los tipos de datos que no son b�sicos (long, short, float, double) reciben un tratamiento especial. Un tipo T reciben traducci�n sobre T y T_var. El tipo T_var incluye mecanismos de gesti�n autom�tica de memoria, por lo que si utilizamos estos tipos, nos vemos liberados de reservar y liberar memoria.
Dentro de los ejemplos profundizaremos m�s 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 quiz�s el m�s directo de todos, debido al soporte que da Java a la programaci�n 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 construcci�n sint�ctica interface la traducci�n es todav�a m�s inmediata.
Uno de los problemas que presenta Java es que no soporta la herencia m�ltiple. 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 pr�cticamente estandarizado por lo que el mapping fue sencillo.
Los problemas de gesti�n de memoria aqu� no aparecen ya que, Java gestiona de forma autom�tica la memoria con el recolector de basura.
�Resumen
Hasta el momento hemos hecho una introducci�n 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 traducci�n.
A continuaci�n pasamos a describir las herramientas b�sicas que utilizaremos para desarrollar los ejemplos, para a continuaci�n pasar a programar utilizando Java.