Funcionamiento de la arquitectura CORBA

Hace unas semanas estuvimos viendo cuáles eran los componentes básicos de CORBA, así que hoy vamos a complementar ese post detallando cómo sería el funcionamiento típico de dicha arquitectura. Recordemos que CORBA es un estándar que permite la intercomunicación entre componentes de diferentes lenguajes y orígenes. Se trata de un diseño creado para facilitar la comunicación y la interoperabilidad entre objetos distribuidos en un entorno de red. 

 

 

Eso sí, esta arquitectura nacida en 1991 actualmente se encuentra en claro retroceso en las aplicaciones modernas, ya que en los nuevos proyectos se suelen implementar webservices para establecer las comunicaciones entre funcionalidades de diferentes sistemas o máquinas. En cualquier caso, nunca viene mal saber cómo funciona CORBA, ya que es posible que nos encontremos con esta estructura en algún momento de nuestra vida laboral. 

 

Funcionamiento de la arquitectura CORBA

A continuación, vamos a ir describiendo cuáles son los puntos fundamentales que hay que tener en cuenta para habilitar la intercomunicación entre componentes dentro de una arquitectura CORBA.

1º) Objetos locales: Todos los componentes CORBA son objetos, cada cual tendrá una interfaz y una identidad única. Además, cada uno de los objetos se podrá implementar en un lenguaje de programación distinto y ejecutarse sobre cualquier sistema operativo.

 

2º) Relación Cliente - Servidor: El servidor crea objetos remotos, hace accesibles referencias a esos objetos remotos y espera a que los clientes invoquen a estos objetos o a sus métodos. Por otro lado, el cliente obtiene una referencia de uno o más objetos remotos en el servidor e invoca a sus métodos.

 

3º) Invocación desde el Cliente: La manera de realizar la invocación por parte del cliente es usando Stub IDL, una interfaz de comunicación con el servidor generada a partir del lenguaje IDL. Mediante invocación dinámica se accederá al objeto del servidor y, al mismo tiempo, se gestionarán las excepciones producidas por su llamada.

 

4º) Interfaz de comunicación: Para habilitar toda la comunicación se necesitan tres cosas: una referencia del objeto remoto IOR (Interoperable Object References), el tipo del objeto y el nombre de la operación que desea invocar. A partir de la descripción de las interfaces IDL, un ORB (Object Request Broker) genera automáticamente código en el lenguaje seleccionado para realizar la integración de las aplicaciones distribuidas. Hay que puntualizar que en el IDL sólo aparece la descripción de la interfaz, de manera que no encontraremos ningún detalle relacionado con todas las tareas complejas de los lenguajes de programación, como control de flujo, gestión de memoria, composición funcional, etc...

 

 

5º) Envío de la petición: A partir de la petición del cliente, el ORB encuentra el código de la implementación apropiada, transmitiendo los parámetros y el control a la implementación de la interfaz a través del Skeleton IDL. En caso de errores, informa de excepciones en el proceso (como, por ejemplo, referencias IOR o IDL no válidas).

 

6º) Recepción de la petición: mediante llamadas desde el ORB hacia la implementación de la interfaz, se recibe la invocación de uno de los métodos del objeto. Esta llamada puede venir de un cliente que haya utilizado los Stubs IDL. Los esqueletos son específicos de cada interfaz y del adaptador de objetos que exista en la implementación de CORBA. Una vez completada la invocación, el control y los valores de retorno son devueltos al cliente.

 

7º) Adaptador de Objetos (OA): El Adaptador de Objetos (Object Adapter) actúa como un puente entre los objetos locales de cada máquina y el ORB (Object Request Broker) de CORBA. Su función principal es adaptar los objetos locales para que puedan ser invocados y gestionados por el entorno distribuido CORBA. Para procesar la petición recibida, se puede hacer uso de los servicios proporcionados tanto por el OA como por el ORB. Existe una amplía variedad de OA disponibles, así que para tomar la decisión de seleccionar uno en concreto se deberá tener en cuenta la clase de servicios requeridos por la implementación de la interfaz.

8º) Protocolo de Comunicación: el protocolo de comunicación utilizado para la intercomunicación entre un ORB y otro es el protocolo GIOP (General Inter-ORB Protocol). Disponemos de varias implementaciones de dicho protocolo, siendo la más utilizada la implementación IIOP (Internet Inter-ORB Protocol).

 

Arquitectura CORBA con protocolo IIOP

 

Flujo de un proceso con arquitectura CORBA

Para que queden más claros los puntos mencionados anteriormente, vamos a describir cuál sería el flujo típico de la creación de una interfaz en arquitectura CORBA.

1. IDL (Interface Definition Language): El proceso comienza con la definición de la interfaz de los objetos distribuidos utilizando la IDL. La IDL describe la estructura y los métodos de los objetos de manera independiente del lenguaje de programación. Se utiliza para especificar cómo se comunican y se invocan los objetos.

    

2. Compilación de la IDL: Una vez que la interfaz está definida en IDL, se compila utilizando herramientas específicas del lenguaje de programación para generar Stubs y Skeletons. Los Stubs son utilizados por el cliente y los Skeletons por el servidor para facilitar la comunicación.

    

3. Objetos Distribuidos: Los objetos distribuidos son entidades de software que encapsulan datos y operaciones. Estos objetos pueden residir en máquinas diferentes en una red y se comunican entre sí mediante invocaciones de métodos.

    

4. ORB (Object Request Broker): El ORB actúa como intermediario entre los objetos distribuidos. Se encarga de la localización de objetos, la invocación de métodos remotos y la gestión de la comunicación entre los objetos a través de la red.

    

5. Localización de Objetos: Cuando un objeto cliente necesita interactuar con un objeto remoto, utiliza el servicio de localización del ORB para encontrar la referencia al objeto remoto en la red.

    

   

    

6. Invocación de Métodos: El cliente utiliza el Stub generado durante la compilación de la IDL para realizar la invocación de métodos en el objeto remoto. El Stub actúa como una interfaz en el lado del cliente y traduce las invocaciones de métodos en llamadas al ORB.

    

7. Transmisión de la Solicitud: El ORB recibe la solicitud del cliente y se encarga de transmitirla al objeto remoto a través de la red. Esto implica convertir la solicitud en un formato de mensajes que pueda ser transmitido a través del protocolo de comunicación GIOP. Aunque hay varias implementaciones disponibles de este protocolo, la más comúnmente utilizada es la IIOP (Internet Inter-ORB Protocol).

    

8. Procesamiento en el Servidor: En el extremo del servidor, el ORB del servidor recibe la solicitud, utiliza el Skeleton generado durante la compilación de la IDL para deserializar la solicitud y luego invoca el método correspondiente en el objeto remoto.

    

9. Retorno de Resultados: El resultado de la operación, junto con cualquier dato de salida, se envía de vuelta al cliente a través del mismo proceso.

    

10. Destrucción de Objetos: Cuando un objeto ya no es necesario, el ORB se encarga de gestionar su destrucción y liberar recursos asociados.

En líneas generales, los puntos anteriores describen con claridad cuál es la forma de trabajo en proyectos implementados con arquitectura CORBA. Obviamente, se trata de una visión global inicial, a partir de aquí tendrías que ir profundizando por ti mismo si vas a trabajar con este tipo de arquitectura. En cualquier caso, cuando tomamos contacto con una nueva tecnología, creo que siempre es importante empezar con una visión general de la misma, eso suele evitar que posteriormente nos perdamos en los detalles de los procesos. Como ya sabéis, aquí abajo podéis dejarme cualquier duda que os vaya surgiendo.

Saludos.