Objetos Distribuidos en el
World Wide Web
Luis Genaro Reyes Velasco
Ana María Martínez Enriquez
Dominique Decouchant
Depto. de IE - Sección Computación
CINVESTAV-IPN, D.F., México
Tel. 57.47.38.00 ext. 3332
e-mail: lreyes@mail.cinvestav.mx
febrero 2000.
La creciente introducción de tecnologías de cómputo distribuido ha dado como resultado el inicio de algunos modelos poderosos sobre cómo puede operar una red mundial inteligente. Microsoft COM/DCOM, la especificación OMG CORBA, las especificaciones Sun's Java y Common Gateway Interface (CGI) son importantes protagonistas en un mundo de información electrónica. Hasta cierto punto éstos modelos son rivales competitivos, sin embargo existen esfuerzos para sintetizar las mejores características de cada uno de ellos. Este documento analiza las contribuciones hechas por éstas arquitecturas y finalmente se lleva a cabo una comparación entra ellas basada en las siguientes consideraciones: arquitectura neutral, transparencia en la comunicación, independencia del lenguaje, complejidad y servicios distribuidos que propocionan.
Con el desarrollo del World Wide Web, la mayoría de los usuarios proporciona información en Internet de una manera visualmente agradable y ampliamente distribuida. El Web ha probado ser un medio ideal para información distribuida como se puede observar desde su inmensa popularidad y crecimiento exponencial. Por consiguiente, se han introducido diversos paradigmas para expresar información denominada hypermedia. Esta tendencia comenzó en la última década con iniciativas como OSF DCE y sistemas transaccionales, pero recientemente el foco de atención se ha dirigido hacia aplicaciones utilizando tecnología orientada a objetos para sistemas distribuidos. Esta poderosa combinación ofrece servicios de red de una manera controlada que sólo proporciona la tecnología de objetos con sus principios de encapsulación de datos e interfaces bien definidas. El acceso a cómputo distribuido con objetos ha llevado a una visión de software bajo componentes, es decir sistemas de información construidos dinámicamente de componentes prefabricados y listos para su instalación en red.
Los objetos distribuidos proporcionan, particularmente, un mecanismo útil para la comunicación cliente-servidor. Las arquitecturas definidas para sistemas de objetos distribuidos son plataformas de software, que son requeridas para la construcción y uso de aplicaciones cliente/servidor que utilizan objetos distribuidos. Los objetos son piezas independientes de código que los clientes acceden de manera local o remota a través de llamadas a métodos. Los clientes no necesitan conocer donde residen los objetos o bajo qué sistema operativo se ejecutan. La plataforma del objeto distribuido también proporciona una infraestructura para soportar un gran número de servicios y capacidades proporcionadas por las diferentes arquitecturas de objeto distribuido tales como llamadas a métodos remotos, objetos compartidos y persistentes, contenedor de objetos, etc.
CORBA es una plataforma de objeto distribuido propuesta por un consorcio de 700+ companías llamado OMG (Object Management Group). El núcleo de la arquitectura CORBA es ORB (Object Request Broker) que actúa como el transporte de objetos sobre el cual los objetos interactúan, de forma transparente, con otros objetos localizados localmente o remotamente. Un objeto CORBA esta representado por una interfaz que especifica los métodos que los clientes requieren. Esta interfaz se define utlizando el Lenguaje de Definición de Interfaces IDL (Interface Definition Language) y así permite que los objetos sean implementados en diferentes lenguajes. Un identificador de objeto identifica una instancia particular del objeto. El cliente de un objeto CORBA adquiere su identificador de objeto y lo utiliza para realizar llamadas al método, como si el objeto fuese localizado en el espacio de direccionamiento del cliente. El diagrama siguiente muestra la arquitectura básica de CORBA.
Figura 1. Representación de la arquitectura CORBA.
Los Stubs son mecanismos de llamada por parte del cliente. El Skeleton es la interfaz que el servidor utiliza para las solicitudes. Como la arquitectura CORBA es trasparente a la localización, por consiguiente la implementación puede estar en el mismo proceso del cliente, en un proceso diferente o en una máquina totalmente diferente. Los detalles sobre el lugar donde el objeto actualmente existe, son un detalle de la implementación y no un requerimiento de la transacción del objeto. CORBA se encarga de pasar las solicitudes (mensajes) del cliente a dondequiera que esté implementado el objeto. El ORB es responsable de los mecanismos necesarios para localizar la implementación del objeto, prepararlo para recibir la solicitud, cominicarle la solicitud y llevar la respuesta al cliente. La implementación del objeto iteractúa con el ORB a través de un Adaptador Básico de Objetos (Basic Object Adapter - BOA) o a través de la interfaz ORB. Un adaptador de objetos soporta diversos estilos de implementación del objeto. El papel de un adaptador de objetos es adecuar al objeto para sus métodos que los clientes invocarán. La interfaz ORB soporta servicios ORB que están ampliamente disponibles y son invocados por el servidor o por el cliente. Mientras que una interfaz es responsable del tipo de implementación, un adaptador de objeto es responsable del "estilo" de la implementación del objeto. Por ejemplo, si el objeto todavía no esta activo, y cuando se envia una solicitud entonces activar al objeto. El BOA describe cuatro estilos de activación: por método, compartido, no compartido y persistente. El ORB procesa una solicitud bajo la ruta de llamada que a continuación se describe:
Figura 2. Ejemplo de la arquitectura CORBA.
Dado que CORBA no dicta la implementación, se requiere un protocolo de red común de tal manera que interactúen diversas implementaciones. El GIOP (General Inter-ORB Protocol) esta especificado como la interfaz común, incluyendo el tipo y formato del mensaje, que se requiere para la interoperabilidad general. Se especifica la etapa semántica IIOP (Internet Inter Orb Protocol) para traducir el GIOP en TCP/IP. Esta combinación de GIOP e IIOP es necesaria para el soporte de la interoperabilidad fuera de la caja. Los distribuidores de ORB que soportan este protocolo deben interactuar. Sin embargo, un sólo protocolo no es adecuado para todos los usos o propósitos, por lo que es posible que el GIOP sea traducido en diferentes protocolos (tales como IPX o SNA). Así también un sólo conjunto de interfaces no es adecuado para todos los propósitos. En este caso son de interés los ESIOP (Environment Specific Inter ORB Protocols). El primer ESIOP especificado esta basado en DCE (Distributed Computing Environment). El DCE-CIOP (DCE Common Inter ORB Procol) une el ESIOP y TCP para aquellos ambientes específicos donde es útil el protocolo DCE. Los servicios que proporciona CORBA incluyen notificación de eventos, persistencia, denominación, control de concurrencia, relaciones, transacciones, colecciones, externalización, tiempo, seguridad, servicios de consulta, negociación y manejo de cambios. Las facilidades de CORBA se presentan en plataformas (frameworks) de objetos que emplearán muchas aplicaciones CORBA. Algunas facilidades que tienen un amplio uso son conocidas como Facilidades Horizontales. Otras que se esperan sean útiles en el mercado o industria se le conoce como Facilidades Verticales. Aquellas facilidades que están actualmente en el dominio de la facilidades CORBA son facilidades horizontales, interfaz del usuario, manejo de información, manejo de sistemas y manejo de tareas. Las facilidades del Mercado Vertical soportan varios segmentos como cuidado de la salud, CAD, ventas al por menor, Internet, imágenes, simulación distribuida, explotación y producción de gas y aceite, desarrollo de aplicaciones, telecomunicaciones, etc.
DCOM es la extensión distribuida de COM (Component Object Model) que construye una etapa de llamada a procedimiento remoto del objeto (ORPC Object Remote Procedure Call) sobre DCE (Distributed Computing Environment) RPC para soportar objetos remotos. COM define cómo interactúan los componentes y sus clientes. Esta interacción esta definida para que el cliente y el componente interactúen sin necesidad de ningún componente intermediario del sistema. El cliente llama a los métodos en el componente sin ningúna sobrecarga. Un servidor COM crea instancias a objetos de múltiples clases. Un objeto COM soporta múltiples interfaces, cada una representando un comportamiento del objeto. Una interfaz consiste de un conjunto de métodos funcionalmente relacionados. Un cliente COM interactúa con un objeto COM adquiriendo un apuntador a una de las interfaces del objeto e invoca los métodos a través del apuntador, como si el objeto residiera en el espacio de direccionamiento del cliente. COM especifica que ninguna interfaz sigue una organización de memoria estándar semejante a la tabla de función virtual de C++. Puesto que la especificación esta en nivel binario, permite la integración de componentes binarios escritos posiblemente en diferentes lenguajes de programación como C++, Java o Visual Basic.
Figura 3. Arquitectura COM/DCOM.
Cuando el cliente y el componente residen en máquinas distintas, DCOM simplemente reemplaza la comunicación entre procesos local con un protocolo de red. Ni el cliente ni el componente están conscientes de que el medio de transmisión que los conecta es más grande que de manera local. El tiempo de ejecución de COM proporciona servicios orientado a objetos a clientes y componentes y utiliza RPC y el proveedor de seguridad para generar paquetes de red estándar que conforman al protocolo DCOM estándar. DCOM administra las conexiones a componentes que están dedicados a un sólo cliente, así como también a los componentes que son compartidos por diversos clientes, manteniendo un contador de referencia por cada componente. DCOM utiliza un protocolo eficiente pinging para detectar si los clientes aún están activos. Las máquinas cliente envian un mensaje periódico. DCOM considera interrumpida una conexión si más de tres periodos de la señal pasan sin que el componente reciba una señal del mensaje. Si la conexión es interrumpida, DCOM decrementa al contador de referencia y libera al componente si la cuenta alcanza un valor de cero. Por consiguiente, DCOM proporciona un mecanismo robusto de recolección de basura que es completamente transparente para la aplicación. DCOM es, inherentemente, un protocolo de red simétrico, así como también es un modelo de programación. No solamente ofrece la interacción unidireccional cliente-servidor sino que también proporciona comunicación interactiva entre clientes y servidor y entre pares de éstos. Las aplicaciones DCOM pueden escalarse fácilmente de máquinas uni-procesador a sistemas multiprocesador a gran escala, tomando ventaja del soporte Windows NT para multiprocesadores simétricos.
DCOM, es un modelo de programación independiente de la localidad, facilita cambiar los esquemas de despliegue a medida que la aplicación crece: una máquina servidor puede, inicialmente, hospedar todos los componentes conectándolos como servidor muy eficiente en proceso. Efectivamente, la aplicación funciona como una aplicación monolítica altamente sincronizada. A medida que la demanda crece, se pueden agregar otras máquinas y los componentes se distribuyen entre aquellas máquinas sin ningún cambio en el código.
DCOM proporciona, por omisión, un mecanismo eficiente de seguridad que permite a los desarrolladores escribir aplicaciones distribuidas confiables sin tener que preocuparse sobre la seguridad. Se puede utilizar, como mecanismo de seguridad, cualquier proveedor de seguridad soportado por Windows NT, además DCOM proporciona una infraestructura poderosa para implementar balanceo de carga dinámica. Se pueden utlizar componentes referenciados para implementar, transparentemente, asignaciones del servidor dinámico en tiempo de conexión. Se pueden implementar mecanismos más sofisticados utilizados para re-enrutar invocaciones individuales del método para servidores diferentes pero requieren más conocimiento profundo de la interacción entre clientes y componentes. El Servidor de Transacciones de Microsoft, construido enteramente bajo DCOM, proporciona un modelo de programación estandarizado que lleva éste conocimiento adicional de la aplicación específica a la infraestructura del Servidor de Transacción, el cual a su vez realiza diversas reconfiguraciones estáticas y dinámicas muy sofisticadas y balance de carga. La arquitectura DCOM permite la integración de ambientes de desarrollo de plataformas neutrales y ambientes de máquinas virtuales (Java), así como también gran desempeño, plataforma optimizada de componentes en una sola aplicación distribuida. Por una parte, DCOM define una plataforma binaria estándar, así los clientes y desarrolladores pueden mezclar e igualar componentes generados con herramientas de diferentes vendedores y utilizarlos con diversas implementaciones de la ejecución (runtime) misma de DCOM. A pesar que los detalles de la librería de ejecución de DCOM (Object Request Broker) pueda variar de implementación a implementación, la interacción entre la librería de ejecución y los componentes esta estandarizada, así como también entre componentes. A diferencia de otros modelos de objetos más abstractos, con DCOM es posible distribuir una versión binaria de una plataforma adecuada que trabaja con otros componentes y librerías de ejecución. Por otro lado, DCOM define servicios cross-platform para computación distribuida orientada a objetos, incluyendo conexión y creación de componentes, localización de componentes, invocación de métodos en componentes, y un marco de seguridad. Además de esto, DCOM simplemente emplea los servicios disponibles en cada plataforma para implementar control de multi-hilos y de concurrencia del usuario, interacción con el sistema de archivos, interacción de red sin DCOM, y el proveedor actual de seguridad. El protocolo DCOM está basado en DCE RPC, por lo que es fácil la implementación de DCOM sobre plataformas para los cuales DCE RPC ya está disponible. DCE RPC define una prueba estándar para convertir estructuras de datos en memoria y parámetros en paquetes de red. Su NDR (Network Data Representation) consiste de una plataforma neutral y proporciona un conjunto rico de tipos de datos portables. COM y DCOM también incorpora la noción de identificadores globalmente únicos (GUIDSs) de DCE RPC. Los GUIDs proporcionan colisión libre, sin control de nombres de objetos e interfaces y son las bases de la versión robusta de COM.
Java es una arquitectura neutral, orientada a objetos, portable y un lenguaje de programación de alto desempeño que proporciona un ambiente de ejecución dinámica, distribuida, robusta, segura y multi-hilos. La principal ventaja de Java para computación distribuida radica en la capacidad de descargar el ambiente. En términos de una arquitectura de objeto distribuido totalmente nueva, Java proporciona las siguientes opciones: Java Remote Method Invocation (RMI), Java IDL y la empresa JavaBEan. La especificación RMI es un API que nos permite crear objetos escritos puramente en lenguaje de programación Java, cuyos métodos se invocan de una Máquina Virtual Java diferente (JVM Java Virtual Machine). La tecnología Java IDL para objetos distribuidos facilitan que los objetos interactuen a pesar de estar escritos en lenguaje de programación Java u otro lenguaje tal como C, C++, COBOL, entre otros.
Básicamente RMI proporciona la capacidad para llamadas a métodos sobre objetos remotos, los cuales convierten al componente de transporte del objeto en arquitectura de objeto distribuido. También proporciona mecanismos para el registro y persistencia del objeto. Ofrece servicios distribuidos tales como Java IDL que proporciona una forma de conectar, transparentemente, a los clientes Java a los servidores de red utilizando la industria estándar: Lenguaje de Definición de Interfaces (IDL Interface Definition Language). Las aplicaciones RMI están, a menudo, compuestas de dos programas separados: un servidor y un cliente. Una aplicación común del servidor crea algunos objetos remotos, realiza referencias para accederlos y se encuentra en espera de que los clientes invoquen los métodos sobre éstos objetos remotos. Una aplicación del cliente tiene una referencia remota a uno o más objetos remotos en el servidor y entonces invoca al método sobre ellos. RMI proporciona los mecanismos a través de los cuales el servidor y el cliente se comunican e intercambian información. Las aplicaciones utilizan uno o dos mecanismos para obtener referencias a objetos remotos. Una aplicación registra sus objetos remotos con la facilidad de denominación del RMI, o bien la aplicación pasa y regresa la referencia a los objetos remotos como parte de su operación normal. Los detalles de comunicación entre objetos remotos está a cargo del RMI; para el programador, la comunicación remota se asemeja a la invocación del método Java. Dado que RMI permite que un solicitante pase objetos a objetos remotos, RMI proporciona los mecanismos necesarios para cargar un código de objeto, así como también de transmitir sus datos. RMI soporta su propio protocolo de transporte denominado Protocolo de Mensajes Remotos Java (JRMP Java Remote Messaging Protocol) para definir el conjunto de formatos de mensajes que permiten que los datos pasen a través de una red de computadoras a otra.
La siguiente ilustración representa una aplicación distribuida RMI que utiliza el registro para obtener una referencia a un objeto remoto. El servidor llama al registro para asociar (o ligar) un nombre con un objeto remoto. El cliente busca el objeto remoto por su nombre en el registro del servidor y entonces invoca un método sobre él. La ilustración también muestra que el sistema RMI utiliza un servidor Web para cargar los códigos en bytes de las clases, del servidor al cliente y del cliente al servidor, para los objetos cuando se les necesita.
Figura 4. Aplicación distribuida RMI.
RMI pasa objetos por su tipo verdadero permitiendo que nuevos tipos sean introducidos en una máquina virtual remota por consiguiente extendiendo el comportamiento de una aplicación de manera dinámica. RMI trata un objeto remoto de manera diferente de un objeto local cuando el objeto se le pasa de una máquina virtual a otra. En lugar de hacer una copia de la implementación del objeto en la máquina virtual receptora. El solicitante invoca un método en el stub local que tiene como responsabilidad cargar la llamada al método en el objeto remoto. Un stub para objetos remotos implementa el mismo conjunto de interfaces remotas que el mismo objeto remoto implementa. Esto permite que un stub se acople a cualquiera de las interfaces que el objeto remoto implemente. Sin embargo, esto también significa que solamente aquellos métodos, definidos en una interface remota, estén disponibles para su solicitud en la máquina virtual receptora.
Java IDL esta basado en CORBA (Common Object Request Brokerage Architecture). Una característica clave de CORBA es un lenguaje-neutral IDL (Interface Definition Language). Cada lenguaje que soporta CORBA tiene su propio traductor IDL y como su nombre lo dice, Java IDL soporta la traducción para Java. Para soportar la interacción entre objetos en programas separados, Java IDL proporciona un ORB (Object Request Broker). El ORB es una librería clase que facilita la comunicación de bajo nivel entre las aplicaciones Java IDL y otras aplicaciones CORBA.
Common Gateway Interface es una interfaz al servidor Web que permite extender la funcionalidad de éste. Con CGI se puede interactuar con los usuarios que acceden a un sitio en particular. En un nivel teórico, los CGI permiten extender las capacidades del servidor para interpretar las entradas obtenidas del browser (navegador) y regresar la información apropiada de acuerdo a la entrada del usuario. En un nivel práctico, CGI es una interfaz que facilita la escritura de programas para que se comuniquen fácilmente con el servidor.
Usualmente, si se desea extender las capacidades del servidor Web, se tendría que modificar el servidor manualmente. Esta no es una solución deseable puesto que requiere un entendimiento de bajo nivel de programación de red sobre el Internet y el protocolo World Wide Web. También requiere editar y recompilar el código fuente del servidor o escribir un servidor dedicado para cada tarea. Por ejemplo, si se quiere extender el servidor para que actúe como una compuerta Web-a-e-mail que tomara la entrada del usuario desde el browser y lo reenvia a otro usuario. Se tendría que insertar código en el servidor que interpretara la entrada desde el browser, re-enviar la entrada al otro usuario y regresar una respuesta al browser sobre una conexión de red.
Primeramente, ésta tarea requiere accesar el código del servidor, algo que no siempre es posible. En segundo lugar, es difícil y requiere excesivo conocimiento técnico. Tercero, funciona solamente para un servidor específico. Si se quiere mover el servidor Web a una plataforma diferente, se tendrá que re-iniciar o al menos desperdiciar mucho tiempo al trasladar el código a esa plataforma.
CGI proporciona una solución portable y simple a estos problemas. El protocolo CGI define una forma estándar para que los programas se comuniquen con el servidor Web. Sin mucho conocimiento especial, se puede escribir un programa en cualquier lenguaje de computación que interactúe con el servidor Web. Este programa trabajará con todos los servidores Web que entiendan al protocolo CGI.
La comunicación CGI esta manejada sobre la entrada y salida estándar, lo que significa que si se conoce como imprimir en pantalla y leer datos utilizando el lenguaje de programación, se puede escribir una aplicación sobre el servidor Web. Programar las aplicaciones CGI es casi equivalente a programar cualquier otra aplicación . Por ejemplo, si se desea programar un programa "Hola México", se utiliza las funciones de imprimir en pantalla del lenguaje y el formato definido para programas CGI para imprimir en pantalla el mensaje apropiado.
La mayoría de los lenguajes de programación y muchos lenguajes desempeñan estas tres actividades y se pueden utilizan cualquiera de ellas.
Los lenguajes caen bajo una de las siguientes clases: compilar o interpretar. Un lenguaje compilador tal como C o C++ tiende a ser más pequeño y más rápido, mientras que el lenguaje intérprete tal como Perl o Rexx requieren cargar, algunas veces, un intérprete grande antes de comenzar. Adicionalmente, se puede distribuir código binario (código compilado en lenguaje máquina) sin el código fuente, si el lenguaje utilizado es del tipo compilador. La distribución de scripts interpretados normalmente significa distribuir el código fuente.
Antes de escoger el lenguaje, se deben considerar las prioridades. Se necesita balancear la ganancia de velocidad y eficiencia de un lenguaje de programación contra la facilidad de programación de otro.
Existen alternativas importantes para aplicaciones CGI. Ahora, muchos servidores incluyen una programación API que hace más fácil programar directamente extensiones al servidor en contra parte a separar aplicaciones CGI. Los servidores APIs tienden a ser más eficientes que los programas CGI. Algunas aplicaciones se manejan por nuevas tecnologías desarrolladas en la parte del cliente (en lugar del servidor) tales como Java.
A continuación se mencionan las principales características de las arquitecturas presentadas:
| Arquitectura | Independencia
del Lenguaje |
Tecnología | Paso
por
Valor/Referencia |
Garbage
Collection |
Independencia
de Plataforma |
| CORBA | si | integración | no | si | |
| DCOM | si | integración (Windows) | por valor | si | no, sólo para Windows |
| JAVA | sólo con lenguaje Java | programación | por valor | si | si |
| CGI | si | programación | ambas | no | si |