SISTEMAS DISTRIBUIDOS

TEMA 3.2: RMI (Remote Method Invocation)

1. Concepto de RMI
El mecanismo de Invocación a Métodos Remotos (RMI, Remote Method Invocation) surge
como resultado de la evolución de las Llamadas a Procedimientos Remotos (RPC) hacia la
programación orientada a objetos.

Cada proceso contiene un conjunto de objetos que pueden recibir invocaciones. Las
invocaciones de métodos entre objetos en diferentes procesos, tanto si es en el mismo
computador o no, se conocen como invocaciones de métodos remotas. Las invocaciones entre
objetos del mismo proceso se denominan invocaciones de métodos locales.

 Para que otros objetos puedan invocar los métodos de un objeto remoto, es necesario
que tengan acceso a su referencia de objeto remoto. La referencia a objeto remoto es
un identificador que puede usarse a lo largo de todo un sistema distribuido para
referirse a un objeto remoto particular único. Por ejemplo, en la figura anterior, deberá
estar disponible para A una referencia a un objeto remoto sobre B.

 RMI está construido sobre los protocolos de petición-repuesta, lo que permite pasar
objetos como argumentos y retornar objetos.

 Con RMI se pueden utilizar todas las herramientas del paradigma de programación
orientada a objetos: clases, objetos, herencia, excepciones.

 Interfaces Remotas. Cada objeto remoto tiene una interfaz remota que especifica
cuáles de sus métodos pueden invocarse remotamente. Los objetos en otros procesos
pueden invocar solamente los métodos que pertenezcan a su interfaz remota, mientras
que los objetos locales pueden invocar los métodos especificados en la interfaz remota
y otros métodos implementados por un objeto remoto y no especificados en la interfaz.

1
 2. Semántica de invocación
Son las mismas semánticas de invocaciones que teníamos para RPC. Dependiendo de la
tolerancia a fallos que puedas prever, utilizarás una u otra.

 maybe. (quizás) El proceso que invoca no puede decir si un método se ha

ejecutado una vez, o ninguna en absoluto. La semántica maybe aparece cuando
no se aplica ninguna medida de tolerancia ante fallos.

Esta semántica es útil solo en aplicaciones donde es aceptable que haya

invocaciones fallidas.

 at-least-once (al menos una vez). Con la semántica de invocación al menos una
vez, el proceso que invoca retransmite los mensajes de invocación. El método
se puede ejecutar varias veces.

 at-most-once (a lo sumo una vez). Con la semántica de invocación como

máximo una vez, el proceso invocante sabe que el método se ejecutó
exactamente una vez, o una excepción le informa de que no se recibió el
resultado, de modo que el método se habrá ejecutado una vez o ninguna en
absoluto.

3. Java RMI
Java RMI extiende el modelo de objetos de Java para proporcionar soporte de objetos
distribuidos en el lenguaje Java. En particular, permite que los objetos invoquen métodos sobre
objetos remotos empleando la misma sintaxis que en las invocaciones locales.

El soporte para RMI en Java está basado en las interfaces y clases definidas en los paquetes
java.rmi y java.rmi.server. Estos paquetes ofrecen:

-Mecanismos para crear servidores y objetos cuyos métodos se puedan invocar

remotamente.

-Mecanismos que permitan a los clientes localizar objetos remotos.

-Servicio de directorios. rmiregistry es un servicio de directorios de Java que se ejecuta

en la máquina servidor objeto. En cada computador que aloje objetos remotos deberá
haber un ejemplar de rmiregistry, el cual contiene referencias a objetos remotos
presentes en ese computador.

2
  3.1 Arquitectura de RMI
En una invocación de método remoto están involucrados varios objetos y módulos separados.

-Stub (proxy). El papel del stub es hacer que la invocación del método remoto sea
transparente para los clientes, y para ello se comporta como un objeto local que se invoca. Pero,
en lugar de ejecutar la invocación, dirige el mensaje al objeto remoto,

Oculta los detalles de la referencia al objeto remoto, el empaquetado de los

argumentos, el desempaquetado de los resultados y el envío y recepción de los mensajes desde
el cliente.

Existe un stub para cada objeto remoto del que el cliente disponda de una referencia de
objeto remoto.

-Skeleton (esqueleto). La clase de un objeto remoto tiene un esqueleto, que

implementa los métodos de la interfaz remota. Un método del esqueleto desempaqueta los
argumentos del mensaje de petición e invoca al método correspondiente en el objeto remoto.
Espera la consumación de la invocación y después empaqueta el resultado, junto con las
excepciones producidas, en un mensaje de respuesta.

- RMIRegistry se encarga de traducir las referencias entre objetos locales y remotos, y

