TRABAJO DE

UNIVERSIDAD
NACIONAL DE TRUJILLO

INVESTIGACIÓN
ASIGNATURA: SISTEMAS DISTRIBUIDOS.

TEMA: CORBA

GRUPO: 3.

DOCENTE: MARCELINO TORRES.

INTEGRANTES:
 SABA SANCHEZ JHON
 DELGADO RODRIGUEZ NILSON
 URBINA NARRO CESAR

FECHA: 22/10/2019.
CONTENIDO
Introducción: .................................................................................................................... 3
Historia: ............................................................................................................................ 3
CORBA 1.0 (octubre de 1991) ....................................................................................... 3
CORBA 1.1 (febrero de 1992)........................................................................................ 3
CORBA 1.2 (diciembre de 1993) ................................................................................... 3
CORBA 2.0 (agosto de 1996) ......................................................................................... 3
CORBA 3 (julio de 2002) ................................................................................................ 3
Definición:......................................................................................................................... 4
Objetivo: ........................................................................................................................... 4
Características: ................................................................................................................. 4
Proceso de desarrollo de una aplicación CORBA .......................................................... 5
PROBLEMAS Y CRÍTICAS:................................................................................................. 10
Implementación e incompatibilidades ....................................................................... 10
Transparencia en la localización ................................................................................. 10
Deficiencias en el diseño y proceso ............................................................................ 10
Problemas con las implementaciones ........................................................................ 11
Cortafuegos ................................................................................................................. 11
VENTAJAS Y DESVENTAJAS ............................................................................................. 11
VENTAJAS .................................................................................................................... 11
• Heterogeneidad .................................................................................................... 11
• Movilidad .............................................................................................................. 12
• Eficiencia............................................................................................................... 12
• Adaptación al cliente ............................................................................................ 12
• Tiempo de desempeño ......................................................................................... 12
• Robusto ................................................................................................................ 13
DESVENTAJAS .............................................................................................................. 13
CONCLUSIONES............................................................................................................... 13
INTRODUCCIÓN:
El software tiene un nuevo enfoque: el desarrollo de componentes, que depende de la
capacidad de integración para comunicarse entre ellos según las interfaces
estandarizadas. Las especificaciones de estandarización son descritas por CORBA, que
permite el desarrollo de programas de software fácilmente expansibles, reemplazables
y que es el inicio para “conectar todo lo que hay en el mundo a Internet”, sin poner en
riesgo la funcionalidad de los elementos y las aplicaciones en su totalidad.

Este informe pretende introducir al lector en el mundo de una de las tecnologías de

punta, mediante la presentación de las características del estándar de la plataforma
CORBA, que se ha convertido en “soporte a multitud de aplicaciones abiertas”.

HISTORIA:
CORBA 1.0 (octubre de 1991)
Incluyó el modelo de objetos CORBA, el lenguaje de definición de interfaz (IDL) y
el conjunto básico de interfaces de programación de aplicaciones (API) para la
gestión dinámica de solicitudes y la invocación (DII) y el repositorio de interfaces.
Incluye un mapeo de un solo lenguaje para el lenguaje C.

CORBA 1.1 (febrero de 1992)

Esta fue la primera versión ampliamente publicada de la especificación CORBA.
Cerró muchas ambigüedades en la especificación original; interfaces adicionales
para el Adaptador de objetos básicos y la gestión de memoria; aclaró el
repositorio de interfaz y aclaró las ambigüedades en el modelo de objetos.

CORBA 1.2 (diciembre de 1993)

Cerró varias ambigüedades, especialmente en la gestión de memoria y la
comparación de referencias de objetos.

CORBA 2.0 (agosto de 1996)

En 1995 aparece CORBA 2, con nuevas normas que permiten: que puedan
cooperar implementaciones de diferentes fabricantes, que pueda ser
implementado sobre cualquier nivel de transporte y que pueda funcionar en
Internet sobre TCP/IP, creando un protocolo: IIOP (Internet IOP). Tuvo su última
actualización en la versión 2 en diciembre del 2001 con CORBA 2.6.

CORBA 3 (julio de 2002)

