Instituto tecnológico superior de Cintalapa
Programación cliente servidor
Investigación RMI (Remote Method Invocation)
Luis German Montesinos Alfaro
Juan Ignacio Zamora Chacón
Ing. Informática
Grupo: E Semestre: 7°
Cintalapa de Figueroa, Chiapas, México a 12 de Octubre del 2021
Introducción
En las siguientes paginas encontraremos el resumen de la investigación sobre
RMI (Remote Method Invocation) el cual es un mecanismo el cual permite la
comunicación entre dos máquinas las cuales corran java virtual machines
(máquinas virtuales de java). Este mecanismo funciona permitiendo invocar o
llamar a métodos u servicios, desde una maquina a otra. Esto facilita en gran
medida el uso de programas o código, el lenguaje sobre el cual se corre este
mecanismo es java, lenguaje perteneciente a la corporación o empresa Oracle.
A continuación, nos adentraremos más en estos temas com por ejemplo
tocaremos temas como la estructura de RMI y la api en java de RMI, entre otros
temas procedentes del tema central RMI (Remote Method Invocation).
3.1. Características y Estructura de RMI
RMI es un mecanismo para la comunicación (solo) entre dos máquinas corriendo
máquinas virtuales java. Cuando el código java en la maquina A necesita un
servicio o un método, respectivamente, del (objeto remoto java) objB en la
maquina B iniciara un método de invocación. Hace esto de la misma manera que
invoca el método de un objeto java (local). La comunicación entera detrás de la
invocación remota es realizada por el mecanismo de RMI.
RMI se caracteriza por la facilidad de su uso en la programación por estar
específicamente diseñado para Java; proporciona paso de objetos por referencia
(no permitido por SOAP), recolección de basura distribuida (Garbage Collector
distribuido) y paso de tipos arbitrarios (funcionalidad no provista por CORBA).
A través de RMI, un programa Java puede exportar un objeto, con lo que dicho
objeto estará accesible a través de la red y el programa permanece a la espera de
peticiones en un puerto TCP. A partir de ese momento, un cliente puede
conectarse e invocar los métodos proporcionados por el objeto.
Como RMI trabaja
Cuando se hace referencia a un objeto remoto que reside en la máquina B desde
el código que está en la máquina A, siempre hay dos objetos intermedios que
realmente manejan la comunicación: un objeto stub y un objeto esqueleto (o
skeleton). Cuando surge una invocación de método remoto, estos dos objetos la
manejan.
El objeto stub (en la maquina A) tiene que
Construir un bloque de información que consista en
Un identificador del objeto remoto que será usado.
Un numero de operación que describirá el método que se llamará y el los
parámetros calculados (los parámetros del método deben codificarse en un
formato adecuado para transportarlos a través de la red).
Enviar esta información al server.
Las tareas del objeto skeleton (en la maquina B) son
Desarmar los parámetros.
Llamar el método deseado en el objeto real que se encuentra en el servidor.
Capturar los valores retornado o las excepciones de la llamada en el server.
Marcar este valor.
enviar un paquete que consta del valor en el formulario ordenado de vuelta al stub
en el cliente, la máquina A.
El objeto de código auxiliar anula el valor de retorno o la excepción del servidor.
Este valor se convierte en el valor de retorno de la invocación del método remoto.
O, si el método remoto arrojó una excepción, el código auxiliar (objeto) lo vuelve a
lanzar en el espacio de proceso de la persona que llama.
3.2. El API Java RMI.
La invocación de método remoto (RMI) es una API que permite que un objeto
invoque un método en un objeto que existe en otro espacio de direcciones, que
podría estar en la misma máquina o en una máquina remota. A través de RMI, el
objeto que se ejecuta en una JVM presente en una computadora (lado del cliente)
puede invocar métodos en un objeto presente en otra JVM (lado del servidor). RMI
crea un objeto de servidor remoto público que permite las comunicaciones del lado
del cliente y del servidor a través de llamadas a métodos simples en el objeto del
servidor.
3.3. Jerarquía de objetos RMI.
El RMI utiliza el mismo mecanismo que los sistemas RPC para implementar la
comunicación con los objetos remotos, el basado en stubs y skeletons. En RMI al
Proxy cliente se le llama stub y al stub servidor se le denomina skeleton.
Los stubs actúan como representantes de los objetos remotos ante sus clientes.
En el cliente se invocan los métodos del stub, quien es el responsable de invocar
de manera remota al código que implementa el objeto remoto.
Cuando se invoca algún método de un stub, este realiza las siguientes acciones:
1. Inicia una conexión con la Máquina virtual que contiene al objeto remoto.
2. Empaqueta (marshaling) y transmite los parámetros de la invocación a la
Máquina Virtual remota.
3. Espera por el resultado de la invocación.
4. Desempaqueta (unmarshals) y devuelve el valor de retorno o la excepción.
5. Devuelve el valor a quien lo llamó.
Los stubs se encargan de ocultar el empaquetado de los parámetros, así como los
mecanismos de comunicación empleados. En la Máquina Virtual remota, cada
objeto debe poseer su esqueleto. Este es el responsable de despachar la
invocación al objeto remoto.
3.4. El Sistema de Nombrado Registry.
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. Desarrollo de 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 protocolos de comunicaciones bien establecidos.
Componentes:
Clientes: Conducen el flujo de la aplicación. Localizan e invocan métodos
ofertados como los métodos remotos por los servidores.
Servidores: Conjunto de objetos que ofrecen interfaces remotas públicas cuyos
métodos pueden ser involucrados por clientes de cualquier procesador.
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 parámetros a través.
RMI depende enteramente de la capacidad para enviar objetos a y desde métodos
en máquinas remotas. RMI asume una arquitectura orientada a objetos. Cualquier
objeto que se envía como parámetro a un objeto remoto lo hace por valor. Esto
significa que se pasa una copia del objeto, no el original o una referencia al
original. La excepción a esta regla es un objeto que haya sido exportado como un
objeto remoto (objeto que implementa métodos remotos). En este caso, al cliente
se le envía un proxy o stub que representa un objeto que reside en el host, o
máquina servidor. Cualquier interacción con el stub es enviada al original, que es
quién realiza realmente cualquier operación que sea requerida por el stub.
Cuando se envían estructuras de datos desde una máquina a otra, dichos datos
se deben codificar de cierta manera para que puedan ser enviados a través de la
red. Esto normalmente implica implementar un protocolo de transmisión,
incluyendo algún tipo de marcas para delimitar los campos y registros enviados.
Las conexiones de red son, en su mayor parte, en serie, y los datos deben
transformarse antes de que sean transmitidos a través de las conexiones serie.
El modelo RMI asume una plataforma homogénea, la plataforma Java. Pero
incluso asumiendo un entorno homogéneo, se debe desarrollar un protocolo para
manejar el desensamblado, transmisión y reconstrucción de los datos. La
serialización de objetos hace referencia a los métodos usados para duplicar un
objeto escribiendo los valores de sus campos en un flujo de datos y recreando una
copia de dicho objeto a partir de dichos valores de campos.
Es importante destacar que la reconstrucción del objeto obtiene una copia, no el
objeto original. Los objetos serializados son siempre copias del original. Cuando
se necesite enviar una referencia a un objeto, en vez de una copia, se debe usar
un objeto remoto, es decir, un objeto exportado de forma implícita extendiendo la
clase [Link], o explícitamente utilizando
[Link](Remote), y en cualquier caso, debe
implementar una interfaz remota.
Conclusión
El mecanismo RMI (Remote Method Invocation) es una herramienta de mucha
utilidad la cual nos permitiría poder hacer uso de servicios y métodos
almacenados en otras máquinas las cuales este corriendo virtual machine java,
esto puede ser de gran ayuda en escenarios como la que una aplicación o servicio
necesite realizar una función, para la cual no tiene el método, pero puede
contactar con la maquina que si lo tiene.
Uno de los principales aspectos del RMI es su estructura la cual se compone de
dos elementos el stub y el skeleton, las cuales son las dos parte que realizan las
actividades para permitir la comunicación entre los dos puntos o las dos máquinas.
Bibliografía
GeeksforGeeks. (2018, February 9). Remote Method Invocation in Java.
[Link]
email: feedback@[Link]
ubicación: 5th Floor, A-118, Sector-136, Noida, Uttar Pradesh – 201305
O.C. (2017, November 7). Java SE Remote Method Invocation APIs and
Developer Guides. Docs Oracle.
[Link]
Cay S. Horstmann and Gary Cornell, core JAVA 1.1, Volume II - Advanced
Features, The Sunsoft Press, 1998, pp.224-263.
Java, T. M., & Tarr, B. (2009). Remote Method Invocation. Available on line, 4(06),
04.
Narasimhan, N., Moser, L. E., & Melliar‐Smith, P. M. (2001). Interceptors for Java
remote method invocation. Concurrency and Computation: Practice and
Experience, 13(8‐9), 755-774.