OBJETOS DISTRIBUIDOS E

INVOCACIÓN REMOTA

INTEGRANTES:
DAVID ALVAREZ
LUIS ALVEAR
OLGA AVALOS
JUAN PABLO CHIMBORAZO
INTRODUCCIÓN (I)
MODELOS DE PROGRAMACIÓN.

Llamada a procedimiento remoto (RPC),

programa cliente llama a procedimiento de
programas servidores.
Invocación a un método remoto (RMI), objeto
de un proceso, invoca a métodos de otros
procesos.
Basado en eventos, recibe notificaciones de
eventos en otros objetos.
INTRODUCCIÓN (II)
MIDDLEWARE.
Emplea protocolos basados en mensajes
entre procesos para proporcionar
abstracciones de un nivel mayor, tales
como invocaciones remotas y eventos.
Aplicaciones
RMI, RPC y eventos
Protocolo petición respuesta Capas de
middleware
Representación externa de datos
Sistema operativo
 INTRODUCCIÓN (III)
MIDDLEWARE.
◦ Transparencia frente a ubicación (no se necesita
conocer la ubicación del procedimiento).
◦ Protocolos de comunicación (son independientes del
protocolo de Transporte que use, petición-repuesta).
◦ Hardware de los computadores (se usa el empaquetado
y desempaquetado de mensajes, oculta diferencias en
HD, como el ordenamiento de los bits).
◦ Sistemas operativos.
◦ Utilización de diversos lenguajes de programación.
COMUNICACIÓN ENTRE OBJETOS
DISTRIBUIDOS
MODELO DE OBJETOS
Referencias a Objetos
Interfaces
Acciones
Excepciones
Compactación Automática de la memoria
OBJETOS DISTRIBUIDOS
Pueden adoptar el modelo cliente – servidor.
Permiten cadena de invocación relacionada
Los objetos pueden estar replicados
Objetos cliente-servidor en diferentes procesos,
promueve la encapsulación.
- Métodos para protegerse contra accesos
incorrectos
- Ventaja para los sistemas heterogeneos en los
que se pueden usar diferentes formatos de datos
en diferentes lugares
MODELO DE OBJETOS
DISTRIBUIDOS
 Referencia de Objeto Remoto
Las referencias a los objetos remotos son
análogas a las locales en cuanto a que:
1. El objeto remoto donde se recibe la
invocación de método remoto se especifica
mediante una referencia a objeto remoto
MODELO DE OBJETOS
DISTRIBUIDOS
2.- Las referencias a objetos remotos
pueden pasarse con argumentos y
resultados de la invocación de métodos
remotos
 Interfaz Remota
 Acciones
 Compactación Automática de memoria
 Excepciones
CUESTIONES DE DISEÑO PARA
RMI
A pesar de que las invocaciones locales se
ejecutan exactamente una sola vez,
pudiera no ser siempre este el caso para
las invocaciones de métodos remotos. Se
discutirán las alternativas
El nivel de transparencia deseable para
RMI
CUESTIONES DE DISEÑO PARA
RMI
Semántica de la invocación RMI:
- Reintento del mensaje de petición.
- Filtrado de duplicados
- Retransmisión de resultados.
CUESTIONES DE DISEÑO PARA
RMI
Semántica de invocación pudiera ser:
Fallos de omisión si se pierde la
invocación o el mensaje con el resultado.
Fallos por caída cuando el servidor que
contiene el objeto falla.
CUESTIONES DE DISEÑO PARA
RMI
Semántica de invocación al menos una vez:
Fallos por caída cuando el servidor que
contiene el objeto remoto falla.
Fallos arbitrarios: En caso donde el
mensaje de invocación se retransmite, el
objeto remoto puede recibirlo y ejecutar
el método más de una vez, provocando
que se almacenen o devuelvan valores
posiblemente erróneos.
CUESTIONES DE DISEÑO PARA
RMI
Semántica de invocación como máximo una
vez: Previene fallos como
Fallos arbitrarios al asegurar que para
cada RMI no se ejecuta el método más de
una sola vez.
Fallos de omisión si se pierde la
invocación o el mensaje con el resultado.
CUESTIONES DE DISEÑO PARA
RMI
TRANSPARENCIA:
Las invocaciones remotas son más
vulnerables a fallos que las locales, puesto
que involucran una red, otro computador,
y otro proceso. Cualquiera que sea la
semántica, siempre es posible que no se
reciba resultado alguno, y en caso de fallo
es imposible distinguir entre el fallo de la
red o del proceso remoto.
CUESTIONES DE DISEÑO
PARA RMI
Esto requiere que los objetos que hacen
invocaciones remotas sean capaces de
recuperarse de tales situaciones. La
latencia de una invocación remota está en
varios órdenes de magnitud mayor que la
de una local
CUESTIONES DE DISEÑO
PARA RMI
El consenso actual parece ser que las
invocaciones remotas deben ser
transparentes en el sentido que la sintaxis
de la invocación remota sea la misma que
en la invocación local, pero la diferencia
entre objetos locales y remotos debe
indicarse en sus interfaces.
IMPLEMENTACION DE RMI
Objetos y módulos involucrados en la
invocación de métodos remotos
Cliente Servidor

