stringtranslate.com

Arquitectura del agente de solicitud de objetos comunes

La arquitectura Common Object Request Broker ( CORBA ) es un estándar definido por Object Management Group (OMG) diseñado para facilitar la comunicación de sistemas que se implementan en diversas plataformas . CORBA permite la colaboración entre sistemas en diferentes sistemas operativos, lenguajes de programación y hardware informático. CORBA utiliza un modelo orientado a objetos, aunque los sistemas que utilizan CORBA no tienen por qué estar orientados a objetos. CORBA es un ejemplo del paradigma de objetos distribuidos .

Si bien CORBA fue brevemente popular a mediados y fines de la década de 1990, su complejidad, inconsistencia y altos costos de licencia lo han relegado a ser una tecnología de nicho. [1]

Descripción general

CORBA permite la comunicación entre software escrito en distintos lenguajes y que se ejecuta en diferentes computadoras. Los detalles de implementación de sistemas operativos, lenguajes de programación y plataformas de hardware específicos no son responsabilidad de los desarrolladores que utilizan CORBA. CORBA normaliza la semántica de llamadas a métodos entre objetos de aplicación que residen en el mismo espacio de direcciones (aplicación) o en espacios de direcciones remotos (mismo host o host remoto en una red). La versión 1.0 se lanzó en octubre de 1991.

CORBA utiliza un lenguaje de definición de interfaz (IDL) para especificar las interfaces que los objetos presentan al mundo exterior. CORBA luego especifica una asignación de IDL a un lenguaje de implementación específico como C++ o Java . Existen asignaciones estándar para Ada , C , C++ , C++11 , COBOL , Java , Lisp , PL/I , Object Pascal , Python , Ruby y Smalltalk . Existen asignaciones no estándar para C# , Erlang , Perl , Tcl y Visual Basic implementadas por intermediarios de solicitud de objetos (ORB) escritos para esos lenguajes. Las versiones de IDL han cambiado significativamente con anotaciones que reemplazan algunos pragmas.

La especificación CORBA establece que debe existir un ORB a través del cual una aplicación interactuaría con otros objetos. Así es como se implementa en la práctica:

  1. La aplicación inicializa el ORB y accede a un adaptador de objetos interno , que mantiene aspectos como el recuento de referencias , las políticas de instanciación de objetos (y referencias) y las políticas de duración de los objetos.
  2. El adaptador de objetos se utiliza para registrar instancias de las clases de código generadas . Las clases de código generadas son el resultado de compilar el código IDL del usuario, que traduce la definición de interfaz de alto nivel en una base de clase específica del SO y del lenguaje para que la utilice la aplicación del usuario. Este paso es necesario para aplicar la semántica CORBA y proporcionar un proceso de usuario limpio para interactuar con la infraestructura CORBA.

Algunas asignaciones de IDL son más difíciles de usar que otras. Por ejemplo, debido a la naturaleza de Java, la asignación de IDL a Java es bastante sencilla y hace que el uso de CORBA en una aplicación Java sea muy simple. Esto también es cierto en el caso de la asignación de IDL a Python. La asignación de C++ requiere que el programador aprenda tipos de datos anteriores a la Biblioteca de plantillas estándar (STL) de C++. Por el contrario, la asignación de C++11 es más fácil de usar, pero requiere un uso intensivo de STL. Dado que el lenguaje C no está orientado a objetos, la asignación de IDL a C requiere que un programador de C emule manualmente las características orientadas a objetos.

Para crear un sistema que utilice o implemente una interfaz de objetos distribuidos basada en CORBA, un desarrollador debe obtener o escribir el código IDL que define la interfaz orientada a objetos para la lógica que utilizará o implementará el sistema. Normalmente, una implementación de ORB incluye una herramienta denominada compilador IDL que traduce la interfaz IDL al lenguaje de destino para su uso en esa parte del sistema. A continuación, un compilador tradicional compila el código generado para crear los archivos de objetos enlazables para su uso en la aplicación. Este diagrama ilustra cómo se utiliza el código generado dentro de la infraestructura CORBA:

