stringtranslate.com

Arquitectura de agente de solicitud de objetos comunes

La Common Object Request Broker Architecture ( 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 .

Descripción general

CORBA permite la comunicación entre software escrito en diferentes idiomas 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 quedan fuera de la responsabilidad de los desarrolladores que utilizan CORBA. CORBA normaliza la semántica de llamada a métodos entre objetos de aplicación que residen en el mismo espacio de direcciones (aplicación) o en espacios de direcciones remotos (el 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 agentes de solicitud de objetos (ORB) escritos para esos lenguajes. Las versiones de IDL han cambiado significativamente y las anotaciones reemplazan algunos pragmas.

La especificación CORBA dicta que debe haber un ORB a través del cual una aplicación interactuará 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 creación de instancias de objetos (y referencias) y las políticas de vida útil 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 la compilación del código IDL del usuario, que traduce la definición de la interfaz de alto nivel en una base de clases específica del sistema operativo y del lenguaje para que la use la aplicación del usuario. Este paso es necesario para hacer cumplir la semántica de CORBA y proporcionar un proceso de usuario limpio para interactuar con la infraestructura de CORBA.

Algunas asignaciones IDL son más difíciles de utilizar que otras. Por ejemplo, debido a la naturaleza de Java, el mapeo IDL-Java es bastante sencillo y hace que el uso de CORBA sea muy simple en una aplicación Java. Esto también se aplica al mapeo de IDL a Python. El mapeo de C++ requiere que el programador aprenda los tipos de datos anteriores a la biblioteca de plantillas estándar (STL) de C++. Por el contrario, el mapeo 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, el mapeo de IDL a C requiere que un programador de C emule manualmente las características orientadas a objetos.

Para construir un sistema que use 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 el sistema usará o implementará. Normalmente, una implementación ORB incluye una herramienta llamada compilador IDL que traduce la interfaz IDL al idioma de destino para su uso en esa parte del sistema. Luego, un compilador tradicional compila el código generado para crear los archivos de objetos vinculables 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 mediante CORBA IDL
Ilustración de la autogeneración del código de infraestructura a partir de una interfaz definida mediante CORBA IDL

Esta figura ilustra el paradigma de alto nivel para comunicaciones remotas entre procesos utilizando CORBA. La especificación CORBA aborda además la tipificación de datos, excepciones, protocolos de red, tiempos de espera de comunicación, 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) al otros servidores. La especificación CORBA (y por lo tanto esta figura) deja varios aspectos del sistema distribuido para que la aplicación los defina, incluida la duración de los objetos (aunque la semántica de recuento de referencias está disponible para las aplicaciones), la redundancia/conmutación por error, la gestión de memoria, el equilibrio de carga dinámico y la gestión de aplicaciones. modelos orientados como la separación entre visualización/datos/semántica de control (por ejemplo, ver Modelo-vista-controlador ), etc.

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

Historial de versiones

Esta tabla presenta la historia de las versiones estándar CORBA. [1] [2] [3]

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 destino de la 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 objeto (que está expuesto a invocaciones remotas) y sirviente (al que la parte anterior reenvía las llamadas al método) . Puede ser un servidor por objeto remoto , o el mismo servidor puede admitir varios (posiblemente todos) objetos, asociados con el Adaptador de objetos portátil determinado . El servidor para cada objeto se puede configurar o encontrar "una vez por siempre" (activación del servidor) o elegirse dinámicamente cada vez que se invoca el método en ese objeto (ubicación del servidor). Tanto el localizador de servidor como el activador de servidor pueden reenviar las llamadas a otro servidor. En total, este sistema proporciona un medio muy potente para equilibrar la carga, distribuyendo las solicitudes entre varias máquinas. En los lenguajes orientados a objetos, tanto el objeto remoto como su servidor son objetos desde el punto de vista de la programación orientada a objetos.

La encarnación es el acto de asociar un servidor con un objeto CORBA para que pueda atender solicitudes. La encarnación proporciona una forma de servidor concreta para el objeto virtual CORBA. Activación y desactivación se refieren únicamente a objetos CORBA, mientras que los términos encarnación y etérea se refieren a sirvientes. Sin embargo, la vida útil de los objetos y los servidores es independiente. Siempre encarnas un sirviente antes de llamar a enable_object(), pero también es posible lo contrario, create_reference() activa un objeto sin encarnar un sirviente, y la encarnación del sirviente se realiza posteriormente bajo demanda con un Servant Manager.

ElEl Adaptador de objetos portátil (POA) es el objeto CORBA responsable de dividir el controlador de invocación remota del lado del servidor en elobjetoy susirviente. El objeto está expuesto 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ámicamente (para cada invocación remota), permitiendo en ambos casos el reenvío de la llamada a otro servidor.

En el lado del servidor, los POA forman una estructura similar a un árbol, donde cada POA es responsable de uno o más objetos a los que se sirve. Las ramas de este árbol se pueden activar/desactivar de forma independiente, tienen diferentes códigos para la ubicación o activación del servidor y las 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), una búsqueda de 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 al método sobre la referencia dan como resultado llamadas posteriores al ORB y el bloqueo del hilo mientras se espera una respuesta, éxito o fracaso. El ORB calcula internamente los parámetros, los datos devueltos (si los hay) y los datos de excepción 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 neutral en cuanto al idioma y al 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 imponer una excelente tipificación de datos al compilar clientes y servidores, preservando al mismo tiempo la flexibilidad inherente al espacio de problemas CORBA.

