RMI (Remote Method Invocation)

1. INTRODUCCIN
En la actualidad los sistemas distribuidos tienen una buena
aceptacin por parte de los desarrolladores java de aplicaciones tanto como
escritorio como para aplicaciones web, RMI es una de las primeras
tecnologas en donde se hace una interaccin Cliente - Servidor pero adems
de eso es posible tener mltiples aplicaciones que solamente puedan ser
accedidas desde mtodos remotos, en este informe se detallar parte de lo
que se refiere a Java RMI.
2. DEFINICIN
RMI es una de las tecnologas java que permite crear sistemas
distribuidos completos utilizando la interaccin cliente-servidor. Liu, M.
(2004), sostiene que RMI es una implementacin orientada a objetos del
modelo de llamada a procedimientos remotos. Se trata de una API exclusiva
para programas Java.
La definicin anterior se complementa con lo que sostiene
Groussard, T. (2012) sobre RMI, permite a los objetos Java comunicarse
entre ellos tanto si se en diferentes mquinas virtuales Java como si lo
hacen en diferentes mquinas fsicas
Segn Rosique, M. (2003) las particularidades destacables de
RMI son:

Permite abstraer las interfaces de comunicacin a

llamadas locales.

Permite trabajar sin protocolos

Es flexible y extensible

Permite disponer de objetos distribuidos utilizando java

Un objeto distribuido se ejecuta en una JVM remota.

Las aplicaciones RMI normalmente comprenden dos programas

separados: un servidor y un cliente, que necesitan de un tercero, el registro

de objetos.
Segn Rosique, M. (2003), las caractersticas de cada programa
son:
En el programa servidor:

Crea objetos remoto servidores

Crea referencia al objeto remoto

Espera a que un cliente invoque un mtodo del objeto

remoto
En el programa cliente:

Obtiene referencia a un objeto remoto en el servidor

Invoca un mtodo del objeto remoto del servidor (peticin

de servicio)
Groussard, T. (2012) otorga una definicin exacta para comprender

mejor cmo funcionan las aplicaciones RMI en java, En RMI, un servidor

de objeto exporta un objeto remoto y lo registra en un servicio de
directorios. El objeto proporciona mtodos remotos, que pueden invocar los
programas clientes. Sintcticamente, un objeto remoto se declara como una
interfaz remota una extensin de la interfaz Java. El servidor de objeto
implementa la interfaz remota. Un cliente de objeto accede al objeto
mediante la invocacin de sus mtodos, utilizando una sintaxis similar a las
invocaciones de los mtodos locales.

3. ARQUITECTURA RMI
3.1.

Componentes de una aplicacin RMI

Los componentes bsicos de una aplicacin RMI, son
cliente, servidor, objetos remotos segn sostiene, Sznajdleder, P.
(2013) una aplicacin RMI se compone de tres partes: el cliente, el
servidor y los objetos remotos agregando una definicin para cada
componente El servidor es el programa que instancia los objetos
remotos y los hace accesibles al cliente publicndolos en un
repositorio de objetos: el rmiregistry.
El cliente es el programa que, luego de realizar una
bsqueda en el repositorio, obtiene una referencia al objeto remoto y
le invoca sus mtodos.
Los objetos remotos son los objetos publicados por el
server a los que el cliente podr acceder remotamente.

Servicio de directorios
Objeto de cliente
Proporciona la interfaz
con el programa de la
aplicacin
Proyecta la capa independiente de la
plataforma en la capa dependiente;
implementa
protocolos
de
referencia remota

Resguardo

Esqueleto

Capa de referencia
remota

Capa de referencia
remota

Capa de transporte

Capa de transporte

Configura, mantiene y elimina

las conexiones; implementa el
protocolo de transporte

Ruta de datos lgica

Ruta de datos fsica
Figura1: Arquitectura Java RMI
Fuente: Groussard, T. (2012)

Objeto de
servidor

3.2.

Arquitectura del Cliente de una aplicacin RMI

Segn Groussard, T. (2012) las capas que le pertenecen a la

parte del cliente en una aplicacin RMI son las siguientes:

Capa resguardo o stub: sirve para interceptar las
invocaciones de los mtodos remotos hechas por los programas
clientes.
Capa de referencia remota: interpreta y gestiona las
referencias a los objetos de servicio remoto hechas por los clientes.
Capa de transporte: est basada en TCP y por tanto es
orientada a la conexin.
3.3.

Arquitectura del servidor de una aplicacin RMI

La parte Servidor de la arquitectura de una aplicacin RMI

est compuesta por tres capas de abstraccin segn Groussard, T.

(2012):
Capa esqueleto o skeleton: Se encarga de traducir las
invocaciones que provienen de la capa de referencia remota, as
corno de gestionar las respuestas (Ceballos, J. & Alies, M. &
Pinto, J. & Jabba, D. & Buenda, M., 2003, p.97)
Capa de referencia remota: Esta capa gestiona y
transforma la referencia remota originada por el cliente en una
referencia local, que es capaz de comprender la capa esqueleto.
Capa de transporte: Al igual que en la parte cliente, se
trata de una capa de transporte orientada a conexin, es decir, TCP
en la arquitectura de red TCP/IP.
3.4.

Comunicacin RMI
La comunicacin RMI es la manera de cmo interactan los

componentes: Cliente, Servidor, Objetos remotos, de acuerdo a

Rosique, M. (2003), estos componentes interaccionan de la siguiente

