3.1 RMI (REMOTE METHOD INVOCATION) Es un mecanismo ofrecido por java para invocar un método de manera remota. Forma parte del entorno estándar de ejecución en java y proporciona un mecanismo simple para la c omunic omunic a c ió n de d e servi ervid d o res en ap a p lic a c io nes d istrib uid uid a s b a sa da s exc exc lusi usivamente vamente en e n J A VA
C ARAC TERÍST ÍSTICA IC AS: •
• • •
Facilidad de uso en la programación por estar espe espec c ífic fic a mente ente dis diseñado eña do pa p a ra J A VA Prop Propor orc c iona p a so de d e objet o bjeto o por p or referenc eferenciia Recolección de basura distribuida Paso de tipos arbitrarios
INVOCACIÓN 1) Enc Enca a p sula ula d o d e lo s p a rá metro metro s 2) invoc invoc a c ió n del d el método métod o (del (de l cl c liente c o n el ser servi vid d o r). El El invoc nvoc a dor do r se q ueda espe esperra ndo una una resp esp uest uesta . 3) Al terminar la ejecución, el servidor realiza el valor de re torno torno y lo lo envía a l c liente
4) El código cliente recibe la respuesta y continúa como si la invocación hubiera sido local.
ARQUITECTURA Puede verse c omo un modelo de c uatro c apa s
PRIMERA CAPA: Es la de aplicación y corresponde con la implementación real de las aplicaciones cliente y servidor
SEGUNDA CAPA: Es la que interactúa directamente con la capa de aplicación, se encuentran las llamadas a objetos remotos y acciones junto
CAPAS TERCERA CAPA:
Es la de referencia remota y es responsable del manejo de la parte semántica de las invocaciones remota, es responsable de la replicación de objetos.
CUARTA CAPA: Es
la de transporte; es la responsable de realizar las conexiones necesarias y manejo de transporte de los datos de una maquina a otra
Skeleton y Stub Dota a clientes y servidores de una interfaz que les permite localizar objetos remotos para invocar métodos c omo si fueran locales.
3.2 El API Java RMI Es una interfaz de programación de aplicaciones provistas por los crea dores del lenguaje J AVA, y que da a los programadores los medios para desarrollar aplicaciones javas. La API de J AVA provee un conjunto de c lases utilitarias para efectuar toda clase de tareas dentro de un programa.
Interfaces y Clases RMI La API RMI está formada por un conjunto de clases que se encuentran agrupadas en los siguientes paquetes: -J ava.rmi -J ava.rmi.server -J ava.rmi.registry -J ava.rmi.ac tivation -J ava.rmi.dgc
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í, J ava no la rec onoc erá como tal. -Mediante una instancia de la clase MarshalledObject se puede manejar el flujo de bytes serializados de un ob jeto. -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) throwsAlrea dyBoundException,Ma lformed URLExcep tion, RemoteException -public static void rebind(String name, Remote object) throws RemoteException, MalformedURLException -public static void lookup(String name) throws NotBoundException,Ma lformedURLExc eption,RemoteExc eption 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.
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 c rear 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.
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 crea ción de los mismos. -Clase RemoteObject: Implementa la clase java.lang.Objec t pa ra objetos remotos y la interfaz java.rmi.Remote. -C lase RemoteServer: Hereda de RemoteObjec t. Es la clase raíz de la que heredan todas las implementaciones de objetos cuyos métodos son accesibles remotamente.
JAVA.RMI.ACTIVATION Permite activar remotamente objetos, desactivarlos c uando ya no se traba je c on ellos y rea ctivarlos cuando sea necesario. Entre activación y desactivación, conservan su estado.
Java.rmi.dgc Este paquete c ontiene c lases, interfac es y exc epciones pa ra la rec oleccion de basura.
3.3 JERARQUIA DE OBJETOS RMI
3.4 EL SISTEMA DE NOMBRADO REGISTRY ¿Q ué es? Es un servidor simple que permite que una aplicación vea los objetos que están siendo importados por un RMI. Una vez que se tiene un objeto que está siendo exportado por un servidor que utiliza métodos de RMI, la comunicación es entonces como una simple llamada a métodos de un objeto que puede existir en una maquina diferente. 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.
3.5 APLICACIONES DISTRIBUIDAS Una aplicación con distintos componentes que se ejec utan en entornos separados, normalmente en diferentes plataformas conectadas a través de una red. Las típicas aplicaciones distribuidas son de dos niveles (cliente-servidor), tres niveles (clientemiddleware-servidor) y multinivel.
Objetivo: Una aplicación distribuida es aquella cuyo objetivo final se alcanza mediante la ejecución de diversos procesos independientes que por lo general se ejecuten en equipos diferentes y que de una forma u otra se pasan datos entre ellos mediante protocolos de c omunicaciones bien establecidos.
Componentes: -Clientes: C onducen el flujo de la aplicación. Loc alizan e invoc an métodos ofertados como los métodos remotos por los servidores.
-Servidores: C onjunto de objetos que ofrec en interfac es remotas públicas cuyos métodos pueden involucrados por clientes de c ualquier procesador.
ser
Registro: Servicio estático que se establece en c ada nudo, en el que se registran los servidores con un nombre, y donde los clientes los localizan.
-Protocolo de aplicación para la comunicación entre el cliente y el servidor: El protoc olo define el tipo de mensajes interc ambiados; por ejemplo, el protocolo de la capa de aplicación de la Web, HTTP, define el formato y la secuencia de los mensajes transmitidos entre el navegador y el servidor Web
Pasos para desarrollar una aplicación distribuida RMI: 1. Se define la interfaz remota 2. Se desarrolla el servidor que implementa la interfaz remota. 3. Se desarrolla el cliente. 4. Se c ompilan los ficheros J ava fuentes. 5. Se ejec uta el RMI Registry en el procesador remoto. 6. Se ejec uta el servidor en el procesador remoto. 7. Se ejec uta el cliente en el procesador local.
3.6 PASO DE PARAMETROS El paso de parámetros es el mecanismo mediante el que se pasa información a un subprograma.
Una precaución que hay que tener en cuenta es que, bajo algunas circunstancias, un subprograma puede modificar el valor de las variables pasadas como parámetros. Algunas veces esto es deseable, y otras vec es no lo es. -Los métodos remotos pueden tener como parámetro o como valor de retorno cualquier clase de objeto siempre que sea serializarle. Esto es, o es primitivo o implementa la interfaz java.io.Serializable.
-Un objeto no remoto que es pa sado c omo parámetro o resultado en la invoc ación de un método es pasado por copia.
-Cuando un objeto no remoto es pasado como parámetro, es primero serializado, luego es transferido a la J VM remota y luego se invoc a el método hac iendo referencia a la copia. -Cuando un objeto no remoto es retornado como resultado por un método, se serializa el objeto, se
transfiere a la J VM local y luego se retorna la referencia de la copia al thread que invoc ó.
-Cuando un objeto es transferido de una J VM a otra, también transfiere la anotación de la clase que implementa el objeto, así que la clase y sus métodos pueden ser carga do en la J VM que lo rec ibe.
Dos maneras de pasar parámetros a métodos remotos: -Por Valor: se inserta una copia “secuenciada” del objeto en el flujo de salida que corresponde al envío de la invocación o el retorno es el objeto remoto el que viaja.
-Por Referencia: se inserta una copia “secuenciada” del stub del objeto en el flujo de salida que corresponde al envío de la invocación o el retorno es el stub del objeto remoto (instancia de la clase stub) el que viaja.
3.7 CALLBACKS Como la palabra en inglés lo indica un callback es una “llamada de vuelta” y este es un concepto importante al momento de escribir código. Es simple: llamo a una funcion y le envío por parámetro otra función (un callback) esperando que la función que llamé se encargue de ejec utar esa función c allba ck.
Pero callback no significa que se va a llamar cuando algo termine, simplemente se puede tener distintos callbacks que se van llamando en determinados casos.
Callback de Cliente 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 callbacks, de forma que el servidor pueda llevar a cabo un invocación al método del cliente c uando el evento oc urra.
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, sólo permite invocación de métodos remotos de clientes en objetos
servidores, se necesita claramente sintaxis adicional para da r soporte a esta nueva carac terí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.
INTERFAZ DEL CALLBACK -El servidor ofrece un método remoto para que el c liente registre sus c allbacks.
-Hay que diseñar una interfaz remota para el callback.
-La interfaz debe incluir un método que será invocado en el callback desde el servidor. El cliente deberá de ser una Subclase de RemoteObject e implementaría la interfaz de c allback.
-El cliente se registrara frente a la clase remota para así ser rellamado.
-El servidor invoc a el método remoto del cliente en caso de apa rec er al evento indicado.
