Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Sistemas
Distribuidos
1. Introduccin
2. La Comunicacin
1. El Modelo de Comunicacin
2. Denominacin y servicio de nombres
3. El modelo RPC
4. RMI
5. CORBA
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 1
La Comunicacin - 1
P2
Mquina 2
P6
RED
P7
P8
P4
P9
Los procesos
estn separados
Lgicamente
Fsicamente
Cmo se
comunican un
grupo de
procesos?
Una Pareja
A un Grupo
Sincronizarse
Modelo CLIENTE-SERVIDOR
Modelo MULTICAST
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 2
La Comunicacin - 2
Modelo Cliente-Servidor
La Comunicacin
cliente
1. peticin
bloqueado
servidor
2. procesando
3. respuesta
1. Cliente:
Envo bloqueado
RPC
Averiguar_Nodo_Impresor
Imprimir (Fichero,Impresora,ok) Enva (Fichero, Nodo_Impresor)
Recibir (Respuesta, Nodo_Impresor)
Clientes Y
Servidores
Sistemas Distribuidos
Sistemas Distribuidos
NO son mquinas
SON PROCESOS
ambivalentes
La Comunicacin - 3
La Comunicacin - 3
Modelo Multicast
La Comunicacin
MULTICAST
Recibe
Recibe
P3
Recibe
Recibe
P4
Envo a
Grupo
P0
Bsqueda de un recurso
APLICACIONES
DE
MULTICAST
Puede haber varios motivos para enviar un mismo mensaje a un grupo de nodos:
P2
P1
Hay diversos algoritmos o mtodos para el envo de mensajes en modo multicast, desde
el mero envo secuencial de un mensaje tras otro desde el nodo origen, o la tcnica de
la inundacin, hasta los basados en rboles de expansin, pero su estudio no est entre
los objetivos de esta asignatura. No obstante s debemos tener en cuenta que la
eleccin del algoritmo de envo utilizado puede repercutir seriamente en el rendimiento
general del sistema.
Tambin puede ayudar a mejorar la velocidad de envo el disponer de cierto soporte
hardware que, para el algoritmo que le convenga, posibilite el envo paralelo de las
mltiples copias del mensaje.
El sistema de alto nivel que pueden utilizar los procesos para difundir mensajes a grupos
puede estar basado tambin en primitivas RPC, aunque con algn mecanismo adicional
en la primitiva de envo para poder indicar las direcciones a las que va dirigido el
mensaje (por ej. una tabla con todas las direcciones o direcciones de grupo).
Tolerancia a fallos
Actualizaciones mltiples
Sistemas Distribuidos
Sistemas Distribuidos
Rendimiento
General del
Sistema
La Comunicacin - 4
La Comunicacin - 4
Denominacin
La Comunicacin
DENOMINACIN
(Gestin de Nombres)
Es la correspondencia entre
objetos lgicos y fsicos
PLANA
JERRQUICA
NotasDiaEuiUpmEs
dia.eui.upm.es/Notas.html
atc.eui.upm.es/Notas.html
Capacidad Finita
Sistemas Distribuidos
Sistemas Distribuidos
Capacidad y estructura del esquema de nombres . Veamos ahora cmo puede ser el
espacio de nombres en cuanto a su capacidad y estructura.
El Espacio de Nombres puede tener una capacidad Limitada o Infinita. El actual espacio
de las direcciones de Internet es un ejemplo de capacidad limitada (ej. 138.100.56.34).
En cuanto a su estructura, puede ser Plana o Jerrquica. La estructura plana de
nombres est asociada a espacios de nombres de capacidad finita (a no ser que la
longitud de los nombres sea ilimitada), mientras que en la estructura jerrquica las
direcciones pueden crecer indefinidamente. Cuando se utiliza la estructura jerrquica, se
dice que la resolucin de nombres se realiza de acuerdo al contexto, es decir,
traduciendo cada uno de los nombres anteriores al nombre final que indican la jerarqua
por la que hay que pasar hasta llegar al objeto concreto. Ejemplo:
dia.eui.upm.es/notas.html hace referencia a un fichero (notas.html) situado
en la mquina dia de la eui de la upm. Para resolver tales nombres se va ascendiendo
por esta jerarqua de nombres, de tal forma que en cada nivel se es capaz de resolver el
nombre y obtener la direccin del siguiente nivel hasta llegar a la mquina de destino, y
en ella obtener el objeto con el nombre indicado (notas.html).
No se debe confundir la capacidad de nombres con la capacidad de identificadores de
direccin. As, por ejemplo, aunque el actual sistema de direcciones de Internet es finito
(en nmero de mquinas), el nmero de algunos recursos referenciables en la red es
ilimitado, puesto que cada mquina puede contar con una estructura jerrquica de
ficheros potencialmente ilimitada (salvo por la capacidad y limitaciones de tablas).
Infinita
La Comunicacin - 5
La Comunicacin - 5
...Denominacin
La Comunicacin
Servidor
de
nombres
NOMBRE
pepe@eui.upm.es
no m
IDENTIFICADOR DE
COMUNICACIN
138.100.56.67
+ Puerto
N1
br e
id.
MAQ. 1
id
.
N1 ID2
N2 ID7
N5 ID8
Recurso
SERVIDOR DE
NOMBRES
SERVIDOR
MAQ. 17
MAQ. 2
FUNCIONES DEL
SERVIDOR DE NOMBRES
Resolucin
Inclusin
Borrado
Ya hemos comentado que cuando un cliente requiere cualquier servicio del sistema
distribuido, primero es necesario comunicarse con el servidor de nombres para obtener
el identificador de un servidor del servicio requerido. Y si el servidor de nombres falla o
se cae? La respuesta es clara: Se pierden todos los accesos a los servicios del sistema.
Dada la importancia del servidor de nombres, cuyo funcionamiento es vital para el resto
del sistema, parece que se hace necesario que este servicio especial sea tolerante a
fallos. Teniendo en cuenta, adems, que va a ser un servicio muy requerido, pues todas
las utilizaciones de cualquier servicio deben pasar primero por l, para facilitar la
tolerancia a fallos y evitar el cuello de botella, suele ser normal que el servicio de
nombres est formado por servidores replicados que ofrezcan este servicio de nombres.
Modificacin
Sistemas Distribuidos
La Comunicacin - 6
La Comunicacin - 6
...Denominacin
Para acceder a un objeto remoto, el proceso cliente (que slo conoce el nombre del
recurso) debe conseguir el identificador de comunicacin del recurso que solicita antes
de comunicarse realmente con l. Para ello debe acudir primero a los servidores de
nombres intermedios necesarios hasta conseguir dicho identificador de comunicacin,
con el consiguiente tiempo de demora debido a los tiempos de resolucin o traduccin
de cada uno de los servidores de nombres requeridos.
N1
La Comunicacin
no m
br e
MAQ. 1
id
.
N1 ID2
N2 ID7
N5 ID8
Recurso
SERVIDOR DE
NOMBRES
SERVIDOR
MAQ. 17
En accesos
frecuentes
a un objeto
MAQ. 2
N1
N2
N5
N1
ID 2
ID 7
ID 8
CACH DE
NOMBRES
MQ. 1
Sistemas Distribuidos
Sistemas Distribuidos
id.
Recurso
SERVIDOR
MAQ. 2
La Comunicacin - 7
La Comunicacin - 7
...Denominacin
La Comunicacin
SE DEBE PERSEGUIR
TRANSPARENCIA
DE UBICACIN
(esttico)
INDEPENDENCIA
DE UBICACIN
(dinmico)
MIGRACIN
Nombres Puros e Impuros. Los nombres puros son simplemente series de bits sin
ninguna interpretacin posible (salvo para el servidor de nombres). Otros nombres (los
impuros) incluyen bits que indican directamente una direccin, permisos de acceso o
cualquier otra informacin sobre el objeto.
Los nombres impuros entran en conflicto con el principio de transparencia al que tanto
hemos aludido. Obsrvese que con un nombre impuro, cualquier informacin implcita
que lleve, puede quedarse obsoleta si el recurso al que se refiere cambia su direccin,
permisos, etc. Con los nombres puros simplemente hay que preocuparse de mantener
actualizadas las bases de datos de los servidores de nombres de cada contexto.
TIPOS DE NOMBRES
IMPUROS
PUROS
138.100.55.fenix
fenix.eui.upm.es
Tienen informacin
explcita
Sin interpretacin
(salvo para el S.N.)
Si hay cambios?
Si hay cambios?
OBSOLETO
Requiere actualizaciones
del Servidor de Nombres
Por falta de
TRANSPARENCIA
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 8
La Comunicacin - 8
...Denominacin
La Comunicacin
Control de acceso. Para evitar accesos no autorizados a los recursos del sistema, un
primer paso consiste en hacer que el identificador de un recurso no se pueda obtener
fcilmente a partir de su nombre si no es a travs del servidor de nombres. Y, por
supuesto, el servidor de nombres debe ocuparse de comprobar la identidad del cliente
que solicita una resolucin de nombres antes de darles el identificador solicitado. Los
identificadores que se comportan as, se denominan credenciales (capabilities). Por eso
se dice que para poder acceder a un recurso o servicio, previamente debe obtenerse la
credencial correspondiente.
Ejemplo: Credencial de Amoeba. Cuando un cliente requiere cierto servicio, en primer
lugar se identifica y solicita la credencial correspondiente al servidor de nombres, el cual
devuelve la credencial solicitada para el cliente identificado. Una vez se tiene la
credencial, se obtiene de ella el Puerto del servidor que va a prestar el servicio
requerido, con lo que ya se le puede enviar el mensaje con la peticin del servicio y la
credencial completa.
El campo Objeto lo utiliza el servidor para identificar el objeto especfico con el que el
cliente quiere realizar alguna operacin. Para el caso de un archivo, este campo sera
algo parecido a un i-nodo de Unix.
CREDENCIALES
(Capabilities)
Los Derechos estn compuestos por una serie de bits que indican las operaciones que
le estn permitidas al usuario para ese objeto (por ej. lectura, escritura, ...).
Credencial de Amoeba
48
Puerto del servidor
Sistemas Distribuidos
Sistemas Distribuidos
24
48
Objeto
Derechos
Verificacin
La Comunicacin - 9
La Comunicacin - 9
...Denominacin
La Comunicacin
Dnde est el binder? El binder nos proporciona la direccin del servidor solicitado,
pero cmo se lo pedimos al binder? dnde est el binder?
Se tienen las siguientes alternativas:
...Denominacin
La Comunicacin
DNDE EST EL BINDER ?
Hay Varias Alternativas
En una
direccin fija
La sabe el S.O.
(var. entorno)
Que los sistemas operativos de los clientes y de los servidores sean responsables
de proporcionar dinmicamente a sus procesos la direccin del binder. Esto puede
hacerse mediante variables de entorno. Si se reubica el binder, debe actualizarse la
direccin en la variable de entorno del sistema operativo, e informarse a los
usuarios para que rearranquen los procesos. Con este enfoque se permite la
reubicacin ocasional del binder sin tener que recompilar todos los clientes y
servidores; normalmente, solo obliga a pararlos y rearrancarlos de nuevo.
Broadcast de
bsqueda
Actualizar var.
de entorno del
S.O.
No Reubicacin Dinmica
Ante un fallo, el
cliente/servidor hace
broadcast de nuevo
Cuando un cliente o un servidor arranca, difunde un mensaje por toda la red para
localizar al binder. Cuando un proceso binder reciba este mensaje, contesta al
emisor con su direccin. Mediante este sistema, el binder puede ejecutarse
siempre sobre cualquier ordenador y reubicarse dinmica y fcilmente.
Reubicacin
Dinmica
Sistemas Distribuidos
La Comunicacin - 10
Sistemas Distribuidos
La Comunicacin - 10
Sistemas Distribuidos
La Comunicacin - 10
Las RPCs
La Comunicacin
CLIENTE
SERVIDOR
...
Haciendo_Cosas;
Enviar(Servidor,Suma,2,4);
Recibir(Servidor,Respuesta);
Usa_Respuesta;
...
loop;
Recibir(Peticion);
Sumar(Peticion);
Enviar(Cliente,Respuesta);
end;
procedure Sumar(Datos);
...
...
end Sumar;
Dnde est la
TRANSPARENCIA
?
SOLUCIN
Sistemas Distribuidos
Sistemas Distribuidos
Tampoco necesita el cliente conocer el tipo de mquina o sistema operativo del servidor
para ubicar convenientemente los parmetros en el mensaje.
Remote
Procedure
Call
Para conseguir esto, el cliente solamente debe realizar llamadas a procedimientos, de tal forma
que dependiendo de cada caso, la ejecucin del servicio solicitado tendr lugar en la propia
mquina o en una remota.
El mecanismo mediante el cual la ejecucin de un procedimiento tiene lugar en una mquina
remota se denomina Llamada a Procedimiento Remoto o RPC (Remote Procedure Call).
La Comunicacin - 11
La Comunicacin - 11
CLIENTE
SERVIDOR
...
Haciendo_Cosas;
Res:=Suma (2,4)
Usa_Respuesta;
...
Una gran parte de las operaciones en los sistemas distribuidos son remotas, por lo que
un proceso debe enviar un mensaje a otro proceso y esperar su respuesta.
Ya que los programadores estn muy familiarizados con el concepto de llamada a
procedimiento, estara bien esconder los detalles de envo y recepcin de mensajes
detrs de la fachada de la elegante interfaz de un procedimiento.
Las llamadas a procedimientos remotos tienen la misma semntica que las llamadas a
procedimientos ordinarios, es decir, al realizar la llamada, el llamante le pasa el control
al procedimiento llamado, y lo recupera cuando el procedimiento llamado le devuelve el
resultado. Las RPC no son ms que operaciones remotas disfrazadas de una
interfaz procedural.
El concepto de Llamada a Procedimiento Remoto lo presentaron por primera vez Birrell
y Nelson en 1984 para solucionar los problemas del paso de datos entre mquinas y
sistemas heterogneos (que trataremos ms adelante).
CLIENTE
SERVIDOR
Usuario
Rutina de Servicio
...
Haciendo_Cosas;
Res:=Suma (2,4)
Usa_Respuesta;
...
loop;
Recibir(Peticion);
Respuesta = Suma(Op1,Op2);
Enviar(Cliente,Respuesta);
end;
Lneas de Comunicacin
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 12
La Comunicacin - 12
Interfaz
del
Servicio
Bsqueda
del
Servidor
Gestin
de
Comunicaciones
Binding
Sistemas Distribuidos
Sistemas Distribuidos
Sistemas Distribuidos
El software que soporta las llamadas a procedimientos remotos debe ocuparse de tres
importantes tareas:
La Interfaz del Servicio. Es decir, la integracin del mecanismo de la RPC con los
programas del cliente y del servidor, estando stos escritos en lenguajes de
programacin convencionales. Esto incluye la serializacin (marshalling y
unmarshalling) de los parmetros que se pasan entre el cliente y el servidor, as
como el establecimiento, en el servidor, de un mecanismo (dispatcher) que reparta
las peticiones entre las rutinas de servicio apropiadas.
Bsqueda del Servidor. Este proceso es el mecanismo que ya hemos visto,
conocido como binding, que consiste en asignar el servidor apropiado ms
conveniente para el servicio que requiere el cliente.
Gestin de la Comunicacin. Esta tarea consiste simplemente en la transmisin y
recepcin de los mensajes de peticin y de respuesta.
Puesto que la bsqueda del servidor ya la hemos tratado en las transparencias previas,
en las siguientes pasaremos a ver con cierto detalle la Interfaz del Servicio. En cuanto a
la gestin de la comunicacin, sta se basa directamente en servicios de comunicacin
ofrecidos por el sistema operativo, por lo que aqu nos centraremos en el tratamiento de
errores, tanto de comunicacin como de los fallos en el cliente o servidor.
La Comunicacin - 13
La Comunicacin - 13
La Comunicacin - 13
Usuario
Stub
Cliente
Paso a form.
nativo
Aplanar
Paso a XDR
Recibir
Proceso Cliente:
- Programa del usuario
- Stub del cliente
Proceso Servidor:
- Stub del servidor (incluye el repartidor de peticiones o dispatcher)
- Rutinas de servicio del servidor (las que realizan la operacin solicitada).
Rutinas
Servicio
Dispatcher
Enviar
Stub Retorno
Servidor
Paso a form.
nativo
Recibir
SERVIDOR
Llamada
local
Aplanar
Paso a XDR
Enviar
Como se puede ver en el grfico, ambos stubs, del cliente y del servidor, se apoyan en
los servicios de comunicaciones que ofrece el sistema operativo, y uno de sus
cometidos bsicos es el paso de parmetros entre cliente y servidor. (En la siguiente
transparencia trataremos el paso de parmetros)
Esta tarea encargada de la interfaz debe preocuparse de la construccin del programa
cliente y del programa servidor. Para ello, debe generar el software apropiado y juntar
todos los componentes para formar los dos programas.
El programa del usuario y las rutinas de servicio del servidor vienen dadas, as como el
mdulo de comunicacin, que lo proporciona el sistema operativo. Falta por construir los
stubs del cliente y del servidor. Veremos entonces, despus del paso de parmetros,
cmo se realiza la generacin de stubs, tambin conocida como generacin de
interfaces.
Mdulos de
Comunicaciones
del S.O.
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 14
La Comunicacin - 14
El Paso de Parmetros
La representacin de los
datos es distinta
(estructuras y escalares)
No se pueden pasar
parmetros por referencia
(listas dinmicas, ...)
Ya hemos visto que una de las funciones del stub del cliente es coger los parmetros de entrada,
ponerlos en un mensaje y enviarselos al stub del servidor. Sin embargo se presentan algunos
problemas para hacer esto.
En primer lugar debe tenerse en cuenta que los datos en los programas suelen estar
representados mediante estructuras de datos, mientras que en un mensaje la informacin debe
ser una secuencia de bytes; por lo tanto, se debe establecer un mecanismo para aplanar o
serializar los parmetros y pasarlos al mensaje. Aplanar significa tomar cualquier estructura de
datos y reordenarla como una secuencia de bytes. Esto debe hacerse tambin con las estructuras
de datos dinmicas (listas enlazadas), que deben pasarse a una serie de valores formando una
secuencia de bytes.
Aunque el aplanamiento (marshalling, en ingls) de los parmetros podra ser una tarea fcil, no
lo es. Por desgracia, los lenguajes utilizados para programar los distintos procesos de la red y los
procesadores en los que se ejecutan, utilizan diferentes representaciones de los datos que
manipulan (distinto tamao y representacin para los enteros complemento a uno o
complemento a dos, distintas fronteras de alineamiento, distintos cdigos de caracteres ASCII
o EBCDIC, ). Esto quiere decir que si un dato lo aplanamos en un proceso, lo ponemos en un
mensaje y se lo enviamos a otro proceso de la red (en una mquina distinta), es muy posible que
el formato en el que se reciben los datos no sea el que espera el receptor, por lo que el contenido
del mensaje podra no entenderse o ser malinterpretado.
Un motivo de la interpretacin errnea de datos por distintas arquitecturas es el debido a la
representacin de los nmeros en la memoria. Las tiras de caracteres estn compuestas por
caracteres sucesivos, tal que cada uno de ellos ocupa un byte, y el carcter siguiente va a
continuacin en el siguiente byte de memoria. Pero para los nmeros, por ejemplo los enteros,
que suelen ocupar 32 bits (4 bytes), hay dos formas de ordenar los cuatro bytes:
Little-endian: El byte menos significativo del entero est en la direccin ms baja. (Intel)
Big-endian: El byte menos significativo est en la direccin ms alta. (Motorola, SPARC).
Sistemas Distribuidos
Sistemas Distribuidos
Para evitar este problema del formato de representacin de los datos, los procesos
comunicantes deben ponerse previamente de acuerdo en el formato en el que se van
intercambiar los datos. Hay tres alternativas en el tipo de acuerdo a tomar:
Antes de la transmisin, los datos se convierten a un formato genrico conocido por todos
los procesos (representacin externa de datos). En el receptor se convierten al formato local
de su arquitectura. Algunos estndares de representacin externa de datos son: XDR de
Sun, Courier de Xerox y ASN 1.
Para la comunicacin entre dos ordenadores con arquitectura comn, el paso anterior puede
omitirse. Esto requiere que antes de la transmisin de los parmetros (al establecer la
sesin de comunicacin), los dos extremos negocien si se requiere pasar los datos a un
formato genrico o no.
Otra posibilidad consiste en transmitir los datos en su formato nativo (el de la arquitectura
del transmisor) junto con un identificador del tipo de arquitectura subyacente. El receptor,
consultando el tipo de arquitectura utilizado, decide si es necesario convertir los datos
recibidos o no.
La Comunicacin - 15
La Comunicacin - 15
Un Ejemplo
package Reloj is
type Tiempos is record
Hora:
t_Horas;
Interfaz de las Rutinas
Minutos: t_Minutos;
de Servicio del Servidor
Segundos: t_Segundos;
y del Stub del Cliente
Dia:
t_Dias;
Mes:
t_Meses;
Ao:
t_Aos;
Zona:
t_Zonas;
end record;
type Operaciones is (SET_TIME, GET_TIME);
procedure Pedir_Hora (t: out Tiempos) return Status;
procedure Poner_Hora (t: in Tiempos) return Status;
end Reloj;
Stub del
Cliente para
Poner_Hora
begin
M = Mensajeaddress;
M = Marshall (M, Mi_Direccin);
M = Marshall (M, SET_TIME);
M = Marshall (M, t);
OK = Envia_Mensaje(Servidor_Reloj, Mensaje);
if OK then
Recibir (Mensaje);
UnMarshall_Boolean (Mensaje, OK);
end if;
return (OK);
end Poner_Hora;
...
...
end Reloj;
Sistemas Distribuidos
Sistemas Distribuidos
Aqu tenemos un ejemplo simplificado de una RPC para comunicarse con un Servidor de
Reloj, que ofrece servicios para proporcionar y establecer una fecha y hora actual.
La interfaz del servidor consta de dos procedimientos y una estructura de datos, tal
como se muestra en la parte superior de la transparencia. Como ya hemos dicho, la
interfaz del stub del cliente debe ser idntica a la ofrecida por las rutinas de servicio del
servidor.
El cuerpo o implementacin del stub del cliente contiene el cdigo correspondiente a los
dos procedimientos definidos en su interfaz. Veamos el aspecto del procedimiento
Poner_Hora. En este procedimiento se declara un mensaje que lo rellena con un
cdigo de operacin (SET_TIME) que identifica la operacin que se va a solicitar al
servidor, y con sus parmetros, es decir, el contenido de la estructura t de tipo
Tiempos.
Una vez que el mensaje ya est formado, se enva mediante la primitiva
Envia_Mensaje que ofrece el nivel de transporte o directamente el sistema operativo
subyacente.
A continuacin debe ponerse a esperar la respuesta del servidor, cosa que hace
mediante la primitiva Recibir. Hasta que llega la respuesta, el proceso queda
bloqueado o en espera. Cuando llega el mensaje de respuesta, deben sacarse los
datos de respuesta del mensaje y devolverlos como parmetros de salida del
procedimiento Poner_Hora.
Obsrvese que mientras que el cliente permanece abstrado del verdadero mecanismo
de comunicacin utilizado, el programador del stub del cliente tiene todo el conocimiento
de la semntica de comunicacin necesaria, y por lo tanto sabe que debe enviar un
mensaje con los datos necesarios a travs de la red, y quedarse esperando un mensaje
de respuesta; tambin conoce los datos que debe extraer del mensaje de respuesta para
devolver los parmetros de salida indicados en su interfaz.
Tambin deben tenerse en cuenta las rutinas Marshall y UnMarshall, cuyo cometido
es adaptar los parmetros de entrada al formato de datos esperado por el servidor; y, al
contrario, adaptar el resultado devuelto por el servidor al formato nativo del cliente.
En algunos casos, por comodidad, utilizaremos el trmino serializar o serializacin
para referirnos tanto a la serializacin como a la deserializacin de los datos.
La Comunicacin - 16
La Comunicacin - 16
...Un Ejemplo
procedure Stub_Servidor_Reloj is
Mensaje: string (1..32);
M: system.address;
OK: boolean;
Stub del
Operacin: Operaciones;
t: Tiempos;
Servidor del Reloj
begin
loop
Recibir (Mensaje);
M = Mensajeaddress;
M = UnMarshall (M, Remitente);
M = UnMarshall (M, Operacin);
case Operacin is
when SET_TIME =>
M = UnMarshall (M, t);
M = Mensajeaddress;
OK = Poner_Hora (t);
Marshall (M, OK);
when GET_TIME =>
/* Codigo para deserializar
datos y llamar a Pedir_Hora
*/
end case;
Envia_Mensaje (Remitente, Mensaje);
end loop;
end Stub_Servidor_Reloj;
Sistemas Distribuidos
Sistemas Distribuidos
Pasemos ahora a ver el aspecto del stub del servidor. Como veremos, tiene una
estructura muy distinta a la del cliente, pues el stub del servidor es un proceso que
recibe peticiones de distinto tipo de todos los clientes.
El stub del servidor debe averiguar el tipo de peticin que le enva el cliente, deserializar
de los datos del mensaje (o unmarshalling) y pasrselos, como parmetros de entrada, a
la rutina de servicio que ejecutar la operacin solicitada por el cliente.
Como se puede apreciar en el cdigo del ejemplo, el stub del servidor consta de un
bucle infinito, y en cada iteracin del bucle atiende una solicitud de un cliente. As, nos
encontramos con que en primer lugar llama a la primitiva Recibir para recoger un
mensaje con la peticin de un cliente. Una vez recibido un mensaje, averigua el tipo de
operacin solicitada (Operacin), y en funcin de la operacin requerida, extrae y
deserializa los datos del mensaje, y los utiliza como parmetros de entrada en la
llamada a la rutina de servicio correspondiente.
En el ejemplo se muestra en detalle el cdigo correspondiente a una solicitud de la
operacin SET_TIME. Como vemos, extrae y deserializa los datos del mensaje mediante
la funcin UnMarshall, para formar la estructura local de tipo Tiempos. A continuacin
llama a la rutina de servicio Poner_Hora pasndole como parmetro de entrada la
estructura t.
La rutina Poner_Hora (que es local) tras su ejecucin devuelve un cdigo de resultado
OK, indicando si la operacin se pudo realizar o no. El stub del servidor entonces toma
este cdigo de resultado, lo serializa y lo pone en el mensaje de respuesta.
Lo ltimo que le queda por hacer al stub del servidor es enviar el mensaje de respuesta
al cliente (concretamente al stub del cliente). Hecho esto, se vuelve al principio del bucle
donde se espera por un nuevo mensaje de algn cliente.
La Comunicacin - 17
La Comunicacin - 17
Generacin de Stubs
Proceso de
Generacin
de las RPC
Interfaz de las
Rutinas de Servicio
DISTINTA
REPRESENTACIN
DE LOS DATOS
Serializacin
de Datos
Sistemas Distribuidos
Sistemas Distribuidos
A partir de la interfaz de las rutinas de servicio (o del stub del cliente), puede construirse
manualmente la implementacin de los stubs del cliente y el servidor, no obstante, puesto que lo
que hay que hacer es muy mecnico, parece razonable automatizar el proceso.
Sin embargo, se presenta un problema inesperado: resulta que las interfaces de las rutinas de
servicio del servidor y del stub del cliente no son exactamente iguales!
En el ejemplo de las transparencias anteriores estas interfaces eran exactamente iguales. Pero es
que hasta ahora hemos obviado el hecho de que los procesos cliente y servidor estn en
mquinas distintas, y hemos supuesto que stas son iguales o equivalentes. Pero la realidad es
que en un sistema distribuido los componentes son heterogneos, con lo que los procesos cliente
y servidor se pueden haber programado en lenguajes diferentes, apoyados en sistemas
operativos variados y ejecutndose sobre procesadores de distinta arquitectura. Por otra parte,
nos encontramos con que el servidor debe ofrecer una interfaz genrica para todos sus clientes.
La nica forma de solucionar esto es que el servidor no ofrezca la interfaz de sus servicios acorde
a un lenguaje de programacin especfico, sino en un lenguaje genrico al que se le denomina
Lenguaje de Definicin de Interfaces (IDL).
Los lenguajes de definicin de interfaces suelen estar derivados de otros lenguajes de
programacin, pero para construir los stubs aaden cierta informacin necesaria que no todos los
lenguajes de programacin proporcionan. Esta informacin adicional tpicamente es: el sentido de
los parmetros (entrada, salida, entrada/salida), discriminantes para registros variantes (o
uniones) e informacin sobe la longitud de los vectores o matrices que se pasan como
parmetros.
Ejemplos de IDLs son: NCS (de la OSF), XDR (de Sun), Courier (de Xerox), MiG (de Mach).
Ahora nos encontramos con que a partir de una definicin de una interfaz genrica (realizada en
un IDL) se deben generar las interfaces y los cuerpos o implementaciones apropiadas para los
lenguajes del servidor y de cada cliente.
A partir de una definicin genrica en IDL y un compilador de interfaces, se pueden realizar
automticamente las siguientes tareas:
1. Generacin del stub del cliente (y su fichero de interfaz) para todos los perfiles (o firmas) de
los procedimientos definidos en la interfaz. El stub se compilar y se montar con el
programa del cliente.
2. Generacin del stub del servidor con el repartidor (o dispatcher) para todas las operaciones
ofrecidas por el servidor. El stub y el repartidor (incluido en el stub) se montarn con el
programa del servidor.
3. Generacin del fichero de definicin de las operaciones ofrecidas, para el lenguaje
correspondiente en el que estn implementadas en el servidor. Los cuerpos
correspondientes a estas definiciones las proporciona el programador de las operaciones
del servidor.
4. Aprovechando la definicin del perfil de los procedimientos de interfaz (que definen los
tipos de los parmetros de entrada y salida), se generan las acciones apropiadas para la
serializacin correspondiente a cada procedimiento de interfaz en los stubs del cliente y del
servidor.
La utilizacin de una definicin comn de la interfaz en el proceso de generacin de los stubs del
cliente y del servidor y el fichero de definicin de los servicios del servidor, asegura que los tipos
de los argumentos y de los resultados manejados por el cliente se ajustan a los definidos por el
servidor.
La Comunicacin - 18
La Comunicacin - 18
...Generacin de Stubs
CLIENTE
Usuario
Programador
Interfaz
Genrica en IDL
Programa del
Usuario
Generador de
Interfaces
Interfaz en
Leng. Fuente_C
Stub del
Cliente
Compilador del
Leng. Fuente_C
Compilador del
Leng. Fuente_C
Programa Obj_C
del Usuario
Stub Obj_C
del Cliente
Linker
Cliente Completo
Ejecutable en
Mquina_C
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 19
La Comunicacin - 19
...Generacin de Stubs
SERVIDOR
Programador
del Servidor
Interfaz
Genrica en IDL
Generador de
Interfaces
Cuerpo de las
Rutinas de Servicio
Interfaz en
Leng. Fuente_S
Stub Fuente_S
del Servidor
+ Dispatcher
Compilador del
Leng. Fuente_S
Compilador del
Leng. Fuente_S
Stub Obj_S
del Servidor
Linker
Servidor Completo
Ejecutable en
Mquina_S
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 20
La Comunicacin - 20
Tratamiento de Errores
TIPOS DE ERRORES EN LA
EJECUCIN DE UNA RPC
ERRORES DE
COMUNICACIN
- No se puede
localizar al servidor
- Prdida de mensajes
de peticin
FALLO EN EL
SERVIDOR
- Parmetros incorrectos,
Op. no permitida,
Fin de Fichero.
FALLO EN
EL CLIENTE
Errores de Comunicacin.
- No se puede localizar al servidor
- Prdida de mensajes de peticin
- Prdida de mensajes de respuesta.
Fallo en el Servidor
- Error por parmetros incorrectos, operacin no permitida, etc.
- Cada del Servidor
Fallo en el Cliente.
- Cada del cliente
- Prdida de mensajes
de respuesta
En las transparencias siguientes veremos con cierto detalle cmo pueden tratarse cada
una de estas situaciones.
Como veremos, debido a estos errores, en las RPC debe incluirse cdigo adicional para
tratarlos convenientemente, lo cual hace dudar sobre si las RPC deben ser totalmente
transparentes al usuario o se le deben ofrecer a ste primitivas distintas para que sea
consciente del tratamiento que le debe dar a cada situacin de error.
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 21
La Comunicacin - 21
Fallos de Comunicacin
Servidor
No Disponible
PRDIDA
No Confundir!
DE MENSAJES DE PETICIN
PRDIDA
Pet.
DE MENSAJES DE RESPUESTA
Recibe
Ejecuta
Responde
Res.
Pet.
No
Res.
Recibe
Ejecuta
Fallo!
Pet.
Recibe
Fallo!
No
Res.
Qu ha pasado?
Si no se obtiene respuesta Repetir la peticin?
Solo con operaciones idempotentes
Solucin: Numero de secuencia en las peticiones
Sistemas Distribuidos
Sistemas Distribuidos
La solucin obvia a este problema podra estar en apoyarse otra vez en las
temporizaciones, de tal forma que si no se recibe la respuesta en un tiempo finito,
simplemente se vuelve a enviar la peticin. Pero este reenvo lo hace el cliente sin
saber cul es el motivo de no haber recibido la respuesta: se perdi la peticin?,
se perdi la respuesta? o simplemente es que el servidor es lento?; y esto puede
ser un problema.
Si se perdi la peticin, no hay ningn problema, pero si se perdi la respuesta
implica que las operaciones solicitadas van a repetirse. Algunas operaciones pueden
repetirse varias veces sin ningn problema (por ejemplo, sumar dos matrices). Estas
operaciones se dice que son idempotentes. Pero otras no pueden repetirse
alegremente, por ejemplo, una orden de transferencia bancaria de un milln de
euros. Para evitar la repeticin de una misma operacin, las peticiones pueden incluir
un nmero de secuencia, de tal forma que en el servidor se compruebe que no se
ejecuta dos veces la misma operacin, y cuando le llega una peticin repetida, no la
ejecuta, sino que simplemente responde con el resultado.
La Comunicacin - 22
La Comunicacin - 22
Fallo en el Servidor
En el Servidor puede
producirse un fallo por
EXCEPCIN
ERROR
La rutina de servicio no
puede ejecutar la operacin
- Parmetros invlidos
- Operacin no permitida
- Lectura despus de EOF
Antes
Despus?
de ejecutar la operacin
Re-ejecutar servicio /
Retransmitir respuesta
QUIZS
No
No
No
AL MENOS UNA
Si
No
Re-ejecutar
COMO MUCHO
UNA
Si
Si
Retransmitir
respuesta
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 23
La Comunicacin - 23
Fallo en el Cliente
Servidor arranca
la operacin
correspondiente
Cliente realiza
una peticin
El cliente
se cae
OPERACIN HURFANA
- Desperdicio de CPU
- Ficheros o recursos bloqueados
- Respuestas antiguas a un cliente rearrancado
EXTERMINACIN
- El stub hace un apunte antes de enviar la RPC
Al rearrancar se pide al servidor que mate al hurfano
S
- Problemas: Sobrecarga de escritura en disco
O
Si red partida inaccesibles
L
U REENCARNACIN
C
- Cada arranque del cliente es una poca
I
Cada peticin lleva su poca
O
En rearranque del cliente: Broadcast nueva poca
N
El servidor mata operaciones de pocas pasadas
E
- Problema: Si red partida inaccesibles
S
El cliente rearrancado
tira respuestas antiguas
EXPIRACIN: Cada RPC lleva su porcin de tiempo
Matar a un hurfano
trae consecuencias
imprevistas
No Matar Hurfanos!
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 24
La Comunicacin - 24
Unix - NFS
PC-NFS
...
Se han implementado diversos sistemas de RPC para Unix. Aqu vamos a comentar la
RPC que Sun realiz en 1990 para soportar el modelo cliente-servidor sobre el que se
construy su sistema de ficheros en red NFS.
Aunque este mecanismo forma parte de los sistemas operativos de Sun, tambin puede
encontrarse con otras instalaciones de NFS que se han desarrollado, por ejemplo para
Windows (PC-NFS) y para diversas variedades de Unix.
El sistema de RPC de Sun proporciona un lenguaje de definicin de interfaz llamado
XDR (eXternal Data Representation) y un compilador de interfaces denominado rpcgen.
A partir de una interfaz definida en XDR y con ayuda del rpcgen, se obtiene gran parte
de los componentes del mecanismo completo de una RPC, es decir:
El stub del cliente.
Ficheros de
cabeceras (.h)
Procedimientos de
serializacin
No consigue
transparencia
total al usuario
Sistemas Distribuidos
Sistemas Distribuidos
El usuario requiere
utilidades de bajo nivel
La Comunicacin - 25
La Comunicacin - 25
Sun RPC
Generacin de Interfaz
rpcgen
Sistemas Distribuidos
Rutinas de serializacin (a formato XDR) que utilizarn tanto el stub del cliente
como el del servidor.
Fichero .h
Procedimientos
de serializacin
La Comunicacin - 26
La Comunicacin - 26
...Generacin de Interfaz
Sun RPC
/* archivador.h
* Please do not edit this file.
* It was generated using rpcgen.
*/
#include <rpc/types.h>
No obstante, merece la atencin ver al final del fichero las definiciones de las constantes
con los valores (indicados en el fichero XDR) del programa ARCHIVADOR y de su versin
VERSION_ACTUAL.
Tambin se proporcionan las definiciones de las dos operaciones declaradas. Por una
parte sus cdigos de operacin, ESCRIBIR y LEER, respectivamente, y por otra el perfil
de sus llamadas: escribir_2 y leer_2. Como puede observarse, los nombres de los
procedimientos asociados a las operaciones se forman con el nombre de la operacin
definida en XDR, en minsculas, seguido de un subrayado y el nmero de la versin.
Sistemas Distribuidos
La Comunicacin - 27
La Comunicacin - 27
Marshalling
Sun RPC
La RPC de Sun puede pasar cualquier tipo de estructuras de datos como argumentos o
resultados, utilizando XDR como sistema de representacin externa de datos.
El sistema dispone de las rutinas estndar que serializan automticamente datos de los
siguientes tipos:
- Tipos Enumerados
- Arrays
- Estructuras
- Registros con discriminante
- Punteros
- Listas enlazadas
Reales
Booleanos
Caracteres
Strings
Tipos enumerados
Tipos opacos (tipos abstractos de datos)
Arrays
Estructuras
Registros con discriminante
Punteros
rpcgen
Ficheros de
cabecera
Prog. Principal Servidor
(incluye dispatcher y
stub del servidor)
Este sistema tambin permite pasar listas dinmicas como parmetros, siendo los stubs
los que se encargan de aplanarlos y desaplanarlos automticamente mediante rutinas
de biblioteca previstas para ello.
Si los parmetros son de tipos predefinidos en XDR, los stubs utilizan directamente
rutinas de librera (definidas en rpc.h) para la serializacin. No obstante, XDR permite
la definicin de tipos de usuario, por lo que los parmetros pueden ser de un tipo
definido por el usuario. En este caso, rpcgen genera las rutinas adecuadas para
serializar el parmetro, y las deja en un fichero con nombre archivador_xdr.c,
siendo archivador el nombre sin extensin del fichero de definicin de la interfaz en
XDR.
Los stubs del cliente y servidor realizarn las llamadas oportunas a las rutinas de librera
o a las generadas en archivador_xdr.c para serializar los datos del mensaje.
Procedimientos de
serializacin
Archivador_xdr.c
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 28
La Comunicacin - 28
Binding
Sun RPC
Puerto
111
Binder
Programa
Servidor
Como se puede apreciar, los binders deben atender siempre las peticiones por un puerto
fijo, mientras que los servidores pueden escuchar por cualquier puerto, puesto que es el
binder el que realiza la correspondencia dinmica entre identificador de servidor y el
puerto por el que escucha.
b
c
d
puertos
Fijo y preestablecido
Dinmico
Programa
Cliente
Sistemas Distribuidos
Sistemas Distribuidos
Broadcast
Servidor 1
Servidor 2
111
El binder de cada mquina es un servidor que atiende las peticiones por un puerto fijo
predeterminado e igual para todas las mquinas (111), y se arranca automticamente en
el proceso de arranque del sistema. Cuando un servidor arranca, se registra en el binder
de su ordenador, indicando el identificador (nmero) del servidor, la versin y el puerto
por el que escucha.
Cuando un cliente efecta una RPC, debe indicar el nombre o direccin de la mquina o
host del servidor correspondiente. El stub del cliente entonces le enva al binder de esa
mquina una peticin con el identificador del servicio solicitado y la versin. Si el
identificador y versin son correctos, el binder del host del servidor responde con el
puerto al que se pueden enviar las peticiones del cliente.
a
Programa
Cliente
Las RPC de Sun no ofrecen un servicio de binding a nivel de red, sino solamente local,
es decir, en cada mquina hay un binder (Sun lo denomina portmapper) que indica el
puerto por el que escucha cada uno de los servidores de esa mquina.
Binder
Servidor 3
Servidor 4
Cuando por algn motivo hay que enviar un mensaje a todos los servidores de un
servicio, lo que se hace es enviar un mensaje por broadcast a un puerto concreto,
esperando que todos los servidores del servicio en cuestin estn escuchando por ese
puerto. Sin embargo, en nuestro caso, cuando para un servicio hay mltiples servidores
en distintas mquinas, cada servidor puede utilizar un puerto distinto para recibir las
peticiones, con lo que no sirve el sistema de envo mltiple y directo de mensajes visto
hasta ahora.
En su lugar, lo que debe hacer el cliente es hacer un envo mltiple de una RPC
especial, que llega a todos los binders locales de todas las mquinas (puesto que todos
tienen un puerto fijo). Cada binder que recibe la peticin, analiza el mensaje extrayendo
el identificador del programa y la versin. Si estos son vlidos (el servidor existe y la
versin es correcta), redirige el mensaje al puerto correspondiente por el que atiende el
servidor.
Una forma de localizar un servicio que no se sabe en qu mquina est, es haciendo un
broadcast a todos los binders para que hagan una llamada al procedimiento 0 del
servicio buscado. El procedimiento 0 de cada servicio est predefinido y se utiliza para
hacer ping (preguntar si est vivo).
La Comunicacin - 29
La Comunicacin - 29
Sun RPC
/*
Programa del usuario del servicio de archivos: cliente.c
*/
#include <stdio.h>
#include <rpc/rpc.h>
#include Archivador.h
main (int argc, char **argv) {
CLIENT *id_cliente;
char *Nombre_Servidor = ServidorFavorito;
Args_Lectura a;
Datos *Mis_Datos;
Sistemas Distribuidos
Hemos dicho que, debido a la transparencia, un programa con llamadas locales debera
ser exactamente igual a uno en el que las llamadas son remotas. Sin embargo, el
sistema de RPC de Sun no ofrece una transparencia absoluta, y el usuario debe realizar
ligeras modificaciones a las llamadas de su programa.
El motivo por el que no se consigue una transparencia total se debe, en gran medida, a
que no se dispone de un servicio de binding global a nivel de red. Por esto, el usuario, al
comienzo del programa, debe solicitar la direccin completa del servidor que ofrece el
servicio a utilizar. Una vez que se le devuelve un descriptor de cliente, el usuario debe
incluir el descriptor de cliente en todas las RPC dirigidas a ese servicio. Cuando ya no
va a realizar ms RPC, el usuario debe cancelar el descriptor de cliente que se le haba
concedido para trabajar con el servidor.
Como se puede ver en el ejemplo, un descriptor de cliente se obtiene mediante
clnt_create (MaquinaServidor,Id_Servicio,Versin,Protocolo);
Sistemas Distribuidos
La Comunicacin - 30
La Comunicacin - 30
Sun RPC
/* archivador_clnt.c
* Please do not edit this file.
* It was generated using rpcgen.
*/
#include <rpc/rpc.h>
#include "archivador.h"
/* Default timeout can be changed using clnt_control() */
static struct timeval TIMEOUT = { 25, 0 };
void * escribir_2(argp, clnt)
Args_Escritura *argp;
CLIENT *clnt;
{
static char res;
bzero((char *)&res, sizeof(res));
if (clnt_call(clnt, ESCRIBIR, xdr_Args_Escritura, argp,
xdr_void, &res, TIMEOUT) != RPC_SUCCESS)
{
return (NULL);
}
return ((void *)&res);
}
Datos * leer_2(argp, clnt)
Args_Lectura *argp;
CLIENT *clnt;
{
static Datos res;
El stub del cliente contiene tantas rutinas como operaciones tiene el servicio. En nuestro
caso tenemos dos: escribir_2 y leer_2.
Estos procedimientos no hacen mucho. En realidad su cometido consiste en pasar los
parmetros al formato de codificacin externa, aplanar estructuras y solicitar el envo del
mensaje por la red.
Dentro de cada uno de estos dos procedimientos, la llamada a la funcin clnt_call es
la que realiza estas labores descritas. Veamos cuales son los parmetros que se le
pasan a esta funcin clnt_call:
El descriptor de cliente
Identificador de operacin
Rutina para serializar el argumento
Argumento de entrada de la operacin
Rutina para deserializar el resultado
Direccin de una variable en la que se recibir el resultado de la RPC
Tiempo total mximo de espera a la respuesta
Recurdese que si se requieren varios parmetros de entrada en la llamada a la RPC,
estos deben organizarse todos en una estructura, de tal forma que se pase un nico
parmetro. No obstante, en las versiones actuales de RPC s se permite el paso de
varios parmetros directamente, sin necesidad de meterlos en una estructura
La funcin clnt_call utiliza una semntica del tipo al menos una. El tiempo de
espera entre reintentos tiene un valor por defecto que se puede modificar en el
programa del usuario mediante clnt_control, despus de llamar a clnt_create.
As, el nmero de reintentos es el tiempo total dividido entre el tiempo entre reintentos.
Despus de enviar un mensaje, espera la respuesta durante un tiempo, y si no llega,
realiza varios reintentos. Si no se consigue ninguna respuesta, clnt_call devuelve un
cdigo de error. Si la RPC tiene xito, clnt_call devuelve un cero. El resultado de la
RPC se deposita en la direccin indicada en la llamada a clnt_call debidamente
deserializada.
Sistemas Distribuidos
La Comunicacin - 31
La Comunicacin - 31
Sun RPC
/* archivador_svc.c
* Please do not edit this file.
* It was generated using rpcgen.
*/
#include <stdio.h>
#include <rpc/rpc.h>
#include "archivador.h"
El programa completo del servidor est compuesto por el programa principal (con el stub
y el dispatcher), las rutinas para la serializacin y las rutinas de servicio que debe
escribir el programador del servidor.
El programa servidor que crea rpcgen esta compuesto por el programa principal (main)
y el dispatcher, que recibe el nombre del servicio seguido de un subrayado y la versin
(en nuestro ejemplo, archivador_2).
En esta primera parte del programa servidor veremos cmo se realiza el registro del
servicio en el binder.
En primer lugar, se debe crear el socket con el que se van a atender las peticiones del
cliente. Ya que la RPC de Sun soporta los dos protocolos de transporte TCP y UDP, se
crea un socket para cada protocolo. As, tenemos que hay una llamada a
svcudp_create y otra a svctcp_create, de tal forma que cada una de ellas
devuelve un descriptor de socket, con el que posteriormente se llama a la funcin de
registro svc_register.
Una vez registrado el servidor, se debe pasar a recibir y servir peticiones. Esto se realiza
llamando a la funcin svc_run, que consta de un bucle sin fin en el que se esperan
peticiones del cliente. Cada vez que se recibe una peticin del cliente le pasa la peticin
al dispatcher (archivador_2, en nuestro ejemplo).
Pasemos a la transparencia siguiente para ver nuestro dispatcher.
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 32
La Comunicacin - 32
Sun RPC
case LEER:
xdr_argument = xdr_Args_Lectura;
xdr_result = xdr_Datos;
local = (char *(*)()) leer_2;
break;
default:
svcerr_noproc(transp);
return;
}
bzero((char *)&argument, sizeof(argument));
if (!svc_getargs(transp, xdr_argument, &argument)) {
svcerr_decode(transp);
return;
}
result = (*local)(&argument, rqstp);
if (result != NULL && !svc_sendreply(transp, xdr_result, result)) {
svcerr_systemerr(transp);
}
if (!svc_freeargs(transp, xdr_argument, &argument)) {
fprintf(stderr, "unable to free arguments");
exit(1);
}
return;
}
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 33
La Comunicacin - 33
Sun RPC
Herramientas de diagnstico
Las facilidades proporcionadas por las RPC de Sun descritas hasta ahora son
suficientes para implementar la mayora de los sistemas. No obstante en algunos casos
pueden ser necesarias algunas utilidades que proporcionan un control adicional del
programador sobre el sistema generado automticamente. Aqu simplemente
enumeraremos algunas de ellas.
Llamadas remotas para comprobar si un servidor est activo o no. (procedimiento
nulo).
Llamadas remotas para comprobar cdigos invlidos de operacin.
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 34
La Comunicacin - 34
RPC Asncronas
Esto puede crear cierta ineficiencia en el cliente, puesto que mientras est esperando la
respuesta no puede hacer nada, mientras que en algunas situaciones, sera deseable
que pudiese realizar otras tareas mientras espera la respuesta, esto es, un
comportamiento asncrono.
... ESPERA...
Recibir
Deserializar result. 1
Tratar resultado 1
Generar args. 2
Serializar
Enviar
... ESPERA...
Recibir
Deserializar result. 2
Tratar resultado 2
Cliente
Tras la llamada a una RPC,
el cliente queda bloqueado
hasta recibir el resultado.
Sistemas Distribuidos
Sistemas Distribuidos
Las RPC que hemos tratado hasta ahora siguen el mismo modelo que las llamadas a
procedimientos locales, es decir, son sncronas. Esto quiere decir que cuando el proceso
cliente realiza la llamada, queda bloqueado hasta recibir la respuesta del servidor.
Servidor
... ESPERA...
Recibir
Deserializar params. 1
Ejecutar peticin
Serializar resultado 1
Enviar
... ESPERA...
Recibir
Deserializar params. 2
Ejecutar peticin
Serializar resultado 2
Enviar
... ESPERA...
Servidor
Prdida de tiempo!
La Comunicacin - 35
La Comunicacin - 35
...RPC Asncronas
Cliente
Servidor
... ESPERA...
Recibir
Deserializar params. 1
Ejecutar peticin
Serializar resultado 1
Enviar
Recibir
Deserializar params. 2
Ejecutar peticin
Serializar resultado 2
Enviar
... ESPERA...
Servidor
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 36
La Comunicacin - 36
RMI de Java
La Comunicacin
Servicio RMI
Interfaz + Implementacin
O b j e t o
Mtodo_1
Variables
(estado)
Mtodo_2
comportamiento
Mtodo_3
Un servicio est formado por su interfaz, que define el conjunto de operaciones que va
ofrecer dicho servicio, y por la implementacin de dichas operaciones, soportada por los
objetos del servicio.
Un objeto es una entidad identificable de manera nica en todo el sistema, que cuenta
con un estado y un comportamiento. El estado se mantiene mediante el uso de un
conjunto de variables, mientras que su comportamiento se implementa mediante los
mtodos correspondientes a cada una de sus operaciones. Un mtodo es una funcin
asociada con un objeto, cuya ejecucin generalmente modifica el estado del objeto.
Desde el exterior, el estado del objeto solo se puede cambiar a travs de la invocacin
de ciertos mtodos del objeto, conocidos como pblicos, por eso se dice que un objeto
es una entidad encapsulada.
En Java existen dos tipos de objetos: los objetos locales y los objetos remotos.
Un objeto es local si sus mtodos se invocan dentro de su mquina virtual. Es decir,
por el proceso que cre dicho objeto o por los threads del proceso.
OBJETO
Local
Interfaz Local
Sistemas Distribuidos
Sistemas Distribuidos
Remoto
Un objeto es remoto si permite que sus mtodos puedan invocarse por procesos que
residen en otras mquinas virtuales.
Interfaz Remota
La Comunicacin - 37
La Comunicacin - 37
Interfaz Remota
MV1
MV2
Proceso
Cliente
Interfaz del
servicio
stub
Interfaz
del servicio
Proceso
Servidor
Objeto remoto
que implementa
la interfaz
En Java existen dos tipos de interfaces: locales y remotas. Su objetivo es el mismo pues
ambas describen servicios. Sin embargo, van orientadas a distinto tipo de clientes.
Si la interfaz es local, solamente es accesible por los procesos clientes dentro de la
misma mquina virtual, pues no es visible fuera de esta mquina. Para permitir que
clientes remotos accedan a un determinado servicio es necesario que la interfaz sea
remota.
Una interfaz remota recoge la declaracin en Java de las operaciones que conforman
un servicio.
Por cada operacin se especifica el tipo y el nmero de los argumentos de entrada y el
tipo del resultado que devuelve, as como las excepciones que pueden producirse si hay
errores de ejecucin o de comunicacin.
Los parmetros que se pasan en la invocacin son solo de entrada y se pasan siempre
por copia. Los parmetros o el resultado de la operacin (si lo hay), pueden ser de tipos
primitivos o de tipo "objeto", es decir tipos abstractos de datos creados por el usuario.
Sistema RMI
Tipo y nmero de
argumentos de
entrada
Semntica
de
ejecucin
Sistemas Distribuidos
Sistemas Distribuidos
Excepciones
Sin fallos
Exactamente una
Con excepciones
La Comunicacin - 38
La Comunicacin - 38
Implementacin de un
Objeto Remoto
Objeto_1
Objeto_2
Objeto_3
Creacin y destruccin
d
re isti
mo nt
mi tos os o
sm o b
o fre jet
se c os
rv en
ici e
o l
El proceso servidor
- Destruye el objeto
A los objetos de una clase que implementa un servicio remoto se les conoce como
objetos remotos. En RMI puede haber ms de un objeto que implemente
simultneamente el mismo servicio.
Un objeto remoto, por s solo, no tiene vida propia por lo que es necesario que un
proceso, conocido como servidor, lo cree y, posteriormente, lo destruya cuando ya no
sea necesario.
Normalmente la vida de un objeto remoto se circunscribe a la vida del proceso servidor
que lo cre. Este tipo de objetos se denominan transitorios, sin embargo, hay veces
que interesa que el objeto remoto sobreviva cuando el proceso servidor muera. A stos
ltimos se les conoce como objetos permanentes.
- Crea el objeto
Objeto
Transitorio
Algunos objetos
necesitan sobrevivir
al proceso servidor
que los crea
Un ejemplo de objetos permanentes son los objetos que soportan cuentas bancarias, ya
que deben existir mientras exista la cuenta asociada. Sin embargo, como pueden existir
miles de cuentas bancarias simultneamente, sera imposible mantener
simultneamente miles de procesos servidores, uno por cada objeto que representa el
estado de una cuenta.
En esta situacin, interesa que el objeto remoto sobreviva al servidor que lo cre, de tal
manera que el estado del objeto pueda salvarse en disco (desactivarlo) cuando el
proceso muera y cargarse de nuevo (activarlo), mediante otro proceso servidor distinto,
en el momento en que se vuelva a necesitar.
Por ltimo, se debe indicar que un mismo servidor puede dar de alta y soportar
simultneamente varios objetos remotos que implementen, bien el mismo servicio, por
ejemplo con diferentes calidades de implementacin, o bien, diversos objetos que
implementen servicios distintos.
Objeto Permanente
Cuando un proceso muere,
el objeto se desactiva
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 39
La Comunicacin - 39
Modelo de Ejecucin
Proceso Servidor
Crear objeto del servicio
Registrar Servicio
Esperar peticiones
Recibir peticin
Tomar parmetros peticin
Averiguar mtodo apropiado
Objeto.mtodo_apropiado (parmetros)
Construir mensaje respuesta
Copiar al mensaje resultado del mtodo
Enviar mensaje de respuesta
Forever
Proceso Cliente
Objeto := Solicitar servicio a Servidor de Nombres
Resultado := Objeto.operacin (parmetros)
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 40
La Comunicacin - 40
Arquitectura de RMI
RMI de Java
Proceso Servidor
del servicio A
Proceso Cliente
Programa cliente
Servicio A
Stub A
Referencias Remotas
Referencias Remotas
Transporte de Java
Transporte de Java
TCP/IP
TCP/IP
Sistema Operativo
Sistema Operativo
Capas de
RMI
Sistemas Distribuidos
Sistemas Distribuidos
Stub
Referencias Remotas
Transporte de Java
La Comunicacin - 41
La Comunicacin - 41
Arquitectura de RMI
Proceso Servidor
del servicio A
Proceso Cliente
Programa cliente
Estado A
Stub A
Com. Servidor
Serializacin
invoke()
Referencias Remotas
Referencias Remotas
Transporte de Java
Transporte de Java
TCP/IP
TCP/IP
Sistema Operativo
Sistema Operativo
rmic
Servicio A
Objeto A1
Stub A1
Objeto A2
Stub A2
...
Objeto An
Sistemas Distribuidos
Sistemas Distribuidos
...
Capa de stub
Como se ha comentado antes, el cliente solo conoce la interfaz del servicio que quiere
invocar, pero esa interfaz, por ser una mera descripcin, no tiene utilidad si no est
soportada por un objeto; por otra parte tambin hemos dicho que el objeto real que
implementa el servicio solo reside en el servidor. Por tanto, el objeto que soporta la
interfaz del cliente debe encargarse, de alguna manera, de hacer llegar las peticiones al
objeto remoto y recoger las respuestas. Este objeto se conoce como representante del
objeto remoto, o ms comnmente stub o proxy.
El stub se encarga de establecer la comunicacin con el servidor, controlar dicha
comunicacin y realizar las operaciones de serializacin y deserializacin de parmetros
y del resultado. Todas estas operaciones las hace apoyndose en los servicios que
ofrecen las capas inferiores.
Cuando el cliente invoca un mtodo del servicio, el stub recoge dicha llamada, extrae el
nombre del mtodo y los parmetros, los serializa y llama al mtodo invoke con dicha
informacin. El mtodo invoke pertenece a la capa de referencias remotas, y su
funcin es similar a la de clnt_call en RPC, ya que a cualquier mtodo remoto de
cualquier servicio se le llama a travs de invoke.
La llamada a invoke es sncrona, por lo que el stub se queda esperando la respuesta.
Cuando el stub recibe la respuesta la deserializa y la devuelve al cliente como respuesta
del mtodo que invoc.
El cdigo del stub no tiene que escribirlo el programador sino que puede obtenerse por
dos vas: mediante el uso del compilador de interfaces o mediante carga dinmica.
El compilador de interfaces de java (rmic) toma como entrada la implementacin de una
interfaz remota en Java y genera el stub del cliente en Java. Obviamente, la obtencin
del stub debe realizarse previamente a la ejecucin del cliente.
La carga dinmica consiste en que el cliente, ya en ejecucin, carga de la mquina
servidora (ms concretamente, del servicio de nombres de la mquina servidora) el stub
del objeto remoto que desea utilizar.
Hay que destacar que el cliente necesita un stub para cada objeto remoto que use. Es
decir, si un cliente se conecta con dos objetos remotos que implementan el mismo
servicio, necesita dos stubs distintos que accedan a su objeto correspondiente, puesto
que esos dos objetos remotos posiblemente tienen estados distintos aunque
implementen la misma interfaz, es decir, el mismo servicio.
Por ejemplo, con una misma interfaz bancaria, se pueden tener dos objetos remotos que
representen el estado de dos cuentas de mismo banco, pertenecientes al mismo titular.
En este caso el cliente necesitara dos stubs.
Hasta la versin 1.1 de Java haba que generar tanto el stub del cliente como el stub o
esqueleto del servidor. Cuando llegaba una peticin al stub servidor, se deserializaba y
se llamaba al mtodo adecuado del objeto remoto. Por ltimo, se serializaba el resultado
y se construa el mensaje de respuesta que se enva al cliente.
A partir de Java 2, ya no hace falta la generacin del esqueleto del servidor, pues la
localizacin del mtodo a invocar se hace con una tcnica de programacin conocida
como "reflexin". Esta tcnica permite, en tiempo de ejecucin, descubrir la naturaleza
del objeto, por ejemplo a qu clase pertenece, las operaciones que soporta, etc.
Nosotros nos vamos ha centrar en la versin ms moderna, en la que no se requieren
los esqueletos.
Stub An
La Comunicacin - 42
La Comunicacin - 42
Arquitectura de RMI
Proceso Cliente
Referencias Remotas
Proceso Servidor
del servicio A
Programa cliente
Estado A
Stub A
Referencias Remotas
Referencias Remotas
invoke()
Creacin y destruccin
del objeto remoto
- Transitorio
Comunicacin sncrona
Comunicacin en grupo
Semntica de invocacin
- Exactamente una
- Como mucho, una
- Permanente
Transporte de Java
Transporte de Java
TCP/IP
TCP/IP
Sistema Operativo
Sistema Operativo
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 43
La Comunicacin - 43
Transporte de RMI
Arquitectura de RMI
Proceso Cliente
Proceso Servidor
del servicio A
Programa cliente
Estado A
Op. 1 Op. 2 Op. 3
Stub A
invoke()
Referencias Remotas
Referencias Remotas
Transporte de Java
(JRMP de Sun)
Transporte de Java
(JRMP de Sun)
Creacin y control
de canales de
comunicacin entre
procesos Java
Creacin y control
de canales de
comunicacin entre
procesos Java
Tabla de
Objetos
Remotos
TCP/IP
TCP/IP
Sistema Operativo
Sistema Operativo
Alternativa JRMP
Sistemas Distribuidos
Sistemas Distribuidos
IIOP
La Comunicacin - 44
La Comunicacin - 44
Servicio de Nombres
RMI de Java
Servicio de Nombres
RMI de Java
RMI Registry
Servicios
Nombre Ref.
Nombre Ref.
Nombre Ref.
Nombre Ref.
STUB
A
ALTAS
Proceso
Servidor
A
BAJAS
STUB
B
Proceso
Cliente
Proceso
Servidor
B
Una alternativa
Java Naming Directory Interface
(JNDI)
Sistemas Distribuidos
1099
RMI ofrece un servicio de nombres, conocido como RMI registry, para la localizacin de
servicios. Este servicio de nombres le ofrece al servidor operaciones tpicas como el dar
de alta un servicio o darlo de baja, mientras que al cliente le ofrece la localizacin de un
servicio.
La Comunicacin - 45
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 45
La Comunicacin - 45
RMI de Java
Un Ejemplo
Comunicacin cliente/servidor
1. Definir su interfaz
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 46
La Comunicacin - 46
El Servicio y la Clase
// Calculador.java
Construccin de la clase que implementa dicha interfaz.
de
la
clase
Construccin de la Clase
// CalculadorBasico.java
public class CalculadorBasico
implements Calculador{
public long div (long a, long b)
throws java.rmi.RemoteException{
return a/b;
}
}
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 47
La Comunicacin - 47
El Servidor
En la figura se muestra el cdigo del proceso servidor que va a crear un objeto del
servicio y lo va hacer visible al exterior.
En el paso 1, se crea el objeto que soportar el servicio a partir de la clase
CalculatorBasico.
// ServidorCalculos.java
import java.io.*;
import java.rmi.UnicastRemoteObject;
import java.rmi.registry.*;
import java.rmi.server.*;
public class ServidorCalculos{
public static void main(String args[]) {
try {
// 1. Se crea un objeto remoto
Calculador calc = new CalculadorBasico();
// 2. Se prepara el mecanismo para recibir peticiones
Calculador refStub =
(Calculador) UnicastRemoteObject.exportObject(calc);
// 3. Se localiza el registro de nombres
Registry r = LocateRegistry.getRegistry(localhost, 1099);
// 4. Se da de alta el servicio Calculator
r.rebind("rmi://localhost/ServicioCalculador", refStub);
Adems, este objeto debe ser capaz de recibir peticiones y enviar respuestas a los
clientes, por lo que, en el paso 2, el mtodo exportObject (de la clase
UnicastRemoteObject) asocia el objeto remoto calc al mecanismo de
comunicacin de RMI para poder recibir peticiones de clientes y devolverles el resultado.
Adems, la clase UnicastRemoteObject establece que el objeto remoto ser
transitorio, es decir, vivir, como mucho, hasta que el servidor muera o lo destruya. Si se
deseara que el objeto fuese permanente, esto es, que sobreviviera al servidor, entonces
se debera utilizar la clase
java.rmi.activation.Activatable
Una vez establecido el soporte de comunicacin, se va a hacer que el servicio sea
visible al exterior. Para ello, en el paso 3, se localiza el identificador de comunicacin
del servicio de nombres (rmiRegistry) de la mquina local, para dar de alta en el
servidor de nombres, en el paso 4, el servicio ServicioCalculador y el stub del
objeto remoto que lo soporta: refStub.
Sistemas Distribuidos
La Comunicacin - 48
La Comunicacin - 48
El Cliente
rmic CalculadorBasico
CalculadorBasico_stub.class
// ClienteDelCalculador.java
import java.rmi.Naming;
import java.rmi.RemoteException;
import java.net.MalformedURLException;
import java.rmi.NotBoundException;
public class ClienteDelCalculador {
public static void main(String[] args) {
try {
// 1. Se localiza el servicio
Calculador calc =(Calculador)Naming.lookup(
"rmi://host:1099/ServicioCalculador");
// 2. Se invocan los mtodos del servicio
System.out.println(calc.div(4,2));
System.out.println(calc.div(9,0));
}
//3. Se capturan las excepciones
catch (Exception e){
e.printStackTrace();
}
}
}
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 49
La Comunicacin - 49
Otra Alternativa
Por lo que hemos visto hasta ahora, la utilizacin del mecanismo RMI es bastante
similar a las RPC, aunque en la parte del cliente queda ms sencilla y transparente. Sin
embargo, la construccin del objeto remoto y el proceso servidor es bastante similar a la
de las RPC, no obstante, esto puede simplificarse significativamente. Veamos la
construccin alternativa que se presenta.
En esta alternativa, la definicin del interfaz permanece inalterado, como parece
razonable, pero para facilitar la creacin del objeto remoto en el proceso servidor sea
ms transparente vamos a modificar ligeramente la construccin de la clase que
implementa la interfaz. Para ello simplemente hay que heredar la clase
java.rmi.server.UnicastRemoteObject. Tambin debemos definir el mtodo
constructor de la clase, que recibe el mismo nombre que sta: CalculadorBasico, y
en l simplemente se llama al constructor de la clase que se hereda, es decir, de
java.rmi.server.UnicastRemoteObject. Este ltimo constructor llamar al su
mtodo export, consiguiendo el mismo efecto que cuando, en la versin anterior, en el
proceso se llamaba a UnicastRemoteObject.export despus de crear el objeto
remoto.
El constructor de una clase que lleva el mismo nombre que ella, se ejecuta
automticamente al crear objetos mediante new.
Construccin de la Clase
// CalculadorBasico.java
public class CalculadorBasico
extends java.rmi.server.UnicastRemoteObject
implements Calculador{
public long div (long a, long b)
throws java.rmi.RemoteException{
return a/b;
}
public CalculatorBasico ()
throws java.rmi.RemoteException{
super();
}
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 50
La Comunicacin - 50
Otra Alternativa
El Servidor
// ServidorCalculos.java
import java.io.*;
import java.rmi.UnicastRemoteObject;
import java.rmi.Naming;
public class ServidorCalculos{
public static void main(String args[]) {
try {
// 1 y 2. Se crea un objeto remoto
// y queda listo para recibir peticiones
Calculador calc = new CalculadorBasico();
Sistemas Distribuidos
La Comunicacin - 51
La Comunicacin - 51
Qu es CORBA?
CORBA
Qu es CORBA?
CORBA
Soportes de
programacin distribuida
CORBA
RMI
DCOM
El ms destacado es CORBA:
Sistemas Distribuidos
Sistemas Distribuidos
Sistemas Distribuidos
Hay otros modelos como DCOM de Microsoft o java RMI para realizar llamadas a
mtodos remotos. El grado de soporte de la distribucin es muy distinto en estos
modelos siendo CORBA, hoy por hoy, el soporte ms moderno de programacin
distribuida.
Se denomina middleware al conjunto de modelos que ofrecen un entorno de
programacin distribuida, sencillo, consistente e integrado que facilita las tareas de
diseo, programacin y gestin de aplicaciones distribuidas.
(Middleware)
RPCs
En esencia, el middleware es una capa de software que se coloca entre medias del
usuario y del entorno distribuido, abstrayendo al usuario de la complejidad y
heterogeneidad de las diferentes arquitecturas de las mquinas, protocolos de
comunicacin, sistemas operativos y lenguajes de programacin.
Hay diferentes tipos de middleware, pero el ms usual es el middleware orientado a
objetos, que facilita que el cliente haga llamadas a mtodos o procedimientos remotos
de manera transparente. El modelo CORBA cae dentro de este tipo.
La Comunicacin - 52
La Comunicacin - 52
La Comunicacin - 52
Qu es CORBA?
CORBA
Orientado a objetos
Portable
No todos los productos implementan todos los servicios del modelo y no todos son
iguales en rendimiento, ya que CORBA dice qu hacer pero no cmo hacerlo.
Reusable
Distribuido
Que funcione en
entornos heterogneos
Implementaciones gratis y de pago: Orbacus, ORBIX, Visibroker
El modelo de
Objetos
El modelo de
referencia
Describe qu es un
objeto CORBA
Indica la arquitectura
para que los objetos
CORBA puedan
relacionarse
Sistemas Distribuidos
CORBA se compone:
Sistemas Distribuidos
Qu es CORBA?
La Comunicacin - 53
La Comunicacin - 53
El Modelo de Objetos
CORBA
Un objeto CORBA en un entidad software que recoge un servicio compuesto por una o
ms operaciones, visibles al exterior, que permiten modificar el estado de dicho objeto.
Un objeto CORBA:
CLIENTE
ESQUELETO
DEL IDL
STUBS
DEL IDL
POA
ORB
Interfaz dependiente de la implementacin del ORB
Interfaz idntica en el lado del cliente y servidor
Interfaz idntica en todas las implementaciones de ORB
Sistemas Distribuidos
Una interfaz recoge el nombre del servicio y la firmas de cada procedimiento indicando
el nombre de la operacin, el conjunto de parmetros de entrada (in), de salida (out) o
de entrada/salida (inout), con sus respectivos tipos y el tipo del resultado de la
operacin. Tambin se pueden asociar excepciones de usuario o del sistema a cada una
de las operaciones.
Por defecto la comunicacin entre cliente y servidor es sncrona o bloqueante: Una vez
que el cliente realiza una peticin se bloquea en espera de la respuesta.
Sistemas Distribuidos
El ORB presenta dos tipos de interfaces: la interfaz pblica que figura en el modelo de
la OMG, y la privada que es la que generan los distintos fabricantes para hacer que se
conecten los stubs con el ORB.
La Comunicacin - 54
La Comunicacin - 54
El Modelo de Referencia
CORBA
El ORB ofrece una interfaz pblica que ofrece operaciones para envo y recepcin con
diferente calidad de servicio.
Interfaces de dominio
Facilidades comunes
Por ltimo, las aplicaciones del usuario forman el conjunto de objetos de aplicacin y
cuyo funcionamiento se basa en el uso del resto de los componentes del modelo
CORBA. Estos objetos son los nicos que no estn estandarizados por la OMG, pero si
ciertos objetos aparecen con frecuencia en diferentes aplicaciones pueden convertirse
en candidatos para que la OMG les incluya en alguna de las categoras anteriores.
Servicios de objetos:
facilidades de bajo nivel
Objetos de aplicacin:
aplicaciones del usuario
Todos los objetos antes descritos presentan una interfaz pblica, diseada por la OMG,
para permitir la interoperabilidad entre diferentes sistemas.
Facilidades comunes:
Facilidades de alto nivel
Interfaces de dominio:
interfaces especificas
Sistemas Distribuidos
La Comunicacin - 55
La Comunicacin - 55
Especificacin
/* NO ERROR */
/* ERROR */
/* Resultado de la divisin */
union resultado switch (divstat status) {
case DIV_OK:
Los errores del
int cociente;
default:
servidor se recogen
void;
en variables
};
struct enteros {
int dividendo;
int divisor;
};
Se admite slo:
Un parmetro de salida
Se especifica:
program MAT_PROGRAM {
version MAT_VERSION {
resultado DIVIDIR(enteros)=1; N de programa
}=1;
N de versin
}= 0x03000000;
Un parmetro de entrada
// Matematico.idl
En el caso de las RPC, nos encontramos con que el diseador debe asociar un nmero
de programa y de versin al servicio matemtico, as como numerar en orden
ascendente las operaciones que ofrece la interfaz. (Qu ocurrira si dos interfaces
distintos tuvieran el mismo nmero de programa y de versin?).
Se admite ms de un parmetro
de entrada y/o salida
raises(DivisionPorCero);
};
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 56
Especificacin
idl2... en entornos
.../CORBA
Java
C++
Smalltalk
Una vez definido el servicio, hay que someterlo al compilador de interfaces para generar
los stubs del cliente as como el cdigo de dispacthing del servidor.
En RPC, con el compilador rpcgen matemtico.x se generan los ficheros de stubs
en lenguaje C.
No vamos a enumerar la serie de ficheros que se crean porque depende del lenguaje de
programacin, por lo que solo iremos destacando aquellos ms representativos.
Ada
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 57
La Comunicacin - 57
El Cliente
Programacin de un cliente
Habitualmente, un cliente realiza las siguientes acciones:
1. Inicializacin del soporte de transmisin.
El Cliente
Adems, dentro de estas acciones, hay que controlar que no se produzcan errores, ya
sean de comunicacin o de ejecucin dentro del servidor.
Sistemas Distribuidos
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 58
La Comunicacin - 58
La Comunicacin - 58
El Cliente RPC
/* Cliente.c */
#include ...
1
/* 1. Se inicializa el soporte de transmisin */
/* 3. Se obtiene el id. Del servicio matemtico */
3
servidor =
clnt_create("quijote",MAT_PROGRAM,MAT_VERSION,"udp");
if (servidor == NULL) {{/* error de comunicacion */
clnt_pcreateerror("quijote");
exit(1);
}
/* Se obtienen los operandos */
oper.dividendo = atoi(argv[1]);
oper.divisor = atoi(argv[2]);
/* 4. Se invoca la operacin de divisin */
resul = dividir_1(&oper, servidor);
if (resul==NULL){/* error de comunicacion */
printf("fallo en comunicacin \n");
exit(-1);
}
5
/* 5. Se imprime el resultado */
printf("%i/%i = %i \n ",oper.dividendo, oper.divisor,
resul->resultado_u.cociente);
exit(0);
}
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 59
La Comunicacin - 59
El Cliente CORBA
// Client.java
import org.omg.CosNaming.*;
public class Client {
public static void main(String[] args) {
try{
1
// 1.Inicializacin del ORB
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args,null);
// 2.Se Obtiene el identificador del servicio de nombres 2
org.omg.CORBA.Object
rootObj = orb.resolve_initial_references("NameService");
NamingContextExt
root = NamingContextExtHelper.narrow(rootObj);
// 3.Se Obtiene el identificador del servicio matemtico
org.omg.CORBA.Object
mgrObj = root.resolve(root.to_name("MAT_PROGRAM"));
Matematico servidor = MatematicoHelper.narrow(mgrObj);
// 5. Se imprime el resultado
System.out.println(dividendo + "/ +divisor+" = "+ cociente);
}
// Se controlan las excepciones del servicio
catch (MatematicoPackage.DivisionPorCero e) {
e.printStackTrace();
}
5. Resultado.
Por ltimo, en este paso se muestra por la salida estndar el resultado de la divisin, si
todo hay ido bien.
}
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 60
La Comunicacin - 60
Gestin de errores de
transmisin y de
ejecucin en el servidor
Los problemas que pueden producirse son errores de ejecucin en el servidor (por
ejemplo divisin por cero) o errores en la comunicacin. Vamos a ver como se tratan:
En RPC los errores deben tratarse explcitamente ya que el lenguaje C no soporta
excepciones. En el cdigo del ejemplo, las cajas sombreadas recogen el control de
errores de transmisin para cada llamada remota.
La caja de lnea discontinua encierra el cdigo que controla el error de ejecucin
especificado en el servicio: la divisin por cero, preguntado por el status devuelto por el
servicio.
En CORBA, los errores de ejecucin se pueden controlar asocindolos a una excepcin,
supuesto que el lenguaje de programacin soporte excepciones. Cuando se intenta
dividir por cero, el servidor produce la excepcin DivisinPorCero, que el cliente
trata en el cdigo de la caja de lnea discontinua, imprimiendo el tipo de error que se ha
producido.
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 61
La Comunicacin - 61
Qu es un objeto CORBA?
NO !!
Un objeto CORBA es un
OBJETO VIRTUAL
Un objeto de un lenguaje
de programacin es real
En el modelo CORBA:
El cliente referencia
un objeto CORBA
Gestor de
ORB
memoria +
MMU
POA
TRANSPARENCIA DE ACCESO !!
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 62
La Comunicacin - 62
El Servidor RPC
El Servidor
El Servidor RPC
/* matematico_svc.c */
main()
{...
/* 1. Se crea un socket udp */
transp = svcudp_create(RPC_ANYSOCK);
/* 3. Se da de alta el servicio de nombres */
svc_register(transp, MAT_PROGRAM, MAT_VERSION,
mat_program_1, IPPROTO_UDP))
/* 4. Se cede el control al dispatcher mat_program_1 */
svc_run();
}
/* dispatcher mat_program_1 */
static void mat_program_1(rqstp, transp)
Hay que recordar que, previamente a la construccin del servidor, hay que someter el
fichero con la especificacin del servicio al compilador de interfaces, para as obtener los
ficheros con los perfiles de las operaciones y el dispatcher.
Un proceso servidor realiza habitualmente los siguientes pasos:
1. Inicializa el soporte de transmisin
2. Localiza el servidor de nombres
3. Da de alta el servicio en el servidor de nombres
4. Espera peticiones para ese servicio
5. Llama al procedimiento de divisin
6. Enva la respuesta al cliente
A continuacin vamos a ver cmo se realiza cada uno de estos pasos en RPC y
CORBA. En esta figura se muestra el servidor completo RPC y en la transparencia
siguiente se ofrece el de CORBA.
1. Inicializacin del soporte de transmisin
En el entorno RPC se crea un socket de tipo UDP para el envo y recepcin, mientras
que en el servidor CORBA simplemente se crea un bus virtual ORB.
2. Localizacin del servidor de nombres
En RPC, ya que no hay un servidor de nombres global, no hay que localizarlo, sino
que directamente hay que dirigirse al portmapper de la mquina en la que reside el
servicio deseado. El puerto por el que escucha el portmapper est prefijado y es el
111.
En CORBA, como el servidor de nombres es global y puede estar en cualquier
mquina (y puede escuchar por cualquier puerto) hay que localizarlo, cosa que se
hace solicitndoselo al ORB.
...
/* Se analiza la peticin */
switch (rqstp->rqproc) {...
case DIVIDIR:/* 5. Llamar al procedimiento de division */
break;
}
El cdigo que realiza las tres operaciones anteriores en el entorno RPC (excepto el paso
2, que en RPC no tiene sentido) es generado automticamente por el compilador de
interfaz (rpcgen), recogindose en la parte main del esqueleto matematico_svc.c.
Sin embargo, en CORBA estas tres operaciones se deben programar explcitamente.
...
/* 6. Se envia la respuesta al cliente */
Sistemas Distribuidos
La Comunicacin - 63
La Comunicacin - 63
El Servidor CORBA
// Server.java
import org.omg.PortableServer.*; import org.omg.CosNaming.*;
4. Espera de peticiones
En los entornos RPC es simple: cuando le llega la peticin de divisin al dispatcher, ste
llama al procedimiento dividir_1 que es el que realmente realiza la divisin.
En CORBA tambin es el dispatcher el encargado de llamar al procedimiento de
divisin cuando se recibe una peticin de tal operacin. Sin embargo, para que esa
peticin llegue al dispatcher el servidor tiene que realizar una serie de acciones antes de
ponerse a esperar a que lleguen peticiones. Vemoslas.
Cuando hablbamos del cliente CORBA decamos que en el exterior slo vea
objetos CORBA, es decir vea objetos virtuales.Tambin comentbamos que tras un
objeto virtual debe haber un objeto real en algn lenguaje concreto que lo soporte.
Pero quin y cmo se realiza esta asociacin?
El encargado de este trabajo es el servidor, que, en nuestro ejemplo en Java, debe
crear el objeto que soporta el procedimiento que realmente divide. (En la jerga de
CORBA, a este objeto se le denomina servant). Despus crear un objeto CORBA y,
por ltimo, tendr que asociar este objeto CORBA al objeto Java anterior. Despus
de esta asociacin, el objeto CORBA est listo para darlo de alta en el servidor de
nombres y hacerlo visible al exterior.
Todas estas tareas se enmarcan en un rectngulo sombreado en el cdigo del servidor
CORBA y no aparecen en el servidor de RPC porque son especficas de CORBA.
La asociacin entre un objeto CORBA y el objeto real que lo implementa se guarda en
un componente del sistema CORBA denominado Adaptador Portable de Objetos o
POA (Portable Object Adapter).
Pero todava nos queda contestar a la pregunta que tenamos pendiente al principio de
este punto:Cmo invoca el dispatcher el procedimiento de divisin?
// 4. Espera de peticiones
orb.run();
4
}
catch (Exception e) {
e.printStackTrace();
}
}
}
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 64
La Comunicacin - 64
/* dividir.c */
#include ...#
resultado *dividir_1(enteros *p1, struct svc_req *p2){
resultado *res;
res = (resultado *)malloc(sizeof(struct resultado));
if (p1->divisor == 0)
res->status = DIV_NOK;
else {
res->status = DIV_OK;
res->resultado_u.cociente=(p1->dividendo/p1->divisor);
}
return res;
}
Sistemas Distribuidos
Sistemas Distribuidos
La Comunicacin - 65
La Comunicacin - 65
Cada objeto tiene su propio dispatcher, pues el reparto dentro del dispacher tendr
diferentes opciones en nombre y nmero, dependiendo de los nombres y nmero de
mtodos que tenga un objeto.
Proceso
Cliente
Proceso
Servidor
Camino virtual
Objeto CORBA
Mtodo del
Servant
Servant
ObjetoCorba. Metodo( param);
dispatcher
En CORBA, por cada servicio hay un POA, y de cada servicio puede haber varios
objetos creados. Pues bien, cuando llega una peticin para uno de los objetos de un
servicio, es el POA de ese servicio el que sabe a cual de los objetos debe dirigirlo.
Y quin le entrega el mensaje al POA?
El bus ORB. Este bus entrega al POA una peticin sobre un objeto CORBA con los
datos en el formato local de esa mquina. A su vez, el bus ORB ha obtenido el
mensaje del modulo de comunicacin que haya por debajo, por ejemplo del sistema
operativo local.
6. Envo de la respuesta
Camino real
Envo de la respuesta:
Proceso
Cliente
POA
stub del
cliente
ORB del cliente
Proceso
Servidor
Camino virtual
Objeto CORBA
Servant
ObjetoCorba. Metodo( param);
Mtodo del
Servant
dispatcher
stub del
cliente
ORB del cliente
Sistemas Distribuidos
Sistemas Distribuidos
Camino real
La Comunicacin - 66
La Comunicacin - 66
Resumiendo
Resumiendo
- En RPC un servidor soporta un servicio
- En CORBA un servicio es un objeto CORBA
En CORBA es global
(portmapper)
(CosNaming
Identificador de comunicacin
El servicio
de nombres
En RPC es local
Service)
Por ltimo, diremos que la forma de llamar a los mtodos presenta transparencia de
acceso y de ubicacin ya que independientemente de que el mtodo pertenezca a un
objeto local o remoto se invoca de la misma manera:
Objeto.mtodo(parmetros)
Referencia de objeto
El soporte de
transmisin
En RPC no es transparente
(tcp, udp)
En CORBA es un bus
virtual ORB
Sistemas Distribuidos
La Comunicacin - 67
La Comunicacin - 67