TECNOLÓGICO DE ESTUDIOS SUPERIORES DE

CHALCO
INGENIERÍA INFORMÀTICA
SEMESTRE 2020-6

3.2. El API Java RMI.

Materia: Programación en ambiente cliente/servidor

Docente: Emmanuel Espinoza Sandoval
Alumno (s):
Beatriz Campos Flores
Grupo: 6651

Chalco, Estado de México, a 22 de octubre del 2020.

INTRODUCCION---------------------------------------------------------3

TEMA-------------------------------------------------------------------------4

API DE JAVA RMI--------------------------------------------------------4

REMOTE METHOD INVOCATION (RMI) --------------------------4

CLASE DE API JAVA RMI----------------------------------------------7

INTERFACES DE API JAVA RMI-------------------------------------8

EJEMPLOS------------------------------------------------------------------10

CONCLUSION--------------------------------------------------------------12

BIBLIOGRAFIA-------------------------------------------------------------13

2
Dentro de los complementos que nos ofrece Java como entorno de programación,
nos encontramos con las API´s de Java RMI.

Un paquete Java es una forma de agrupar las interfaces y las clases relacionadas
en Java. Los paquetes Java son parecidos a las bibliotecas de clases existentes en
otros lenguajes.

Los paquetes Java, que proporcionan las API Java, las cuales forman parte del Java
Development Kit (JDK) de Sun Microsystems, Inc.

Nos proporciona un mecanismo para facilitar la elaboración de aplicaciones

distribuidas. Integrado dentro de la jerarquía de paquetes oficiales del lenguaje de
programación Java, se adapta perfectamente al modelo de programación de dicho
lenguaje.

Una llamada remota a método es una llamada a un método de un objeto desde un

espacio de direcciones donde éste no reside. Java permite trabajar con objetos en
ubicaciones remotas como si estuvieran en el espacio de direcciones local, es decir,
con la misma sintaxis que tiene las llamadas locales. De esta forma se consigue
una total transparencia cara al programador.

3
El uso de sockets permite la elaboración de aplicaciones distribuidas. Sin embargo,
en ocasiones, son necesarios enfoques con un mayor grado de abstracción que el
proporcionado por éstos. Al utilizar sockets, las aplicaciones deben desarrollar sus
propios mecanismos para manejar de forma eficiente los mensajes intercambiados,
con la consecuente complicación que esto conlleva.
La API RMI (Remote Method Invacation) proporciona un mecanismo para facilitar la
elaboración de aplicaciones distribuidas. Integrado dentro de la jerarquía de
paquetes oficiales del lenguaje de programación Java, se adapta perfectamente al
modelo de programación de dicho lenguaje.

Como ya se ha comentado, la programación orientada a objetos se adapta de

manera natural a la programación de aplicaciones distribuidas. En la programación
orientada a objetos, tareas parciales de un problema pueden ser modeladas como
entidades, que llamaremos objetos, que se comunican entre ellos durante su
ejecución. En consecuencia, el uso de programación orientada a objetos, resulta
una evolución natural en el desarollo de aplicaciones distribuidas; de forma que
tareas parciales, que ahora estarán ubicadas en distintas máquinas, son modeladas
como objetos que intercambian mensajes a través de la red. RMI integra este
concepto en el lenguaje de programación Java, de manera que el manejo de objetos
en aplicaciones distribuidas mantenga la semántica propia de los objetos locales de
Java. En consecuencia, RMI puede ser fácilmente 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. En
definitiva, RMI proporciona un modelo propio de objetos distribuidos, optimizado
para las características de Java.

En el modelo de objetos distribuidos de Java, un objeto distribuido es aquel cuyos

métodos pueden llamarse desde otra Máquina Virtual Java (JVM), que puede estar
ejecutándose en otro host. Por lo tanto, un objeto remoto ubicado en un proceso

4
puede recibir llamadas desde otros procesos que se estén ejecutando en diferentes
espacios de direcciones (es decir, en diferentes máquinas).
Una clase remota es cualquier clase cuyas instancias son objetos remotos. Desde
el punto de vista de la máquina virtual que crea instancias de objetos remotos, éstos
son objetos ``normales''. Se podrán usar como cualquier otro objeto.

Una llamada remota a método es una llamada a un método de un objeto desde un

espacio de direcciones donde éste no reside. Java permite trabajar con objetos en
ubicaciones remotas como si estuvieran en el espacio de direcciones local, es decir,
con la misma sintaxis que tiene las llamadas locales. De esta forma se consigue
una total transparencia cara al programador.

Una característica adicional del modelo de objetos remotos de Java es la utilización

de interfaces para la manipulación de estos objetos. Cuando un proceso actuando
como cliente quiere instanciar un objeto, que para él será remoto, ubicado en un
servidor; no instancia directamente a éste, sino a un intefaz del mismo denominada
interfaz remota. Un cliente únicamente necesita una interfaz remota para poder
invocar los métodos de un objeto remoto.

