Apunte unidad 3

Capítulo 4Objetos Distribuidos e invocación remota

Universidad Nacional de AsunciónFacultad Politécnica

Ingeniería Informática

Sistemas DistribuidosProf: Guillermo J. González Rodas

[email protected]

CompilaciónProf: Víctor Manuel Verona Gutiérrez

[email protected]

[email protected]

[email protected]

Introducción

Este capítulo trata de los modelos de programación para aplicacionesdistribuidas; esto es, aquella aplicaciones que se componen de programascooperantes corriendo en procesos distintos.

Tales programas necesitan ser capaces de invocar operaciones en otrosprocesos, que a menudo residen en computadores diferentes.

. El primero, y quizás mejor conocido de entre ellos, fue la extensión delmodelo de llamada procedimiento convencional al modelo deprocedimiento remoto, que permite a programas clienteprocedimientos de programas servidores lanzados en procesosgeneralmente en computadores distintos al del cliente.

llamada allamar a

parados, y

Facultad Politécnica - UNA

Introducción

. Más recientemente, el modelo de programación basado en objetos ha sidoextendido permitir que los objetos de diferentes procesos se comuniquenuno con otro por medio una invocación a un método remoto (RMI, remotemethod invocation).

RMI es una extensión de la invocación a métodos locales que permite queun objeto que vive en un proceso invoque los métodos de un objeto quereside en otro proceso.

. El modelo de programación basado en eventos permite a los objetos recibirnotificación de los eventos que ocurren en otros objetos en los que se hamanifestado el interés. Este modelo ha sido extendido para permitir escribirprogramas distribuidos basados en eventos.


Figura 5.1Capas Middleware

Middlewarelayers


Applications

RMI, RPC and events

Request reply protocol

External data representation

Operating System

Middleware

Middleware. Al software que proporcionasobre bloques básicos arquitectónicos, amensajes, se le denomina middleware. La

un modelo de programaciónsaber: procesos y paso decapa de middleware emplea

protocolos basados en mensajes entre procesos para proporcionarabstracciones de un nivel mayor, tales como invocaciones remotas yeventos.

Un aspecto importante del middleware es que proporciona transparenciade ubicación e independencia de los detalles de los protocolos decomunicación, los sistemas operativos y el hardware de loscomputadores.

Algunas formas de middleware permiten que los componentesseparados estén escritos en diferentes lenguajes de programación.


Middleware

Transparencia frente a ubicación: En RPC, el cliente que llama a unprocedimiento no puede discernir si el procedimiento se ejecuta en elmismo proceso o en un proceso diferente, Posiblemente en otrocomputador.

El cliente tampoco necesita conocer la ubicación del servidor.Análogamente, en RMI el objeto que realiza la

invocación no podrá decirnos si el objeto queinvoca es local o no, y tampoco requiere

conocer su ubicación. Asimismo, en los programas distribuidos basadosen eventos, los objetos que generan eventos y los objetos que recibennotificaciones de esos eventos tampoco necesitan estar al corriente desus ubicaciones respectivas.Protocolos de comunicación:abstracciones del middlewaretransporte subyacentes. Por

Los protocolos que dan soporte a lasson independientes de los protocolos deejemplo el protocolo petición-respuesta

puede estar implementado tanto sobre UDP como sobre TCP.Facultad Politécnica - UNA

Middleware

Hardware de los computadores: Se emplean en el empaquetado ydesempaquetado de mensajes. Éstos ocultan las diferencias dearquitectura en el hardware, como el ordenamiento de los bytes.

Sistemas operativos: Las abstracciones de mayor nivel que provee la capade middleware son independientes de los sistemas operativos subyacentes

Utilización de diversos lenguajes de programación: Diversos middleware sediseñanmás declientes

para permitir que las aplicaciones distribuidas sean escritas enun lenguaje de programación. En particular CORBA permite a losescritos en un lenguaje invocar métodos en objetos que viven en

programas servidores escritos en otro lenguaje. Esto se obtiene empleandoun lenguaje de definición de interfaz o IDL (interface definition language)para definir interfaces.


Interfaces

Las interfaces en los sistemas distribuidos. En un programa distribuido,los módulos pueden lanzarse en procesos separados. No es posible paraun módulo que se ejecutamódulo que está en otroescrita para RPC o RMI no

en un proceso acceder a las variables de unproceso. Asimismo, la interfaz de un módulopuede especificar el acceso directo a variables.

