3.

5 DESARROLLO DE APLICACIN DISTRIBUIDA

Una aplicacin distribuida desarrollada utilizando RMI, como cualquier aplicacin
Java, est compuesta por interfaces y clases. Los interfaces definen mtodos,
mientras que las clases implementan los mtodos definidos en los interfaces
(tambin puede definir algunos mtodos adicionales). En una aplicacin
distribuida, se asume que algunas implementaciones residen en diferentes
mquinas virtuales. Los objetos que tienen mtodos que pueden llamarse desde
mquinas virtuales localizadas en otros ordenadores, son los objetos remotos.
Un objeto se convierte en remoto implementando un interfaz remoto, que tenga
estas caractersticas.

Un interfaz remoto extiende a java.rmi.Remote.

Cada

mtodo

del

interfaz

debe

soportar

la

excepcin

java.rmi.RemoteException, adems de cualquier excepcin especfica de la

aplicacin.
El STUB de un objeto remoto implementa el mismo conjunto de interfaces que el
objeto. En consecuencia, y haciendo uso de las propiedades bsicas del lenguaje
de programacin Java, como son la herencia y el polimorfismo, se permite la
conversin de tipos del STUB a cualquiera de esas interfaces. Un cliente podr
recibir siempre su STUB aprovechando este mecanismo, que en la prctica se
realizar a travs de la interfaz REMOTE ya presentada. Adems, slo aquellos
mtodos definidos en una interfaz remota estn disponibles para ser llamados en
la mquina virtual destino, lo cual permite aislar a los objetos remotos y slo
hacerlos accesibles a determinados mtodos.
Paso 1
Definir la interfaz remota
La interfaz remota definida debe derivar de la Interfaz Remote.
Los mtodos declarados en la interfaz debe lanzar la excepcin
RemoteException

Import java.rmi.*;
Public interface InterfaceRemote extends Remote {
Public int suma(int a,int b) throws RemoteException;
}
Paso 2
Desarrollar el objeto remoto mediante la implementacin de la interfaz remota.
Es importante hacer notar que:
El

servidor

remoto

se

define

partir

de

la

clase

java.rmi.server.

UnicastRemoteObject
El servidor remoto debe implementar la interfaz remota definida en el paso 1.
El servidor utilice un gestor de seguridad RMI propio para garantizar sus recursos
durante el transcurso de la comunicacin del cliente.
Public

class

ObjetoRemoto

extends

unicastRemoteObject.

InterfaceRemota {
Public ObjectRemoto () throws RemoteException
{
Super():
}
@Override
Public synchronized int suma(int a, int b) throws RemoteException {
System.out.println (Operacin: + a+ ++b+);
Return a*b;
}
}

Implements.

LAS

FUNCIONES

ESENCIALES

QUE

DEBEN

DESARROLLAR

LAS

APLICACIONES DISTRIBUIDAS, SON:

Localizar objetos remotos. Las aplicaciones cliente tienen dos alternativas para
obtener referencias de objetos remotos. Una aplicacin puede registrar sus
objetos remotos ante un servidor de nombres llamado rmiregistry, o la aplicacin
puede pasar referencias a objetos remotos como parmetro de una invocacin o
como valor de retorno.
Comunicarse con los objetos remotos. Los detalles de la comunicacin entre los
objetos remotos, son manejados por el sistema RMI. Para el programador, la
comunicacin entre objetos se asemeja a la utilizada normalmente en programas
Java.
RMI Permite pasar objetos Java puros, como parmetros en la invocacin de
mtodos de objetos remotos, proporciona los mecanismos necesarios para, por
medio de un servidor HTTP o FTP, cargar el cdigo y los datos de dichos
objetos.(figura 1.)

En la figura 1 se muestra una aplicacin distribuida, basada en RMI, que utiliza al

servidor de nombres rmiregistry para obtener referencias de objetos remotos.

El servidor que implementa los objetos remotos, invoca al rmiregistry para

