Download Presentación de PowerPoint - Departamento de Ingeniería Telemática

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
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
©2009 Marisol García Valls
Arquitecturas distribuidas
3
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
©2009 Marisol García Valls
Arquitecturas distribuidas
4
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.
©2009 Marisol García Valls
Arquitecturas distribuidas
5
Invocación de métodos remotos. Concepto
CountRMIClient
RMI Stub
CountRMIServer
RMI
sobre
TCP/IP
Cliente
RMI Skeleton
Servidor
Bus software
©2009 Marisol García Valls
Arquitecturas distribuidas
Java RMI. Objetivos
6
•
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
©2009 Marisol García Valls
Arquitecturas distribuidas
RMI. Arquitectura
7
Niveles
OSI
7
Cliente
6
Stubs
Servidor
Skeletons
 El Sistema RMI mismo está
formado por 3 niveles
El nivel Stubs/Skeletons
Remote Reference Layer
El nivel de Transporte
5
Remote Reference Layer
Hoy por hoy basado en TCP
4
Nivel de Transporte (TCP)
3
Nivel de Red (IP)
1y2
Interfaz Hardware
 El cliente y el servidor
desarrollan sus
aplicaciones en paralelo
La Red
©2009 Marisol García Valls
Podría ser sustituido por UDP
 El cliente invoca objetos
remotos a través de los Stubs
 Los Skeletons permiten hacer
accesibles los objetos servidores
al cliente
Arquitecturas distribuidas
8
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
©2009 Marisol García Valls
Arquitecturas distribuidas
9
Stubs y Skeletons (Sustitutos - Talones y Esqueletos)
Objeto
Objeto
Cliente
Remoto
Interfaz
remota
Skeleton
Stub
Red
©2009 Marisol García Valls
Arquitecturas distribuidas
10
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
©2009 Marisol García Valls
Arquitecturas distribuidas
11
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:
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?
•
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.
©2009 Marisol García Valls
Arquitecturas distribuidas
12
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.
©2009 Marisol García Valls
Arquitecturas distribuidas
13
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”.
java.io.Serializable
java.io.Serializable
java.io.Serializable
Clase2
Clase3 c
Clase3
MiClase
int a
transient long b
String s
Clase2 c
java.io.Serializable
Java.lang.String
©2009 Marisol García Valls
Arquitecturas distribuidas
14
El proceso de desarrollo
Definir una
interfaz remota
1
2
Implementar
la interfaz
3
(.class)
4
Clases
Servidoras
javac
rmic
Esqueleto de
servidor
(.class)
8
Implementar
el cliente
9
Stub de
cliente
(usa)
(.java)
javac
(.class)
10
Arrancar
el cliente
6
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
Arrancar el
registro RMI
Arrancar los
objetos servidores
7
Cliente
©2009 Marisol García Valls
5
1.
Registrar los
objetos remotos
Servidor
Arquitecturas distribuidas
15
Ubicación de ficheros
Cliente
Clase
Implementación
cliente
Clase de
Interfaz Remota
Clase Stub
©2009 Marisol García Valls
Servidor
Clase
Implementación
del Servidor
Clase de
Interfaz Remota
Clase
Skeleton
Clase
Stub
Arquitecturas distribuidas
16
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
©2009 Marisol García Valls
Arquitecturas distribuidas
17
Seguridad
•
RMI no descarga ficheros de clases remotas si no hay instalado un
SecurityManager.
•
Instalación:
System.setSecurityManager(new RMISecurityManager());
•
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.
©2009 Marisol García Valls
Arquitecturas distribuidas
18
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.
©2009 Marisol García Valls
Arquitecturas distribuidas
19
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.
©2009 Marisol García Valls
Arquitecturas distribuidas
20
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
©2009 Marisol García Valls
Arquitecturas distribuidas
21
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;
©2009 Marisol García Valls
Arquitecturas distribuidas
22
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
©2009 Marisol García Valls
Arquitecturas distribuidas
23
Clase RemoteObject (II)
¿Cómo se declara método en el objeto remoto?
¡Bien!
public void metodo(Object obj)
throws RemoteException;
¡Bien!
public void metodo(MyRemote remoto)
throws RemoteException;
¡MAL!
public void metodo(MiObjetoImpl miImpl)
throws RemoteException;
©2009 Marisol García Valls
Arquitecturas distribuidas
24
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.
©2009 Marisol García Valls
Arquitecturas distribuidas
25
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;
}
©2009 Marisol García Valls
Arquitecturas distribuidas
26
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);
}
}
©2009 Marisol García Valls
Arquitecturas distribuidas
27
Servidor de hora.
Generación del stub y skeleton
rmic DateServerImpl
DateServerImpl_Stub
DateServerImpl_Skel
©2009 Marisol García Valls
Arquitecturas distribuidas
28
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);
}
}
©2009 Marisol García Valls
Arquitecturas distribuidas
29
Servidor de hora.
Arranque de la aplicación
rmiregistry
java DateServerImpl
java DateClient localhost
©2009 Marisol García Valls
Arquitecturas distribuidas
30
Bibliografía
• G. Coulouris, et al. “Sistemas distribuidos. Conceptos y diseño”. Capítulo 5.
• R. Harold. “Java Network Programming”. Elliote Rusty Harold. ISBN 156592-227-1. O'Reilly.
©2009 Marisol García Valls
Arquitecturas distribuidas