Este documento proporciona una introducción a Java RMI (Remote Method Invocation), incluyendo su arquitectura, servicios, uso de stubs y skeletons, paso de parámetros, marshalling y secuenciación de objetos. También presenta un ejemplo de un servidor de hora remoto utilizando RMI con las clases e interfaces necesarias, así como los pasos para generar stubs y skeletons, y ejecutar el cliente y servidor.

1. RMI: Invocación a método remoto, y
Java RMI
Arquitecturas Distribuidas
2º Ingeniero de Telecomunicación. Especialidad Telemática
Departamento de Ingeniería Telemática
Universidad Carlos III de Madrid
mvalls@it.uc3m.es

2. 2
Arquitecturas distribuidas
Indice
• Introducción a RMI
• Arquitectura de Java RMI
• Servicios que ofrece Java RMI
• Stubs y Skeletons
• Paso de parámetros
– Paso por valor
– Paso por referencia
– Marshalling y secuenciación de objetos
• Ejemplo: un servidor de hora remoto

3. 3
Arquitecturas distribuidas
Objetos distribuidos
• En un programa centralizado las invocaciones entre objetos son locales.
• En un programa distribuido existen objetos distribuidos y puede haber tanto
invocaciones locales como remotas.
• Las invocaciones concurrentes sobre un objeto distribuido son posibles.
• Un objeto distribuido que pueda sufrir invocaciones concurrentes deberá proteger
su estado adecuadamente.
• Los objetos remotos son aquellos que pueden recibir invocaciones
remotas.
• Conceptos clave en el modelo distribuido son:
– Referencia a objeto remoto
– Interfaz remota

4. 4
Arquitecturas distribuidas
Referencias remotas e Interfaces remotas
• Referencia remota: identificador que puede ser utilizado a lo largo y ancho de
un sistema distribuido para referirse a un objeto remoto único y particular.
• Son análogas a las referencias a objetos locales porque:
– El objeto cuyo método se va a invocar se especifica como una referencia remota.
– Las referencias remotas pueden pasarse como argumentos y resultados de
invocaciones a métodos remotos.
• Interfaz remota: identifica qué funcionalidad (métodos) de un objeto remoto
puede ser utilizada remotamente.
• Por lo tanto, un objeto remoto debe siempre implementar una interfaz remota para
permitir la recepción de invocaciones remotas.
• En Java, las interfaces remotas se definen con el propio lenguaje Java.

5. 5
Arquitecturas distribuidas
Invocación de métodos remotos. Concepto
CountRMIClient
RMI Stub
CountRMIServer
RMI Skeleton
Cliente Servidor
RMI
sobre
TCP/IP
Bus softwareBus software

6. 6
Arquitecturas distribuidas
Java RMI. Objetivos
• Permitir invocación remota de métodos en objetos que residen en
diferentes Máquinas Virtuales
• Integrar el Modelo de Objetos Distribuidos al lenguaje Java de modo
natural, preservando en lo posible la semántica de objetos en Java
– Permitir la utilización de objetos locales y remotos
– Permitir diferentes semánticas en las referencias a objetos remotos: no
persistentes (vivas), persistentes, de activación lenta
• Preservar la seguridad de tipos (type safety) dada por el ambiente de
ejecución Java
– Mantener la seguridad del ambiente dada por los Security Managers y
Class Loaders
• Facilitar el desarrollo de aplicaciones distribuidas

7. 7
Arquitecturas distribuidas
RMI. Arquitectura
Cliente Servidor
Remote Reference Layer
Nivel de Transporte (TCP)
Stubs Skeletons
Nivel de Red (IP)
Interfaz Hardware
La Red
1 y 2
3
4
5
6
7
Niveles
OSI El Sistema RMI mismo está
formado por 3 niveles
El nivel Stubs/Skeletons
Remote Reference
Layer
El nivel de Transporte
Hoy por hoy basado en TCP
Podría ser sustituido por
UDP
El cliente y el servidor
desarrollan sus
aplicaciones en paralelo
El cliente invoca objetos
remotos a través de los Stubs
Los Skeletons permiten hacer
accesibles los objetos
servidores al cliente

