apunte unidad 3
TRANSCRIPT
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
CompilaciónProf: Víctor Manuel Verona Gutiérrez
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.
Facultad Politécnica - UNA
Figura 5.1Capas Middleware
Middlewarelayers
Facultad Politécnica - UNA
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.
Facultad Politécnica - UNA
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.
Facultad Politécnica - UNA
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.
Facultad Politécnica - UNA
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.
Facultad Politécnica - UNA
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.
Facultad Politécnica - UNA
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
Facultad Politécnica - UNA
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.
Facultad Politécnica - UNA
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();
};
Facultad Politécnica - UNA
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
Facultad Politécnica - UNA
Figura 5.3Invocaciones de métodos locales y remotas
remoteinvocation E
invocation invocation F
Facultad Politécnica - UNA
local Cinvocation local
remoteB local
invocation DA
El modelo de objetos distribuido
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.
Facultad Politécnica - UNA
El modelo de objetos distribuido
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.
Facultad Politécnica - UNA
El modelo de objetos distribuido
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.
Facultad Politécnica - UNA
El modelo de objetos distribuido
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.
Facultad Politécnica - UNA
El modelo de objetos distribuido
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
Facultad Politécnica - UNA
El modelo de objetos distribuido
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++.
Facultad Politécnica - UNA
Figura 5.4Un objeto remoto y su interfaz remota
remoteobject
Dataremoteinterface
{m4m5m6
m1m2m3
implementation
of methods
Facultad Politécnica - UNA
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
Facultad Politécnica - UNA
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.
Facultad Politécnica - UNA
Semánticas de invocación
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.
Facultad Politécnica - UNA
Semánticas de invocación
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.
Facultad Politécnica - UNA
Semánticas de invocación
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.
Facultad Politécnica - UNA
Figura 5.6El papel de un proxy y un esquema en la invocación de métodos remotos
remote
Request
Reply
modulemodule
Facultad Politécnica - UNA
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.
Facultad Politécnica - UNA
Implementación de RMI
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.
Facultad Politécnica - UNA
Implementación de RMI
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.
Facultad Politécnica - UNA
Implementación de RMI
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..
Facultad Politécnica - UNA
Implementación de RMI
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.
Facultad Politécnica - UNA
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
Facultad Politécnica - UNA
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.
Facultad Politécnica - UNA
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
Facultad Politécnica - UNA
Figura 5.7Papel de los procedimientos de resguardo de cliente y servidor en RPC
Request
Reply
procedure
Communication procedure
Facultad Politécnica - UNA
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.
Facultad Politécnica - UNA
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
Facultad Politécnica - UNA
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.
Facultad Politécnica - UNA
Eventos y notificaciones
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
Facultad Politécnica - UNA
Eventos y notificaciones
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.
Facultad Politécnica - UNA
Eventos y notificaciones
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.
Facultad Politécnica - UNA
Eventos y notificaciones
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:
Facultad Politécnica - UNA
Eventos y notificaciones
. 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.
Facultad Politécnica - UNA
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
Facultad Politécnica - UNA
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.
Facultad Politécnica - UNA
Participantes en una notificación de eventos distribuida
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.
Facultad Politécnica - UNA
Participantes en una notificación de eventos distribuida
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.
Facultad Politécnica - UNA
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
Facultad Politécnica - UNA
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.
Facultad Politécnica - UNA
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
Facultad Politécnica - UNA
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.
Facultad Politécnica - UNA
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
Facultad Politécnica - UNA
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());}}
}
Facultad Politécnica - UNA
Figura 5.16Clases de soporte de Java RMI
RemoteObject
RemoteServer
UnicastRemoteObjectActivatable
<servant class>
Facultad Politécnica - UNA