Advierta que las interfaces en IDL de CORBA pueden especificar atributos,lo que parece violar esta regla. Sin embargo, los atributos no son accedidosdirectamente sino mediante ciertos procedimientos de escritura y lecturaque se añaden automáticamente a la interfaz.

Los mecanismos de paso de parámetros, por ejemplo la llamada por valor yla llamadalocales, noestán en

por Referencia, utilizados en las llamadas a procedimientosson adecuados cuando el que llama y el procedimiento llamadoprocesos diferentes. La especificación de un método o

procedimiento en la interfaz de un módulo en un programa distribuidodescribe los parámetros como entrada o salida o, a veces, ambos.


Interfaces

Los parámetros de entrada se pasan al módulo remoto mediante el envíode los valores de los argumentos en el mensaje de peticiónposteriormente se proporcionan como argumentos a la operación queejecutará en el servidor. Los parámetros de salida se devuelven en

yseel

mensaje de respuesta y se sitúan como la respuesta de la llamada o reemplazando los valores de las correspondientes variables argumento en elentorno

Cuando se proporciona un parámetro tanto como para entrada como parasalida, el valor debe transmitirse tanto en los mensajes de la petición comoen los de la respuesta.

Otra diferencia entre los módulos locales y remotos es que los punteros enun proceso dejan de ser válidos en el remoto. En consecuencia, no puedenpasarse punteros como argumentos o como valores retornados comoresultado de las llamadas a los módulos remotos.


Interfaces

Interfaces de servicio: En el modelo cliente-servidor, cada servidorproporciona procedimientos disponibles para su empleo por los clientes.Por ejemplo, un servidor de archivos proporcionará procedimientos paraleer y escribir archivos. El término interfaz de servicio se emplea parareferirse a la especificación de los procedimientos que ofrece un servidor, ydefine los tipos de los argumentos de entrada y salida de cada uno de losprocedimientos.

Interfaces remotas: En el modelo de objetosremota especifica los métodos de un objeto queinvocación por objetos de otros procesos, y

distribuidos, una interfazestán disponibles para sudefine los tipos de los

argumentos de entrada y de salida de cada uno de ellos. Sin embargo, lagran diferencia es que los métodos en las interfaces remotas pueden pasarobjetos como argumentos y como resultados de los métodos.


Interfaces

Lenguajes de definición de interfaces. Se puede integrar un mecanismoRMI con un lenguaje de programación concreto si incluye una notaciónapropiada para definir interfaces, que permita relacionar los parámetros deentrada y de salida con el uso habitual de los parámetros en ese lenguaje.

Java RMI es un ejemplo en el que se ha añadido un mecanismo RMI a unlenguaje de programación con orientación a objeto.

Esta aproximación es útil cuando se puede escribir cada parteaplicación distribuida en el mismo lenguaje.

de una

También es conveniente dado que permite al programador emplearlenguaje para las invocaciones locales y remotas.

un solo


Interfaces

Sin embargo, muchos servicios útiles se encuentran escritos en C + + yotros lenguajes.

Sería beneficioso, que pudieran acceder a ellos remotamente, muchosotros programas escritos en gran variedad de lenguajes, incluyendo Java.

Los lenguajes de definición de interfaces (IDL) estan diseñados parapermitir que los objetos implementados en lenguajes diferentes se invoquenunos a otros. Un IDL proporciona una notación para definir interfaces en lacual cada uno de los parámetros de un método se podrá describir como deentrada o de salida además de su propia especificación de tipo.


Figura 5.2Ejemplo en CORBA IDL

// In file Person.idlstruct Person {

string name;string place;long year;

} ;interface PersonList {

readonly attribute string listname;void addPerson(in Person p) ;void getPerson(in string name, out Person p);long number();

};


El modelo de objetos distribuido

Cada proceso contiene un conjunto de objetos, algunos de los cualesrecibir tanto invocaciones locales como remotas, mientras que otrossólo pueden recibir invocaciones locales

puedenobjetos

Las invocaciones de métodos entre objetos en diferentes procesos, tanto sies en el mismo computador o no, se conocen como invocaciones de métodosremotas .

Las invocaciones de métodosinvocaciones de métodos locales.

entre objetos del mismo proceso son


Figura 5.3Invocaciones de métodos locales y remotas

remoteinvocation E

invocation invocation F


local Cinvocation local

remoteB local

invocation DA


A los objetos que pueden recibir invocaciones remotas los conocemos comoobjetos remotos.

