CORBA

Common Object Request Broker Architecture(CORBA) es unestándardefinido porObject Management Group(OMG) que permite que diversoscomponentes de softwareescritos en múltipleslenguajes de programacióny que corren en diferentes computadoras, puedan trabajar juntos; es decir, facilita el desarrollo de aplicaciones distribuidas en entornos heterogéneos.
CORBA fue el primer producto propuesto porOMG. Su objetivo es ayudar a reducir la complejidad, disminuir los costes y acelerar la introducción de nuevasaplicaciones informáticas, promoviendo la teoría y la práctica de la tecnología deobjetosen 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ónmultiplataforma, también define servicios habitualmente necesarios como seguridad y transacciones. Y así este no es un sistema operativo en sí, en realidad es unmiddleware.
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 sobreTCP/IP, creando un protocolo:IIOP(Internet IOP).
CORBA 3 se muestra en 2002, como intento de plantar cara aMicrosofty su modelo de programación de objetos distribuidosDCOM. Entre otras cosas, se introdujo el CORBA Component Model (CCM), con el que se pasó de un modelo de objetos distribuidos (EJB, restringido aJava) a un modelo distribuido orientado a componentes.
Entre las principales características de CORBA nos encontramos con:
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 comoCoCOBOL, aunque CORBA trabaja más eficientemente con lenguajes orientados a objeto como sonJavaoC++.
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 deserialización.
ElORBtiene como principal característica la transparencia. Facilita la comunicación entre cliente y servidor ocultando:
El lenguaje de definición de interfaz oIDL(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. ElIDLsólo puede definir interfaces, no implementaciones. Al especificar las interfaces entre objetos en CORBA,IDLes 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 cualIDLdefine los tipos de datos de una forma independiente del lenguaje con las correspondencias necesarias. Por ejemplo, un tipolongenC++de 32 bits puede corresponderse con unintdeJava.OMGha definido bastantes correspondencias con lenguajes de programación populares, como:C,C++,COBOL,Java,SmalltalkoAda.
Tendremos principalmente dos tipos diferentes deIDLen CORBA:
En la siguiente figura se muestra un ejemplo de IDL para un objeto que realiza el hola mundo, cononewayindicamos que la comunicación es unidireccional y que por lo tanto no se espera ninguna respuesta del método:
La referencia de los objetos se obtiene a través de un campoUniform Resource Identifier(URI) en formato cadena, una búsqueda NameServer (similar a la delSistema de Nombres de Dominio(DNS)) o pasada como argumento durante la llamada a unmé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 alORBque 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 sonserializadaspor elORBinternamente según ellenguaje de programaciónysistema operativo.
ElIDLproporciona 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.
Además de objetos remotos, CORBA yRMI-IIOPdefinen el concepto deObjects by valueu OBV (Objetos por valor) yValuetypes. El código de los métodos de objetosValuetypees ejecutado localmente por omisión. Si el OBV ha sido recibido desde el lado remoto, el código necesario debe ser conocidoa prioripor ambas partes o descargado dinámicamente por el emisor. Para hacer que todo esto sea posible, el registro, que define el OBV, contiene labase de códigoque 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 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 unframeworkpara 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 elEJBdefine. 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.
Los interceptores portables (portable interceptors) son los ganchos usados por CORBA yRMI-IIOPpara proporcionar una de las funciones más importantes del sistema CORBA, que define los siguientes tipos de interceptores:
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.
ElGIOPes un protocolo abstracto por el cual los ORBs se comunican. Los estándares asociados con el protocolo son mantenidos porOMG. La arquitectura deGIOPproporciona una serie de protocolos entre los que se encuentran:
Las localizaciones de CORBA (CorbaLoc) hacen referencia a un objeto referenciado CORBA que tiene una estructura similar a la de unaURL.
Todos los productos CORBA deben soportar dos URLs definidas: CorbaLoc y CorbaName. El propósito de ambas es proporcionar una forma que pueda ser leída y editada por el ser humano para especificar la localización donde el IOR puede ser obtenido.
Un ejemplo de CorbaLoc se puede ver más abajo:
corbaloc::160.45.110.41:38693/StandardNS/NameServer-POA/_root
Un producto CORBA puede opcionalmente soportar el uso de formatos HTTP, FTP y FILE. La finalidad de estos es proporcionar detalles sobre cómo descargar los campos IOR.
Todos los componentes CORBA son objetos, cada cual tendrá una interfaz y una identidad única, cada uno de los objetos se podrá implementar en un lenguaje de programación distinto y ejecutarse sobre cualquier sistema operativo.
El servidor crea objetos remotos, hace accesibles referencias a esos objetos remotos y espera a que los clientes invoquen a estos objetos o a sus métodos. Por otro lado el cliente obtiene una referencia de uno o más objetos remotos en el servidor e invoca a sus métodos.
La manera de realizar la invocación por parte del cliente es usandostub, una interfaz de comunicación con el servidor generada a partir delIDL, usando la invocación dinámica para acceder a los objetos del servidor gestionando a su vez las excepciones producidas por su llamada.
Necesita para ello una referencia del objeto remoto o IOR (Interoperable Object References), el tipo del objeto y el nombre de la propia operación que desea invocar.
Describiendo las interfacesIDL, unORBgenera automáticamente código en el lenguaje seleccionado para realizar la integración de las aplicaciones distribuidas. Evidentemente, puesto que sólo describe interfaces, todas las tareas complejas relacionadas con los lenguajes de programación, como control de flujo, gestión de memoria, composición funcional, no aparecen enIDL.
ElORB, a partir de la petición del cliente encuentra el código de la implementación apropiada y transmite los parámetros, el control a la implementación de la interfaz a través delskeletonIDLe informa de excepciones en el proceso (como referencias IOR oIDLno válidas).
Para recibir la petición, recibe la invocación de uno de sus métodos como llamadas desde elORBhacia la implementación de la interfaz, la llamada puede venir de un cliente que haya utilizado los stubsIDL; los esqueletos de la interfaz son específicos de cada interfaz y del adaptador de objetos que exista en la implementación de CORBA. Una vez completada la invocación, el control y los valores de retorno son devueltos al cliente.
Puede utilizar los servicios que proporciona el adaptador de objetos e incluso que proporciona elORB, mientras es procesada la petición que ha recibido el cliente, para ese caso puede elegir un adaptador de objetos entre un conjunto de ellos, para tomar esa decisión se basa en la clase de servicios que pueda requerir la implementación de la interfaz.
Aunque CORBA prometió mucho en cuanto a la forma de codificar y construir software, ha sido objeto de muchas críticas.
Algunos de los fallos se deben a la implementación y el proceso por el que CORBA fue concebido como un estándar y los problemas que se surgieron en referencia a la política de negocio al implementar un software estandarizado. Estos derivaron en un rechazo en el uso y adopción de CORBA en nuevos proyectos y áreas.
La especificación inicial de CORBA definía tan solo elIDL, y no la interoperabilidad entre los lenguajes. Esto significa que la compatibilidad del código fuente no era mejor que la que había disponible en el momento. Con CORBA 2 y posteriores, este problema se resolvió.
La noción de CORBA en cuanto a transparencia ha sido motivo de crítica, y esto se debe a que los objetos que residen en el mismoespacio de direccionesy que son accesibles con una simple llamada a una función son tratados como objetos que residen en cualquier parte del sistema distribuido. Esto hace que los accesos locales sean tan complicados como serían en el escenario remoto más complejo. Aunque cabe decir que CORBA no ofrece restricciones en la complejidad de las llamadas.
La creación del estándar CORBA es citado a menudo por su proceso de diseño por comité. No hubo proceso de arbitraje entre las propuestas conflictivas o de decisión de la jerarquía de los problemas a resolver. Así, el estándar se creó teniendo en cuenta todas las propuestas sin importar la coherencia entre estas. Esto hizo que la especificación fuera muy compleja, cara de implementar y a menudo ambigua.
A lo largo de su historia, CORBA se ha visto afectada por las deficiencias en sus implementaciones. Ha habido pocas implementaciones que hayan incluido todos los elementos críticos de la especificación, y las implementaciones existentes estaban incompletas o eran inadecuadas. Al no existir requisitos a la hora de proponer nuevas características, los miembros incluían propiedades que no habían sido probadas nunca en cuanto a usabilidad o implementación. A su vez las implementaciones se vieron obstaculizadas por la tendencia general para detallar las normas y la práctica común de comprometerse a adoptar todas ellas, lo que normalmente generabaAPIsincoherentes y de difícil utilización.
En la actualidad este punto ha cambiado considerablemente a mejor y podemos encontrar implementaciones de CORBA de mejor calidad.
CORBA (más precisamente,IIOP) utiliza conexionesTCP/IPcrudas con el fin de transmitir los datos. Sin embargo, si el cliente está detrás de un cortafuegos muy restrictivo o un entorno con servidor proxy transparente que sólo permite conexionesHTTPhacia el exterior por el puerto 80, la comunicación puede llegar a ser imposible, salvo que el servidorproxyen cuestión permita el método CONNECTHTTPo conexiones con sockets. Hubo un momento, en el que era difícil hasta forzar implementaciones para utilizar un solo puerto estándar, en vez de esto tenían que escoger varios puertos al azar. Hoy en día, los ORBs actuales no tienen estas deficiencias. Debido a estas dificultades, algunos usuarios han preferido el uso de los servicios web en lugar de CORBA. Estos se comunican utilizandoXML/SOAPtravés del puerto 80, que normalmente se deja abierto o se filtra a través de un proxyHTTPdentro de la organización, para la navegación web a través deHTTP. Implementaciones CORBA recientes, sin embargo, soportan SSL y pueden ser fácilmente configurados para trabajar en un solo puerto. La mayoría de los ORBs de código abierto más populares como son TAO y JacORB, soportan tambiénGIOPbidireccional, lo que da a CORBA la ventaja de ser capaz de utilizar la comunicación de retorno de llamada en lugar del enfoque de sondeo característica de implementaciones de servicios web. A su vez, cada vez se comercializan más cortafuegos que soportan CORBA sin problemas.