INTRODUCCIÓN El uso de sockets permite la elaboración de aplicaciones distribuidas. Sin embargo, en ocasiones, son necesarios enfoques con un mayor grado de abstracción 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 complicación que esto conlleva. La API RMI (Remote Method Invacation) proporciona un mecanismo para facilitar la elaboración de aplicaciones distribuidas. Integrado dentro de la jerarquía de paquetes oficiales del lenguaje de programación Java, se adapta perfectamente al modelo de programación de dicho lenguaje.
3.1 Características y Estructura de RMI En el modelo de objetos distribuidos de Java, un objeto distribuido distribuido es aquel cuyos métodos pueden llamarse desde otra Máquina Virtual Java (JVM), que puede estar ejecutándose en otro host. Por lo tanto, un objeto remoto ubicado en un proceso puede recibir llamadas desde otros procesos que se estén ejecutando en diferentes espacios de direcciones (es decir, en diferentes máquinas). Una clase remota es cualquier clase cuyas instancias son objetos remotos. Desde el punto de vista de la máquina virtual que crea instancias de objetos remotos, éstos son objetos ``normales''. Se podrán usar como cualquier otro objeto. Una llamada remota a método es una llamada a un método 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 característica adicional del modelo de objetos remotos de Java es la utilización de interfaces para la manipulación 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 métodos de un objeto remoto. El uso de interfaces remotas proporciona una serie de ventajas, como son: las implementaciones de los métodos no son visibles por los clientes y no hace falta comunicar a los clientes cambios realizados en las implementaciones de los métodos. Es común 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 comunicación entre procesos.[ procesos. [6] La figura 3.1 muestra este concepto.
Figura: Representación lógica del middleware
Típicamente, una aplicación 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 búsqueda por nombres propia de RMI, rmiregistry . Comunicar con los objetos remotos.- Los detalles de la comunicación entre objetos remotos quedan a cargo de RMI. Para el programador, la invocación remota de métodos es como la estándar. Cargar el código de las clases para los objetos remotos.- RMI permite no sólo el paso de objetos completos hacia y desde los procesos remotos sino, además, la descarga de las clases que implementan dichos objetos desde ubicaciones remotas.
En la práctica, la comunicación entre clientes y servidores no es directa, siempre media entre ambos unos elementos suplentes que se conocen como stub y skeleton . Un stub actúa 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 método de la interfaz remota de un objeto, esta llamada se realiza en realidad sobre los métodos del stub local, desde donde se transmite hasta el objeto remoto. Por lo tanto, no hay comunicación directa entre objetos locales y remotos sino que se realiza a través de los elementos suplentes. El stub se encarga de realizar la conexión con la máquina virtual remota, enviar los argumentos para el método especificado, esperar la respuesta y pasársela al objeto local. El skeleton es la contrapartida del stub, es decir, actúa 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 petición. En las versiones actuales del JDK ( Java Development Kit) no es necesaria la utilización 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 comunicación directa entre objetos que residen en máquinas virtuales diferentes, se necesitan suplentes que lo permitan, y estos suplentes son el stub y skeleton. La referencia remota contendrá la dirección IP del servidor, un puerto, un identificador del objeto remoto y una interfaz remota. Ambos, stub y skeleton , deberán implementar las interfaces remotas de los objetos a los que están asociados. Tanto el stub como el skeleton utilizan el mecanismo de serialización para comunicarse con el objeto remoto. Mediante la serialización, toda la información que es necesaria intercambiar (objetos pasados como argumentos, ubicación de las clases de dichos objetos, etc.) es intercambiada como un flujo de bytes. RMI puede cargar dinámicamente nuevas clases basándose en la información recibida por la red. Esta información tiene forma de URL, puesto que hace referencia a recursos disponibles en distintas máquinas. Con este mecanismo se pueden localizar, en ubicaciones remotas, las clases necesarias para instanciar nuevos objetos en tiempo de ejecución.
Para poder cargar dinámicamente clases de máquinas remotas, RMI obliga a crear e instalar un gestor 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 gestor 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 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 parámetros. Estas restricciones aseguran que las operaciones realizadas por el código descargado cumple ciertos requisitos de seguridad. RMI proporciona un gestor de seguridad propio, RMISecurityManager . Una aplicación RMI también 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 más específicos. 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 operación completa de una llamada RMI.
Figura: Comunicación basada en RMI
Un objeto remoto en Java debe implementar la interfaz java.rmi.Remote que actúa como flag para que la máquina virtual lo reconozca como tal. El paso de argumentos y los valores de retorno que admiten los métodos remotos tiene las siguientes características:
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 máquina virtual a otra. Los objetos (no remotos) cuyas clases implementen la interfaz java.io.Serializable se pasan por valor. Los objetos remotos que estén a la espera de peticiones llegadas desde los clientes no se transmiten sino que, en su lugar, se envían las referencias remotas a los mismos (instancias de un stub). Por lo tanto, puede concluirse que se envían 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 programación Java, el paso de argumentos es sólo por valor, sean tipos primitivos u objetos. Cuando se utiliza la expresión 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 serialización 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. Además, se asegura que si un objeto contiene referencias a otros objetos, éstas se incluyen en sus copias.
3.2 El API Java RMI El uso de sockets permite la elaboración de aplicaciones distribuidas. Sin embargo, en ocasiones, son necesarios enfoques con un mayor grado de abstracción 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 complicación que esto conlleva.
La API RMI (Remote Method Invacation) proporciona un mecanismo para facilitar la elaboración de aplicaciones distribuidas. Integrado dentro de la jerarquía de paquetes oficiales del lenguaje de programación Java, se adapta perfectamente al modelo de programación de dicho lenguaje. La API RMI está formada por un conjunto de clases que se encuentran agrupadas en los siguientes paquetes:
java.rmi java.rmi.registry java.rmi.server java.rmi.activation java.rmi.dgc
La figura 3.7 muestra un esquema simplificado de la jerarquía de clases e interfaces del paquete java.rmi.
Figura: Clases e interfaces del paquete java.rmi
El paquete java.rmi
Este paquete proporciona la interfaz Remote y las clases MarshalledObject , Naming y RmiSecurityManager , junto con una serie de excepciones.
La interfaz Remote, que carece de métodos, debe ser implementada por toda clase remota para que sus métodos sean accesibles. Si no es así, Java no la reconocerá como tal. Mediante una instancia de la clase MarshalledObject se puede manejar el flujo de bytes serializados de un objeto. Sus métodos son usados internamente por RMI. La clase Naming proporciona métodos para obtener y almacenar referencias de los objetos remotos mediante URLs. Sus métodos más habituales son:
public static void bind(String name, Remote object) throws AlreadyBoundException,MalformedURLException,RemoteExceptio n public static void rebind(String name, Remote object) throws RemoteException, MalformedURLException public static void lookup(String name) throws NotBoundException,MalformedURLException,RemoteException
El método bind() asocia un nombre a un objeto remoto mediante una URL, es decir, lo registra. En consecuencia, ese nombre se utiliza para localizar el objeto. Las URL's son de la forma: rmi://host:port/remote_object_name
Si la especificación dada en la URL no es correcta, se producirá una excepción del tipo MalformedURLException. El host y el puerto son opcionales, de manera que si no se incluyen se toma el host local y el puerto por defecto asociados al servicio de registro RMI. El código que registra un objeto remoto en el rmiregistry , típicamente, tiene la forma siguiente: myClass myInstance=new myClass(); Naming.bind("rmi://host:port/name,myInstance");
Este código registra una instancia de la clase myClass en el rmiregistry mediante la URL especificada. La diferencia entre rebind() y bind() radica en el hecho de que el primero permite asociar un nuevo nombre a un objeto ya registrado, cambiando el actual, mientras que el segundo ocasionaría una excepción del tipo AlreadyBoundException.
Por otro lado, el método lookup() devuelve una referencia al objeto remoto especificado en la URL. De esta forma un proceso local puede determinar qué host está proporcionando el servicio buscado y dónde se ubica el objeto remoto. Esta referencia remota se obtiene en forma de stub, de manera que se podrán abrir conexiones hacia el host y puerto que especifica el stub y llamar a los métodos remotos del objeto. Una llamada típica a lookup() sería de la forma: myClass myInstance= (myClass)Naming.lookup("rmi://host:port/remote_object_name");
Por último, la clase RMISecurityManager proporciona un gestor de seguridad para las aplicaciones que utilizan código descargado desde un servidor. El paquete java.rmi.registry
Este paquete proporciona las interfaces Registry y RegistryHandler , así como la clase LocateRegistry . La interfaz Registry define los métodos bind(), rebind(), y lookup() (así como otros que no hemos comentado como son unbind() y list()) de la clase Naming. Por último, la clase LocateRegistry permite recuperar y, por tanto, manejar objetos Registry , que representan a los procesos que ejecutan el servicio de registro RMI, a partir de un par host-puerto. También permite crear estos objetos a partir de un puerto o puertos y, si se desea, factorías de sockets RMI. Las factorías de sockets permiten establecer características comunes a los sockets que se quieren crear en una aplicación determinada. El paquete java.rmi.server
Este paquete proporciona una serie de clases, interfaces y excepciones para el lado servidor de las aplicaciones RMI. Algunas de sus clases principales son:
Clase ObjID.- Genera identificadores de objetos que los hosts
declaran como remotos, proporcionando métodos para la creación
de los mismos, lectura de éstos desde flujos de bytes e inserción en ellos. Estos identificadores son los propios de un objeto remoto en una referencia remota. Clase RemoteObject .- Implementa la clase java.lang.Object (clase raíz de todas las clases Java) para objetos remotos y la interfaz java.rmi.Remote. Clase RemoteServer .- Hereda de RemoteObject. Es la clase raíz de la que heredan todas las implementaciones de objetos cuyos métodos son accesibles remotamente, y proporciona la semántica básica para el manejo de referencias remotas. Clase RemoteStub.- Hereda de RemoteObject. Es la clase raíz de la que heredan todos los stubs de los clientes. Clase RMIClassLoader .- Incluye métodos estáticos para permitir la carga dinámica de clases remotas. Si un cliente o servidor de una aplicación RMI necesita cargar una clase desde un host remoto, llama a esta clase. Clase RMISocketFatory .- Usada por RMI para obtener sockets cliente y servidor para las llamadas RMI. Clase UnicastRemoteObject.- Subclase de RemoteServer . Incluye la implementación por defecto de los objetos remotos. Permite llamar a los métodos remotos mediante conexiones TCP por el puerto especificado. Si se necesitan objetos remotos con un funcionamiento más específico, se puede extender esta clase para lograrlo. Una clase que herede de UnicastRemoteObject debe incluir un constructor que soporte excepciones del tipo RemoteException.
Algunas de sus principales interfaces son:
Interfaz RemoteRef .- Usada por los objetos RemoteStub para
referirse a objetos remotos. Incluye métodos para llamar a los métodos de objetos remotos. Interfaz RMIClientSocketFactory .- Usada por RMI para obtener sockets clientes para las llamadas RMI. Interfaz RMIFailureHandler .- Especifica los métodos que se encargan de manejar los fallos derivados de la creación de ServerSockets. Interfaz RMIServerSocketFactory .- Usada por RMI para obtener sockets servidores para las llamadas RMI.
Interfaz ServerRef .- Extiende la interfaz RemoteRef y es
implementada por los objetos remotos para poder acceder a sus objetos RemoteStub. Interfaz Unreferenced .- Usada para que los objetos remotos puedan recibir mensajes de aviso cuando no existan más clientes con referencias a ellos.
El paquete java.rmi.activation
Permite activar remotamente objetos, desactivarlos cuando ya no se trabaje con ellos y reactivarlos cuando sea necesario. Entre activación y desactivación, conservan su estado.
3.3 Jerarquía 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 métodos como si fueran locales. Capa de referencias remotas.- Esta capa se encarga de la creación y gestión de las referencias a objetos remotos, manteniendo para ello una tabla de objetos distribuidos. Además, 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.4 El sistema de nombrado Registry RMI necesita un servicio de registro de nombres para permitir que los clientes encuentren los objetos remotos. Para ello proporciona un servicio de registro propio, implementado por la aplicación rmiregistry . El servicio de registro de RMI, debe estar en funcionamiento antes que los clientes y servidores. Si no es así, los clientes no pueden encontrar los objetos remotos ni los servidores pueden atender sus peticiones. Destacar que el servicio de registro de RMI no admite persistencia, es decir, la información de registro se pierde al reiniciar la aplicación rmiregistry . Al ejecutar rmiregistry , se activa un proceso que escucha en un puerto TCP específico. Para que un cliente pueda acceder a los servicios remotos ofrecidos por un servidor, éste deberá registrarlos previamente en el rmiregistry , asociándoles un nombre lógico. El rmiregistry actúa, en consecuencia, como un servidor DNS, de manera que a las búsquedas por nombre de los clientes, devuelva los stubs asociados al servicio. La figura 3.5 muestra cómo se realiza una llamada remota en RMI utilizando el servicio de registro.
Por otro lado, en la figura 3.6 se muestra en detalle el proceso de una llamada RMI[6]. La secuencia completa es la siguiente: 1. Se ejecuta el servidor de registro RMI, rmiregistry , en la máquina que contendrá al objeto servidor. Una vez activo, permanece a la espera de peticiones utilizando un socket de servidor. 2. Se crea un objeto en el servidor, se exporta (es decir, se deja preparado para admitir llamadas a sus métodos por un determinado puerto) y se registra en el servicio de registro RMI con un nombre. Al registrarse se crea una instancia del skeleton, que permanece a la escucha usando un socket de servidor asociado al puerto por el que el objeto se ha hecho accesible. 3. Se crea el objeto cliente, que llamará a un método de la interfaz del objeto remoto. 4. El servidor de registro envía al proceso cliente una referencia remota al objeto ( stub) como un flujo de bytes serializado que el cliente utiliza para crear una instancia de éste. Este stub contiene la dirección IP del host donde reside el objeto remoto, el número de puerto por el que escucha y un identificador del objeto. 5. El stub serializa los argumentos y envía a la capa de referencias remotas una petición de conexión, delegando en ella su envío. 6. La capa de referencias remotas indica a la capa de transporte que necesita abrir una conexión para enviarle el flujo de datos resultante de la serialización. 7. La capa de transporte crea un socket de cliente para enviar dicho flujo. 8. En el host remoto, los datos llegan a la capa de transporte y el socket servidor asociado los lee. 9. La capa de referencias remotas pasa los datos al skeleton. 10. El skeleton extrae del flujos de datos serializado los objetos incluidos y pasa la llamada al objeto remoto. 11. El objeto remoto ejecuta el método invocado con los argumentos proporcionados y, si corresponde, devuelve un valor al objeto skeleton . 12. El skeleton envía una petición de conexión a la capa de referencias remotas y delega en ella el envío de la respuesta. 13. La capa de referencias remotas serializa la respuesta y envía el flujo de bytes resultante a la capa de transporte, indicándole que necesita una conexión. 14. La capa de transporte remota abre un socket de cliente y envía la respuesta al host local.
15. Ésta llega a la capa de transporte del host local y allí un socket servidor lo transmite a la capa de referencias remotas. 16. La capa de referencias remotas extrae la información serializada y la envía al stub. 17. Finalmente, el stub envía el valor devuelto al objeto local.
Figura: Llamada remota en RMI
3.5 Desarrollo de aplicaciones distribuidas
omo se ha comentado a lo largo de este documento, una aplicación RMI típicamente está compuesta por un proceso servidor y otro cliente. Un proceso servidor crea una serie de objetos remotos, hace accesibles referencias a los mismos y queda a la espera de la invocación de sus métodos por parte de los clientes. Por otra parte, un cliente obtiene una referencia remota a algún objeto del servidor, e invoca sus métodos [13]. En este apartado veremos cómo se lleva este proceso a la práctica. Interfaces, objetos y métodos remotos
Una aplicación distribuida desarrollada utilizando RMI, como cualquier aplicación Java, está compuesta por interfaces y clases. Los interfaces definen métodos, mientras que las clases implementan los métodos definidos en los interfaces (también puede definir 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 desde máquinas virtuales localizadas en otros ordenadores, son los objetos remotos. Un objeto se convierte en remoto implementando un interfaz remoto, que tenga estas características.
Un interfaz remoto extiende a java.rmi.Remote. Cada método del interfaz debe soportar la excepción java.rmi.RemoteException, además de cualquier excepción específica de la aplicación.
El stub de un objeto remoto implementa el mismo conjunto de interfaces que el objeto. En consecuencia, y haciendo uso de las propiedades básicas del lenguaje de programación Java, como son la herencia y el polimorfismo, se permite la conversión de tipos del stub a cualquiera de esas interfaces. Un cliente podrá recibir siempre su stub aprovechando este mecanismo, que en la práctica se realizará a través de la interfaz Remote ya presentada. Además, sólo aquellos métodos definidos en una interfaz remota están disponibles para ser llamados en la máquina virtual destino, lo cual permite aislar a los objetos remotos y sólo hacerlos accesibles a determinados métodos. Diseñar e implementar los componentes de la aplicación distribuida
Podemos dividir la creación de una aplicación con objetos distribuidos RMI en una serie de pasos descritos en los apartados siguientes:
Diseñar e implementar los componentes de nuestra aplicación distribuida Compilar los fuentes y generar los stubs Hacer las clases accesibles a la red Arrancar la aplicación
Primero, decidimos la arquitectura de nuestra aplicación y determinamos qué componentes son objetos locales y cuáles accesibles remotamente. Este paso incluye:
Definir los interfaces remotos. Un interfaz remoto especifica los
métodos que pueden ser llamados remotamente por un cliente. 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. Para implementar un cliente que solicite servicio a un objeto remoto, de este último sólo es necesario conocer su interfaz. En el código del cliente se instancian las llamadas RMI a los objetos remotos mediante dichas interfaces.
* Compilar los fuentes y generar los stubs. Este es un proceso de dos pasos. En el primer paso, se compilan los ficheros fuentes de Java usando javac, los cuales contienen las implementaciones de los interfaces remotos y las clases del servidor y del cliente. En el segundo paso se utiliza el compilador rmic para crear los stubs de los objetos remotos. * Hacer accesibles las clases en la red.
Si se va a permitir que la aplicación descargue, en tiempo de ejecución, los ficheros de las clases Java asociadas a los interfaces remotos, los stubs, u otras clases que necesitemos; se deben hacen accesibles, por ejemplo, a través de un servidor web. El mecanismo que lo permite es la carga dinámica de clases, que será estudiada posteriormente. * Arrancar la aplicación.
Arrancar la aplicación incluye ejecutar el registro de objetos remotos de RMI (rmiregistry ), el servidor y el cliente, en este orden. El apéndice A de este documento muestra, con un ejemplo, los pasos para elaborar una aplicación con RMI. El ejemplo (apéndice ), presenta un servicio que acepta peticiones de tareas concretas especificadas por parte de los clientes. Es decir, cada cliente puede especificar la tarea que desea que el servidor le realice, utilizando para ello el paso de objetos serializados.
3.6 Paso de parámetros a través de la red A un método de un objeto remoto, además de pasar tipos primitivos int, char, etc como vimos en el ejemplo simple, también podemos pasarle objetos que implementen la
interface Serializable o la interface Remote. Veremos que el primer caso es el equivalente al paso de parámetro por valor en rmi y el segundo al paso de parámetro por referencia. Aunque aquí y en el ejemplo sólo hablemos de los parámetros de los métodos remotos, todo es válido para el valor devuelto con return y ¿por qué no? con la excepcionRemoteException de dichos métodos.
Parámetros Serializable.
Parámetros Remote.
Modificando el ejemplo simple.
Liberar el objeto remoto.
Los fuentes del ejemplo.
PARÁMETROS Serializable
Un objeto Serializable es el que implementa la interface Serializable. Como dicha interface no tiene ningún método, basta con poner que nuestra clase la implementa y ya está. Para que la clase sea realmente Serializable, necesita además, que todos sus atributos sean también 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 también la implementen. Cuando pasamos un objeto Serializable como parámetro de un método 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 dinámica 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 objetoSerializable equivale al paso por valor. En el ejemplo simple de rmi, vamos a modificar el InterfaceRemoto para que en vez de dos parámetros int admita un objeto Serializable que los contenga en su interior. Por aquello de la "elegancia" en el código, haremos que el parámetro recibido sea una interface, la InterfaceSumandos.
/* La InterfaceRemota admite ahora otra Interface como parámetro */ public interface InterfaceRemota extends Remote { public int suma (InterfaceSumandos sumandos) throws
RemoteException; ... } /* La interface que hace de parámetro del método remoto */ public interface InterfaceSumandos extends Serializable { public int getSumando1(); public int getSumando2(); } La implementación de esta clase puede ser así
/* Una implementación para el parámetro del método remoto */ public class Sumando implements InterfaceSumandos { private int a=0; private int b=0; public Sumando (int a, int b)
{
this.a=a; this.b=b; } public int getSumando1()
{
return a; } public int getSumando2()
{
return b; } } Se compila normalmente y necesitamos copiar los class tanto en el servidor como en el cliente. PARÁMETROS Rem ote
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 código especial, lo mejor es hacer heredar nuestra clase de UnicastRemoteObject. Con ello ya implementa la interface Remote y tenemos hecho todo el código necesario hecho.
Cuando un objeto es Remote, además 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 parámetro de un método 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 método de la clase ObjetoRemote_Stub, que son los mismos que tiene ObjetoRemote, la clase ObjetoRemote_Stub se encarga de transmitir la llamada a través 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 través de algún método, esta clase se encarga de pedir el valor a través de red al original. Por ello, pasar objetos Remote es equievalente al paso de parámetros por referencia. Sólo existe un objeto real y hay otro ficticio que delega todas las llamadas, a través de red, en el original Seguimos modificando el ejemplo simple de rmi, añadiendo un nuevo método a InterfaceRemota para que admita, por ejemplo, un Contador remoto. Nuevamente, como nos pasamos de "elegantes", otra interface para ello
/* Añadimos un nuevo método a InterfaceRemota */ public interface InterfaceRemota extends Remote { public int suma (InterfaceSumandos sumandos) throws RemoteException; public void tomaContador (InterfaceContador contador) throws RemoteException; } /* Y aquí la nueva interface que hará de parámetro del nuevo método */ public interface InterfaceContador extends Remote {
public void incrementa() throws RemoteException; } Y la implementación de esto puede ser
/* Una implementación para este nuevo parámetro */ public class Contador extends UnicastRemoteObject implements InterfaceContador { 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 obligados a hacer un constructor que lance una RemoteException. Escribimos como se incrementa el contador cada vez que llamamos al método para ver en la pantalla de quién (servidor o cliente) se realiza el incremento. 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.
3.7 Callbacks (Respaldos) Callback de cliente Considérese una aplicación RMI donde un objeto servidor debe notificar a los procesos participantes la ocurrencia de algún evento. Como ejemplos, en un chat , cuando un nuevo participante entra, se avisa al resto de los participantes de este hecho; en un sistema de subastas en tiempo real, cuando empiezan las ofertas, se debe avisar a los procesos participantes. Esta característica también es útil en un juego en red cuando se informa a los jugadores de la actualización del estado del juego. Dentro del entorno del API básica de RMI presentada en el capítulo anterior, es imposible que el servidor inicie una llamada al cliente para transmitirle alguna clase de información que esté disponible, debido a que una llamada a
método remoto es unidireccional (del cliente al servidor). Una forma de llevar a cabo la transmisión de información es que cada proceso cliente realice un sondeo al objeto servidor, invocando de forma repetida un método remoto, que supóngase que se llama haComenzadoOferta, hasta que el método devuelva el valor booleano verdadero: InterfazServidor h = (InterfazServidor) Naming.lookup(URLRegistro); while (!(h.haComenzadoOferta()) {;} // comienza la oferta
El sondeo (p o l l i n g ) es de hecho una técnica empleada en muchos programas de red. Pero se trata de una técnica muy costosa en términos de recursos del sistema, ya que cada invocación a un método remoto implica un thread separado en la máquina servidora, además de los recursos de sistema que su ejecución conlleva. Una técnica más eficiente se denomina callback : permite que cada objeto cliente interesado en la ocurrencia de un evento se registre a sí mismo con el objeto servidor, de forma que el servidor inicie una invocación a un método remoto del objeto cliente cuando dicho evento ocurra. La Figura 8.1 compara las dos técnicas: sondeo y callback . En RMI, el callback de cliente es una característica que permite a un objeto cliente registrarse a sí mismo con un objeto servidor remoto para c a l l b a c k s , de forma que el servidor pueda llevar a cabo un invocación al método del cliente cuando el evento ocurra. Hay que observar que con los callbacks de clientes, las invocaciones de los métodos remotos se convierten en bidireccionales, o dúplex , desde el cliente al servidor y viceversa. Debido a que el API de RMI básica, introducida en el capítulo anterior, sólo permite invocación de métodos remotos de clientes en objetos servidores, se necesita claramente sintaxis adicional para dar soporte a esta nueva característica. Cuando un objeto servidor realiza un callback , los papeles de los dos procesos se invierten: el objeto servidor se convierte en cliente del objeto cliente, debido a que el primero inicia una invocación de método remoto en el segundo. La Figura 8.2 muestra la arquitectura de RMI con callback de cliente. Comparada con la arquitectura básica de RMI, se puede observar que en este caso se necesitan dos conjuntos de proxies, uno para la interfaz remota del servidor, como en la arquitectura básica de RMI, y otro para una interfaz adicional, la interfaz remota del cliente. La interfaz remota del cliente proporciona un método remoto que puede invocar el servidor a través del callback . Como ejemplo, se incrementará la aplicación HolaMundo, presentada en el capítulo anterior, de forma que el objeto cliente se registre con el servidor para callback y entonces se le notifique cualquier registro de otro objeto cliente para callback con el servidor.
Incremento [AUNQUE ES CORRECTO GRAMATICALMENTE, QUIZÁS A MÍ ME SUENA MEJOR ALGO COMO “EXTENSIÓN” PERO QUEDA A TU CRITERIO] de la parte cliente para callback de cliente Para el callback , el cliente debe proporcionar un método remoto que permita al servidor notificarle el evento correspondiente. Esto puede hacerse de una forma similar a los métodos remotos del objeto servidor. En la siguiente subsección se describe la sintaxis necesaria para llevar a cabo esto.
La interfaz remota de cliente Es importante recordar que el objeto servidor proporciona una interfaz remota que declara los métodos que un objeto cliente puede invocar. Para el callback , es necesario que el objeto cliente proporcione una interfaz remota similar. Se le denominará interfaz remota de cliente(por ejemplo, InterfazCallbackCliente ), por oposición a la interfaz remota de servidor (por ejemplo, InterfazCallbackServidor ). La interfaz remota de cliente debe contener al menos un método que será invocado por el servidor en el callback . Como ejemplo, se describe la siguiente interfaz remota de cliente: public interface InterfazCallbackCliente extends java.rmi.Remote { // Este método remoto es invocado por un servidor // que realice un callback al cliente que implementa // esta interfaz. // El parámetro es una cadena de caracteres que // contiene información procesada por el cliente // una vez realizado el callback . // Este método devuelve un mensaje al servidor. public String notificame(String mensaje) throws java.rmi.RemoteException; } // final de la interfaz El servidor debe invocar el método notificame cuando realiza el callback , pasando como argumento una cadena de caracteres ( String ). Una vez recibido el callback , el cliente utiliza esta cadena para componer otra cadena que devuelve al servidor.
La implementación de la interfaz remota de cliente Al igual que la interfaz remota de servidor, es necesario implementar la interfaz remota de cliente en una clase, denominada ImplCallbackCliente en el ejemplo, tal y como se muestra a continuación: import java.rmi.*; import java.rmi.server.*; public class ImplCallbackCliente extends UnicastRemoteObject implements InterfazCallbackCliente { public ImplCallbackCliente() throws RemoteException { super(); }
public String notificame (String mensaje) { String mensajeRet =“Callback recibido: “ + mensaje; System.out.println(mensajeRet); return mensajeRet; } } // final clase ImplCallbackCliente En este ejemplo el método de callback notificame simplemente imprime la cadena de caracteres que le pasa el servidor como argumento, y devuelve otra cadena a dicho servidor. Al igual que la interfaz remota de servidor, se debe utilizar el compilador r m i c con la implementación de la interfaz remota de cliente para generar los proxies necesarios en tiempo de ejecución.
Incremento de la clase cliente En la clase del objeto cliente, se necesita añadir código al cliente para que instancie un objeto de la implementación de la interfaz remota de cliente. A continuación, se registra con el servidor una referencia al objeto utilizando un método remoto proporcionado por el servidor (véase la próxima sección, “Incremento de la parte servidora para callback de cliente”). Un ejemplo de cómo debe realizarse esto se muestra a continuación: InterfazCallbackServidor h = (InterfazCallbackServidor) Naming.lookup(URLRegistro); InterfazCallbackCliente objCallback = new ImplCallbackCliente(); // registrar el objeto para callback h.registrarCallback(objCallback);
Las figuras entre la 8.3 hasta la 8.5 presentan el código del software de la parte cliente para la aplicación HolaMundo modificada.
Incremento de la parte servidora para callback de cliente En la parte del servidor, se necesita añadir un método remoto para que el cliente pueda registrarse para callback . En el caso más sencillo, la cabecera del método puede ser análoga a la siguiente: public void registrarCallback( // Se puede elegir el nombre de método deseado InterfazCallbackCliente objCallbackCliente ) throws java.rmi.RemoteException; Como argumento se pasa una referencia a un objeto que implementa la interfaz remota de cliente ( InterfazCallbackCliente, no ImplCallbackCliente). También se puede proporcionar un método eliminarRegistroCallback , para que un cliente pueda cancelar el registro (de forma que no reciba más callbacks). La implementación de estos métodos, así como la implementación de un método local hacerCallbacks – para realizar los callbacks – se muestra en la figura 8.7. La figura 8.6 muestra el fichero con la interfaz del servidor aumentado con las
cabeceras de los métodos adicionales. La figura 8.8 muestra el código para el objeto servidor, que queda sin modificar respecto a la anterior versión, presentada en el capítulo anterior. El servidor necesita emplear una estructura de datos que mantenga una lista de las referencias a la interfaz de cliente registradas para callbacks. En el código de ejemplo, un objeto Vector es utilizado para este propósito, aunque se puede sustituir por cualquier otra estructura de datos apropiada. Cada llamada a registrarCallback implica añadir una referencia al vector, mientras que cada llamada a eliminarRegistroCallback supone borrar una referencia del vector. En el ejemplo, el servidor realiza un callback (mediante el método hacerCallbacks) siempre que se lleva a cabo una llamada a registrarCallback , donde se envía al cliente a través de callback , el número de clientes actualmente registrados. En otras aplicaciones, los callbacks se pueden activar por otros eventos y pueden gestionarse a través de un manejador de eventos. En el ejemplo, un cliente elimina su registro después de un determinado periodo de tiempo. En las aplicaciones reales, la cancelación del registro se puede realizar al final de la sesión del cliente (tal como en el caso de una sesión de chat o en una sesión de subastas).
Pasos para construir una aplicación RMI con callback de cliente En las siguientes páginas se presenta una descripción revisada del procedimiento para construir una aplicación RMI paso a paso, permitiendo callback de cliente.
Algoritmo para desarrollar el software de la parte del servidor 1. Crear un directorio donde se almacenen todos los ficheros generados por la aplicación. 2. Especificar la interfaz remota de servidor en InterfazCallbackServidor.java. Compilarla y revisarla hasta que no exista ningún error de sintaxis. 3. Implementar la interfaz en ImplCallbackServidor.java. Compilarlo y revisarlo hasta que no exista ningún error de sintaxis. 4. Utilizar el compilador RMI rmic para procesar la clase de la implementación y generar los ficheros stub y skeleton para el objeto remoto: rmic ImplCallbackServidor Los ficheros generados se pueden encontrar en el directorio como ImplCallbackServidor_Skel.class y ImplCallbackServidor_Stub.class. Los pasos 3 y 4 deben repetirse cada vez que se cambie la implementación de la interfaz. 5. Obtener una copia del fichero class de la interfaz remota del cliente. Alternativamente, obtener una copia del fichero fuente para la interfaz remota y compilarlo utilizando javac para generar el fichero class de la interfaz InterfazCallbackCliente.class. 6. Crear el programa correspondiente al objeto servidor ServidorEjemplo.java. Compilarlo y revisarlo hasta que no exista ningún error de sintaxis. 7. Obtener una copia del fichero stub de la interfaz remota del cliente ImplCallbackCliente_Stub.class. 8. Activar el objeto servidor
java ServidorEjemplo
Algoritmo para desarrollar el software de la parte cliente 1. Crear un directorio donde se almacenen todos los ficheros generados por la aplicación. 2. Especificar la interfaz remota de cliente en InterfazCallbackCliente.java. Compilarla y revisarla hasta que no exista ningún error de sintaxis. 3. Implementar la interfaz en ImplCallbackCliente.java. Compilarlo y revisarlo hasta que no exista ningún error de sintaxis. 4. Utilizar el compilador RMI rmic para procesar la clase de la implementación ImplCallbackCliente.class y generar los ficheros stub y skeleton ImplCallbackCliente_Skel.class y ImplCallbackCliente_Stub.class para el objeto remoto: rmic ImplCallbackCliente Los ficheros generados se pueden encontrar en el directorio como ImplCallbackCliente_Skel.class y ImplCallbackCliente_Stub.class. Los pasos 3 y 4 deben repetirse cada vez que se cambie la implementación de la interfaz. 5. Obtener una copia del fichero class de la interfaz remota del servidor. Alternativamente, obtener una copia del fichero fuente para la interfaz remota y compilarlo utilizando javac para generar el fichero class de la interfaz Interfaz . 6. Crear el programa correspondiente al objeto cliente ClienteEjemplo.java. Compilarlo y revisarlo hasta que no exista ningún error de sintaxis. 7. Obtener una copia del fichero stub de la interfaz remota del servidor ImplCallbackServidor_Stub.class. 8. Activar el objeto cliente java ClienteEjemplo La figura 8.9 muestra los ficheros que se necesitan en los dos extremos, cliente y servidor, cuando se utiliza callback de cliente. (Como se mencionó en el capítulo anterior, desde la versión 1.2 de Java no se requieren clases skeleton en las aplicaciones RMI. Las funciones de las clases skeleton se realizan a través de una técnica denominada reflexión.)
Resumen
RMI proporciona un mecanismo para la elaboración de aplicaciones con objetos Java distribuidos. Al estar integrado dentro de la jerarquía de paquetes oficiales del lenguaje de programación Java, se adapta perfectamente al modelo de programación del mismo. RMI facilita la elaboración de aplicaciones que sigan el modelo clienteservidor. Dada su naturaleza, resulta muy sencillo integrar RMI con la versión empresarial del lenguaje Java (J2EE); con el objetivo de desplegar, po ejemplo, los muy extendidos servicios web. Para concluir, RMI presenta una serie de ventajas e inconvenientes: Entre sus principales ventajas destaca su sencillez, con RMI los objetos remotos se manejan como si fueran locales. Por otro lado, al existir una separación entre interfaces e implementaciones, en una aplicación con objetos distribuidos se pueden aprovechar las ventajas de la programación orientada a objetos. Además, la carga dinámica de clases permite, por ejemplo, que los clientes se conviertan en applets interpretados en un navegador. RMI proporciona un servicio de registro, rmiregistry , que facilita la localización por nombre de los servicios. Por último, existe la posibilidad de añadir a las comunicaciones RMI protocolos de seguridad, como SSL o HTTPS. En contrapartida, uno de sus principales inconvenientes es el uso exclusivo de Java; problema parcialmente resuelto con la posibilidad, incorporada en las últimas versiones, de trabajar con nuevos protocolos que proporcionan interoperatiblidad. Por otro lado, RMI no proporciona metainformación, es decir, no dispone de un sistema que informe de los servicios disponibles y sus APIs (nombre de métodos, valores de retorno, etc.). Cierta consideración merece el hecho de que, al realizar el paso de objetos por valor, cuando se serializa un objeto hay que hacerlo junto con todos aquellos de los que tiene referencias. Cuanto mayor sea el tamaño de estos objetos, mayor será el tráfico entre máquinas. Por último, no existe un mecanismo que controle las transacciones realizadas y actúe cuando no se completen.
BIBLIOGRAFIA http://laurel.datsi.fi.upm.es/~ssoo/LIBRO/Cap8/cap8-revisado.doc
http://www.itescam.edu.mx/portal/asignatura.php?clave_asig=IFF1019&carrera=IINF-2010-220&id_d=60 http://www.iuma.ulpgc.es/users/lhdez/inves/pfcs/memoriadomingo/node6.html#SECTION03330000000000000000
