Cambiando la manera de dise

1
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

2
Technologías Alternativas

• Desarrollo de redes gt 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

3
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

4
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
5
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
6
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

RemoteObjectServer
Invoca método
Recibe resultado
7
Archivos necesarios
interface
Define los métodos (sólo el encabezado) que
podrán ser invocados remotamente
Usa para la compilación
implementa

• Obtiene una referencia al objeto remoto
• aplica el método y
• recibe resultados como si estuviese localizado
  localmente

• 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
Client program
8
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 172024
9
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

10
Definiendo una clase para implementar objetos
remotos
Remote
RemoteObject
Remote Interface
Extiende
Implementa
Extiende
Definición de la clase para el objeto remoto
DateServer.java
11
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.look
  up(
• "rmi//"args0"/DateServer" )
• Date datum dateobj.getDate()
• System.out.println( Server Date "
  datum )
• catch ( Exception e ) System.out.println(e)
  

12
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

Remote Object Server
Client
Stub
Skel
13
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
14
Qué archivo dónde ?

• El cliente necesita el archivo de interfaz y el
  stub
• El servidor necesita el Stub y el Skel

Client
Remote Object Server
DateServer.class RemoteDate.class DateServer_stub
.class DateServer_skel.class
DateClient.class RemoteDate.class DateServer_stub.
class
15
Generando stub skel

• El archivo class de la implementación del objeto
  debe ser compilado nuevamente con el comando rmic

DateServer.java
RemoteDate.java
DateClient.java
javac
javac
DateServer.class
javac
RemoteDate.class
rmic
DateClient.class
DateServer_skel.class
DateServer_stub.class
16
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
3
2
getNumber()
getNumber()
Client
Client
Client
17
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

Remote Object Client
addClient(this)
Remote Object Server
sendMessage(text)
newMessage(text)
18
Un servidor de archivos remoto
Access to files

• open file read/write
• close file
• Read line
• Write line

• 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

Client
19
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.policypolicy.txt
• -Djava.rmi.server.codebasehttp//hostname/fileloc
  ation
• ClientProgram
• Ver ejemplos PideNumero ReparteNumeros

20
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

21
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

22
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

23
Pasos para correrlo

• Partir el ClassFileServer y rmiregistry
• Partir el rmid
• rmid J-Djava.security.policypolicy.txt
• correr el programa Setup
• Java -Djava.security.policypolicy.txt
• Djava.rmi.server.codebasehttp//hostnamep
  ort/ Setup
• correr el cliente
• Java -Djava.security.policypolicy.txt
• Djava.rmi.server.codebasehttp//hostnamep
  ort/ client