Objetos por valor (OBV)

Además 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 del lado remoto, el código necesario debe ser conocido a priori por ambos lados o descargarse dinámicamente del remitente. Para que esto sea posible, el registro que define OBV contiene el código base, que es una lista de URL separadas por espacios desde donde se debe descargar este código. El OBV también puede tener métodos remotos.

Modelo de componentes CORBA (CCM)

El modelo de componentes CORBA (CCM) es una adición a la familia de definiciones CORBA. [4] Se introdujo con CORBA 3 y describe un marco de aplicación estándar para 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 nombres bien definidos llamados 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 de 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" utilizados por CORBA y RMI-IIOP para mediar en las funciones más importantes del sistema CORBA. El estándar CORBA define los siguientes tipos de interceptores:

  1. Los interceptores IOR median en la creación de nuevas referencias a los objetos remotos, presentados por el servidor actual.
  2. Los interceptores de clientes generalmente median en las llamadas a 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 en las llamadas locales.
  3. Los interceptores de servidor median en 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 objetivo.

Protocolo general InterORB (GIOP)

El GIOP es un protocolo abstracto mediante el cual se comunican los intermediarios de solicitud de objetos (ORB). Los estándares asociados con el protocolo son mantenidos por el Object Management Group (OMG). La arquitectura GIOP proporciona varios protocolos concretos, que incluyen:

  1. Protocolo InterORB de Internet (IIOP): el protocolo Inter-Orb de Internet es una implementación de 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 y proporciona cifrado y autenticación .
  3. Protocolo InterORB de hipertexto (HTIOP): HTIOP es IIOP sobre HTTP , lo 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 menores del proveedor)

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 menores son de tipo largo sin firmar y constan de un "ID de conjunto de códigos menores de proveedor" (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, "Estándar Definiciones de excepciones", en la página 3-52 y Sección 3.17.2, "Códigos de excepción menores estándar", en la página 3-58).

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

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

El agente de solicitud de objetos comunes: arquitectura y especificación (CORBA 2.3)

Ubicación de Corba (CorbaLoc)

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

Todos los productos CORBA deben admitir dos URL definidas por OMG: " corbaloc: " y " corbaname: ". El propósito de estos es proporcionar una forma legible y editable para 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/NameServer-POA/_root

Un producto CORBA puede opcionalmente soportar 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 propietarios de ese ORB.

Beneficios

Los beneficios de CORBA incluyen independencia del lenguaje y del sistema operativo, libertad de implementaciones vinculadas a la tecnología, tipificación de datos sólida, alto nivel de sintonizabilidad y libertad de los detalles de las transferencias de datos distribuidas.

