Cambiando la manera de disear aplicaciones distribuidas Diseo

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, . . ) • e. Xternal 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 Remote. Object. Server

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á get. Date(), que entregará como resultado la fecha del computador donde está ubicado Remote Server get. Date() Tue Jun 12 17: 20: 24

El archivo de interfaz import java. rmi. *; import java. util. Date; public interface Remote. Date extends Remote { public Date get. Date() throws Remote. Exception; } • Debe importar java. rmi. * • debe extender la clase Remote • cada método declarado debe lanzar una excepción Remote. Exception

Definiendo una clase para implementar objetos remotos Remote Extiende Remote. Object Remote Interface Implementa Extiende Definición de la clase para el objeto remoto Date. Server. java

El programa cliente import java. rmi. *; import java. rmi. server. *; import java. util. Date; public class Date. Client { public static void main( String args[] ) { try { Remote. Date dateobj = (Remote. Date)Naming. lookup( "rmi: //"+args[0]+"/Date. Server" ); Date datum = dateobj. get. Date(); 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 Date. Client. class Remote. Date. class Date. Server_stub. class Remote Object Server Date. Server. class Remote. Date. class Date. Server_stub. class Date. Server_skel. class

Generando stub & skel • El archivo class de la implementación del objeto debe ser compilado nuevamente con el comando rmic Remote. Date. java Date. Server. java Date. Client. javac Date. Client. class Remote. Date. class Date. Server. class rmic Date. Server_skel. class Date. Server_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 get. Number() 1 get. Number() Client 3 2 Client get. Number() 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 add. Client(this) Remote Object Client send. Message(text) new. Message(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 Client. Program • Ver ejemplos Pide. Numero Reparte. Numeros

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 • Class. File. Server (extends Class. Server) • pasos : – Bajar RFSClient. cass, RFSInterface. class, policy. txt – Echar a correr el servidor de clases con el comando Class. File. Server 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 Remote. Unicast. Object import java. rmi. activation. *; public class My. Remote. Class extends Activable implement My. Interface • Reemplazar el constructor por otro que recibe 2 parámetros: public My. Remote. Class(Activation. ID id, Marshalled. Object data) throws Remote. Exception { super(id, 0); } • compilar con javac y rmic • Escribir y copilar el programa setup

Pasos para correrlo • Partir el Class. File. Server y rmiregistry • Partir el 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