Introducción
OMG
OMA
CORBA
Ejemplos de programación en CORBA
Alternativas a CORBA

Una característica importante de las grandes redes de ordenadores actuales, como Internet, es su  heterogeneidad. La heterogeneidad y la estandarización nos permiten, idealmente, utilizar la mejor combinación de hardware y software, aumentando el rendimiento de las aplicaciones sin afectar a su interoperabilidad, consiguiendo un sistema coherente, eficiente y altamente operativo. Pero la práctica demuestra que cumplir los requerimientos de seguridad, eficiencia, flexibilidad y extensibilidad, en sistemas distribuidos heterogéneos es, desafortunadamente, raramente fácil.
 
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.

OMG

Figura 1: Modelo de referencia de OMA.

 

La especificación CORBA detalla las interfaces y características del componente ORB de la OMA. La última actualización hasta el momento es CORBA 2.2. En la Figura 2, se muestra la arquitectura CORBA y como se relacionan sus distintos componentes.


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 ORB

Misión del ORB

Una parte fundamental de la arquitectura CORBA es el ORB, componente software cuyo fin es facilitar la comunicación entre objetos. El ORB se encarga de enviar las peticiones a los objetos y retornar las respuestas a los clientes que invocan las peticiones.

• Ubicación de los objetos. El cliente no sabe dónde se encuentra el objeto destino. Puede residir en un proceso diferente en otra máquina a través de la red, o dentro del mismo proceso
• Implementación de los objetos. El cliente no sabe cómo esta implementado el objeto remoto, en qué lenguaje de programación o de scripts está escrito, o el sistema operativo y el hardware, sobre el que se ejecuta.
• Estado de ejecución del objeto. Cuando el cliente lanza una petición sobre un objeto remoto, no necesita saber si el objeto está en ese momento en ejecución, y listo para aceptar peticiones. El ORB de forma transparente inicializa el objeto en caso de ser necesario, antes de enviarle la petición
• Mecanismos de comunicación de los objetos. El cliente no sabe qué mecanismos de comunicación (por ejemplo, TCP/IP, memoria compartida, llamada a método local) utiliza el ORB para enviar la petición al objeto y retorna la respuesta al cliente.

Cuando se crea un objeto CORBA también se crea una referencia para él. Cuando es utilizada por un cliente, la referencia siempre -durante toda la vida del objeto-, se refiere a dicho objeto para la que fue creada. En otras palabras, la referencia a un objeto siempre hace referencia a un único objeto. Las referencias a objetos son inmutables y opacas, de esta forma un cliente no puede manipular una referencia y modificarla. Las referencias a objetos pueden tener un formato estándar o propietario. Los clientes pueden obtener las referencias a objetos de muy diversas formas:

• En la creación de objetos. El cliente puede crear un nuevo objeto y conseguir así una referencia al objeto.
• A través del servicio de directorio. El cliente puede invocar a un servicio de búsqueda de cualquier tipo, con el fin de obtener referencias a objetos. Estos servicios no crean nuevos objetos, sino que almacenan referencias a objetos e información asociada (por ejemplo, nombres y propiedades) para los objetos existentes, y los proporcionan previa solicitud.
• Convirtiendo la referencia al objeto en una cadena y recuperándola. Una aplicación puede solicitar al ORB que convierta una referencia a un objeto en una cadena, y esta cadena almacenarla en un fichero o base de datos. Más tarde, la cadena puede ser recuperada y transformada nuevamente en una referencia a un objeto por el ORB.

Marshaling

Después de que el componente de una aplicación haya obtenido la referencia a un objeto, el componente puede invocar métodos en dicho objeto. Generalmente, dichos métodos tienen ciertos parámetros como entrada, y retornan otros parámetros como salida. El ORB es el encargado de clasificar esos parámetros; es decir, trasformar los parámetros procedentes del componente que invoca los métodos remotos, a un formato estándar, denominado formato de red y después al formato entendible por el componente que tiene dichos métodos. El ORB se encarga así mismo de desclasificar los parámetros de salida retornados por el método, convirtiéndolos de la representación de la red al formato que entiende este componente invocador. 

El proceso total de clasificación tiene lugar sin intervención alguna por parte del programador. Una aplicación cliente simplemente invoca el método remoto deseado, que para él tiene la apariencia de un método local, y el resultado es retornado o se lanza una excepción, de nuevo, como si se tratase de un método local.

