Visión General de Rmi: Servidorejemplo Objetoremoto Int S S Objetoremoto - Sum (1,2)

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 7

1.

Visión general de RMI


Java RMI permite al programador ejecutar métodos de objetos remotos utilizando la
misma semántica que si fueran invocaciones locales (Véase Figura 1).

Máquina Local (Cliente) Máquina Remota (Servidor)

ServidorEjemplo objetoRemoto;
int s;

s = objetoRemoto.sum(1,2); 1,2
public int sum(int a,int b)
{
return a + b;
}
System.out.println(s);
3

Figura 1. Invocación remota.

La Figura 2 muestra la arquitectura general de una aplicación RMI.

Máquina Remota

bind
Servidor RMI

rmiRegistry
skeleton

retorno invocación
lookup

stub

Cliente RMI

Máquina Local
Figura 2. Estructura general de una aplicación RMI.
• El servidor debe, en primer lugar, registrar su nombre en la utilidad de registro
(rmiregistry)
• El cliente debe buscar el nombre del servidor en la utilidad de registro con el fin
de obtener una referencia del objeto remoto.
• El stub (en el lado cliente) serializa los parámetros del método invocado y se los
envía, vía red, al skeleton (en el lado servidor), invoca al método ya en local y
devuelve el resultado al stub.

Sistemas Distribuidos:: Java RMI EUI-SG/INFOR.UVA.ES 1


1.1 El Stub y el Skeleton

invocación

Skeleton
Stub
Cliente RMI Servidor RMI
retorno

Figura 3. Papel del stub y del skel en una aplicación RMI


• Un cliente invoca a un método remoto, la invocación es redirigida primero al stub.
• El stub es el responsable de “transmitir” la invocación remota hacia el skeleton
que está en el lado del servidor.
• Para ello el stub abre una conexión (mediante un socket) con el servidor remoto,
empaqueta los parámetros de la invocación y la redirige a través del flujo de datos
hacia el skeleton.
• El skeleton posee un método que recibe las llamadas remotas, desempaqueta los
parámetros e invoca al la implementación real del objeto remoto.
2. Pasos en el desarrollo de una aplicación RMI:
1. Definir la interfaz remota.
2. Desarrollar el objeto remoto mediante la implementación de la interfaz remota.
3. Desarrollar el problema del cliente.
4. Compilar los ficheros fuente en Java.
5. Generar los stubs del cliente y los skeletons del servidor mediante la utilidad rmic
y tomando como entrada la clase con la implementación del objeto remoto.
6. Iniciar la utilidad de registro, rmiregistry.
7. Lanzar el servidor de objetos remotos.
8. Ejecutar el cliente.
Paso 1. Definición de la Interfaz Remota
Para crear una aplicación remota, el primer paso es la definición de una interfaz remota
entre los objetos del cliente y del servidor. Es importante fijarse que:
• La interfaz remota definida debe derivar de la interfaz Remote
• Los métodos declarados en la interfaz deben lanzar la excepción
RemoteException
/* ServidorEjemplo.java */
import java.rmi.*;

public interface ServidorEjemplo extends Remote


{
public int sum(int a,int b) throws RemoteException;
}

Paso 2. Desarrollar el objeto remoto mediante la implementación de la interfaz


remota
Es importante hacer notar que:
• El servidor remoto se define (se deriva) a partir de la clase
java.rmi.server.UnicastRemoteObject.
• El servidor remoto debe implementar la interfaz remota definida en el Paso 1.

Sistemas Distribuidos:: Java RMI EUI-SG/INFOR.UVA.ES 2


• El servidor utilice un gestor de seguridad RMI propio (RMISecurityManager)
para garantizar sus recursos durante el transcurso de la comunicación con el
cliente.
/* ServidorEjemploImpl.java */
import java.rmi.*;
import java.rmi.server.*;
import java.rmi.registry.*;

public class ServidorEjemploImpl extends UnicastRemoteObject


