Arquitectura de agente de solicitud de objetos comunes

Esta referencia se obtiene mediante una URL ( Localizador Uniforme de Recursos ) convertida a cadena de texto, una búsqueda en el Servicio de Nombres (similar al Sistema de Nombres de Dominio (DNS)) o se pasa como parámetro de un método durante una llamada.

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

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, números decimales, estructuras, enumeraciones, etc.) se pasan por valor. La combinación de objetos por referencia y datos por valor permite garantizar una tipificación de datos precisa durante la compilación de clientes y servidores, a la vez que se conserva la flexibilidad inherente al entorno CORBA.

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 por defecto. Si el OBV se ha recibido del lado remoto, el código necesario debe ser conocido de antemano por ambos lados o descargarse dinámicamente del remitente. Para que esto sea posible, el registro que define el OBV contiene la base de código, 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.

El modelo de componentes CORBA (CCM) es una adición a la familia de definiciones CORBA. ^{[ 5 ]} 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 nombre bien definidas llamadas puertos .

El CCM cuenta con un contenedor de componentes donde se pueden implementar los componentes de software. Este contenedor ofrece un conjunto de servicios que los componentes pueden utilizar. Estos servicios incluyen (entre otros) notificaciones , autenticación , persistencia y procesamiento de transacciones . Estos son los servicios más utilizados en 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.

Los interceptores portátiles son los "ganchos" que utilizan 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 las nuevas referencias a los objetos remotos presentados por el servidor actual.
2. Los interceptores de cliente suelen gestionar las llamadas a métodos remotos en el lado del cliente (quien realiza la llamada). Si el objeto Servant existe en el mismo servidor donde se invoca el método, también gestiona las llamadas locales.
3. Los interceptores del servidor gestionan 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.

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

1. Protocolo InterORB de Internet (IIOP) : El Protocolo InterORB de Internet es una implementación del GIOP para su uso en Internet y proporciona una correspondencia 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 InterORB de Hipertexto (HTIOP) : HTIOP es IIOP sobre HTTP , que proporciona una omisión transparente del proxy.
4. IOP comprimido (ZIOP) : una versión comprimida de GIOP que reduce el uso de ancho de banda.

Cada excepción estándar de CORBA incluye un código secundario para designar la subcategoría de la excepción. Los códigos de excepción secundarios 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 secundario 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 mediante una operación OR con OMGVMCID para obtener el valor del código menor que se devuelve en la estructura ex_body. ^{[ 6 ]}

Dentro de un espacio asignado por el proveedor, la asignación de valores a los códigos secundarios queda a criterio del proveedor. ^{[ 7 ] [ 8 ]}

Los VMCID 0 y 0xfffff están reservados para uso experimental. Los VMCID OMGVMCID ^{[ 9 ]} y del 1 al 0xf están reservados para uso de OMG. ^{[ 10 ]}

Corba Location (CorbaLoc) se refiere a una referencia de objeto en formato de 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 estas es proporcionar una forma legible y editable para especificar la 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 admitir opcionalmente los formatos " http: ", " ftp: " y " file: ". Estos formatos proporcionan detalles sobre cómo descargar un IOR en formato de cadena (o, recursivamente, descargar otra URL que eventualmente proporcionará un IOR en formato de cadena). Algunos ORB ofrecen formatos adicionales que son propietarios de dicho ORB.

CORBA se diseñó para liberar a los ingenieros de las limitaciones que implica vincular sus diseños a un lenguaje de programación específico. Actualmente, existen numerosos lenguajes compatibles con diversos proveedores de CORBA, siendo Java y C++ los más populares. También existen implementaciones para C++11, C-only, Smalltalk, Perl, Ada, Ruby y Python, entre otras.

Históricamente, Java admitía CORBA como parte de su biblioteca estándar , en el paquete org.omg.CORBA.*. Estos fueron posteriormente descontinuados en Java 9 y eliminados en Java 11. ^{[ 11 ]}

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.