Como intento de plantar cara a Microsoft y su modelo de programación de
objetos distribuidos DCOM. Entre otras cosas, se introdujo el CORBA Component
Model (CCM), con el que se pasó de un modelo de objetos distribuidos (EJB,
restringido a Java) a un modelo distribuido orientado a componentes.
DEFINICIÓN:
 Common Object Request Broker Architecture (CORBA) es un estándar para
escribir sistemas de objetos distribuidos en forma completamente neutral con
respecto a la plataforma, lenguaje y proveedores. CORBA fue definido por
el Object Management Group (OMG) que es un grupo fundado en 1989 por
grandes compañías como 3Com Corporation, Canon, Hewlett-Packard, Sun
Microsystems y Unisys Corporation con el objetivo de crear mercados de
componentes de softwares creando estándares como CORBA y UML.
 Es una especificación definida por el OMG (Object Management Group) para la
creación y uso de objetos remotos, cuyo objetivo es proporcionar
interoperabilidad entre aplicaciones en un entorno distribuido y heterogéneo.
Es conocido como un tipo de “middleware”, ya que no efectúa las funciones de
bajo nivel necesarias para ser considerado un sistema operativo.
 CORBA es una arquitectura de comunicaciones que soporta la construcción e
integración de tecnologías de diferente fabricante independientemente del
tiempo de creación, así como pueden intercambiar información personas que
dominan diferente idioma, sin importar que no sea usado actualmente

OBJETIVO:
Su objetivo es ayudar a reducir la complejidad, disminuir los costes y acelerar la
introducción de nuevas aplicaciones informáticas, promoviendo la teoría y la práctica
de la tecnología de objetos en los sistemas distribuidos.

CARACTERÍSTICAS:
Entre las principales características de CORBA nos encontramos con:

 Independencia en el lenguaje de programación y sistema operativo: CORBA fue

diseñado para liberar a los ingenieros de las limitaciones en cuanto al diseño del
software. Actualmente soporta Ada, C, C++, Lisp Java, COBOL, PL/I y Python.
 Posibilidad de interacción entre diferentes tecnologías: uno de los principales
beneficios de la utilización de CORBA es la posibilidad de normalizar las
interfaces entre las diversas tecnologías y poder así combinarlas.
 Transparencia de distribución: ni cliente ni servidor necesitan saber si la
aplicación está distribuida o centralizada, pues el sistema se ocupa de todo eso.
 Transparencia de localización: el cliente no necesita saber dónde ejecuta el
servicio y el servicio no necesita saber dónde ejecuta el cliente.
 Integración de software existente: se amortiza la inversión previa reutilizando el
software con el que se trabaja, incluso con sistemas heredados.
 Activación de objetos: los objetos remotos no tienen por qué estar en memoria
permanentemente, y se hace de manera invisible para el cliente.
  Otras como: el tipado fuerte de datos, la alta capacidad de configuración,
libertad de elección de los detalles de transferencia de datos, o la compresión de
los datos.

Proceso de desarrollo de una aplicación CORBA

1. Define la interfaz del servidor: Define la interfaz del servidor utilizando IDL. Con
ello se formaliza que operaciones ofrece el servidor y como pueden ser
invocadas.
2. Registra la definición en el repositorio de interfaces: La definición de la interfaz
se almacena en un repositorio de interfaces, a fin de que en tiempo de ejecución
los clientes obtengan la información reflectiva que ofrecen.
3. Compila la especificación de la interfaz: Compila la especificación IDL y obtienes
los ficheros de código Java que se requieren para desarrollar la aplicación: Stub
del cliente, esqueleto del servidor y ficheros auxiliares con funciones.
4. Implementa el código del servant: Escribe el código Java que implementa la
funcionalidad del servidor.
5. Compila el código Java del servidor: Compila el código Java utilizando un
compilador Java ordinario.
6. Registra el servidor en el repositorio de objetos: Registra los objetos del servidor
en el registro de nombres que ofrece el sistema para ser posteriormente
localizados por los clientes.
7. Instancia los objetos del servidor: Crea un adaptador, y a través de él, el servidor
queda a la espera de recibir invocaciones.
8. Implementa el código del cliente: Implementa el código Java del cliente. A través
del registro de objetos, se obtiene el proxy al servidor, y se invocan las
operaciones como si fuesen locales.
9. Compila el código Java del cliente: Se compila y ejecuta el cliente como cualquier
aplicación Java ordinaria

