oma - ¿Por qué perdió CORBA popularidad?

oma corba

Question

Nunca he escuchado a nadie hablar de CORBA en nada más que términos burlones, lo cual es extraño teniendo en cuenta que hace más de 10 años eran las rodillas de la abeja. ¿Por qué CORBA cayó en desgracia? ¿Era puramente que las implementaciones eran malas o había algo más fundamental?

Answer 1

Hay una sección sobre sus problemas y críticas en el artículo de la wikipedia: http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

Answer 2

Las tecnologías de objetos distribuidos como CORBA y DCOM tenían problemas de granularidad: las implementaciones tendían a ser demasiado "parlanchinas" para funcionar bien en una red, y generalmente filtraban detalles de implementación que hacían frágil la solución.

La Orientación al Servicio ganó prominencia como una reacción a esas preocupaciones.

Answer 3

No es solo CORBA, es RPC en general. Esto incluye cosas como DCOM, Java-RMI, .NET Remoting y todos los demás también.

El problema es básicamente que la computación distribuida es fundamentalmente diferente de la informática local. RPC intenta simular que estas diferencias no existen y hace que las llamadas remotas se vean como llamadas locales. Pero, para construir un buen sistema distribuido, necesita lidiar con esas diferencias.

Bill Joy, Tom Lyon, L. Peter Deutsch y James Gosling identificaron 8 falacias de computación distribuida , es decir, cosas que los recién llegados a la programación distribuida creen que son ciertas, pero que en realidad son falsas, lo que generalmente resulta en la falla del proyecto o un aumentar el costo y el esfuerzo RPC es la encarnación perfecta de esas falacias, porque se basa en las mismas suposiciones erróneas:

1. La red es confiable.
2. Latencia es cero.
3. El ancho de banda es infinito.
4. La red es segura.
5. La topología no cambia
6. Hay un administrador.
7. El costo de transporte es cero.
8. La red es homogénea

Todo esto es cierto para la informática local.

Tomemos la fiabilidad, por ejemplo: si llama a un método localmente, la llamada en sí misma siempre tiene éxito. Claro, el método llamado en sí puede tener un error, pero la llamada real del método siempre tendrá éxito. Y el resultado siempre será devuelto, o, si el método falla, se señalará un error.

En un sistema distribuido, esto no es cierto: el acto de llamar al método en sí puede fallar. Es decir, desde su final, parece que usted llamó al método, pero la llamada realmente se perdió en la red y nunca llegó al método. O bien, el método recibió correctamente la llamada y realizó la operación, pero el resultado se perdió en el camino de regreso a usted. O el método falló, pero el error se perdió.

Similar con la latencia: localmente, llamar a un método es esencialmente gratuito. El método en sí puede tomar una cantidad arbitraria de tiempo para calcular la respuesta, pero la llamada es gratuita. En una red, una llamada puede tomar cientos de milisegundos.

Es por eso que prácticamente todos los proyectos de RPC, incluido CORBA, fallaron.

Tenga en cuenta que a la inversa funciona bien: si solo pretende que todas las llamadas son llamadas remotas , entonces lo peor que puede pasar es que pierda un poco de rendimiento y su aplicación contiene algún código de manejo de errores que nunca se utilizará. . Así es como funciona Erlang, por ejemplo.

En Erlang, los procesos siempre tienen montones separados y recolectores de basura por separado, al igual que si se ejecutaran en diferentes máquinas en diferentes continentes, incluso si esos procesos se ejecutan en la misma máquina virtual en la misma CPU en el mismo espacio de direcciones. Si transfiere datos de un proceso a otro, esos datos siempre se copian, como debería ser, si los procesos se encontraban en máquinas diferentes. Las llamadas siempre se realizan como envíos de mensajes asincrónicos.

Por lo tanto, hacer que las llamadas locales y remotas tengan el mismo aspecto no es el problema. Hacer que se vean como llamadas locales es.

En CORBA, el problema es en realidad un poco más enrevesado que eso. De hecho, hicieron que las llamadas locales parecieran llamadas remotas, pero como CORBA fue diseñado por el comité, las llamadas remotas eran increíblemente complejas, porque tenían que ser capaces de manejar algunos requisitos increíblemente absurdos. Y esa complejidad se impuso a todos , incluso para llamadas locales.

De nuevo, comparando con Erlang, la complejidad es mucho menor. En Erlang, enviar un mensaje a un proceso no es más complejo que llamar a un método en Java. La interfaz es básicamente la misma, solo las expectativas son diferentes: se espera que las llamadas a métodos en Java sean instantáneas y síncronas; en Erlang, se espera que los envíos de mensajes sean asincrónicos y tengan latencia visible. Pero en realidad usarlos no es más complicado que una simple llamada de procedimiento local.

Otra diferencia es que Erlang distingue entre llamadas a funciones, que solo pueden ocurrir dentro de un proceso y, por lo tanto, son siempre locales, y envíos de mensajes, que ocurren entre procesos y se supone que siempre son remotos, incluso si no lo son. En CORBA, se supone que todas las llamadas a métodos son remotas.