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 Server RPC 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 Client Interface 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 RemoteObjectServer Invoca 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 implementa Usa 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() 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 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.class RemoteDate.class DateServer_stub.class 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 DateClient.java RemoteDate.java DateClient.class DateServer.class DateServer_stub.class DateServer_skel.class DateServer.java RemoteDate.class javac 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 Client 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 archivo java –Djava.security.policy=policy.txt -Djava.rmi.server.codebase= 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= Setup correr el cliente Java -Djava.security.policy=policy.txt – Djava.rmi.server.codebase= client