ARQUITECTURA CORBA
Para que el cliente pueda realizar una invocación sobre un objeto, se debe tener una
referencia del objeto (IOR) y conocer el tipo de objeto y la operación que desea invocar.
El cliente puede iniciar la petición a través de una conexión IDL o bien construyendo la
invocación de forma dinámica utilizando el DII. El ORB se encarga de encontrar el código
de la implementación apropiada, transmitir los parámetros y transferir el control a la
Implementación de la Interfaz a través del esqueleto IDL, o a través del esqueleto
dinámico (DII) como se explica más adelante. Las invocaciones pueden producir
excepciones de diversa índole. Por ejemplo, la referencia al objeto puede ya no ser
válida, o la interfaz IDL del objeto ha podido cambiar. El ORB se encargará de
informarnos de todas estas posibles excepciones y nuestro código deberá estar
preparado para gestionar estas excepciones. A continuación, se describe cada una de
las características fundamentales de la Arquitectura CORBA.

Objetos CORBA
Las implementaciones de los objetos reciben las invocaciones como llamadas hacia
arriba (up-call), desde el ORB hacia la Implementación de la interfaz. La implementación
de la interfaz puede elegir un adaptador de objetos entre un conjunto de ellos, una
decisión que estará basada en la clase de servicios que pueda requerir dicha
implementación. Los objetos CORBA se diferencian de los objetos de los lenguajes
habituales de programación en que:

 Pueden estar localizados en cualquier lugar de la red.

 Pueden ejecutarse en cualquier plataforma de hardware y de sistema operativo.
 Pueden estar escritos en cualquier lenguaje.
 Pueden tener la capacidad de detectar el entorno, procesar información y
además tienen la capacidad de comunicación.

ORB object request broker

Componente que permite que clientes y objetos puedan comunicarse en un ambiente
distribuido. Y que contempla cada una de las interfaces que el ORB manipula. El bus de
objetos es el intermediario entre clientes y servidores que transmite las peticiones
cliente-servidor y las respuestas servidor-cliente. Se necesita un ORB en cada máquina.
El ORB soporta cuatro tipos de interfaces de objetos:

 Object Services: Son interfaces para servicios generales. Son usadas en cualquier
programa basado en objetos distribuidos.
 Common Facilities: Son interfaces orientadas al usuario final y que se programan
por la aplicación específica.
 Domain Interfaces: Son interfaces de dominio específico para las aplicaciones.
  Application Interfaces: Este tipo de interfaz acepta interfaces que no sean
estandarizadas y se utilizan en aplicaciones específicas.

El adaptador de objetos (OA)

El adaptador de objetos (OA) es el módulo que permite a las implementaciones de los
objetos acceder a servicios ofrecidos por el ORB, éste genera las referencias a los
objetos. El adaptador de objetos exporta una interfaz pública para su uso por la
implementación del objeto y una interfaz privada para ser usada por el esqueleto del
objeto que depende de la implementación del adaptador de objetos. Las funciones que
realiza este adaptador son:

 Generación e interpretación de las referencias a objetos.

 Invocación de métodos.
 Seguridad en las interacciones.
 Activación y desactivación de objetos e implementaciones.
 Traducción de referencias a objetos con sus correspondientes
implementaciones.
 Registro de las implementaciones. Debido a que las implementaciones de los
objetos dependen del adaptador de objetos, se deben definir la menor cantidad
de adaptadores de objetos.

IDL (Interface Definition Language)

Para poder especificar los servicios que ofrecen los objetos que forman parte de un
sistema abierto y distribuido, se necesita contar con algún lenguaje preciso, bien
definido, e independiente de cualquier posible representación de los datos o estructuras
que él define, así como la futura implementación de los objetos que especifica. La norma
ISO/IEC 14750 (ITUT X.920) define dicho lenguaje, al que se conoce como lenguaje de
definición de interfaces de ODP, o ODP IDL por su acrónimo en inglés. Su principal
objetivo es describir la signatura de los objetos que especifica, en términos de las
estructuras de datos que se manejan y el perfil de las operaciones que definen sus
servicios. De esta forma se consigue la ocultación necesaria para el desarrollo de
aplicaciones abiertas. En IDL, una interfaz es una descripción de un conjunto de posibles
operaciones que un cliente puede solicitar de un objeto. El objeto satisface una interfaz
si este puede satisfacer una solicitud de otro objeto. La interfaz provee mecanismos
compuestos que le permiten a tal objeto soportar múltiples interfaces. Las operaciones
que se realizan denotan servicios que pueden ser atendidos y ejecutados para cambiar
de valor y adquirir un valor. Una operación es reconocida por un identificador de
operación. Una operación no es un valor. Los tipos de datos que manipula CORBA en IDL
son:

 Tipos básicos : long, short, ushort, ulong, float, double char, boolean, enum,
