¿Es el legado de CORBA?

79

Para un proyecto de computación distribuida que comienza hoy, sin componentes heredados, ¿existen buenas razones para investigar CORBA?

corba 
— flybywire
fuente
27
Para ser honesto, no estoy seguro de que alguna vez hayan tenido buenas razones: es una tecnología horrible. Hablo aquí como ex programador de CORBA.
2
La buena razón fue que cuando CORBA apareció por primera vez, no había una alternativa viable (a menos que pudieras usar DCOM o DCE).
— skaffman
@skaffman Había alternativasw, cosas como TIBCO, por ejemplo.
Claro, pero eso era igualmente feo, por no mencionar caro.
— skaffman
3
@Skaffman ¡Estás bromeando! TIBCO Rendezvous fue / es al menos 10 veces más fácil de usar que CORBA. En cuanto a los gastos, me imagino que los IB que usan estas cosas pueden permitírselo. O al menos podían, en ese entonces.

Respuestas:

46

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

  • cuando está construyendo un sistema distribuido que involucra múltiples lenguajes de programación y múltiples plataformas,
  • 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 tenga que interactuar con clientes y / o servicios de CORBA existentes.

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

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

Esto es inexacto y engañoso .

  1. ICE es un software con licencia GPL y está disponible para su descarga gratuita. Solo tenía que pagar por ICE si usted o su empresa no están preparados para cumplir con los términos de la GPL. (O si necesita apoyo).
  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 desempeño si no cumplen con CORBA.
  3. TAO no es de ninguna manera la única implementación 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).

— Stephen C
fuente
Con respecto al punto 1: esperaba que CORBA y los servicios web fueran más o menos equivalentes desde una perspectiva multiplataforma y entre idiomas. Cada uno tendrá puntos débiles que no cubren, pero en general no veo mucha diferencia. Para este escenario no heredado, no veo que esto sea un problema.
— djna
@djna: pero considere que la aplicación no heredada de hoy es la aplicación heredada del mañana. El uso de una tecnología de middleware multilenguaje / multiplataforma hoy puede ayudarlo en 5 a 10 años cuando se integre con la próxima generación de aplicaciones empresariales.
— Stephen C
@Stephen. El único problema con ICE es el precio, TAO es gratis.
— fnieto - Fernando Nieto
3
Bien dicho. De hecho, Java es una implementación de CORBA gratuita muy llamativa. Y el hecho de que J2EE requiera IIOP como su transporte significa que CORBA es probablemente más omnipresente y "actual" ahora que nunca.
— user207421
33

De las respuestas existentes, esto entra en un tema casi religioso. Se 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 "diablo que sabes".

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 hay ediciones comerciales disponibles.

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

— Chris Cleeland
fuente
20

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

En cuanto a la popularidad, creo que puede que queden algunas implementaciones de alto nivel durante varias décadas, pero para la mayoría de las personas, Corba está muerta.

Hay muchas formas muy sexys de hacer las mismas cosas (excepto la gama alta mencionada anteriormente).

  • Computación en la nube (servicios web, computación escalable, acoplamiento flexible, colas).
  • Servicios REST (web-services lite).
  • Servicios SOAP (servicios web pesados).
  • Computación Grid / Cluster (cola, reducción de mapas y similares)

Pero, por supuesto, su milagro puede variar.

— Andrew Russell
fuente
15

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 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 un legado. Y por cómo está escrito CORBA es una buena tecnología. Sin embargo, si estuviera comenzando de nuevo, probablemente no usaría CORBA:

  • Es complicado y solo un pequeño número de personas en mi organización lo conocen muy bien, por lo que todos los problemas difíciles recaen sobre ellos para resolverlos.
  • La contratación de personal puede ser un problema. CORBA ya no es genial y no se está volviendo más genial Aunque en Irlanda los desarrolladores de C ++ también son un poco débiles en el terreno.
  • La mayoría de las empresas consultoras desean utilizar servicios web para el trabajo de integración, por lo que si desea que terceros realicen la integración, probablemente necesitará una API de servicios web de todos modos.

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

  • búferes 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 que en la calidad técnica de CORBA, que uso todos los días y es fuerte aunque un poco engorroso.

— iain
fuente
@iain: buenos puntos. CORBA no es fácil de usar incluso desde Java, donde hice la mayor parte de mi desarrollo CORBA. Las cosas de POA / BOA son difíciles de entender.
— Stephen C
3
Si las cosas POA en particular, es más difícil de lo que debería ser
— Iain
2
Con la estandarización de IDL a C ++ 11, el aprendizaje de mapas de idiomas y el uso de CORBA es mucho más fácil. El mapeo de idiomas es sencillo y reutiliza tanto como puede desde STL. Todavía necesita aprender el POA, pero eso no es realmente difícil.
— Johnny Willemsen
13

CORBA es ciertamente anticuado, pero también proporciona ciertas funciones de alto nivel listas para usar (ver aquí ). Toda esta funcionalidad podría realizarse 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.

— skaffman
fuente
12
Y dado ese último punto, es por eso que a la gente se le ocurrió jabón / ws- *. Lo que ahora también es feo y complejo.
— leeeroy
Soap no es tan feo cuando trabajas con marcos que hacen la mayor parte del trabajo detrás de escena por ti.
— arg20
¿Qué alternativas sugieres?
— Schoetbi
5
@ arg20 - Eso es un poco como decir que SOAP no es tan feo si no puedes verlo :-)
— Stephen C
12

Una cosa que nadie ha mencionado aquí es ESTÁNDARES ABIERTOS, ABIERTOS. De todas las tecnologías que existen (excepto SOAP), es el único estándar de papel blanco verdaderamente abierto. El estándar no depende de las tecnologías de ninguna organización. RMI (Sun / Oracle), DCOM (ahora desaparecido - Microsoft). Es completamente neutral respecto del idioma y el proveedor. Excepto SOAP, ninguna de las otras tecnologías DOS (Tecnología de objetos distribuidos)

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

Mírelo de esta manera, si estuviera tan muerto, ninguna de las redes 3 / 4G funcionaría. 3GPP está totalmente especificado en CORBA. El Sistema de Satélites Europeo es todo CORBA especificado. Pregúntense por qué. ¡Es porque deben basarse en arquitecturas neutrales al proveedor y al idioma!

— Selvyn
fuente
2
Ermm ... en el pasado, estuve involucrado en el desarrollo de estándares OMG, y puedo decirles que los procesos no siempre fueron tan abiertos y transparentes como uno podría esperar. Y el OMG históricamente se ha mantenido alejado del tema del cumplimiento ... no es que IETF o W3C lo hagan mucho mejor en eso.
— Stephen C
1+ @Selvyn Estaba buscando esta información
— Tony Shih
@Selvyn, Michi Henning presenta un argumento bastante convincente en sentido contrario, que la apertura de OMG es una causa sistémica de sus problemas: queue.acm.org/detail.cfm?id=1142044 . Buena lectura.
— semiseguro
9

Yo diría que el nivel actual de madurez de los servicios web (incluido REST) ​​y en el mundo de Java EJB (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 considerar cuidadosamente es el grado de interacción asincrónica que necesita en su sistema distribuido. Postulo que cualquier sistema distribuido de escala no trivial necesita comunicaciones asincrónicas, y la infraestructura elegida debe soportar el procesamiento asincrónico, por lo general eso significa colas.

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

— djna
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.