TutorJava recomienda...

Invocación Remota de Métodos (RMI)

Autor-Traductor: Juan Antonio Palos (Ozito)
Puedes encontrar la Version Original en Ingles en ( http://java.sun.com)
Leer comentarios (0) | Escribir comentario | Puntuación: (1 voto) Vota

Indice de contenidos
● Trabajar con RMI

● Introducción a las Aplicaciones RMI

❍ Ventajas de la Carga Dinámica de Código
❍ Interfaces, Objetos y Métodos Remotos

❍ Crear Aplicaciones Distribuidas utilizando RMI

❍ Diseñar e implementar los componentes de nuestra aplicación distribuida.

❍ Compilar los Fuentes y Generar stubs.

❍ Hacer accesibles las Clases en la Red.

❍ Arrancar la Aplicación.

❍ Construir un Motor de Cálculo Genérico

● Escribir un Servidor RMI

● Diseñar un Interface Remoto
● Implementar un Interface Remoto
❍ Declarar los Interfaces Remotos que están siendo Implementados
❍ Definir el Constructor

❍ Proporcionar una Implementación para cada Método Remoto

❍ Pasar Objetos en RMI

❍ El método main() del Servidor

❍ Crear e Instalar un Controlador de Seguridad

❍ Poner el Objeto Remoto a Disposición de los Clientes

● Crear un Programa Cliente

● Compilar el Ejemplo
❍ Construir un Fichero JAR con las Clases de Interfaces
❍ Construir las Clases del Servidor

❍ Construir las clases del Cliente

● Ejecutar el Ejemplo
❍ Una Nota sobre la Seguridad
❍ Arrancar el Servidor
❍ Arrancar el Cliente
Leer comentarios (0) | Escribir comentario | Puntuación: (1 voto) Vota
 TutorJava recomienda...

Invocación Remota de Métodos (RMI)

En esta página:
● Trabajar con RMI

Trabajar con RMI

El sistema de Invocación Remota de Métodos (RMI) de Java permite a un objeto que se está
ejecutando en una Máquina Virtual Java (VM) llamar a métodos de otro objeto que está en otra VM
diferente.
Nota:

RMI proporciona comunicación remota entre programas escritos en Java. Si unos de nuestros
programas está escrito en otro lenguaje, deberemos considerar la utilización de IDL en su lugar.

Esta sección ofrece una breve descripción del sistema RMI que pasea a través de un ejemplo
completo cliente/servidor que utiliza la capacidades únicas de RMI para cargar y ejecutar tareas
definidas por el usuario en tiempo de ejecución. El servidor del ejemplo implementa un motor de
cálculo general. El cliente utiliza el motor de cálculo para calcular el valor del número pi.

Introducción a las Aplicaciones RMI Describe el sistema RMI y lista sus ventajas. Además, esta
lección proporcionar una descripción de una aplicación típica de RMI, compuesta por un servidor y
un cliente, y presenta los términos importantes.

Escribir un Servidor RMI Muestra el código del servidor del motor de cálculo. A través de este
ejemplo, aprenderemos cómo diseñar e implementat un servidor RMI.

Crear un Programa Cliente Echa un vistazo a un posible cliente del motor de cálculo y lo utiliza
para ilustrar las características importantes de un cliente RMI.

Compilar y Ejecutar el Ejemplo Muestra cómo compilar y ejecutar tanto el servidor del motor de
cálculo como su cliente.
 TutorJava recomienda...

Invocación Remota de Métodos (RMI)

En esta página:
● Introducción a las Aplicaciones RMI
❍ Ventajas de la Carga Dinámica de Código
❍ Interfaces, Objetos y Métodos Remotos
❍ Crear Aplicaciones Distribuidas utilizando RMI
❍ Diseñar e implementar los componentes de nuestra aplicación distribuida.
❍ Compilar los Fuentes y Generar stubs.
❍ Hacer accesibles las Clases en la Red.
❍ Arrancar la Aplicación.
❍ Construir un Motor de Cálculo Genérico

Introducción a las Aplicaciones RMI

Las aplicaciones RMI normalmente comprenden dos programas separados: un servidor y un cliente.
Una aplicación servidor típica crea un montón de objetos remotos, hace accesibles unas referencias
a dichos objetos remotos, y espera a que los clientes llamen a estos métodos u objetos remotos.
Una aplicación cliente típica obtiene una referencia remota de uno o más objetos remotos en el
servidor y llama a sus métodos. RMI proporciona el mecanismo por el que se comunican y se pasan
información del cliente al servidor y viceversa. Cuando es una aplicación algunas veces nos
referimos a ella como Aplicación de Objetos Distribuidos.

Las aplicaciones de objetos distribuidos necesitan.

Localizar Objetos Remotos
Las aplicaciones pueden utilizar uno de los dos mecanismos para obtener referencias a objetos
remotos. Puede registrar sus objetos remotos con la facilidad de nombrado de RMI rmiregistry. O
puede pasar y devolver referencias de objetos remotos como parte de su operación normal.
Comunicar con Objetos Remotos
Los detalles de la comunicación entre objetos remotos son manejados por el RMI; para el
programador, la comunicación remota se parecerá a una llámada estándard a un método Java.
Cargar Bytecodes para objetos que son enviados.
Como RMI permite al llamador pasar objetos Java a objetos remotos, RMI proporciona el mecanismo
necesario para cargar el código del objeto, así como la transmisión de sus datos.
La siguiente ilustración muestra una aplicación RMI distribuida que utiliza el registro para obtener
referencias a objetos remotos. El servidor llama al registro para asociar un nombre con un objeto
remoto. El cliente busca el objeto remoto por su nombre en el registro del servidor y luego llama a
un método. Esta ilustración también muestra que el sistema RMI utiliza una servidor Web existente
para cargar los bytecodes de la clase Java, desde el servidor al cliente y desde el cliente al servidor,
para los objetos que necesita.
El sistema RMI utiliza un servidor Web para cargar los bytecodes de la clase Java, desde el servidor
al cliente y desde el cliente al servidor.

Ventajas de la Carga Dinámica de Código

Una de las principales y únicas características de RMI es la habilidad de descargar los bytecodes (o
simplemente, código) de una clase de un objeto si la clase no está definida en la máquina virtual
del recibidor. Los tipos y comportamientos de un objeto, anteriormente sólo disponibles en una sóla
máquina virtual, ahora pueden ser transmitidos a otra máquina virtual, posiblemente remota. RMI
pasa los objetos por su tipo verdadero, por eso el comportamiento de dichos objetos no cambia
cuando son enviados a otra máquina virtual. Esto permite que los nuevos tipos sean introducidos en
máquinas virtuales remotas, y así extender el comportamiento de una aplicación dinámicamente. El
ejemplo del motor de cálculo de este capítulo utiliza las capacidad de RMI para introducir un nuevo
comportamiento en un programa distribuido.

Interfaces, Objetos y Métodos Remotos

Una aplicación distribuida construida utilizando RMI de Java, al igual que otras aplicaciones Java,
está compuesta por interfaces y clases. Los interfaces definen métodos, mientras que las clases
implementan los métodos definidos en los interfaces y, quizás, también definen algunos métodos
adicionales. En una aplicación distribuida, se asume que algunas implementaciones residen en
diferentes máquinas virtuales. Los objetos que tienen métodos que pueden llamarse por distintas
máquinas virtuales son los objetos remotos.

Un objeto se convierte en remoto implementando un interface remoto, que tenga estas

caracterísitcas.
● Un interface remoto desciende del interface java.rmi.Remote.
● Cada método del interface declara que lanza una java.rmi.RemoteException además de cualquier
excepción específica de la aplicación.
El RMI trata a un objeto remoto de forma diferente a como lo hace con los objetos no-remotos
cuando el objeto es pasado desde una máquina virtual a otra. En vez de hacer una copia de la
implementación del objeto en la máquina virtual que lo recibe, RMI pasa un stub para un objeto
remoto. El stub actúa como la representación local o proxy del objeto remoto y básicamente, para
el llamador, es la referencia remota. El llamador invoca un método en el stub local que es
responsable de llevar a cabo la llamada al objeto remoto.

Un stub para un objeto remoto implementa el mismo conjunto de interfaces remotos que el objeto
remoto. Esto permite que el stub sea tipado a cualquiera de los interfaces que el objeto remoto
implementa. Sin embargo, esto también significa que sólo aquellos métodos definidos en un
interface remoto están disponibles para ser llamados en la máquina virtual que lo recibe.

Crear Aplicaciones Distribuidas utilizando RMI

Cuando se utiliza RMI para desarrollar una aplicación distribuida, debemos seguir estos pasos
generales.
1. Diseñar e implementar los componentes de nuestra aplicación distribuida.
2. Compilar los Fuentes y generar stubs.
3. Hacer las clases Accesibles a la Red.
4. Arrancar la Aplicación.

Diseñar e implementar los componentes de nuestra aplicación distribuida.

Primero, decidimos la arquitectura de nuestra aplicación y determinamos qué componentes son
objetos lcoales y cuales deberían ser accesibles remotamente. Este paso incluye.
● Definir los Interfaces Remotos. Un interface remoto especifica los métodos que pueden ser llamados
remotamente por un cliente. Los clientes programan los interfaces remotos, no la implementación de
las clases de dichos interfaces. Parte del diseño de dichos interfaces es la determinación de cualquier
objeto local que sea utilizado como parámetro y los valores de retorno de esos métodos; si alguno de
esos interfaces o clases no existen aún también tenemos que definirlos.
● Implementar los Objetos Remotos. Los objetos remotos deben implementar uno o varios interfaces
remotos. La clase del objeto remoto podría incluir implementaciones de otros interfaces (locales o
remotos) y otros métodos (que sólo estarán disponibles localmente). Si alguna clase local va a ser
utilizada como parámetro o cómo valor de retorno de alguno de esos métodos, también debe ser
implementada.
● Implementar los Clientes. Los clientes que utilizan objetos remotos pueden ser implementados
después de haber definido los interfaces remotos, incluso después de que los objetos remotos hayan
sido desplegados.
Compilar los Fuentes y Generar stubs.
Este es un proceso de dos pasos. En el primer paso, se utiliza el compilador javac para compilar los
ficheros fuentes de Java, los cuales contienen las implementaciones de los interfaces remotos, las
clases del servidor, y del cliente. En el segundo paso es utilizar el compilador rmic para crear los
stubs de los objetos remotos. RMI utiliza una clase stub del objeto remoto como un proxy en el
cliente para que los clientes puedan comunicarse con un objeto remoto particular.

Hacer accesibles las Clases en la Red.

En este paso, tenmos que hacer que todo - los ficheros de clases Java asociados con los interfaces
remotos, los stubs, y otras clases que necesitemos descargar en los clientes - sean accesibles a
través de un servidor Web.

Arrancar la Aplicación.
Arrancar la aplicación incluye ejecutar el registro de objetos remotos de RMI, el servidor y el cliente.
El resto de este capítulo muestra cómo seguir estos pasos para crear un motor de cálculo.

Construir un Motor de Cálculo Genérico

Esta sección se enfoca a una sencilla pero potente aplicación distribuida llamada motor de cálculo.
Este motor de cálculo es un objeto remoto en el servidor que toma tareas de clientes, las ejecuta, y
devuelve los resultados. Las tareas se ejecutan en la máquina en la que se está ejecutando el
servidor. Este tipo de aplicación distribuida podría permitir que un número de máquinas clientes
utilizaran una máquina potente, o una que tuviera hardware especializado.

El aspecto novedoso del motor de cálculo es que las tareas que ejecuta no necesitan estar definidas
cuando se escribe el motor de cálculo. Se pueden crear nuevas clases de tareas en cualquier
momento y luego entregarlas el motor de cálculo para ejecutarlas. Todo lo que una tarea requiere
es que su clase implemente un interface particular. Por eso una tarea puede ser enviada al motor
de cálculo y ejecutada, incluso si la clase que define la tarea fue escrita mucho después de que el
motor de cálculo fuera escrito y arrancado. El código necesita conseguir que una tarea sea
descargada por el sistema RMI al motor de cálculo, y que éste ejecute la tarea utilizando los
recursos de la máquina en la que está ejecutando el motor de cálculo.

La habilidad para realizar tareas arbitrarias esta permitida por la naturaleza dinámica de la
plataforma Java, que se extiende a través de la red mediante RMI. El RMI carga dinámicamente el
código de las tareas en la máquina virtual del motor de cálculo y ejecuta la tarea si tener un
conocimiento anterior de la clase que implementa la tarea. Una aplicación como ésta que tiene la
habilidad de descargar código dinámicamente recibe el nombre de "aplicación basada en
comportamiento". Dichas aplicaciones normalmente requieren infraestructuras que permitan
agentes. Con RMI, dichas aplicaciones son parte del macanismo básico de programación distribuida
de Java.
 TutorJava recomienda...

Invocación Remota de Métodos (RMI)

En esta página:
● Escribir un Servidor RMI

Escribir un Servidor RMI

El servidor del motor de cálculo acepta tareas de los clientes, las ejecuta, y devuelve los resultados.
El servidor está compuesto por un interface y una clase. El interface propociona la definición de los
métodos que pueden ser llamados desde el cliente. Esencialmente, el interface define lo que el
cliente ve del objeto remoto. La clase proporciona la implementación.

Diseñar un Interface Remoto Esta página muestra cómo el interface Compute es el pegamento que
conecta el cliente y el servidor. También aprenderemos sobre el API de RMI que soporta esta
comunicación.

Implementar un Interface Remoto En esta página exploraremos la clase que implementa el interface
Compute, que implementa un objeto remoto. Esta clase también propociona el resto del código que
configura el programa servidor: un método main que crea un ejemplar del objeto remoto, lo
registra con la facilidad de nombrado, y configura un controlador de seguridad.
 TutorJava recomienda...

Invocación Remota de Métodos (RMI)

En esta página:
● Diseñar un Interface Remoto

Diseñar un Interface Remoto

En el corazón del motor de cálculo hay un protocolo que permite que se le puedan enviar trabajos,
el motor de cálculo ejecuta esos trabajos, y los resultados son devueltos al cliente. Este protocolo
está expresado en interfaces soportados por el motor de cálculo y por los objetos que le son
enviados.

El protocolo del motor de cálculo en acción.

Cada uno de los interfaces contiene un sólo método. El interface del motor de cálculo Compute,
permite que los trabajos sean enviados al motor, mientras que el interface Task define cómo el
motor de cálculo ejecuta una tarea enviada.
El interface compute.Compute define la parte accesible remotamente - el propio motor de cálculo.
Aquí está el interface remoto con su único método.

package compute;

import java.rmi.Remote;
import java.rmi.RemoteException;

public interface Compute extends Remote {

Object executeTask(Task t) throws RemoteException;
}
Al extender el interface java.rmi.Remote, este interface se marca a sí mismo como uno de
aquellos métodos que pueden ser llamados desde cualquier máquina virtual. Cualquier objeto que
implemente este interface se convierte en un objeto remoto.

Como miembro de un interface remoto, el método executeTask es un método remoto. Por lo

tanto, el método debe ser definido como capaz de lanzar una java.rmi.RemoteException. Esta
excepción es lanzada por el sistema RMI durante una llamada a un método remoto para indicar que
ha fallado la comunicación o que ha ocurrido un error de protocolo. Una RemoteException es una
excepción chequeada, por eso cualquier método Java que haga una llamada a un método remotor
necesita manejar esta excepción, capturándola o declarándola en sus clausula throws.

El segundo interface necesitado por el motor de cálculo define el tipo Task. Este tipo es utilizado
como un argumento del método executeTask del interface Compute. El interface compute.Task
define el interface entre el motor de cálculo y el trabajo que necesita hacer, proporcionando la
forma de iniciar el trabajo.

package compute;

import java.io.Serializable;

public interface Task extends Serializable {

Object execute();
}
El interface Task define un sólo método, execute. Este método devuelve un Object, y no tiene
parámetros ni lanza excepciones. Como este interface no extiende Remote, el método no necesita
listar java.rmi.RemoteException en su clausula throws.

El valor de retorno de los métodos executeTask de Compute y execute de Task es declarado

como del tipo Object. Esto significa que cualquiera tarea que quiera devolver un valor de uno de los
tipos primitivos de Java (como un int o un float) necesita crear un ejemplar de la clase envolvente
equivalente para ese tipo (como un Integer o un Float) y devolver ese objeto en su lugar.

Observamos que el interface Task extiende el interface java.io.Serializable. El RMI utiliza el

mecanismo de serialización de objetos para transportar objetos entre máquinas virtuales.
Implementar Serializable hace que la clase sea capaz de convertirse en un stream de bytes
auto-descriptor que puede ser utilizado para reconstruir una copia exacta del objeto serializado
cuando el objeto es leído desde el stream.

Se pueden ejecutar diferentes tipos de tareas en un objeto Compute siempre que sean
implementaciones del tipo Task. Las clases que implementen este interface pueden contener
cualquier dato necesario para el cálculo de la tarea, y cualquier otro método necesario para ese
cálculo.

Así es cómo RMI hace posible este sencillo motor de cálculo. Como RMI puede asumir que los
objetos Task están escritos en Java, las implementaciones de los objetos Task que anteriormente
eran desconocidas para el motor de cálculo son descargadas por el RMI dentro de la máquina virtual
del motor de cálculo cuando sea necesario. Esto permite a los clientes del motor de cálculo definir
nuevos tipos de tareas para ser ejecutadas en el servidor sin necesitar que el código sea instalado
explícitamente en dicha máquina. Además, como el método executeTask devuelve un
java.lang.Object, cualquier tipo de objeto Java puede ser pasado como valor de retorno en una
llamada remota.

El motor de cálculo, implementado por la clase ComputeEngine, implementa el interface

Compute, permitiendo que diferentes tareas le sean enviadas mediante llamadas a su método
executeTask. Estas tareas se ejecutan utilizando la implementación de task del método execute.
El motor de cálculo devuelve los resultados a su llamador a través de su valor de retorno: un
Object.
 TutorJava recomienda...

Invocación Remota de Métodos (RMI)

En esta página:
● Implementar un Interface Remoto
❍ Declarar los Interfaces Remotos que están siendo Implementados
❍ Definir el Constructor
❍ Proporcionar una Implementación para cada Método Remoto
❍ Pasar Objetos en RMI
❍ El método main() del Servidor
❍ Crear e Instalar un Controlador de Seguridad
❍ Poner el Objeto Remoto a Disposición de los Clientes

Implementar un Interface Remoto

Empecemos la tarea de implementar una clase para el motor de cálculo. En general, la implementación de la clase
para un interface remoto debería al menos.
● Declarar los Interfaces remotos que están siendo implementados.
● Definir el constructor del objeto remoto.
● Proprorcionar una implementación para cada método remoto de cada interface remoto.
El servidor necesita crear e instalar los objetos remotos. Este proceso de configuración puede ser encapsulado en un
método main en la propia clase de implementación del objeto remoto, o puede ser incluido completamente en otra
clase. El proceso de configuración debería.
● Crear e instalar un controlador de seguridad.
● Crear uno o más ejemplares del objeto remoto.
● Registrar al menos uno de los objetos remotos con el registro de objetos remotos de RMI (a algún otro servicio de
nombrado que utilice JNDI).
Abajo podemos ver la implementación completa del motor de cálculo. La clase engine.ComputeEngine implementa
el interface remoto Compute y también incluye el método main para configurar el motor de cálculo.

package engine;

import java.rmi.*;
import java.rmi.server.*;
import compute.*;

public class ComputeEngine extends UnicastRemoteObject

implements Compute
{
public ComputeEngine() throws RemoteException {
super();
}
public Object executeTask(Task t) {
return t.execute();
}

public static void main(String[] args) {

if (System.getSecurityManager() == null) {
System.setSecurityManager(new RMISecurityManager());
}
String name = "//localhost/Compute";
try {
Compute engine = new ComputeEngine();
Naming.rebind(name, engine);
System.out.println("ComputeEngine bound");
} catch (Exception e) {
System.err.println("ComputeEngine exception: " + e.getMessage());
 e.printStackTrace();
}
}
}
Ahora echaremos una mirada más cercana a cada uno de los componentes de la implementación del motor de
cálculo.

Declarar los Interfaces Remotos que están siendo Implementados

La clase que implementa el motor de cálculo se declara como.

public class ComputeEngine extends UnicastRemoteObject

implements Compute
Esta declaración indica que la clase implementa el interface remoto Compute (y, por lo tanto, define un objeto
remoto) y extiende la clase java.rmi.server.UnicastRemoteObject.

UnicastRemoteObject es una clase de conveniencia, definida en el API público del RMI, que puede ser utilizada
como superclase para la implementación de objetos remotos. La superclase UnicastRemoteObject suministra
implementación para un gran número de métodos de java.lang.Object (equals, hashCode, toString) para que
estén definidos apropiadamente para objetos remotos. UnicastRemoteObject también incluye constructores y
métodos estáticos utilizados para exportar un objeto remoto, es decir, hacer que el objeto remoto pueda recibir
llamadas de los clientes.
Una implementación de objeto remoto no tiene porque extender UnicastRemoteObject, y ninguna implementación
que lo haga debe suministrar las implementaciones apropiadas de los métodos de java.lang.Object. Además, una
implementación de un objeto remoto debe hacer una llamada explícita a uno de los métodos exportObject de
UnicastRemoteObject para que el entorno RMI se de cuenta del objeto remoto para que éste pueda aceptar
llamadas.
Al extender UnicastRemoteObject, la ComputeEngine puede ser utilizada pra crear un sólo objeto remoto que
soporte comunicación remota (punto a punto) y que utilice el transporte de comunicación basado en sockets que
tiene por defecto el RMI.

Si elegimos extender un objeto remoto de otra clase distinta de UnicastRemoteObject, o, alternativamente, los
extendemos de la nueva clase java.rmi.activation.Activatable del JDK 1.2 (utilizada pra construir objetos remotos
que puedan ser ejecutados sobre demanda), necesitamos exportar explícitamente el objeto remoto llamando a uno
de los métodos UnicastRemoteObject.exportObject o Activatable.exportObject desde el constructor de nuestra
clase (o cualquier otro método de inicialización, cuando sea apropiado).
El ejemplo del motor de cálculo define un objeto remoto que implementa un sólo interface remoto y ningún otro
interface. La clase ComputeEngine también contiene algunos métodos que sólo pueden ser llamados localmente. El
primero de ellos es un constructor para objetos ComputeEngine; el segundo es un método main que es utilizado
para crear un objeto ComputeEngine y ponerlo a disposición de los clientes.

Definir el Constructor
La clase ComputeEngine tiene un único constructor que no toma argumentos.

public ComputeEngine() throws RemoteException {

super();
}
Este constructor sólo llama al constructor de su superclase, que es el constructor sin argumentos de la clase
UnicastRemoteObject. Aunque el constructor de la superclase obtiene la llamada incluso si la omitimos en el
constructor de ComputeEngine, la hemos incluido por claridad.

Durante la construcción, un objeto UnicastRemoteObject es exportado, lo que significa que está disponible para
aceptar peticiones de entrada al escuchar las llamadas de los clientes en un puerto anónimo.
Nota:

En el JDK 1.2, podríamos indicar el puerto específico que un objeto remoto utiliza para aceptar peticiones.

El constructor sin argumentos de la superclase,UnicastRemoteObject, declara la excepción RemoteException en

su clausula throws, por eso el constructor de ComputeEngine también debe declarar que lanza una
RemoteException. Esta excepción puede ocurrir durante la construcción si falla el intento de exportar el objeto
(debido a que, por ejemplo, no están disponibles los recursos de comunicación o a que la clase stub apropiada no se
encuentra).

Proporcionar una Implementación para cada Método Remoto

La clase para un objeto remoto proporciona implementaciones para todos los métodos remotos especificados en los
interfaces remotos. El interface Compute contiene un sólo método remoto, executeTask, que se implementa de
esta forma.

public Object executeTask(Task t) {

return t.execute();
}
Este método implementa el protocolo entre el ComputeEngine y sus clientes. Los clientes proporcionan al
ComputeEngine un objeto Task, que tiene una implementación del método execute de task. El ComputeEngine
ejecuta la tarea y devuelve el resultado del método directamente a su llamador.
El método executeTask no necesita saber nada más sobre el resultado del método execute sólo que es un Object.
El llamador presumiblemente sabe algo más sobre el tipo preciso del Object devuelto y puede tipar el resultado al
tipo apropiado.

Pasar Objetos en RMI

Los argumentos y los tipos de retorno de los métodos remotos pueden ser de casi cualquier tipo Java, incluyendo
objetos locales, objetos remotos y tipos primitivos. Más precisamente, una entidad de cualquier tipo Java puede ser
pasada como un argumento o devuelta por un método remoto siempre que la entidad sea un ejemplar de un tipo que
sea.
● Un tipo primitivo de Java,
● un objeto remoto, o
● un objeto serializable lo que significa que implementa el interface java.io.Serializable
Unos pocos tipos de objetos no cumplen con estos criterios y por lo tanto no pueden ser pasados ni devueltos por un
método remoto. La mayoría de estos objetos (como un descriptor de fichero) encapsulan información que sólo tiene
sentido en un espacio de dirección única. Muchas clase del corazón Java, incluso algunas de java.lang y java.util,
implementan el interface Serializable.

Estas son las reglas que gobiernan el paso y retorno de valores.

● Los objetos remotos se pasan esencialmente por referencia. Una referencia a un objeto remoto es realmente un stub, que
es un proxy del lado del cliente que implementa el conjunto completo de interfaces remotos que implementa el objeto
remoto.
● Los objetos locales son pasados por copia utilizando el macanismo de serialización de objetos de Java. Por defecto,
todos los campos se copian, excepto aquellos que están marcados como static o transient. El comportamiendo de la
serialización por defecto puede ser sobrecargado en una básica clase-por-clase.
Pasar un objeto por referencia (como se hace con los objetos remotos) significa que cualquier cambio hecho en el
estado del objeto por el método remoto es reflejado en el objeto remoto original. Cuando se pasa un objeto remoto,
sólo aquellos interfaces que son interfaces remotos están disponibles para el receptor, cualquier otro método definido
en la implementación de la clase o definido en un interface no remoto no estará disponible para el receptor.

Por ejemplo, si pasarámos por referencia un ejemplar de la clase ComputeEngine, el receptor tendría acceso sólo al
método executeTask. El receptor no vería ni el constructor ComputeEngine ni su método main ni cualquier otro
método de java.lang.Object.

En las llamadas a método remotoss, los objetos -parámetos, valores de retorno y excpeciones - que no son objetos
remotos son pasados por valor. Esto significa que se crea una copia del objeto en la máquina virtual del receptor.
Cualquier cambio en el estado del objeto en el receptor será reflejado sólo en la copia del receptor, no en el ejemplar
original.

El método main() del Servidor

El método más complicado de la implementación de ComputeEngine es el método main. Este método es utilizado
para arrancar el ComputeEngine, y, por lo tanto, necesita hacer la inicialización necesaria para preparar el servidor
para aceptar llamadas de los clientes. Este método no es un método remoto, lo que significa que no puede ser
llamado desde otra máquina virtual que no sea la suya. Cómo el método main se declara static, no está asociado
con ningún objeto, sino con la clase ComputeEngine.

Crear e Instalar un Controlador de Seguridad

Lo primero que hace el método main es crear e instalar un controlador de seguridad. Éste protege los accesos a los
recursos del sistema por parte de código no firmado que se ejecute dentro de la máquina virtual. El controlador de
seguridad determina si el código descargado tiene acceso al sistema de ficheros local o puede realizar cualquier otra
operación privilegiada.

Todos los programas que utilicen RMI deben instalar un controlador de seguridad o el RMI no descargará las clases
(las que no se encuentren el el path local) para los objetos que se reciban como parámetros. Estas restriciones
aseguran que las operaciones realizadas por el código descargado pasarán a través de unas pruebas de seguridad.

El ComputeEngine utiliza un ejemplo de controlador de seguridad suministrado como parte del RMI, el
RMISecurityManager. Este controlador de seguridad fuerza una política de seguridad similar al controlador de
seguridad típico de los applets (es decir, es muy conservador con los accesos que permite). Una aplicación RMI
podría definir y utilizar otra clase SecurityManager que diera un acceso más liberal a los recursos del sistema, o, en
el JDK 1.2, utilizar un fichero de vigilancia que ofrezca más permisos.
Aquí temos el código que crea e instala el controlador de seguridad.

if (System.getSecurityManager() == null) {
System.setSecurityManager(new RMISecurityManager());
}
Poner el Objeto Remoto a Disposición de los Clientes
Luego, el método main crea un ejemplar de ComputeEngine. Esto se hace con la sentencia.

Compute engine = new ComputeEngine();

Como se mencionó anteriormente, este constructor llama al constructor de su superclase UnicastRemoteObject,
que exporta el objeto recien creado al sistema RMI. Una vez completada la exportación, el objeto remoto
ComputeEngine esta listo para aceptar llamadas de los clientes en un puerto anónimo (elegido por el RMI o por el
sistema operativo). Observa que el tipo de la variable engine es Compute, y no ComputeEngine. Esta declaración
enfatiza que el interface disponible para los clientes es el interfaceCompute y sus métodos, no la clase
ComputeEngine y sus métodos.
Antes de que un llamador pueda invocar un método de un objeto remoto, debe obtener una referencia al objeto
remoto. Este puede hacerse de la misma forma que en que se obtiene cualquier otra referencia en un programa
Java, que es obteniéndolo como parte del valor de retorno de un método o como parte de una estructura de datos
que contenga dicha referencia.

El sistema proporciona un objeto remoto particular, el registro RMI, para encontrar referencias a objetos remotos. El
registro RMI es un sencillo servicio de nombrado para objetos remotos que permite a los clientes remotos obtener
una referencia a un objeto remoto por su nombre. El registro se utiliza típicamente para localizar el primer objeto
remoto que un cliente RMI necesita utilizar. Este primer objeto remoto, luego proporciona soporte para encontrar
otros objetos.

El interface java.rmi.Naming es utilizado como un API final para la entrega (o registrado) y búsqueda de objetos
remotos en el registro. Una vez registrado un objeto remoto en el registro RMI en el host local, los llamadores de
cualquier host pueden busar el objeto remoto por el nombre, obtener su referencia, y luego llamar a los métodos del
objeto. El registro podría ser compartido por todos los servidores ejecútandose en un host, o un proceso servidor
individual podría crear y utilizar su propio registro si así lo desea.

La clase ComputeEngine crea un nombre para el objeto con la sentencia.

String name = "//localhost

/Compute";
Este nombre incluye el nombre del host localhost, en el que se están ejecutando el registro y el objeto remoto, y un
nombre Compute, que identifica el objeto remoto en el registro. Luego está el código necesario para añadir el
nombre al registro RMI que se está ejecutando en el servidor. Esto se hace después (dentro del bloque try con la
sentencia.

Naming.rebind(name, engine);
Al llamar al método rebind se hace una llamada remota al registro RMI del host local. Esta llamada puede provocar
que se genera une RemoteException, por eso tenemos que manejar la excepción. La clase ComputeEngine
maneja la excepción dentro de los bloques try/catch. Si la excepción no fuese manejada de esta manera,
tendríamos que añadir RemoteException a la clausula throws (ahora inexistente) del método main.

Observemos lo siguiente sobre los argumentos de la llamada a Naming.rebind.

● El primer parámetro es un java.lang.String formateado como URL representando la localización y el nombre del objeto
remoto.
❍ Podríamos necesitar cambiar el valor de localhost por el nombre o dirección IP de nuestro servidor. Si se omite el
Host en la URL, el host por defecto es el host local. Tampoco necesitamos especificar el protocolo, Por ejemplo,
está permitido suministrar "Compute" como el nombre en la llamada a Naming.rebind.
❍ Opcionalmente se puede suministar un número de puerto en la URL, por ejemplo el nombre
"//host:1234/objectname" es legal. Si se omite el puerto, por defecto se toma el 1099. Debemos especificar el
puerto si un servidor crea un registro en otro puerto que no sea el 1099. El puerto por defecto es útil porque
proporciona un lugar bien conocido para buscar los objetos remotos que ofrecen servicios en un host particular.
● El sistema RMI susituye una referencia al stub por la referencia real al objeto especificado en el argumento. La
implementación de objetos remotos como ejemplares de ComputeEngine nunca abandonan la máquina virtual en que se
crearon, por eso, cuando un cliente realiza un búsqueda en el registro de objetos remotos del servidor, se le devuelve una
referencia al stub. Como se explicó anteriormente, los objetos remotos en dichos casos se pasan por referencia, no por
valor.
● Obsevemos que por razones de seguridad, una aplicación puede entregar o eliminar referencias a objetos remotos sólo
en un registro que se ejecute en el mismo host. Esta restricción evita que un cliente remoto elimine o sobreesciba
cualquier entrada en el registro del servidor.
Una vez que el servidor se ha registrado en el registro RMI local, imprime un mensaje indicando que está listo para
empezar a manejar llamadas, y sale del método main. No es necesario tener un thread esperando para mantener
vivo el servidor. Siempre que haya una referencia al objeto ComputeEngine en algún lugar de la máquina virtual
(local o remota) el objeto ComputeEngine no será eliminado. Como el programa entrega una referencia de
ComputeEngine en el registro, éste es alcanzable por un cliente remoto (¡el propio registro!). El sistema RMI tiene
cuidado de mantener vivo el proceso ComputeEngine. El ComputeEngine está disponible para aceptar llamadas y
no será reclamado hasta que.
● su nombre sea eliminado del registro, y
● ningún cliente remoto mantenga una referencia al objeto ComputeEngine.
La pieza final de código del método ComputeEngine.main maneja cualquier excepción que pudiera producirse. La
única excepción que podría ser lanzada en el código es RemoteException, que podría ser lanzada por el constructor
de la clase ComputeEngine o por la llamada al registro para entregar el nombre del objeto "Compute". En
cualquier caso, el programa no puede hacer nada más que salir e imprimir un mensaje de error. En algunas
aplicaciones distribuidas, es posible recuperar un fallo al hacer una llamada remota. Por ejemplo, la aplicación podría
elegir otro servidor y continuar con la operación.
 TutorJava recomienda...

Invocación Remota de Métodos (RMI)

En esta página:
● Crear un Programa Cliente

Crear un Programa Cliente

El motor de cálculo es un bonito y sencillo programa - ejecuta las tareas que le son enviadas. Los
clientes del motor de cálculo son más complejos. Un cliente necesita llamar al motor de cálculo, pero
también tiene que definir la tarea que éste va a realizar.

Nuestro ejemplo está compuesto por dos clases separadas. la primera clase ComputePi, busca y
llama a un objeto Compute. La segunda clase Pi, implementa el interface Task y define el trabajo
que va a hacer el motor de cálcilo. El trabajo de la clase Pi es calcular el valor del número pi, con
algún número de posiciones decimales.
Como recordaremos, el interface no-remoto Task se define de esta forma.

package compute;
public interface Task extends java.io.Serializable {
Object execute();
}
El interface Task extiende java.io.Serializable por lo que cualquier objeto que lo implemente
puede ser serializado por el sistema RMI y enviado a una máquina virtual remota como parte de una
llamada a un método remoto. Podríamos haber elegido hacer que la implementación de nuestra
clase implementara los interfaces Task y Serializable, y hubiera tenido el mismo efecto. Sin
embargo, el único proposito del interface Task es permitir que las implementaciones de este
interface sean pasadas a objetos Compute, por eso, una clase que implemente el interface Task no
tiene sentido que también implemente el interface Serializable. Dado esto, hemos asociado
explícitamente los dos interfaces en el tipo system, asegurando que todos los objetos Task sean
serializables.
El código que llama a los métodos del objeto Compute debe obtener una referencia a ese objeto,
crear un objeto Task, y luego pedir que se ejecute la tarea. Más adelante veremos la definición de la
tarea Pi. Un objeto Pi se construye con un sólo argumento, la precisión deseada en el resultado. El
resultado de la ejecución de la tarea es un java.math.BigDecimal que representa el número pi
calculado con la precisión especificada.
La clase cliente ComputePi.

package client;

import java.rmi.*;
import java.math.*;
import compute.*;

public class ComputePi {

public static void main(String args[]) {
if (System.getSecurityManager() == null) {
System.setSecurityManager(new RMISecurityManager());
}
try {
String name = "//" + args[0] + "/Compute";
Compute comp = (Compute) Naming.lookup(name);
Pi task = new Pi(Integer.parseInt(args[1]));
 BigDecimal pi = (BigDecimal) (comp.executeTask(task));
System.out.println(pi);
} catch (Exception e) {
System.err.println("ComputePi exception: " + e.getMessage());
e.printStackTrace();
}
}
}
Al igual que el servidor ComputeEngine, el cliente empieza instalando un controlador de seguridad.
Esto es necesario porque RMI podría descargar código en el cliente. En este ejemplo, el stub
ComputeEngine es descargado al cliente. Siempre que el RMI descargue código, debe presentarse
un controlador de seguridad. Al igual que el servidor, el cliente utiliza el controlador de seguridad
proporcionado por el sistema RMI para este propósito.

Después de llamar al controlador de seguridad, el cliente construye un nombre utilizado para buscar
un objeto remoto Compute. El valor del primer argumento de la línea de comandos args[0], es el
nombre del host remoto, en el que se están ejecutando los objetos Compute. Usando el método
Naming.lookup, el cliente busca el objeto remoto por su nombre en el registro del host remoto.
Cuando se hace la búsqueda del nombre, el código crea una URL que específica el host donde se
está ejecutando el servidor. El nombre pasado en la llamada a Naming.lookup tiene la misma
síntaxis URL que el nombre pasado a la llamada Naming.rebind que explícamos en páginas
anteriores.
Luego, el cliente crea un objeto Pi pasando al constructor de Pi el segundo argumento de la línea de
comandos, args[1], que indica el número de decimales utilizados en el cálculo. Finalmente, el
cliente llama al método executeTask del objeto remoto Compute. El objeto pasado en la llamada a
executeTask devuelve un objeto del tipo java.math.BigDecimal, por eso el programa fuerza el
resultado a ese tipo y almacena en resultado en la variable result. Finalmente el programa imprime
el resultado.

Flujo de mensajes entre el cliente ComputePi, el rmiregistry, y el ComputeEngine.

Finalmente, echemos un vistazo a la clase Pi. Esta clase implementa el interface Task y cálcula el
valor del número pi con un número de decimales especificado. Desde el punto de vista de este
ejemplo, el algoritmo real no es importante (excepto, por supuesto, para la fiabilidad del cálculo).
Todo lo importante es que el cálculo consume numéricamene muchos recursos (y por eso es el tipo
que cosa que querríamos hacer en un servidor potente).

Aquí tenemos el código de la clase Pi, que implementa Task.

package client;
import compute.*;
import java.math.*;

public class Pi implements Task {

/** constantes utilizadas en el cálculo de pi*/

private static final BigDecimal ZERO =
BigDecimal.valueOf(0);
private static final BigDecimal ONE =
BigDecimal.valueOf(1);
private static final BigDecimal FOUR =
BigDecimal.valueOf(4);

/** modo de redondeo utilizado durante el cálculo*/

private static final int roundingMode =
BigDecimal.ROUND_HALF_EVEN;

/** número de dígitos tras el punto decimal*/

private int digits;
 /**
* Construye una tarea para calcular el núemro pi
* con la precisión específicada.
*/
public Pi(int digits) {
this.digits = digits;
}

/**
* Calcula pi.
*/
public Object execute() {
return computePi(digits);
}

/**
* Calcula el valor de Pi con el número de decimales especificados.
* El valor se calcula utilizando la fórmula de Machin.
*
* pi/4 = 4*arctan(1/5) - arctan(1/239)
*
* y una poderoas serie de expansiones de arctan(x)
* para una precisión suficiente.
*/
public static BigDecimal computePi(int digits) {
int scale = digits + 5;
BigDecimal arctan1_5 = arctan(5, scale);
BigDecimal arctan1_239 = arctan(239, scale);
BigDecimal pi =
arctan1_5.multiply(FOUR).subtract(arctan1_239).multiply(FOUR);
return pi.setScale(digits,
BigDecimal.ROUND_HALF_UP);
}

/**
* Calcula el valor, en radianes, de la arcotangente de la
* inversa del entero suministrado para el número de decimales.
* El valor se calcula utilizando la poderosa serie de
* expansiones de arcotangente.
*
* arctan(x) = x - (x^3)/3 + (x^5)/5 - (x^7)/7 +
* (x^9)/9 ...
*/
public static BigDecimal arctan(int inverseX,
int scale)
{
BigDecimal result, numer, term;
BigDecimal invX = BigDecimal.valueOf(inverseX);
BigDecimal invX2 =
BigDecimal.valueOf(inverseX * inverseX);

numer = ONE.divide(invX, scale, roundingMode);

result = numer;
int i = 1;
do {
numer =
numer.divide(invX2, scale, roundingMode);
int denom = 2 * i + 1;
term =
numer.divide(BigDecimal.valueOf(denom),
 scale, roundingMode);
if ((i % 2) != 0) {
result = result.subtract(term);
} else {
result = result.add(term);
}
i++;
} while (term.compareTo(ZERO) != 0);
return result;
}
}
La característica más interesante de este ejemplo es que el objeto Compute no necesita una
definición de la clase Pi hasta que se le pasa un objeto Pi como un argumento del método
executeTask. Hasta este punto, el código de la clase se ha cargado por el RMI dentro de la
máquina virtual del objeto Compute, se ha llamado al método execute, y se ha ejecutado el código
de la tarea. El Object resultante (que en el caso de la tarea Pi es realmente un objeto
java.math.BigDecimal) es enviado de vuelta al cliente, donde se utiliza para imprimir el resultado.

El hecho de que el objeto Task suministrado calcule el valor de Pi es irrelevante para el objeto
ComputeEngine. Por ejemplo, también podríamos implementar una tarea que generara un número
primo aleatorio utilizando un algoritmo probabilistico. (Esto también consume muchos recursos y por
tanto es un candidato para ser enviado al ComputeEngine). Este código también podría ser
descargado cuando el objeto Task fuera pasado al objeto Compute. Todo lo que el objeto
Compute sabe es que cada objeto que recibe implementa el método execute, no sabe (y tampoco
le interesa) qué hace la implementación.
 TutorJava recomienda...

Invocación Remota de Métodos (RMI)

En esta página:
● Compilar el Ejemplo
❍ Construir un Fichero JAR con las Clases de Interfaces
❍ Construir las Clases del Servidor
❍ Construir las clases del Cliente

Compilar el Ejemplo
En un escenario del mundo real donde se desarrollara un servicio como el del motor de cálculo, un
desarrollador querría crear un fichero JAR que contenga los interfaces Compute y Task para que
los implementan las clases servidor y para que los utilicen los programas clientes.

Luego, un desarrollador (quizás el mismo que creo el fichero JAR con los interfaces) escribiría una
implementación del interface Compute y desarrollaría ese servicio en una máquina disponible para
los clientes.

Los desarrolladores de los programas clientes pueden utilizar los interfaces Compute y Task
(contenidos en el fichero JAR) e independientemente desarrollar una tarea y un programa cliente
que utilice un servicio Compute.

En esta página, aprenderemos cómo crear un fichero JAR, las clases del servidor, y las clases del
cliente. Veremos como la clase Pi será descargada al servidor durante la ejecución. También
veremos como el stub remoto ComputeEngine será descargado desde el servidor hasta el cliente
durante la ejecución.
El ejemplo separa los interfaces, la implementación de los objetos remotos y el código del cliente en
tres paquetes diferentes.
● compute (Los interfaces Compute y Task)
● engine (Implementación de la clase, el interface y el stub de ComputeEngine)
● client (la implementación del cliente ComputePi y de la tarea Pi)
Primero construiremos el fichero JAR para proporcionar los interfaces del servidor y del cliente a los
desarrolladores.

Construir un Fichero JAR con las Clases de Interfaces

Primero necesitamos compilar los ficheros fuente de los interfaces del paquete compute que
construir un fichero JAR que contenga los ficheros class. Supongamos que el usuario waldo ha
escrito estos interfaces particulares y ha situado los ficheros fuente en
c:\home\waldo\src\compute (en UNIX sería, /home/waldo/src/compute). Con estos paths
podemos utilizar los siguientes comandos para compilar los intefaces y crear el fichero JAR.
Detalles específicos de la Plataforma: Construir un Fichero JAR

Windows.

cd c:\home\waldo\src
javac compute\Compute.java
javac compute\Task.java
jar cvf compute.jar compute\*.class

UNIX.

cd /home/waldo/src
javac compute/Compute.java
javac compute/Task.java
jar cvf compute.jar compute/*.class

El comando jar muestra la siguiente salida (debido a la opción -v).

added manifest
adding: compute/Compute.class (in=281) (out=196)
(deflated 30%)
adding: compute/Task.class (in=200) (out=164)
(deflated 18%)

Ahora podemos distribuir el fichero compute.jar a los desarrolladores de las aplicaciones del cliente
y del servidor para que puedan hacer uso de los interfaces.
En general, cuando cosntruimos las clases del servidor o del cliente con los compiladores javac y
rmic, necesitaremos especificar donde deberían residir los ficheros de clase resultantes para que
sean accesibles a la red. En este ejemplo, esta localización es, para Unix,
/home/user/public_html/classes porque algunos servidores web permiten el acceso a
public_html mediante una URL HTTP construida como http://host/~user/. Si nuestro servidor
web no soporta esta convención, podríamos utilizar un fichero URL en su lugar. El fichero de URL
toma la forma file:/home/user/public_html/classes/ en UNIX, o
file:/c:\home\user\public_html\classes/ en Windows. También se puede seleccionar otro tipo
de URL apropiado.
La accesibilidad en la red de los ficheros de clases permite al sistema RMI descargar código cuando
sea necesario. En vez de definir su propio protocolo para descargar código, RMI utiliza un protocolo
URL soportado por Java (por ejemplo, HTTP) para descargar el código. Observa que un servidor web
completo y poderoso no necesita realizar esta descarga de fichero class. De hecho, un sencillo
servidor HTTP proporciona toda la funcionalidad necesaria para hacer que las clases estén
disponibles para su descarga en RMI mediante HTTP, puedes encontrar uno en.

ftp://java.sun.com/pub/jdk1.1/rmi/class-server.zip
Construir las Clases del Servidor
El paquete engine sólo contiene la implementación de la clase del lado del servidor,
ComputeEngine, la implementación del objeto remoto del interface Compute. Como
ComputeEngine es una implementación de un interface remoto, necesitamos generar un stub para
el objeto remoto para que los clientes puedan contactar con él.
Digamos que, ana, la desarrolladora de la clase ComputeEngine, ha situado
ComputeEngine.java en el directorio c:\home\ana\src\engine, y ha colocado el fichero class
para que lo usen los clientes en un subdirectorio de su directorio public_html,
c:\home\ana\public_html\classes (en UNIX podría ser /home/ana/public_html/classes,
accesible mendiante algún servidor web como http://host/~ana/classes/).

Asumamos que el fichero compute.jar esta localizado en el directorio

c:\home\ana\public_html\classes. Para compilar la clase ComputeEngine, nuestro path de
clases debe incluir el fichero compute.jar y el propio directorio fuente.
Una nota sobre el path de clases:

Normalmente, recomendamos seleccionar el path de clases en la linea de comandos utilizando la

opción -classpath. Sin embargo, por varias razones, este ejemplo utiliza la variable de entorno
CLASSPATH (porque tanto javac como rmic necesitan un path de clases y la opción -classpath
se trata de forma diferente en el JDK 1.1 y el JDK 1.2). Recomendamos que no selecciones el
CLASSPATH en un fichero de login o de arranque y que los desactives después de haber
terminado con este ejemplo.

Para más información sobre CLASSPATH puedes visitar

http://java.sun.com/products/jdk/1.2/docs/install.html

Aquí podemos ver cómo seleccionar la variable de entorno CLASSPATH.

Detalles Específicos de la Plataforma: Selecionar el CLASSPATH

Windows.

set CLASSPATH=c:\home\ana\src;c:\home\ana\public_html\classes\compute.jar

Unix:

setenv CLASSPATH /home/ana/src:/home/ana/public_html/classes/compute.jar

Ahora compilamos el fichero fuente ComputeEngine.java y generamos un stub para la clase

ComputeEngine y coloca el stub accesible a la red. Para crear el stub (y opcionalmente los ficheros
esqueleto) ejecutamos el compilador rmic sobre los nombres totalmente cualificados de las clases
de implementación de los objetos remotos que deberían encontrarse en el path de clases. El
comando rmic toma uno o más nombres de clase como entrada y produce, como salida, ficheros de
clases con la forma ClassName_Stub.class (y opcionalmente ClassName_Skel.class). El fichero
esqueleto no será generado si llamamos a rmic con la opción -v1.2. Esta opción sólo debería
utilizarse si todos nuestros clientes van a utilizar el JDK 1.2 o posterior.
Detalles Específicos de la Plataforma: Compilar el Motor de Cálculo y sus Stubs

Windows.

cd c:\home\ana\src
javac engine\ComputeEngine.java
rmic -d . engine.ComputeEngine
mkdir c:\home\ana\public_html\classes\engine
cp engine\ComputeEngine_*.class
c:\home\ana\public_html\classes\engine

Unix.

cd /home/ana/src
javac engine/ComputeEngine.java
rmic -d . engine.ComputeEngine
mkdir /home/ana/public_html/classes/engine
cp engine/ComputeEngine_*.class
/home/ana/public_html/classes/engine

La opción -d le dice al compilador rmic que situe los ficheros de clases generados,
ComputeEngine_Stub y ComputeEngine_Skel, en el directorio c:\home\ana\src\engine.
También necesitamos poner estos ficheros accesibles en la red, por eso debemos copiarlos en el
área public_html\classes.

Como el stub de ComputeEngine implementa el interface Compute, que referencia al interface

Task, también necesitamos poner estas clases disponibles en la red. Por eso, el paso final es
desempaquetar el fichero compute.jar en el directorio c:\home\ann\public_html\classes para
hacer que los interfaces Compute y Task estén disponibles para su descarga.
Detalles Específicos de la Plataforma: Desempaquetar el Fichero JAR

Windows.

cd c:\home\ana\public_html\classes
jar xvf compute.jar

Unix.

cd /home/ana/public_html/classes
jar xvf compute.jar

El comando jar muestra esta salida.

created: META-INF/
extracted: META-INF/MANIFEST.MF
extracted: compute/Compute.class
extracted: compute/Task.class

Construir las clases del Cliente

Asumamos que el usuario jones ha creado el código del cliente en el directorio
c:\home\jones\src\client y colocará la clase Pi (para que sea descargada por el motor de
cálculo) en el directorio accesible a la red c:\home\jones\public_html\classes (también
disponible mediante algunos servidores como http://host/~jones/classes/). Las dos clases del
lado del cliente están contenidas en los ficheros Pi.java y ComputePi.java en el subdirectorio
client.

Para construir el código del cliente, necesitamos el fichero compute.jar que contiene los interfaces
Compute y Task que utiliza el cliente. Digamos que el fichero compute.jar está situado en
c:\home\jones\public_html\classes. Las clases del cliente se pueden construir así.
Detalles Específicos de la Plataforma: Compilar el Cliente
Windows:

set CLASSPATH=c:\home\jones\src;c:\home\jones\public_html\classes\compute.jar
cd c:\home\jones\src
javac client\ComputePi.java
javac -d c:\home\jones\public_html\classes client\Pi.java

UNIX.

setenv CLASSPATH /home/jones/src:/home/jones/public_html/classes/compute.jar

cd /home/jones/src
javac client/ComputePi.java
javac -d /home/jones/public_html/classes client/Pi.java

Sólo necesitamos situar la clase Pi en el directorio public_html\classes\client (el directorio

client lo crea el javac si no existe). Esto es así por esta clase es la única que necesita ser
desacargada por la máquina virtual del motor de cálculo.
Ahora podemos ejecutar el servidor y luego el cliente.
 TutorJava recomienda...

Invocación Remota de Métodos (RMI)

En esta página:
● Ejecutar el Ejemplo
❍ Una Nota sobre la Seguridad
❍ Arrancar el Servidor
❍ Arrancar el Cliente

Ejecutar el Ejemplo
Una Nota sobre la Seguridad
El modelo de seguridad del JDK 1.2 es más sofisticado que el modelo utilizado en el JDK 1.1.
Contiene ampliaciones para seguridad de grano fino y requiere código que permita los permisos
específicos para realizar ciertas operaciones.

En el JDK 1.1, todo el código que haya en el path de clases se considera firmado y puede realizar
cualquier operación, el código descargado está gobernado por las reglas del controlador de
seguridad instalado. Si ejecutamos este ejemplo en el JDK 1.2 necesitaremos especificar un fichero
de policía cuando ejecutemos el servidor y el cliente. Aquí tenemos un fichero de policía general que
permite al código descargado desde cualquier codebase, hacer dos cosas.
● conectar o acceptar conexiones en puertos no privilegiados (puertos por encima del 1024) de
cualquier host, y
● conectar con el puerto 80 (el puerto HTTP).

grant {
permission java.net.SocketPermission "*:1024-65535",
"connect,accept";
permission java.net.SocketPermission "*:80", "connect";
};
Si hacemos nuestro código disponible mediante URLs HTTP, deberíamos ejecutar el fichero de
policía anterior cuando ejecutemos este ejemplo. Sin embargo, si utilizarámos un fichero de URLs
en su lugar, podemos utilizar el fichero de policía siguiente. Observa que en entornos windows, la
barra invertida necesita ser representada con dos barras invertidas en el fichero de policía.

grant {
permission java.net.SocketPermission "*:1024-65535",
"connect,accept";
permission java.io.FilePermission
"c:\\home\\ana\\public_html\\classes\\-", "read";
permission java.io.FilePermission
"c:\\home\\jones\\public_html\\classes\\-", "read";
};
Este ejemplo asume que el fichero de policía se llama java.policy y contiene los permisos
apropiados. Si ejecutamos este ejemplo en el JDK 1.1, no necesitamos un fichero de policía ya que
el RMISecurityManager proporciona toda la protección que necesitamos.

Arrancar el Servidor
Antes de arrancar el motor de cálculo, necesitamos arrancar el registro de RMI con el comando
rmiregistry. Como explicamos en páginas anteriores el registro RMI es una facilidad de nombrado
que permite a los clientes obtener una referencia a un objeto remoto.
Observa que antes de arrancar el rmiregistry, debemos asegurarnos de que el shell o ventana en
la que ejecutaremos rmiregistry no tiene la variable de entorno CLASSPATH, o si la tiene ésta no
incluye el path a ninguna clase, incluyendo los stubs de nuestras clases de implementación de los
objetos remotos, que querramos descargar a los clientes de nuestros objetos remotos.
Si arrancamos el rmiregistry y éste puede encontrar nuestras clases stub en el CLASSPATH, no
recordará que las clases stub cargadas pueden ser cargadas desde el codebase de nuestro servidor
(que fue especificado por la propiedad java.rmi.server.codebase cuando se arrancó la aplicación
servidor). Como resultado, el rmiregistry no enviará a los clientes un codebase asociado con las
clases stub, y consecuentemente, nuestros clientes no podrán localizar y cargar las clases stub (u
otras clases del lado del servidor).

Para arrancar el registro en el servidor, se ejecuta el comando rmiregistry. Este comando no

produce ninguna salida y normalmente se ejecuta en segundo plano.
Detalles Específicos de la Plataforma: Arrancar el Registro en el Puerto por Defecto

Windows (utilizar javaw si no está disponible start).

unset CLASSPATH
start rmiregistry

UNIX.

unsetenv CLASSPATH
rmiregistry &

Por defecto el registro se ejecuta sobre el puerto 1099. Para arrancar el registro sobre un puerto
diferente, se especifica el número de puerto en la línea de comandos. No olvidemos borrar el
CLASSPATH.
Detalles Específicos de la Plataforma: Arrancar el Registro en el Puerto 2001

Windows.

start rmiregistry 2001

UNIX.

rmiregistry 2001 &

Una vez arrancado el registro, podemos arrancar el servidor. Primero, necesitamos asegurarnos de
que el fichero compute.jar y la implementación del objeto remoto (que es lo que vamos a
arrancar) están en nuestro path de clases.
Detalles Específicos de la Plataforma - Seleccionar la variable CLASSPATH

Windows.

set CLASSPATH=c:\home\ana\src;c:\home\ana\public_html\classes\compute.jar

Unix.

setenv CLASSPATH /home/ana/src:/home/ana/public_html/classes/compute.jar

Cuando arrancamos el motor de cálculo, necesitamos especificar, utilizando la propiedad

java.rmi.server.codebase, donde están disponibles las clases del servidor. En este ejemplo, las
clases del lado del servidor disponibles son el stub de ComputeEngine y los interfaces Compute y
Task disponibles en el directorio public_html\classes de ana.
Detalles Específicos de la Plataforma: Arrancar el Motor de Cálculo

Windows.

java -Djava.rmi.server.codebase=file:/c:\home\ana\public_html\classes/
-Djava.rmi.server.hostname=zaphod.east.sun.com
-Djava.security.policy=java.policy
engine.ComputeEngine

UNIX.

java -Djava.rmi.server.codebase=http://zaphod/~ana/classes/
-Djava.rmi.server.hostname=zaphod.east.sun.com
-Djava.security.policy=java.policy
engine.ComputeEngine
El comando java anterior define varias propiedades.
● java.rmi.server.codebase, una propiedad que especifica una localización, una URL codebase, de las
clases originarias desde este servidor para que la información de las clases enviadas a otras máquinas
virtuales incluya la localización de la clase que el receptor pueda descargar. Si el codebase especifica
un directorio (como oposición a un fichero JAR), debemos incluir la barra inclinada en la URL.
● java.rmi.server.hostname, una propiedad que indica el nombre totalmente cualificado de nuestro
servidor. En algunos entornos de red, el nombre totalmente cualificado del host no se puede obtener
utilizando el API de Java. RMI hace el mejor esfuerzo para obtener ese nombre. Si uno de ellos no
puede ser determinado, fallará y utilizará la dirección IP. Para asegurarnos de que el RMI utilizará un
nombre de Host, podríamos seleccionar la propiedad java.rmi.server.hostname como medida de
seguridad.
● java.security.policy, una propiedad utilizada para especificar el fichero de policía que contiene los
permisos concedidos a los codebases específicados.
La clase stub de ComputeEngine se carga dinámicamente en la máquina virtual del cliente sólo
cuando la clase no está disponible localmente y la propiedad java.rmi.server.codebase ha sido
configurada apropiadamente, para la localización de la clase stub, cuando se arrancó el servidor.
Una vez cargada la clase stub no necesitamos recargarla más veces para referencias adicionales a
objetos ComputeEngine.

Arrancar el Cliente
Una vez que el registro y el motor se están ejecutando, podemos arrancar el cliente, especificando.
● la localización donde el cliente sirve sus clases (la clase Pi) utilizando la propiedad
java.rmi.server.codebase.
● como argumentos de la línea de comandos, el nombre del host (para que el cliente sepa donde
localizar el objeto remoto) y el número de decimales utilizado en el cálculo del número Pi.
● java.security.policy, una propiedad utilizada para especificar el fichero de policía que contiene los
permisos adecuados.
Primero seleccionamos el CLASSPATH para ver el cliente de jones y el fichero JAR que contiene los
interfaces. Luego se arranca el cliente de esta forma.
Detalles Específicos de la Plataforma: Arrancar el Cliente

Windows.

set CLASSPATH c:\home\jones\src;c:\home\jones\public_html\classes\compute.jar

java -Djava.rmi.server.codebase=file:/c:\home\jones\public_html\classes/
-Djava.security.policy=java.policy
client.ComputePi localhost 20

UNIX.

setenv CLASSAPTH /home/jones/src:/home/jones/public_html/classes/compute.jar

java -Djava.rmi.server.codebase=http://ford/~jones/classes/
-Djava.security.policy=java.policy
client.ComputePi zaphod.east.sun.com 20

Después de arrancar el cliente, deberíamos ver la siguiente salida en nuesta pantalla.

3.14159265358979323846
La siguiente figura muestra de dónde obtienen las clases el rmiregistry, el servidor
ComputeEngine y el cliente ComputePi durante la ejecución del programa.

Cuando el servidor ComputeEngine coloca su referencia al objeto remoto en el registro, éste

descarga el ComputeEngine_Stub, y también los interfaces Compute y Task de los que la clase
stub depende. Estas clases son descargadas del servidor web del ComputeEngine (o del sistema
de ficheros, dado el caso).
El cliente ComputePi también carga ComputeEngine_Stub, desde el servidor web de
ComputeEngine, como resultado de la llamada a Naming.lookup. Como el cliente tiene los dos
intefaces disponibles en su path de clases, estas clases son cargadas desde allí, no de la localización
remota.
Finalmente, la clase Pi se carga en la máquina virtual de ComputeEngine cuado el objeto Pi es
pasado en la llamada al método remoto executeTask del objeto ComputeEngine. La clase Pi se
carga desde la página web del cliente.