3.1.1.

Caractersticas y Estructura de RMI

En el modelo de objetos distribuidos de Java, un objeto distribuido es
aquel cuyos mtodos pueden llamarse desde otra Mquina Virtual Java
(JVM), que puede estar ejecutndose en otro host. Por lo tanto, un
objeto remoto ubicado en un proceso puede recibir llamadas desde
otros procesos que se estn ejecutando en diferentes espacios de
direcciones (es decir, en diferentes mquinas).
Una clase remota es cualquier clase cuyas instancias son objetos
remotos. Desde el punto de vista de la mquina virtual que crea
instancias de objetos remotos, stos son objetos ``normales''. Se podrn
usar como cualquier otro objeto.
Una llamada remota a mtodo es una llamada a un mtodo de un objeto
desde un espacio de direcciones donde ste no reside. Java permite
trabajar con objetos en ubicaciones remotas como si estuvieran en el
espacio de direcciones local, es decir, con la misma sintaxis que tiene
las llamadas locales. De esta forma se consigue una total transparencia
cara al programador.
Una caracterstica adicional del modelo de objetos remotos de Java es
la utilizacin de interfaces para la manipulacin de estos objetos.
Cuando un proceso actuando como cliente quiere instanciar un objeto,
que para l ser remoto, ubicado en un servidor; no instancia
directamente a ste, sino a un intefaz del mismo denominada interfaz
remota. Un cliente nicamente necesita una interfaz remota para poder
invocar los mtodos de un objeto remoto.
El uso de interfaces remotas proporciona una serie de ventajas, como
son: las implementaciones de los mtodos no son visibles por los
clientes y no hace falta comunicar a los clientes cambios realizados en
las implementaciones de los mtodos.
Es comn hablar de RMI como un middleware, en el sentido que se
comporta como un software que separa las comunicaciones entre
clientes y servidores de los protocolos de red y los mecanismos de
comunicacin entre procesos.[6] La figura 3.1 muestra este concepto.

Figura: Representacin lgica del middleware

Tpicamente, una aplicacin RMI est compuesta de un cliente y un

servidor. El servidor se encarga de crear los objetos remotos, hacerlos
accesibles y permanecer a la espera de llamadas para esos objetos
remotos. El cliente debe conseguir referencias para esos objetos
remotos y, en ese momento, puede hacer uso de ellas para realizar
llamadas remotas. Las aplicaciones con objetos distribuidos necesitan:

Localizar los objetos remotos.- Para ello pueden hacer uso de la

utilidad de bsqueda por nombres propia de RMI, rmiregistry.
Comunicar con los objetos remotos.- Los detalles de la
comunicacin entre objetos remotos quedan a cargo de RMI. Para
el programador, la invocacin remota de mtodos es como la
estndar.
Cargar el cdigo de las clases para los objetos remotos.- RMI
permite no slo el paso de objetos completos hacia y desde los
procesos remotos sino, adems, la descarga de las clases que
implementan dichos objetos desde ubicaciones remotas.

En la prctica, la comunicacin entre clientes y servidores no es

directa, siempre media entre ambos unos elementos suplentes que se
conocen como stub y skeleton.
Un stub acta como un proxy local de un objeto remoto. Debe
implementar las mismas interfaces remotas que implementa el objeto al
que representa.
Cuando un objeto local llama a un mtodo de la interfaz remota de un
objeto, esta llamada se realiza en realidad sobre los mtodos
del stub local, desde donde se transmite hasta el objeto remoto. Por lo
tanto, no hay comunicacin directa entre objetos locales y remotos sino
que se realiza a travs de los elementos suplentes. El stub se encarga
de realizar la conexin con la mquina virtual remota, enviar los
argumentos para el mtodo especificado, esperar la respuesta y
pasrsela al objeto local. El skeleton es la contrapartida del stub, es
decir, acta como proxy del objeto remoto en el lado servidor. Se
encarga de recibir las peticiones dirigidas al objeto servidor y devolver
los resultados a quien hizo la peticin. En las versiones actuales del JDK
(Java Development Kit) no es necesaria la utilizacin de los
elementos skeleton.

Figura: Relaciones entre elementos RMI

El stub constituye la referencia al objeto remoto que representa.

Evidentemente, no puede ser una referencia de memoria o un puntero,
ya que los objetos local y remoto se encuentran en espacios de memoria

diferentes. Al ser imposible la comunicacin directa entre objetos que

