3.2.2 CORBA (Common Object Resource Broker Architecture) [OMG, 1991]).

CORBA es un middeware o marco de trabajo estndar y abierto de objetos distribuidos

que permite a los componentes en la red nter operar en un ambiente comn sin importar el
lenguaje de desarrollo, sistema operacional, tipo de red, etc.

En esta arquitectura, los mtodos de un objeto remoto pueden ser invocados de forma
transparente en un ambiente distribuido y heterogneo a travs de un ORB (Object Request
Broker).

Adems del objetivo bsico de ejecutar simplemente mtodos en objetos remotos, CORBA
adiciona un conjunto de servicios que amplan las potencialidades de stos objetos y
conforman una infraestructura slida para el desarrollo de aplicaciones crticas de negocio.

CORBA permite el desarrollo de software para entornos distribuidos heterogneos
separando la especificacin de las aplicaciones de su implementacin.


OMG.
(Object Management Group)
Conjunto de organizaciones que cooperan en la definicin de estndares para la
interoperabilidad en entornos heterogneos.
Fundado en 1989, en la actualidad lo componen ms de 700 empresas y otros organismos.
OMA.
(Object Management Architecture)
Arquitectura de referencia sobre cual se pueden definir aplicaciones distribuidas sobre un
entorno heterogneo. CORBA es la tecnologa asociada a esta arquitectura genrica.
Formalmente est dividida en una serie de modelos:
Modelo de Objetos
Modelo de Interaccin
...
Una aplicacin definida sobre OMA est compuesta por una serie de objetos distribuidos
que cooperan entre s. Estos objetos se clasifican en los siguientes grupos:




Servicios:
Proporcionan funciones elementales necesarias para cualquier tipo de entorno
distribuido, independientemente del entorno de aplicacin.
Los tipos de funciones proporcionados son cuestiones tales como la resolucin de
nombres, la notificacin asncrona de eventos o la creacin y migracin de objetos.
Concede un valor aadido sobre otras tecnologas (por ejemplo RMI).
Estn pensados para grandes sistemas.

Facilidades Comunes:
Proporcionan funciones, al igual que los servicios vlidos para varios dominios pero
ms complejos. Estn orientadas a usuarios finales (no al desarrollo de
aplicaciones).
Un ejemplo de este tipo de funciones es el DDCF (Distributed Document Component
Facility) formato de documentacin basado en OpenDoc.
(Tambin denominadas Facilidades Horizontales)

Interfaces de Dominio:
Proporcionan funciones complejas, al igual que las Facilidades, pero restringidas a
campos de aplicacin muy concretos. Por ejemplo, telecomunicaciones,
aplicaciones mdicas o financieras, etc.
Muchos grupos de inters (SIGs) trabajan sobre estas especificaciones.
(Tambin denominadas Facilidades Verticales)

Aplicaciones:
El resto de funciones requeridas por una aplicacin en concreto. Es el nico grupo
de objetos que OMG no define, pues est compuesto por los objetos propios de cada
caso concreto.
Estos son los objetos que un sistema concreto tiene que desarrollar. El resto
(servicios, facilidades) pueden venir dentro del entorno de desarrollo.

ORB:
(Object Request Broker)
Es el elemento central de la arquitectura. Proporciona las funcionalidades de
interconexin entre los objetos distribuidos (servicios, facilidades y objetos de
aplicacin) que forman una aplicacin.
Representa un bus de comunicacin entre objetos.

Para posibilitar la comunicacin entre dos objetos cualesquiera de una aplicacin se realiza
por medio del ORB. El escenario de aplicacin elemental es:



El ORB funciona como una capa middleware.
El ORB redirige las peticiones al objeto apropiado que proporciona el servicio solicitado.


El ORB acta como mediador de objetos heterogneos

IDL de CORBA.
(Interface Definition Language).
Es el lenguaje mediante el cual se describen los mtodos que un determinado objeto del
entorno proporciona al resto de elementos del mismo.