Ilustración de la autogeneración del código de infraestructura a partir de una interfaz definida utilizando el IDL CORBA
Ilustración de la autogeneración del código de infraestructura a partir de una interfaz definida utilizando el IDL CORBA

Esta figura ilustra el paradigma de alto nivel para las comunicaciones remotas entre procesos utilizando CORBA. La especificación CORBA aborda además la tipificación de datos, las excepciones, los protocolos de red, los tiempos de espera de las comunicaciones, etc. Por ejemplo: normalmente, el lado del servidor tiene el adaptador de objetos portátil (POA) que redirige las llamadas a los servidores locales o (para equilibrar la carga) a los otros servidores. La especificación CORBA (y, por lo tanto, esta figura) deja varios aspectos del sistema distribuido a la aplicación para que los defina, incluyendo la duración de los objetos (aunque las semánticas de recuento de referencias están disponibles para las aplicaciones), redundancia/conmutación por error, gestión de memoria, equilibrio dinámico de carga y modelos orientados a aplicaciones como la separación entre la semántica de visualización/datos/control (por ejemplo, consulte Modelo–vista–controlador ), etc.

Además de proporcionar a los usuarios un lenguaje y una especificación de llamada a procedimiento remoto (RPC) independiente de la plataforma, CORBA define servicios comúnmente necesarios, como transacciones y seguridad, eventos, tiempo y otros modelos de interfaz específicos del dominio.

Historial de versiones

Esta tabla presenta el historial de versiones del estándar CORBA. [2] [3] [4]

Tenga en cuenta que los cambios de IDL han progresado con anotaciones (por ejemplo, @unit, @topic) que reemplazan algunos pragmas.

Servicio

Un sirviente es el objetivo de invocación que contiene métodos para manejar las invocaciones de métodos remotos . En las versiones más nuevas de CORBA, el objeto remoto (en el lado del servidor) se divide en el objeto (que está expuesto a invocaciones remotas) y el sirviente (a quien la primera parte reenvía las llamadas de método) . Puede ser un sirviente por objeto remoto , o el mismo sirviente puede soportar varios objetos (posiblemente todos), asociados con el Adaptador de Objetos Portátil dado . El sirviente para cada objeto puede establecerse o encontrarse "una vez y para siempre" (activación del sirviente) o elegirse dinámicamente cada vez que se invoca el método en ese objeto (ubicación del sirviente). Tanto el localizador del sirviente como el activador del sirviente pueden reenviar las llamadas a otro servidor. En total, este sistema proporciona un medio muy poderoso para equilibrar la carga, distribuyendo las solicitudes entre varias máquinas. En los lenguajes orientados a objetos, tanto el objeto remoto como su sirviente son objetos desde el punto de vista de la programación orientada a objetos.

La encarnación es el acto de asociar un sirviente con un objeto CORBA para que pueda atender solicitudes. La encarnación proporciona una forma de sirviente concreta para el objeto CORBA virtual. La activación y la desactivación se refieren únicamente a los objetos CORBA, mientras que los términos encarnación y etherealización se refieren a los sirvientes. Sin embargo, la duración de los objetos y los sirvientes es independiente. Siempre encarnas un sirviente antes de llamar a activate_object(), pero lo inverso también es posible, create_reference() activa un objeto sin encarnar un sirviente, y la encarnación del sirviente se realiza posteriormente a pedido con un administrador de sirvientes.

ElPortable Object Adapter (POA) es el objeto CORBA responsable de dividir el manejador de invocación remota del lado del servidor en elobjetoy suservidor. El objeto se expone para las invocaciones remotas, mientras que el servidor contiene los métodos que realmente manejan las solicitudes. El servidor para cada objeto se puede elegir de forma estática (una vez) o dinámica (para cada invocación remota), en ambos casos permitiendo el reenvío de llamadas a otro servidor.