implements ServidorEjemplo
{
ServidorEjemploImpl() throws RemoteException
{
super();
}

• El método main() de la clase servidora actúa como un cargador del objeto


remoto: crea el objeto, un gestor de seguridad y es responsable de registrar la
instancia del objeto remoto creada:
• El servidor debe registrar su nombre ante la utilidad de cliente, para que el cliente
luego pueda localizar, después, una referencia al objeto. Para ello, se utiliza la
clase java.rmi.Naming para registrar el nombre de la clase servidora en la
utilidad del registro. El nombre utilizado, es un nombre lógico y no tiene que ver
nada con el nombre de las clases, en el ejemplo “SERVIDOR-EJEMPLO”.
• En el método main() del objeto servidor, se crea y se instala el gestor de
seguridad RMI, un objeto de la clase RMISecurityManager, que controla la
descarga y ejecución de código en la maquina virtual Java (JVM) del servidor. La
JVM permite la descarga de código y su posterior ejecución, en el caso de las
aplicaciones RMI esto es útil para que el cliente se pueda bajar, por ejemplo, los
stubs de la clase remota. Para soportar esta funcionalidad es necesario que en la
máquina que actúa como servidor RMI disponga de un servidor web funcionando
y se almacenen el código de las clases en un “sitio” reconocido por el servidor
web.
/* ServidorEjemploImpl.java */
public static void main(String args[])
{
try
{
//Crea un nuevo gestor de seguridad y lo instala
System.setSecurityManager(new RMISecurityManager());

// crea una instancia local del objeto


ServidorEjemploImpl servidor = new ServidorEjemploImpl();

// registra el objeto creado en la utilidad de registro


Naming.rebind("SERVIDOR-EJEMPLO", servidor);

System.out.println("Servidor a la espera .....");


}
catch (java.net.MalformedURLException me) {
System.out.println("URL incorrecta: " + me.toString()); }
catch (RemoteException re) {
System.out.println("Excepción remota: " + re.toString()); }
}

Sistemas Distribuidos:: Java RMI EUI-SG/INFOR.UVA.ES 3


• Implementar los métodos remotos
/* ServidorEjemploImpl.java */
public int sum(int a,int b) throws RemoteException
{
return a + b;
}
}

Paso 3. Desarrollo del cliente


• Para que el objeto cliente pueda invocar los métodos del servidor, el cliente debe
buscar primero el nombre del servidor en el registro. Para ello se utiliza también
la clase java.rmi.Naming.
• El nombre del servidor se especifica mediante una URL de la forma:
rmi://host:puerto/nombre
• El puerto por defecto que asigna Java RMI es el 1099.
• El nombre debe coincidir exactamente con el nombre lógico que utilice el servidor
en el registro del objeto, en el ejemplo, el nombre es “SERVIDOR-EJEMPLO”.
• Para obtener una referencia del objeto remoto es necesario hacer un casting
(conversión explícita de tipos) a la interfaz remota definida en la invocación al
método lookup() de la clase java.rmi.Naming. Por lo tanto es necesario, para
poder construir el cliente, disponer de la interfaz remota compilada en local (en el
ejemplo, el archivo ServidorEjemplo.class).
• La invocación al método remoto se hace como si fuera en local, pero utilizando la
referencia del objeto remoto.
import java.rmi.*;
import java.rmi.server.*;

public class EjemploCliente


{
public static void main(String[] args)
{
// Crea y establece el gestor de seguridad RMI
System.setSecurityManager(new RMISecurityManager());

//get the remote object from the registry


try
{
System.out.println("Gestor de seguridad cargado ");
String url = "//localhost/SERVIDOR-EJEMPLO";

SampleServer objetoRemto = (EjemploServidor)Naming.lookup(url);


System.out.println("Obtenida referencia al objeto remoto");

System.out.println(" 1 + 2 = " + objetoRemoto.sum(1,2) );


}
catch (RemoteException exc) {
System.out.println("Excepción remota: " + exc.toString()); }
catch (java.net.MalformedURLException exc) {
System.out.println("URL incorrecta: " + exc.toString()); }
catch (java.rmi.NotBoundException exc) {
System.out.println("Servicio no registrado: " + exc.toString());
}

}
}

Sistemas Distribuidos:: Java RMI EUI-SG/INFOR.UVA.ES 4