interface Cuenta
{
void ingresar(in long cantidad);
void retirar(in long cantidad);
long balance();
};

Language Mappings:
Traducen la definicin IDL a un lenguaje de programacin como:
C++,
Ada,
COBOL,
SmallTalk,
Java,
...


Este proceso genera dos fragmentos de cdigo denominados Stub y Skeleton que
representan el cdigo de cliente y servidor respectivamente.

El cdigo cliente generado en base a la definicin IDL (stub) contiene las llamadas para
realizar el proceso de marshalling.
Marshalling: Traduccin de los argumentos a un formato intermedio y pedir al ORB su
ejecucin.


El cdigo servidor generado en base a la definicin IDL (skeleton) contiene las llamadas
para realizar el proceso inverso (de-marshalling).
De-marshalling: Recuperar del ORB los parmetros con los que se invoc el mtodo,
construir la llamada y realizar la peticin.



Implementacin del Objeto:
La implementacin del objeto es invocada por los mtodos definidos en el Skeleton.
Por lo general se trata de una clase derivada del mismo.

class Cuenta_Impl: public Cuenta_Skel
{
void ingresar(CORBA::Long &cantidad)
{
dinero += cantidad;
}
};

COMPONENTES DE UN ORB.

La arquitectura completa de comunicaciones de CORBA es la siguiente:



Stub:
Cdigo cliente asociado al objeto remoto con el que se desea interactuar. Simula
para el cliente los mtodos del objeto remoto, asociando a cada uno de los mtodos
una serie de funciones que realizan la comunicacin con el objeto servidor.
Skeleton:
Cdigo servidor asociado al objeto. Representa el elemento anlogo al stub del
cliente. Se encarga de simular la peticin remota del cliente como una peticin local
a la implementacin real del objeto.

DII (Dynamic Invocation Interface).
Alternativa al uso de stubs estticos que permite que un cliente solicite peticiones a
servidores cuyos interfaces se desconocan en fase de compilacin.
DSI (Dynamic Skeleton Interface).
Alternativa dinmica al uso de skeletons estticos definidos en tiempo de
compilacin del objeto. Es usado por servidores que durante su ejecucin pueden
arrancar diferentes objetos que pueden ser desconocidos cuando se compil el
servidor.

ORB/Interface ORB:
Elemento encargado de (entre otras) las tareas asociadas a la interconexin entre
la computadora cliente y servidor, de forma independiente de las arquitecturas
hardware y Software.
Debido a que tanto clientes como servidores pueden requerir de ciertas
funcionalidades del ORB, ambos son capaces de acceder a las mismas por medio
de un interfaz.

Las dos principales responsabilidades del ORB son:
Localizacin de objetos: El cliente desconoce la computadora donde se encuentra
el objeto remoto.
Comunicacin entre cliente y servidor: De forma independiente de protocolos de
comunicacin o caractersticas de implementacin (lenguaje, sistema operativo, ...)

Adaptador de Objetos:
En este elemento se registran todos los objetos que sirven en un determinado nodo.
Es el encargado de mantener todas las referencias de los objetos que sirven en una
determinada computadora de forma que cuando llega una peticin a un mtodo es
capaz de redirigirla al cdigo del skeleton adecuado.

Existen dos tipos de Adaptadores de Objetos especificados por OMG:
BOA: (Basic Object Adapter).
POA: (Portable Object Adapter).

Las principales tareas del Adaptador de Objetos son:
Multiplexar a dos niveles (objeto y mtodo) las llamadas.
Mantiene informacin (almacenada en el Repositorio de Implementaciones) sobre
los objetos servidos, siendo el encargado de activarlos si al llegar una peticin no se
encontraban en ejecucin.
Permite diferente modos de activacin de los objetos:
Persistente: El estado del objeto se almacena entre varias ejecuciones.
Compartido: Todos los clientes comparten la instancia de objeto.
No-compartido: Cada cliente accede a una instancia diferente del objeto.
Por-mtodo: Cada mtodo solicitado es servido por una instancia de objeto
diferente.
Genera las referencias de los objetos dentro del entorno. Esta referencia es nica
para todos los objetos.