manera:
primero el servidor registra el objeto remoto en el registro
de nombres, el cliente obtiene una referencia del objeto registrado
por el servidor, el cliente enva una peticin al objeto remoto (que se
encuentra en el servidor o es el propio servidor), el objeto remoto
enva la respuesta al cliente y por ltimo el cliente recibe la
respuesta.

Figura1: Diagrama de comunicacin RMI

Fuente: Rosique, M. (2003)

4. CONFIGURACION DE LA APLICACIN VISTA EN CLASE

En una aplicacin RMI o aplicacin distribuida se necesitan de dos
aplicaciones una aplicacin servidor para nuestro caso se llamar
ProyectoRMIServidor, y una aplicacin Cliente que tendr como nombre
ProyectoRMICliente,

para

hacer

funcionar

estas

aplicaciones

correctamente primero se debe ejecutar la aplicacin servidor y luego la

aplicacin del lado cliente.

La aplicacin ProyectoRMIServidor est compuesta por

Una clase remota y una interfaz remota y una clase principal

llamada Servidor.
En la interface InterfazRemota se define el mtodo remoto el cual
debe ser pblico para que sea accedido desde cualquier aplicacin adems la
InterfazRemota debe extender de java.rmi.remote que indica que pueda ser
accedido desde otra mquina virtual de java,

la interfaz remota se

implementa en ClaseRemota donde tambin se implementa el mtodo

remoto.
En la clase Servidor tenemos:

Un mtodo iniciar() , pero lo ms importante es examinar a detalle

el cdigo :
Registry registry = LocateRegistry.createRegistry(4567);
En el cdigo anterior se crea un registro llamado registry, se asigna
el

puerto

que

tendr

el

servidor

con

el

mtodo

LocateRegistry.createRegistry
InterfazRemota obj = new ClaseRemota();
En el cdigo anterior se crea un objeto llamado obj pero en vez de
ser de la interface remota, este es creado de la clase remota.
registry.rebind("abc", obj);
En el cdigo anterior el mtodo registry.rebind asigna un
identificador en este caso llamado abc al objeto creado obj, este es
importante ya que el cliente podr acceder al objeto mediante el
identificador.
La aplicacin ProyectoRMICliente esta expresada de la siguiente
manera:

De acuerdo a la imagen anterior la aplicacin del lado cliente tiene

una clase principal llamada Cliente.java y una interfaz remota que es la
misma que en el servidor llamada InterfazRemota.java donde se define el
mtodo remoto.

En la clase cliente se encuentra lo siguiente:

Registry myRegistry = LocateRegistry.getRegistry("127.0.0.1",
4567);
En el cdigo anterior localizamos y obtenemos el registro con el
mtodo LocateRegistry.getRegistry(), que tiene como parmetros la
direccin IP y el puerto donde se aloja el servidor.
InterfazRemota

obj

=(InterfazRemota)myRegistry.lookup("abc");
Con el cdigo anterior estamos accediendo al objeto que se cre en
la clase remota del servidor llamando con su identificador en este caso el
que hace posible es el mtodo myRegistry.lookup() que tiene como
parmetro el identificador del objeto.
System.out.println(obj.metodoRemoto();
Con este cdigo imprimimos lo que est en el mtodo remoto

5. VENTAJAS Y DESVENTAJAS DE RMI

Segn Ceballos, J. & Alies, M. & Pinto, J. & Jabba, D. & Buenda,
M. (2003) las ventajas y desventajas que posee RMI son las siguientes
5.1.

Ventajas

Hace Parte del estndar del lenguaje Java

Aprovecha las ventajas del lenguaje Java

Los detalles de comunicacin son transparentes para el

programador

Permite el desarrollo rpido y fcil de objetos distribuidos

Es una plataforma amigable para empezar en el rea de

aplicaciones distribuidas.

La habilidad de descargar los bytecodes (o simplemente,

cdigo) de una clase de un objeto si la clase no est
definida en la mquina virtual del servidor.

5.2.

Desventajas

No permite la fcil integracin con sistemas heredados

No es rpido

Tiene algunas limitaciones debido a su estrecha integracin

con Java;

La principal de ellas es que esta tecnologa no permite la

interaccin con aplicaciones escritas en otro lenguaje.

6. CONCLUSIONES

RMI es una tecnologa que permite la creacin de grandes sistemas

distribuidos basados en Cliente Servidor.

Se tiene que tener una interfaz remota para acceder a los mtodos
remotos de esta, y se debe crear tanto en el cliente como en el
servidor pero es en el servidor donde se implementan los mtodos.

Es importante examinar cual es la estructura de una aplicacin

basada con tecnologa RMI para poder comprender sus principales
componentes.

7. BIBLIOGRAFA
Ceballos, J. & Alies, M. & Pinto, J. & Jabba, D. & Buenda, M.
(2003). Conectividad de Java con bases de datos
mediante

invocacin de objetos con mtodos remotos

(objetos RMI)

Ingeniera

diciembre, 2003, pp. 93-

106.

Desarrollo,
Universidad

nm.
del

14,
Norte

Barranquilla, Colombia.
Liu, M. (2004). Computacin Distribuida. Fundamentos y
Aplicaciones. Madrid: PEARSON.
Groussard, T. (2012).Java 7. Los fundamentos del lenguaje java.
Editorial: Eni.
Rosique, M. (2003). La Programacion distribuida de aplicaciones.
Universidad Politecnica de Cartagena- Colombia.
Sznajdleder, P. (2013). Java a fondo: estudio del lenguaje y
desarrollo de aplicaciones. Buenos Aires: AlfaOmega.