string, octect, any
  Tipos compuestos: struct, union, array
 Tipos derivados: sequence
 Tipos de objeto: interface, referencia a objetos

Un tipo es una entidad con predicados asociados y definidos con valores en un objeto.
Un valor satisface un tipo si el predicado es verdadero para la variable. Los tipos son
usados para restringir los posibles valores, parámetros, o para identificar un posible
resultado. La Interfaz IDL se compone del repositorio de interfaces y la interoperabilidad
de la Interfaz de invocación dinámica:

 El repositorio de interfaces (IR) es un servicio que ofrece objetos persistentes

que representan la información IDL de las interfaces disponibles en CORBA, de
una forma accesible en tiempo de ejecución (runtime). Esta información puede
ser utilizada por el ORB para realizar peticiones. Y, además, el programador de
aplicaciones puede utilizar esta información para acceder a objetos cuya interfaz
no se conoce en tiempo de compilación, o para determinar que operaciones son
válidas en un objeto.
 La interfaz de invocación dinámica El DII (Dynamic Invocation Interface) es una
interfaz que nos permite la construcción dinámica de invocaciones para un
determinado objeto. Ello garantiza que el cliente pueda especificar el objeto, la
invocación y los parámetros que se pasan al servidor. La invocación es idéntica a
la que llega a través de la interfaz estática pero que ya dentro del cliente, logra
una flexibilidad fundamental en arquitecturas complejas y dinámicas. Una
invocación dinámica se compone, de una referencia al objeto, una operación y
una lista de parámetros. Todos estos datos se obtienen del Repositorio de
Interfaces (IR).

Stub
Es el intermediario entre el cliente y el ORB. El Stub recoge del cliente llamadas a
métodos y las transmite al ORB. Se requiere una clase de stub por cada clase remota.
Además, es un componente que actúa como servidor, puede estar ejecutándose en
cualquier máquina conectada a la red que recibe peticiones por parte de clientes que
pueden ser locales o remotos. Indistintamente de ello, el cliente siempre tendrá la
ilusión de que la llamada se ejecuta localmente. En otras palabras, el stub logra que el
programador no se ocupe de las instrucciones de programación remotas ya que son
objetos que residen en el cliente y que representan objetos remotos instalados en un
servidor. En él se identifica: Host, puerto e identificador del objeto.

Esqueleto:
Es el intermediario entre ORB y los objetos del servidor. Recibe llamadas del ORB y
ejecuta los métodos correspondientes en el servidor sobre el objeto que corresponda.
Cuando el cliente establece un objeto local (con servicio remoto), la petición se realiza
por intermedio del protocolo de comunicaciones IIOP a través del ORB. El servidor recibe
la petición, busca el objeto definido (compara el esqueleto del método en el módulo
esqueleto) lo ejecuta y retorna la respuesta al cliente. (Barrera, 2017)

FUNCIONAMIENTO DE CORBA
Todos los componentes CORBA son objetos, cada cual tendrá una interfaz y una
identidad única, cada uno de los objetos se podrá implementar en un lenguaje de
programación distinto y ejecutarse sobre cualquier sistema operativo.

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.

La manera de realizar la invocación por parte del cliente es usando stub, una interfaz de
comunicación con el servidor generada a partir del IDL, usando la invocación dinámica
para acceder a los objetos del servidor gestionando a su vez las excepciones producidas
por su llamada.

Necesita para ello una referencia del objeto remoto o IOR (Interoperable Object
References), el tipo del objeto y el nombre de la propia operación que desea invocar.
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.

El ORB, a partir de la petición del cliente encuentra el código de la implementación

apropiada y transmite los parámetros, el control a la implementación de la interfaz a
través del skeleton IDL e informa de excepciones en el proceso (como referencias IOR o
IDL no válidas).