8. 8
Arquitecturas distribuidas
Servicios existentes en RMI
• Secuenciación de objetos: Serialization
• Servicio de nombrado: Naming Service
• Descarga de clases por la red: Loader
• Seguridad extra: Security Manager
• Recolección de basura distribuida: Distributed
Garbage Colector

9. 9
Arquitecturas distribuidas
Stubs y Skeletons (Sustitutos - Talones y Esqueletos)
Objeto
Cliente
Objeto
Remoto
Stub
Skeleton
Interfaz
remota
Red

10. 10
Arquitecturas distribuidas
Paso de Parámetros a Métodos Remotos
Hay 3 mecanismos básicos
1. Tipos primitivos : se pasan por valor (copia). Todos son serializables
2. Objetos Remotos: se pasan por referencia (sustitutos-talones,
usados para invocar métodos remotos).
3. Objetos Locales: se pasan por valor (sólo si son serializables), se
crea un nuevo objeto en la Máquina Virtual que recibe la copia.
Observaciones
1. Los objetos remotos no viajan, en cambio se envían referencias
2. Un sustituto-talón se debe convertir al tipo (cast) de las interfaces
remotas que implemente la clase del objeto remoto al que corresponde
3. Si un objeto remoto implementa varias interfaces remotas un cliente
sólo puede convertir el sustituto (talón) a una de ellas
4. Dos sustitutos (talones) que se refieren al mismo objeto remoto en el
mismo servidor se consideran iguales bajo la operación equals

11. 11
Arquitecturas distribuidas
Marshalling de parámetros y serialización
• Marshalling hace referencia al empaquetado de los parámetros involucrados en la
llamada a un procedimiento remoto.
• El paso de parámetros por valor introduce un problema:
• Secuenciar un objeto consiste en convertirlo en una secuencia de bits que representa a
ese objeto.
• Para hacer que un objeto sea secuenciable, éste debe implementar el interfaz
java.lang.Serializable
• Es una interfaz de marcado (no contiene métodos): indica que un objeto puede ser
secuenciable (serializable) y reconstruible (deserializable).
• Es posible implementar una secuenciación a medida (custom serialization) con
writeObject() y readObject().
• Normalmente los mecanismos existentes por defecto son suficientemente buenos.
Si se pasa un objeto por la red y éste contiene referencias a otros objetos,
¿cómo se resuelven las referencias en la máquina de destino?

12. 12
Arquitecturas distribuidas
Reglas para secuenciar objetos
• Las variables y objetos miembros cumplen las reglas de secuenciación.
• Cualquier tipo primitivo (int, char, etc.) es secuenciado
automáticamente y está disponible en la reconstrucción.
• Los objetos contenidos en el objeto a secuenciar pueden o no ser
secuenciados:
– Si se marcan con la palabra transient, éstos no son secuenciados con el
objeto y no están disponibles en la reconstrucción.
– Los objetos no marcados con transient deberán implementar el interfaz
java.io.Serializable.
– Si no están marcados con transient ni implementan java.io.Serializable,
se lanza una excepción NotSerializable.
• Objetos transient típicos:
– objetos muy grandes
– recursos no reconstruibles en la máquina de destino (sockets o conexiones a bases
de datos)
– información confidencial.

13. 13
Arquitecturas distribuidas
Secuenciación recursiva
• Cuando se secuencia un objeto, todos sus objetos no transient, también
serán secuenciados.
• Esto se realiza de forma recursiva para todos los “subojetos”.
MiClase
int a
transient long b
String s
Clase2 c
java.io.Serializable
Clase2
java.io.Serializable
Clase3 c
Clase3
java.io.Serializable
Java.lang.Strin
g
java.io.Serializable

