CURSO: Sistemas Distribuidos

TEMA: RMI (Java Remote Method Invocation)

PROFESOR: Velásquez Diaz, Christian David

ALUMNO: Acero Cuica, David Arturo

Cevallos Ramírez, Edgar

Gaspar Juárez, Jesús Alejandro

Yllatupa Lancho, Jonathan

Yrigoyen Aspiazu, Eduardo

2019
DEFINICIÓN

RMI (Java Remote Method Invocation) es un mecanismo ofrecido por Java

para invocar un método de manera remota. Forma parte del entorno

estándar de ejecución de Java y proporciona un mecanismo simple para la

comunicación de servidores en aplicaciones distribuidas basadas

exclusivamente en Java. Si se requiere comunicación entre otras tecnologías

debe utilizarse CORBA o SOAP en lugar de RMI.

RMI se caracteriza por la facilidad de su uso en la programación por estar

específicamente diseñado para Java; proporciona paso de objetos por

referencia (no permitido por SOAP), recolección de basura distribuida (Garbage

Collector distribuido) y paso de tipos arbitrarios (funcionalidad no provista por

CORBA).

En el modelo de objetos distribuidos de Java, un objeto remoto es aquel cuyos

métodos pueden ser invocados por objetos que se encuentran en una máquina

virtual (MV) diferente.

Los objetos de este tipo se describen por una o más interfaces remotas que

contienen la definición de los métodos del objeto que es posible invocar

remotamente.

A través de RMI, un programa Java puede exportar un objeto, con lo que dicho

objeto estará accesible a través de la red y el programa permanece a la espera

de peticiones en un puerto TCP. A partir de ese momento, un cliente puede

conectarse e invocar los métodos proporcionados por el objeto.

de datos. El cliente luego prepara el requerimiento que envía a un objeto

ubicado en un servidor. El objeto remoto prepara la información requerida

(accediendo a bases de datos, otros objetos, etc). Finalmente, el objeto remoto

envía la respuesta al cliente. En lo posible esta interacción debería ser lo más

semejante posible a requerimientos hechos localmente.

CONCEPTOS

Las aplicaciones distribuidas requieren que componentes que se ejecutan en

diferentes procesadores se comuniquen entre sí.

Modelos:

 Sockets: Facilitan la generación dinámica de canales de comunicación.

Es actualmente la base de la comunicación. Pero al ser de muy bajo

nivel de abstracción, no son adecuados a nivel de aplicación.

 Remote Procedure Call (RPC): Abstrae la comunicación a nivel de

invocación de procedimientos. Es adecuada para programación

estructurada basada en librerías.

de métodos de objetos que se encuentran distribuidos por el sistema

distribuido.

CARACTERÍSTICAS

El sistema de Invocación de Métodos Remotos (RMI) de Java permite a un

objeto que se está ejecutando en una máquina llamar a métodos de otro objeto

residente en otra máquina diferente. RMI supone una evolución natural de RPC

a entornos con objetos Java distribuidos.

Las aplicaciones basadas en RMI, normalmente, comprenden dos programas

separados: un servidor y un cliente. Una aplicación servidora típica crea una

serie de objetos remotos, hace accesibles unas referencias a dichos objetos y

espera a que los clientes llamen a estos métodos u objetos remotos usando

estas referencias. RMI proporciona el mecanismo para la comunicación entre

objetos distribuidos.

A través de RMI, un programa Java puede exportar un objeto, con lo que dicho

objeto estará accesible a través de la red y el programa permanece a la espera

de peticiones en un puerto TCP. A partir de ese momento, un cliente puede

conectarse e invocar los métodos proporcionados por el objeto.

OBJETIVOS

Proporcionar un middelware para el desarrollo de aplicaciones distribuida

manteniendo un estilo Java puro y ortodoxo:

 Facilita la interacción de objetos instanciados en diferente JVM mediante

el paradigma de invocación de métodos de los objetos.

 Integra el modelo de objetos distribuidos en el lenguaje Java de una

forma natural y manteniendo la semántica que le es propia.

 Capacita para escribir aplicaciones distribuidas tan simple como sea

posible.

 Mantiene y preserva en aplicaciones distribuidas el tipado fuerte propio

de Java.

 Proporciona diferentes modelos de persistencia de objetos distribuidos

(objetos vivos, objetos persistentes, objetos con activación débil) para

conseguir la escalabilidad de las aplicaciones.

 Introduce los niveles de seguridad necesarios para garantizar la

integridad de las aplicaciones distribuidas.

Las aplicaciones RMI se componen de:

 Clientes: Conducen el flujo de la aplicación. Localizan e invocan

métodos ofertados como remotos por los servidores.

 Servidores: Conjunto de objetos que ofrecen interfaces remotas públicas

cuyos métodos pueden ser invocados clientes de cualquier procesador

de la plataforma.

 Registro: Servicio estático que se establece en cada nudo, en el que se

registran los servidores con un nombre, y donde los clientes los localizan

por él.

INVOCACIONES

Existen semejanzas y diferencias entre las invocaciones distribuidas y