COMUNICACIN VA CORBA.
Pasos de una comunicacin:
1- El cliente invoca el mtodo asociado en el stub que realiza el proceso de marshalling.
(Stub cliente)
2- El stub solicita del ORB la transmisin de la peticin hacia el objeto servidor. (ORB cliente)
3- El ORB del servidor toma la peticin y la transmite el Adaptador de Objetos asociado, por
lo general slo hay uno. (ORB servidor).
4- El Adaptador de Objetos resuelve cul es el objeto invocado, y dentro de dicho objeto
cul es el mtodo solicitado (Adaptador de Objetos).
5- El skeleton del servidor realiza el proceso de de-marshalling de los argumentos e invoca
a la implementacin del objeto. (Skeleton servidor).
6- La implementacin del objeto se ejecuta y los resultados y/o parmetros de salida se
retornan al skeleton. (Implementacin del objeto).
7- El proceso de retorno de los resultados es anlogo.




IMPLEMENTACIN DE UN ORB.
El ORB representa a nivel lgico el bus de objetos que comparten tanto clientes como
servidores. A nivel de prctico puede estar implementado como:
Residente cliente/servidor: Cdigo que tanto clientes como objetos tiene que
enlazar.
Demonio del sistema: Un servicio del sistema encargado de centralizar las
peticiones.
Interno al sistema: Integrado dentro del SO.
Librera: Usado cuando tanto clientes como servidores residen dentro del mismo
espacio de memoria.

LOCALIZACIN DE OBJETOS.
Los objetos de servicio de una aplicacin CORBA se encuentran identificados por
medio de una referencia nica (Identificador de Objeto).
Esta referencia es generada al activar un objeto en el Adaptador de Objetos.
Por medio de esta referencia el ORB es capaz de localizar la computadora y el
Adaptador de Objetos donde se encuentra, y ste ltimo es capaz de identificar el
objeto concreto dentro del Adaptador.

El ORB proporciona mecanismos para transformar a cadena de caracteres y de cadena de
caracteres a dicha referencia:
object_to_string, string_to_object
Ejemplo:
IOR:010000000f00000049444c3a4375656e74613a312e300000020000000000000030000
00001010000160000007175696e6f2e64617473692e66692e75706d2e65730041040c000
000424f418a640965000009f4030100000024000000010000000100000001000000140000
000100000001000100000000000901010000000000

Una IOR es una cadena de caracteres que contiene codificada la informacin
siguiente:




objeto la utiliza el servidor de objetos para localizar el objeto internamente.

Una IOR es una cadena de caracteres parecida a esta:
IOR:000000000000000d49444c3a677269643a312e3000000
00000000001000000000000004c0001000000000015756c74
72612e6475626c696e2e696f6e612e6965000009630000002
83a5c756c7472612e6475626c696e2e696f6e612e69653a67
7269643a303a3a49523a67726964003a

La representacin consiste en un prefijo con los caracteres IOR: seguido por una
secuencia hexadecimal de caracteres numricos, cada carcter representa 4 bits de datos
binarios en la IOR.


IMPLEMENTACIN DEL SERVIDOR.
La implementacin del objeto se disea como una subclase de la clase generada por el
compilador (el skeleton) de IDL en base a la definicin.
Si el lenguaje usado para la implementacin no soporta objetos el mecanismo es diferente.


Tareas Tpicas de un Servidor.
El servidor debe realizar las siguientes tareas:

Inicializar el ORB (obtiene el interfaz con el ORB).
CORBA::ORB_init
Obtener la referencia del Adaptador de objetos.
orb->BOA_init
Crear un un objeto (de la clase Cuenta_impl).
new Cuenta_impl()
Activar el objeto.
boa->impl_is_ready(...)
Iniciar el bucle de servicio.
orb->run()

