Figura 1: La heterogeneidad amenazada (xbill)
Bienvenidos a este nuevo curso que se va a impartir desde Barrapunto. En él se va a mostrar como Linux se consolida como plataforma de desarrollo de aplicaciones "middleware" y como los nuevos desarrollo en Linux, como el entorno de ventanas GNOME, se diseñan utilizando las últimas tecnologías.
Gracias a este curso el lector va a ir conociendo la arquitectura CORBA, dada vez más utilizada dentro de los desarrollos software distribuidos y heterogéneos (como por ejemplo Internet y el web), arquitectura que básicamente nos va a permitir olvidarnos de toda la gestión de las comunicaciones (como por ejemplo el uso de sockets).
CORBA es una arquitectura que cada vez se está adoptando con más fuerza dentro del mundo de las empresas y por lo tanto, cualquier profesional del sector software debe conocer y saber como utilizar.
Los objetivos que se van a perseguir son:
Para lograr todas estas metas el curso se va a organizar en cuatro entregas inicialmente, pudiendo ampliar este número en el caso de introducirnos en conceptos avanzados de la arquitectura. Para que el lector pueda irse organizando, las entregas del curso van a cubrir los siguientes aspectos:
Con estas cuatro entregas se completaría el curso básico de CORBA que nos fijamos como objetivo primordial.
Para que el lector pueda seguir sin problemas el curso, lo único que va a necesitar es un equipo con Linux instalado. Además será necesario instalar una serie de herramientas para poder desarrollar utilizando CORBA. Todas estas herramientas serán proporcionadas en el CD que acompaña a la revista, y en el caso de que su licencia no permitiera su distribución, el lector podrá obtener de Internet dichas herramientas.
La idea que vamos a buscar es utilizar herramientas a ser posible con licencia GPL, de cara a que el lector pueda obtener de forma gratuita dicha herramienta, pueda consultar el código fuente y pueda redistribuir sin problemas la herramienta. En el caso de que no exista dicha herramienta en al actualidad, se utilizarán herramientas cuyo uso no suponga la compra de licencias, al menos para desarrollos no comerciales como serán los que hagamos aquí en nuestro curso.
A parte de los artículos de la revista que componen el curso, será necesario que el lector disponga una copia del estándar que describe CORBA, ya que es este el que al final deberá consultar el lector en caso de dudas.
Los estándares desarrollados por OMG, el grupo que ha especificado CORBA, son de una lectura si no amena, bastante clara y concisa. De hecho un objetivo más de este curso sería que el lector pudiera leer el estándar de CORBA sin problemas, entendiendo todo lo que en él se describe.
Junto al estándar se irán recomendando libros de lectura interesante, algunos de ellos centrándose en el desarrollo de CORBA utilizando algún lenguaje en concreto (Java y C++ principalmente).
La programación con CORBA está basada en la programación orientada a objetos (POO). Por ello, es necesario que el lector tenga los conceptos de POO claros ya que serán utilizados de forma constante a lo largo de los ejemplos prácticos. En Internet encontramos tutoriales que pueden servir como introducción a la POO y a los que remitirá al lector.
El desarrollo con CORBA, a pesar de poderse realizar en muchos lenguajes, utiliza principalmente los lenguajes Java y C++, en especial Java. De nuevo, el lector deberá tener nociones de estos lenguajes para seguir los ejemplos prácticos. De cualquier modo, al ser estos lenguajes utilizados masivamente dentro del mundo de desarrollo, se espera que la mayoría de los lectores los conozcan.
Desde estas líneas quiero agradecer a la empresa Future Space [3] la oportunidad que me ha dado de utilizar unos apuntes que he realizado para los cursos de CORBA que se imparten en dicha empresa como base parcial de este curso.
Pasamos a continuación a desarrollar esta primera entrega del curso, en la que se comenzarán a fijar las bases teóricas de CORBA y las causas que han motivado el éxito de esta arquitectura.
Esta es la primera pregunta que debemos contestar al lector. Y lo hacemos por un lado dando la definición de la arquitectura y por otro, mediante un ejemplo que busca aclarar los conceptos introducidos.
Definición
CORBA define la infraestructura para la arquitectura OMA (Object Management Arquitecture) de OMG, especificando los estándares necesarios para la invocación de métodos sobre objetos en entornos heterogéneos.
Los entornos heterogéneos son aquellos en los que las arquitecturas que constituyen el entorno pueden ser sistemas Microsoft Windows, máquinas Unix de diferentes fabricantes (Linux entre otros) e inclusos sistemas como MacOS o OS/2. Y es más, dentro de la heterogeneidad también se incluyen los sistemas de comunicaciones (protocolos de comunicación como TCP/IP, IPX ...) o los lenguajes de programación utilizados en las diferentes arquitecturas. Es el mundo informático en su complejidad más alta y por tanto sólo una arquitectura muy flexible y potente puede cubrir todos estos aspectos.
CORBA define su propio modelo de objetos, basado en la definición de las interfaces de los objetos mediante el lenguaje IDL.
De esta forma se logra una abstracción a la heterogeneidad que permite que el uso de CORBA no sea nada complejo. Como veremos, la forma de desarrollar con CORBA sigue una metodología concreta y fácil de seguir.
CORBA ha buscando un entorno heterogéneo, el cual constituye una visión abierta del mundo de la informática y en la cual hay cabida para diferentes sistemas y distintas filosofías, un mundo más rico que el que se puede lograr con un solo sistema alrededor del cual funcionan todas las aplicaciones.
Figura 1: La heterogeneidad amenazada (xbill)
CORBA ha logrado parte de su éxito a la clara separación entre la interfaz de los objetos y la implementación de los mismos. Las interfaces se definen utilizando el lenguaje IDL, cuya principal característica es su alto nivel de abstracción, lo que le separa de cualquier entorno de desarrollo específico. Para la implementación de los objetos se puede utilizar cualquier lenguaje de programación que proporcione enlaces con el lenguaje IDL. Para que un lenguaje de programación se pueda utilizar desde CORBA, debe tener definida la forma de enlazarse con IDL.
De esta forma, y a partir de una especificación de las interfaces en IDL, se generan unos cabos (proxies) en el lenguaje elegido que permiten el acceso a la implementación de los objetos desde la arquitectura CORBA.
La implementación de CORBA es que la que esconde al usuario de la arquitectura toda la complejidad que pueda existir en un entorno concreto (como por ejemplo su sistema AIX de IBM), y permite al programador desarrollar siguiendo la metodología genérica aprendida.
CORBA es un estándar creado con la idea de una distribución de los sistemas basada en objetos. Con CORBA se pretende definir una arquitectura que especifique cómo se crean los objetos y como se accede a sus funcionalidades. El mundo de los objetos se recrea en su máxima expresión y mostrando toda la potencia de esta metodología de desarrollo, hasta hace pocos años demasiado costosa para los equipos disponibles.
Para comenzar a explicar esta arquitectura vamos a utilizar un ejemplo, ya que así podremos obtener una idea del funcionamiento global del sistema y de la metodología a seguir.
Para esta primera parte de explicación de CORBA, vamos a desarrollar un ejemplo de una sencilla interfaz IDL que describe la funcionalidad que proporciona un determinado objeto.
El ejemplo que utilizaremos será una implementación del protocolo de eco entre un cliente y un servidor, es decir, el servidor deberá responder al cliente todo lo que este le mande.
En este ejemplo se omitirán detalles que las entregas 3 y 4 del curso serán detallados en profundidad. La interfaz IDL de nuestro ejemplo sería:
module CursoCORBA {
interface echo {
// El cliente envía un mensaje al servidor y este se lo devuelve
string repite (in string mensaje);
};
};
La sintaxis del lenguaje IDL es similar a la de C++, así que el lector que conozca dicho lenguaje podrá entender sin problemas este código.
A partir de esta interfaz de generan de forma automática y para un lenguaje concreto el código que "enchufa" a este objeto con CORBA. Una vez enchufado el objeto a CORBA, el uso dentro del código de los clientes es tan sencillo como invocar una operación sobre un objeto.
Nuestra labor como desarrollador consiste en implementar del lado del servidor esta interfaz, mientras que del lado del cliente lo único que hay que hacer es utilizar los cabos (enchufes) generados para acceder a CORBA.
De momentos no vamos a bajar a más detalles ya que aquí solo buscamos descubrir CORBA.
El uso de una nueva tecnología siempre implica unos esfuerzos de formación de los desarrolladores, nuevas herramientas, nuevos problemas y nuevas soluciones ...
La adopción de una nueva tecnología debe ser llevada a cabo tras un análisis de los costes y la ventajas que se obtienen ya que en el fondo, es una inversión que debe amortizarse en el futuro.
Vamos a intentar dar al lector los motivos por los que creemos que debe utilizarse CORBA.
Con el triunfo de las redes de ordenadores y su implantación, las aplicaciones distribuidas son las únicas que pueden explotar toda la potencia de este nuevo modelo informático.
Las aplicaciones distribuidas, aquellas que se caracterizan por su ejecución coordinada en diferentes máquinas comunicadas, se caracterizan por una alta complejidad en todas las etapas de su desarrollo, debido a la gran cantidad de factores que influyen en su ejecución, siendo uno de los principales la gestión de las comunicaciones.
Por ejemplo, hay que tener en cuenta que los enlaces entre las máquinas se pueden caer, y prever qué hacer en esos casos, y como se detectan dichas caídas. Otro ejemplo sería que contra una máquina A se pueden conectar varias, y debe ser capaz esta máquina A de manejar todas las conexiones. Y las máquinas se tienen que poder encontrar y tienen que poder localizar servicios remotos. Podemos citar también que los entornos en red suelen ser heterogéneos, hay que comunicar diferentes máquinas con distintas configuraciones software y hardware.
CORBA abstrae muchos de estos detalles y hace la distribución de la aplicación un proceso mucho menos complejo y costoso.
Se encarga de organizar los servicios que se pueden encontrar en la red a través de los interfaces IDL. Es independiente de la plataforma y del lenguaje de desarrollo lo que facilita el desarrollo en entornos heterogéneos. Gestiona las comunicaciones, informando a clientes y servidores de caídas de los canales de comunicación.
Facilita la integración de software heredado. Tan sólo hay que definir las interfaces IDL de este software para ponerlo disponible en CORBA.
Proporciona servicios adicionales para, por ejemplo, encontrar objetos y servicios dentro de entornos distribuidos, llegando incluso a definir entornos de trabajo CORBA para diferentes disciplinas: telecomunicación, medicina, ...
Dentro del libro publicado por OMG, "CORBA Fundamentals and Programming", de Jon Siegel se citan otra serie de ventajas:
En definitiva, CORBA presenta unas ventajas enormes en el desarrollo de software distribuido y es una herramienta sin la cual sería muy complicado llevar a cabo un proyecto en unos plazos adecuados y con unos resultados robustos.
El desarrollo con CORBA tiene una serie de pasos adicionales a los desarrollos software clásicos, y una serie de factores a tener en cuenta a la hora de desarrollar la aplicación. En la fase de análisis poco cambia respecto a la metodología que se utiliza en los proyectos software clásicos.
En la fase de diseño sí que se pueden optar por unas soluciones basadas en CORBA, ya que CORBA ofrece unas tecnologías que pueden hacer factibles soluciones que de otra forma serían muy complejas de desarrollar.
En la fase de diseño deberán generarse las interfaces IDL de los diferentes módulos del sistema, algo que facilita mucho la transmisión de los resultados del diseño a los desarrolladores.
Ya en la fase de desarrollo, cada equipo de desarrollo de un módulo recibirá la interfaz IDL para que la implemente en el lenguaje que considere más adecuado, recibiendo también las interfaces IDL de los servicios que vaya a utilizar su módulo. De nuevo, el uso de estos servicios se puede hacer en el lenguaje que seleccionen los desarrolladores, siendo para ellos transparente en qué tipo de hardware y en qué lenguaje se desarrolló la implementación de dichos servicios.
Queda claro que la modularidad que proporciona CORBA facilita mucho los desarrollos paralelos y modulares, algo que en la fase de pruebas también se agradecerá mucho, ya que será más sencillo detectar los fallos y dar respuesta a ellos.
Quizás cabe aquí resaltar la escalabilidad de esta forma de desarrollo. El insertar un nuevo servicio dentro del sistema es un proceso poco traumático. Habría que definir su IDL y ponerla disponible para aquellos servicios que ya existen que la quisieran utilizar.
Los proyectos heredados también se pueden integrar en los nuevos sistemas definiendo los interfaces IDL que ofrecen, y afectando de forma mínima a la nueva arquitectura CORBA que se desarrolla. Todo el software que ya existe por lo tanto es perfectamente utilizable, y su posible sustitución se puede realizar de forma progresiva y bajo demanda.
El proceso a seguir para implementar una interfaz IDL y poner disponible está funcionalidad en CORBA es el siguiente:
Esta es la metodología a aplicar siempre, independientemente del entorno en el que nos movamos. Tanto si es Linux, como Microsoft Windows o Solaris de Sun, los desarrolladores deben de seguir este proceso.
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.
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 :
Ilustración 1: Arquitectura CORBA
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.
En el siguiente gráfico, perteneciente al estándar de CORBA, podemos observar los diferentes elementos de CORBA, entre ellos el ORB.
Ilustración 2: Arquitectura CORBA
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:
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.
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).
Ilustración 3: Invocación del cliente
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.
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.
Las implementaciones de los objetos reciben las invocaciones como llamadas hacia arriba (up-call), desde el ORB hacia la Implementación de la Interfaz.
Ilustración 4: Invocación sobre objeto.
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 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 (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:
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.
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.
En la próxima entrega del curso se pasará a describir el lenguaje IDL y comenzaremos a utilizar herramientas para generar los enchufes de nuestros objetos a CORBA. Serán ya entregas mucho más prácticas donde comenzaremos a disfrutar de la sencillez y potencia de esta arquitectura.