Una vez expuestas ambas concepciones de sistemas operativos distribuidos podemos establecer la comparación entre ellas.
La diferencia fundamental entre DCE y CORBA, como ya se ha podido observar, radica en el enfoque de la implementación del sistema operativo distribuido. Mientras que DCE nace con la idea de soportar la programación procedural, CORBA decide apostar por un entorno orientado a objetos.
 

A ) Nivel de implementación

En estos momentos la especificación de DCE está más cerca concluirse que la especificación propuesta por la OMG, que por el momento no ha concretado los servicios de seguridad entre otros, o las facilidades verticales y horizontales.

Por otra parte las especificaciones existentes de los dos modelos de sistemas operativos distribuidos, están sujetas a revisiones periódicas, intentando mantener siempre la compatibilidad entre las especificaciones anteriores y la revisada. En este sentido ambas, DCE y CORBA (solo la especificación de ORB), han alcanzado ya gran estabilidad.

En cuanto a la implementación de los dos sistemas, existen implementaciones bastante completas de ambas, aunque en el caso de CORBA nos limitamos a los ORB's.
También podemos encontrar implementaciones de CORBA que se han construido en la cima de DCE.

La lista de vendedores de DCE incluye nombres tan importantes como AT&T, Bull, Hitachi, SCO, Transarc o Siemens Nixdorf. En el otro lado, apoyando la especificación CORBA encontramos a Expersift, IONA TEchnologies, SunSoft o Postmodern Computing.
Otras grandes firmas han decidido apostar en ambos lados, ejemplo de ellas son IBM, DEC o Hewelt Packard.
 
B ) Características Generales

CORBA soporta las características habituales de los entornos orientados a objeto:

• encapsulación de los datos y funciones que manejan dichos datos en objetos.
• abstracción de características comunes a varios objetos en clases.
• herencia de interfaces e implementaciones, especializando entre clases y subclases.
• polimorfismo, se invoca a una operación y dependiendo del tipo de los parámetros con los que ha sido invocada se ejecuta una u otra implementación.
• otras características propias de los entornos de programación orientados a objeto como la creación de clases, reutilización de clases y objetos definidos por una aplicación en otra

• Un cliente de DCE puede determinar e tiempo de ejecución con que servidor quiere comunicarse y efectuar RPC´s (aunque debe haber especificado en tiempo de compilación que interfaces de servidor va a utilizar para ello )
• Un servidor DCE puede generar objetos UUID ( Universal Unique Identifiers ) para reconocer los diferentes recursos controlados por el servidor.
• Un servidor puede generar tipos de objetos UUID, asociar a cada objeto UUID un tipo UUID, y definir una serie de manejadores específicos para cada tipo

En DCE RPC, una interface de servidor debe hacer múltiples llamadas para registrarse, y a su vez un cliente debe hacer múltiples llamadas para encontrar la interface del servidor al que desea invocar.

Además, si el cliente y el servidor están escritos orientados a objeto el uso de DCE RPC es muy complejo ya que la interface con la que interactuan es no orientada a objeto..

DCE RPC no ofrece ningún soporte a C++, aunque es usado tanto en C como en C++. Por otra parte, CORBA resulta más fácil de manejar con C++.

CORBA en su mecanismo de invocación remota el software "llamador" envía una petición y no sabe que objeto será el que le responda ni dónde va a estar localizado.

Una dirección nos da la información necesaria para que un objeto pueda asociarse a la objeto direccionado. Las direcciones DCE se llaman manejadores de bindings, las direcciones de CORBA son las referencias a objeto.

El problema del "binding" es solucionado en DCE facilitando funciones encargadas de realizar la asociación basándose en manejadores de "bindings". En CORBA cada objeto definido en la especificación de la interface posee una función de binding, que se encuentra en cada referencia a ese objeto.

Para tratar el tema de los nombres ambos sistemas proveen una serie de servicios. En el caso de DCE se suministra el Cell Directory Service, mientras el servicio de nombres de CORBA está englobado entre los Common Object Services.

Tanto las direcciones como los nombres constituyen un problema cuando se intenta traspasar la frontera del sistema implementado, es decir, si tuviésemos una red en la que parte está implementada en DCE y parte en CORBA y quisiéramos comunicar una parte con la otra. Este problema podría resolverse utilizando nombres federados y localizadores. El nombre federado tendrá varios campos y el localizador utilizará el campo correspondiente según estemos en un implementación orientada a objeto o a procedimiento.