Independencia lingüística
CORBA fue diseñado para liberar a los ingenieros de las limitaciones de acoplar sus diseños a un lenguaje de software particular. Actualmente existen muchos lenguajes soportados por varios proveedores CORBA, siendo los más populares Java y C++. También hay implementaciones de C++11, solo C, Smalltalk, Perl, Ada, Ruby y Python, solo por mencionar algunas.
independencia del sistema operativo
El diseño de CORBA pretende 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 de tecnologías
Uno de los principales beneficios implícitos es que CORBA proporciona 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 puedan unirse en un sistema completo. Esto no descarta la necesidad de tomar decisiones básicas de ingeniería del sistema, como subprocesos, sincronización, vida útil del objeto, etc. Estas cuestiones son parte de cualquier sistema, independientemente de la tecnología. CORBA permite normalizar los elementos del sistema en un único modelo de sistema cohesivo.
Por ejemplo, el diseño de una arquitectura multinivel se simplifica utilizando servlets Java 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 cambien las implementaciones de la lógica empresarial, mientras que los cambios de interfaz deberían manejarse como en cualquier otra tecnología. Por ejemplo, una base de datos empaquetada por un servidor puede cambiar su esquema de base de datos para mejorar el uso o el rendimiento del disco (o incluso un cambio de proveedor de 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 Java, y puede proporcionar datos a una interfaz web.
Escritura de datos
CORBA proporciona tipificación de datos flexible, por ejemplo, un tipo de datos "CUALQUIER". CORBA también impone 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 posible que un servidor proporcione un número donde 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, retornos, tipos de parámetros y excepciones.
Alta sintonizabilidad
Muchas implementaciones (por ejemplo, ORBexpress (implementación de Ada, C++ y Java) [5] y OmniORB (implementación de código abierto de C++ y Python)) [6] tienen opciones para ajustar las funciones de administración de conexiones y subprocesos. No todas las implementaciones de ORB ofrecen las mismas funciones.
Libertad de detalles de transferencia de datos
Al manejar conexiones y subprocesos de bajo nivel, CORBA proporciona un alto nivel de detalle en condiciones de error. Esto se define en el conjunto de excepciones estándar definido por CORBA y en el conjunto de excepciones extendidas específico de la implementación. A través de las excepciones, la aplicación puede determinar si una llamada falló por motivos como "Pequeño problema, así que inténtalo de nuevo", "El servidor está muerto" o "La referencia no tiene sentido". La regla general es: no recibir una excepción significa que la llamada al método se completó con éxito. Esta es una característica de diseño muy poderosa.
Compresión
CORBA reúne sus datos en forma binaria y admite la compresión. IONA, Remedy IT y Telefónica han trabajado en una extensión del estándar CORBA que ofrece compresión. Esta extensión se llama ZIOP y ahora es un estándar formal de OMG.

Problemas y críticas

Si bien CORBA aportó muchos resultados en la forma en que se escribió el código y se construyó el software, ha sido objeto de críticas. [7]

Gran parte de las críticas a CORBA provienen de implementaciones deficientes del estándar y no de deficiencias del estándar en sí. Algunas de las fallas del estándar 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 un estándar común obtenido por muchos implementadores competidores.

Incompatibilidades de implementación inicial
Las especificaciones iniciales de CORBA definían sólo el IDL, no el formato en el cable. Esto significó que la compatibilidad del código fuente fue 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 a los que se puede acceder con una simple llamada a función se tratan de la misma manera que los objetos que residen en otros lugares (diferentes procesos en la misma máquina o diferentes máquinas). Este es un defecto de diseño fundamental, [8] [ verificación fallida ] ya que hace que todo acceso a objetos sea tan complejo como el caso más complejo (es decir, una 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 adecuada (es decir, una llamada con una latencia de 1  µs y retorno garantizado se usará de manera muy diferente a una llamada con una latencia de 1 s con posible transporte). fallo, en el que el estado de entrega es potencialmente desconocido y puede tardar 30 s en expirar).
Deficiencias de diseño y proceso.
La creación del estándar CORBA también es frecuentemente citada por su proceso de diseño por comité . No había ningún proceso para arbitrar entre propuestas contradictorias ni para decidir la jerarquía de los problemas a abordar. Así, el estándar se creó tomando una unión de los rasgos en todas las propuestas sin tener en cuenta su coherencia. [9] Esto hizo que la especificación fuera compleja, costosa de implementar en su totalidad y, a menudo, ambigua.
Un comité de diseño compuesto por una combinación de proveedores y clientes de implementación creó un conjunto diverso de intereses. Esta diversidad dificultaba un estándar cohesivo. Los estándares y la interoperabilidad aumentaron la competencia y facilitaron el movimiento de los clientes entre implementaciones alternativas. Esto provocó muchas luchas políticas dentro del comité y frecuentes publicaciones de revisiones del estándar CORBA que algunos implementadores de ORB aseguraron que eran difíciles de usar sin extensiones patentadas. [7] Los proveedores de CORBA menos éticos alentaron la retención de clientes y lograron sólidos resultados a corto plazo. Con el tiempo, los proveedores de ORB que fomentan la portabilidad se hicieron cargo de la cuota de mercado. [ cita necesaria ]
Problemas con las implementaciones.
A lo largo de su historia, CORBA ha estado plagada de deficiencias en implementaciones ORB deficientes. Desafortunadamente, muchos de los artículos que critican a CORBA como estándar son simplemente críticas a una implementación particularmente mala de CORBA ORB.
CORBA es un estándar integral con muchas características. Pocas implementaciones intentan implementar todas las especificaciones, [9] y las implementaciones iniciales fueron incompletas o inadecuadas. Como no había requisitos para proporcionar una implementación de referencia, los miembros eran libres de proponer características cuya utilidad o implementabilidad nunca se probó. Las implementaciones se vieron aún más obstaculizadas por la tendencia general del estándar a ser detallado y la práctica común de llegar a un acuerdo mediante la adopción de 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 necesaria ]
En el pasado ha sido muy difícil conseguir implementaciones sólidas de CORBA, pero ahora es mucho más fácil de encontrar. El SDK de SUN Java viene con CORBA integrado. Se ha descubierto que algunas implementaciones mal diseñadas son complejas, lentas, incompatibles e incompletas. Comenzaron a aparecer versiones comerciales robustas, pero a un costo significativo. A medida que estuvieron disponibles implementaciones gratuitas de buena calidad, las malas implementaciones comerciales desaparecieron rápidamente.
Cortafuegos
CORBA (más precisamente, GIOP ) no está vinculada 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 formato para transmitir datos.
Si el cliente está detrás de un firewall muy restrictivo o un entorno de servidor proxy transparente que solo permite conexiones HTTP al exterior a través del puerto 80, la comunicación puede ser imposible, a menos que el servidor proxy en cuestión permita el método HTTP CONNECT o también conexiones SOCKS . Hubo un tiempo en que era difícil incluso obligar a las implementaciones a utilizar un único puerto estándar; en su lugar, tendían a elegir varios puertos aleatorios. 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 vía HTTP. Sin embargo, las implementaciones recientes de CORBA admiten SSL y se pueden configurar fácilmente para que funcionen en un solo puerto. Algunos ORBS, como TAO , omniORB y JacORB, también admiten GIOP bidireccional, lo que le da a CORBA la ventaja de poder utilizar 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 cortafuegos modernos son compatibles con GIOP y IIOP y, por tanto, son cortafuegos compatibles con CORBA.