Para recibir la petición, recibe la invocación de uno de sus métodos como llamadas
desde el ORB hacia la implementación de la interfaz, la llamada puede venir de un cliente
que haya utilizado los stubs IDL; los esqueletos de la interfaz 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.

Puede utilizar los servicios que proporciona el adaptador de objetos e incluso que
proporciona el ORB, mientras es procesada la petición que ha recibido el cliente, para
ese caso puede elegir un adaptador de objetos entre un conjunto de ellos, para tomar
esa decisión se basa en la clase de servicios que pueda requerir la implementación de la
interfaz.
 Cliente Servidor
Esqueleto
Stub

ORB ORB
IIOP

PROBLEMAS Y CRÍTICAS:
Aunque CORBA prometió mucho en cuanto a la forma de codificar y construir software,
ha sido objeto de muchas críticas.

Algunos de los fallos se deben a la implementación y el proceso por el que CORBA fue
concebido como un estándar y los problemas que se surgieron en referencia a la política
de negocio al implementar un software estandarizado. Estos derivaron en un rechazo
en el uso y adopción de CORBA en nuevos proyectos y áreas.

Implementación e incompatibilidades
La especificación inicial de CORBA definía tan solo el IDL, y no la interoperabilidad entre
los lenguajes. Esto significa que la compatibilidad del código fuente no era mejor que la
que había disponible en el momento. Con CORBA 2 y posteriores, este problema se
resolvió.

Transparencia en la localización
La noción de CORBA en cuanto a transparencia ha sido motivo de crítica, y esto es debido
a que los objetos que residen en el mismo espacio de direcciones y que son accesibles
con una simple llamada a una función son tratados como objetos que residen en
cualquier parte del sistema distribuido. Esto hace que los accesos locales sean tan
complicados como serían en el escenario remoto más complejo. Aunque cabe decir que
CORBA no ofrece restricciones en la complejidad de las llamadas.

Deficiencias en el diseño y proceso

La creación del estándar CORBA es citado a menudo por su proceso de diseño por
comité. No hubo proceso de arbitraje entre las propuestas conflictivas o de decisión de
la jerarquía de los problemas a resolver. Así, el estándar se creó teniendo en cuenta
todas las propuestas sin importar la coherencia entre estas. Esto hizo que la
especificación fuera muy compleja, cara de implementar y a menudo ambigua.
Problemas con las implementaciones
A lo largo de su historia, CORBA se ha visto afectada por las deficiencias en sus
implementaciones. Ha habido pocas implementaciones que hayan incluido todos los
elementos críticos de la especificación, y las implementaciones existentes estaban
incompletas o eran inadecuadas. Al no existir requisitos a la hora de proponer nuevas
características, los miembros incluían propiedades que no habían sido probadas nunca
en cuanto a usabilidad o implementación. A su vez las implementaciones se vieron
obstaculizadas por la tendencia general para detallar las normas y la práctica común de
comprometerse a adoptar todas ellas, lo que normalmente generaba APIs incoherentes
y de difícil utilización. En la actualidad este punto ha cambiado considerablemente a
mejor y podemos encontrar implementaciones de CORBA de mejor calidad.

Cortafuegos
CORBA (más precisamente, IIOP) utiliza conexiones TCP/IP crudas con el fin de
transmitir los datos. Sin embargo, si el cliente está detrás de un cortafuegos muy
restrictivo o un entorno con servidor proxy transparente que sólo permite
conexiones HTTP hacia el exterior por el puerto 80, la comunicación puede llegar a ser
imposible, salvo que el servidor proxy en cuestión permita el método CONNECT HTTP o
conexiones con sockets. Hubo un momento, en el que era difícil hasta forzar
implementaciones para utilizar un solo puerto estándar, en vez de esto tenían que
escoger varios puertos al azar. Hoy en día, los ORBs actuales no tienen estas deficiencias.
Debido a estas dificultades, algunos usuarios han preferido el uso de los servicios web
en lugar de CORBA. Estos se comunican utilizando XML/SOAP través del puerto 80, que
normalmente se deja abierto o se filtra a través de un proxy HTTP dentro de la
organización, para la navegación web a través de HTTP. Implementaciones CORBA
recientes, sin embargo, soportan SSL y pueden ser fácilmente configurados para trabajar
en un solo puerto. La mayoría de los ORBs de código abierto más populares como son
TAO y JacORB, soportan también GIOP bidireccional, lo que da a CORBA la ventaja de
ser capaz de utilizar la comunicación de retorno de llamada en lugar del enfoque de
sondeo característica de implementaciones de servicios web. A su vez, cada vez se
comercializan más cortafuegos que soportan CORBA sin problemas.