Pasos 4 y 5. Compilación de los ficheros fuente de Java y Generación de los stubs del
cliente y de los skeletons del servidor
• Se supone que se está trabajando con la máquina infodep03 y se tienen los
fuentes en el directorio /home/fdiaz/rmi
• JavaRMI proporciona el compilador rmic que toma como entrada el .class
generado a partir de la implementación de la interfaz remota, y genera el código
de los stubs y del skeleton.

infodep03:/home/fdiaz/rmi> javac ServidorEjemplo.java


infodep03:/home/fdiaz/rmi> javac ServidorEjemploImpl.java
infodep03:/home/fdiaz/rmi> rmic ServidorEjemploImpl

infodep03:/home/fdiaz/rmi> javac ClienteEjemplo.java

Paso 6. Inicio del registro RMI


• Las aplicaciones RMI necesitan instalar un registro (binder). El registro de Java
RMI se puede iniciar manualmente mediante la orden rmiregisty.
• Por defecto, el binder rmiregistry utiliza el puerto 1099. Se puede especificar
un nuevo puerto sin más que hacerlo constar a la hora en que se lanza el registro,
mediante la orden rmiregistry <nuevo_puerto>

infodep03:/home/fdiaz/rmi> rmiregistry

nota: En Windows, se puede teclear la siguiente orden para iniciar el registro:


> start rmiregistry

Pasos 7 y 8. Inicio de los objetos servidores remotos y Ejecución del cliente


• Una vez que el registro (binder) es iniciado, el servidor puede ser lanzado. Es
necesario lanzar antes el registro, para que el servidor pueda registrar el objeto
remoto.
• Derivado del modelo de seguridad granular en Java 2.0, se debe definir una
política de seguridad para Java RMI mediante el establecimiento de la propiedad
java.security.policy a un fichero específico, por ejemplo, mijava.policy.

infodep03:/home/fdiaz/rmi> java –Djava.security.policy=mijava.policy ServidorEjemploImpl


infodep03:/home/fdiaz/rmi> java –Djava.security.policy=mijava.policy ClienteEjemplo

nota: Políticas de Seguridad en Java 2

En Java 2, una aplicación Java debe obtener primero, antes de ejecutarse, información
acerca de sus privilegios o permisos para acceder a los recursos del sistema. Estos permisos se
definen en Java mediante la definición de una política de seguridad y una aplicación puede
obtener una política a través de un fichero “.policy”. En el ejemplo visto, se da, tanto al servidor
como al cliente, todos los permisos ya que se utilice la política de seguridad definida en el
archivo “mijava.policy” que contiene una única regla:

Sistemas Distribuidos:: Java RMI EUI-SG/INFOR.UVA.ES 5


grant {
permission java.security.AllPermission;
};

La política de seguridad puede ser más restrictiva, como se pone de manifiesto en el siguiente
“java.policy” que incluye las siguientes reglas:

grant {
permission java.io.filePermission “/tmp/*”, “read”, “write”;
permission java.net.SocketPermission “host.dominio.com:999”,”connect”;
permission java.net.SocketPermission “*:1024-65535”,”connect,request”;
permission java.net.SocketPermission “*:80”,”connect”;
};

1. permite a cualquier aplicación Java, leer/escribir cualquier fichero que esté en el


directorio /tmp (incluidos subdirectorios).
2. se permite a todas las clases Java establecer una conexión de red con la máquina
“host.dominio.com” a través del puerto 999.
3. se permite a todas la clases permiso para conectarse o aceptar conexiones a través de
puertos no privilegiados mayores que 10024 (puertos 1024-65535) y desde o hacia
cualquier host (carácter comodín *).
4. ser permite a todas las clases que se ejecutan en la JVM local conectarse al puerto 80 de
cualquier otra máquina (conexiones http).

Más información sobre el modelo de seguridad en Java:


http://www.programacion.net/java/tutorial/security1dot2/1/
http://www.uv.es/~sto/cursos/seguridad.java/html/sjava.html

Sistemas Distribuidos:: Java RMI EUI-SG/INFOR.UVA.ES 6


Sistemas Distribuidos:: Java RMI EUI-SG/INFOR.UVA.ES 7

También podría gustarte