CORBA es un sistema distribuido basado en objetos que permite la integración de gran variedad de sistemas de objetos. Automatiza muchas tareas de programación en red como registro de objetos, localización y activación; manejo de errores; de multiplexado de peticiones...
La clave para entender la arquitectura de CORBA es la Object Management Architecture (OMA).

2.1. OMA

La OMA está compuesta del Object Model y el Reference Model. El primero define como pueden ser descritos los objetos distribuidos por un entorno heterogéneo, mientras que el segundo caracteriza las interacciones entre dichos objetos.

En el Object Model un objeto es una entidad encapsulada con una identidad única y cuyos servicios pueden ser requeridos solamente a través de interfaces específicas, entendiendo interface como una descripción del conjunto de operaciones que puede realizarse en un objeto.

Un objeto puede crearse y destruirse mediante peticiones. El resultado de la creación de un objeto se revela al cliente como una referencia a objeto que denota al nuevo objeto. Una Referencia a Objeto es un nombre de objeto con un ORB que garantiza que se hace referencia a un objeto particular. Este objeto es inmutable y opaco, en el sentido de que ni el cliente ni la implementación del objeto pueden alcanzar a al referencia a objeto y modificarla. Solo el ORB sabe que es lo que hay en el interior de una referencia a objeto. La referencia a objeto solo es valida mientras el cliente realiza la petición.
Para entender mejor el Object Reference Model fijémonos en la figura,

 

                                    FIGURA 1: Arquitectura del Modelo de Referencia OMG

El Object Request Broker (ORB) es el principal responsable de las comunicaciones entre clientes y objetos. Capacita a los objetos a realizar y recibir peticiones y respuestas en entornos distribuidos. Asegura la construcción de aplicaciones a partir de objetos distribuidos y garantiza la interoperabilidad entre aplicaciones en plataformas distribuidas, abiertas y heterogéneas.

Cuando un cliente envía una petición a un objeto a través de un ORB, el ORB es el responsable de los mecanismos requeridos para encontrar la implementación del objeto, y de preparar al objeto para recibir la petición... la interface que el cliente percibe es independiente de la localización del objeto y de su lenguaje de implementación.

Los Object Services son interfaces independientes del dominio que soportan las funciones básicas para el manejo y la implementación de objetos.

Las Common Facilities son servicios compartidos por muchas aplicaciones. Al igual que los Object Services sus interfaces están orientadas horizontalmente, aunque no están dirigidas a usuarios finales como los están aquellas. No son imprescindibles.

Las Domain Interfaces juegan un papel similar al de los Object Services y las Common Facilities, pero son interfaces orientadas hacia dominios de aplicación específicos como telecomunicaciones o aplicaciones médicas.

Las Aplication Interfaces son interfaces desarrolladas especialmente para una aplicación dada.

 
 2.2. LA ARQUITECTURA DE CORBA

El esqueleto de CORBA es el que se muestra en la siguiente figura, para entenderlo mejor, examinaremos a continuación cada uno de sus componentes. 

FIGURA 2: Arquitectura de CORBA
 

2.2.1. Object Request Broker (ORB)

El ORB es el componente central de CORBA. Provee un mecanismo para la comunicación transparente entre clientes y objetos. Simplifica la programación distribuida separando al cliente de los detalles de los métodos de invocación, y haciendo parecer a las peticiones del cliente llamadas a procedimientos locales.

Durante una petición, el ORB primero localiza la implementación de código apropiada, entonces transmite la implementación del objeto para después devolver los resultados y el control al cliente.

La clave de ORB es, como ya se ha dicho, la transparencia en la comunicación cliente/objeto.

El ORB oculta:

- la localización del objeto: El cliente no sabe donde reside el objeto deseado, que puede estar en un proceso diferente de una máquina distinta, en la misma máquina pero en diferente proceso o incluso en el mismo proceso.

- la implementación del objeto: El cliente no sabe como está implementado el objeto, en que lenguaje ha sido escrito, o en que máquina y sistema operativo se está ejecutando.

- el estado de ejecución del objeto: Cuando se hace una petición a un objeto, el cliente no necesita saber si el objeto está respondiendo a algún otro cliente o está preparado para recibir una petición.