asociarle un nombre a un objeto remoto. El cliente busca al objeto remoto
utilizando su nombre como argumento y, finalmente, invoca alguno de sus
mtodos. La figura 1 tambin muestra cmo el sistema RMI puede usar un
servidor web para cargar cdigos de operacin, de clientes a servidores y de
servidores a clientes, mediante el empleo de cualquier protocolo URL. Lazy
activation. Como se ver ms adelante, consiste en activar un objeto hasta que se
invoca alguno de sus mtodos. Un localizador de recursos uniforme (Uniform
Resourse Locator) es una representacin compacta de la localizacin y del medio
de acceder a algn recurso disponible va Internet. El URL proporciona un
apuntador a cualquier objeto que sea accesible en cualquier mquina conectada a
Internet. Debido a que los objetos son accesibles de diferentes maneras (ftp, http,
gopher, file, etc.), el URL indica adems el mtodo de acceso que se debe utilizar
para obtener el objeto deseado

ESCENARIOS DE UTILIZACIN DE
LAS APLICACIONES DISTRIBUIDAS

EJEMPLOS DE APLICACIONES
DISTRIBUIDAS

3.6 PASO DE PARMETROS A TRAVS DE LA RED.

Un parmetro de una llamada remota o un valor de retorno puede ser cualquier

tipo primitivo u objeto que sea serializable, es decir, que implemente la interfaz
java.io.Serializable.
Las clases de los parmetros o valor de retorno que no estn localmente se
descargan de forma dinmica durante la ejecucin. Paso de parmetros no
remotos
Paso de parmetros no remotos

Estos parmetros se pasan como valor

Si es un parmetro se hace una copia del objeto antes de mandarlo al

servidor

Si es un valor de retorno se crea un nueva instancia del objeto

Paso de parmetros remotos

Objeto remoto exportado: se enva la referencia del stub del objeto

Objeto remoto no exportado: se enva la referencia al objeto remoto

Clase Annotation

El descriptor de la clase de un objeto se asocia con los parmetros o valor

de retorno

enviados en la invocacin remota para poder descargar el

cdigo de la clase de forma dinmica durante la ejecucin en caso de que

no se encuentren de forma local.
PARMETROS SERIALIZABLE
Un objeto Serializable es el que implementa la interface Serializable. Como dicha
interface no tiene ningn mtodo, basta con poner que nuestra clase la
implementa y ya est.

Para que la clase sea realmente Serializable, necesita adems, que todos sus
atributos sean tambin Serializable. Esto quiere decir que sus atributos pueden ser
tipos primitivos (int, char, float, etc), clases de java normalitas (consultar en la API
de Java si implementan la interface, por ejemplo Integer, String) o bien clases
nuestras que tambin la implementen.
Cuando se pasa un objeto Serializable como parmetro de un mtodo remoto,
java se encarga de convertir ese objeto a bytes (serializar el objeto), enviarlo por
red y hacerlo llegar al otro lado (el servidor). All, java se encarga de convertir
nuevamente esos bytes a un objeto (deserializar el objeto). Si no usamos carga
dinmica de clases, tanto el cliente como el servidor deben tener esa clase en su
CLASSPATH para poder usarla.
En este momento, existen dos instancias distintas de la clase, una copia de la otra.
Si el cliente o el servidor tocan su copia, la otra no se ve afectada. Pasar un objeto
Serializable equivale al paso por valor.
En el ejemplo simple de rmi, vamos a modificar el InterfaceRemoto para que en
vez de dos parmetros int admita un objeto Serializable que los contenga en su
interior. Por aquello de la "elegancia" en el cdigo, haremos que el parmetro
recibido sea una interface, la InterfaceSumandos.
int getSumando2()

