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 comunicación de servidores en aplicaciones distribuidas basadas
exclusivamente en JAVA

CARACTERÍSTICAS:
• Facilidad de uso en la programación por estar específicamente diseñado para
JAVA
• Proporciona paso de objeto por referencia
• Recolección de basura distribuida
• Paso de tipos arbitrarios

INVOCACIÓN
1) Encapsulado de los parámetros
2) invocación del método (del cliente con el servidor). El invocador se queda
esperando una respuesta.
3) Al terminar la ejecución, el servidor realiza el valor de retorno y lo envía al cliente
4) El código cliente recibe la respuesta y continúa como si la invocación hubiera sido
local.

ARQUITECTURA Puede verse como un modelo de cuatro capas

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 re
3.2 El API Java RMI Es una interfaz de programación de aplicaciones provistas por
los creadores del lenguaje JAVA, y que da a los programadores los medios para
desarrollar aplicaciones javas. La API de JAVA provee un conjunto de clases
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:
-Java.rmi
-Java.rmi.server
-Java.rmi.registry
-Java.rmi.activation
-Java.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í, Java no la reconocerá como
tal.
-Mediante una instancia de la clase MarshalledObject se puede manejar el flujo de
bytes serializados de un objeto.
-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)
throwsAlreadyBoundException,MalformedURLException, RemoteException
-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.
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.
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.
-Clase RemoteObject: Implementa la clase java.lang.Object 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.
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.
Java.rmi.dgc Este paquete contiene clases, interfaces y excepciones para la
recoleccion de basura
3.3 JERARQUIA DE OBJETOS RMI

3.4 EL SISTEMA DE NOMBRADO REGISTRY

¿Qué 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 ejecutan 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 pro Registro: Servicio estático que
se establece en cada 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 protocolo define el tipo de mensajes intercambiados; 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 compilan los ficheros Java fuentes.
5. Se ejecuta el RMI Registry en el procesador remoto.
6. Se ejecuta el servidor en el procesador remoto.
7. Se ejecuta 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 veces 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 pasado como parámetro o resultado en la invocació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 JVM remota y luego se invoca el método haciendo
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 JVM local y luego se retorna la referencia de la
copia al thread que invocó.
-Cuando un objeto es transferido de una JVM 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
cargado en la JVM que lo recibe. 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 ejecutar esa función callback. 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 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, 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.

INTERFAZ DEL CALLBACK -El servidor ofrece un método remoto para que el
cliente registre sus callbacks. -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 callback.
-El cliente se registrara frente a la clase remota para así ser rellamado.
-El servidor invoca el método remoto del cliente en caso de aparecer al evento
indicado.