TEMA 4. Arquitectura de aplicaciones distribuidas

1. TEMA 4. Arquitectura de aplicaciones distribuidas Tecnologías orientadas al desarrollo de aplicaciones distribuidas. La invocación remota de métodos (RMI).

2. Bibliografía Qusay H. Mahmoud. Distributed Programming with Java. Capítulos 7 al 10. Sun. “Documentación de Java”. http://java.sun.com . Traducciones al castellano en http://www.programacion.com Liu M. “Computación distribuida”. Pearson(A.W). Capítulos 7 y 8.

3. 1 . Tecnologías orientadas al desarrollo de aplicaciones distribuidas Tipos de arquitecturas • Cliente/servidor de dos capas. • Cliente/servidor en tres capas. Añade un servidor intermedio entre el cliente y el servidor que se encarga, entre otras cosas: • de la traducción de servicios, • controlar los accesos al servidor y • enrutar las peticiones a distintos servidores en función de algunas características.

4. 1 . Tecnologías orientadas al desarrollo de aplicaciones distribuidas Objetos distribuidos • los objetos dinámicamente asumen el papel de clientes o servidores, según la necesidad. • Un objeto distribuido es un objeto que puede ser accedido remotamente desde cualquier lugar en la red, del mismo modo que se haría si estuviese en la misma máquina.

5. 1 . Tecnologías orientadas al desarrollo de aplicaciones distribuidas Objetos distribuidos • Los objetos distribuidos estarán "unidos" mediante algún mecanismo que permita saber a los clientes: • dónde se encuentran los servidores, • cómo acceder a ellos y • qué se les puede pedir. • Por ejemplo, una especie de gestionador de peticiones de objetos podría servirnos para esta tarea o bien algún tipo de registro general dinámico.

6. 1 . Tecnologías orientadas al desarrollo de aplicaciones distribuidas Objetos distribuidos • Este “pegamento” lógico es el que nos hace todo el sistema transparente. • Localiza los objetos en los sistemas remotos y transforma las peticiones para que se entiendan independientemente a la máquina sobre la que se están ejecutando o en el lenguaje en el que están escritos.

7. 1 . Tecnologías orientadas al desarrollo de aplicaciones distribuidas Objetos distribuidos • El concepto global de objetos distribuidos puede verse como una red global de clientes y servidores heterogéneos.

8. 1 . Tecnologías orientadas al desarrollo de aplicaciones distribuidas Ventajas de usar objetos distribuidos • Sirven para hacer más sencilla la reconstrucción de aplicaciones por partes sin tener que reinstalarla o recompilarla completamente. • Favorecen la escalabilidad y permiten el mejor uso de la potencia computacional de las máquinas repartiendo la ejecución de los objetos constituyentes entre ellas.

9. 1 . Tecnologías orientadas al desarrollo de aplicaciones distribuidas Ventajas de usar objetos distribuidos • Pueden facilitar la movilidad de los objetos entre las máquinas, aumentado considerablemente la disponibilidad y la eficiencia global de la aplicación. • Pueden servir para que las aplicaciones se construyan independientemente de la plataforma sobre la que se crearon. • Favorecen la compartición de datos entre aplicaciones y usuarios de forma inmediata, además de la sincronización de actividades a través de varias máquinas.

10. 1 . Tecnologías orientadas al desarrollo de aplicaciones distribuidas Tecnologías • El mecanismo más usado en el modelo procedural es la llamada a procedimiento remoto (Remote procedure call, RPC ) que es idéntico a una llamada a un procedimiento sólo que origen y destino son procesos distintos. • El inconveniente que presenta esta forma de trabajo es que para utilizarlo se debe hacer referencia a conceptos de bajo nivel que están en función del sistema operativo en el que se está programando. • Los RPCs son un estándar del DCE (Distributed Computed Environment), que fue creado por empresas como HP, IBM, Sun y DEC como un entorno para sistemas abiertos que nos ofrece un conjunto de servicios como son direccionamiento (naming), administración de tareas paralelas (thread management) y seguridad.