Proxy
Objeto A para B Esqueleto y Objeto B
Petición despachador para
la clase de B

Respuesta

Modulo de Modulo de Modulo de Modulo de

referencia remota comunicación comunicación referencia remota
IMPLEMENTACION DE RMI
 Modulo de Comunicación
◦ Es el encargado de transmitir los mensajes de Petición y
respuesta entre el cliente y el servidor.
 Modulo de Referencia Remota
◦ Es responsable de traducir las referencias entre objetos
locales y remotos, y de crear referencias a objetos remotos.
 El software RMI
◦ Es una capa entre los objetos del nivel de aplicación y los
módulos de comunicación y de referencia remota y
especifica los papeles que deben cumplir los siguientes
elementos de middleware:
 Proxy
 Distribuidor
 Esqueleto
IMPLEMENTACION DE RMI
Generación de las clases para cada proxy,
distribuidor y esqueleto
◦ Estas clases se generan automáticamente
mediante un compilador de interfaces.
Programas cliente y servidor
◦ El Programa servidor contiene las clases para
los distribuidores y esqueletos.
◦ El programa cliente contiene las clases para
cada proxy.
IMPLEMENTACION DE RMI
Métodos factoría
◦ Se emplea para hacer referencia a un método que
crea objetos remotos
El enlazador(binder)
◦ Se emplea por parte del servidor para registrar sus
objetos remotos mediante su nombre y por parte
de los clientes para buscarlos por el nombre.
 Hilos del servidor
◦ Para evitar que la ejecución de una invocación
remota retrase la ejecución de otra.
IMPLEMENTACION DE RMI
Activación de Objetos Remotos
◦ Se utiliza cuando las aplicaciones requieren
que la información este disponible por largos
periodos de tiempo pero los objetos no son
utilizados durante todo ese tiempo.
◦ Un objeto se dice que esta activo cuando esta
disponible para su invocación dentro de un
proceso caso contrario se dice que esta pasivo
pero puede activarse.
IMPLEMENTACION DE RMI
Almacenes de objetos persistentes
◦ Un objeto persistente es aquel cuya vida esta
garantizada entre procesos de activación.
◦ Estos almacenes administran cantidades muy grandes
de objetos persistentes que se almacenan en el disco
hasta ser usados.
◦ Requieren de una estrategia para decidir cuando
desactivar un objeto.
◦ Existen 2 aproximaciones para saber si un objeto es
persistente o no:
 El almacén mantiene algunas raíces persistentes y cualquier
objeto alcanzable desde dichas raíces se define para ser
persistente.
 El almacén de objetos proporciona algunas clases sobre las
cuales se basa la persistencia.
IMPLEMENTACION DE RMI
Ubicación de Objetos
◦ Los objetos remotos pueden existir en un
conjunto de procesos diferentes y
posiblemente en computadores diferentes
durante su periodo de vida.
◦ Por lo que para lo su invocación se requiere
tanto una referencia a un objeto remoto como
una dirección a donde enviar sus
invocaciones.
◦ Para esto se utiliza un servicio de localización.
COMPACTACION
AUTOMATICA DE MEMORIA
Mientras alguien posea una referencia a
un objeto este debe seguir existiendo pero
cuando un haya dicha referencia el se
cobra ese objeto y se recupera la
memoria.
El algoritmo distribuido de compactación
automática de memoria de java se basa en
el recuento de referencias.
COMPACTACION
AUTOMATICA DE MEMORIA
Cuando un proceso obtiene una referencia a un
objeto remoto se crea un proxy que permanecerá
allí tanto tiempo como se necesario.
El proceso donde vive este objeto deberá estar
informado del nuevo proxy en el cliente.
Cuando no haya dicho proxy en el cliente se
informara al servidor.
 En ese momento el compactador de memoria