En la Figura 5.3, los objetos E y F son objetos remotos. Todos los objetospueden recibir invocaciones locales, a pesar de que sólo puedan recibirlasde otros objetos que posean referencias ellos. Por ejemplo, el objeto Cpuede tener una referencia al objeto E de modo que puede invocar uno desus métodos. Los dos conceptos fundamentales siguientes son el corazóndel modelo objetos distribuidos:

Referencia de objeto remoto: otros objetos pueden invocar los métodos deun objeto remoto si tienen acceso a su referencia de objeto remoto. Porejemplo, en la Figura 5.3 deberá estar disponible para A una referencia a unobjeto remoto sobre E.lnterfaz remota: cada objeto remoto tiene una interfaz remota que especificacuáles de sus métodos pueden invocarse remotamente. Por ejemplo, losobjetos E y F deben tener interfaces remotas.



Referencias a objetos remotos. La noción de referencia a objeto seextiende para permitir que cualquier objeto que pueda recibir un RMI tengauna referencia a objeto remoto. Una referencia a objeto remoto es unidentificador que puede usarse a lo largo de todo un sistema distribuido parareferirse a un objeto remoto particular único.

Las referencias a objetos remotos son análogas a las locales en cuanto aque:

•El objeto remoto donde se recibe la invocación de método remoto seespecifica mediante una referencia a objeto remoto.•Las referencias a objetos remotos pueden pasarse como argumentos yresultados de las invocaciones de métodos remotos.



Interfaces remotas. La clase de un objeto remoto implementa los métodosde su interfaz remota, por ejemplo las instancias públicas en Java. Losobjetos en otros procesos pueden invocar solamente los métodos quepertenezcan a su interfaz remota.

Losobjetos locales pueden invocarcomo otros métodos implementados

los métodos en la interfaz remota asípor un objeto remoto.

El sistema CORBA proporciona IDL, que permite definir interfaces remotas.

En Java RMI, las interfaces remotas se definen de la misma forma quecualquier interfaz Java.

Adquieren su capacidad de ser interfaces remotas al extender una interfazdenominada Remote.



Acciones en un sistema de objetos distribuido. Como en el caso nodistribuido, una acción se inicia mediante la invocación de un método, quepudiera resultar en consiguientes invocaciones sobre métodos de otrosobjetos.

Pero en el caso distribuido, los objetos involucrados en una cadena deinvocaciones relacionadas pueden estar ubicados en procesos o encomputadores diferentes.

Cuando una invocación cruza los límites de un proceso o un computador, seemplea una RMI, y la referencia remota al objeto se hace disponible parahacer posible la RMI.

En la Figura 5.3, el objeto A necesita poseer una referencia a objeto remotopara el objeto E. Las referencias a un objeto remoto pueden obtenersecomo resultado de una invocación a un objeto remoto. Por ejemplo, elobjeto A podría obtener una referencia remota al objeto F desde el objeto E.



Compactación automática de memoria en un sistema de objetosdistribuido. Si un lenguaje, por ejemplo Java, soporta compactaciónautomática de memoria, entonces cualquier sistema RMI asociado debierapermitir la compactación automática de memoria para objetos remotos.

La compactación automática de memoria, distribuida, se logra usualmentemediante la Cooperación entre el compactador automático de memoria localy un módulo adicional quede memoria, distribuida,referencias.

realiza una forma de compactación automáticabasada generalmente en una cuenta de



Excepciones. Cualquier invocación remota puede fallar por razonesrelativasdiferentecontiene

a que el objeto invocado está en un proceso o computadorde la del objeto que lo invoca. Por ejemplo, el proceso que

el objeto remoto pudiera malograrse o estar demasiado ocupadopara responder, o pudiera perderse el mensaje resultante de la invocación.

Es así, que una invocación a un método remoto debiera ser capaz delanzar excepciones tales como timeouts debidos a la distribución así comoaquellos lanzados durante la ejecución del método invocado. Ejemplos deesto último son: un intento de lectura pasado el fin de un archivo, o unacceso a un archivo sin los permisos adecuados.

CORBA IDL proporciona una notación para las excepciones específicas delnivel de aplicación, y el sistema subyacente genera excepciones estándarcuando ocurren errores debidos a la distribución. Los programas clientesCORBA deben ser capaces de gestionar las excepciones. Por ejemplo, unprograma cliente C++ empleará los mecanismos de excepciones de C++.


Figura 5.4Un objeto remoto y su interfaz remota

remoteobject

Dataremoteinterface

