Temas:

2.1 Tecnologas de sistemas distribuidos 2.1.1 Modelo de objetos distribuidos 2.1.1.1 Arquitectura RMI (Remote Method Invocation) 2.1.1.2 Activacin de objetos

Introduccin
En los ltimos aos en la informtica se est viviendo un gran avance da a da en el diseo y desarrollo de Sistemas Distribuidos. Ms all de las cuestiones clsicas de diseo de los mismos (acceso y localizacin transparentes, escalabilidad, tolerancia a fallos, rendimiento, etc) se plantea qu tecnologa utilizar para su desarrollo. Por mencionar algunos: Sistemas distribuidos en Java, incluyendo el estndar CORBA (Common Object Request Broker Architecture) del OMG (Object Management Group) y el sistema propio de Java, RMI.

Qu es CORBA?

El CORBA es:
Middleware orientado a objetos que permite invocacin de mtodos distribuidos de forma transparente a las redes, sistemas operativos, arquitecturas y lenguajes de programacin.

Para la implementacin de sistemas distribuidos se requiere de tener bien identificados dos puntos primordiales para la operacin:

-El Protocolo -El Middleware

PROTOCOLO
Definicin: Es un conjunto bien conocido de reglas y formatos que se utilizan para la comunicacin entre procesos que realizan una determinada tarea. Se requieren dos partes:

-Especificacin de la secuencia de mensajes que se han de intercambiar. -Especificacin del formato de los datos en los mensajes.

Un protocolo permite que componentes heterogneos de sistemas distribuidos puedan desarrollarse independientemente, y por medio de mdulos de software que componen el protocolo, haya una comunicacin transparente entre ambos componentes. Es conveniente mencionar que estos componentes del protocolo deben estar tanto en el receptor como en el emisor.

Ejemplos de protocolos usados en los sistemas distribuidos:

-IP: Protocolo de Internet -TCP: Protocolo de Control de Transmisin -HTTP: Protocolo de Transferencia de Hipertexto -SMTP: Protocolo de Transferencia de Correo Simple -POP3: Protocolo de Oficina de Correo

MIDDLEWARE
Definicin: Capa de software intermedio entre el cliente y el servidor. Es la capa de software que nos permite gestionar los mecanismos de comunicaciones. Ejemplo, si se hace la peticin de una pgina web desde un browser en el cliente, el middleware determina la ubicacin y enva una peticin para dicha pgina. El servidor Web, interpreta la peticin y enva la pgina al software intermedio, quien la dirige al navegador de la mquina cliente que la solicit.

Existen dos tipos: -Software intermedio general. Servicios generales que requieren todos los clientes y servidores, por ejemplo: software para las comunicaciones usando el TCP/IP, software parte del sistema operativo que, por ejemplo, almacena los archivos distribuidos, software de autenticacin, el software intermedio de mensajes de clientes a servidores y viceversa. -Software intermedio de servicios. Software asociado a un servicio en particular, por ejemplo: software que permite a dos BD conectarse a una red cliente/servidor (ODBC: Conectividad abierta de BD), software de objetos distribuidos, por ejemplo la tecnologa CORBA permite que objetos distribuidos creados en distintos lenguajes coexistan en una misma red (intercambien mensajes), software intermedio para software de grupo, software intermedio asociado a productos de seguridad especficas (Conexiones Seguras: Sockets), etc.

Qu son los Sockets?

Sockets:
designa un concepto abstracto por el cual dos programas (posiblemente situados en computadoras distintas) pueden intercambiar cualquier flujo de datos, generalmente de manera fiable y ordenada.

Modelo de objetos distribuidos

Definicin: En los sistemas Cliente/Servidor, un objeto distribuido es aquel que est gestionado por un servidor y sus clientes invocan sus mtodos utilizando un "mtodo de invocacin remota". El cliente invoca el mtodo mediante un mensaje al servidor que gestiona el objeto, se ejecuta el mtodo del objeto en el servidor y el resultado se devuelve al cliente en otro mensaje.

Tecnologas orientadas a los objetos distribuidos:

Las tres tecnologas ms importantes y ms usadas en este mbito son:
-RMI.- Remote Invocation Method.- Fue el primer framework para crear sistemas distribuidos de Java. El sistema de Invocacin Remota de Mtodos (RMI) de Java permite, a un objeto que se est ejecutando en una Mquina Virtual Java (JVM), llamar a mtodos de otro objeto que est en otra Mquina Virtual (VM) diferente. Esta tecnologa est asociada al lenguaje de programacin Java, es decir, que permite la comunicacin entre objetos creados en este lenguaje.