VENTAJAS Y DESVENTAJAS
VENTAJAS
• Heterogeneidad
Un sistema heterogéneo consiste en conjuntos de elementos interconectados de
hardware y software de diferente fabricante y que puede integrar aplicaciones de
diferente tecnología.
La infraestructura de sistemas de información antiguos que poseen las compañías no
son fácilmente reemplazable, debido al costo de desarrollo y al tiempo de implantación,
una de las mejores alternativas es integrar antiguas tecnologías con nuevas para así
obtener un completo beneficio.

• Movilidad
La migración de procesos en sistemas distribuidos tradicionales es muy útil para mejorar
el reparto de carga de los diferentes computadores. Tiene como fin garantizan el
rendimiento global y ciertas restricciones de administración o seguridad.

• Eficiencia
 La red lleva menos mensajes.
 El servidor realiza más trabajo.
 Se evita la latencia/inestabilidad de la red en los procesos.

• Adaptación al cliente
 El cliente puede extender la funcionalidad del servidor.
 Fácil instalación para el usuario.
 No se requiere instalación de servidor.
 No se acuerdan los procedimientos entre los clientes y los servidores.
 Instalación dinámica de los procedimientos del cliente en el servidor.

• Tiempo de desempeño
Además, la ejecución asíncrona permite que los procesos controlen la gestión y
terminación de tarea y que el cliente pueda finalizar o continuar haciendo otras cosas
en su sistema, por otro lado, se reduce el tráfico en la red y la capacidad de cómputo del
cliente.

• Robusto
 Reducción de la dependencia de la disponibilidad de la red y del
cliente/servidor.
 Los procesos migrados al sistema servidor no se ven afectados por los
fallos del cliente o de la red.
 Los procesos se ejecutan realizando tareas específicas en lugares
diferentes.
 Automatización de las tareas distribuidas.

DESVENTAJAS
El problema fundamental de los sistemas de integración es el software. Aún no existe
mucha experiencia en el diseño, implantación y uso de software como CORBA.
Precisamente, éste es un campo de investigación actual.

Las redes son indispensables para la comunicación entre máquinas; sin embargo,
pueden plantear problemas de saturación, embotellamiento, interrupción o pérdidas de
mensajes.

El posible acceso a todo el sistema por parte de los usuarios plantea el inconveniente de
la necesidad de un sistema de seguridad adecuado y estándar, aunque CORBA maneja
la seguridad.

CONCLUSIONES
CORBA proporciona una infraestructura y un modelo común desde donde los requisitos
expresados en diferentes lenguajes (las diferentes metodologías de desarrollo), pueden
ser integrados para formar un sistema globalmente consistente.

CORBA ofrece un conjunto de mecanismos muy útiles a la hora de desarrollar

aplicaciones distribuidas, junto con un soporte tecnológico suficientemente maduro
como para construir aplicaciones robustas, eficientes y competitivas, a la vez que
integrables con otros sistemas que cumplan estos estándares.

Los sistemas que son desarrollados con tecnologías antiguas pueden ser integrados con
las nuevas a través de CORBA. Esto es, construyendo interfaces para que intercambien
información local o remota a través de la red para resolver problemas en forma parcial
e incremental.

Ya, algunas tecnologías incorporan interfaces para intercambiar información a través de

CORBA, así como desarrollos adicionales que facilitan la integración de servidores y
clientes con filosofía CORBA.

Java como herramienta también integra interoperabilidad con CORBA siempre y cuando
los objetos estén usando un ORB compatible con las especificaciones y que se apoyen
con IIOP como protocolo de comunicaciones.

Finalmente, el protocolo de comunicación IIOP, establecido por la especificación CORBA

para la interoperabilidad entre distintas plataformas, se ha convertido en el protocolo
por defecto utilizado en los estándares para asegurar la interoperabilidad entre todos
los sistemas.