CONSULTORÍA ESTRATÉGICA EN TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIONES
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.
El OMG es un consorcio internacional sin ánimo de lucro establecido en 1989. Su objetivo es, ayudar a reducir la complejidad, disminuir los costes y acelerar la introducción de nuevas aplicaciones software, promoviendo la teoría y la práctica de la tecnología de objetos en los sistemas distribuidos.
Originalmente estaba formada por 13 compañías, pero los miembros del OMG han crecido progresivamente y en la actualidad es el consorcio de software más grande del mundo, compuesto por más de 760 vendedores, programadores y usuarios. De hecho todas las grandes compañías de software interesadas en el desarrollo orientado a objetos distribuidos son miembros del OMG.
El OMG alcanza sus objetivos promoviendo la adopción de especificaciones de interfaz y de protocolo, que permiten la interoperabilidad y portabilidad de las aplicaciones orientadas a objetos distribuidos. En este consorcio no se producen guías de cómo implementar o producir software, sólo especificaciones.
Los miembros del OMG contribuyen tecnológicamente y con ideas en respuesta a RFI (Request For Information) y RFP (Request For Proposals), emitidas por el OMG. El OMG no establece estándares en la industria, se formó para promover mediante el consenso de sus participantes, la adopción de estándares de facto por parte de los vendedores. El estándar a ser adoptado, debe existir como una implementación; es decir, sólo se aprueba un estándar si alguien lo ha implementado y se comprueba su correcto funcionamiento.
En su Web Site, http://www.omg.org, se puede encontrar información detallada sobre sus actividades, estándares, y la tecnología CORBA en general.
OMA (Object Management Architecture) o arquitectura de gestión de objetos es el centro de toda la actividad emprendida en el OMG. Se trata de una visión a alto nivel de un entorno distribuido completo y se compone de un modelo de objeto y un modelo de referencia.
En el modelo de objeto de OMA, un objeto es una entidad encapsulada con una identidad inmutable y distinguible, cuyos servicios pueden ser accedidos a través de interfaces bien definidas.
En la Figura 1 se muestran los componentes del modelo de referencia de OMA, encargado de caracterizar las interacciones entre objetos. El componente fundamental es el denominado ORB (Object Request Broker). El ORB es, principalmente, el responsable de facilitar la comunicación entre clientes y objetos. Puede verse como el microkernel de un sistema distribuido. Utilizando el componente ORB hay cuatro categorías de interfaces de objetos, descritas a continuación:
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.
La arquitectura CORBA está orientada a objetos. Los objetos CORBA presentan muchas características de otros sistemas orientados a objetos, incluyendo la herencia de interfaces y el polimorfismo. 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.
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.
La principal característica del ORB es la transparencia, cómo facilita la comunicación cliente/servidor. Generalmente, el ORB oculta lo siguiente:
Estas características del ORB permiten a los desarrolladores de aplicaciones preocuparse más por las cuestiones propias del dominio de sus aplicaciones y desentenderse de las cuestiones de programación a bajo nivel del sistema distribuido.
La idea de un ORB es la siguiente, cuando un componente de aplicación quiere utilizar un servicio proporcionado por otro componente, primero debe obtener una referencia para el objeto que proporciona ese servicio. Después de obtenerla, el componente puede llamar a los métodos en ese objeto, accediendo así a los servicios proporcionados por éste; evidentemente el programador del componente cliente debe saber en tiempo de compilación que métodos están disponibles por un objeto servidor particular. La principal responsabilidad de ORB es resolver las peticiones por las referencias a objetos, posibilitando a los componentes de aplicación establecer conectividad entre ellos.
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:
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.
Un resultado del proceso de clasificación y desclasificación es, que debido a que los parámetros se convierten en la transmisión a un formato independiente de la plataforma, la comunicación entre componentes es independiente de la plataforma. Esto significa que, por ejemplo, un cliente ejecutándose en un sistema Macintosh puede invocar métodos en un servidor ejecutándose en un sistema Unix. Además de la independencia del sistema operativo utilizado, las diferencias de hardware, como puede ser el orden de los bytes más significativos o el tamaño de una palabra, son así mismo irrelevantes, ya que el ORB hace automáticamente la conversión necesaria.
El lenguaje de definición de interfaz o IDL (Interface Definition Language), es un lenguaje muy sencillo utilizado para definir interfaces entre componentes de aplicación. Es importante destacar que IDL sólo puede definir interfaces, no implementaciones. IDL, al especificar las interfaces entre objetos CORBA, es el instrumento que asegura la independencia del lenguaje de programación utilizado.
Para ello, la especificación IDL ha de asegurar que los datos son correctamente intercambiados entre dos lenguajes distintos. Por ejemplo, el tipo long es un entero con signo de 32 bits, que se puede hacer corresponder con un long de C++ (dependiendo de la plataforma) o a un int de Java. Es responsabilidad de la especificación IDL (y de los compiladores IDL que la implementan), definir dichos tipos de datos de una forma independiente del lenguaje.
IDL consigue la independencia del lenguaje a través de una correspondencia. El OMG ha definido bastantes correspondencias con lenguajes de programación populares, como: C, C++, COBOL, Java, Smalltalk y Ada. Las correspondencias para otros lenguajes también existen, pero o no son estándar o están en proceso de estandarización. En la Tabla 1 se muestra la correspondencia entre los tipos IDL y los tipos C++.
Describiendo las interfaces IDL, un ORB genera automáticamente código en el lenguaje seleccionado para realizar la integración de las aplicaciones distribuidas. Evidentemente, puesto que sólo describe interfaces, todas las tareas complejas relacionadas con los lenguajes de programación, como control de flujo, gestión de memoria, composición funcional, no aparecen en IDL.
Evidentemente, la independencia del lenguaje de programación es una característica muy importante de la arquitectura CORBA. CORBA da a los programadores de la aplicación la libertad para elegir el lenguaje que mejor se adapta a las necesidades de su aplicación o bien utilizar varios lenguajes para varios componentes de la aplicación. Por ejemplo, el cliente de una aplicación podría estar implementado en Java, lo que asegura que los clientes pueden ejecutarse virtualmente en cualquier máquina. Los componentes servidores de dicha aplicación podrían implementarse en C++, para conseguir una elevada eficiencia. CORBA hace posible la comunicación entre estos componentes de diversa naturaleza.
| IDL | C++ |
|---|---|
| Short | CORBA::Short |
| Long | CORBA::Long |
| Unsigned short | CORBA::UShort |
| Unsigned long | CORBA::ULong |
| Float | CORBA::Float |
| Double | CORBA::Double |
| Char | CORBA::Char |
| Boolean | CORBA::Boolean |
| Octect | CORBA::Octect |
| Any | CORBA::Any |
Todas las aplicaciones basadas en CORBA necesitan acceder al tipo de sistema de IDL cuando se están ejecutando. Esto es necesario porque la aplicación necesita conocer los tipos de valores a ser pasados como argumentos de la petición. Asimismo, la aplicación ha de conocer los tipos de interfaces soportados por los objetos que están utilizando.
Ciertas aplicaciones requieren sólo un conocimiento estático del tipo de sistema IDL. Típicamente, la especificación IDL es compilada o traducida a código para el lenguaje de programación de la aplicación siguiendo las reglas de traducción como es definido por su correspondencia con el lenguaje. De esta forma, si el tipo del sistema IDL cambia de tal modo que pasa a ser incompatible con el tipo de sistema construido en la aplicación, la aplicación ha de volver a construirse.
Pero hay ciertas aplicaciones, sin embargo, para las cuales es imposible un conocimiento estático del tipo de sistema IDL. Para estas aplicaciones CORBA proporciona otro método de definir interfaces sustituyendo a IDL, el registro de interfaz. Las interfaces pueden ser añadidas a un servicio de registro de interfaz, el cual define las operaciones para la recuperación de la información del almacén en tiempo de ejecución. Utilizando el registro de interfaz, un cliente podría ser capaz de ubicar un objeto desconocido en tiempo de compilación, preguntar acerca de su interfaz, y después construir una petición a ser enviado a través del ORB.
Toda arquitectura orientada a objeto caracteriza un modelo de objeto, que describe cómo se representan los objetos en el sistema. No obstante, puesto que CORBA es una arquitectura distribuida, su modelo de objeto difiere de los modelos de objetos tradicionales como C++ o Java.
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.
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.
El estándar CORBA describe un cierto número de adaptadores de objeto, cuya principal tarea es la de hacer de interfaz entre la implementación de un objeto y su ORB, puesto que se trata de mantener el ORB tan sencillo como sea posible. El ORB, en efecto, sólo ha de proporcionar una infraestructura de comunicación y activación para aplicaciones de objetos distribuidos.
Los adaptadores de objeto son, en otras palabras, un objeto interpuesto que usa la delegación para permitir realizar invocaciones sobre un objeto, incluso aunque el innovador no conozca la verdadera interfaz del objeto. Entre las responsabilidades de los adaptadores de objeto, cabe destacar las siguientes:
Actualmente CORBA sólo proporciona un adaptador de objeto, conocido por adaptador de objeto básico. El adaptador de objeto básico suministra objetos CORBA con un conjunto común de métodos para acceder a las funciones del ORB y trata de ser un adaptador de objeto multipropósito que pueda soportar varios estilos e implementaciones de servidores, resultando ser muy básica en ciertas áreas. Esto ha supuesto baja eficiencia y baja portabilidad, pues cada vendedor ORB ha optado por cubrir dichas áreas con implementaciones propias. No obstante el OMG se ha percatado de este problema y está trabajando activamente en él.
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.
GIOP, es sólo un protocolo general; el estándar CORBA también determina protocolos adicionales, que especializan GIOP para utilizar un protocolo de transporte en particular. Por ejemplo, los protocolos basados en GIOP existen para TCP/IP y DCE. Adicionalmente, los vendedores pueden definir y utilizar protocolos propietarios para la comunicación entre componentes CORBA.
El protocolo basado en GIOP más importante es el destinado a redes TCP/IP, conocido como IIOP (Internet Inter-ORB Protocol). Los fabricantes tienen que implementar el protocolo IIOP para ser considerados conformes a CORBA, aunque pueden ofrecer además sus protocolos propietarios. Este requerimiento ayuda a asegurar la interoperabilidad entre los productos CORBA de diferentes vendedores pues cada producto conforme a CORBA 2.2 debe ser capaz de hablar el mismo lenguaje. Algunos vendedores han adoptado IIOP como protocolo nativo de sus productos en vez de utilizar un protocolo propietario; sin embargo, se permite que un ORB soporte cualquier número de protocolos, siembre y cuando IIOP se soporte, es decir, al comunicarse entre sí, los ORBs pueden negociar que protocolo utilizar. Adicionalmente algunos fabricantes están incorporando IIOP en productos como servidores de bases de datos o herramientas de desarrollo de aplicaciones o navegadores Web.
Esencialmente, las aplicaciones CORBA se realizan sobre los protocolos derivados de GIOP como IIOP. Estos protocolos van sobre TCP/IP, DCE o cualquier otro protocolo de transporte que utilice la red. Las aplicaciones CORBA no están limitadas a utilizar únicamente uno de estos protocolos; la arquitectura de una aplicación puede ser diseñada para utilizar un puente que interconecte, por ejemplo, componentes de una aplicación basados en DCE con otros basados en IIOP. Es decir, máquinas que suplantan los protocolos de la red de transporte. CORBA es una arquitectura que crea otra capa (la capa del protocolo entre ORBs) que utiliza la capa de transporte subyacente. Esto es también un punto determinante de la interoperabilidad entre aplicaciones CORBA, CORBA no dicta la utilización de una capa de transporte en particular.
Tradicionalmente, en una aplicación cliente/servidor, el servidor es el componente o componentes que proporciona servicios a otros componentes de la aplicación. El cliente es el componente que hace uso de los servicios suministrados por un servidor o servidores.
La arquitectura de una aplicación CORBA no es diferente; generalmente, ciertos componentes de una aplicación proporcionan servicios que son utilizados por otros componentes de otra aplicación. El papel del cliente y servidor puede intercambiarse temporalmente, ya que un objeto CORBA puede participar en múltiples interacciones simultáneamente.
En una aplicación CORBA, cualquier componente que proporciona la implementación para un objeto es considerado un servidor. El hecho de ser un servidor CORBA significa que, el componente (el servidor), ejecuta métodos para un objeto particular, en nombre de otros componentes (los clientes).
Después de que el programador cree las definiciones de interfaz del componente utilizando IDL, dicho desarrollador procesa los ficheros IDL resultantes con un compilador IDL. El compilador crea los conocidos por client stubs y server skeletons. Los client stubs y server skeletons sirven como una clase de “pegamento” que conecta las especificaciones de interfaz IDL independientes del lenguaje con un código de implementación específico del lenguaje.
Los client stubs para una interfaz en particular se suministran para su inclusión con los clientes que utilizan dichas interfaces. El client stub para una interfaz en particular, proporciona una falsa implementación para cada uno de los métodos de dicha interfaz. En vez de ejecutar la funcionalidad del servidor, los métodos del client stub simplemente se comunican con el ORB para clasificar y desclasificar los parámetros.
Por otro lado, se tienen los server skeletons, proporcionando el esqueleto sobre el que se construirá el servidor. Para cada método en la interfaz, el compilador IDL genera un método vacío en el server skeleton. El desarrollador después proporciona una implementación para cada uno de esos métodos.
Los stubs y skeletons han sido generalizados a un DII (Dynamic Invocation Interface) y DSI (Dynamic Skeleton Interface), respectivamente. Ambas son interfaces proporcionadas directamente por ORB, y son independientes de las interfaces IDL de los objetos que están siendo invocados. Utilizando DII una aplicación cliente puede invocar peticiones, en cualquier objeto, sin tener conocimiento en tiempo de compilación de las interfaces del objeto. De forma semejante, DSI permite a los servidores ser codificados, sin tener skeletons para los objetos que están siendo invocados, siendo compilados estáticamente en el programa.
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.
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:
#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
#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;
}
#include <ContadorSC.h>
main( )
{
// Se crea una instancia del contador
Contador_var Servidor = TIE_Contador(Contador_i)(new Contador_i);
// Se entra en el bucle de eventos
try
{
CORBA::Orbix.impl_is_ready ("contador", CORBA::Orbix.INFINITE_TIMEOUT);
}
catch (const CORBA::SystemException& codigo)
{
cerr << "Excepcion CORBA al registrar el servidor: "<< codigo;
}
// 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
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;
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.
A primera vista, el entorno distribuido construido a partir de la arquitectura CORBA presenta grandes semejanzas con el de DCE (Distributed Computing Environment) del OSF (Open Software Foundation), que se basa en llamadas a procedimiento remoto o RPCs (Remote Procedure Call). Pero aunque la base lógica de ambas arquitecturas es la misma, hay diferencias significativas entre ambas.
Las RPCs, como su propio nombre indica, son inherentes a procedimientos, es decir, llaman a aplicaciones y sistemas operativos para que realicen tareas específicas, una al tiempo. CORBA, por el contrario, es inherentemente orientada a objeto, lo que significa que las aplicaciones por completo, así como las combinaciones de aplicaciones y datos, pueden invocar y encapsularse unas a otras. En vez de escribir una llamada procedimiento especifica para enlazar con las aplicaciones, el programador puede encapsular una aplicación o una aplicación y un rango dado de datos en otra aplicación mayor. Actualmente las RPC son ligeramente más eficientes que CORBA en aplicaciones sencillas.
CORBA actualmente presenta más aspectos en común con otro entorno para la integración de aplicaciones, la especificación OLE (Object Linking and Embedding) de Microsoft. CORBA y OLE utilizan principios de programación orientada a objetos, incluyendo herencia, encapsulación, y extensibilidad. El problema estaba en que OLE 2.0 no posibilitaba la integración de aplicaciones en plataformas distintas a PCs, lo cual fue resuelto por la especificación COM (Common Object Model), publicada por Microsoft y Digital conjuntamente, que estipula como la funcionalidad OLE puede extenderse para ser implementada en otras plataformas en las que se está utilizando CORBA. Además, el OMG ha formulado un RFP para establecer la interoperabilidad entre CORBA y COM.
Otro ORB muy conocido es Java RMI (Remote Method Inovocation) de Sun Microsystems. Se trata de la solución más recomendable para escribir aplicaciones distribuidas en Java, por ser un ORB nativo a él, pero con la desventaja de no poder ser utilizado con objetos o aplicaciones codificadas en otros lenguajes.
