Common Object Request Broker Architecture (CORBA) es un estándar definido por Object Management Group (OMG) que permite que diversos componentes de software escritos en múltiples lenguajes de programación y que corren en diferentes computadoras, puedan trabajar juntos; es decir, facilita el desarrollo de aplicaciones distribuidas en entornos heterogéneos.
Introducción CORBA fue el primer producto propuesto por OMG. Su objetivo es ayudar a reducir la complejidad, disminuir los costes y acelerar la introducción de nuevas aplicaciones informáticas, promoviendo la teoría y la práctica de la tecnología de objetos en los sistemas distribuidos.
Es una tecnología que oculta la programación a bajo nivel de aplicaciones distribuidas. No obstante también brinda al programador una tecnología orientada a objetos; las funciones objetos y estos objetos pueden estar en diferentes máquinas, pero el programador accederá a ellos a través de funciones normales dentro de su programa.
CORBA es más que una especificación multiplataforma, también define servicios habitualmente necesarios como seguridad y transacciones. Y así este no es un sistema operativo en sí, en realidad es un middleware.
Historia Su primera versión se lanzó en 1991.
En 1995 aparece CORBA 2, con nuevas normas que permiten: que puedan cooperar implementaciones de diferentes fabricantes, que pueda ser implementado sobre cualquier nivel de transporte y que pueda funcionar en Internet sobre TCP/IP, creando un protocolo: IIOP (Internet IOP).
CORBA 3 se muestra en 2002, como intento de plantar cara a Microsoft y su modelo de programación de objetos distribuidos DCOM. Entre otras cosas, se introdujo el CORBA Component Model (CCM), con el que se pasó de un modelo de objetos distribuidos (EJB, restringido a Java) a un modelo distribuido orientado a componentes.
Características Entre las principales características de CORBA nos encontramos con: Independencia en el lenguaje de programación y sistema operativo: CORBA fue diseñado para liberar a los ingenieros de las limitaciones en cuanto al diseño del software. Actualmente admite Ada, C, C++, C++11, Lisp, Ruby, Smalltalk, Java, COBOL, PL/I y Python. Posibilidad de interacción entre diferentes tecnologías: uno de los principales beneficios de la utilización de CORBA es la posibilidad de normalizar las interfaces entre las diversas tecnologías y poder así combinarlas. Transparencia de distribución: ni cliente ni servidor necesitan saber si la aplicación está distribuida o centralizada, pues el sistema se ocupa de todo eso. Transparencia de localización: el cliente no necesita saber donde ejecuta el servicio y el servicio no necesita saber donde ejecuta el cliente. Integración de software existente: se amortiza la inversión previa reutilizando el software con el que se trabaja, incluso con sistemas heredados. Activación de objetos: los objetos remotos no tienen por qué estar en memoria permanentemente, y se hace de manera invisible para el cliente. Otras como: el tipado fuerte de datos, la alta capacidad de configuración, libertad de elección de los detalles de transferencia de datos, o la compresión de los datos.
Elementos La arquitectura CORBA está orientada a objetos. En CORBA los objetos poseen muchas de las características de otros sistemas orientados a objetos, como son la herencia en cuanto a interfaces y el polimorfismo. Pero lo más interesante de este aspecto, es la posibilidad de proporcionar estas características a lenguajes no orientados a objeto como C o COBOL, aunque CORBA trabaja más eficientemente con lenguajes orientados a objeto como son Java o C++.
Object Request Broker (ORB) El Object Request Broker (ORB), es un componente fundamental de la arquitectura CORBA y su misión es facilitar la comunicación entre objetos. Este se encarga de enviar las peticiones a los objetos y retornar las respuestas a los clientes que las invocan por el proceso de serialización.
El ORB tiene como principal característica la transparencia. Facilita la comunicación entre cliente y servidor ocultando: La localización de los objetos: El cliente no tiene por qué saber dónde se encuentra el objeto destino, puede estar en su propia máquina o en un proceso en una máquina remota. La implementación de los objetos: El cliente ignora el lenguaje de programación con el que se ha escrito el objeto remoto, su implementación o el sistema operativo en el que se encuentra. Estado de ejecución del objeto: Al enviar una petición sobre un objeto remoto, el ORB se encarga de inicializar el objeto en caso de ser necesario, antes de enviarle la petición. Mecanismos de comunicación de los objetos: El cliente no sabe qué mecanismos de comunicación utiliza el ORB para enviar las peticiones y retornar el resultado.
Interface Definition Language (IDL) El lenguaje de definición de interfaz o IDL (Interface Definition Language), es un lenguaje que se utiliza para definir las interfaces entre los componentes de una aplicación y es el elemento que soporta la interoperabilidad de la tecnología. El IDL sólo puede definir interfaces, no implementaciones. Al especificar las interfaces entre objetos en CORBA, IDL es el encargado de asegurar la independencia del lenguaje de programación utilizado.
Para que esto sea posible, es necesario asegurar que los datos son correctamente intercambiados entre dos lenguajes distintos, para lo cual IDL define los tipos de datos de una forma independiente del lenguaje con las correspondencias necesarias. Por ejemplo, un tipo long en C++ de 32 bits puede corresponderse con un int de Java. OMG ha definido bastantes correspondencias con lenguajes de programación populares, como: C, C++, COBOL, Java, Smalltalk o Ada.
Tendremos principalmente dos tipos diferentes de IDL en CORBA: Stub IDL: es la interfaz estática a los servicios declarados en las interfaces IDL, para el cliente todas las llamadas parecen locales. Actuará como proxy del objeto remoto, realizando la invocación de métodos remotos, incluyendo la serialización, la recepción de respuestas y la deserialización. El cliente puede tener tantos stubs como interfaces IDL existan. Es generado a partir del IDL en el lenguaje de programación del cliente (C, C++ Java, Smalltalk, Ada,… ) por un compilador IDL. Skeleton IDL: es el representante estático del cliente en el servidor. Para el servidor todas las llamadas parecen locales. Es generado a partir del IDL por un compilador IDL y realiza la deserialización de las invocaciones del cliente.
En la siguiente figura se muestra un ejemplo de IDL para un objeto que realiza el hola mundo, con oneway indicamos que la comunicación es unidireccional y que por lo tanto no se espera ninguna respuesta del método: module HelloApp {
interface Hello { string sayHello(); oneway void shutdown();
Objetos por referencia La referencia de los objetos se obtiene a través de un campo Uniform Resource Identifier (URI) en formato cadena, una búsqueda NameServer (similar a la del Sistema de Nombres de Dominio (DNS)) o pasada como argumento durante la llamada a un método.
Los objetos referenciados son objetos mucho más livianos que implementan la interfaz del objeto real, ya sea remoto o local. Las llamadas a métodos por referencia consisten en una sucesión de llamadas al ORB que se encarga de bloquear los hilos y esperar por una respuesta, ya sea de éxito o fracaso. Los parámetros, información de retorno (en caso de haberla), y las excepciones son serializadas por el ORB internamente según el lenguaje de programación y sistema operativo.
Datos por valor El IDL proporciona el lenguaje de definición de intercomunicación entre objetos o sistemas operativos. Los objetos de CORBA se pasan por referencia, mientras que los datos (integers, doubles, structs, enums, etc.) se pasan por valor. Esta combinación hace que podamos complementar datos fuertemente tipados al compilar clientes y servidores, y aun así preservar la flexibilidad que CORBA nos facilita.
Objects by value (OBV) Además de objetos remotos, CORBA y RMI-IIOP definen el concepto de Objects by value u OBV (Objetos por valor) y Valuetypes. El código de los métodos de objetos Valuetype es ejecutado localmente por omisión. Si el OBV ha sido recibido desde el lado remoto, el código necesario debe ser conocido a priori por ambas partes o descargado dinámicamente por el emisor. Para hacer que todo esto sea posible, el registro, que define el OBV, contiene la base de código que contiene una lista separada por espacios de URLs desde donde este código debe ser descargado. Además el OBV puede tener métodos remotos.
Los OBVs pueden tener campos que se transfieren cuando los OBVs son transferidos. Estos campos pueden ser los OBVs por sí mismos, formando listas, árboles o gráficos arbitrarios. Los OBVs poseen una jerarquía de clases, incluyendo herencia múltiple y clases abstractas.
CORBA Component Model (CCM) CORBA Component Model o CCM (Modelo de Componentes de CORBA) es un añadido a la familia de definiciones de CORBA. Fue introducido en la versión CORBA 3 y describe un framework para los componentes de CORBA. Aunque no depende de language dependent Enterprise Java Beans (EJB) es una forma más general de este, proporcionando cuatro tipos diferentes de componentes en vez de los dos que el EJB define. Además proporciona la abstracción de entidades que pueden proveer y aceptar servicios a través de unas interfaces propias bien definidas llamadas ports (puertos).
El CCM tiene un contenedor de componentes donde los componentes software pueden ser depositados. El contenedor ofrece una serie de servicios que los componentes pueden usar. Estos servicios incluyen (aunque no están limitados solo a estos) notificación, autenticación, persistencia y proceso de transacciones. Son los servicios más utilizados que cualquier sistema distribuido necesita y, moviendo la implementación de estos servicios de los componentes del software al contenedor de componentes, la complejidad de los componentes se reduce drásticamente.
Interceptores portables Los interceptores portables (portable interceptors) son los ganchos usados por CORBA y RMI-IIOP para proporcionar una de las funciones más importantes del sistema CORBA, que define los siguientes tipos de interceptores: Los interceptores de Referencia del Objeto Remoto (IOR) permiten la creación de las nuevas referencias de los objetos remotos presentes en el actual servidor. Los interceptores clientes proporcionan la llamada a métodos remotos desde el lado del cliente. Si el objeto servicio existe en el mismo servidor donde el método es invocado, además permiten llamadas locales. Los interceptores servidor proporcionan la tramitación de las llamadas de métodos remotos en el lado del servidor.
Los interceptores pueden incluir la información específica de los mensajes al ser enviados y los IORs al ser creados. Esta información puede ser leída más adelante por el interceptor correspondiente en el lado remoto. Los interceptores pueden a su vez lanzar excepciones de reenvío, redirigiendo la petición a otro objetivo.
General InterORB Protocol (GIOP) El GIOP es un protocolo abstracto por el cual los ORBs se comunican. Los estándares asociados con el protocolo son mantenidos por OMG. La arquitectura de GIOP proporciona una serie de protocolos entre los que se encuentran: Internet InterORB Protocol (IIOP): implementación de GIOP para su uso por internet, proporcionando una interfaz entre los mensajes GIOP y la capa TCP/IP. SSL InterORB Protocol (SSLIOP): protocolo IIOP sobre SSL, proporcionando encriptación y autenticación. HyperText InterORB Protocol (HTIOP): protocolo IIOP sobre HTTP, proporcionando transparencia remota. Zipped IOP (ZIOP): una versión comprimida de GIOP que reduce el uso de ancho de banda.
Localizaciones de CORBA (CorbaLoc) Las localizaciones de CORBA (CorbaLoc) hacen referencia a un objeto referenciado CORBA que tiene una estructura similar a la de una URL.