Arquitectura de Comunicación CORBA

Vamos a dedicar el post de hoy a dar una visión global de la arquitectura CORBA (Common Object Request Broker Architecture). Aunque se trata de un estándar que ya no suele emplearse en nuevas aplicaciones, hemos de tener en cuenta que todavía nos lo podemos encontrar con en aplicaciones antiguas. Recordad que, como desarrolladores todoterreno, en vuestra vida laboral vais a trabajar tanto con implementación de nuevos proyectos como con mantenimiento de aplicaciones ya existentes. Por tanto, lo ideal es que estéis preparados para adaptaros a cualquier entorno.

 

 

Estándar de comunicación CORBA

En primer lugar, ¿qué es CORBA? Básicamente, CORBA es un estándar definido por el grupo OMG (Object Management Group) que nos va a permitir trabajar con un conjunto de componentes de software escritos en distintos lenguajes y ejecutados en diferentes sistemas. Dicho de otro modo, simplifica la comunicación y la interoperabilidad entre objetos distribuidos en una red con entornos no homogéneos. Nos permitiría conectar, por ejemplo, un módulo desarrollado en Java con otro módulo implementado en C++ mediante el empleo de una forma estandarizada de intercomunicación.

 

Las versiones más relevantes de CORBA han sido:

• CORBA 1: lanzado en 1991
• CORBA 2: lanzado en 1995
• CORBA 3: lanzado en 2003

Mediante el estándar CORBA podemos distribuir objetos a través de las redes de modo que las operaciones de dichos objetos (esto es, sus funciones lógicas concretas) puedan ser invocadas de forma remota. Los objetos CORBA se describen en sintaxis IDL (Interface Definition Language).

Como resulta obvio por la definición inicial, CORBA no está atado a ningún lenguaje concreto. De hecho, cualquier lenguaje podría hacer uso de un enlace CORBA para invocar y ejecutar objetos CORBA. Eso sí, hay que puntualizar que esta arquitectura trabaja más eficientemente con lenguajes orientandos a objetos (como Java o C++). 

Componentes básicos de la arquitectura CORBA

A continuación, vamos a hacer un repaso de los que podemos considerar como componentes básicos precisados para montar una aplicación con arquitectura basada en el estándar CORBA.

1º) Gestor ORB (Object Request Broker): El componente central de la arquitectura CORBA es el ORB. Actúa como un intermediario entre los objetos distribuidos, permitiéndoles comunicarse y realizar operaciones en otros objetos a través de la red. Los ORBs gestionan la localización, invocación y destrucción de objetos distribuidos.

• Se trata de un gestor Middleware encargado de la comunicación, ordenación y desordenación de parámetros, de modo que sea transparente para las aplicaciones cliente y servidor.

• Se encarga de enviar las peticiones a los objetos y retornar las respuestas a los clientes que las invocan utilizando un proceso de serialización (marshalling / unmarshalling).

 

2º) Protocolo GIOP (General Inter-ORB Protocol): La comunicación se realiza mediante el protocolo GIOP. En realidad, CORBA puede utilizar diferentes implementaciones de dicho protocolo. 

• Implementación IIOP (Internet Inter-ORB Protocol): es una de las implementaciones más utilizadas del protocolo GIOP. Esta implementación facilita la interacción en Red y permite la comunicación entre ORBs utilizando el protocolo TCP/IP a través de internet.

3º) Objetos Distribuidos: Son entidades de software que encapsulan datos y operaciones (esto es, funciones lógicas). Estos objetos pueden residir en máquinas diferentes en una red y pueden invocar operaciones entre ellos.

4º) Interoperabilidad: permite la construcción de sistemas distribuidos heterogéneos, ya que los objetos pueden estar implementados en diferentes lenguajes de programación y ejecutarse en plataformas distintas. Esto se logra mediante la utilización de la IDL y los servicios proporcionados por los ORBs.

5º) Servidor CORBA: Crea los objetos CORBA y los inicializa en un ORB concreto. El servidor coloca las referencias de dichos objetos dentro de un servicio de denominación, de manera que cualquier cliente pueda tener acceso a ellos.

6º) Servicio de Nombres (Naming Service): Servicio de administración de nombres para localizar objetos distribuidos. Se trata del servicio de denominación que mantiene activas las referencias concretas a los diferentes objetos CORBA.

Aparte de este servicio, en CORBA disponemos también de otros servicios relavantes:

• Servicio de tiempo para la sincronización
• Servicio de seguridad de los objetos distribuidos
• Servicio de transacción
• Servicio de persistencia

7º) Nodo CORBA-Request: Se trata del nodo que actúa como cliente CORBA.

8º) Lenguaje IDL (Interface Definition Language): CORBA utiliza un lenguaje independiente de plataforma llamado IDL para describir la interfaz de los objetos distribuidos. Este IDL define la estructura y los métodos de un objeto de manera que sea independiente del lenguaje de programación utilizado. Luego, se generan stubs y skeletons en el lenguaje de programación específico a partir de esta descripción.

• Sirve para definir las interfaces entre los componentes de una aplicación y soporta la interoperabilidad de la tecnología.

• Es importante ser consciente de que se definen interfaces, no implementaciones.

• Si queremos entrar más en detalle, podemos decir que hay dos tipos IDL

  • Stub IDL para el Cliente: es la interfaz estática a los servicios declarados en las interfaces IDL. Gracias a ella, para el cliente todas las invocaciones enviadas parecen locales.

  • Skeleton IDL para el Servidor: es el representante estático del cliente en el servidor. Con ella, para el servidor todas las llamadas recibidas parecen locales.

👉 Ejemplo de código IDL

module UniversoApp { interface Universo { string crearUniverso(); oneway void shutdown(); } }

En líneas generales, con lo mencionado hasta ahora ya tendríamos suficiente para tener una visión general de la estructura básica de la arquitectura CORBA. Aún en la época actual, este estándar se sigue utilizando en una notable variedad de aplicaciones, especialmente en entornos empresariales donde la interoperabilidad entre sistemas distribuidos es crucial. 

 

Sin embargo, muy importante, hay que tener en cuenta que ya no se trata de un estándar que se emplee en la construcción de nuevas aplicaciones. Como ya sabemos, el tiempo no perdona a ninguna herramienta informática y este estándar fue creado en 1991. Actualmente otras arquitecturas y tecnologías, como los webservices, han ido ocupando su lugar y, por tanto, en la misma medida el uso de CORBA se ha ido diluyendo poco a poco.

Saludos.