objetos - oma corba

¿Legado de CORBA? (7)

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 línea de 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.

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

CORBA ciertamente está pasado de moda, 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.

Creo que Corba fue revivido por las especificaciones EJB originales, 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 realmente en Java.

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

Hay muchas formas muy sexys de hacer lo mismo (excepto el extremo superior mencionado 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 (haciendo cola, map-reduce y similar)

Pero, por supuesto, tu Milage May Vary.

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 comenzaba de nuevo, probablemente no usaría CORBA:

Es complicado y solo un pequeño número de personas en mi organización lo saben muy bien, por lo que todos los problemas difíciles recaen sobre ellos para resolverlo.
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 lo hagan, probablemente necesite una API de servicios web.

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 aprovechamiento de 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.

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 el envío de estructuras de datos complejas ... y SOAP no lo corta,
cuando tiene altas tasas de mensajes ... y HTTP no lo corta, o
cuando tiene que interactuar con los clientes y / o servicios existentes de CORBA.

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

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

Esto es inexacto y engañoso .

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 ayuda).
Usé 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.
TAO de ninguna manera es 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 de 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).

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. Con la excepción de 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í, 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!

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

Aconsejo que un aspecto que debe analizar 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 inconsistente con el uso de WebServices (o de hecho CORBA), pero sí apunta hacia un aspecto de su selección de productos que puede ser pasado por alto en la excitación inicial de lograr que el procesamiento distribuido funcione.