En cuanto a los Interface Definition Languages, DCE tan solo permite un interface por IDL mientras que el número en CORBA es ilimitado. Además, como ya se ha explicado DCE permite transmitir por la red datos de tipo puntero, algo que CORBA no contempla.

EL IDL de DCE no permite, como ya se ha señalado, la herencia en los interfaces y define un espacio de nombres compartido. CORBA permite la herencia de interfaces y define su espacio de nombres de forma jerárquica.

CORBA define el Interface Repository que contiene información equivalente a la de los ficheros IDL, pero que puede ser accedida en tiempo de compilación. DCE no posee este tipo de "reposiciones".

Además del "static stub interface", CORBA define la "dynamic invocation interface" , que puede ser usada por un cliente para invocar una operación cualquiera en un tipo de objeto cualquiera en tiempo de ejecución. En DCE las stubs de RPC apropiadas deben ser linkadas en el cliente DCE.

CORBA permite la activación automática de sus servidores, de forma que, si un servidor al que va dirigida una petición está desactivado, un ORB se encargará de ponerlo en marcha. La activación de los servidores en entornos DCE debe ser manual.

Los servicios que DCE puede ofrecer a una aplicación son muy limitados si los comparamos con los que ofrece la arquitectura de CORBA, con un conjunto de posibilidades muy rico con las que construir más servicios además de los que ya ofrece.
 

C ) Sobre los tipos de datos

• "Vectores variantes", en DCE el servidor almacena el array completo, que tiene una longitud fija, y se pasa al cliente de forma troceada, CORBA no posee un tipo de datos similar a este, aunque podríamos imitar este comportamiento con "sequences".
• Los "DCE pipes" permiten el paso de parámetros de gran longitud en series de pequeños bloques, de forma que se segmentan tanto la transmisión como el procesado de dichos parámetros. CORBA no permite segmentación en los parámetros por lo que ésta debe realizarse directamente en las operaciones, que deben descomponerse en series de operaciones más pequeñas.
• DCE soporta "contextos". Un contexto es un mecanismo para mantener el estado del servidor durante la comunicación con un cliente a través de sucesivas llamadas. El funcionamiento es el siguiente: el estado del servidor se pasa como una estructura contexto opaca al cliente. Éste lo incluirá en sus RPC's al servidor de forma que cuando el servidor reciba un petición utilizará y modificará convenientemente dicha información. DCE provee el soporte para contexto directamente en el client y server stubs, mientras que CORBA no tiene ningún mecanismo de este tipo sino que es el programador el que manualmente ha de controlar el cambio de contexto. No hay que confundir este tipo de datos con los contextos de CORBA que son utilizados para transportar las preferencias de cada user junto con una petición a un objeto.
• DCE soporta el uso de punteros incluso como parámetros o como parte de una estructura que se pasa como parámetro. Lógicamente este tipo de parámetros no se pasa de cliente a servidor como una dirección, que pierde su validez en un entorno distribuido. Los paquetes de sistemas en tiempo de ejecución encargados de preparar las peticiones transforman esta dirección en el dato adecuado. CORBA no permite utilizar punteros ni como parámetros ni como parte de ellos. El conjunto de tipos básicos de IDL no los incluye. Esto le deja al programador dos opciones, o bien se escribe código capaz de convertir los valores direccionados por los punteros a estructuras adecuadas libres de punteros en el cliente y reconstruir los parámetros complejos en el servidor, o bien, el programador puede redefinir la estructura de datos como una colección de uno o más objetos, aprovechando que CORBA da soporte a estructuras complejas compuestas de objetos.
• CORBA soporta el tipo de dato "any" que DCE no soporta. Este tipo nos permite pasar un valor de cualquier tipo entre un cliente y un servidor. Junto con el valor del dato se pasa también un campo que indica de qué tipo es.

D ) Conclusión:

Por todo lo expuesto debemos resumir que, si se desea un entorno distribuido podemos basarnos en cualquiera de las dos especificaciones. Si lo que queremos es un entorno distribuido orientado a objeto deberemos pensar en la especificación CORBA. Los servicios que nos ofrecen ambas son muy similares, cada uno con sus particularidades pero que viene a desempeñar el mismo trabajo.