Qu es el Framework?

Un Framework es:
literalmente un marco o ambiente de trabajo. Normalmente integra componentes variados para desarrollo de aplicaciones, pero dependen del lenguaje y ambiente de desarrollo. Por ejemplo, un framework para Java es Struts, un framework para Windows es .Net, etc.

-DCOM.- Distributed Component Object Model.- El Modelo de Objeto Componente Distribuido, est incluido en los sistemas operativos de Microsoft. Es un juego de conceptos e interfaces de programa, en el cual los objetos de programa del cliente, pueden solicitar servicios de objetos de programa servidores en otros ordenadores dentro de una red. Esta tecnologa est asociada a la plataforma de productos Microsoft. -CORBA.- Common Object Request Broker Architecture.Tecnologa introducida por el Grupo de Administracin de Objetos OMG, creada para establecer una plataforma para la gestin de objetos remotos independiente del lenguaje de programacin.

Arquitectura RMI
Conceptos Bsicos
La idea que sustenta RMI es un ideal recurrente en tecnologas de Orientacin a Objetos: hacer que un objeto invoque a otro objeto remoto con independencia de la JVM (Java Virtual Machine) o el servidor en el que se encuentra, como si fuera un objeto local.

Qu es una Mquina Virtual de Java?

Una Maquina Virtual Java es:

Aplicacin que interpreta y ejecuta programas escritos en el lenguaje de programacin Java. Especficamente puede interpretar el bytecode generado al compilar en Java. Lo que hace la JVM es terminar de compilar el bytecode en lenguaje mquina para que la aplicacin Java pueda ser ejecutada en un dispositivo especfico

Cliente Usa

Objeto remoto Exporta

Servidor

Hay varias cosas que debemos tener, una de ellas es un interfaz para el objeto remoto. Un concepto fundamental es que el cliente slo puede invocar al objeto remoto a travs de su interfaz remota. La interfaz remota es el "escaparate" del objeto remoto, es el modo en que el objeto remoto "exporta" sus servicios. Aquello a lo que el cliente accede est en el interfaz del objeto remoto. Lo que no significa que el objeto remoto no tenga otros mtodos, claro que puede tenerlos; pero slo los mtodos que estn en su interfaz son invocados por el cliente.

RMI (Remote Method Invocation):

Es un mecanismo que permite realizar llamadas a mtodos de objetos remotos situados en distintas (o la misma) mquinas virtuales de Java, compartiendo as recursos y carga de procesamiento a travs de varios sistemas.

Esquema RMI

La arquitectura RMI puede verse como un modelo de cuatro capas:

Aplicacin servidor

Aplicacin cliente

Stub

Capa proxy

Skeleton

Capa de referencia remota

Capa de transporte

La primera Aplicacin:

capa

es

la

de

y corresponde a la implementacin real de las aplicaciones cliente y servidor. Aqu tienen lugar las llamadas a alto nivel para acceder y exportar objetos remotos. Cualquier aplicacin que quiera que sus mtodos estn disponibles para su acceso por clientes remotos debe declarar dichos mtodos en una. Dicha interfaz se usa bsicamente para "marcar" un objeto como remotamente accesible. Una vez que los mtodos han sido implementados, el objeto debe ser exportado.

La capa 2 es la capa Proxy, o capa stub-skeleton:

Esta capa es la que interacta directamente con la capa de aplicacin. Todas las llamadas a objetos remotos y acciones junto con sus parmetros y retorno de objetos tienen lugar en esta capa.

Qu es el Proxy?

Un Proxy es:
Un programa o dispositivo que realiza una accin en representacin de otro, esto es, si una hipottica mquina a solicita un recurso a una c, lo har mediante una peticin a b; C entonces no sabr que la peticin procedi originalmente de a. Su finalidad ms habitual es la de servidor proxy, que sirve para interceptar las conexiones de red que un cliente hace a un servidor de destino, por varios motivos posibles como seguridad, rendimiento, anonimato, etc.

Esqueletos y Cabos (Stub-Skeleton)