distribuido trabaja en cooperación con el
compactador de memoria local para la
recuperación de memoria.
LLAMADA A UN
PROCEDIMIENTO REMOTO
Introducción
Es muy similar a la invocación de un
método remoto.
RPC se implementa usualmente sobre un
protocolo petición-respuesta.
Se encuentra simplificado por la omisión
de referencia a objetos remotos en los
mensajes de petición.
 Papel de los procedimientos de
resguardo de cliente y servidor en
RPC
Proceso cliente Proceso servidor
Petición

Respuesta
Procedimiento de Procedimiento de
resguardo del resguardo del
cliente cliente

Procedimiento
Programa cliente Modulo de Modulo de Distribuidor de servicio
comunicación comunicación
Caso de estudio de Sun RPC
Diseñado para la comunicación cliente-
servidor en el sistema de archivos Sun
NTFS.
Sun RPC proporciona un leguaje de
interfaz denominado XDR y un
compilador de interfaces llamado rpcgen
cuyo uso esta orientado al leguaje de
programación c.
Caso de estudio de Sun RPC
Lenguaje de definición de interfaz
◦ Sun XDR Puede utilizarse para definir una
interfaz de servicio para Sun RPC especificando
un conjunto de definiciones de procedimiento
junto a las definiciones de tipos que la soportan.
 Sun RPC no permite identificar nombres de interfaces.
 Una definición de procedimiento especifica una firma de
un procedimiento en la que consta el tipo de resultado,
nombre del procedimiento y el tipo de parámetro de
entrada, y un numero de procedimiento.
 Solo permite un parámetro de entrada.
 Los parámetros de salida se devuelven como un solo
resultado.
Caso de estudio de Sun RPC
 Enlazado
◦ Para esto Sun RPC lanza el servicio enlazador de puertos en un
número de puerto bien conocido en cada computador.
 Autenticación
◦ Sun RPC proporciona campos adicionales en los mensajes de
petición y respuesta los que permiten pasar información de
autenticación entre el el cliente y el servidor.
 Programas cliente y servidor
◦ Un programa cliente importa la interfaz de servicio adecuado y
llama a los procedimientos remotos, por ejemplo, leer y escribir.
◦ El programa de servidor consiste en los procedimientos de
servidor, apoyados por los main, el despatcher y los
procedimientos de cálculo de referencias, todos los cuales se
emiten por rpcgen.
EVENTOS Y NOTIFICACIONES
(I)
“La idea bajo el uso de eventos es que un
objeto pueda reaccionar a un cambio que
ocurre en otro objeto”.
Los eventos y las notificaciones son
asíncronos.
Por ejemplo al manipular el mouse o una
caja de texto , se ven como eventos que
provocan cambios en los objetos.
EVENTOS Y NOTIFICACIONES
(II)
Sistemas distribuidos basados en eventos,
usan el paradigma publica-suscribe.
Publica, el objeto que genera eventos publica
el tipo de eventos que ofrece para su
observación por otros.
Suscribe, objetos que deseen recibir
notificaciones, se suscriben a los que sean de
su interés(registrar el interés).
Ejemplos, añadir una forma a un dibujo,
modificar un documento, entrar o dejar una
sala, cambiar de lugar un objeto.
EVENTOS Y NOTIFICACIONES
(III)
Características de los sistemas
distribuidos basados en notificaciones.
◦ Heterogéneos
Permite hacer funcionar conjuntamente aquellos
componentes del sistema distribuido que no han
sido diseñados con características de
interoperabilidad
Se requiere que los objetos generadores de eventos
publiquen los tipos de eventos que ofrecen
Se necesita que otros objetos se suscriban a los
eventos y proporcionen una interfaz para recibir
las notificaciones.
EVENTOS Y NOTIFICACIONES
(IV)
Características de los sistemas
distribuidos basados en notificaciones.
◦ Asíncronos
Las notificaciones se envían de manera asíncrona
a los suscriptores de ese objetos.
Por ejemplo Mushroom (sistema distribuido para
trabajo colaborativo), si un actor entra, esto se
verá reflejado como un cambio en la interfaz y
será de manera asíncrona, pues no se tiene la
certeza de cuando se generarán los eventos.
 EVENTOS Y NOTIFICACIONES