El uso de interfaces remotas proporciona una serie de ventajas, como son: las
implementaciones de los métodos no son visibles por los clientes y no hace falta
comunicar a los clientes cambios realizados en las implementaciones de los
métodos.

Es común hablar de RMI como un middleware, en el sentido que se comporta como

un software que separa las comunicaciones entre clientes y servidores de los
protocolos de red y los mecanismos de comunicación entre procesos.[6] La figura
3.1 muestra este concepto.

5
Típicamente, una aplicación RMI está compuesta de un cliente y un servidor. El
servidor se encarga de crear los objetos remotos, hacerlos accesibles y permanecer
a la espera de llamadas para esos objetos remotos. El cliente debe conseguir
referencias para esos objetos remotos y, en ese momento, puede hacer uso de ellas
para realizar llamadas remotas. Las aplicaciones con objetos distribuidos necesitan:

Localizar los objetos remotos.- Para ello pueden hacer uso de la utilidad de
búsqueda por nombres propia de RMI, rmiregistry.
Comunicar con los objetos remotos.- Los detalles de la comunicación entre objetos
remotos quedan a cargo de RMI. Para el programador, la invocación remota de
métodos es como la estándar.
Cargar el código de las clases para los objetos remotos.- RMI permite no sólo el
paso de objetos completos hacia y desde los procesos remotos sino, además, la
descarga de las clases que implementan dichos objetos desde ubicaciones
remotas.
En la práctica, la comunicación entre clientes y servidores no es directa, siempre
media entre ambos unos elementos suplentes que se conocen como stub y
skeleton.

Un stub actúa como un proxy local de un objeto remoto. Debe implementar las
mismas interfaces remotas que implementa el objeto al que representa.

Cuando un objeto local llama a un método de la interfaz remota de un objeto, esta

llamada se realiza en realidad sobre los métodos del stub local, desde donde se
transmite hasta el objeto remoto. Por lo tanto, no hay comunicación directa entre

6
objetos locales y remotos sino que se realiza a través de los elementos suplentes.
El stub se encarga de realizar la conexión con la máquina virtual remota, enviar los
argumentos para el método especificado, esperar la respuesta y pasársela al objeto
local. El skeleton es la contrapartida del stub, es decir, actúa como proxy del objeto
remoto en el lado servidor. Se encarga de recibir las peticiones dirigidas al objeto
servidor y devolver los resultados a quien hizo la petición. En las versiones actuales
del JDK (Java Development Kit) no es necesaria la utilización de los elementos
skeleton.

Muestra la operación completa de una llamada RMI.

7
Paquetes, clases e interfaces básicos:
java.rmi: clases, interfaces y excepciones manejadas t´ıpicamente
por los clientes
• Interfaz Remote: interfaz base a implementar/extender por los objetos remotos
• Excepci´on RemoteException: base de las excepciones lanzadas por los objetos
remotos
• Clase Naming: clase de apoyo para acceder al servicio de nombres rmiregistry
• Clase RMISecurityManager: gestor de seguridad para aplicaciones RMI
java.rmi.server: clases, interfaces y excepciones manejadas t´ıpicamente
por los servidores
• Clase RemoteObject: implementaci´on de m´etodos b´asicos para objetos remotos
(hashCode(),
equals())

8
• Clase RemoteServer: superclase base para las implementaciones de objetos
remotos
• Clase UnicastRemoteObject: usada para crear y exportar objetos remotos con
JRMP y
obtener un stub que se comunicar´a con ese objeto remoto
• Clase RMIClassLoader: cargador de clases (bytecodes) desde origenes remotos
◦ necesario para deserializar stubs y objetos serializados recibidos como
par´ametro
• Clase ObjID: clase que encapsula un identificador ´unico para objetos
• Clase RemoteStub: superclase de la que heredan las implementaciones de stubs
• Interface RemoteRef, ServerRef: gesti´on de referencias remotas
java.rmi.registry: clases, interfaces y excepciones necesarios
para registrar y localizar objetos remotos
• Interface Registry: definici´on del interfaz remoto de rmiregistry
• Clase LocateRegistry: clase con m´etodos para creaci´on y consulta de servidores
de nombres
java.rmi.dgc: clases, interfaces y excepciones para dar soporte a
la recolecci´on de basura distribuida
java.rmi.activation: clases, interfaces y excepciones para dar
soporte a la activaci´on de objetos remotos
• Clase Activatable: usadas en la creaci´on y exportaci´on de objetos remotos
activables
Elementos adicionales
Servicio de nombres. Asocia nombres l´ogicos a los objetos remotos
exportados (stubs)
Servidor: asocia un nombre al objeto remoto (registro) [bind()]
Cliente: obtiene una referencia al objeto remoto (stub) a partir
de ese nombre [lookup()]
Objetivo: ofrecer transparencia de ubicaci´on
Evitar que el cliente tenga que ser recompilado si el objeto remoto
pasa a ejecutarse en otra m´aquina virtual (JVM)