14. 14
Arquitecturas distribuidas
El proceso de desarrollo
1. Extender java.rmi.Remote
2. Implementar
java.rmi.UnicastRemoteOb
ject
3. Compilar la clase
implementación
4. rmic <clase implement.>
5. Start rmiregistry
6. Arrancar los objetos del servidor
7. Registrar los objetos remotos
(Heredando de
java.rmi.Naming para
asociar un nombre con el objeto
remoto)
8. Escribir el código cliente
(Heredando de
java.rmi.Naming para
localizar el objeto remoto)
9. Compilar el código cliente
10. Arrancar el cliente
Definir una
interfaz remota
Stub de
cliente
javac
rmic
Implementar
la interfaz
Implementar
el cliente
javac
Arrancar
el cliente
Clases
Servidoras
Arrancar el
registro RMI
Arrancar los
objetos servidores
Registrar los
objetos remotos
Esqueleto de
servidor
(.class)
(.class)
(.java)
(.class)
(usa)
Cliente Servidor
1
2
4
8
10
9
5
6
7
3

15. 15
Arquitecturas distribuidas
Ubicación de ficheros
Cliente
Clase
Implementación
cliente
Clase de
Interfaz Remota
Clase Stub
Servidor
Clase
Implementación
del Servidor
Clase de
Interfaz Remota
Clase
Stub
Clase
Skeleton

16. 16
Arquitecturas distribuidas
Carga automática de clases
• Si se encuentra un nombre de clase desconocido se descarga de una ubicación
estándar (primero buscando en el CLASSPATH).
• Si no, si el nombre desconocido se encuentra en:
– El servidor como parámetro de una RMI o el cliente como resultado de una RMI, se
busca en una URL interna.
– Si la desconocida es una clase local (p.ej. el skeleton), el entorno de Java RMI
busca en una URL especificada en java.rmi.server.codebase.
• Para permitir a un cliente RMI la descarga automática de ficheros stub del servidor
RMI:
java –Djava.rmi.server.codebase=http://maquina.com/ruta/clases/ ServImpl

17. 17
Arquitecturas distribuidas
Seguridad
• RMI no descarga ficheros de clases remotas si no hay instalado un
SecurityManager.
• Instalación:
• El RMISecurityManager es una implementación simple de SecurityManager que
permite la descarga de stubs remotos.
• RMISecurityManager no permite que las clases descargadas realicen operaciones
arriesgadas (acceso a código nativo, ficheros, etc.).
• Para que las clases descargadas tengan otros niveles de acceso, se deberá
instalar una subclase de RMISecurityManager y cambiar la imposición de
seguridad convenientemente.
System.setSecurityManager(new RMISecurityManager());

18. 18
Arquitecturas distribuidas
Paquetes RMI
• java.rmi. Clientes: para acceder a servicios remotos RMI y
para ubicar servicios RMI en máquinas remotas.
• java.rmi.server. Servidores: para hacer accesible un
servicio RMI a peticiones TCP/IP y HTTP proxy.
• java.rmi.registry. Creación y ubicación de registros de
nombres.
• java.rmi.dgc. Recolección de basura para un entorno
distribuido.
• java.rmi.activation (jdk 1.2). Permite que los servidores sólo
sean activados cuando haya una petición real de servicio.

19. 19
Arquitecturas distribuidas
Interfaz Remote
• Describe los métodos que soporta un objeto remoto (son los únicos
accesibles por un cliente).
• Todos los parámetros y resultados de un método remoto deben ser
secuenciables.
• Todos los métodos de una interfaz remota deben declarar que lanzan
RemoteException.

20. 20
Arquitecturas distribuidas
Clase Naming
• Permite la manipulación de registros de nombres.
• Permite a los clientes localizar objetos remotos almacenados en el
registro de nombres.
• Permite a los servidores registrar objetos remotos.
• Las direcciones que utiliza son de tipo URL:
rmi://maquina:puerto/ruta