(V)
SISTEMA SIMPLE DE UNA SALA DE
CONTRATACIÓN.
EVENTOS Y NOTIFICACIONES
(VI)
Los participantes en una notificación
de eventos distribuida.
◦ El objeto de interés, objeto que experimenta
cambios de estado, como resultado de
operaciones sobre él (los cambios pueden ser
de interés para otros objetos).
Por ejemplo si una persona entra en una
habitación(O. interés), la operación consiste
en añadir información sobre la nueva persona
en el registro de la habitación.
EVENTOS Y NOTIFICACIONES
(VII)
Los participantes en una notificación de
eventos distribuida.
◦ Evento, un evento aparece en un objeto de interés
como resultado de la finalización de la ejecución
de un método.
◦ Notificación, objeto que contiene información de
un evento (tipo de evento, atributos).
Atributos: - Identidad del O. de Interés.
- Método que se invoca.
- Instante en que ocurre (ó secuencia).
EVENTOS Y NOTIFICACIONES
(IIX)
Los participantes en una notificación
de eventos distribuida.
◦ Suscriptor, objeto que se ha suscrito a algún
evento en otro objeto (recibe notificaciones).
◦ Objetos observadores, su función es
desacoplar un objeto de interés de sus
suscriptores.
Se puede tener muchos suscriptores con
diferentes intereses, lo que haría complicado a
un objeto.
EVENTOS Y NOTIFICACIONES
(IX)
Los participantes en una notificación
de eventos distribuida.
◦ Anunciante, objeto que declara que generará
notificaciones de tipos concretos de eventos.
Puede ser:
-Objeto de Interés
-Observador
EVENTOS Y NOTIFICACIONES
(X)
Los participantes en una notificación
de eventos distribuida.
EVENTOS Y NOTIFICACIONES
(XI)
Los participantes en una notificación
de eventos distribuida.
-Objeto de interés en el interior de un
servicio de eventos, sin observador.
- Objeto de interés en el interior de un
servicio de eventos, con observador.
- Objeto de interés fuera de un servicio de
eventos, con observador.
EVENTOS Y NOTIFICACIONES
(XII)
Los participantes en una notificación
de eventos distribuida.
-Reglas para los observadores.
A pesar de que pudiera enviar las
notificaciones directamente desde el
objeto de interés al receptor, la tarea de
procesar notificaciones puede dividirse
entre los procesos observadores, los
cuales tienen una variedad de papeles, por
ejemplo:
EVENTOS Y NOTIFICACIONES
(XII)
Encaminamiento, hace el trabajo de
enviar las notificaciones a los suscriptores
en representación de uno o varios objetos
de interés.
Filtrado de notificaciones, puede aplicar
filtros, basado en los contenidos de las
notificaciones.
EVENTOS Y NOTIFICACIONES
(XIII)
Patrones de eventos, cuando un objeto se
suscribe, se puede especificar patrones sobre
los cuales está interesado, un patrón
especifica una relación entre varios eventos.
Buzones de notificaciones, en ciertos
escenarios se debe retrasar las notificaciones
hasta que el suscriptor esté listo, en ese caso
el observador almacenará las notificaciones
en lugar del suscriptor.
EVENTOS Y NOTIFICACIONES
(XIV)
Especificación de eventos distribuidos
de JINI.
Permite que un suscriptor en una JVM se
suscriba y reciba notificaciones de otro
JVM (la cual puede estar en otra PC).
◦ Generadores de eventos.
◦ Oyentes de eventos remotos.
◦ Eventos remotos.
◦ Agentes terceros.
 EVENTOS Y NOTIFICACIONES
(XV)
Especificación de eventos distribuidos de
JINI.
Para enviar las notificaciones desde el
generador de eventos al suscriptor se usa Java
RMI (puede usar uno o más agentes terceros).