Una de las principales ventajas implícitas es que CORBA proporciona un entorno neutral para que los ingenieros puedan estandarizar las interfaces entre diversos sistemas, tanto nuevos como 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 coherente, CORBA facilita la estandarización y permite que equipos dispares desarrollen sistemas y pruebas unitarias que posteriormente se pueden integrar en un sistema completo. Esto no elimina la necesidad de tomar decisiones básicas de ingeniería de sistemas, como la gestión de hilos, la sincronización, el ciclo de vida de los objetos, etc. Estas cuestiones son inherentes a cualquier sistema, independientemente de la tecnología. CORBA permite normalizar los elementos del sistema en un único modelo de sistema coherente.

Por ejemplo, el diseño de una arquitectura multicapa se simplifica mediante el uso de Java Servlets en el servidor web y diversos servidores CORBA que contienen la lógica de negocio y gestionan los accesos a la base de datos. Esto permite modificar la implementación de la lógica de negocio, mientras que los cambios en la interfaz se gestionan como en cualquier otra tecnología. Por ejemplo, una base de datos gestionada por un servidor puede modificar su esquema para optimizar el uso del disco o el rendimiento (o incluso cambiar de proveedor de base de datos por completo), sin afectar a 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 la base de datos Java, y proporcionar datos a una interfaz web.

CORBA ofrece tipado de datos flexible, por ejemplo, el tipo de dato "ANY". Además, garantiza un tipado de datos estrechamente acoplado, lo que reduce los errores humanos. En situaciones donde se intercambian pares nombre-valor, es posible que un servidor devuelva un número en lugar de una cadena. El lenguaje de definición de interfaz de CORBA proporciona el mecanismo para asegurar que el código del usuario cumpla con los nombres de los métodos, los tipos de retorno y de parámetros, y las excepciones.

Muchas implementaciones (por ejemplo, ORBexpress (implementación en Ada, C++ y Java) ^{[ 12 ]} y OmniORB (implementación de código abierto en C++ y Python)) ^{[ 13 ]} ofrecen opciones para ajustar las funciones de gestión de conexiones y subprocesos. No todas las implementaciones de ORB ofrecen las mismas funciones.

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 de CORBA y en el conjunto de excepciones extendidas específicas de la implementación. Mediante las excepciones, la aplicación puede determinar si una llamada falló por motivos como "Problema menor, inténtelo de nuevo", "El servidor no está disponible" o "La referencia no tiene sentido". La regla general es: si no se recibe una excepción, significa que la llamada al método se completó correctamente. Esta es una característica de diseño muy potente.

CORBA organiza sus datos en formato binario y admite 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 oficial de OMG.

Las especificaciones iniciales de CORBA definían únicamente el IDL, no el formato de transmisión. Esto significaba que la compatibilidad del código fuente era la mejor disponible durante varios años. Con CORBA 2 y versiones posteriores, este problema se resolvió.

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 a una función se tratan igual que los objetos que residen en otro lugar (diferentes procesos en la misma máquina o en diferentes máquinas). Este es un defecto de diseño fundamental, ^{[ 15 ]} 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 fallos que no son posibles en las 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 conLa latencia de 1 μs  y el retorno garantizado se utilizarán de forma muy diferente a una llamada conLatencia de 1  s con posible fallo de transporte, en el que el estado de entrega es potencialmente desconocido y podría tardar30  segundos para que se agote el tiempo.

La creación del estándar CORBA también se cita a menudo por su proceso de diseño por comité . No existía un proceso para arbitrar entre propuestas contradictorias ni para decidir la jerarquía de problemas a abordar. Por lo tanto, el estándar se creó mediante la unión de las características de todas las propuestas, sin tener en cuenta su coherencia. ^{[ 16 ]} Esto hizo que la especificación fuera compleja, costosa de implementar por completo y, con frecuencia, 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 coherente. Los estándares y la interoperabilidad aumentaron la competencia y facilitaron la migración de clientes entre implementaciones alternativas. Esto provocó muchas luchas políticas dentro del comité y frecuentes lanzamientos de revisiones del estándar CORBA que algunos implementadores de ORB se aseguraron de que fueran difíciles de usar sin extensiones propietarias. ^{[ 14 ]} Los proveedores de CORBA menos éticos fomentaron la dependencia del cliente y obtuvieron buenos resultados a corto plazo. Con el tiempo, los proveedores de ORB que fomentan la portabilidad ganaron cuota de mercado.

