•  22-07-2019
  •  | 
  •  

Pregunta

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

¿Fue útil?

Solución

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

  • cuando está construyendo un distribuido sistema que involucra programación múltiple idiomas y plataformas múltiples,
  • cuando su sistema implica enviar estructuras de datos complejas ... y SOAP no lo corta,
  • cuando tiene altas tasas de mensajería ... y HTTP no lo corta, o
  • cuando tienes que interactuar con clientes CORBA existentes y / o servicios.

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

EDITAR @fnieto interviene para decir (o insinuar) que ICE no es gratis, pero TAO sí.

Esto es inexacto y engañoso .

  1. ICE es un software GPL y está disponible para descarga gratuita. Solo necesita pagar ICE si usted / su empresa no están preparados para vivir con los términos de la GPL. (O si necesita ayuda).
  2. Usé ICE como ejemplo de una alternativa a CORBA. TAO es CORBA. Los autores de ICE presentan un caso creíble de por qué pueden obtener un mejor rendimiento al no cumplir con CORBA.
  3. TAO no es la única implementación de CORBA gratuita / de código abierto. Puedo pensar en otros 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 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 CORBA desde ~ 2002, así que estoy un poco fuera de contacto).

Otros consejos

De las respuestas existentes, esto se mete casi en un tema religioso. Uno puede ver CORBA de la misma manera que el vaso medio vacío / medio lleno: por un lado, CORBA es anticuado legacy cruft, y por otro lado es relativamente estable con varias implementaciones disponibles y el '' diablo que conoces ''.

En mi línea de trabajo, veo CORBA implementado en sistemas embebidos, 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 todavía hay ediciones comerciales disponibles.

Con respecto a " la mayoría " Las aplicaciones CORBA se implementan en Java, ese no es el caso en mi experiencia. Si bien el mapeo de lenguaje para CORBA a Java es uno de los mejores (lo que no puede decir mucho), Java ya tiene un modelo de computación distribuida muy agradable que ofrece riqueza más allá de CORBA, y las aplicaciones Java utilizan 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 asíncronas estandarizadas del lado del cliente en forma de AMI, pero nunca ofreció manejo asíncrono en el lado del servidor. TAO ofrece una implementación no estándar del lado del servidor llamada AMH.

Creo que Corba fue revivido por la especificación original de EJB, ya que los EJB pueden convertirse 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 podría haber algunas implementaciones de gama alta restantes durante varias décadas, pero para la mayoría de las personas Corba está muerta.

Hay muchas maneras muy sexys de hacer lo mismo (a excepción de la gama alta mencionada anteriormente).

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

Pero, por supuesto, su Milage puede variar.

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

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

  • Es complicado y solo un pequeño número de personas en mi organización lo sabe muy bien, como resultado, todos los problemas difíciles recaen sobre ellos.
  • 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 terceros hagan la integración, de todos modos probablemente necesitará una API de servicios web.

Ahora, dependiendo del tipo de comunicación que quisiera, probablemente consideraría:

  • memorias intermedias de protocolo para muchos mensajes pequeños (sé que tendría que proporcionar el transporte)
  • servicios web para menos mensajes grandes

Esto se basa más en encontrar personal y experiencia, soporte de terceros y aprovechar las bibliotecas de código abierto y luego en la calidad técnica de CORBA, que uso todos los días y es fuerte aunque un poco engorroso.

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

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

Una cosa que nadie ha mencionado aquí es ABRIR, ABRIR NORMAS. De todas las tecnologías que existen (excepto SOAP), es el único estándar de papel blanco abierto verdadero. El estándar no depende de las tecnologías de ninguna organización. RMI (Sun / Oracle), DCOM (ahora difunto - Microsoft). Es completamente proveedor y lenguaje neutral. Excepto SOAP, ninguna de las otras tecnologías de DOS (Tecnología de Objetos Distribuidos) son

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

Míralo de esta manera, si estuviera tan muerto, ninguna de las redes 3 / 4G funcionaría. 3GPP está totalmente especificado en CORBA. El sistema europeo de satélites está especificado por CORBA. Pregúntense por qué? ¡Es porque deben basarse en arquitecturas neutrales de proveedores y lenguaje!

Diría que el nivel actual de madurez de los servicios web (incluido REST) ??y en los EJB del mundo de Java (que incluso pueden usar CORBA bajo las cubiertas) cubren lo que se necesita para los sistemas empresariales distribuidos.

Aconsejaría que un aspecto que debe observar detenidamente es el grado de interacción asincrónica que necesita en su sistema distribuido. Supongo que cualquier sistema distribuido de una escala no trivial necesita comunicaciones asincrónicas, y la infraestructura elegida debería soportar el procesamiento asíncrono, generalmente eso significa colas.

Eso no es inconsistente con el uso de WebServices (o de hecho CORBA) pero señala un aspecto de su selección de productos que puede pasarse por alto en la emoción inicial de poner en marcha un procesamiento distribuido

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top