de crear referencias a objetos remotos. El stub y skeleton llaman a este módulo cuando realizan
el empaquetado y desempaquetado de las referencias a objetos a remotos. Por ejemplo, cuando
llega un mensaje de petición, se utiliza el rmiregistry para encontrar qué objeto local se va a
invocar.

3
  3.2 Diseño de aplicaciones RMI

1. Definición de la interfaz remota.

Las interfaces remotas se definen mediante la extensión de

una interfaz denominada Remote que proporciona el
paquete java.rmi. Los métodos deberán lanzar
RemoteException, además de lanzar las excepciones
específicas de la aplicación.

2. Implementación de la interfaz remota.

El servidor contará con una clase para implementar

cada una de las interfaces remotas que se han
definido.

Observe que está clase extiende una clase

denominada UnicastRemoteObject, que
proporciona objetos remotos que duran tanto
tiempo como el proceso en que son creadas.

4
3. Diseño por parte del servidor
a. Implementar la interfaz remota
b. Generar el resguardo y el esqueleto. Para generar el stub y el skeleton existe
una herramienta llamada rmic que los genera automáticamente.

4. Plantilla de clase de servidor de objetos

5
 5. Plantilla de clase de cliente de objetos

4. Síncrono vs Asíncrono
Un aspecto común entre Java RMI y ZeroC Ice, es que la invocación a objetos se puede hacer
de dos formas:

-Síncrona. El cliente realiza la invocación al método y espera la respuesta del servidor. Este
paradigma tiene un problema de escalabilidad, ya que, si tuviéramos que llamar a una gran
cantidad de objetos, habría que hacerlo uno a uno y no se podría llamar a un determinado
método hasta que no se hubiera obtenido la respuesta del anterior.

-Asíncrona. El cliente realiza la invocación de un objeto, pero continua su ejecución sin esperar
la respuesta. El problema de la escalabilidad se resuelve porque puedo, por ejemplo, crear un
hilo para cada invocación y esperar a que me hayan respondido todos. Hay tres alternativas:

-Esperar a que se hayan completado todas las invocaciones.

-Polling. Preguntar cada cierto tiempo

-Callback. En RMI, el callback de cliente es una característica que permite a un objeto

cliente registrarse a sí mismo con un objeto servidor remoto para callbacks, de forma que el
servidor pueda llevar a cabo una invocación al método del cliente cuando el evento ocurra.

 Asynchronous Method Dispatch (AMD) : El servidor utiliza hilos para atender varios
clientes de forma simultánea. Esta técnica tiene que ser transparente para el cliente, y
debe permitir encolar peticiones para minimizar el tiempo de espera de los clientes.

6
 5. Nomenclatura
 Adaptador de objetos. Es un objeto encargado de mantener todas las referencias de los
objetos que se sirven en una determinada computadora, de forma que cuando llega una
petición a un método es capaz de redirigirla al código del skeleton adecuado.

 Servant: Implementación del servidor

.
 Proxy. El papel del proxy es hacer que la invocación al método remoto sea transparente
para los clientes, y para ello se comporta como un objeto local para el que invoca, pero
en lugar de ejecutar la invocación, dirige el mensaje al objeto remoto. Oculta los detalles
de la referencia al objeto remoto, el empaquetado de los argumentos, el
desempaquetado de los resultados y el envío y recepción de los mensajes desde el
cliente.

 Stub Se encarga de la serialización / deserialización.

 Skeleton Se encarga de la serialización / deserialización.

6. Caso de Estudio: CORBA

CORBA es un diseño de middleware que permite que los programas de aplicación se
comuniquen unos con otros con independencia de sus lenguajes de programación, sus
plataformas hardware y software, las redes sobre las que se comunican y sus implementaciones.

Las aplicaciones se construyen mediante objetos CORBA, que implementan interfaces definidas
en el lenguaje de definición de interfaces de CORBA, IDL. Los clientes acceden a los métodos de
las interfaces de los objetos de CORBA mediante RMI. El componente middleware que da
soporte a RMI se denomina Object Request Broker u ORB. Se han implementado versiones muy
diferentes de ORB, que soportan variedad de lenguajes de programación.

La invocación remota en CORBA define, por defecto, la semántica cómo máximo una vez. Sin
embargo, IDL puede especificar que la invocación de un método tenga semántica puede ser
mediante la palabra clave oneway.

7
 7. Caso de Estudio: ZeroC Ice
Ice (Internet Communication Engine) es un middleware de comunicaciones orientado a objetos
distribuidos desarrollado por la empresa ZeroC Inc.

Ice soporta múltiples lenguajes (Java, C#, C++, ObjectiveC, Python, Ruby, PHP, etc.) y
multiplataforma (Windows, GNU/Linux, Solaris, Mac OS X, Android, IOS, etc.) lo que proporciona
una gran flexibilidad

ICE hereda de CORBA un gran parte de su terminología, aunque difiere de él en algunos

conceptos calves.