21. 21
Arquitecturas distribuidas
Clase Naming (II)
• Todos los métodos son estáticos.
Remote lookup(String address) throws MalformedURLException,
RemoteException, NotBoundException;
void bind(String address, Remote object) throws
MalformedURLException,RemoteException,AlreadyBoundException;
void rebind(String address, Remote object) throws
MalformedURLException, RemoteException;
void unbind(String address) throws MalformedURLException,
RemoteException, NotBoundException;
String[] list(String address) throws MalformedURLException,
RemoteException;

22. 22
Arquitecturas distribuidas
Clase RemoteObject (I)
• Es la superclase de las implementaciones de objetos remotos y de los stubs
remotos.
• Cuando se pasa un objeto remoto como parámetro, se pasa una referencia.
• Lo que recibe el método remoto es una instancia de una clase stub RMI.
• Este stub RMI, internamente contiene una ref. remota a la implementación real del
objeto.
• Por tanto, sólo se pueden definir métodos remotos que reciben como parámetros
objetos no remotos o interfaces remotas.
public class MiObjImpl extends UnicastRemoteObject implements MyRemote {
// ...
public static void main(String[] args) throws Exception {
MiObjImpl miobj = new MiObjImpl();
OtroObjRem otro = (OtroObjRem) Naming.lookup(“//server/otro”);
otro.metodo(miobj);
}
} // fin clase

23. 23
Arquitecturas distribuidas
Clase RemoteObject (II)
¡Bien! public void metodo(Object obj)
throws RemoteException;
¡Bien! public void metodo(MyRemote remoto)
throws RemoteException;
¡MAL! public void metodo(MiObjetoImpl miImpl)
throws RemoteException;
¿Cómo se declara método en el objeto remoto?

24. 24
Arquitecturas distribuidas
Clase UnicastRemoteObject
• Subclase de RemoteServer.
• Normalmente los objetos remotos extenderán de esta clase.
• Presenta soporte para clone() para obtener otro objeto remoto único.
UnicastRemoteObject(int port)
throws RemoteException;
Constructor donde se indica el puerto donde se escucha.
boolean unexportedObject(Remote object,boolean force) throws
NoSuchObjectException;
El objeto no estará disponible para aceptar llamadas remotas. Si está siendo usado
devuelve false.

25. 25
Arquitecturas distribuidas
Servidor de hora. Interfaz DateServer
import java.rmi.Remote;
import java.rmi.RemoteException;
import java.util.Date;
public interface DateServer extends Remote {
public Date getDate() throws RemoteException;
}

26. 26
Arquitecturas distribuidas
Servidor de hora. Implementación objeto remoto
import java.rmi.*;
import java.rmi.server.*;
import java.util.Date;
public class DateServerImpl extends UnicastRemoteObject
implements DateServer {
public DateServerImpl getDate() throws RemoteException{}
public Date getDate() { return new Date(); }
public static void main(String[] args) throws Exception{
DateServerImpl dateServer = new DateServerImpl();
Naming.bind(“Date Server”, dateServer);
}
}

27. 27
Arquitecturas distribuidas
Servidor de hora. Generación del stub y skeleton
rmic DateServerImpl
DateServerImpl_Stub
DateServerImpl_Skel

28. 28
Arquitecturas distribuidas
Servidor de hora. Clase DateClient
Import java.rmi.Naming;
Import java.util.Date;
public class DateClient {
public static void main(String[] args) throws Exception{
if (args.length != 1)
throw new IllegalArgumentException (“Syntax:
DateClient <hostname>”);
DateServer dateServer = (DateServer) Naming.lookup
(“rmi://” + args[0] + “/DateServer”);
Date when = dateServer.getDate();
System.out.println(when);
}
}

29. 29
Arquitecturas distribuidas
Servidor de hora. Arranque de la aplicación
rmiregistry
java DateServerImpl
java DateClient localhost

30. 30
Arquitecturas distribuidas
Bibliografía
• G. Coulouris, et al. “Sistemas distribuidos. Conceptos y diseño”. Capítulo
5.
• R. Harold. “Java Network Programming”. Elliote Rusty Harold. ISBN 1-
56592-227-1. O'Reilly.