En el lado del servidor, los POA forman una estructura tipo árbol, donde cada POA es responsable de uno o más objetos que se sirven. Las ramas de este árbol pueden activarse o desactivarse de forma independiente, tienen un código diferente para la ubicación o activación del servidor y diferentes políticas de manejo de solicitudes.

Características

A continuación se describen algunas de las formas más importantes en que se puede utilizar CORBA para facilitar la comunicación entre objetos distribuidos.

Objetos por referencia

Esta referencia se adquiere a través de un localizador uniforme de recursos (URL) en forma de cadena, una búsqueda en NameService (similar al Sistema de nombres de dominio (DNS)) o se pasa como un parámetro de método durante una llamada.

Las referencias a objetos son objetos livianos que coinciden con la interfaz del objeto real (remoto o local). Las llamadas a métodos en la referencia dan como resultado llamadas posteriores al ORB y el bloqueo del hilo mientras se espera una respuesta, éxito o falla. Los parámetros, los datos de retorno (si los hay) y los datos de excepción son procesados ​​internamente por el ORB de acuerdo con el idioma local y la asignación del sistema operativo.

Datos por valor

El lenguaje de definición de interfaz CORBA proporciona la definición de comunicación entre objetos independiente del lenguaje y del sistema operativo. Los objetos CORBA se pasan por referencia, mientras que los datos (enteros, dobles, estructuras, enumeraciones, etc.) se pasan por valor. La combinación de objetos por referencia y datos por valor proporciona los medios para aplicar una gran tipificación de datos al compilar clientes y servidores, pero conservando la flexibilidad inherente al espacio de problemas CORBA.

Objetos por valor (OBV)

Aparte de los objetos remotos, CORBA y RMI-IIOP definen el concepto de OBV y Valuetypes. El código dentro de los métodos de los objetos Valuetype se ejecuta localmente de forma predeterminada. Si el OBV se ha recibido desde el lado remoto, el código necesario debe ser conocido a priori por ambos lados o descargado dinámicamente desde el remitente. Para que esto sea posible, el registro que define el OBV contiene la base de código, que es una lista separada por espacios de las URL desde donde se debe descargar este código. El OBV también puede tener los métodos remotos.

Modelo de componentes CORBA (CCM)

El modelo de componentes CORBA (CCM) es una incorporación a la familia de definiciones CORBA. [5] Se introdujo con CORBA 3 y describe un marco de aplicación estándar para los componentes CORBA. Aunque no depende de los " Enterprise Java Beans (EJB) dependientes del lenguaje", es una forma más general de EJB, que proporciona cuatro tipos de componentes en lugar de los dos que define EJB. Proporciona una abstracción de entidades que pueden proporcionar y aceptar servicios a través de interfaces con nombre bien definido llamadas puertos .

El CCM tiene un contenedor de componentes, donde se pueden implementar los componentes de software. El contenedor ofrece un conjunto de servicios que los componentes pueden utilizar. Estos servicios incluyen (pero no se limitan a) notificación , autenticación , persistencia y procesamiento de transacciones . Estos son los servicios más utilizados que requiere cualquier sistema distribuido y, al trasladar la implementación de estos servicios desde los componentes de software al contenedor de componentes, la complejidad de los componentes se reduce drásticamente.

Interceptores portátiles

Los interceptores portátiles son los "ganchos" que utilizan CORBA y RMI-IIOP para mediar las funciones más importantes del sistema CORBA. El estándar CORBA define los siguientes tipos de interceptores:

  1. Los interceptores IOR median la creación de nuevas referencias a los objetos remotos, presentados por el servidor actual.
  2. Los interceptores de cliente suelen mediar las llamadas de métodos remotos en el lado del cliente (llamador). Si el objeto Servant existe en el mismo servidor donde se invoca el método, también median las llamadas locales.
  3. Los interceptores de servidor median el manejo de las llamadas a métodos remotos en el lado del servidor (controlador).

Los interceptores pueden adjuntar información específica a los mensajes que se envían y a los IOR que se crean. Esta información puede ser leída posteriormente por el interceptor correspondiente en el lado remoto. Los interceptores también pueden generar excepciones de reenvío, redirigiendo la solicitud a otro destino.