Tareas Tpicas de un Cliente.

El cliente debe realizar las siguientes tareas:
Inicializar el ORB (obtiene el interfaz con el ORB).
CORBA::ORB_init
Obtener la referencia del Adaptador de objetos.
orb->BOA_init
Obtener la referencia al objeto (desde un string).
orb->string_to_object(...)
Cambiar la clase del objeto obtenido (down-casting).
Cuenta::_narrow(obj)
Realizar las llamadas al objeto.
cc->...

Servicios CORBA.
Conjunto de objetos o grupos de objetos, que proporcionan una serie de funcionalidades
elementales. Estos objetos estn definidos de forma estndar (interfaces IDL concretos).
Sus especificaciones se encuentran recogidas en los documentos COSS (Common
Object Services Specifications).
Los servicios definidos son:








IIOP: Protocolo para la comunicacin entre ORBs a travs de TCP/IP. El ORB se comunica
a travs de IIOP sin intervencin del desarrollador.

GIOP: En computacin distribuida, GIOP (Protocolo Entre ORBs General, General Inter-
ORB Protocol) es el protocolo abstracto por el cual los ORBs se comunican. Los estndares
asociados con el protocolo son mantenidos por el Object Management Group (OMG).

IIOP (Internet Inter-Orb Protocol) es la implementacin de GIOP para TCP/IP. Es una
realizacin concreta de las definiciones abstractas de GIOP.

El Object Management Group define tres partes en GIOP:

La Representacin Comn de Datos (CDR) - es una sintaxis de transferencia, que
mapea los tipos de datos de IDL en una representacin de bajo nivel para su
transferencia "por el hilo" entre ORBs.
Servicio de Nombres
Servicio de Eventos
Servicio de Ciclo de Vida
Servicio de Objetos Persistentes
Servicio de Transacciones
Servicio de Control de Concurrencia
Servicio de Relacin
Servicio de Externalizacin

Servicio de Consulta
Servicio de Licencias
Servicio de Propiedad
Servicio de Tiempo
Servicio de Seguridad
Servicio de Negociacin
Servicio de Coleccin de Objetos


La Referencia de Objetos Interoperable (IOR) -define el formato de una referencia
a un objeto remoto. Una IOR consiste en varios perfiles etiquetados, y sus
componentes pueden llevar diversa informacin segn se necesite. La IOR tpica
habitualmente contiene la versin del protocolo, la direccin del servidor y una
secuencia de octetos que identifica al objeto remoto (clave del objeto).

Los formatos de mensaje definidos - los mensajes se intercambian entre agentes
para facilitar las peticiones de objetos, localizar implementaciones de objetos y
gestionar los canales de comunicacin.





Cuestionario.
Qu problema la OMG est probando para resolver con CORBA?
Por qu la orientacin a objetos ayuda a resolver el problema de heterogeneidad?
Qu patrones de invocacin de objetos soporta CORBA?
Cul es la diferencia entre estilos de invocacin sncrono y asincrnicos?
Qu es IDL y su utilidad?
Qu son los stubs y cmo se usan?
Qu son los skeletons y cmo se usan?
Cul es la diferencia entre la invocacin esttica y dinmico y cmo se soportan tanto en
lado del cliente como del servidor?
Qu es un almacn dela interfaz?
Qu es un adaptador del objeto?
Cmo trabaja el registro del objeto y referencia del objeto?
Cul es la diferencia entre el adaptador del objeto y el skeleton?
Qu realiza un Adaptador del Objeto Porttil (POA)?
Qu es la activacin / desactivacin?
Qu es un objeto persistente?
Qu es un objeto transente?
Cul es la diferencia entre la llamada por referencia y llamada por valor?
Cmo la interoperabilidad del inter -orb se soporta?
Cul es la diferencia entre GIOP e IIOP?
Qu transparencias proporciona CORBA?
Ejercicio Prctico