Visión General de Rmi: Servidorejemplo Objetoremoto Int S S Objetoremoto - Sum (1,2)
Visión General de Rmi: Servidorejemplo Objetoremoto Int S S Objetoremoto - Sum (1,2)
Visión General de Rmi: Servidorejemplo Objetoremoto Int S S Objetoremoto - Sum (1,2)
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
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.
invocación
Skeleton
Stub
Cliente RMI Servidor RMI
retorno
}
}
infodep03:/home/fdiaz/rmi> rmiregistry
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:
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”;
};