11. 1 . Tecnologías orientadas al desarrollo de aplicaciones distribuidas Tecnologías • Actualmente, algunas de las tendencias principales que se están utilizando dando soporte a la distribución de objetos son RMI de Sunsoft, CORBA del Object Management Group y DCOM (Distributed Component Object Model)de Microsoft.

12. 1 . Tecnologías orientadas al desarrollo de aplicaciones distribuidas Tecnologías • De estos tres mecanismos no hay ninguna respuesta única en cuanto a cual es el mejor. • Las tendencias actuales consisten en establecer conexiones entre ellos.

13. 2 . La invocación remota de métodos (RMI) Introducción • El Remote Method Invocation aparece como parte integrante del JDK (Java Development Kit) de Java a partir de la versión 1.1. • RMI permite la invocación de métodos de objetos Java que residen en otras máquinas. • Estas otras máquinas no tienen por que tener ni la misma arquitectura ni el mismo sistema operativo, sólo requieren tener su JVM (Java Virtual Machine) correspondiente.

14. 2 . La invocación remota de métodos (RMI) Introducción • RMI usa un protocolo nativo propio JRMP(Java Remote Method Protocol) que se sitúa sobre el protocolo de red (TCP/IP, por ejemplo) que hace que sólo se pueda hablar con otros objetos Java. • La principal diferencia de este mecanismo con respecto a los RPC es que el RMI forma parte integrante del lenguaje y no hay que hacer ninguna referencia explícita a ningún nivel subyacente del sistema sobre el que se va a ejecutar la aplicación.

15. 2 . La invocación remota de métodos (RMI) Introducción • Para el desarrollo de una aplicación distribuida, la solución planteada por Java y RMI (Remote Method Invocation) es más sencilla de llevar a cabo que cualquiera de las otras alternativas (CORBA o DCOM). • Carece de un soporte contrastado para múltiples lenguajes y no es tan robusto y escalable como los dos anteriores. • Lo que realmente hace interesante esta aproximación es la facilidad de desarrollo de aplicaciones distribuidas dentro del marco del lenguaje Java.

16. 2 . La invocación remota de métodos (RMI) Introducción • El uso de RMI, entre otras cosas, aporta: • Un recolector de basura distribuido, • mantiene los sistemas de seguridad de Java, • usa la posibilidad de crear hilos de ejecución (threads) concurrentes potenciando la idea concurrente en las aplicaciones distribuidas y • hace un uso inteligente de la Serialization de los objetos Java con la posibilidad de transportar objetos a través de la red sin necesidad de ningún esquema extra.

17. 2 . La invocación remota de métodos (RMI) Estrategia • El objetivo básico que se persigue es la posibilidad de enviar un mensaje a un objeto que reside en una máquina a partir de un método que se está ejecutando en otra máquina distinta.

18. Servicio directorios objeto Objeto servidor cliente Interfaz con el programa stub Implementa protocolos de ref. remota skeleton Capa ref. remota Capa de ref. remota Capa transporte Capa transporte Implementa protocolo transporte Ruta de datos lógica Ruta de datos física 2 . La invocación remota de métodos (RMI) Arquitectura RMI

19. método stub stub remoto tiempo Empaquetado parámetros Envía petición Desempaquetado: Invoca método executa codigo Recibe retorno empaqueta envía desempaqueta Retorna valor 2 . La invocación remota de métodos (RMI) Interacciones stub Llamada a método

20. 2 . La invocación remota de métodos (RMI) Ejemplo cliente/servidor • Para estudiar el mecanismo de RMI se plantea el siguiente ejercicio. • Diseñar un servidor remoto que informe sobre la hora, de forma que tenga un método obtenerHora que pueda ser consultado por cualquier cliente.

21. 2 . La invocación remota de métodos (RMI) Cliente y servidor import java.rmi.*; interface HoraExactaI extends Remote { long obtenerHora() throws RemoteException; }