Protocolo general interORB (GIOP)

El GIOP es un protocolo abstracto mediante el cual los intermediarios de solicitudes de objetos (ORB) se comunican. El Object Management Group (OMG) mantiene los estándares asociados con el protocolo . La arquitectura GIOP proporciona varios protocolos concretos, entre ellos:

  1. Protocolo Internet InterORB (IIOP): el Protocolo Internet Inter-Orb es una implementación del GIOP para su uso en Internet y proporciona un mapeo entre los mensajes GIOP y la capa TCP/IP .
  2. Protocolo SSL InterORB (SSLIOP): SSLIOP es IIOP sobre SSL , que proporciona cifrado y autenticación .
  3. Protocolo HyperText InterORB (HTIOP): HTIOP es IIOP sobre HTTP , que proporciona una omisión de proxy transparente.
  4. IOP comprimido (ZIOP): una versión comprimida de GIOP que reduce el uso del ancho de banda.

VMCID (ID de conjunto de códigos de proveedor menor)

Cada excepción CORBA estándar incluye un código menor para designar la subcategoría de la excepción. Los códigos de excepción menor son de tipo unsigned long y constan de un "Vendor Minor Codeset ID" (VMCID) de 20 bits, que ocupa los 20 bits de orden superior, y el código menor propiamente dicho, que ocupa los 12 bits de orden inferior.

Los códigos menores para las excepciones estándar están precedidos por el VMCID asignado a OMG, definido como la constante larga sin signo CORBA::OMGVMCID, que tiene el VMCID asignado a OMG ocupando los 20 bits de orden superior. Los códigos de excepción menores asociados con las excepciones estándar que se encuentran en la Tabla 3–13 en la página 3-58 se combinan con OMGVMCID para obtener el valor del código menor que se devuelve en la estructura ex_body (consulte la Sección 3.17.1, "Definiciones de excepciones estándar", en la página 3-52 y la Sección 3.17.2, "Códigos de excepciones menores estándar", en la página 3-58).

Dentro de un espacio asignado por un proveedor, la asignación de valores a los códigos menores queda en manos del proveedor. Los proveedores pueden solicitar la asignación de VMCID enviando un correo electrónico a [email protected]. Se puede encontrar una lista de los VMCID asignados actualmente en el sitio web de OMG en: https://www.omg.org/cgi-bin/doc?vendor-tags

Los VMCID 0 y 0xfffff están reservados para uso experimental. Los VMCID OMGVMCID (Sección 3.17.1, "Definiciones de excepciones estándar", en la página 3-52) y los de 1 a 0xf están reservados para uso OMG.

El Common Object Request Broker: arquitectura y especificación (CORBA 2.3)

Ubicación de Corba (CorbaLoc)

Ubicación de Corba (CorbaLoc) se refiere a una referencia de objeto en forma de cadena para un objeto CORBA que parece similar a una URL.

Todos los productos CORBA deben admitir dos URL definidas por OMG: " corbaloc: " y " corbaname: ". El propósito de estas es proporcionar una forma legible y editable para humanos de especificar una ubicación donde se puede obtener un IOR.

A continuación se muestra un ejemplo de corbaloc:

corbaloc::160.45.110.41:38693/StandardNS/Servidor de nombres-POA/_root

Un producto CORBA puede admitir opcionalmente los formatos " http: ", " ftp: " y " file: ". La semántica de estos es que proporcionan detalles sobre cómo descargar un IOR en cadena (o, recursivamente, descargar otra URL que eventualmente proporcionará un IOR en cadena). Algunos ORB ofrecen formatos adicionales que son exclusivos de ese ORB.

Beneficios

Los beneficios de CORBA incluyen independencia del lenguaje y del sistema operativo, libertad de implementaciones vinculadas a la tecnología, fuerte tipificación de datos, alto nivel de capacidad de ajuste y libertad de los detalles de las transferencias de datos distribuidos.

