PROGRAMACION EN AMBIENTE CLIENTE-SERVIDOR
ING. MILTON JOSE MARTIL CRUZ
ZAMORANO LARA MARISOL WENDOLINE TOVILLA LOPEZ ABEL EMERIT CALVO AGUILAR ANDRES DE JESUS
TAPACHULA DE CORDOVA Y ORDOEZ, CHIAPAS A 20 DE NOVIEMBRE DEL 2013.
3.1 RMI: Remote Method Invocation (Invocacin Remota de Mtodos)
Permite invocar a mtodos de objetos remotos a travs del protocolo TCP/IP Objetos en la misma mquina, Objetos en mquinas distintas. Arquitectura Cliente/Servidor, Ambos conocen y comparten una interfaz, Comunicacin a travs de la red transparente RMI es un mecanismo mediante el cual los objetos cliente y servidor en una aplicacin distribuida Java se comunican.La aplicacin distribuida en Java necesita: 1) Localizar los objetos remotos: Mediante la facilidad rmi registry de Java o pasando los objetos remotos como parmetros o valores de retorno en llamadas a mtodos remotos. 2) Comunicarse con objetos remotos: RMI maneja todos los detalles de la comunicacin. Para el programador la comunicacin remota es igual a una invocacin a un mtodo local estndar. 3) Descarga de las clases de los objetos pasados como parmetros o valor de retorno: RMI proporciona los mecanismos necesarios para descargar el cdigo de los objetos tanto remotos como locales pasados cmo parmetros o valor de retorno, as como transmitir sus datos.
CARACTERISTICAS RMI
Se caracteriza por la facilidad de su uso en la programacin por estar especficamente diseado para Java; Proporciona paso de objetos por referencia (no permitido por SOAP), Recoleccin de basura distribuida (Garbage Collector distribuido) y paso de tipos arbitrarios (funcionalidad no provista por CORBA). Por medio de RMI, un programa Java puede exportar un objeto, lo que significa que ste queda accesible a travs de la red y el programa permanece a la espera de peticiones en un puerto TCP. A partir de este momento, un cliente puede conectarse e invocar los mtodos proporcionados por el objeto. Es necesario tratar mayor nmero de excepciones que en el caso de innovacin de mtodos locales. Errores en la comunicacin entre los procesos (fallos de acceso, fallos de conexin) Problemas asociados a la invocacin de mtodos remotos(no encontrar el objeto, el resguardo o el esqueleto) Los mtodos deben especificar la excepcin RemoteException.
LA ESTRUCTURA DE JAVA RMI
La definicin de un comportamiento y su implementacin son conceptos separados. En RMI, el cdigo que define el comportamiento y el cdigo que lo implementa estn y se ejecutan en diferentes JVMs. La definicin de un servicio remoto se hace usando una interfaz de JAVA. La implementacin se codifica en una clase (Servidor). RMI soporta 2 clases que implementan la misma interfaz. La primera implementa el servicio y se ejecuta en el servidor. La segunda acta como un proxy para el servicio remoto y se ejecuta en el cliente. Estructura Java RMI Clientes y servidores. Objetos que implementan la lgica de la aplicacin
Servidores
Crean instancias de los objetos remotos y los ponen a disposicin de los clientes para recibir peticiones: Crear objetos remotos Crear referencias remotas y exportarlas Nombrar y registrar los objetos remotos en el servicio de nombres Espera de invocaciones RMI mantiene activo el proceso servidor mientras existan referencias remotas a alguno de los objetos remotos creados por el (incluidas las referencias del servicio de nombres) Cuando un objeto no tiene referencias desde ningn cliente, ni desde el servidor, queda disponible para la recoleccin de basura (Garbage Collection).
Cliente
Declaran objetos de la interfaz remota y obtienen referencias a objetos remotos (stubs) consultas al servidor de nombres mediante referencias remotas recibidas como valor de retorno. Invocacin de mtodos remotos (mediante el stub). Un mismo proceso/objeto puede actuar a la vez como servidor (exporta un objeto remoto) y como cliente (invoca un mtodo de otro objeto remoto).
Nivel de Aplicacin
La capa de aplicacin se corresponde con la implementacin real de las aplicaciones cliente y servidor. Aqu tienen lugar las llamadas a alto nivel para acceder y exportar objetos remotos. Cualquier aplicacin que quiera que sus mtodos estn disponibles para su acceso por clientes remotos debe declarar dichos mtodos en una interfaz que extienda java.rmi.Remote. Dicha interfaz se usa bsicamente para "marcar" un objeto como remotamente accesible. Una vez que los mtodos han sido implementados, el objeto debe ser exportado. Esto puede hacerse de forma implcita si el objeto extiende la clase UnicastRemoteObject (paquete java.rmi.server), o puede hacerse de forma explcita con una llamada al mtodo exportObject() del mismo paquete.
Nivel de Referencia Remota
Los niveles de referencia remota definen y soportan la semntica de la invocacin de una conexin RMI. Este nivel ofrece un objeto RemoteRef que representa el enlace al objeto que alberga la implementacin del servicio remoto. Tambin es responsable de la gestin de la replicacin de objetos y realizacin de tareas especficas de la implementacin con los objetos remotos, como el establecimiento de las persistencias semnticas y estrategias adecuadas para la recuperacin de conexiones perdidas Los stubs usan el mtodo invoke() para dirigir (to forward) la llamada. El objeto RemoteRef entiende la semntica de invocacin para servicios remotos.
Nivel de los Stubs y Skeletons
La capa 2 es la capa proxy, o capa stub-skeleton. Esta capa es la que interacta directamente con la capa de aplicacin. Todas las llamadas a objetos remotos y acciones junto con sus parmetros y retorno de objetos tienen lugar en esta capa. Un skeleton es una clase auxiliar generada por RMI. Un skeleton entiende cmo comunicarse con el stub a travs del enlace RMI. El skeleton mantiene una conversacin con el stub; lee los parmetros de la llamada, efecta la invocacin al servicio remoto (to the remote service implementation object), acepta el valor de retorno y lo retorna al stub. En la implementacin de RMI de Java 2 SDK la clase skeleton est obsoleta debido al protocolo new wire.
Nivel de Transporte
El nivel de transporte realiza la conexin entre JVMs. Todas las conexiones son streambased y usan TCP. An si dos JVMs se estn ejecutando en la misma computadora, ellas se conectan a travs del protocolo TCP/IP.Por encima de TCP/IP, RMI usa un wire level protocol llamado Java Remote Method Protocol (JRMP). JRMP es un protocolo propietario, stream-based que est especificado para dos versiones. La primera se liber con JDK 1.1 y requiere del uso de clases Skeleton en el servidor. La segunda versin se liber con Java 2 SDK. Se ha optimizado para mejorar el desempeo por lo que no requiere de las clases skeletons. La capa 4 es la de transporte. Es la responsable de realizar las conexiones necesarias y manejo del transporte de los datos de una mquina a otra. El protocolo de transporte subyacente para RMI es JRMP (Java Remote Method Protocol), que solamente es "comprendido" por programas Java.
3.2 API RMI
La API RMI (Remote Method Invacation) proporciona un mecanismo para facilitar la elaboracin de aplicaciones distribuidas. Integrado dentro de la jerarqua de paquetes oficiales del lenguaje de programacin Java, se adapta perfectamente al modelo de programacin de dicho lenguaje. La programacin orientada a objetos se adapta de manera natural a la programacin de aplicaciones distribuidas. En la programacin orientada a objetos, tareas parciales de un problema pueden ser modeladas como entidades, que llamamos objetos, que se comunican entre ellos durante su ejecucin. En consecuencia, el uso de programacin orientada a objetos, resulta una evolucin natural en el desarollo de aplicaciones distribuidas; de forma que tareas parciales, que ahora estarn ubicadas en distintas mquinas, son modeladas como objetos que intercambian mensajes a travs de la red. RMI integra este concepto en el lenguaje de programacin Java, de manera que el manejo de objetos en aplicaciones distribuidas mantenga la semntica propia de los objetos locales de Java. En consecuencia, RMI puede ser fcilmente integrada con otras APIs de dicho lenguaje. En RMI, un objeto de Java puede ``marcarse'' como remoto de forma que los procesos de aplicaciones distribuidas pueden acceder a l como si fuera local. RMI proporciona un modelo propio de objetos distribuidos, optimizado para las caractersticas de Java.
3.3 JERARQUIA DE OBJETOS RMI
OBJETOS REMOTOS Un objeto remoto en Java debe implementar la interfaz java.rmi.Remote que acta como flag para que la mquina virtual lo reconozca como tal. El paso de argumentos y los valores de retorno que admiten los mtodos remotos tiene las siguientes caractersticas: Los tipos de datos primitivos y los objetos predefinidos de Java que implementen la interfaz java.io.Serializable se pasan por valor. Es decir, se copian del espacio de direcciones de una mquina virtual a otra. Los objetos (no remotos) cuyas clases implementen la interfaz java.io.Serializable se pasan por valor. Los objetos remotos que estn a la espera de peticiones llegadas desde los clientes no se transmiten sino que, en su lugar, se envan las referencias remotas a los mismos (instancias de un stub). Por lo tanto, puede concluirse que se envan por referencia. Los objetos (no remotos) que no implementan java.io.Serializable no pueden enviarse a un objeto remoto. Implementa la interfaz remota
OBJETOS SERIALIZABLES La serializacin de un objeto consiste en generar una secuencia de bytes lista Para su almacenamiento o transmisin. Despus, mediante la deserializacin, el estado original del objeto se puede reconstruir. Para que un objeto sea serializable, ha de implementar la interfaz java.io.Serializable (que lo nico que hace es marcar el objeto como serializable, sin que tengamos que implementar ningn mtodo). La serializacin es una caracterstica aadida al lenguaje Java para dar soporte a La invocacin remota de objetos (RMI) La persistencia La invocacin remota de objetos permite a los objetos que viven en otros ordenadores comportarse como si vivieran en la propia mquina. La serializacin es necesaria para transportar los argumentos y los valores de retorno. La persistencia, es una caracterstica importante de los JavaBeans. El estado de un componente es configurado durante el diseo. La serializacin nos permite guardar el estado de un componente en disco, abandonar el Entorno Integrado de Desarrollo (IDE) y restaurar el estado de dicho componente cuando se vuelve a correr el IDE.
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
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 mtodos, debe ser implementada por toda clase remota para que sus mtodos 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 mtodos son usados internamente por RMI. La clase Naming proporciona mtodos para obtener y almacenar referencias de los objetos remotos mediante URLs. Sus mtodos ms habituales son: public static void bind(String name, Remote object) throws AlreadyBoundException,MalformedURLException,RemoteException public static void rebind(String name, Remote object) throws RemoteException, MalformedURLException public static void lookup(String name) throws NotBoundException,MalformedURLException,RemoteException El mtodo 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 especificacin dada en la URL no es correcta, se producir una excepcin 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 cdigo que registra un objeto remoto en el rmiregistry, tpicamente, tiene la forma siguiente:
myClass myInstance=new myClass(); Naming.bind("rmi://host:port/name,myInstance");
Este cdigo 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 ocasionara una excepcin del tipo AlreadyBoundException. Por otro lado, el mtodo 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 dnde se ubica el objeto remoto. Esta referencia remota se obtiene en forma de stub, de manera que se podrn abrir conexiones hacia el host y puerto que especifica el stub y llamar a los mtodos remotos del objeto. Una llamada tpica a lookup() sera 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 cdigo 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 mtodos 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. Tambin permite crear estos objetos a partir de un puerto o puertos y, si se desea, factoras de sockets RMI. Las factoras de sockets permiten establecer caractersticas comunes a los sockets que se quieren crear en una aplicacin 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 mtodos para la creacin de los mismos, lectura de stos
desde flujos de bytes e insercin en ellos. Estos identificadores son los propios de un objeto remoto en una referencia remota. Clase RemoteObject.- Implementa la clase java.lang.Object (clase raz de todas las clases Java) para objetos remotos y la interfaz java.rmi.Remote. Clase RemoteServer.- Hereda de RemoteObject. Es la clase raz de la que heredan todas las implementaciones de objetos cuyos mtodos son accesibles remotamente, y proporciona la semntica bsica para el manejo de referencias remotas. Clase RemoteStub.- Hereda de RemoteObject. Es la clase raz de la que heredan todos los stubs de los clientes. Clase RMIClassLoader.- Incluye mtodos estticos para permitir la carga dinmica de clases remotas. Si un cliente o servidor de una aplicacin 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 implementacin por defecto de los objetos remotos. Permite llamar a los mtodos remotos mediante conexiones TCP por el puerto especificado. Si se necesitan objetos remotos con un funcionamiento ms especfico, 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 mtodos para llamar a los mtodos de objetos remotos. Interfaz RMIClientSocketFactory.- Usada por RMI para obtener sockets clientes para las llamadas RMI. Interfaz RMIFailureHandler.- Especifica los mtodos que se encargan de manejar los fallos derivados de la creacin 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 ms 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 activacin y desactivacin, conservan su estado.
3.4 EL SISTEMA DE NOMBRADO REGISTRY
RMIRegistry: Se ejecuta en el servidor y es un objeto remoto con un puerto conocido. Relaciona el objeto remoto con un nombre. El contacto directo se tiene con el stub proporcionado por el objeto remoto. Almacena internamente la etiqueta y el objeto stub en un hashmap. Devuelve el stub al cliente que solicito el objeto remoto. En caso de no hacer uso de este ejecutable de Java se encuentran la interfaz Registry y la clase LocateRegistry (con sus mtodos createRegustry y getRegistry). 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 aplicacin 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 informacin de registro se pierde al reiniciar la aplicacin rmiregistry. Al ejecutar rmiregistry, se activa un proceso que escucha en un puerto TCP especfico. Para que un cliente pueda acceder a los servicios remotos ofrecidos por un servidor, ste deber registrarlos previamente en el rmiregistry, asocindoles un nombre lgico. El rmiregistry acta, en consecuencia, como un servidor DNS, de manera que a las bsquedas por nombre de los clientes, devuelva los stubs asociados al servicio. La figura 3.5 muestra cmo se realiza una llamada remota en RMI utilizando el servicio de registro. La secuencia completa es la siguiente: 1. Se ejecuta el servidor de registro RMI, rmiregistry, en la mquina 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 mtodos 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 mtodo de la interfaz del objeto remoto. 4. El servidor de registro enva 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 direccin IP del host donde reside el objeto remoto, el nmero de puerto por el que escucha y un identificador del objeto. 5. El stub serializa los argumentos y enva a la capa de referencias remotas una peticin de conexin, delegando en ella su envo.
6. La capa de referencias remotas indica a la capa de transporte que necesita abrir una conexin para enviarle el flujo de datos resultante de la serializacin. 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 mtodo invocado con los argumentos proporcionados y, si corresponde, devuelve un valor al objeto skeleton. 12. El skeleton enva una peticin de conexin a la capa de referencias remotas y delega en ella el envo de la respuesta. 13. La capa de referencias remotas serializa la respuesta y enva el flujo de bytes resultante a la capa de transporte, indicndole que necesita una conexin. 14. La capa de transporte remota abre un socket de cliente y enva 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 informacin serializada y la enva al stub. 17. Finalmente, el stub enva el valor devuelto al objeto local.
3.5 DESARROLLO DE APLICACIONES DISTRIBUIDAS
Como se ha comentado a lo largo de este documento, una aplicacin RMI tpicamente 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 invocacin de sus mtodos por parte de los clientes. Por otra parte, un cliente obtiene una referencia remota a algn objeto del servidor, e invoca sus mtodos. En este apartado veremos cmo se lleva este proceso a la prctica.
Interfaces, objetos y mtodos remotos
Una aplicacin distribuida desarrollada utilizando RMI, como cualquier aplicacin Java, est compuesta por interfaces y clases. Los interfaces definen mtodos, mientras que las clases implementan los mtodos definidos en los interfaces (tambin puede definir algunos mtodos adicionales). En una aplicacin distribuida, se asume que algunas implementaciones residen en diferentes mquinas virtuales. Los objetos que tienen mtodos que pueden llamarse desde mquinas virtuales localizadas en otros ordenadores, son los objetos remotos. Un objeto se convierte en remoto implementando un interfaz remoto, que tenga estas caractersticas. Un interfaz remoto extiende a java.rmi.Remote. Cada mtodo del interfaz debe soportar la excepcin java.rmi.RemoteException, adems de cualquier excepcin especfica de la aplicacin. El stub de un objeto remoto implementa el mismo conjunto de interfaces que el objeto. En consecuencia, y haciendo uso de las propiedades bsicas del lenguaje de programacin Java, como son la herencia y el polimorfismo, se permite la conversin de tipos del stub a cualquiera de esas interfaces. Un cliente podr recibir siempre su stub aprovechando este mecanismo, que en la prctica se realizar a travs de la interfaz Remote ya presentada. Adems, slo aquellos mtodos definidos en una interfaz remota estn disponibles para ser llamados en la mquina virtual destino, lo cual permite aislar a los objetos remotos y slo hacerlos accesibles a determinados mtodos.
Disear e implementar los componentes de la aplicacin distribuida
Podemos dividir la creacin de una aplicacin con objetos distribuidos RMI en una serie de
pasos descritos en los apartados siguientes: Disear e implementar los componentes de nuestra aplicacin distribuida Compilar los fuentes y generar los stubs Hacer las clases accesibles a la red Arrancar la aplicacin
Primero, decidimos la arquitectura de nuestra aplicacin y determinamos qu componentes son objetos locales y cules accesibles remotamente. Este paso incluye: Definir los interfaces remotos. Un interfaz remoto especifica los mtodos 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 podra incluir implementaciones de otros interfaces (locales o remotos) y otros mtodos (que slo estarn disponibles localmente). Si alguna clase local va a ser utilizada como parmetro o cmo valor de retorno de alguno de esos mtodos, tambin debe ser implementada. Implementar los clientes. Para implementar un cliente que solicite servicio a un objeto remoto, de este ltimo slo es necesario conocer su interfaz. En el cdigo 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 aplicacin descargue, en tiempo de ejecucin, 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 travs de un servidor web. El mecanismo que lo permite es la carga dinmica de clases, que ser estudiada posteriormente. Arrancar la aplicacin. Arrancar la aplicacin incluye ejecutar el registro de objetos remotos de RMI (rmiregistry), el servidor y el cliente, en este orden.
3.6 PASO DE PARAMETROS ATRAVES DE LA RED
PAS DE PARMETROS ATRAVEZ DE LA RED A un mtodo de un objeto remoto, adems de pasar tipos primitivos int, char, etc como vimos en el ejemplo simple, tambin podemos pasarle objetos que implementen la interface Serializable o la interface Remote. Veremos que el primer caso es el equivalente al paso de parmetro por valor en rmi y el segundo al paso de parmetro por referencia. Aunque aqu y en el ejemplo slo hablemos de los parmetros de los mtodos remotos, todo es vlido para el valor devuelto con return y por qu no? con la excepcion RemoteException de dichos mtodos. PARMETROS Serializable Un objeto Serializable es el que implementa la interface Serializable. Como dicha interface no tiene ningn mtodo, basta con poner que nuestra clase la implementa y ya est. Para que la clase sea realmente Serializable, necesita adems, que todos sus atributos sean tambin Serializable. Esto quiere decir que sus atributos pueden ser tipos primitivos (int, char, float, etc), clases de java normalitas (consultar en la API de Java si implementan la interface, por ejemplo Integer, String) o bien clases nuestras que tambin la implementen. Cuando pasamos un objeto Serializable como parmetro de un mtodo remoto, java se encarga de convertir ese objeto a bytes (serializar el objeto), enviarlo por red y hacerlo llegar al otro lado (el servidor). All, java se encarga de convertir nuevamente esos bytes a un objeto (deserializar el objeto). Si no usamos carga dinmica de clases, tanto el cliente como el servidor deben tener esa clase en su CLASSPATH para poder usarla. En este momento, existen dos instancias distintas de la clase, una copia de la otra. Si el cliente o el servidor tocan su copia, la otra no se ve afectada. Pasar un objeto Serializable equivale al paso por valor. En el ejemplo simple de rmi, vamos a modificar el InterfaceRemoto para que en vez de dos parmetros int admita un objeto Serializable que los contenga en su interior. Por aquello de la "elegancia" en el cdigo, haremos que el parmetro recibido sea una interface, la InterfaceSumandos.
/* La InterfaceRemota admite ahora otra Interface como parmetro */ public interface InterfaceRemota extends Remote
{ public int suma (InterfaceSumandos sumandos) throws RemoteException; ... } /* La interface que hace de parmetro del mtodo remoto */ public interface InterfaceSumandos extends Serializable { public int getSumando1(); public int getSumando2(); }
La implementacin de esta clase puede ser as...
/* Una implementacin para el parmetro del mtodo 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.
PARMETROS REMOTE Un objeto Remote es el que implementa la interface Remote. Aunque aparentemente con esta inteface no tenemos que hacer nada (igual que con la interface Serializable), en realidad si debemos hacer nuestra clase de una cierta forma. Para evitarnos hacer este cdigo especial, lo mejor es hacer heredar nuestra clase de UnicastRemoteObject. Con ello ya implementa la interface Remote y tenemos hecho todo el cdigo necesario hecho. Cuando un objeto es Remote, adems de compilarlo de la forma habitual, necesitamos compilarlo con el compilador rmic, que viene con java y est en JAVA_HOME/bin. Una vez obtenido nuestro ObjetoRemote.class, pasamos el compilador rmic de esta forma $ rmic paquete.ObjetoRemote No ponemos el fichero ObjetoRemote.class, sino el nombre de la clase. Esto generar un fichero ObjetoRemote_Stub.class. Cuando pasamos un objeto Remote como parmetro de un mtodo rmi, java se encarga de enviar el ObjetoRemote_Stub al otro lado. El servidor reconstruye este ObjetoRemote_Stub. Por ello, ObjetoRemote_Stub.class debe estar en el CLASSPATH de ambos. Cuando el servidor llama a cualquier mtodo de la clase ObjetoRemote_Stub, que son los mismos que tiene ObjetoRemote, la clase ObjetoRemote_Stub se encarga de transmitir la llamada a travs de la red al ObjetoRemote original que est en el cliente. Por ello, si el servidor cambia algo llamando a ObjetoRemote_Stub, se cambia en el objeto original del cliente. Si el servidor trata de obtener un valor de ObjetoRemote_Stub a travs de algn mtodo, esta clase se encarga de pedir el valor a travs de red al original. Por ello, pasar objetos Remote es equievalente al paso de parmetros por referencia. Slo existe un objeto real y hay otro ficticio que delega todas las llamadas, a travs de red, en el original Seguimos modificando el ejemplo simple de rmi, aadiendo un nuevo mtodo a InterfaceRemota para que admita, por ejemplo, un Contador remoto. Nuevamente, como nos pasamos de "elegantes", otra interface para ello. /* Aadimos un nuevo mtodo a InterfaceRemota */ public interface InterfaceRemota extends Remote { public int suma (InterfaceSumandos sumandos) throws RemoteException; public void tomaContador (InterfaceContador contador) throws RemoteException; } /////* Y aqu la nueva interface que har de parmetro del nuevo mtodo */
public interface InterfaceContador extends Remote { public void incrementa() throws RemoteException; }
Y la implementacin de esto puede ser... /* Una implementacin para este nuevo parmetro */ public class Contador 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 mtodo para ver en la pantalla de quin (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. SEGUIMOS MODIFICANDO EL EJEMPLO SIMPLE Ahora slo nos queda modificar el ObjetoRemoto del ejemplo para que implemente los dos mtodos de InterfaceRemota. El mtodo de suma lo modificamos lo justo para que sirva funcionando como antes. El mtodo de tomaContador() haremos que incremente el contador recibido 10 veces, una cada segundo. La nueva implementacin de este ObjetoRemoto puede ser as...
/* Y ahora el ObjetoRemoto al completo */ public class ObjetoRemoto extends UnicastRemoteObject
implements InterfaceRemota { public ObjetoRemoto () throws RemoteException { super(); } public int suma(InterfaceSumandos sumandos) { System.out.println("Sumando " + sumandos.getSumando1() + " + " + sumandos.getSumando2() + " = ..."); return sumandos.getSumando1()+sumandos.getSumando2(); }
public void tomaContador (InterfaceContador contador) { final InterfaceContador elContador=contador; Thread hilo = new Thread (new Runnable() { public void run() { int i=0; while (i<10) { try { i++; elContador.incrementa(); Thread.sleep(1000); } catch (Exception e) { e.printStackTrace(); } } } }); hilo.start();
} }
3.7 CALLBACKS (RESGUARDOS)
Hay escenarios en los que los servidores deben notificar a los clientes la ocurrencia de algn evento. Ejemplo: chat. Problema: llamada a mtodo remoto es unidireccional Posibles soluciones: Sondeo (polling): Cada cliente realiza un sondeo al servidor, invocando repetidas veces un mtodo, hasta que ste devuelva un valor true. Problema: Tcnica muy costosa (recursos del sistema) Callback: Cada cliente interesado en la ocurrencia de un evento se registra a s mismo con el servidor, de modo que el servidor inicia una invocacin de un mtodo remoto del cliente cuando ocurra dicho evento.
Las invocaciones de los mtodos remotos se convierten en bidireccionales o Sin callbacks, el cliente debe sondear continuamente el servidor hasta que se produce cierta respuesta. o Con callbacks el cliente es notificado por el servidor.
El cliente inscribe un objeto remoto para recibir una invocacin remota.
Al ocurrir cierto evento, el servidor realiza una devolucin de llamada a cada cliente interesado.
INTERFAZ CALLBACK El servidor ofrece un mtodo remoto para que el cliente registre sus callbacks Hay que disear una interfaz remota para el Callback La interfaz debe incluir un mtodo que ser invocado en el callback desde el servidor. El cliente deber ser una subclase de RemoteObject e implementar la interfaz de callback. El cliente se registrar frente a la clase remota para ser rellamado (usualmente en el main). El servidor invoca el mtodo remoto del cliente en caso de aparecer el evento indicado.
CONCLUSION
RMI proporciona un mecanismo para la elaboracin de aplicaciones con objetos Java distribuidos. Al estar integrado dentro de la jerarqua de paquetes oficiales del lenguaje de programacin Java, se adapta perfectamente al modelo de programacin del mismo. RMI facilita la elaboracin de aplicaciones que sigan el modelo cliente-servidor. 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 separacin entre interfaces e implementaciones, en una aplicacin con objetos distribuidos se pueden aprovechar las ventajas de la programacin orientada a objetos. Adems, la carga dinmica 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 localizacin por nombre de los servicios. Por ltimo, existe la posibilidad de aadir 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 metainformacin, es decir, no dispone de un sistema que informe de los servicios disponibles y sus APIs (nombre de mtodos, valores de retorno, etc.). Cierta consideracin 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 tamao de estos objetos, mayor ser el trfico entre mquinas. Por ltimo, no existe un mecanismo que controle las transacciones realizadas y acte cuando no se completen.