localizadas, tales como:

 Una referencia a un objeto remoto puede ser pasado como parámetro de

un método, y devuelto como resultados de los métodos.

 El tipo de una referencia a un objeto remoto puede ser transformado por

operaciones de casting siempre que sean compatibles con sus

relaciones de herencias.

 A las referencias remotas se les puede aplicar el método instanceof()

para identificar dinámicamente las interfaces que soporta.

Diferencias:

 Los clientes interaccionan con los objetos remotos a través de las

interfaces remotas, no a través de implementaciones o interfaces

estándares.

 Los objetos que se pasan como parámetros de métodos que no son

remotos se pasan por copia (valor) y nunca por referencia.

 Los objetos que se pasan como parámetros de métodos que se

referencian por sus interfaces remotas se pasan por referencia y nunca

por valor.

 La semántica de los métodos heredados de Object es especializada

para los objetos remotos.

 Las invocaciones de objetos remoto pueden lanzar excepciones

adicionales que son propias de los mecanismos de comunicación.

SERVICIOS

RMI ofrece los siguientes servicios:

Localizar objetos remotos: Hay dos métodos para localizar un objeto remoto:

 En el rmiRegistry se pueden registrar objetos con un nombre. Otros

pueden buscar su referencia a través del mismo nombre.

 Un objeto puede pasar como parámetro u obtener como retorno de la

invocación de un método remoto, la referencia a un tercer objeto, y luego

usarlo para comunicarse con él.

Comunicar con objetos remotos: Un objeto que disponga de la referencia

remota (stub) de un objeto que ofrezca una interfaz remota, puede invocar los
métodos remotos sobre él, en una forma similar a la invocación de cualquier

método públicos.

Descargar objetos remotos: RMI ofrece mecanismos para transferir por valor

los objetos que se pasan como parámetro de los métodos que se invocan. Esta

transferencia incluye la transferencia de su código (bytecodes) y de su estado.

ARQUITECTURA

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

Primera capa

La primera capa es la de aplicación y se corresponde con la implementación

real de las aplicaciones cliente y servidor. Aquí tienen lugar las llamadas a alto

nivel para acceder y exportar objetos remotos. Cualquier aplicación que quiera

que sus métodos estén disponibles para su acceso por clientes remotos debe

declarar dichos métodos en una interfaz que extienda java.rmi.Remote. Dicha

interfaz se usa básicamente para "marcar" un objeto como remotamente

accesible. Una vez que los métodos han sido implementados, el objeto debe

ser exportado. Esto puede hacerse de forma implícita si el objeto extiende la

clase UnicastRemoteObject (paquete java.rmi.server), o puede hacerse de

forma explícita con una llamada al método exportObject() del mismo paquete.

Segunda capa

La capa 2 es la capa proxy, o capa stub-skeleton. Esta capa es la que

interactúa directamente con la capa de aplicación. Todas las llamadas a

tienen lugar en esta capa.

Tercera capa

La capa 3 es la de referencia remota, y es responsable del manejo de la parte

semántica de las invocaciones remotas. También es responsable de la gestión

de la replicación de objetos y realización de tareas específicas de la

implementación con los objetos remotos, como el establecimiento de las

persistencias semánticas y estrategias adecuadas para la recuperación de

conexiones perdidas. En esta capa se espera una conexión de tipo stream

(stream-oriented connection) desde la capa de transporte.

Cuarta capa

La capa 4 es la de transporte. Es la responsable de realizar las conexiones

necesarias y manejo del transporte de los datos de una máquina a otra. El

protocolo de transporte subyacente para RMI es JRMP (Java Remote Method

Protocol), que solamente es "comprendido" por programas Java.

Arquitectura básica de procesos de RMI:

1. El servidor debe registrarse (bind) en el registry bajo un nombre.

2. El cliente localiza (lookup) la referencia de servidor en el registry por su

nombre.

3. El cliente crea un stub que referencia al skeleton

4. El cliente invoca localmente el stub.

5. El stub transfiere como un mensaje la invocación al skeleton.

6. El skeleton invocamente localmente el método del servidor.

7. El skeleton transfiere al stub como mensaje los resultados obtenidos de la

invocación.
8. El stub finaliza la invocación del cliente retornándole los resultados.

COMUNICACIÓN

Stub y skeleton

1. Un cliente invoca un método remoto invocando localmente el mismo método

en el stub.
2. The stub genera un mensaje que contiene: la referencia al método y un

stream de bytes que resulta de secuencializar los parámetros del método.

3. El stub crea dinámicamente un socket y establece la conexión con el

skeleton.

4. El skeleton recibe el mensaje los decodifica y delega en un thread la

invocación del método del servidor. Quedando dispuesto de nuevo a la

recepción de un nuevo mensaje (no siempre es multithread).

5. El thread genera un mensaje con el stream de bytes que corresponde a la

secuencialización de los resultados de la invocación.

6. El thread envía por el socket abierto el mensaje de retorno.

7. El stub decodifica el mensaje y concluye la invocación inicial retornando los

resultados al cliente.

CONCLUSIONES