RMI

RMI(Metodo de Invocacion Remota)

Introducción

RMI por sus siglas en incgles(Remote Method Invocation), permite que una aplicación o applet se comunique con objetos que residen en programas que se ejecutan en máquinas remotas. En esencia, en lugar de crear un objeto, el programador liga el objeto remoto con un representante local, conocido como stub. Los mensajes dirigidos al objeto remoto se envían al stub local, como si fuera el objeto real. El stub acepta los mensajes que se le envíen, y a su vez, los envía al objeto remoto, el cual invoca sus métodos apropiados. El resultado de la invoación de los métodos en el objeto remoto se env´ıa de regreso al stub local, que los remite al emisor original de la llamada.

Desarrollo

RMI es un paquete de JAVA que permite manejar objetos (y sus respectivos metodos) de manera remota, para utilizar los recursos de un servidor de manera transparente para el usuario local. La manera en que RMI logra hacer esto, es por medio de lo que se conoce como stubs. En el caso del stub servidor, se conoce como skeleton. Estos Stubs y Skeletons permiten que al momento de ser invocada la función remota esta pueda ser "simulada localmente".Para la comunicación entre el servidor y el cliente, se trabaja con interfaces, que deben ser implementadas por el servidor y/o cliente, para que los stubs puedan realizar la transparencia para ambos. Además esto evita que deba existir una definición local real de la clase remota, vale decir, en el cliente solo debe estar definida la interface, no la clase remota. Otro punto importante en RMI, es el como se produce la conectividad entre el cliente y servidor. Para esto se ocupa una herramienta de JAVA, llamada RMI Registry. El RMI Registry puede estar localizado en un lugar distinto al servidor, y se encarga de registrar un determinado objeto y asignarle un servidor que se encargará de procesar dicho objeto. 

El flujo y funcionamiento general de RMI es el siguiente: 

1. Se ejecuta el RMI Registry, en algún lugar de la red.
2. El servidor que desea manejar un objeto, se registra en dicho servidor,
3. El RMI Registry registra el par: objeto/servidor
4. El cliente que necesita utilizar un determinado objeto, hace una consulta al RMI Registry, quien devuelve el STUB listo para la comunicación

El mecanismo RMI se compone de cuatro capas:   

1. La primera capa es la de aplicación y se corresponde con la implementación real de las aplicaciones cliente y servidor. Aquí tienen lugar las llamadas a alto nivel para acceder y exportar objetos remotos.
   Cualquier aplicación que quiera que sus métodos estén disponibles para su acceso por clientes remotos debe declarar dichos métodos en una interfaz que extienda java.rmi.Remote. Dicha interfaz se usa básicamente para "marcar" un objeto como remotamente accesible. Una vez que los métodos han sido implementados, el objeto debe ser exportado. Esto puede hacerse de forma implícita si el objeto extiende la clase UnicastRemoteObject, o puede hacerse de forma explícita con una llamada al método exportObject() del mismo paquete.
2. La capa 2 corresponde al proxy. 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.
3. La capa 3 es la de referencia remota, y 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.
   En esta capa se espera una conexión de tipo stream (stream-oriented connection) desde la capa de transporte.
4. Por ultimo tenemos la capa de transporte. Es la responsable de realizar las conexiones necesarias y manejo del transporte de los datos de una máquina a otra.

Conclusión

Como su mismo nombre lo señala, RMI tiene la finalidad de permitir la interaccion con objetos (en java) de manera remota utilizando una red, esto nos permite explotar al maximo la arquitectura para aplicaciones tipo cliente/servidor.
La posibilidad de separar el trabajo, encapsulandolo en aplicaciones cliente servidor, en donde el cliente y el servidor se desligan a tal grado que no deben saber nada sobre el trabajo del uno y del otro. Esto es sumamente util en los tiempos actuales en donde las aplicaciones cliente servidor son cada vez mas abundantes y la complejidad de ellas hace fundamental la separacion del codigo en modulos independientes.

Fuentes

• Coulouris George (2008). Sistemas Distribuidos. Madrid, España: Pearson.
• Ing. TURPO A. Einar (s.f)
  http://www.unap.edu.pe/cidiomas/licing/pdf/sd.pdf
• http://laurel.datsi.fi.upm.es/~ssoo/SD.dir/practicas/guiarmi.html
• http://www.tamps.cinvestav.mx/~vjsosa/clases/sd/DAAI_RMI.pdf