¿El legado de CORBA es?

Question

Para un proyecto de computación distribuida a partir de hoy, con 0 componentes heredados, ¿hay alguna buena razón para investigar CORBA?

Answer 1

Todavía hay situaciones en CORBA podría ser una buena respuesta:

• cuando se está construyendo un sistema distribuido que involucra múltiples programación idiomas y múltiples plataformas,
• cuando el sistema implica el envío de datos complejos estructuras ... y SOAP no es suficiente,
• cuando se tiene altas tasas de mensajería ... y HTTP no es suficiente, o
• cuando tiene que interactuar con clientes CORBA existentes y/o servicios .

Pero una vez dicho esto, hay alternativas que hacen lo que CORBA hace, solo que mejor ... o eso dicen. Por ejemplo ZeroC's ICE

EDITAR @fnieto interviene para decir (o implica) que el ICE no es libre, pero es TAO.

Esto es inexacto y engañoso.

1. ICE es un software GPL, y está disponible para su descarga gratuita. Solo tenía que pagar ICE si usted o su empresa no están preparados para vivir con los términos de la GPL. (O si necesita asistencia)
2. Utilicé ICE como ejemplo de una alternativa a CORBA. TAO es CORBA. Los autores de ICE presentan un caso verosímil de por qué pueden obtener un mejor rendimiento al no cumplir con CORBA.
3. TAO no es de ninguna manera la única implementación de CORBA gratuita/de código abierto. Puedo pensar en otras 3, fuera de mi cabeza.

La desventaja de ICE es la falta de interoperabilidad con las pilas de middleware CORBA, pero en mi experiencia la interoperabilidad de las diferentes implementaciones de CORBA también podría ser problemática. (Las cosas pueden haber mejorado en esa área ... pero no he hecho ningún trabajo de CORBA desde ~ 2002, así que estoy un poco fuera de contacto.)

Answer 2

Diría que el nivel actual de madurez de los servicios web (incluido REST) ​​y en los EJB de Java (que incluso pueden usar CORBA bajo las carátulas) cubre lo que se necesita para los sistemas empresariales distribuidos.

Aconsejo que un aspecto que debe observar cuidadosamente es el grado de interacción asincrónica que necesita en su sistema distribuido. Postulo que cualquier sistema distribuido de una escala no trivial necesita comunicaciones asincrónicas, y la infraestructura elegida debe soportar el procesamiento de asincronización, generalmente eso significa colas.

Eso no es incompatible con el uso de servicios web (o de hecho CORBA), pero sí apunta a un aspecto de la selección de productos que pueden ser pasados ​​por alto en el entusiasmo inicial de conseguir un poco de procesamiento distribuido va

Answer 3

CORBA es ciertamente viejo formado, pero también proporciona ciertas funciones de alto nivel listas para usar (ver here). Esta funcionalidad podría hacerse usando servicios web modernos, pero probablemente no de manera estándar, y no sin una gran cantidad de trabajo adicional.

Para el 99% de los servicios distribuidos, sin embargo, CORBA no es deseable. Es feo, complejo y difícil de usar.

Answer 4

Creo que Corba fue revivido por EJB original especificaciones, ya que los EJB se pueden convertir fácilmente en beans CORBA mediante un poco de configuración. Sospecho que la mayoría de las implementaciones de Corba se implementaron realmente en Java.

En cuanto a la popularidad, creo que puede haber algunos despliegues de gama alta restantes durante varias décadas, pero para la mayoría de las personas Corba está muerto.

Hay muchas maneras muy sexys de hacer lo mismo (excepto el extremo superior mencionado anteriormente).

• Computación en la nube (servicios web, informática escalable, acoplamiento flexible, colas).
• Servicios REST (servicios web lite).
• servicios SOAP (servicios web pesados).
• cuadrícula/Cluster de Computación (colas, mapas reducir y similares)

Pero por supuesto, su Milage puede variar.

Answer 5