- los mecanismos de comunicación: El cliente desconoce que tipo de mecanismos utiliza ORB para enviar el "request" al objeto y devolverle a él la respuesta. Podría utilizarse el protocolo TCP/IP , compartición de memoria...

 El ORB Core es la parte de ORB que provee la representación básica de los objetos y de las peticiones de comunicación.
CORBA está diseñado para soportar diferentes mecanismos de objetos, gracias a la estructuración de ORB sobre ORB Core que provee diferentes interfaces que enmascaran las diferencias entre distintos ORB Cores.
Las interfaces de ORB pueden clasificarse en tres categorías:

        1. Operaciones comunes a todas las implementaciones de ORB ( DII, DSI... )
        2. Operaciones específicas a tipos particulares de objetos (OA)
        3. Operaciones específicas a estilos particulares de implementaciones de objetos ( IDL Stub Interface...)

Pueden existir varias implementaciones de ORB, y el cliente puede acceder simultáneamente a dos referencias de objetos de dos ORB's distintas. Sin embargo, cuando dos ORB's trabajan juntas es muy importante distinguir sus respectivas referencias a objetos.

A continuación describiremos brevemente cada una de las interfaces de ORB y su función.

 ORB Interface: Es la inteface que va directamente al ORB Core, es la misma para todos los ORB's y es independiente de la interface del objeto y del object adapter. La mayor parte de las funcionalidades de ORB se proveen en el Object Adapter por lo que hay pocas operaciones comunes a todos los objetos.

Object Adapter (OA): Es el nexo de unión entre la implementación de los objetos CORBA y el ORB, es decir, es un objeto interpuesto que permite a un emisor enviar peticiones a un objeto aunque el emisor no conozca la interface del objeto.

El OA provee los siguientes servicios:

                - registro de implementaciones
                - generación e interpretación de referencias a objeto.
                - invocaciones
                - seguridad en las interacciones
                - activación y desactivación de objetos e implementaciones
                - correspondencia de referencias a objeto e implementaciones
 

A pesar de que CORBA permite varios OA's es conveniente incluir solo los que sean necesarios, ya que la implementación del objeto depende de del Object Adapter, sólo cuando una implementación requiere servicios o interfaces muy diferentes debe considerarse un nuevo OA. Algunos de ellos son:

- Basic Object Adapter (BOA): Es usado por la mayor parte de objetos ORB con implementaciones convencionales, como los objetos y las referencias a objetos son conocidas por el ORB una implementación ha de registrar explícitamente los objetos que deben ser activados.

- Library Object Adapter (LOA): Es muy usado por objetos que tienen implementadas librerías. No necesitan autentificación ni activación ya que los objetos se encuentran en el programa cliente. Además acceden a almacenamiento permanente en ficheros.

- Object-Oriented Database Adapter (OODA): Usa una conexión a una base de datos orientada a objeto, para proveer acceso a los objetos almacenados en ella. Como la base de datos convierte referencias a objetos en objetos, los objetos deben registrarse implícitamente y residir en almacenamiento permanente.

 Interface Definition Language (IDL): Es el medio por el que una implementación de un objeto en concreto dice a sus posibles clientes que operaciones están disponibles y como invocarlas.
Uno de los detalles más relevantes del IDL es su independencia del lenguaje. Al ser IDL un lenguaje "de declaración" y no un lenguaje de programación obliga a que las interfaces sean definidas de forma separada a las implementaciones de los objetos. Las implementaciones de los objetos pueden estar hechas con distintos lenguajes y comunicarse entre ellas. Las interfaces independientes del lenguaje son muy importantes en los sistemas heterogéneos ya que no todos los lenguajes de programación están disponibles en cualquier plataforma.
IDL asegura la independencia de la plataforma y a la vez refuerza la modularidad y la robustez.
IDL proporciona un conjunto de tipos similares a los utilizados por los lenguajes de programación, los grupo más importantes de ellos son:

- Buil-in types:

            long: con o sin signo, tipos aritméticos de 32 bits
            long long: con o sin signo, tipos aritméticos de 64 bits
            char and wchar: tipos caracter
            float,double,long double: tipos de punto flotante
            boolean: tipo booleano
            octet: valores de 8 bit
            enum: tipo ennumerado
            any: cualquier tipo que esconda un valor de cualquier tipo de IDL incluyendo los Built-in y los tipos definidos por el usuario.