Independencia de la plataforma

El registro de interfaz

Distribución de los objetos

Para un cliente CORBA, una llamada a procedimiento remoto se ve exactamente igual a la llamada a un método local. Así, la naturaleza distribuida de los objetos CORBA es transparente a los usuarios de dichos objetos; los clientes no son conscientes de que están realmente tratando con objetos distribuidos en una red.

 Debido a que la distribución de objetos supone una mayor probabilidad de fallo (caída de un servidor, caída de un segmento o enlace de la red…), CORBA debe ofrecer mecanismos para manejar dichas posibles situaciones. Para ello, proporciona un conjunto de excepciones, que pueden ser lanzadas por cualquier método remoto.

Referencias a objetos

En una aplicación distribuida, hay dos métodos posibles para que el componente de una aplicación obtenga el acceso a un objeto en otro proceso.

Un método es conocido como paso por referencia. Mediante este mecanismo cuando un proceso invoca un método sobre un objeto en un proceso remoto, el método es ejecutado por dicho proceso remoto pues el objeto existe en la memoria y espacio de procesos de dicho proceso. El pasar un objeto por referencia significa que un proceso admite la visibilidad de uno de sus objetos (a través de las referencias a esos objetos) en otro proceso mientras conserva la propiedad de ese objeto.
 
El segundo método para pasar un objeto entre componentes de una aplicación se conoce como paso por valor. Mediante este mecanismo, el actual estado del objeto (así como los valores de sus atributos) es pasado al componente que lo solicita. Cuando los métodos de un objeto son invocados por un proceso remoto, son ejecutados por dicho proceso en vez de por aquel en el que reside el objeto original. Es más, puesto que el objeto es pasado por valor, el estado del objeto original no cambia; sólo la copia es modificada.

Los adaptadores de objeto

La especificación CORBA es independiente de los protocolos de transporte; el estándar CORBA especifica el conocido como GIOP (General Inter-ORB Protocol). GIOP especifica, a alto nivel, un estándar para la comunicación entre varios componentes CORBA ORBs.

Ejemplo de programación en CORBA

En este apartado mostramos un sencillo ejemplo del desarrollo de una  aplicación en CORBA, en concreto en Orbix 2.2 de IONA Technologies PLC sobre el sistema operativo Unix Solaris 5.5.1 de Sun Microsystems. Se trata de un contador, cuyo valor podrá ser reseteado, incrementado, decrementado y consultado por los clientes ejecutándose en la misma u otras máquinas. Para información sobre IONA, puede acudir a su Sitio Web, en http://www.iona.com/.

Interfaz IDL

El código de la interfaz IDL de un contador, que sería común a la implementación de CORBA de cualquier vendedor, es el siguiente:

// Interfaz IDL a un contador.

interface Contador

{ 

  // Devuelve el valor actual del contador

  long daValor ();

  // Pone el contador al valor especificado

  oneway void ponValor (in long valor);

  // Incrementa el valor del contador en la cantidad especificada

  // y devuelve el valor resultante

  long incrementarValor (in short cantidad);

  // Decrementa el valor del contador en la cantidad especificada

  // y devuelve el valor resultante

  long decrementarValor (in short cantidad);

};

 Por defecto todos los métodos son bloqueantes, es decir, cuando un objeto llama a un método en un objeto remoto, el objeto que invoca el método espera (se bloquea), hasta que el método se ejecute y retorne. Cuando el objeto remoto termina de procesar la invocación del método, devuelve el valor resultante, con lo cual podrá continuar con el resto de sus operaciones. Para indicar que la operación sea no bloqueante, se debe especificar la claúsula oneway antes de la definición de éste.

Como puede observar, los parámetros en un método pueden ser declarados como in -indica que se trata de un parámetro de entrada-, out -indica que es un parámetro de salida-, o inout -indica que el parámetro se utiliza como entrada y salida del método-.
 
Esta interfaz será compilada utilizando el compilador IDL, generando tres ficheros:

• Un fichero de cabecera que deberá ser incluido en la implementación del contador y en sus clientes.
• Un fichero fuente a ser compilado e incluido en la implementación del contador.
• Un fichero fuente a ser compilado e incluido en los clientes del contador.

Servidor

Fichero ContadorSC.h

#ifndef ContadorSC_h