A lo largo de su historia, CORBA se ha visto afectado por 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 mala de ORB de CORBA.

CORBA es un estándar integral con muchas características. Pocas implementaciones intentan implementar todas las especificaciones, ^{[ 16 ]} y las implementaciones iniciales fueron incompletas o inadecuadas. Como no había requisitos para proporcionar una implementación de referencia, los miembros tenían libertad para proponer características que nunca se probaron en cuanto a su utilidad o implementabilidad. Las implementaciones se vieron aún más obstaculizadas por la tendencia general del estándar a ser prolijo y la práctica común de llegar a un compromiso adoptando la suma de todas las propuestas presentadas, lo que a menudo creaba API incoherentes y difíciles de usar, incluso si las propuestas individuales eran perfectamente razonables.

En el pasado, era muy difícil conseguir implementaciones robustas de CORBA, pero ahora son mucho más fáciles de encontrar. Algunas implementaciones mal diseñadas resultaron ser complejas, lentas, incompatibles e incompletas. Empezaron a aparecer versiones comerciales robustas, pero a un precio elevado. A medida que se dispuso de implementaciones gratuitas de buena calidad, las deficientes implementaciones comerciales desaparecieron rápidamente.

CORBA (o más precisamente, GIOP ) no está vinculado a ningún protocolo de comunicación específico. Una especialización de GIOP es el Protocolo Inter-ORB de Internet (IIOP). IIOP utiliza conexiones TCP/IP directas para transmitir datos.

Si el cliente se encuentra 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 resultar imposible, a menos que el servidor proxy en cuestión también permita el método HTTP CONNECT o las conexiones SOCKS . En el pasado, incluso era difícil obligar a las implementaciones a usar un único puerto estándar; en su lugar, solían elegir varios puertos aleatorios. Actualmente, los ORB actuales presentan estas deficiencias. Debido a estas dificultades, algunos usuarios han optado cada vez más por los 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 mediante 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 funcionar 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 usar 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 cortafuegos modernos son compatibles con GIOP e IIOP y, por lo tanto, son compatibles con CORBA.

• Infraestructura de lenguaje común : especificación abierta para entornos de ejecución. 
• Modelo de objetos componentes (COM) : tecnología de componentes de software de Microsoft . 
• Modelo de objetos de componentes distribuidos : software para la comunicación entre componentes de software (COM/DCOM distribuido). 
• Bonobo (GNOME) : marco de componentes obsoleto para el entorno de escritorio gratuito GNOME. 
• IBM System Object Model ( SOM ) – Marco de programación SOM y DSOM – Sistemas de componentes de IBM utilizados en OS/2 y AIX 
• Motor de comunicaciones de Internet : marco para llamadas a procedimientos remotos (ICE) 
• Plataforma Java, Edición Empresarial : conjunto de especificaciones que extienden las páginas de Java SE que muestran descripciones breves de los destinos de redireccionamiento (Java EE). 
• Invocación remota de métodos en Java – Interfaz de programación de aplicaciones Java (Java RMI) 
• Llamada a procedimiento remoto : Mecanismo que permite al software ejecutar un procedimiento remoto (RPC). 
• Arquitectura de comunicaciones por software : marco de arquitectura abierta para radio definida por software (SCA). 
• SOAP – Protocolo de mensajería para servicios web 
• Motor de comunicaciones de Internet : marco para llamadas a procedimientos remotos. 

• Interfaz binaria de la aplicación (ABI) : interfaz para el software definida en términos de acceso a código máquina dentro del proceso. 
• Interfaz de programación de aplicaciones : conexión entre ordenadores o programas. Páginas que muestran breves descripciones de destinos de redirección : API. 
• Convención de llamada : Mecanismo de llamadas a funciones en computadoras 
• Interfaz de funciones externas : interfaz para llamar a funciones desde otros lenguajes de programación. 
• Enlace de lenguaje : Interfaz que permite que un lenguaje de programación utilice una biblioteca escrita en otro.