Independencia del lenguaje
CORBA fue diseñado para liberar a los ingenieros de las limitaciones que implicaba acoplar sus diseños a un lenguaje de software en particular. Actualmente, existen muchos lenguajes compatibles con varios proveedores de CORBA, siendo los más populares Java y C++. También existen implementaciones de C++11, C-only, Smalltalk, Perl, Ada, Ruby y Python, por mencionar solo algunas.
Independencia del sistema operativo
El diseño de CORBA está pensado para ser independiente del sistema operativo. CORBA está disponible en Java (independiente del sistema operativo), así como de forma nativa para Linux/Unix, Windows, Solaris, OS X, OpenVMS, HPUX, Android, LynxOS, VxWorks, ThreadX, INTEGRITY y otros.
Libertad frente a las tecnologías
Uno de los principales beneficios implícitos es que CORBA ofrece un campo de juego neutral para que los ingenieros puedan normalizar las interfaces entre varios sistemas nuevos y heredados. Al integrar C, C++, Object Pascal, Java, Fortran, Python y cualquier otro lenguaje o sistema operativo en un único modelo de diseño de sistema cohesivo, CORBA proporciona los medios para nivelar el campo y permitir que equipos dispares desarrollen sistemas y pruebas unitarias que luego se puedan unir para formar un sistema completo. Esto no descarta la necesidad de tomar decisiones básicas de ingeniería de sistemas, como subprocesos, tiempos, vida útil de los objetos, etc. Estas cuestiones son parte de cualquier sistema independientemente de la tecnología. CORBA permite que los elementos del sistema se normalicen en un único modelo de sistema cohesivo.
Por ejemplo, el diseño de una arquitectura de varios niveles se simplifica utilizando Java Servlets en el servidor web y varios servidores CORBA que contienen la lógica empresarial y encapsulan los accesos a la base de datos. Esto permite que las implementaciones de la lógica empresarial cambien, mientras que los cambios de interfaz tendrían que manejarse como en cualquier otra tecnología. Por ejemplo, una base de datos encapsulada en un servidor puede cambiar su esquema de base de datos para mejorar el uso o el rendimiento del disco (o incluso para cambiar el proveedor de la base de datos a gran escala), sin afectar las interfaces externas. Al mismo tiempo, el código heredado de C++ puede comunicarse con el código heredado de C/Fortran y el código de base de datos de Java, y puede proporcionar datos a una interfaz web.
Tipificación de datos
CORBA proporciona una tipificación de datos flexible, por ejemplo, un tipo de datos "ANY". CORBA también aplica una tipificación de datos estrechamente acoplada, lo que reduce los errores humanos. En una situación en la que se pasan pares Nombre-Valor, es concebible que un servidor proporcione un número cuando se esperaba una cadena. El lenguaje de definición de interfaz CORBA proporciona el mecanismo para garantizar que el código de usuario se ajuste a los nombres de métodos, tipos de retorno y de parámetros, y excepciones.
Alta capacidad de ajuste
Muchas implementaciones (por ejemplo, ORBexpress (implementación de Ada, C++ y Java) [6] y OmniORB (implementación de código abierto en C++ y Python) [7] tienen opciones para ajustar las características de administración de conexiones y subprocesos. No todas las implementaciones de ORB brindan las mismas características.
Libertad de detalles de transferencia de datos
Al gestionar conexiones y subprocesos de bajo nivel, CORBA proporciona un alto nivel de detalle en las condiciones de error. Esto se define en el conjunto de excepciones estándar definido por CORBA y en el conjunto de excepciones extendidas específicas de la implementación. A través de las excepciones, la aplicación puede determinar si una llamada falló por razones como "Problema menor, inténtelo de nuevo", "El servidor está inactivo" o "La referencia no tiene sentido". La regla general es: no recibir una excepción significa que la llamada al método se completó correctamente. Esta es una característica de diseño muy poderosa.
Compresión
CORBA organiza sus datos en formato binario y admite la compresión. IONA, Remedy IT y Telefónica han trabajado en una extensión del estándar CORBA que permite la compresión. Esta extensión se llama ZIOP y ahora es un estándar OMG formal.

Problemas y críticas

Si bien CORBA ha aportado mucho en cuanto a la forma de escribir el código y construir el software, ha sido objeto de críticas. [8]

Gran parte de las críticas a CORBA se deben a implementaciones deficientes de la norma y no a deficiencias de la norma en sí. Algunas de las fallas de la norma en sí se debieron al proceso mediante el cual se creó la especificación CORBA y a los compromisos inherentes a la política y el negocio de escribir una norma común a partir de la participación de muchos implementadores que compiten entre sí.

Incompatibilidades de implementación inicial
Las especificaciones iniciales de CORBA definían únicamente el IDL, no el formato en línea. Esto significaba que la compatibilidad del código fuente era la mejor disponible durante varios años. Con CORBA 2 y posteriores, este problema se resolvió.
Transparencia de ubicación
La noción de transparencia de ubicación de CORBA ha sido criticada; es decir, que los objetos que residen en el mismo espacio de direcciones y son accesibles con una simple llamada de función son tratados de la misma manera que los objetos que residen en otro lugar (diferentes procesos en la misma máquina o diferentes máquinas). Este es un defecto de diseño fundamental, [9] [ verificación fallida ] ya que hace que todo acceso a objetos sea tan complejo como el caso más complejo (es decir, llamada de red remota con una amplia clase de fallas que no son posibles en llamadas locales). También oculta las diferencias ineludibles entre las dos clases, lo que hace imposible que las aplicaciones seleccionen una estrategia de uso apropiada (es decir, una llamada con una latencia de 1  μs y un retorno garantizado se usará de manera muy diferente a una llamada con una latencia de 1 s con posible falla de transporte, en la que el estado de entrega es potencialmente desconocido y podría demorar 30 s en agotarse).
Deficiencias de diseño y proceso
La creación del estándar CORBA también se cita a menudo por su proceso de diseño por parte de un comité . No había un proceso para arbitrar entre propuestas conflictivas o para decidir la jerarquía de problemas a abordar. Por lo tanto, el estándar se creó tomando una unión de las características de todas las propuestas sin tener en cuenta su coherencia. [10] Esto hizo que la especificación fuera compleja, costosa de implementar por completo y, a menudo, ambigua.
Un comité de diseño compuesto por una mezcla de proveedores de implementación y clientes creó un conjunto diverso de intereses. Esta diversidad dificultó la creación de un estándar cohesivo. Los estándares y la interoperabilidad aumentaron la competencia y facilitaron el movimiento de los clientes entre implementaciones alternativas. Esto condujo a muchas luchas políticas dentro del comité y a frecuentes lanzamientos de revisiones del estándar CORBA que algunos implementadores de ORB aseguraron que eran difíciles de usar sin extensiones propietarias. [8] Los proveedores de CORBA menos éticos fomentaron la dependencia del cliente y lograron sólidos resultados a corto plazo. Con el tiempo, los proveedores de ORB que fomentan la portabilidad se hicieron con la participación de mercado. [ cita requerida ]
Problemas con las implementaciones
A lo largo de su historia, CORBA ha estado plagado de deficiencias en implementaciones deficientes de ORB. Lamentablemente, muchos de los artículos que critican a CORBA como estándar son simplemente críticas a una implementación particularmente deficiente de CORBA ORB.
CORBA es un estándar completo con muchas características. Pocas implementaciones intentan implementar todas las especificaciones [10] y las implementaciones iniciales eran incompletas o inadecuadas. Como no había requisitos para proporcionar una implementación de referencia, los miembros tenían libertad para proponer características cuya utilidad o implementabilidad nunca se probó. Las implementaciones se vieron obstaculizadas aún más por la tendencia general del estándar a ser verboso y la práctica común de llegar a acuerdos adoptando la suma de todas las propuestas presentadas, lo que a menudo creaba API que eran incoherentes y difíciles de usar, incluso si las propuestas individuales eran perfectamente razonables. [ cita requerida ]
En el pasado, era muy difícil conseguir implementaciones robustas de CORBA, pero ahora es mucho más fácil encontrarlas. El SDK de SUN para Java viene con CORBA incorporado. Se ha descubierto que algunas implementaciones mal diseñadas son complejas, lentas, incompatibles e incompletas. Comenzaron a aparecer versiones comerciales robustas, pero con un coste significativo. A medida que se empezaron a conseguir implementaciones gratuitas de buena calidad, las implementaciones comerciales deficientes desaparecieron rápidamente.
Cortafuegos
CORBA (más precisamente, GIOP ) no está vinculado a ningún transporte de comunicaciones en particular. Una especialización de GIOP es el Protocolo Inter-ORB de Internet o IIOP. IIOP utiliza conexiones TCP/IP sin procesar para transmitir datos.
Si el cliente está detrás de un entorno de servidor proxy transparente o firewall muy restrictivo que solo permite conexiones HTTP al exterior a través del puerto 80, la comunicación puede resultar imposible, a menos que el servidor proxy en cuestión también permita el método HTTP CONNECT o conexiones SOCKS . En un momento dado, era difícil incluso obligar a las implementaciones a utilizar un único puerto estándar; tendían a elegir varios puertos aleatorios en su lugar. A día de hoy, los ORB actuales tienen estas deficiencias. Debido a estas dificultades, algunos usuarios han hecho un uso cada vez mayor de servicios web en lugar de CORBA. Estos se comunican mediante XML / SOAP a través del puerto 80, que normalmente se deja abierto o se filtra a través de un proxy HTTP dentro de la organización, para la navegación web a través de HTTP. Sin embargo, las implementaciones recientes de CORBA admiten SSL y se pueden configurar fácilmente para que funcionen en un solo puerto. Algunos ORB, como TAO , omniORB y JacORB también admiten GIOP bidireccional, lo que le da a CORBA la ventaja de poder utilizar la comunicación de devolución de llamada en lugar del enfoque de sondeo característico de las implementaciones de servicios web. Además, la mayoría de los firewalls modernos admiten GIOP e IIOP y, por lo tanto, son compatibles con CORBA.

Véase también

Ingeniería de software

Tecnologías de software basadas en componentes

Enlaces de idioma

Referencias

  1. ^ El ascenso y la caída de CORBA
  2. ^ "Historia de CORBA". Object Management Group . Consultado el 12 de marzo de 2017 .
  3. ^ "Historia de CORBA". Object Management Group . Consultado el 4 de junio de 2017 .
  4. ^ "OMG IDL Corba Version". Object Management Group . Consultado el 4 de diciembre de 2023 .
  5. ^ "El modelo de componentes CORBA". Dr. Dobb's Journal . 1 de septiembre de 2004. Consultado el 13 de marzo de 2017 .
  6. ^ "ORBexpress: una descripción general".
  7. ^ "omniORB: ORBE CORBA gratuito" . Consultado el 10 de octubre de 2024 .
  8. ^ ab Chappel, David (mayo de 1998). "Trouble with CORBA". davidchappel.com. Archivado desde el original el 3 de diciembre de 2012. Consultado el 10 de octubre de 2024 .
  9. ^ Waldo, Jim; Geoff Wyant; Ann Wollrath; Sam Kendall (noviembre de 1994). "Una nota sobre computación distribuida" (PDF) . Sun Microsystem Laboratories . Archivado (PDF) del original el 10 de octubre de 2022 . Consultado el 10 de octubre de 2024 .
  10. ^ ab Henning, Michi (30 de junio de 2006). "El ascenso y la caída de CORBA". ACM Queue . 4 (5). Association for Computing Machinery : 28–34. doi : 10.1145/1142031.1142044 . S2CID  12103742.

Lectura adicional

Enlaces externos

Wikilibros tiene un libro sobre el tema: Programación CORBA