RMI utiliza el mismo mecanismo que los sistemas RPC (llamadas a procedimientos remotos) para implementar la comunicacin con los objetos remotos, el basado en esqueletos y cabos. Los cabos forman parte de las referencias y actan como representantes de los objetos remotos ante sus clientes. En el cliente se invocan los mtodos del cabo, quien es el responsable de invocar de manera remota al cdigo que implementa al objeto remoto. En RMI un cabo de un objeto remoto implementa el mismo conjunto de interfaces remotas que el objeto remoto al cual representa.

Qu es el RPC?

El RPC es:
(Remote Procedure Call, Llamada a Procedimiento Remoto) es un protocolo que permite a un programa de ordenador ejecutar cdigo en otra mquina remota sin tener que preocuparse por las comunicaciones entre ambos. El protocolo es un gran avance sobre los sockets usados hasta el momento. De esta manera el programador no tena que estar pendiente de las comunicaciones, estando stas encapsuladas dentro de las RPC.

Cuando se invoca algn mtodo de un cabo, realiza las siguientes acciones:

Inicia una conexin con la MV (maquina virtual) que contiene al objeto remoto. Aplana y transmite los parmetros de la invocacin a la MV remota. Espera por el resultado de la invocacin. Des aplana y devuelve el valor de retorno o la excepcin. Devuelve el valor a quien lo llam.

Los cabos se encargan de ocultar el aplanado de los parmetros, as como los mecanismos de comunicacin empleados. En la MV remota, cada objeto debe poseer su esqueleto correspondiente. El esqueleto es responsable de despachar la invocacin al objeto remoto. Cuando un esqueleto recibe una invocacin, realiza las siguientes acciones: Des aplana los parmetros necesarios para la ejecucin del mtodo remoto. Invoca el mtodo de la implantacin del objeto remoto. Aplana los resultados y los enva de vuelta al cliente.

Esquema Esqueletos y Cabos (Stub-Skeleton)

La capa 3 es la de Referencia Remota:

Es responsable del manejo de la parte semntica de las invocaciones remotas. Tambin es responsable de la gestin de la replicacin de objetos y realizacin de tareas especficas de la implementacin con los objetos remotos, como el establecimiento de las persistencias semnticas y estrategias adecuadas para la recuperacin de conexiones perdidas. En esta capa se espera una conexin de tipo stream (stream-oriented connection, q es el flujos de datos) desde la capa de transporte.

La capa 4 es la de Transporte:

Es la responsable de realizar las conexiones necesarias y manejo del transporte de los datos de una mquina a otra. El protocolo de transporte subyacente para RMI es JRMP (Java Remote Method Protocol), que solamente es "comprendido" por programas Java.

En general la capa de transporte de RMI es responsable de: --Establecer conexiones al espacio de direcciones. --Manejar las conexiones. --Monitorear las conexiones actuales. -- Escuchar las llamadas. --Mantener una tabla de objetos remotos que residen en el espacio de direcciones. --Establecer una conexin para una llamada.

Toda aplicacin RMI normalmente se descompone en 2 partes:

Un servidor, que crea algunos objetos remotos, crea referencias para hacerlos accesibles, y espera a que el cliente los invoque. Un cliente, que obtiene una referencia a objetos remotos en el servidor, y los invoca.

Las metas que se pretenden alcanzar al soportar objetos distribuidos en Java, son:
-Proporcionar invocacin remota de objetos que se encuentran en MVs diferentes. -Soportar llamadas a los servidores desde los applets. -Integrar el modelo de objetos distribuidos en el lenguaje Java de una manera natural, conservando en medida de lo posible la semntica de los objetos Java. -Hacer tan simple como sea posible la escritura de aplicaciones distribuidas. -Preservar la seguridad proporcionada por el ambiente Java. -Proporcionar varias semnticas para las referencias de los objetos remotos (persistentes, no persistentes y de "activacin retardada").

Qu son las Applets?

Un Applet es:
Un applet es un componente de una aplicacin que se ejecuta en el contexto de otro programa, por ejemplo un navegador web. El applet debe ejecutarse en un contenedor, que lo proporciona un programa anfitrin, mediante un plugin, un applet no puede ejecutarse de manera independiente.

Activacin de Objetos Remotos

Los sistemas de objetos distribuidos estn diseados para soportar objetos persistentes de larga vida. Debido a que dichos sistemas pueden estar constituidos por miles o quizs millones de objetos, no es razonable que sus instancias siempre estn activas y consumiendo recursos, an cuando no se encuentren participando en ninguna tarea. Por otro lado, los clientes necesitan tener la capacidad de almacenar referencias persistentes de objetos, de manera tal que se pueda restablecer la comunicacin con ellos despus de un fallo en el sistema, o simplemente en una posterior ejecucin del cliente.