return b;
}
}Se compila normalmente y necesitamos copiar los class tanto en el servidor
como en el cliente.
PARMETROS REMOTE
Un objeto Remote es el que implementa la interface Remote. Aunque
aparentemente con esta inteface no tenemos que hacer nada (igual que con la
interface Serializable), en realidad si debemos hacer nuestra clase de una cierta
forma. Para evitarnos hacer este cdigo especial, lo mejor es hacer heredar

nuestra clase de UnicastRemoteObject. Con ello ya implementa la interface

Remote y tenemos hecho todo el cdigo necesario hecho.
Cuando un objeto es Remote, adems de compilarlo de la forma habitual,
necesitamos compilarlo con el compilador rmic, que viene con java y est en
JAVA_HOME/bin. Una vez obtenido nuestro ObjetoRemote.class, pasamos el
compilador rmic de esta forma
$ rmic paquete.ObjetoRemote
No ponemos el fichero ObjetoRemote.class, sino el nombre de la clase. Esto
generar un fichero ObjetoRemote_Stub.class.
Cuando pasamos un objeto Remote como parmetro de un mtodo rmi, java se
encarga de enviar el ObjetoRemote_Stub al otro lado. El servidor reconstruye este
ObjetoRemote_Stub. Por ello, ObjetoRemote_Stub.class debe estar en el
CLASSPATH de ambos.
Cuando el servidor llama a cualquier mtodo de la clase ObjetoRemote_Stub, que
son los mismos que tiene ObjetoRemote, la clase ObjetoRemote_Stub se encarga
de transmitir la llamada a travs de la red al ObjetoRemote original que est en el
cliente. Por ello, si el servidor cambia algo llamando a ObjetoRemote_Stub, se
cambia en el objeto original del cliente.
Si el servidor trata de obtener un valor de ObjetoRemote_Stub a travs de algn
mtodo, esta clase se encarga de pedir el valor a travs de red al original.
Por ello, pasar objetos Remote es equievalente al paso de parmetros por
referencia. Slo existe un objeto real y hay otro ficticio que delega todas las
llamadas, a travs de red, en el original
Seguimos modificando el ejemplo simple de rmi, aadiendo un nuevo mtodo a
InterfaceRemota para que admita, por ejemplo, un Contador remoto. Nuevamente,
como nos pasamos de "elegantes", otra interface para ello
/* Aadimos un nuevo mtodo a InterfaceRemota */
public interface InterfaceRemota extends Remote {

public int suma (InterfaceSumandos sumandos) throws RemoteException;

public
void
RemoteException;

tomaContador

(InterfaceContador

contador)

throws

}
/* Y aqu la nueva interface que har de parmetro del nuevo mtodo */
public interface InterfaceContador extends Remote
{
public void incrementa() throws RemoteException;
}
Y la implementacin de esto puede ser
/* Una implementacin para este nuevo parmetro */
public
class
Contador
InterfaceContador

extends

UnicastRemoteObject

implements

{
private int contador;
public Contador () throws RemoteException

contador=0;
}
public void incrementa() throws RemoteException

System.out.println (contador + " + 1 = " + ++contador);

}
}
Al heredar de UnicastRemoteObject nos vemos Este Contador debemos
compilarlo de la forma normal y luego, como comentamos antes, con rmic para
obtener el Contador_Stub.class. Este ltimo es el que tienen que tener cliente y
servidor.
Obligados a hacer un constructor que lance una RemoteException. Escribimos
como se incrementa el contador cada vez que llamamos al mtodo para ver en la
pantalla de quin (servidor o cliente) se realiza el incremento.

Bibliografa
file:///C:/Users/v%C2%A1%C2%A1lma/Downloads/55931825-Desarrollo-deAplicaciones-Distribuidas.pdf
http://www.iuma.ulpgc.es/users/lhdez/inves/pfcs/memoriadomingo/node6.html#SECTION03330000000000000000
http://prezi.com/l7mlseryvl5z/copy-of-rmi-en-java/#share_embed
http://www.lcc.uma.es/~pinilla/JavaRMI.pdf
http://www.chuidiang.com/java/rmi/rmi_parametros.php