RMI = Remote Method Invocation
Una aplicación RMI distribuida consta de dos componentes:
-
RMI Server (Servidor)
-
RMI Client (Cliente)
El RMI server es el que contiene los métodos que son invocados remotamente. El server crea varios objetos y referencia a estos objetos en el registro del RMI.
El registro del RMI es un servicio que corre del lado del RMI server. Los objetos que son creados remotamente por el servidor son registrados por objetos con nombre únicos en este registro.
Entonces el cliente obtiene la referencia de uno o más objetos que han sido creados remotamente del registro del RMI, luego el cliente invoca los métodos de los objetos remotos para acceder a estos servicios.
Una vez el cliente obtiene la referencia del objeto remoto, el método en el objeto remoto es invocado como si fueran locales, en realidad no se puede diferencia si los objetos son accedidos remota o localmente en los objetos del cliente.
Mis Comentarios: En este punto de la lectura, lo único que se me viene a la mente es un webservices, como los de .Net, solo que de manera más complicada, pero hay que recordar que los webservices de .Net quedaron en países desarrollados por decirlo así obsoletos, es por eso que salió WCF, que viene a implementar mucha mas funcionalidad a los webservices de .Net, entonces podría suponer que debido a que en java todo sale antes, utilizando esta manera de acceder a los objetos podríamos tener un mejor control sobre nuestra aplicación mejor o similar (apuesto a que mejor) a la obtenida con WCF en .Net
La Arquitectura del RMI
La arquitectura RMI consiste de tres capas:
-
La capa Stub (Cliente) /Skeleton (Server)
-
La capa de RRL (Remote Reference Layer)
-
La capa de Transport
La capa de Stub/Skeleton
Esta capa es la que escucha los métodos llamados remotamente hechos por el cliente y re direcciona estas llamadas a los servicios del RMI en el servidor, esta capa consiste de un stub y del skeleton.
Para invocar a los métodos de los objetos remotos, el request (pedido) en el lado del cliente empieza en el stub.
El stub es proxy del cliente que representa el objeto remoto.
Este es referenciado por el programa como si fuera cualquier otro método local que está corriendo.
El stub comunica el método al objeto remoto a través del skeleton que es implementado en el servidor.
El skeleton es el proxy del lado del servidor que continua la comunicación con el stub:
-
Lee los parámetros para el método llamado.
-
Hace una llamada al servicio remoto.
-
Acepta el valor que retorna
-
Escribe el valor retornado de regreso al stub.
La capa RRL(Remote Reference layer)
La capa RRL es la que interpreta y maneja las referencias hechas por el cliente al objeto remoto en el servidor. Esta capa está presente en el lado del cliente, así como en la del servidor.
La RRL en el lado del cliente recibe un request para los métodos del stub que son transferidos encriptados como una cadena de datos del RRL hacia el lado del servidor. Los datos son transferidos a través de la red. La capa RRL del lado del servidor desencripta los parámetros que son enviados remotamente a través del skeleton, esto lo hace para que estén en el formato para que pueda entenderlo el skeleton.
Mientras retorna el valor del skeleton, la data es de nuevo encriptado y comunicada hacia el cliente a través de la capa RRD del lado del servidor.
La capa Transport (Transporte)
La capa de transport es un enlace entre el RRL de el lado del servidor hacia el RRL de lado del cliente. La capa de transport es responsable de crear una nueva conexión y manejar las conexiones existentes.
También es responsable de manejar los objetos remotos que residen en el espacio de la capa de transport.
Los siguientes pasos explican como el cliente es conectado hacia el servidor:
-
Una vez recibido el request del RRL del lado del cliente, la capa de transport establece un socket de conexión al servidor a través del RRL del lado del servidor.
-
Entonces, la capa transport pasa la conexión establecida hacia el RRL del lado del cliente y añade u referencia remota a la conexión en esta tabla.
juliopari
Si te ha interesado este artículo y deseas un apoyo o asesoría en algún requerimiento, envíame un mensaje a: (info@juliopari.com) o sino a través de Linkedin: https://www.linkedin.com/in/juliopari/