- Constructed types:

            struct: construcción de estructuras de datos (similar a C )

            discriminated union: tipo compuesto por un tipo discriminador y un valor de un tipo IDL especificado en la definición de la union. Las unions en IDL son similares a C, agregando estas últimas la discriminación que guarda el valor de la alternativa que es actualmente válida.

- Template types:

            string and wstring: tipos cadena
            sequence: es un contenedor de longitud variable y cuyos elementos son del tipo especificado entre < >.
            Fixed: un valor decimal de no mas de 31 dígitos significativos.
 

- Object Reference Types:

Un tipo IDL de referencia a objeto, se define simplemente nombrando al tipo de interface deseado. Veamos un ejemplo para que quede más claro:

interface banco{
                            typedef sequence cuentas;
                            cuentas busca_cuentas(in string cliente_name );
                        };

Este IDL define un interface llamado banco, que contiene la definición de un tipo llamado cuentas. El tipo cuentas está definido como un sequence de referencias al objeto cuentas. La operación busca_cuentas recibe como argumento de entrada un tipo cadena y devuelve un sequence de referencias a cuentas como resultado.

Un hecho importante de las interfaces IDL es que pueden ser herencia de una o más interfaces. Esto permite la reutilización de interfaces ya existentes para la definición de nuevos servicios. Debemos tener en cuenta ciertas reglas a la hora de construir nuevos interfaces ya que, por ejemplo, no se puede heredar de dos interfaces con el mismo nombre de una operación o atributo aunque si se puede redefinir un tipo u operación con un nombre que sea usado en las interfaces "madre".
Hay un caso especial de herencia en IDL y es que todas las interfaces son herencia implícita de la interface object definida en el modulo CORBA.

El sistema de tipos de IDL es suficiente para muchas aplicaciones, a pesar de su pequeño conjunto de tipos. Mantener tan pequeño como sea posible este conjunto ayuda a que sea usado por muchos lenguajes de programación. La simplicidad de IDL es necesaria para el éxito de CORBA.

Stubs and Skeleton and Static Invocation Interface (SII): Antes de comenzar definamos algunos conceptos:
Un stub es un mecanismo que crea y emite una petición en nombre del cliente.
Un skeleton es un mecanismo que entrega la petición a la implementación del objeto.
Ambos están incluidos en la IDL y son específicos para cada interface. Como los stubs y skeleton están construidos directamente dentro de la aplicación cliente y de la implementación del objeto, todas las operaciones o "métodos" son conocidas con anticipación por el cliente. SII es muy usado cuando el cliente conoce la interface que ofrece el servidor en tiempo de compilación. Las principales ventajas de SII son la simplicidad y la eficiencia.

 Una vez que la petición está hecha como una llamada a procedimiento en el lenguaje de programación se invoca al stub. El stub trabaja directamente con el cliente ORB para convertir la representación de la petición del lenguaje de programación en que la recibe a un formato válido para su transmisión por la red.

Una vez que la petición llega al objeto destino, el ORB servidor y el skeleton cooperan para convertirla del formato transmitible al formato del lenguaje de programación y dirigirlo al objeto.

Después de que el objeto completa la operación devuelve el resultado por la misma vía, a través del skeleton, el servidor ORB, la conexión, el cliente ORB, el stub y finalmente el cliente.
 

 
                                    FIGURA 3: Arquitectura del ORB

 Finalmente, indicar que puede haber más de un ORB disponible lo que implica que exista un stub para cada ORB. En este caso es necesario que el ORB colabore con el lenguaje de programación para asociar el correcto stub a cada referencia a objeto.

 Dynamic Invocation Interface (DII): Es la interface para invocaciones dinámicas de CORBA. Es independiente de las interfaces IDL desde las que los objetos son invocados. Es muy utilizada cuando el cliente no conoce en tiempo de compilación las interfaces ofrecidas por los servidores.