Ver también

Ingeniería de software

Tecnologías de software basadas en componentes

Enlaces de idiomas

Referencias

  1. ^ "Historia de CORBA". Grupo de administración de objetos . Consultado el 12 de marzo de 2017 .
  2. ^ "Historia de CORBA". Grupo de administración de objetos . Consultado el 4 de junio de 2017 .
  3. ^ "Versión Dios mío IDL Corba". Grupo de administración de objetos . Consultado el 4 de diciembre de 2023 .
  4. ^ "El modelo de componentes CORBA". Diario del Dr. Dobb . 1 de septiembre de 2004 . Consultado el 13 de marzo de 2017 .
  5. ^ "ORBexpress: ORB CORBA en tiempo real".
  6. ^ "omniORB: ORB CORBA gratuito". fuenteforge.net . Consultado el 9 de enero de 2014 .
  7. ^ ab Chapell, David (mayo de 1998). "Problema con CORBA". davidchappel.com. Archivado desde el original el 3 de diciembre de 2012 . Consultado el 15 de marzo de 2010 .
  8. ^ Waldo, Jim; Geoff Wyant; Ann Wollrath; Sam Kendall (noviembre de 1994). "Una nota sobre la informática distribuida" (PDF) . Laboratorios Sun Microsystem . Archivado (PDF) desde el original el 10 de octubre de 2022 . Consultado el 4 de noviembre de 2013 .
  9. ^ ab Henning, Michi (30 de junio de 2006). "El ascenso y caída de CORBA". Cola ACM . Asociación para Maquinaria de Computación . 4 (5): 28–34. doi : 10.1145/1142031.1142044 . S2CID  12103742.

Otras lecturas

enlaces externos

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