22. 2 . La invocación remota de métodos (RMI) Servidor import java.rmi.*; import java.rmi.server.*; import java.rmi.registry.*; import java.net.*; public class HoraExacta extends UnicastRemoteObject implements HoraExactaI { // Implementación de la interface: public long obtenerHora() throws RemoteException { return System.currentTimeMillis(); } // Implementación del constructor para lanzar //RemoteException: public HoraExacta() throws RemoteException { super(); }

23. 2 . La invocación remota de métodos (RMI) Cliente • El cliente debe conocer la clase HoraExacta, pero sólo le interesan los métodos que puede invocar. • La solución que proporciona el lenguaje es mediante el uso de interfaces remotas, que presentan los métodos y no el código que estará en la máquina residente del servidor.

24. 2 . La invocación remota de métodos (RMI) • El problema reside en como el cliente crea una referencia a un objeto remoto y como el servidor hace accesibles los métodos de sus objetos remotos.

25. 2 . La invocación remota de métodos (RMI) Accesibilidad del objeto remoto (servidor) try { HoraExacta he = new HoraExacta(); Naming.bind("//canyella:2005/HoraExacta", he); System.out.println("Preparado..."); } catch(Exception e) {

26. 2 . La invocación remota de métodos (RMI) Arrancar el registro • En nuestro caso hay una llamada a Naming.bind(), que requiere que el registro esté ya ejecutándose como un proceso a parte en nuestro sistema. • El nombre del proceso que se encarga de hacer el registro es rmiregistry y en función del sistema en el que estemos lo arrancaremos como: • Start rmiregistry en Windows y • rmiregistry & en UNIX.

27. 2 . La invocación remota de métodos (RMI) Arrancar el registro • Si se registran objetos sin ningún parámetro, el registro escuchará en el puerto 1099. • La información del puerto se debe pasar al comando bind(), así como la dirección IP de la máquina sobre la que se ejecuta el registro. • El nombre del servicio es arbitrario, en nuestro caso coincide con el nombre de la clase pero no tiene porque ser así. Lo único importante es que sea único dentro del registro al que el cliente pregunta.

28. 2 . La invocación remota de métodos (RMI) Arrancar el registro • Si en un mismo registro tuviésemos dos servicios con el mismo nombre se lanzaría la excepción AlreadyBoundException. • Para prevenir esta posibilidad podemos usar rebind() en lugar de bind() ya que ésta añade o reemplaza el nuevo servicio en función de que ya exista.

29. 2 . La invocación remota de métodos (RMI) Arrancar el registro • Aunque se termine el main(), el objeto creado y registrado permanece vivo por el registro esperando por alguna petición de algún cliente a no ser que se llame a Naming.unbind().

30. 2 . La invocación remota de métodos (RMI) Arrancar el registro • El registro se puede reiniciar desde la aplicación haciendo uso de LocateRegistry.createRegistry(2005), en donde el 2005 es el puerto en el que escucha.

31. 2 . La invocación remota de métodos (RMI) Creación de stubs • Los stubs establecen de forma transparente las conexiones con la red y hacen que el objeto remoto se comporte como si fuese local. • Para crear los stubs usamos la herramienta rmic sobre el código compilado y creará los archivos necesarios. rmic HoraExacta

32. 2 . La invocación remota de métodos (RMI) Creación de stubs y skeletons • El resultado será una clase, que tendrá que tener el cliente y el servidor: • HoraExacta_Stub.class

33. 2 . La invocación remota de métodos (RMI) Usando el objeto remoto import java.rmi.*; public class MuestraHoraExacta { public static void main(String[] args) { try { HoraExactaI t = (HoraExactaI)Naming.lookup("//canyella:2005/HoraExacta"); for(int i = 0; i < 10; i++) System.out.println("Hora Exacta = " +t.obtenerHora()); } catch(Exception e) { }}