{m4m5m6

m1m2m3

implementation

of methods


Figura 5.5Semánticas de invocación

SemánticasDe Invocación

Medidas de tolerancia a fallos

Retransmisión de,mensajes

No

Si

FiltradoDe duplicados

No procede

No

Reejecución del procedimientoO retransmisión de la respuesta

No procede

Reejecutar proced.

Pudiera ser

Al menos una vez

Si Si Retransmitir resp. Como máximo una vez


Semánticas de invocación

Semántica de la invocación RMI. Las opciones principales son:

Reintento del mensaje de petición: donde se retransmite el mensaje depetición hasta que, o bien se recibe una respuesta o se asume que elservidor ha fallado.

Filtrado de duplicados: cuando se emplean retransmisiones, si se descartanlas peticiones duplicadas en el servidor .

Retransmisión de resultados: si se mantiene una historia de los mensajes deresultados para permitir retransmitir los resultados perdidos sin reejecutar lasoperaciones en el servidor.



Semántica de invocación pudiera ser: Con la semántica de invocaciónpudiera ser, el que invoca no puede decir si un método se ha ejecutado unavez, o ninguna en absoluto. La semántica pudiera ser aparece cuando nose aplica ninguna medida de tolerancia ante fallos. Esta puede padecer delos siguientes tipos de fallo:

. Fallos de omisión si se pierde la invocación o el mensaje con elresultado. Fallos por caída cuando el servidor que contiene el objeto remoto falla

Si el mensaje con el resultado no se recibe tras un time out y no hayreinentos, no hay certeza si se ha ejecutado el método. Si se pierde elmensaje de invocación, entonces el método no se habrá ejecutado. Porotro lado, puede haberse ejecutado el método y haberse perdido elmensaje con el resultado.La semántica pudiera ser es útil sólo en aplicaciones donde es aceptableque haya invocaciones fallidas.



Semántica de invocación al menos una vez: Con la semántica deinvocación al menos una vez, el invocante recibe un resultado, en cuyocaso el invocante sabe que el método se evaluó al menos una vez, amenos que se reciba una excepción informando que no se recibe ningúnresultado.

La semántica de invocación al menos una vez puede alcanzarse mediantela retransmisión de los mensajes de petición, que enmascara los fallos poromisión de los mensajes de invocación del resultado, La semántica almenos una vez puede padecer los siguientes tipos de fallos:

.Fallos por caída cuando el servidor que contiene el objeto remoto falla.

.Fallos arbitrarios. En casos donde el mensaje de invocación seretransmite, el objeto remoto puede recibirlo y ejecutar el método másde una vez, provocando que se almacenen o devuelvan valoresposiblemente erróneos.



Semántica como máximo una vez: Con la semántica de invocación como máximouna vez, el invocante recibe bien un resultado, en cuyo caso el invocante sabe queel método se ejecutó exactamente una vez, o una excepción que le informa de queno se recibió el resultado, de modo que el método se habrá ejecutado o una vez oninguna en absoluto. La semántica de invocación como máximo una vez puedeobtenerse utilizando todas las medidas de tolerancia frente a fallos.

Como en el caso anterior, al usar reintentos se enmascara cualquier fallo poromisión de los mensajes de invocación y del resultado. Las medidas adicionales detolerancia frente a fallos previenen los fallos arbitrarios al asegurar que para cadaRMI no se ejecuta el método más que una sola vez. Tanto Java RMI como CORBAobservan la semántica de invocación como máximo una vez, pero CORBA permiteemplear la semántica pudiera ser para los métodos que no devuelven resultados.

Sun RPC proporciona la semántica de llamadas al menos una vez.


Figura 5.6El papel de un proxy y un esquema en la invocación de métodos remotos

remote

Request

Reply

modulemodule


serverskeleton object B& dispatcher

for B’s class

Communication Remote reference

client

object A proxy for B

Remote Communicationreference module module

Implementación de RMI

Módulo de comunicación. Los dos módulos cooperantes realizan elprotocolo de petición-respuesta, que retransmite los mensajes de petición yrespuesta entre el cliente y el servidor.

El módulo de comunicación emplea sólo los tres primeros elementos, queespecifican el tipo de mensaje, su idPeticion y la referencia remota del objetoque se invoca. La idMetodo y todo el empaquetado y (desempaquetado escuestión del software RMI.

Los módulos de comunicación son responsables conjuntamente deproporcionar una semántica de invocación, por ejemplo como máximo unavez.

El módulo de comunicación en el servidor selecciona el distribuidor para laclase del objeto que se invoca, pasando su referencia local, que se obtienedel módulo de referencia remota en respuesta al identificador de objetoremoto en el mensaje petición.



Módulo de referencia remota. Un módulo de referencia remota esresponsable de traducir las referencias entre objetos locales y remotos, y decrear referencias a objetos remotos. Para soportar sus responsabilidades, elmódulo de referencia remota de cada proceso tiene una tabla de objetosremotos que almacena la correspondencia entre referencias a objetoslocales en ese proceso y las referencias a objetos remotos (cuyo ámbito estodo el sistema). La tabla incluye:

. Una entrada para todo objeto remoto implementado por el proceso. Porejemplo, en la Figura 5.6, el objeto remoto B estará registrado en la tabladel servidor .

. Una entrada para cada proxy local. Por ejemplo, en la Figura 5.6 el proxypara B estará registrado en la tabla de ese cliente.



Las acciones del módulo de referencia remota ocurren como sigue:

. Cuando se pasa un objeto remoto por primera vez, como argumento oresultado, se le pide al módulo de referencia remota que cree una referenciaa un objeto remoto, que se añade a su tabla.

. Cuando llega una referencia a un objeto remoto, en un mensaje de peticióno respuesta, se le pide al módulo de referencia remota la referencia al objetolocal correspondiente, que se referirá bien a un proxy o a un objeto remoto.En el caso de que el objeto remoto no esté en la tabla, el software RMI creaun nuevo proxy y pide al módulo de referencia remota que lo añada a latabla.

Los componentes del módulo software de RMI llaman a este módulo cuandorealizan el empaquetado y el desempaquetado de las referencias a objetosremotos. Por ejemplo, cuando llega un mensaje de petición, se emplea sutabla para encontrar qué objeto local se va a invocar.



EI software de RMI. Éste consiste en una capa de software entre los objetosdel nivel de aplicación y los módulos de comunicación y de referenciaremota. Los papeles de los objetos de middlewareware mostrados en laFigura 5.6 son como sigue:

Proxy : el papel del proxy es hacer que la invocación al método remoto seatransparente para los clientes, y para ello se comporta como un objeto localpara el que invoca; pero en lugar de ejecutar la invocación, dirige el mensajeal objeto remoto.

Oculta los detalles de la referencia al objeto remoto, el empaquetado de losargumentos, el desempaquetado de los resultados y el envío y recepción delos mensajes desde el cliente. Hay un proxy para cada objeto remoto delque el cliente disponga de una referencia de objeto remoto. La clase de unproxy implementarepresenta. Estoadecuadas según

los métodos de la interfaz remota del objeto remoto al queasegura que las invocaciones al método remoto sonel tipo del objeto remoto..



Distribuidor: cada servidor tiene un distribuidor y un esqueleto para cadaclase que represente a un objeto remoto. En nuestro ejemplo, el servidortiene un distribuidor y un esqueleto clase del objeto remoto E. El distribuidorrecibe el mensaje de petición desde el módulo de comunicación. Emplea elidMetodo para seleccionar el método apropiado del esqueleto, pasándole elmensaje de petición. El distribuidor y el proxy emplean los mismos métodosde asignación de cada idMetodo para los métodos de la interfaz remota.

Esqueleto: la clase de un objeto remoto tiene un esqueleto, que implementalos métodos interfaz remota. Se encuentran implementados de forma muydiferente de los métodos del objeto remoto. Un método del esqueletodesempaqueta los argumentos del mensaje de petición, invoca el métodocorrespondiente en el objeto remoto.


RPC

Una llamada a un procedimiento remoto es muy similar a una invocación aun método remoto, en la que un programa cliente llama a un procedimientode otro programa en ejecución en un servidor.

Los servidores pueden ser clientes de otros servidores para permitir cadenasde RPC.

Un proceso servidor define en su interfaz de servicio los procedimientosdisponibles para ser llamados remotamente. RPC, como RMI, puedeimplementarse para ofrecer alguna de las semánticas de invocacióndiscutidas, al menos una vez o como máximo una vez.

RPC se implementa usualmente sobre un protocolo petición-respuesta.

Los contenidos de loslos que mostraronReferenciaObjeto.

mensajes de petición y respuesta son los mismos quepara RMI, excepto que se omite el campo


RPC

El software que soporta RPC es similar al mostrado para RMI excepto queno se requieren módulos de referencias remotas, dado que las llamadas aprocedimientos no tienen que ver con objetos y referencias a objetos.

El cliente que accede a unpara cada procedimientoprocedimiento de resguardo

servicio incluye un procedimiento de resguardoen la interfaz de servicio.El papel dees similar al de un proxy.

un

Se comporta como un procedimiento local del cliente, pero en lugarejecutar la llamada, empaqueta el identificador del procedimiento y

delosdeargumentos en un mensaje de petición, que se envía

comunicación al servidor.vía su módulo

Cuando llega el mensaje de respuesta, desempaquetaproceso servidor contiene un distribuidor junto a un

los resultados. Elprocedimiento de

resguardo de servidor y un procedimiento de servicio para cadaprocedimiento de la interfaz de servicio.


RPC

El distribuidor selecciona uno de los procedimientos de resguardo según elidentificador de procedimiento del mensaje de petición.

Un procedimiento de resguardo de servidor es como un método deesqueleto en el que sepetición, se llama al

desempaquetan los argumentos en el mensaje deseprocedimiento de servicio correspondiente y

empaquetan los datos con el resultado para el mensaje de respuesta.

Los procedimientos de servicio implementan los procedimientosinterfaz de servicio

en la


Figura 5.7Papel de los procedimientos de resguardo de cliente y servidor en RPC

Request

Reply

procedure

Communication procedure


server process

server stub

service

module dispatcher

client process

client stubprocedure

clientprogram Communication

module

SUN RPC

Sun RPC, se diseñó para la comunicación cliente-servidor en el sistemade archivos en red Sun NFS. Sun RPC se denomina a menudo ONC(Computación de Red Abierta -Open Network Computing)

RPC se proporciona como parte de los varios sistemas operativos deSun y otros del tipo UNIX.Los diseñadores tienen la opción de utilizarllamadas a procedimientos remotos sobre UDP o TCP.

Utiliza la semántica de llamada al menos una vez.

Como opción existe la posibilidad de difusión de RPC.

El sistema Sun RPC proporciona un lenguaje de interfaz denominadoXDR y un compilador de interfaces llamado rpcgen cuyo uso estáorientado al lenguaje de programación C.


Figura 5.8Interfaz de archivos en Sun XDR

const MAX = 1000;typedef int FileIdentifier;typedef int FilePointer;typedef int Length;struct Data {

int length;char buffer[MAX];

};struct writeargs {

FileIdentifier f;FilePointer position;Data data;

};

struct readargs {FileIdentifier f;FilePointer position;Length length;

};

program FILEREADWRITE {version VERSION {

void WRITE(writeargs)=1;Data READ(readargs)=2;

}=2;} = 9999;

12


Eventos y notificaciones

En particular, en las aplicaciones interactivas, las acciones que el usuariorealiza sobre los objetos, por ejemplo al manipular un botón con el ratón oal introducir texto en una caja de texto mediante el teclado, se ven comoeventos que provocan cambios en los objetos que mantienen el estado dela aplicación. Los objetos responsables de mostrar el aspecto del estadoactual son notificados cuando cambia el estado.

Los sistemas distribuidos basados en eventos extienden el modelo local deeventos al permitir que varios objetos en diferentes ubicaciones puedan sernotificados de los eventos que tienenparadigma publica-suscribe, en el quepublica el tipo de eventos que ofrece para

lugaren un objeto. Emplean elun objeto que genera eventossu observación por otros objetos.

Los objetos que desean recibir notificaciones de un objeto que hayapublicado sus eventos se suscriben a los tipos de eventos que sean deinterés para ellos. Los objetos que representan los eventos se denominannotificaciones o anuncios.



Los eventos y las notificaciones pueden emplearse en una gran variedadde aplicaciones diferentes, por ejemplo para comunicar que se añade unaforma a un dibujo, una modificación de documento, el hecho de que unapersona haya entrado o dejado una sala, o que una parte del equipamientoo un libro etiquetado electrónicamente se encuentra en un nuevo lugar.

Los dos últimos ejemplos se hacen posibles con el uso de distintivosactivos o dispositivos empotrados



Los sistemas distribuidos basados en eventos presentan doscaracterísticas importantes:

Heterogéneos:comunicaciónconjuntamente

cuando se emplean notificaciones como mecanismo deentre objetos distribuidos, es posible hacer funcionaraquellos componentes del sistema distribuido que no han

sido diseñados con características de interoperabilidad. Todo lo que serequiere es que los objetos generadores de eventos publiquen los tipos deeventos que ofrecen, y que otros objetos se suscriban a los eventos yproporcionen una interfaz para recibir las notificaciones.

Por ejemplo, Bates describe cómo se pueden emplear los sistemasbasados en eventos para conectar componentes heterogéneos en Internet.Éste, describe un sistema en el que las aplicaciones son advertidas de lasubicaciones y actividades de sus usuarios, tales como utilizar loscomputadores, las impresoras o libros marcados electrónicamente.



Asíncronos: las notificaciones se envían asíncronamente desde los objetosgeneradores de eventos a todos los objetos que se hayan suscrito a ellospara prevenir que el que los anunciantes necesiten sincronizarse con lossuscriptores; es preciso desacoplar los anunciantes de los suscriptores.

Por ejemplo, un evento podría especificar que un usuario concreto haentrado o salido de un lugar, o ha realizado una acción particular sobre unobjeto. Cada réplica de cada objeto para el que sean relevantes ciertostipos de eventos se subscriben a ellos y recibe notificaciones cuando éstosocurran. Pero los suscriptores se encuentran desacoplados de los objetosque experimentan los eventos, dado que en momentos diferentes losusuarios activos son diferentes.



Sistema simple de una sala de contratación. Considere un sistemasimple de una sala de contratación cuya tarea es permitir que los tratanteshagan uso de los computadores para consutar la información más recientesobre los precios del mercado de las mercancías con que comercian.

El precio del mercado para una sola mercancía conocida se representamediante un objeto con varias variables de instancia. La información llega ala sala de contratación desde diferentes fuentes externas en forma deactualizaciones de algunos o todas las variables de instancia de los objetosque representan las mercancías y es recolectada por procesos quellamamos proveedores de información.

Los tratantes están interesados solamente en aquellas mercancías en queestán especializados. Un sistema de sala de contratación podría modelarsemediante procesos con dos tareas diferentes:



. Un proceso proveedor de información recibe continuamente nuevainformación comercial desde una sola fuente externa y le aplica los objetosde la mercancía apropiada. Cada una de las actualizaciones a un objeto demercancía se contempla como un evento. El objeto de mercancía queexperimenta tales eventos notifica a todos los tratantes que se hayansuscrito a la mercancía correspondiente. Habrá un proceso proveedor deinformación separado para cada fuente externa.

. Un proceso tratante crea un objeto para representar cada mercancía queel usuario pida visualizar.Este objeto local se suscribe al objeto querepresenta esa mercancía en el proveedor de información relevante.Entonces recibe toda la información enviada al anterior mediante lasnotificaciones y la muestra al usuario.


Figura 5.9Sistema de sala de contratación

Dealer’s computer Dealer’s computer

Notification Notification

InformationNotification Notification

NotificationNotification

NotificationDealer’s computer Dealer’s computer

Notification

NotificationNotification

Externalsource


DealerDealer

Informationprovider

Externalsource

provider

DealerDealer

Participantes en una notificación de eventos distribuida

El objeto de interés: éste es un objeto que experimenta cambios de estado,como resultado las operaciones que se invocan sobre él. Sus cambios deestado podrían ser de interés para los otros objetos. Esta descripciónpermite eventos como el que unaidentificador entre en una habitación, ende interés y la operación consiste en

persona que lleva un distintivocuyo caso la habitación es el objetoañadir información sobre la nueva

persona a su registro o quién está en la habitación. Se considera que elobjeto de interés es parte del servicio de eventos si transmite notificaciones.

Evento: un evento que aparece en un objeto de interés como resultado dela finalización de la ejecución de un método.

Notificación: una notificación es un objeto que contiene información sobreun evento. Generalmente, contiene el tipo de evento y sus atributos, quegeneralmente incluyen la identidad del objeto de interés, el método que seinvoca, y el momento en que ocurre, o un número de secuencia.



Suscriptor: un suscriptor es un objeto que se ha suscrito a algún tipo deevento en otro objeto. ibirá notificaciones sobre tales eventos.

Objetos observadores: el principal objetivo de un observador es desacoplarun objeto de interés sus suscriptores. Un objeto de interés puede tenermuchos suscriptores diferentessuscriptores podrían diferir en elo aquellos que comparten los

con difentes intereses. Por ejemplo, lostipo de eventos en que están interesados,mismos requisitos sobre el tipo podrían

divergir en atributos sobre los que están interesados.

Anunciante: éste es un objeto que declara que generará notificaciones detipos concretos de eventos, Un anunciante pudiera ser un objeto de interéso un observador.



La figura 5.10 muestra tres casos:

Un objeto de interés en el interior de un servicio de eventos sinobservador. Envía notificaciones directamente a los suscriptores.

un

Un objeto deobservador. Elel observador.

interés en el interior de un servicio de eventos conobjeto de interés envía notificaciones a los suscriptores

unvía

Un objeto de interés fuera del servicio de eventos. En este caso, unobservador consulta al objeto de interés para descubrir cuando ocurre unevento. El observador envía notificaciones a los suscriptores.


Figura 5.10Arquitectura para la notificación distribuida de eventos

Event service

object of interest subscriber

1. notification

object of interest observer subscriber

2. notificationnotification

object of interest observer subscriber

3. notification


Java RMI

Java RMI extiende el modelo desoporte de objetos distribuidos en elque los objetos invoquen métodos

objetos de Java para proporcionarlenguaje Java. En particular, permitesobre objetos remots empleando la

misma sintaxis que en las invocaciones locales. Además, la comprobaciónde tipos se aplica de modo igual en las invocaciones remotas como enlocales.

las

Sin embargo, realice una invocación remota conoce que su destinoremoto porque debe manejar RemoteExceptions; y el implementador

esde

un objeto remoto conoce que es remoto porque debe implementar lainterfaz Remote. A pesar de que el modelo de objetos distribuidos estáintegrado en Java de forma natural, la semántica de paso de parámetrosdifiere en que el objeto que invoca y el destino son remotos entre sí.

El programador de un objeto remoto debe considerar su comportamientoen un entorno concurrente.


Figura 5.11Interfaces Remote en Java para Forma y ListaForma

import java.rmi.*;import java.util.Vector;public interface Shape extends Remote {

int getVersion() throws RemoteException;GraphicalObject getAllState() throws RemoteException;

}public interface ShapeList extends Remote {

Shape newShape(GraphicalObject g) throws RemoteException;Vector allShapes() throws RemoteException;int getVersion() throws RemoteException;

}

1

2


Figura 5.12La clase Naming de Java RMIregistry

void rebind (String name, Remote obj)This method is used by a server to register the identifier of a remote object byname, as shown in Figure 15.13, line 3.

void bind (String name, Remote obj)This method can alternatively be used by a server to register a remote objectby name, but if the name is already bound to a remote object reference anexception is thrown.

void unbind (String name, Remote obj)This method removes a binding.

Remote lookup(String name)This method is used by clients to look up a remote object by name, as shownin Figure 15.15 line 1. A remote object reference is returned.

String [] list()This method returns an array of Strings containing the names bound in theregistry.


Figura 5.13Clase Java ServidorListaForma con el método main.

import java.rmi.*;public class ShapeListServer{

public static void main(String args[]){System.setSecurityManager(new RMISecurityManager());try{

ShapeList aShapeList = new ShapeListServant();Naming.rebind("Shape List", aShapeList );

System.out.println("ShapeList server ready");}catch(Exception e) {System.out.println("ShapeList server main " + e.getMessage());}

}}

12


Figura 5.14Clase Java SirvienteListaForma implementando la interfaz Listaforma.

import java.rmi.*;import java.rmi.server.UnicastRemoteObject;import java.util.Vector;public class ShapeListServant extends UnicastRemoteObject implements ShapeList {

private Vector theList;private int version;

// contains the list of Shapes 1

public ShapeListServant()throws RemoteException{...}public Shape newShape(GraphicalObject g) throws RemoteException {

version++;Shape s = new ShapeServant( g, version);theList.addElement(s);return s;

}public Vector allShapes()throws RemoteException{...}public int getVersion() throws RemoteException { ... }

2

3

}Facultad Politécnica - UNA

Figura 5.15Cliente Java de ListaForma

import java.rmi.*;import java.rmi.server.*;import java.util.Vector;public class ShapeListClient{

public static void main(String args[]){System.setSecurityManager(new RMISecurityManager());ShapeList aShapeList = null;try{

aShapeList = (ShapeList) Naming.lookup("//bruno.ShapeList")Vector sList = aShapeList.allShapes();

} catch(RemoteException e) {System.out.println(e.getMessage());

; 12

}catch(Exception e) {System.out.println("Client: " + e.getMessage());}}

}


Figura 5.16Clases de soporte de Java RMI

RemoteObject

RemoteServer

UnicastRemoteObjectActivatable

<servant class>


Apunte unidad 3

Documents

Transcript of Apunte unidad 3