CORBA Y LA PROGRAMACIÓN
DISTRIBUÍDA ORIENTADA A LOS OBJETOS.
La diversidad de las redes actuales hace que la tarea de programar aplicaciones de red sea difícil. Las aplicaciones distribuidas consisten frecuentemente de varios programas intercomunicados escritos en diferentes lenguajes y ejecutándose sobre diferentes sistemas operativos. Los programadores de aplicaciones de red deben considerar todos estos factores al realizar las aplicaciones.
El Arquitectura Común para un Mensajero de Solicitudes entre Objetos (CORBA) define un marco para desarrollar aplicaciones distribuidas orientadas a los objetos. Esta arquitectura facilita la programación en red permitiendo crear aplicaciones distribuidas que interactuán como si hubiesen sido implementadas en un solo lenguaje de programación y sobre un solo computador.
Por otra parte, CORBA añade las ventajas de las técnicas orientadas a objetos a los entornos distribuidos. Lo que permite diseñar aplicaciones distribuidas como un conjunto de objetos cooperantes y utilizar nuevamente los objetos existentes en nuevas aplicaciones.
El Papel del Mensajero de Solicitudes entre Objetos (ORB)
CORBA define una arquitectura estándar para el Mensajero de Solicitudes entre Objetos (ORB). Un ORB es un componente software que hace de mediador en la transferencia de mensajes desde un programa hacia un objeto localizado en un servidor de una red remota. El papel del ORB es el de esconder al programador la complejidad existente en las comunicaciones entre redes.
Un ORB permite crear objetos software estándares cuyas funciones miembro pueden ser invocadas por programas cliente localizados en cualquier parte de la red. Un programa que contiene instancias de objetos CORBA es a menudo conocido como un servidor.
Cuando un cliente invoca una función miembro de un objeto CORBA, el ORB intercepta la llamada a la función. Como se muestra en la figura 1, el ORB redirecciona la llamada a la función a través de la red hacia le objeto destino. El ORB luego toma los resultados de la llamada a la función y los retorna al cliente.
Figura 1 El Mensajero de Solicitudes entre Objetos (ORB).
La Naturaleza de los Objetos en CORBA
Los objetos CORBA son simplemente objetos software comunes implementados en cualquier lenguaje de programación soportado. CORBA soporta varios lenguajes, incluyendo Java, C++ y Smalltalk.
Con pocas llamadas a la interfaz de aplicación del ORB (API), se pueden hacer disponibles los objetos CORBA a los clientes localizados en la red. Los clientes pueden ser escritos en cualquier lenguaje de programación soportado y pueden invocar las funciones miembro de un objeto CORBA usando la sintaxis de un lenguaje de programación normal.
Aunque los objetos CORBA son implementados usando lenguajes de programación estándares, cada objeto CORBA tiene una interfaz bien definida, especificada con el Lenguaje de Definición de Interfaces de CORBA (IDL). La definición de la interfaz especifica qué funciones miembro están disponibles al cliente, sin hacer ninguna suposición sobre la implementación del objeto.
Para invocar funciones miembro de un objeto CORBA, el cliente solo necesita conocer la definición IDL del objeto. El cliente no necesita conocer detalles como el lenguaje de programación utilizado en la implementación del objeto, la localización del objeto en la red, o el sistema operativo sobre el que el objeto se ejecuta.
La separación entre la interfaz del objeto y su implementación tiene varias ventajas. Por ejemplo, permite cambiar el lenguaje de programación en el que se implementó el objeto sin cambiar los clientes que acceden el objeto. Además permite que objetos previamente existentes puedan ser hechos disponibles a la red.
La Estructura de una Aplicación CORBA
El primer paso en desarrollar una aplicación CORBA es el de definir las interfaces de los objetos en el sistema usando el IDL de CORBA. Luego se compilan estas interfaces usando un compilador IDL.
Un compilador IDL genera Java a partir de las definiciones en IDL. Este código Java incluye un código stub del cliente, el que permite desarrollar programas cliente, y un código skeleton para el servidor, que permite implementar objetos CORBA.
Como se muestra en la figura 2, cuando un cliente llama a una función miembro de un objeto CORBA, la función es transferida a través del código stub del cliente hacia el ORB. Si el cliente no ha accedido al objeto anteriormente, el ORB busca una base de datos conocida como el repositorio de implementaciones, para determinar con exactitud el objeto que debería recibir la llamada a la función. El ORB entonces pasa la llamada a la función a través del código skeleton del servidor hacia el objeto destino.
Figura 2 Invocando un Objeto CORBA.
La Estructura de una aplicación CORBA dinámica
Una dificultad que presenta la programación normal de CORBA es que se debe compilar el IDL asociado con los objetos y usar el código generado en las aplicaciones. Esto significa que los programas clientes pueden usar funciones miembros de solamente aquellos objetos cuyas interfaces están definidas en tiempo de compilación. Si un cliente desea obtener la información sobre la interfaz IDL de un objeto en tiempo de ejecución, necesita un método alterno: la programación dinámica con CORBA.
El repositorio de interfaces de CORBA es una base de datos que contiene la información sobre las interfaces IDL implementadas por objetos en una red. Un programa cliente puede escudriñar esta base de datos en tiempo de ejecución para obtener información sobre esas interfaces. El cliente puede entonces hacer llamadas sobre las funciones miembro de esos objetos usando un componente del ORB denominado la Interfaz de Invocación Dinámica (DII) como se muestra en la figura 3.
Figura 3 Cliente invocando un método usando DII.
CORBA también soporta programación dinámica del servidor. Un programa CORBA puede recibir invocaciones a funciones para interfaces IDL para las que ningún objeto CORBA existe. Usando un componente del ORB denominado la Interfaz de Esqueleto Dinámico (DSI), el servidor puede examinar la estructura de estas invocaciones e implementarlas en tiempo de ejecución. La figura 4 muestra un programa cliente dinámico comunicándose con una implementación dinámica de un servidor.
Figura 4 Invocación de métodos usando DII y DSI.
Interoperabilidad entre ORB´s
Los componentes de un ORB hacen la distribución de programas transparente a los programadores de aplicaciones de redes. Para lograr esto, los componentes del ORB deben comunicarse entre sí, a través de la red.
En muchas redes, varias implementaciones del ORB coexisten y programas desarrollados con una implementación de un ORB deben comunicarse con aquellas desarrolladas con otros. Para asegurar que esto suceda, CORBA especifica que los componentes del ORB deben comunicarse usando un protocolo estándar de red llamado Protocolo de Internet Inter-ORB (IIOP).
La Arquitectura de Organización de Objetos
Un ORB es un componente de la Arquitectura de Organización de Objetos (OMA) de la OMG. Esta arquitectura define un marco de trabajo para la comunicación entre objetos distribuidos. Como se muestra en la figura 5, la OMA incluye cuatro elementos :
Los objetos de Aplicación son objetos que implementan interfaces IDL definidas por el programador. Estos objetos se comunican entre sí, y con los servicios y facilidades CORBA por medio del ORB. Los servicios y facilidades CORBA son conjuntos de objetos que implementan interfaces definidas por CORBA y que proveen servicios que le son útiles a las aplicaciones distribuidas.
Figura 5 La Arquitectura de Organización de Objetos.
Los servicios de CORBA definen un conjunto de servicios de bajo nivel que permiten a los Objetos de Aplicación comunicarse de una forma estándar. Estos servicios incluyen los siguientes:
Las facilidades de CORBA definen un conjunto de servicios de alto nivel que las aplicaciones usualmente requieren cuando se manipulan objetos distribuidos. Las facilidades CORBA se dividen en dos categorías:
Las facilidades horizontales consisten de interfaces de usuario, manejo de información, sistemas de gestión, y facilidades para el manejo de tareas. Las facilidades verticales estandarizan especificaciones IDL para sectores del mercado, como la salud y las telecomunicaciones.
JAVA Y SU ESTILO CLIENTE/SERVIDOR
Java está revolucionando el desarrollo y la operación de las aplicaciones de red para Internet. Java es un lenguaje de programación orientado a los objetos que se dice es un subconjunto de C++ y que ha eliminado las características confusas y poco entendibles de C++. Las características omitidas consisten principalmente de la sobrecarga de operadores (aunque Java provee un método para sobrecargas), herencia múltiple y manejo de punteros. Ha agregado liberación automática de memoria (automatic garbage collection), simplificando de esta forma la programación. Las características orientadas a los objetos de Java son esencialmente las mimas de C++, con una resolución de métodos más dinámica. Java provee librerías con gran cantidad de rutinas para acoplarse a los protocolos de Internet como TCP/IP, HTTP, y FTP. Esto hace que construir aplicaciones de red sea más sencillo que en C y en C++. Las aplicaciones de Java pueden abrir y acceder objetos en la red usando un URL (Uniform Resource Locator) con la misma facilidad con que se acceden a los sistemas de ficheros locales.
Java ha sido pensado para escribir programas que deben ser muy confiables desde muchos puntos de vista. Java hace énfasis en chequeos previos a la ejecución para evitar posibles problemas, chequeos dinámicos en tiempo de ejecución, y agregación de limitaciones para evitar situaciones mal intencionadas. Java esta diseñado para el uso en ambientes distribuidos y las redes. Debido a esto es el gran énfasis dado a la seguridad. Java permite la construcción de sistemas libres de virus y muy estables. Las técnicas de autenticación se basan en claves públicas. Hay una fuerte relación entre seguridad y robustez.
Java fue diseñado para soportar aplicaciones sobre la red. En general, las redes están compuestas de una variedad de sistemas, con una variedad de arquitecturas de CPU y sistemas operativos. Para permitirle a una aplicación de Java ejecutarse en cualquiera parte de la red, el compilador genera un archivo objeto con un formato neutral a cualquier arquitectura – el código compilado es ejecutable en muchos procesadores si está presente el sistema de ejecución de Java llamado VM (Virtual Machine). Esto es útil no solo para las redes, sino además para la distribución de software en sistemas de una sola máquina. En el mercado actual de los PC, los programadores deben escribir diferentes versiones de sus aplicaciones para hacerlas compatibles con el PC y los Macintosh. Con Java, la misma versión de la aplicación funciona en todas las plataformas. El compilador de Java lo permite generando instrucciones llamadas byte-code que no están relacionadas con ninguna arquitectura particular de computadoras. En su lugar, están diseñadas para ser fácilmente interpretadas por cualquier máquina, realizando una traducción al código nativo de máquina en tiempo de ejecución.
El lenguaje Java incluye ambientes de compilación y ejecución. El usuario escribe los programas de Java en un archivo .java, el cual es compilado para generar el byte-code el cual es depositado en un archivo cuya extensión es .class. Es este byte-code la fuente de alimentación de la maquina virtual de Java (VM) que se presenta como un archivo ejecutable que recibe en su línea de parámetros un archivo .class.
Java es utilizado para la construcción de aplicaciones que hubiesen podido ser implementadas en otros lenguajes de igual manera. Sin embargo, es su arquitectura neutra que provee la movilidad de código, lo que ha llevado a Java a ingresar con tanta fuerza en Internet. A surgido la aparición de un nuevo estilo cliente servidor en Internet basado en objetos móviles –llamados applets en Java- que son trozos autosuficientes de código ejecutable.
Estilo Cliente/Servidor de Java en Internet
Java introduce un modelo de interacción cliente/servidor totalmente nuevo en la Web. Permite escribir pequeños programas llamados applets - significando mini-application - que pueden ser descargados en un navegador que sea compatible con Java. Los applets permiten la distribución de código ejecutable y de datos a través de toda la Web. La distribución es inmediata, pudiéndose distribuir una aplicación a millones de clientes al colocarla en un servidor Web. Se acceden siempre las últimas versiones disponibles de la aplicación sin preocuparse por su instalación. Un applet puede realizar tareas e interactuar con el usuario en su navegador sin usar recursos del servidor Web desde el que fue llamado, aunque algunos, pueden por su puesto, interactuar con servidores para cumplir sus propios fines.
Cuando se desea crear applets, el programador debe almacenar los archivos de byte-code en un servidor Web y luego crear una página HTML en la cual se invoque dichos archivos por medio de las cláusulas <applet>...</applet>. Cuando un usuario visite este sitio web, el byte-code viajará por la red hasta donde se encuentre el usuario final. En este momento se realiza una verificación del código antes de ser llevado a la maquina virtual de Java para su ejecución. Cuando el código Java es ejecutado i/o interpretado, se cargan dinámicamente los APIs a medida que sea necesario. La siguiente figura ilustra el ambiente en que se desarrolla de un applet de java.
Figura 7 Ambientes de Compilación y Ejecución de Java
Combinación de CORBA y Java en la "Object Web"
La combinación de las tecnologías de CORBA y Java es natural – no porque las dos compartan el paradigma de la orientación a objetos. Ambos, CORBA y Java esencialmente buscan abstraer las tecnologías y arquitecturas hardware que se encuentran en los niveles bajos. Este factor produce una reducción en las curvas de aprendizaje y ofrecen una mejora dramática en los tiempos de implementación y los costos de mantenimiento. La combinación del lenguaje de programación Java con el estándar CORBA para la integración de aplicaciones, presenta la solución ideal para aplicaciones descargables - desde el Web - capaces de acceder múltiples servicios compartidos en la Internet. Estos servicios se encuentran disponibles como objetos a los que se accede a través del ORB cuya extensión final, es gracias a Java, el propio navegador de los usuarios.
La figura de abajo muestra un típico escenario WWW – el usuario final navega hasta un URL requerido que identifica una página HTML conteniendo una cláusula <applet>. Esta cláusula <applet> referencia a un applet de Java construido usando CORBA. El navegador descarga e interpreta el HTML (1) – reconociendo la cláusula <applet>, ordena a su interprete de Java (VM) el descargue y ejecución de las clases (.class) de Java que constituyen aplicaciones de alto nivel (2). El interpretador de Java procesa este código de alto nivel, y automáticamente va descargando los stubs IDL y luego las clases requeridas que habilitan CORBA. Todo lo anterior es transparente al usuario ya que se realiza usando el cargador estándar de byte-codes del interpretador Java del navegador. Una vez activadas las capacidades CORBA, el applet usa el protocolo IIOP para comunicarse con los servicios CORBA localizados en el servidor Web (5). Estos servicios, a su vez, pueden estar implementados en Java haciendo uso de las capacidades de CORBA.
Figura 8 Applet con capacidades CORBA