A partir de las respuestas existentes, esto se convierte en un tema casi religioso. Uno puede ver CORBA de la misma manera que el vaso medio vacío/medio lleno: por un lado, CORBA está anticuado, y por otro lado es relativamente estable con varias implementaciones disponibles y el "demonio que conoces".

En mi trabajo, veo que CORBA se implementa en sistemas integrados, sistemas en tiempo real (CORBA tiene extensiones RT) y similares. No hay muchas alternativas AFAIK.

Otra "ventaja" de CORBA es la disponibilidad de varias implementaciones de código abierto de alta calidad, por ejemplo, TAO, MICO, JacORB, etc., con diferentes modelos de licencia y soporte. También hay todavía ediciones comerciales disponibles.

Con respecto a la "mayoría" de las aplicaciones CORBA implementadas en Java, ese no es el caso en mi experiencia. Si bien el mapeo de idiomas para CORBA a Java es uno de los más bonitos (lo que puede no decir mucho), Java ya tiene un modelo de computación distribuida muy agradable que ofrece riqueza más allá de CORBA, y todas las aplicaciones Java usan eso más que CORBA. La gran mayoría del desarrollo de CORBA que he visto está en C++ (que también es el peor mapeo de lenguaje).

Finalmente, CORBA ofrece invocaciones asincrónicas estandarizadas del lado del cliente en forma de AMI, pero nunca ofreció un manejo asíncrono en el lado del servidor. TAO ofrece una implementación no estándar del lado del servidor llamada AMH.

Answer 6

Obviamente, depende del tipo de servidor y de la comunicación entre procesos que esté considerando. Y creo que Stephen C y Chris Cleeland cubren los aspectos positivos de Corba muy bien.

Nuestra aplicación ha utilizado CORBA (Orbix) durante más de 10 años, por lo que ahora es un legado. Y por cómo está escrito, CORBA es una buena tecnología.Sin embargo, si yo estaba empezando de nuevo que probablemente no usar CORBA:

• Es complicado y sólo un pequeño número de personas en mi organización sabe muy bien como resultado todos los problemas duros caen sobre ellos para resolver.
• Reclutar personal puede ser un problema. CORBA ya no es genial y no se está enfriando. Aunque en Irlanda, los desarrolladores de C++ también son un poco delgados.
• La mayoría de las firmas consultoras desean utilizar los servicios web para el trabajo de integración, por lo que si desea que terceras partes realicen la integración probablemente necesite una API de servicios web de todos modos.

Ahora dependiendo del tipo de comunicación que quería yo probablemente considerar:

• búferes de protocolo para un montón de mensajes pequeños (sé que tendría que proporcionar el transporte)
• servicios web un menor número de mensajes de gran tamaño

Esto se basa más en la búsqueda de personal y conocimientos, el apoyo tercera parte y el aprovechamiento de las bibliotecas de código abierto entonces la calidad técnica de CORBA, que utilizo todos los días y es fuerte si es un poco engorroso.

Answer 7

Una cosa que nadie ha mencionado aquí es OPEN, OPEN STANDARDS. De todas las tecnologías que existen (excepto SOAP), es la única norma verdadera de papel blanco abierto. El estándar no depende de las tecnologías de ninguna organización. RMI (Sun/Oracle), DCOM (ahora desaparecido - Microsoft). Es completamente independiente del vendedor y del lenguaje. Excepto SOAP, ninguna de las otras tecnologías de DOS (tecnología de objetos distribuidos) es

Soy un arquitecto de software y tengo que elegir regularmente qué DOS debe usarse en un diseño de sistema. Si no fuera por la guerra religiosa que enfrento cada vez, sería una MAMÁ o CORBA.

Mírelo de esta manera, si fuera así de muerto, ninguna de las redes 3/4G funcionaría. 3GPP está totalmente especificado por CORBA. El Sistema Europeo de Satélites está especificado en CORBA. Pregúntense por qué? ¡Es porque deben basarse en las arquitecturas neutrales de proveedores y lenguajes!