|
Curso práctico de Corba en GNU/Linux |
Profundizando en CORBA
Pasamos a profundizar un poco más en CORBA y su arquitectura. Lo que sigue es quizás la sección más teórica del curso, pero su conocimiento es indispensable para que en los ejemplos prácticos no nos perdamos entre los detalles.
CORBA : Common Object Request Broker Arquitecture
Como ya dijimos en la definición, CORBA es una herramienta que nos va a facilitar el desarrollo de aplicaciones distribuidas en entornos heterogéneos. Y como allí dijimos, son estos entornos precisamente los más complejos a los que se tiene que enfrentar cualquier desarrollador.
Vamos a analizar como CORBA va proporcionando mecanismos y herramientas que nos permiten salvar las grandes barreras que hasta ahora existían en este tipo de entornos.
Ya citamos que el lenguaje IDL es uno de los pilares de esta solución, y a este lenguaje dedicaremos gran parte de la segunda entrega de este curso.
No podemos olvidar que en todos los entornos de funcionamiento ya existen aplicaciones que resuelven gran variedad de problemas, aplicaciones que tienen un gran valor para el proceso de producción de nuestra empresa. Y OMG tuvo esto muy en cuenta, al estar formado por empresas comerciales. De esta forma y gracias de nuevo a IDL, las aplicaciones heredadas son muy fáciles de integrar dentro de CORBA. Tan sólo hay que desarrollar para ellas un pequeño recubrimiento IDL que exporte la funcionalidad que ofrece este sistema. Y claro, necesitamos que la aplicación esté desarrollada en un lenguaje aceptado en CORBA, pero como veremos la mayoría de lenguajes importantes se pueden utilizar en CORBA. Gracias a los cabos que se generan a partir de las interfaces IDL, podemos enchufar estos sistemas heredados a nuestra arquitectura CORBA.
La primera especificación de CORBA se realizó en 1990, por lo que ya existe un largo desarrollo y una amplia experiencia adquirida.
Con el impulso que ha significado Internet para los sistemas distribuidos, CORBA ha pasado ha ocupar un papel muy relevante dentro de la industria software y hay grandes intereses en su implantación en Internet.
Como ya detallaremos en este curso, CORBA ha llegado a ser incluido dentro de los clientes de Netscape y se pretende que llegue a sustituir al protocolo HTTP (con IIOP) en el futuro.
Un primer esquema modular de CORBA se puede observar en la siguiente figura:
Ha llegado el momento de explicar esta figura, es decir, de comenzar a detallar la arquitectura CORBA y explicar los diferentes módulos que nos encontramos en la figura.
El ORB de CORBA
En el siguiente gráfico, perteneciente al estándar de CORBA, podemos observar los diferentes elementos de CORBA, entre ellos el ORB.
El ORB es posiblemente la parte más importante de CORBA. Es lo que se conoce como el bus de los objetos. El ORB se encarga de poner en contacto a los clientes y a los objetos de forma transparente con respecto a la distribución.
Sus responsabilidades principales son:
- Mecanismos para que el cliente encuentre la Implementación de la Interfaz
- Preparación de la Implementación de la Interfaz para que pueda recibir invocaciones remotas
- Comunicación de los datos que hacen posible la petición (argumentos de la función y parámetros de retorno)
Cuando el cliente quiere hacer una petición a la Implementación de la Interfaz puede utilizar dos caminos diferentes: utilizar un cabo OMG IDL tal o utilizar la interfaz de invocación dinámica (DII). Los detalles sobre estos módulos se desarrollarán a continuación.
Invocaciones remotas desde el cliente
Para que el cliente pueda realizar una invocación sobre un objeto, debe tener una Referencia del Objeto (IOR) y conocer el tipo de objeto y la operación que desea invocar.
El cliente puede iniciar la petición a través de un cabo IDL o bien construyendo la invocación de forma dinámica utilizando el DII.
El ORB se encarga de encontrar el código de la implementación apropiada, transmitir los parámetros y transferir el control a la Implementación de la Interfaz a través del esqueleto IDL, o a través del esqueleto dinámico (DII).
Las invocaciones pueden producir excepciones de diversa índole. Por ejemplo la referencia IOR al objeto puede ya no ser válida, o la interfaz IDL del objeto ha podido cambiar.
El ORB se encargará de informarnos de todas estas posibles excepciones y nuestro código deberá de estar preparado para gestionar estas excepciones.
La interfaz de invocación dinámica
El DII (Dynamic Invocation Interface) es una interfaz que nos permite la construcción dinámica de invocaciones para un determinado objeto.
Esto nos permite, en vez de utilizar una llamada a una función determinada de un objeto concreto, que el cliente puede especificar el objeto, la invocación y los parámetros a pasar a la invocación a través de una llamada o conjunto de llamadas.
De cara al servidor la invocación es idéntica a una que llega a través de la interfaz estática, pero dentro del cliente se logra una flexibilidad fundamental en arquitecturas complejas y dinámicas.
Una invocación dinámica se compone de una referencia al objeto, una operación y una lista de parámetros. Todos estos datos se obtiene del Repositorio de Interfaces (IR) , un nuevo elemento de la arquitectura que pasamos a detallar. El Repositorio de Interfaces (IR)
El Repositorio de Interfaces (IR) es un servicio que ofrece objetos persistentes que representan la información IDL de los interfaces disponibles en CORBA, de una forma accesible en tiempo de ejecución (run-time).
Esta información puede ser utilizada por el ORB para realizar peticiones. Y además, el programador de aplicaciones puede utilizar esta información para acceder a objetos cuya interfaz no se conocía en tiempo de compilación, o para determinar que operaciones son válidas en un objeto.
La Implementación de los Objetos
Las implementaciones de los objetos reciben las invocaciones como llamadas hacia arriba (up-call), desde el ORB hacia la Implementación de la Interfaz.
Esta llamada puede venir de un cliente que ha utilizado los cabos IDL, o bien la DII.
Los esqueletos de la interfaz IDL son específicos de cada interfaz y del adaptador de objetos que exista en la implementación de CORBA. Cuando la invocación ha sido completada, el control y los valores de retorno son devueltos al cliente.
La Implementación de la Interfaz puede utilizar los servicios que proporciona el adaptador de objetos e incluso los que proporciona el ORB, mientras procesa la petición que ha recibido del cliente.
La Implementación de la Interfaz puede elegir un Adaptador de Objetos entre un conjunto de ellos, una decisión que estará basada en la clase de servicios que pueda requerir la Implementación de la Interfaz. Inicialmente OMG propuso como adaptador de objetos el BOA, pero debido a sus limitaciones los fabricantes introducían muchas extensiones propietarias. Para solucionarlo en CORBA 2.2 se introdujo POA, el adaptador de objetos estándar dentro de CORBA 2.2. POA es un módulo fundamental y se intentará cubrir en profundidad en futuras entregas del curso.
El Repositorio de Implementaciones (IR)
El Repositorio de Implementaciones contiene información que permite al ORB localizar y activar la implementación de los objetos.
Normalmente, la instalación de implementaciones y el control de las políticas para la activación y ejecución de las implementaciones de los objetos, se realiza a través de operaciones en el IR. Por ejemplo, los permisos por usuario para acceder e invocar los objetos son especificados aquí.
La introducción de POA en CORBA 2.2 ha supuesto que la información que se almacena en el IR sea menor, ya que por ejemplo, las políticas de activación y ejecución se localizan ahora dentro de POA, en el propio código del servidor.
El Adaptador de Objetos
El Adaptador de Objetos (OA) es el módulo que permite a las implementaciones de los objetos acceder a servicios ofrecidos por el ORB como la generación de referencias para los objetos.
El adaptador de objetos exporta una interfaz pública para su uso por la implementación del objeto, y una interfaz privada para su uso por el esqueleto del objeto, que depende de la implementación del adaptador de objetos.
Las funciones que debe realizar el adaptador de objetos son:
- Generación e interpretación de las referencias a objetos
- Invocación de métodos
- Seguridad en las interacciones
- Activación y desactivación de objetos e implementaciones
- Traducción de referencias a objetos a sus correspondientes implementaciones
- Registro de las implementaciones
Si bien la invocación de los métodos se realiza a través del esqueleto de la interfaz, implícitamente también se utiliza al adaptador de objetos en funciones tales como la activación de la implementación o la autenticación de la invocación.
El Adaptador de Objetos define la mayoría de los servicios que la implementación de los objetos pueden obtener del ORB. Según la implementación, el ORB podrá ofrecer unos servicios u otros. Según la clase de adaptador que se implemente, se deberán ofrecer los servicios asociados a dicha clase. Debido a que las implementaciones de los objetos dependen del Adaptador de Objetos, se deben definir los menos adaptadores de objetos diferentes posibles, teniendo en cuenta que, el Adaptador de Objetos Portable (POA) que está incluido dentro del estándar de CORBA, está diseñados para cubrir la funcionalidad necesaria en un amplio rango de implementaciones de objetos.
Conclusiones
CORBA es una plataforma lo suficientemente madura como para poder ser usada en el ámbito comercial. Es una plataforma basada en un entorno sólido de objetos distribuidos. Para acceder a los objetos utilizan referencias a los mismos, las cuales permiten al cliente acceder al conjunto de servicios que proporciona el objeto, a diferencia de esquemas como RPC, donde el acceso es por función.
CORBA está recibiendo el apoyo de la industria, al ser un estándar abierto, y más aún desde la entrada en juego de Java, y la integración en JDK 1.2 de una implementación de CORBA, formando un equipo que deberá enfrentarse a la plataforma propietaria ActiveX/DCOM de Microsoft.
Referencias
 |
 |
 |
Publicado por: Miguel Serrano |
|
|
