Invocación Remota de Métodos (RMI)

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

Las aplicaciones de objetos distribuidos necesitan.

Localizar Objetos Remotos
Las aplicaciones pueden utilizar uno de los dos mecanismos para obtener referencias a objetos remotos. Puede registrar sus objetos remotos con la facilidad de nombrado de RMI rmiregistry. O puede pasar y devolver referencias de objetos remotos como parte de su operaci�n normal.
Comunicar con Objetos Remotos
Los detalles de la comunicaci�n entre objetos remotos son manejados por el RMI; para el programador, la comunicaci�n remota se parecer� a una ll�mada est�ndard a un m�todo Java.
Cargar Bytecodes para objetos que son enviados.
Como RMI permite al llamador pasar objetos Java a objetos remotos, RMI proporciona el mecanismo necesario para cargar el c�digo del objeto, as� como la transmisi�n de sus datos.

La siguiente ilustraci�n muestra una aplicaci�n RMI distribuida que utiliza el registro para obtener referencias a objetos remotos. El servidor llama al registro para asociar un nombre con un objeto remoto. El cliente busca el objeto remoto por su nombre en el registro del servidor y luego llama a un m�todo. Esta ilustraci�n tambi�n muestra que el sistema RMI utiliza una servidor Web existente para cargar los bytecodes de la clase Java, desde el servidor al cliente y desde el cliente al servidor, para los objetos que necesita.

El sistema RMI utiliza un servidor Web para cargar los bytecodes de la clase Java, desde el servidor al cliente y desde el cliente al servidor.

.�Ventajas de la Carga Din�mica de C�digo

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

.�Interfaces, Objetos y M�todos Remotos

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

Un objeto se convierte en remoto implementando un interface remoto, que tenga estas caracter�sitcas.

  • Un interface remoto desciende del interface java.rmi.Remote.
  • Cada m�todo del interface declara que lanza una java.rmi.RemoteException adem�s de cualquier excepci�n espec�fica de la aplicaci�n.

El RMI trata a un objeto remoto de forma diferente a como lo hace con los objetos no-remotos cuando el objeto es pasado desde una m�quina virtual a otra. En vez de hacer una copia de la implementaci�n del objeto en la m�quina virtual que lo recibe, RMI pasa un stub para un objeto remoto. El stub act�a como la representaci�n local o proxy del objeto remoto y b�sicamente, para el llamador, es la referencia remota. El llamador invoca un m�todo en el stub local que es responsable de llevar a cabo la llamada al objeto remoto.

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

.�Crear Aplicaciones Distribuidas utilizando RMI

Cuando se utiliza RMI para desarrollar una aplicaci�n distribuida, debemos seguir estos pasos generales.

  1. Dise�ar e implementar los componentes de nuestra aplicaci�n distribuida.
  2. Compilar los Fuentes y generar stubs.
  3. Hacer las clases Accesibles a la Red.
  4. Arrancar la Aplicaci�n.

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

Primero, decidimos la arquitectura de nuestra aplicaci�n y determinamos qu� componentes son objetos lcoales y cuales deber�an ser accesibles remotamente. Este paso incluye.

  • Definir los Interfaces Remotos. Un interface remoto especifica los m�todos que pueden ser llamados remotamente por un cliente. Los clientes programan los interfaces remotos, no la implementaci�n de las clases de dichos interfaces. Parte del dise�o de dichos interfaces es la determinaci�n de cualquier objeto local que sea utilizado como par�metro y los valores de retorno de esos m�todos; si alguno de esos interfaces o clases no existen a�n tambi�n tenemos que definirlos.
  • Implementar los Objetos Remotos. Los objetos remotos deben implementar uno o varios interfaces remotos. La clase del objeto remoto podr�a incluir implementaciones de otros interfaces (locales o remotos) y otros m�todos (que s�lo estar�n disponibles localmente). Si alguna clase local va a ser utilizada como par�metro o c�mo valor de retorno de alguno de esos m�todos, tambi�n debe ser implementada.
  • Implementar los Clientes. Los clientes que utilizan objetos remotos pueden ser implementados despu�s de haber definido los interfaces remotos, incluso despu�s de que los objetos remotos hayan sido desplegados.

.�Compilar los Fuentes y Generar stubs.

Este es un proceso de dos pasos. En el primer paso, se utiliza el compilador javac para compilar los ficheros fuentes de Java, los cuales contienen las implementaciones de los interfaces remotos, las clases del servidor, y del cliente. En el segundo paso es utilizar el compilador rmic para crear los stubs de los objetos remotos. RMI utiliza una clase stub del objeto remoto como un proxy en el cliente para que los clientes puedan comunicarse con un objeto remoto particular.

.�Hacer accesibles las Clases en la Red.

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

.�Arrancar la Aplicaci�n.

Arrancar la aplicaci�n incluye ejecutar el registro de objetos remotos de RMI, el servidor y el cliente.

El resto de este cap�tulo muestra c�mo seguir estos pasos para crear un motor de c�lculo.

.�Construir un Motor de C�lculo Gen�rico

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

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

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

COMPARTE ESTE ARTÍCULO

COMPARTIR EN FACEBOOK
COMPARTIR EN TWITTER
COMPARTIR EN LINKEDIN
COMPARTIR EN WHATSAPP
ARTÍCULO ANTERIOR

SIGUIENTE ARTÍCULO