El mecanismo para proveer referencias persistentes y administrar la ejecucin de las implantaciones de los objetos, es la activacin automtica de dichos objetos. En RMI es posible activar dinmicamente los objetos en el momento en que son necesitados, es decir, cuando se accede a un objeto remoto "activable" va la ejecucin de alguno de sus mtodos, el sistema se encarga de ejecutar el objeto en una MV Java apropiada.

Terminologa Activables

de

Objetos

Un objeto remoto activo, es aquel que es instanciado y exportado en una MV Java. Un objeto remoto pasivo, es aquel que no ha sido instanciado o exportado, pero es susceptible de pasar al estado activo. El proceso de llevar un objeto pasivo a activo se conoce como activacin. La activacin requiere la asociacin de un objeto con una MV. Dicha asociacin incluye la carga del cdigo que implementa la clase en la MV, as como la restauracin del estado persistente del objeto, si es que lo tuviese.

En el sistema RMI se utiliza la activacin tarda (lazy activation), que consiste en retrasar la activacin del objeto hasta que algn cliente lo utilice por primera vez, es decir, la primera vez que se invoque alguno de sus mtodos.

Activacin Activation)

Tarda

(Lazy

La activacin tarda de objetos remotos se implanta utilizando lo que se conoce como una "referencia remota responsable" (faulting remote reference), algunas veces denominada "bloque responsable". Una referencia remota responsable a un objeto remoto, "responde" por la referencia del objeto activo durante la primera invocacin de algn mtodo del objeto. Cada referencia responsable mantiene tanto un manipulador persistente (un identificador de activacin) y una referencia remota transitoria al objeto remoto destinatario.

El identificador de activacin del objeto remoto contiene informacin suficiente para iniciar la activacin del objeto remoto y la referencia transitoria es la referencia "viva" real al objeto remoto activo, que puede utilizarse para comunicarse con l. En una referencia responsable, si la referencia viva a un objeto remoto es nula, no se sabe si el objeto destinatario est activo. Durante la invocacin del mtodo, la referencia responsable se compromete en el protocolo de activacin a obtener una referencia "viva", que es una referencia remota para el objeto recin activado. Una vez que la referencia responsable obtiene la referencia "viva", le reenva la invocacin del mtodo para que esta ltima a su vez reenve la invocacin al objeto remoto.

En trminos ms concretos, una referencia de objeto remoto contiene un tipo referencia remota responsable, que contiene dos cosas: -Un identificador de activacin para un objeto remoto y -Una referencia "viva" (posiblemente nula) que contiene el tipo referencia remota activa del objeto remoto.

Protocolo de Activacin

Durante la invocacin de un mtodo remoto, si no se conoce la referencia "viva" para el objeto destino, la referencia responsable se compromete en el protocolo de activacin. El protocolo de activacin involucra muchas entidades: la referencia responsable, el activador, un grupo de activacin en una MV Java y el objeto remoto que ser activado.

El activador (generalmente uno por mquina) es la entidad que supervisa la activacin, y acta como: Una base de datos que contiene las asociaciones entre los identificadores de activacin y la informacin necesaria para activar al objeto (la clase del objeto, su ubicacin -un camino URL-, de donde se puede obtener la clase, informacin que el objeto podra necesitar al momento de arrancar, etc.) y

Un administrador de mquinas virtuales, que se encarga de ejecutar MVs (cuando sea necesario) y de encaminar solicitudes de activacin de objetos (junto con la informacin necesaria) al grupo de activacin correcto dentro una MV remota. Un grupo de activacin (uno por cada MV Java) es la entidad que recibe la solicitud de activacin de un objeto en una MV y devuelve el objeto activado al activador.

El protocolo de activacin es como sigue. Una referencia responsable utiliza un identificador de activacin y llama al activador (mediante una interfaz RMI interna) para activar al objeto asociado con el identificador. El activador busca el descriptor de activacin (activation descriptor) del objeto (previamente registrado).

El descriptor del objeto contiene: Un identificador del grupo del objeto (especifica la MV en que ser activado), El nombre de la clase del objeto, Un URL que contenga el camino de dnde obtener el cdigo de la clase del objeto, Datos de inicializacin aplanados especficos al objeto (por ejemplo el nombre del archivo que contiene el estado persistente del objeto).