De igual manera se la usa para suscribirse a

los eventos.
 EVENTOS Y NOTIFICACIONES
(XVI)
RemoteEventListener, interfaz proporciona un método
llamado notify. Es implementada por los suscriptores y
los agentes terceros.
RemoteEvent (Clase):
-Referencia a un generador de eventos.
-Identificador de Eventos(tipo de eventos en el generador
de eventos).
-Número de Secuencia.
-Objeto empaquetado, contiene información que necesite
el receptor para identificar el evento y reaccionar a sju
aparición.
 EVENTOS Y NOTIFICACIONES
(XVII)
EventGenerator, interfaz proporciona un método
llamado register. Es implementada por los
generadores de eventos, se usa para suscribirse a
un evento del Objeto.
-Register:
Un identificador de eventos(Tipo).
Objeto empaquetado(se devolverá con la
notificación).
Referencia remota a un objeto suscriptor.
Periodo de duración de la suscripción (se pueden
renovar).
CASO DE ESTUDIO JAVA
RMI
CASO DE ESTUDIO JAVA
RMI
Permite que los objetos invoquen métodos sobre
objetos remotos, empleando la misma sintaxis
que las invocaciones locales.

El servidor proporciona operaciones adicionales

al cliente.

Ejemplosde tecnología distribuida son Java

RMI y CORBA.
 Comunicacion entre Tecnologias
de objetos distribuidos
Permiten que cualquier agente de la aplicacion
distribuida pueda actuar directamente con objetos
situados en host remotos.
 Modelo de Objetos Distribuidos

Las interfacez remotas se definen para localizar al objeto remoto.

 CASO DE ESTUDIO JAVA
RMI
Interfaces Remotas en JAVA RMI:

 Los interfaces definen métodos, mientras que las clases implementan los
métodos definidos en los interfaces.

 En una aplicación distribuida, se asume que algunas implementaciones

residen en diferentes máquinas virtuales.

 Los argumentos se empaquetan a través de la interfaz serializable.

CASO DE ESTUDIO JAVA
RMI
Paso de parámetros y resultados:
Los parámetros de un método son parámetros de
entrada y el resultado de un método es un único
parámetro de salida. Donde se tiene:

 Paso de objetos remotos.(Referencia)

 Paso de objetos no remotos.(Crea nuevo objeto)
CASO DE ESTUDIO JAVA
RMI
Descarga de Clases
Los objetos remotos se comuniquen mediante la
invocación remota.

RMIregistry
Es el enlazador para Java RMI, contiene:
//nombreComputador:puerto/nombreObjeto
Clase Naming
 CONSTRUCCIÓN DE
PROGRAMAS C/S
Programa Servidor Representa una forma como un objeto
remoto que implementa la interfaz.
Inicio Consta de un método main y una clase
sirviente.
El método main crea una instancia y
Método main RMI register
lo enlaza en RMI register.
La clase sirviente implementa la
Clase Sirviente RMI SecurityManager interfaz.

Interfaz Clase UnicastRemoteObject

Clase UnicastRemoteObject
Registra y Desregistra proporciona objetos remotos.
 CONSTRUCCIÓN DE
PROGRAMAS C/S
Programa Cliente:
Inicio

Busca referencias remotas

Establece un gestor de Seguridad

A un objetos remoto se envían RMI

Recibe un vector de referencia a objetos

Registro del ultimo número de versión
 Devolución de Llamada
El servidor debe informarse cuando termine
de una conexión con un cliente.(Objeto de
retrollamada.)
Necesita de una serie de RMI sincrónicas de
los objetos en las lista.

Devolución de llamada.- El servidor notifica a los clientes acerca de nuevos eventos.

 DISEÑO E IMPLEMENTACIÓN
DE JAVA RMI
Empleo de la reflexión.-Pasa información en los mensajes con la clase Method.

Clases de java que dan soporte a RMI.

Remote Object

RemoteServer

Activatable UnicastRemoteObject

Clase sirviente
RESUMEN
Los SD basados en eventos pueden
emplearse para permitir que grupos
distribuidos de objetos heterogéneos se
comuniquen unos con otros.
Mientras que RMI lo único que necesita
es implementar una interfaz para recibir
las notificaciones y suscripciones a
eventos.