Con DII un cliente puede especificar el objeto a ser invocado, la operación a realizar y los parámetros necesarios para la operación en una llamada o una secuencia de llamadas. El código del cliente debe proveer información sobre la operación a llevar a cabo y los tipos de parámetros que deben ser pasados (información obtenida generalmente del Interface Repository o de otra fuente en tiempo de ejecución)

La invocación puede ser implementada en uno de estos tres modos:

                - Invocación Síncrona: El cliente invoca la petición y se queda bloqueado en espera de la respuesta. Es el método más utilizado por CORBA ya que es soportado por stub estáticos.

                - Invocación Síncrona Pospuesta: El cliente envía la petición, y continua su ejecución mientras esta se procesa hasta que recibe la respuesta. Este método es usado si el cliente invoca a muchos servicios independientes.

                - Invocación Unilateral: El cliente envía la petición y continua su ejecución sin esperar ninguna respuesta. También es soportado por SIL.

Comparativamente DII es más flexible que la interface estática de IDL, aunque es menos eficiente.

  Dynamic Skeleton Interface (DSI): Permite a los servidores ser escritos sin tener skeletons para los objetos que van a ser invocados y compilados estáticamente en el programa. Esto es especialmente útil cuando la implementación de un objeto desconoce en tiempo de compilación el tipo del objeto que está implementando.
El código de esta implementación debe proveer de descripciones de todos los parámetros de las operaciones al ORB, y el ORB proveerá los valores de entrada de los parámetros para utilizarlos en la ejecución de la operación. El código de la implementación provee los valores de salida de los parámetros al ORB después de realizarse la operación.
La naturaleza de DSI puede variar de un lenguaje de programación o Object Adapter a otro.
El DSI puede ser invocado a través del stub cliente o del DII.

Interface and Implementation Repositories: El Interface Repository es un servicio que provee objetos persistentes representando la información de IDL de una forma disponible en tiempo de ejecución. Esta información será usada por el ORB para realizar peticiones o por un programa para encontrar un objeto cuya interface desconocía en tiempo de compilación. Además el Interface Repository es un lugar utilizado para guardar información adicional asociada a las interfaces y los objetos.
La Implementation Repository permite al ORB localizar y activar implementaciones de los objetos. Juega un papel similar al de la Interface Repository guardando información adicional como localización de recursos, seguridad...

                                FIGURA 4: Interface e Implementation repositories

En la figura se muestra como toda esta información se hace disponible al cliente. La información de la implementación del objeto se provee en el tiempo de instalación y es guardada en la Implementation Repository para su uso una vez lleguen las peticiones.

 2.2.2. Servicios de Corba

Hasta ahora hemos hablado de ORB que es el encargado de proporcionarnos la infraestructura necesaria para la invocar operaciones de los objetos de forma transparente respecto a su localización en la red, el tipo de hard o sistema operativo sobre el que están ejecutándose, el lenguaje en el que se han implementado, o los mecanismos en la red que se han utilizado para establecer comunicación con ellos...
Trataremos ahora de los servicios que la especificación CORBA incluye. Estos servicios proveen de funciones básicas que todo objeto puede necesitar a lo largo de su vida, como copia, traslado, o servicios de nombre o dirección.
Entre ellos, y agrupados en componentes, se encuentran:

 
COMPONENTE 1:

1. Servicio de Eventos: soporta la notificación de las diferentes partes interesadas en el objeto cuando ocurren eventos definidos en el programa. Documento OMG 94.1.1

2. Servicio de Ciclo de Vida: soporta la creación, manipulación, y destrucción de objetos. Documento OMG 94.1.1

3. Servicio de objetos persistentes: soporta la persistencia del estado de un objeto aún cuando el objeto no está activado en memoria y entre ejecuciones de aplicaciones. Documento OMG 94.1.1 & 94.10.7

4. Servicio de Nombres: permite recuperar referencias a objetos a través de las asociaciones nombres-objetos. A su vez permite crear y destruir esas asociaciones. Documento OMG 94.1.1

 
COMPONENTE 2:

5. Servicio de Control de Concurrencia: protege la integridad de los datos de los objetos cuando se están procesando varias peticiones a la vez, de forma concurrente. Documento OMG 94.5.8

6. Servicio de Externalización: soporta la conversión del estado del objeto a un formato transmitible por la red.

Documento OMG 94.9.15