nombre de objeto remoto

referencia remota (stub) serializada

Funcionamiento del proceso bind()

Toma un objeto de la clase que implementa el interfaz Remote
Si es necesario se construye internamente una instancia de

autom´aticamente [Java 1.5]

desde clase stub generada por rmic)
Serializa esa instancia de RemoteStub y la env´ıa al registro
asociada a un nombre

Funcionamiento del proceso bind()

Toma un objeto de la clase que implementa el interfaz Remote
Si es necesario se construye internamente una instancia de

9
autom´aticamente [Java 1.5]
desde clase stub generada por rmic)
Serializa esa instancia de RemoteStub y la env´ıa al registro
asociada a un nombre

Un servidor RMI consiste en definir un objeto remoto que va a ser utilizado por los
clientes. Para crear un objeto remoto, se define una interfaz, y el objeto remoto será
una clase que implemente dicha interfaz. Veamos cómo crear un servidor de
ejemplo mediante 3 pasos:
Definir la interfaz remota. Cuando se crea una interfaz remota:
La interfaz debe ser pública.
Debe heredar de la interfaz java.rmi.Remote, para indicar que puede llamarse desde
cualquier máquina virtual Java.
Cada método remoto debe lanzar la excepción java.rmi.RemoteException en su
cláusula throws, además de las excepciones que pueda manejar.

En este apartado se explicará, con un ejemplo concreto, los pasos seguidos para
elaborar una aplicación con objetos distribuidos RMI. Esta aplicación ejemplo
proporcionará un servicio que acepta peticiones de tareas concretas especificadas
por parte de los clientes. Es decir, cada cliente puede especificar la tarea que desea
que el servidor le realice, utilizando para ello el paso de objetos serializados.
La figura A.1 muestra un esquema del proceso paso por paso en la elaboración de
una aplicación RMI.

10
Ejemplo: CalculadoraImpl.java (opcion 1)
import java.rmi.RemoteException;
import java.rmi.server.UnicastRemoteObject;
public class CalculadoraImpl extends UnicastRemoteObject implements
Calculadora {
private int contadorPeticiones;
public CalculadoraImpl() throws RemoteException {
super();
contadorPeticiones = 0;
}
public int sumar(int a, int b) throws RemoteException {
contadorPeticiones++;
return(a+b);
}
...
}
Compilaci´on: $ javac CalculadoraImpl.java

11
Cuales se usan en el cliente y cuales se usan en el servidor.
La primera capa es la de aplicación y se corresponde con la implementación real de
las aplicaciones cliente y servidor. Aquí tienen lugar las llamadas a alto nivel para
acceder y exportar objetos remotos. Cualquier aplicación que quiera que sus
métodos estén disponibles para su acceso por clientes remotos debe declarar
dichos métodos en una interfaz que extienda java.rmi.Remote. Dicha interfaz se usa
básicamente para "marcar" un objeto como remotamente accesible. Una vez que
los métodos han sido implementados, el objeto debe ser exportado. Esto puede
hacerse de forma implícita si el objeto extiende la clase UnicastRemoteObject
(paquete java.rmi.server), o puede hacerse de forma explícita con una llamada al
método exportObject() del mismo paquete.

La capa 2 es la capa proxy, o capa stub-skeleton. Esta capa es la que interactúa

directamente con la capa de aplicación. Todas las llamadas a objetos remotos y
acciones junto con sus parámetros y retorno de objetos tienen lugar en esta capa.

La capa 3 es la de referencia remota, y es responsable del manejo de la parte

semántica de las invocaciones remotas. También es responsable de la gestión de
la replicación de objetos y realización de tareas específicas de la implementación
con los objetos remotos, como el establecimiento de las persistencias semánticas y
estrategias adecuadas para la recuperación de conexiones perdidas. En esta capa
se espera una conexión de tipo stream (stream-oriented connection) desde la capa
de transporte.

La capa 4 es la de transporte. Es la responsable de realizar las conexiones

necesarias y manejo del transporte de los datos de una máquina a otra. El protocolo
de transporte subyacente para RMI es JRMP (Java Remote Method Protocol), que
solamente es "comprendido" por programas Java.

Toda aplicación RMI normalmente se descompone en 2 partes:

Un servidor, que crea algunos objetos remotos, crea referencias para hacerlos
accesibles, y espera a que el cliente los invoque.
Un cliente, que obtiene una referencia a objetos remotos en el servidor, y los invoca.

12
http://www.iuma.ulpgc.es/users/lhdez/inves/pfcs/memoria-domingo/node17.html

https://es.wikipedia.org/wiki/Java_Remote_Method_Invocation

http://ccia.ei.uvigo.es/docencia/SCS/0910/transparencias/Tema3-1.pdf

13