residen en mquinas virtuales diferentes, se necesitan suplentes que lo
permitan, y estos suplentes son el stub y skeleton. La referencia remota
contendr la direccin IP del servidor, un puerto, un identificador del
objeto remoto y una interfaz remota. Ambos, stub y skeleton, debern
implementar las interfaces remotas de los objetos a los que estn
asociados.
Tanto el stub como el skeleton utilizan el mecanismo de serializacin
para comunicarse con el objeto remoto. Mediante la serializacin, toda
la informacin que es necesaria intercambiar (objetos pasados como
argumentos, ubicacin de las clases de dichos objetos, etc.) es
intercambiada como un flujo de bytes.
RMI puede cargar dinmicamente nuevas clases basndose en la
informacin recibida por la red. Esta informacin tiene forma de URL,
puesto que hace referencia a recursos disponibles en distintas
mquinas. Con este mecanismo se pueden localizar, en ubicaciones
remotas, las clases necesarias para instanciar nuevos objetos en tiempo
de ejecucin.
Para poder cargar dinmicamente clases de mquinas remotas, RMI
obliga a crear e instalar un gestor de seguridad. ste protege los
accesos a los recursos del sistema por parte de cdigo ``no firmado''
que se ejecute dentro de la mquina virtual. El gestor de seguridad
determina si el cdigo descargado tiene acceso al sistema de ficheros
local o puede realizar cualquier otra operacin privilegiada.
Todos los programas que utilicen RMI deben instalar un gestor de
seguridad o RMI no descargar las clases (concretamente las que no se
encuentren en el path local) para los objetos que se reciban como
parmetros. Estas restricciones aseguran que las operaciones realizadas
por el cdigo descargado cumple ciertos requisitos de seguridad.
RMI proporciona un gestor de seguridad propio, RMISecurityManager.
Una aplicacin RMI tambin puede definir y utilizar otra
clase SecurityManager que permita un acceso menos restrictivo a los
recursos del sistema, o, a partir del JDK 1.2, utilizar un fichero de
privilegios que ofrezca permisos ms especficos. Estos ficheros suelen
nombrarse como java.policy y, para ser utilizados como gestores de
seguridad, se utiliza la
propiedad java.rmi.security.policy=security.policy (suponiendo que ese

es el nombre del archivo que especifica los permisos y que se encuentra

en el directorio actual).
La figura 3.3 muestra la operacin completa de una llamada RMI.

Figura: Comunicacin basada en RMI

Un objeto remoto en Java debe implementar la

interfaz java.rmi.Remote que acta como flag para que la mquina
virtual lo reconozca como tal. El paso de argumentos y los valores de
retorno que admiten los mtodos remotos tiene las siguientes
caractersticas:

Los tipos de datos primitivos y los objetos predefinidos de Java

que implementen la interfaz java.io.Serializable se pasan por
valor. Es decir, se copian del espacio de direcciones de una
mquina virtual a otra.
Los objetos (no remotos) cuyas clases implementen la
interfaz java.io.Serializable se pasan por valor.
Los objetos remotos que estn a la espera de peticiones llegadas
desde los clientes no se transmiten sino que, en su lugar, se
envan las referencias remotas a los mismos (instancias de
un stub). Por lo tanto, puede concluirse que se envan por
referencia.

Los objetos (no remotos) que no

implementan java.io.Serializable no pueden enviarse a un objeto
remoto.

Aclarar que, en el lenguaje de programacin Java, el paso de

argumentos es slo por valor, sean tipos primitivos u objetos. Cuando se
utiliza la expresin paso por referencia se refiere al paso por valor de
referencias remotas, es decir, el paso de los stubs.
La copia por valor se realiza mediante la serializacin de objetos. De
esta forma, los objetos pueden ser enviados por los clientes en forma de
flujo de bytes y pueden ser reconstruidos por los servidores en sus
espacios de direcciones. Adems, se asegura que si un objeto contiene
referencias a otros objetos, stas se incluyen en sus copias.

3.1.2. El API Java RMI

El uso de sockets permite la elaboracin de aplicaciones distribuidas.
Sin embargo, en ocasiones, son necesarios enfoques con un mayor grado
de abstraccin que el proporcionado por stos. Al utilizar sockets, las
aplicaciones deben desarrollar sus propios mecanismos para manejar de
forma eficiente los mensajes intercambiados, con la consecuente
complicacin que esto conlleva.
La API RMI (Remote Method Invacation) proporciona un mecanismo para
facilitar la elaboracin de aplicaciones distribuidas. Integrado dentro de
la jerarqua de paquetes oficiales del lenguaje de programacin Java, se
adapta perfectamente al modelo de programacin de dicho lenguaje.
Como ya se ha comentado, la programacin orientada a objetos se
adapta de manera natural a la programacin de aplicaciones
distribuidas. En la programacin orientada a objetos, tareas parciales
de un problema pueden ser modeladas como entidades, que
llamaremos objetos, que se comunican entre ellos durante su ejecucin.
En consecuencia, el uso de programacin orientada a objetos, resulta
una evolucin natural en el desarollo de aplicaciones distribuidas; de
forma que tareas parciales, que ahora estarn ubicadas en distintas
mquinas, son modeladas como objetos que intercambian mensajes a
travs de la red. RMI integra este concepto en el lenguaje de
programacin Java, de manera que el manejo de objetos en

aplicaciones distribuidas mantenga la semntica propia de los objetos

locales de Java. En consecuencia, RMI puede ser fcilmente integrada
con otras APIs de dicho lenguaje.
En RMI, un objeto de Java puede ``marcarse'' como remoto de forma
que los procesos de aplicaciones distribuidas pueden acceder a l como
si fuera local. En definitiva, RMI proporciona un modelo propio de
objetos distribuidos, optimizado para las caractersticas de Java.

3.1.3. Jerarqua de Objetos RMI

RMI se compone de una arquitectura de tres capas:

Capa de stubs/skeletons.- Dota a clientes y servidores de una

interfaz que les permite localizar objetos remotos para invocar
sus mtodos como si fueran locales.
Capa de referencias remotas.- Esta capa se encarga de la creacin
y gestin de las referencias a objetos remotos, manteniendo para
ello una tabla de objetos distribuidos. Adems, convierte las
llamadas remotas en peticiones hacia la capa de transporte.
Capa de transporte.- Capa de transporte del conjunto de
protocolos TCP/IP. RMI por defecto usa TCP, aunque admite otros.

3.1.4. El sistema de nombrado Registry