Este documento describe el uso de RMI (Remote Method Invocation) para implementar un sistema distribuido de bibliotecas en Java. RMI permite invocar métodos de objetos remotos de forma sencilla. Se explican los conceptos clave de RMI como stubs, skeletons y capas de arquitectura. También se mencionan las clases, métodos y herramientas de Java necesarias para usar RMI como rmiregistry.

1. Programación orientada a objetos Sistemas distribuidos

2. Introducción Para aplicar el sistema de la Biblioteca como un sistema distribuido, se utilizaría el mecanismo de programación RMI (RemoteMethodInvocation) ya que es un simple pero potente framework basado en Java para diseñar objetos distribuidos, los cuales pueden desarrollarse rápidamente y administrarse a través de la red. El sistema Biblioteca es programado en Java con la IDE Eclipse Europa, y por lo tanto el RMI sería el adecuado.

3. RMI RemoteMethodInvocation

4. Definición Es un mecanismo ofrecido por Java para invocar un método de manera remota. Forma parte del entorno estándar de ejecución de Java y provee de un mecanismo simple para la comunicación de servidores en aplicaciones distribuidas basadas exclusivamente en Java.

5. RMI se caracteriza por la facilidad de su uso en la programación por estar específicamente diseñado para Java; proporciona paso de objetos por referencia (no permitido por SOAP), recolección de basura distribuida (GarbageCollector distribuido) y paso de tipos arbitrarios (funcionalidad no provista por CORBA). Por medio de RMI, un programa Java puede exportar un objeto, lo que significa que éste queda accesible a través de la red y el programa permanece a la espera de peticiones en un puerto TCP. A partir de este momento, un cliente puede conectarse e invocar los métodos proporcionados por el objeto.

6. La invocación se compone de los siguientes pasos: Encapsulado (marshalling) de los parámetros (utilizando la funcionalidad de serialización de Java). Invocación del método (del cliente sobre el servidor). El invocador se queda esperando una respuesta. Al terminar la ejecución, el servidor serializa el valor de retorno (si lo hay) y lo envía al cliente. El código cliente recibe la respuesta y continúa como si la invocación hubiera sido local.

7. La arquitectura RMI

8. La definición de un servicio remoto se hace usando una interfaz de JAVA . La implementación se codifica en una clase. Programa Servidor Programa Cliente Interfaz Implementación Sistema RMI

9. Elementos Toda aplicación RMI normalmente se descompone en 2 partes: Un servidor, que crea algunos objetos remotos, crea referencias para hacerlos accesibles, y espera a que el cliente los invoque. Un cliente, que obtiene una referencia a objetos remotos en el servidor, y los invoca. Cliente Servidor Result = Obj.method1(val1) DefObj { int method1(int v) { } string method2(string v) { } int method3(int v) { } int method4(int v) { } }

10. RMI soporta 2 clases que implementan la misma interfaz. La primera implementa el servicio y se ejecuta en el servidor. La segunda actúa como un proxy para el servicio remoto y se ejecuta en el cliente. << Interface >> Service Cliente Servidor Service Proxy Service Implementation RMI

11. Niveles de arquitectura Client Server Application Skeletons Stubs Remote Reference Layer RMI System Transport

12. APLICACIÓN La capa de la aplicación está situada en el nivel superior del sistema RMI. Una invocación remota de un cliente a un servidor de objetos remotos viaja a través de las capas del sistema RMI.

13. STUB - SKELETON Esta capa es la que interactúa directamente con la capa de aplicación. Todas las llamadas a objetos remotos y acciones junto con sus parámetros y retorno de objetos tienen lugar en esta capa.

14. Un stub es responsable de: Inicializar la llamada al objeto remoto. Hacer el marshaling de argumentos a un marshalstream, obtenido de la capa de referencia remota. Informa a la capa de referencia remota que debe invocarse la llamada. Hacer unmarshaling al valor de retorno o excepción desde un marshalstream. Informar al nivel de referencia remota que la llamada está completa. Un skeleton es responsable de: Hacer unmarshaling a los argumentos desde el marshalstream. Hacer la llamada a la implementacion del objeto remoto. Hacer marshaling al valor de retorno de la llamada o una excepcion sobre el marshalstream.

15. REFERENCIA REMOTA Es responsable del manejo de la parte semántica de las invocaciones remotas. También es responsable de la gestión de la replicación de objetos y realización de tareas específicas de la implementación con los objetos remotos, como el establecimiento de las persistencias semánticas y estrategias adecuadas para la recuperación de conexiones perdidas.

16. TRANSPORTE Responsable de: Establecer conexiones a JVM remotas. Administrar las conexiones. Escuchar las llamadas entrantes. Mantener una tabla de objetos remotos que residen en la JVM. Establecer una conexión para una llamada entrante. Localizar el despachador del objetivo de la llamada remota y pasar la conexión a este despachador.

17. Proceso:

18. Clases, métodos y aplicaciónes a utilizar java.rmi.Naming Esta clase contiene los métodos estáticos que permiten el acceso a objetos remotos utilizando un URL para especificar el nombre y lugar del objeto remoto. java.rmi.Remote De esta clase se deben de heredar las clases a utilizar para indicar que puede llamarse desde cualquier máquina virtual Java. java.rmi.RemoteException Todos los métodos deben de lanzar esta excepción en su cláusula throws, además de las excepciones que pueda manejar. rmiredistry Es una aplicación del servidor que se utiliza para registrar un nombre y un lugar de un objeto remoto. Esto se realiza a partir de un servidor que contiene un objeto remoto.

19. Ventajas y Desventajas De usar el RMI

20. Ventajas de RMI Hace parte del estándar del lenguaje Java. Aprovecha las ventajas del lenguaje Java. Los detalles de comunicación son transparentes para el programador. Permite el desarrollo rápido y fácil de objetos distribuidos. Es una plataforma amigable para empezar en el área de aplicaciones distribuidas. Desventajas de RMI No permite la fácil integración con sistemas heredados. No es rápido. Java RMI no es ampliamente aceptado, no es interoperable.