7. Servicio de Relaciones: es el encargado de crear, manipular y destruir las relaciones entre los distintos objetos.

Documento OMG 94.1.1

8. Servicio de Transacciones: asegura la computación consistente de varias operaciones en uno o mas objetos satisfaciendo los requerimientos de atomicidad (1), aislamiento (2) y durabilidad (3). Documento OMG 94.1.1

 
COMPONENTE 3:

9. Servicio de Seguridad: soporta la autentificación, autorización e integridad utilizando determinados mecanismos. Documento OMG 95.12.1

10. Servicio de Tiempos: provee relojes sincronizados a todos los objetos dondequiera que estén. Documento OMG 95.11.8

 
COMPONENTE 4:  

11. Servicio de Licencia: controla y dirige la remuneración de los proveedores por servicios prestados. Documento OMG 95.3.7

12. Servicio de Query: soporta operaciones en conjuntos de objetos que tiene una especificación declarativa basada en predicados, su resultado puede ser también un conjunto de objetos. Documento OMG 95.1.1

13. Servicio de la Propiedad: soporta la asociación de valores arbitrarios (equivalentes a los atributos dinámicos) a los objetos. Documento OMG 96.6.1

 
COMPONENTE 5:

14. Servicio de Cambio de Dirección: soporta la identificación y la evolución consistente de las configuraciones de objetos.

15. Servicio de Colección de Objetos: soporta la creación y manipulación de colecciones de objetos. Documento OMG 96.5.5

16. Servicio de Intercambio de Datos: soporta el intercambio de datos entre objetos.

17. Servicio de Replicación: tiene por objetivo la replicación explícita de objetos en entornos distribuidos y el posterior manejo de las replicas manteniéndolas consistentes.

18. Servicio de Comerciantes: trata de encontrar los objetos apropiados para compensar las necesidades del cliente. Documento OMG 96.5.6

 
2.2.3. Common Facilities de Corba

Así como los servicios de CORBA proveen de servicios a los objetos, las "facilities" de CORBA proveen servicios para las aplicaciones. Las Corba Facilities tienen dos componentes principales, las horizontal facilities y las vertical facilities. Las primeras de carácter más general pueden ser potencialmente usadas por cualquier negocio, están más orientadas al usuario. Las verticales, están más especializadas en cada tipo de industria y de aplicación.

CORBA Horizontal Facilities: La primera facilidad horizontal especificada fue Compound Document Facilitie ( integrada por Compound Interchange y Compound Presentation ) en octubre de 1994.

OMG las ha agrupado en cuatro áreas:

1. User Interface Facilities: incluyen Compound Presentation, Desktop Management, Scripting, Rendering Management, y User Support Facilities.

2. Information Managemnet Facilities: grupo formado por las facilidades Compound Interchange, Codificación y Representación de Datos, Intercambio de Datos, Cambio de Información, Modelado de la Información, Almacenamiento y Recuperación de la Información y Operaciones de Tiempo.

3. System Management Facilities: en este tercer agrupamiento encontramos facilidades como Collection Management, Consistency, Customization, Data Collection, Event Management, Instance Management, Instrumentation, policy Management, Process Launch, Quality of Service Management, Schedulling Management y por último Security Facilitie.

4. Taks Management Facilities: incluye agentes, Automatización, Control de Regals, y Facilidades de Flujo de Trabajo.

CORBA Vertical Facilities: En este grupo encontramos las facilidades más moldeadas a cada actividad concreta.

Forman el grupo las facilidades Accounting, Application Development, Computer Integrated Manufacturing (CIM), Currency, Distributed Simulation, Imagery, Information Superhighways, Internationalitazion, Mapping, Oil and Gas Exploration and Production, Security y Telecommunication.

 2.4. INTEROPERABILIDAD

 La interoperabilidad se define como la habilidad de realizar invocaciones entre clientes y objetos servidores independientemente de si se encuentran en el mismo o distintos ORB's, de forma que el usuario perciba todas las peticiones como llamadas locales, es decir, haciendo transparente el envío de peticiones y respuestas.

La función de la arquitectura de interoperabilidad en ORB es proveer de interoperabilidad directa ORB-ORB e interoperabilidad basada en puentes.
La primera de ellas, es posible cuando dos ORB´s residen en el mismo dominio, por lo que entienden las mismas referencias a ORB's el mismo sistema de tipos IDL, y posiblemente la misma información de seguridad.

