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

Call(parameters)

Receive results

RPC ServerRPC Client

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

Cliente usa la interfaz para complilar

Servidor la implementa

RPC Server

RPC ClientInterface definition file

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

RemoteObjectServerInvoca método

Recibe resultado

Archivos necesarios

• Obtiene una referencia al objeto remoto

• aplica el método y• recibe resultados

como si estuviese localizado localmente

Client program Server program

• 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

Define los métodos (sólo el encabezado)que podrán ser invocados remotamente

implementaUsa para la compilación

interface

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

Definición de la clase para el objeto remoto

Remote Interface

RemoteObject

Implementa

Remote

Extiende

Extiende

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

Client Remote Object Server

rmiregistry

¿ 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

DateClient.classRemoteDate.classDateServer_stub.class

DateServer.class RemoteDate.classDateServer_stub.classDateServer_skel.class

Generando stub & skel• El archivo class de la implementación del objeto debe ser

compilado nuevamente con el comando rmic

DateClient.javaRemoteDate.java

DateClient.class

DateServer.class

DateServer_stub.classDateServer_skel.class

DateServer.java

RemoteDate.classjavac

javacjavac

rmic

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

ClientClient Client

getNumber()

getNumber()getNumber()

1 2 3

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

Remote Object Server

addClient(this)

sendMessage(text)

newMessage(text)

Un servidor de archivos remoto

Access to files

Client

-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

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 archivojava –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 SetupJava -Djava.security.policy=policy.txt – Djava.rmi.server.codebase=http://hostname:port/ Setup

• correr el clienteJava -Djava.security.policy=policy.txt

– Djava.rmi.server.codebase=http://hostname:port/ client