Download Cap7-imp

Cambiando la manera de diseñar
aplicaciones distribuidas
• Diseño orientado a las comunicaciones: Primero se
diseña el protocolo de las comunicaciones y luego se
desarrolla el sistema de acuerdo a él
• Diseño orientado a ala aplicación: Se diseña y
desarrolla la aplicación como si todo estuviera local y
luego se divide la aplicación en módulos que correrán
en distintas máquinas
• La primera estrategia implica más complicación en el
diseño y la programación pero usa menos recursos
• El segundo es mejor cuando las comunicacioes son
complicadas al punto de hacer difícil el programa
Technologías Alternativas
• Desarrollo de redes => desarrollo de
sistemas distribuidos
• Desarrollo de middleware (bibliotecas,
herramientas, servicios, etc..) que apoyan la
programación de sistemas distribuidos
• Basados en protocolos TCP/IP
• Resultan en un lenguaje de programación de
más alto nivel
• El problema de la aplicación distribuida no
es un caso particular
Remote Procedure Calls (RPC)
• Motivatción: desarrollo del NFS (SUN)
• Un cliente puede llamar a una función en la
aplicación corriendo en un servidor como si
estuviera localmente implementada
• Pasa los parámetros y recibe los resultados
en un formato apropiado (integer, string,
float,..)
• eXternal Data Representation
• Serialización
Remote Procedure Calls
• El cliente detiene su ejecución hasta que la
lamada retorna
RPC Client
RPC Server
Call(parameters)
Receive results
Server framework: provisto por el middleware
El archivo de interfaz
• Especifica el protocolo de la función remota: nombre,
parámetros requeridos (cuantos y de que tipo),
resultado (tipo).
• Se llama archivo de interfaz ya que el cliente obtiene
de él la información que necesita
RPC Client
Interface definition file
Cliente usa la
interfaz para
complilar
RPC Server
Servidor la
implementa
Objetos Remotos
• Reemplazó rápidamente al paradigma anterior
• Una aplicación puede invocar un método de un
objeto ubicado en otra JVM
• El archivo de interfaz permanece como el
concepto clave en la implementación
Invoca método
Recibe resultado
RemoteObjectServer
Archivos necesarios
interface
Define los métodos (sólo el encabezado)
que podrán ser invocados remotamente
Usa para la compilación
•
•
•
Obtiene una
referencia al
objeto remoto
aplica el método y
recibe resultados
como si estuviese
localizado
localmente
Client program
implementa
•
•
•
Define una clase particular para
implementar los métodos
especificados en la interfaz
Crea el objeto remoto a parti de
esta clase
lo publica en algún servicio de
registro para que pueda ser
localizado por los clientes
Server program
Ejemplo: Remote Date Server
• El único método que tendrá el objeto Date será
getDate(), que entregará como resultado la fecha
del computador donde está ubicado
Remote Server
getDate()
getDate()
Tue Jun 12 17:20:24
El archivo de interfaz
import java.rmi.*;
import java.util.Date;
public interface RemoteDate extends Remote {
public Date getDate() throws RemoteException;
}
• Debe importar java.rmi.*
• debe extender la clase Remote
• cada método declarado debe lanzar una excepción
RemoteException
Definiendo una clase para
implementar objetos remotos
Remote
Extiende
RemoteObject
Remote Interface
Implementa
Extiende
Definición de la clase
para el objeto remoto
DateServer.java
El programa cliente
import java.rmi.*;
import java.rmi.server.*;
import java.util.Date;
public class DateClient {
public static void main( String args[] ) {
try {
RemoteDate dateobj = (RemoteDate)Naming.lookup(
"rmi://"+args[0]+"/DateServer" );
Date datum = dateobj.getDate();
System.out.println( “Server Date : " + datum );
}
catch ( Exception e ){ System.out.println(e); }
}
}
Los archivos Stub y Skel
• Las comunicaciones son implementadas por los
archivos stub y skel
• son generados al compilar los archivos class con el
comando rmic
Client
Stub
Remote Object
Server
Skel
El name registry server
• Un servidor para registrar y hacer públicos los
objetos remotos
• El servidor del objeto remoto registra el objeto en
él y los clientes obtienen una referencia al objeto
• Debe correr en el host servidor y tener acceso a los
archivos stub y skel.
• Debe ser levantado antes de registrar el objeto
rmiregistry
Client
Remote Object
Server
¿ Qué archivo dónde ?
• El cliente necesita el archivo de interfaz y el stub
• El servidor necesita el Stub y el Skel
Client
DateClient.class
RemoteDate.class
DateServer_stub.class
Remote Object
Server
DateServer.class RemoteDate.class
DateServer_stub.class
DateServer_skel.class
Generando stub & skel
• El archivo class de la implementación del objeto
debe ser compilado nuevamente con el comando
rmic
RemoteDate.java
DateServer.java
DateClient.java
javac
javac
javac
RemoteDate.class
DateServer.class
rmic
DateClient.class
DateServer_skel.class
DateServer_stub.class
Levantando el rmiregistry desde
el programa
• Es posible levantarlo desde dentro de un programa
invocando un método de java
• El siguiente ejemplo también va a mostrar
problemas de concurrencia
Remote Number
Server
getNumber()
1
getNumber()
Client
3
2
Client
getNumber()
Client
El chat basado en RMI
• El cliente debe recibir mensajes del servidor
• El cliente implementa un objeto remoto que lo
pasa como parámetro al servidos !!!
• The server does not need to locate the client
addClient(this)
Remote
Object Client
sendMessage(text)
newMessage(text)
Remote Object
Server
Un servidor de archivos remoto
Access to files
-open file read/write
-close file
-Read line
-Write line
Client
Qué pasa si:
- se le pide abrir un
archivo que no existe
- se le pide leer de un
archivo no abierto
- se generan otros errores
Distribución Automática (stub)
• El stud puede ser distribuido automáticamente
pero se necesita agregar un controlador de
seguridad
• Para esto se necesita escribir un archivo de
“politica de seguridad” secutiry policy
• Cuando se echa andar el servidor se debe
especificar una URL para decir de dónde se debe
recuperar el archivo
java –Djava.security.policy=policy.txt
-Djava.rmi.server.codebase=http://hostname/filelocation
ClientProgram
• Ver ejemplos PideNumero ReparteNumeros
Distribución automática del stub
• La recuperación del stub se hace via protocolo
URL
• Un “web-server” debe estar corriendo
• Se puede usar un pequeño servidor de clases
• ClassFileServer (extends ClassServer)
• pasos :
– Bajar RFSClient.cass, RFSInterface.class, policy.txt
– Echar a correr el servidor de clases con el comando
ClassFileServer port path
– Echar a correr el servidor de objetos remoto
– El cliente contacta al servidor (con parámetros policy y
codebase
Activación automática del
servidor de objetos
• A veces no es conveniente tener corriendo muchos
objetos servidores a la vez, sólo cuando se necesitan
• RMI provee un esquema para activar objetos
• Solo un servidor corre siempre “server” (el
rmideamon), que va a despertar al objeto cuando sea
necesario (llamada de un cliente)
• Es necesario escribir y correr un programa “set-up”
que va a registrar el servidor de objetos dormido
con el rmid que lo despertará
• Para el cliente no hay diferencia
Pasos para escribir un servidor
activable
• Reescribir el servidor para que extienda una clase “activable” en
vez de la RemoteUnicastObject
import java.rmi.activation.*;
public class MyRemoteClass extends Activable implement
MyInterface
• Reemplazar el constructor por otro que recibe 2 parámetros:
public MyRemoteClass(ActivationID id, MarshalledObject data)
throws RemoteException {
super(id, 0);
}
• compilar con javac y rmic
• Escribir y copilar el programa setup
Pasos para correrlo
• Partir el ClassFileServer y rmiregistry
• Partir el rmid
rmid –J-Djava.security.policy=policy.txt
• correr el programa Setup
Java -Djava.security.policy=policy.txt
– Djava.rmi.server.codebase=http://hostname:port/ Setup
• correr el cliente
Java -Djava.security.policy=policy.txt
– Djava.rmi.server.codebase=http://hostname:port/ client