La interoperabilidad basada en puentes es necesaria cuando dos ORB's pertenecientes a diferentes dominios necesitan comunicarse. El cometido de los puentes es transformar la información especifica de ORB de un dominio a otro. Cuando una invocación tiene lugar en los limites de un dominio un mecanismo de mapeo, o puente, transforma los elementos importantes de la invocación al formato adecuado para el otro lado del puente. Existen dos métodos para hacer esto:

            - mediated bridging: Los elementos de la interacción relevantes dominio origen son transferidos al límite de cada dominio, entre el formato interno de dicho dominio y un formato común intermedio.

            -Immediated bridging: Los elementos de la interacción relevantes al dominio son transformados al límite de cada dominio, directamente del formato interno del dominio origen al formato interno del dominio destino. Este mecanismo es optimo, si lo comparamos con el mediated bidginig, en los casos en los que no hay que pasar por varios puentes, aunque se pierde flexibilidad.

La arquitectura general de la interoperabilidad de ORB está basada en el GIOP ( General Inter-ORB Protocol) que especifica la sintaxis de transferencia y un conjunto de formatos de mensajes estándar para interoperaciones ORB sobre transportes orientados a conexión. GIOP está diseñado de forma que sea simple y fácil de implementar, permitiendo una razonable escalabilidad.

Además , la arquitectura de interoperabilidad de ORB provee de otros protocolos construidos para actuar en situaciones especiales en las que ciertas infraestructuras de sistemas operativos distribuidos todavía en uso. Son los llamados Enviroment-Specific Inter-ORB Protocols (ESIOPs) .

El primer ESIOP utiliza el Distributed Computing Enviroment (DCE), por lo que es llamado DCE Common Inter-ORB Protocol (DCE-CIOP). Este ESIOP puede ser usado por ORB en entornos donde DCE está todavía instalado, permite a ORB utilizar funciones implementadas por DCE, lo que facilita la integración entre CORBA y DCE.

Esta arquitectura de interoperabilidad de ORB también especifica un estándar para los formatos de las referencias a objeto, al que se llama Interoperable Object Reference (IOR). El IOR no es más que una estructura de datos que guarda información necesaria para localizar y establecer comunicación con un objeto sobre uno o más protocolos.

 
2.5. LENGUAJES DE PROGRAMACIÓN ASOCIADORES

Como IDL es un lenguaje "declarativo" no puede ser usado directamente para implementar aplicaciones distribuidas. Se necesitan por tanto otros lenguajes de programación que hagan corresponder las implementaciones IDL con las facilidades dadas por lenguajes de programación habituales.

Actualmente la OMG ha estándarizado varios "lenguajes de programación asociadores" para los lenguajes de programación C, C++, Smalltalk, Ada95 y está en proceso de construcción los correspondientes a UNIX Bourne Shell, COBOL o Java.

Todos los, lenguajes asociadores tienen la misma estructura, deben definir:

    - todos los tipo básicos de IDL
    - todos los tipos constructed de IDL
    - referencias a constantes definidas en IDL
    - referencias a objetos definidas en IDL
    - invocaciones a operaciones, incluyendo parámetros de entrada y salida
    - excepciones
    - accesos a atributos
    - identificaciones para las operaciones definidas por el ORB, como DII, OA ...
 

/tabla/

 En la tabla se nos muestra la correspondencia ente los tipos IDL y los tipos en C++. El resto puede resumirse en:

    - cada modulo se asocia a una clase
    - cada interface con su modulo es asociada a una clase nested de C++
    - cada operación es asociada en C++ a un método con sus parámetros
    - cada atributo de lectura/escritura es asociado en C++ a un par de get/set métodos

  En lenguajes de programación orientados a objeto como C++, Java o Smalltalk los objetos CORBA son implementados como objetos de los lenguajes de programación. En C, se implementan como tipos de datos abstractos.
Una implementación típica consiste en una estructura que guarda el estado del objeto y algunas funciones implementadas en C correspondientes a las operaciones IDL soportadas por el objeto para manipular el estado.