Estas exigencias motivaron el uso de CORBA (Common Object Request Broker

Architecture). CORBA es un estándar abierto del OMG (Object Management Group) para la
programación de aplicaciones distribuidas. CORBA mejora la flexibilidad y portabilidad de las
aplicaciones y permite al programador desentenderse de las tareas más complejas que
conllevan los entornos distribuidos heterogéneos, con muy diversas máquinas, sistemas
operativos y protocolos de comunicaciones. CORBA constituye, por ser la arquitectura
distribuida de más éxito actualmente, el soporte fundamental para la consecución de la
universalidad de las aplicaciones, y es un entorno cada vez más demandado por las empresas
dedicadas a las telecomunicaciones avanzadas.

La arquitectura CORBA está orientada a objetos. Los objetos CORBA presentan muchas
características de otros sistemas orientados a objetos, incluyendo la herencia de interfaces y el
polimorfismo. Lo que hace a CORBA más interesante es que proporciona estas capacidades,
incluso cuando es utilizado en lenguajes no orientados a objeto como C o COBOL, aunque
CORBA trabaja particularmente bien con los lenguajes orientados a objeto como C++ y Java.

Dentro de las nuevas técnicas y lenguajes de modelado de objetos, cabe destacar la notación
estándar UML (Unified Modeling Language), cuya última actualización es UML 1.2 a mediados
de 1998. UML es una evolución de las metodologías orientadas a objeto anteriores, como
Booch, OMT, y OOSE, tratando de unificar lo mejor de cada una de ellas. UML ha dado lugar un
potente lenguaje visual, para expresar diseños orientados a objetos, consistente en palabras,
textos, gráficos y símbolos.

Cabe destacar, sin embargo, que UML es sólo un estándar de notación. Esencialmente, define
un cierto número de diagramas que se pueden dibujar para describir un sistema y el
significado de dichos diagramas. UML no describe el proceso a seguir al desarrollar el software,
también considerado en la metodología formal tradicional.

El IDL

El lenguaje de definición de interfaz o IDL (Interface Definition Language), es un lenguaje

muy sencillo utilizado para definir interfaces entre componentes de aplicación. Es importante
destacar que IDL sólo puede definir interfaces, no implementaciones. IDL, al especificar las
interfaces entre objetos CORBA, es el instrumento que asegura la independencia del lenguaje
de programación utilizado.

Para ello, la especificación IDL ha de asegurar que los datos son correctamente intercambiados
entre dos lenguajes distintos. Por ejemplo, el tipo long es un entero con signo de 32 bits, que
se puede hacer corresponder con un long de C++ (dependiendo de la plataforma) o a un int de
Java. Es responsabilidad de la especificación IDL (y de los compiladores IDL que la
implementan), definir dichos tipos de datos de una forma independiente del lenguaje.

IDL consigue la independencia del lenguaje a través de una correspondencia. El OMG ha

definido bastantes correspondencias con lenguajes de programación populares, como: C, C++,
COBOL, Java, Smalltalk y Ada. Las correspondencias para otros lenguajes también existen, pero
o no son estándar o están en proceso de estandarización. En la Tabla 1 se muestra la
correspondencia entre los tipos IDL y los tipos C++.

Describiendo las interfaces IDL, un ORB genera automáticamente código en el lenguaje

seleccionado para realizar la integración de las aplicaciones distribuidas. Evidentemente,
puesto que sólo describe interfaces, todas las tareas complejas relacionadas con los lenguajes
de programación, como control de flujo, gestión de memoria, composición funcional, no
aparecen en IDL.

Evidentemente, la independencia del lenguaje de programación es una característica muy

importante de la arquitectura CORBA. CORBA da a los programadores de la aplicación la
libertad para elegir el lenguaje que mejor se adapta a las necesidades de su aplicación o bien
utilizar varios lenguajes para varios componentes de la aplicación. Por ejemplo, el cliente de
una aplicación podría estar implementado en Java, lo que asegura que los clientes pueden
ejecutarse virtualmente en cualquier máquina. Los componentes servidores de dicha
aplicación podrían implementarse en C++, para conseguir una elevada eficiencia. CORBA hace
posible la comunicación entre estos componentes de diversa naturaleza.

El registro de interfaz

Todas las aplicaciones basadas en CORBA necesitan acceder al tipo de sistema de IDL cuando
se están ejecutando. Esto es necesario porque la aplicación necesita conocer los tipos de
valores a ser pasados como argumentos de la petición. Asimismo, la aplicación ha de conocer
los tipos de interfaces soportados por los objetos que están utilizando.

Ciertas aplicaciones requieren sólo un conocimiento estático del tipo de sistema IDL.
Típicamente, la especificación IDL es compilada o traducida a código para el lenguaje de
programación de la aplicación siguiendo las reglas de traducción como es definido por su
correspondencia con el lenguaje. De esta forma, si el tipo del sistema IDL cambia de tal modo
que pasa a ser incompatible con el tipo de sistema construido en la aplicación, la aplicación ha
de volver a construirse.

Pero hay ciertas aplicaciones, sin embargo, para las cuales es imposible un conocimiento
estático del tipo de sistema IDL. Para estas aplicaciones CORBA proporciona otro método de
definir interfaces sustituyendo a IDL, el registro de interfaz. Las interfaces pueden ser añadidas
a un servicio de registro de interfaz, el cual define las operaciones para la recuperación de la
información del almacén en tiempo de ejecución. Utilizando el registro de interfaz, un cliente
podría ser capaz de ubicar un objeto desconocido en tiempo de compilación, preguntar acerca
de su interfaz, y después construir una petición a ser enviado a través del ORB.

En una aplicación CORBA, cualquier componente que proporciona la implementación para

un objeto es considerado un servidor. El hecho de ser un servidor CORBA significa que, el
componente (el servidor), ejecuta métodos para un objeto particular, en nombre de otros
componentes (los clientes).

Stubs y skeletons

Después de que el programador cree las definiciones de interfaz del componente utilizando
IDL, dicho desarrollador procesa los ficheros IDL resultantes con un compilador IDL. El
compilador crea los conocidos por client stubs y server skeletons. Los client stubs y server
skeletons sirven como una clase de “pegamento” que conecta las especificaciones de interfaz
IDL independientes del lenguaje con un código de implementación específico del lenguaje.

Los client stubs para una interfaz en particular se suministran para su inclusión con los
clientes que utilizan dichas interfaces. El client stub para una interfaz en particular,
proporciona una falsa implementación para cada uno de los métodos de dicha interfaz. En
vez de ejecutar la funcionalidad del servidor, los métodos del client stub simplemente se
comunican con el ORB para clasificar y desclasificar los parámetros.

Por otro lado, se tienen los server skeletons, proporcionando el esqueleto sobre el que se
construirá el servidor. Para cada método en la interfaz, el compilador IDL genera un método
vacío en el server skeleton. El desarrollador después proporciona una implementación para
cada uno de esos métodos.

Los stubs y skeletons han sido generalizados a un DII (Dynamic Invocation Interface) y DSI
(Dynamic Skeleton Interface), respectivamente. Ambas son interfaces proporcionadas
directamente por ORB, y son independientes de las interfaces IDL de los objetos que están
siendo invocados. Utilizando DII una aplicación cliente puede invocar peticiones, en
cualquier objeto, sin tener conocimiento en tiempo de compilación de las interfaces del
objeto. De forma semejante, DSI permite a los servidores ser codificados, sin
tener skeletonspara los objetos que están siendo invocados, siendo compilados
estáticamente en el programa.