#define ContadorSC_h

// Fichero de cabecera generado por el compilador IDL a partir de Contador.idl

#include <Contador.hh>

 

class Contador_i

{

private:
 

  // Valor actual del contador

  CORBA::Long _valor;
 

public:
 

 // Constructor

 Contador_i(CORBA::Long valor = 0);

 // Operaciones ofrecidas por el contador

  virtual void ponValor

 (CORBA::Long valor, CORBA::Environment    &IT_env=CORBA::default_environment);

  virtual CORBA::Long daValor

  (CORBA::Environment &IT_env=CORBA::default_environment);

  virtual CORBA::Long incrementarValor

 (CORBA::Short cantidad,

  CORBA::Environment  &IT_env=CORBA::default_environment);

  virtual CORBA::Long

  decrementarValor

  (CORBA::Short cantidad,

  CORBA::Environment &IT_env=CORBA::default_environment);

};

 

// Macro que asocia la interfaz Contador con // su implementación en C++ Contador_i

DEF_TIE(Contador, Contador_i)

 

#endif

Fichero ContadorSC.cc

#include <ContadorSC.h>

 

Contador_i::Contador_i (long int valor)

{

  _valor = valor;

}

 

void Contador_i::ponValor

(long int valor, CORBA::Environment &se)

{

  _valor = valor;

}

 

long int Contador_i::daValor CORBA::Environment &se)

{

  CORBA::Long valor = _valor;

  return valor;

}

 

long int Contador_i::incrementarValor (short int cantidad,CORBA::Environment& se)

{

  _valor = _valor + cantidad;

  return _valor;

}

 

long int Contador_i::decrementarValor

(short int cantidad,CORBA::Environment& se)

{

  _valor = _valor - cantidad;

  return _valor;

}

Fichero main.cc

#include <ContadorSC.h>
 

main( )

{
 

  // Se crea una instancia del contador

  Contador_var Servidor =

  new  TIE_Contador(Contador_i)(new  Contador_i);
 

  // Se entra en el bucle de eventos 

  // CORBA

  try

  {    

    CORBA::Orbix.impl_is_ready ("contador",

    CORBA::Orbix.INFINITE_TIMEOUT);

  }

  catch (const CORBA::SystemException& codigo)

  {

    cerr << "Excepcion CORBA al registrar el servidor: " << codigo;

  }

}

Cliente

Fichero ContadorCC.cc

// Fichero de cabecera generado por el compilador IDL a partir de Contador.idl

include <Contador.hh> 

int main()

{      

  // Referencia al objeto contador

  Contador_var MiContador;

  int operacion = 0;

  short int cantidad = 0;

 

try

  {

   // Se obtiene la referencia al objeto    

    MiContador =   

    Contador::_bind(":contador");

  }

catch (const CORBA::SystemException& codigo)

  {

    cerr << "Ha fallado el intento de comunicación con el objeto: "

    << codigo << endl;

    return 0;

  }

 

  while (operacion != 5)

  {

    cout << "Comandos posibles:" << endl;

    cout << "1. Resetear el contador" << endl;

    cout << "2. Incrementar el contador" << endl;

    cout << "3. Decrementar el contador" << endl;

    cout << "4. Visualizar el valor del contador" << endl;

    cout << "5. Abandonar el programa" << endl;

    cout << "Seleccion: ";

    cin >> operacion;

 

    switch (operacion)

    {

      case 1:

        MiContador->ponValor(0);

        break;

      case 2:

         cout << "Valor a incrementar:" << endl;

         cin >> cantidad;

         MiContador->

 incrementarValor(cantidad); 

          break;

      case 3:

        cout << "Valor a decrementar:" << endl;

        cin >> cantidad;

        MiContador->

 decrementarValor(cantidad);

        break;

      case 4:

        cout << "Valor del contador: " << MiContador->daValor() << endl;

        break;

      case 5:

        return 1;

      default:

        break;

    }

  }

}; 

Alternativas a CORBA

La eficiencia de las aplicaciones CORBA es, por lo general, menor que la de implementaciones a bajo nivel utilizando sockets en C/C++, ya que los ORBs incurren en una significante carga debido a la cantidad de datos copiados, la clasificación y desclasificación de argumentos, y la sobrecarga de demultiplexación de conexiones. No obstante, esta solución es compleja, no portable y sujeta a muchos errores.