Comunica C I Ones

Sistemas Operativos Distribuidos
Comunicacin de
Procesos en
Sistemas
Distribuidos
Fernando Prez Costoya
Jos Mara Pea Snchez
2
Comunicacin en Sistemas Distribuidos
Permite la interaccin entre aplicaciones y servicios del sistema.

Modelos de comunicacin entre procesos:
Memoria compartida (Slo uni/multiprocesador no distribuido).
Paso de mensajes.

El nivel de abstraccin en la comunicacin:
Paso de mensajes puro (Cliente-Servidor).
Llamadas a procedimientos remotos.
Modelos de objetos distribuidos.
Jos Mara Pea Snchez
3
Factores de Comunicacin
Los diferentes mecanismos de comunicacin se caracterizan por
los siguientes factores:
Rendimiento: Latencia, ratio de transferencia, ancho de banda, ...
Escalabilidad: Nmero de elementos activos.
Fiabilidad: Prdida de mensajes.
Seguridad:Cifrado, certificacin, ...
Movilidad: Equipos mviles.
Calidad de Servicio (QoS): Reserva y garanta de anchos de banda.
Comunicacin en grupo: Multicast.
Jos Mara Pea Snchez
4
Niveles de Comunicacin
TCP/UDP
Protocolo y
Representacin
RMI/RPC
App./Servicios
3) Llamadas a
procedimientos
remotos y objetos
distribuidos.
ATM/Ethernet
Interfaz
y
Lgica de
Comunicacin
App./Servicios
2) Funcionalidades de
comunicacin de bajo
nivel. Sistemas
Operativos Distribuidos.
TCP/UDP
API (sockets)
Aplicaciones
y
Servicios
1) Paso de
mensajes puro.
Aplicaciones en
red.
Jos Mara Pea Snchez
5
Primitivas de Comunicacin
Cada una de las funciones de comunicacin de una tecnologa
determinada. Las primitivas bsicas son:
Envo: send(destino,mensaje).
Recepcin: receive(fuente,mensaje).
Otras primitivas:
Conexin: connect(destino).
Desconexin: close().

Cada una de las primitivas tiene las siguientes caractersticas:
Boqueantes vs No-bloqueantes.
Sncronas vs Asncronas.
Fiables vs No-fiables.
Jos Mara Pea Snchez
6
Bloqueantes vs. No-bloqueantes
Las caractersticas de bloqueo son:
Primitivas bloqueantes: La operacin bloquea al elemento que la
solicita hasta que sta sea completada.
Primitivas no-bloqueantes: La operacin no detiene la ejecucin del
elemento que la solicita.

Las llamadas no bloqueantes tienen distinto sentido dependiendo
de la primitiva que se trate:
Envo no bloqueante: El emisor almacena el dato en un buffer del
ncleo (que se encarga de su transmisin) y reanuda su ejecucin.
Recepcin no bloqueante: Si hay un dato disponible el receptor lo
lee, en otro caso indica que no haba mensaje.

Jos Mara Pea Snchez
7
Snconas vs. Asncronas
Esta caracterstica afecta no tanto a la primitiva como a la
transmisin en s.
Comunicacin sncrona: Envo y recepcin se realizan de forma
simultanea.
Comunicacin asncrona: El envo no requiere que el receptor este
esperando.

La comunicacin asncrona usa un buffer de almacenamiento.
Implica ciertas condiciones de bloque en envo y recepcin.
Jos Mara Pea Snchez
8
Fiabilidad
El envo fiable de datos garantiza que un mensaje enviado ha
sido recibido por el receptor.
Implica la retransmisin de mensajes de validacin (ACKs).

La fiabilidad la puede garantizar:
El protocolo de comunicacin (TCP si y UDP no).
Los elementos emisor y receptor.

Jos Mara Pea Snchez
9
Primitivas de Comunicacin
EMISOR
Ncleo
Emisor
RED
RECEPTOR
Ncleo
Receptor
1
2
7
3
6
4
8 5
msg
ACK
Envo no bloqueante: [1:8] El emisor continua al pasar el mensaje al ncleo.
Envo bloqueante: [1:2:7:8] El emisor espera a que el ncleo transmita por red el
mensaje.
Envo bloqueante fiable: [1:2:3:6:7:8]: El emisor espera a que el ncleo receptor
recoge el mensaje.
Envo bloqueante explcito: [1:2:3:4:5:6:7:8]: Idem al anterior, pero es la
aplicacin receptora la que confirma la recepcin.
Peticin-Respuesta: [1:2:3:4:<servicio>:5:6:7:8]: El emisor espera a que el
receptor procese la operacin para reanudar la ejecucin.
Jos Mara Pea Snchez
10
Direccionamiento
Informacin vlida para la identificacin de elementos del
sistema. Posibles receptores de un mensaje.

Mecanismos:
Direccin dependiente de la localizacin:
Por ejemplo: direccin mquina + direccin puerto local.
No proporciona transparencia.
Direccin independiente de la localizacin (dir. lgica):
Facilita transparencia.
Necesidad de proceso de localizacin:
Mediante broadcast.
Uso de un servidor de localizacin que mantiene relaciones entre
direcciones lgicas y fsicas.
Uso de cache en clientes para evitar localizacin.
Jos Mara Pea Snchez
11
Comunicacin en Grupo
Se habilita por medio de:
Variantes de protocolos de red: IP-multicast.
Emulandola por medio de protocolos de alto nivel o por las
aplicaciones.

El direccionamiento se realiza por medio de una direccin de
grupo (grupo al que pertenecen todos los receptores).

Modelos de grupos:
Grupo abierto.
Grupo abierto controlado.
Grupo cerrado.
Jos Mara Pea Snchez
12
Comunicacin en Grupo
Utilidad para los sistemas distribuidos:
Ofrecer tolerancia a fallos basado en servicios replicados.
Localizar objetos en sistemas distribuidos.
Mejor rendimiento mediante datos replicados.
Actualizaciones mltiples.
Operaciones colectivas en clculo paralelo.

Problemtica:
Comunicacin fiable es difcil.
Escalabilidad de las tecnologas (Internet con MBone).
Gestin de grupos.
Encaminamiento (Flooding, Spanning Tree, RPB, TRPB, RPM).
Jos Mara Pea Snchez
13
Ordenacin en Comunicacin en Grupo
De acuerdo a las garantas de ofrecidas en la recepcin de
mensajes de grupo se tienen:
Ordenacin FIFO: Los mensajes de una fuente llegan a cada
receptor en el orden que son enviados.

Ordenacin Causal: Los mensajes enviados por dos emisores
distintos so recibidos en el orden relativo en el que se han enviado.

Ordenacin Total: Todos los mensajes (de varias fuentes) enviados
a un grupo son recibidos en el mismo orden por todos los elementos.
Cliente-Servidor
<Paso de Mensajes>
Berkeley Sockets
Java Sockets
Jos Mara Pea Snchez
15
Paso de Mensajes
Los modelos de comunicacin basados en cliente-servidor con
paso de mensajes responden al esqueleto:
CLIENTE
msg
Send(msg) Send(msg)
msg
SERVIDOR
msg
Receive(msg)
Mensaje msg,reply;
msg=<dato a trasmitir>
send(msg);
receive(reply);
if(isOK(reply))
<operacin correcto>
else
<error en operacin>
...
Mensaje op,ack;
receive(op);
if(validOp(op))
ack=<operacin OK>
else
ack=<operacin ERROR>
send(ack);
...
Jos Mara Pea Snchez
16
Paso de Mensajes
Cada pareja send-receive transmite un mensaje entre
cliente y servidor. Por lo general de forma asncrona.
Habitualmente:
Send no bloqueante.
Receive bloqueante (pude hacerse no bloqueante).

Los mensajes intercambiados pueden ser:
Mensajes de texto (por ejemplo: HTTP).
Mensajes con formato (binarios).

Las aplicaciones definen el protocolo de comunicacin: Peticin-
respuesta, recepcin explcita, sin/con confirmacin, ...
Jos Mara Pea Snchez
17
Mensajes Texto
Estructura del Mensaje:
Cadenas de caracteres.
Por ejemplo HTTP:
GET //www.fi.upm.es HTTP/1.1

Envo del Mensaje:
send(GET //www.fi.upm.es HTTP/1.1);

El emisor debe hacer un anlisis de la cadena de caracteres
transmitida.

Jos Mara Pea Snchez
18
Mensajes Binarios
Estructura del Mensaje:
struct mensaje_st
{
unsigned int msg_tipo;
unsigned int msg_seq_id;
unsigned char msg_data[1024];
};
Envo del Mensaje:
struct mensaje_st confirm;
confirm.msg_tipo=MSG_ACK;
confirm.msg_seq_id=129;

send(confirm);
Jos Mara Pea Snchez
19
Formatos de Representacin
Para la transmisin de formatos binarios tanto emisor y receptor
deben coincidir en la interpretacin de los bytes transmitidos.
Problemtica:
Tamao de los datos numricos.
Ordenacin de bytes.
Formatos de texto: ASCII vs EBCDIC.
Arquitectura
little-endian
Dato a enviar: 5
0 0 0 5
Valor: 0x2
24
+0x2
16
+0x2
8
+5
Arquitectura
big-endian
Dato a recibido: 83.886.080
0 0 0 5
Valor: 5x2
24
+0x2
16
+0x2
8
+0
0 0 0 5
0 1 2 3
3 2 1 0
Jos Mara Pea Snchez
20
Berkeley Sockets
Aparecieron en 1981 en UNIX BSD 4.2
Intento de incluir TCP/IP en UNIX.
Diseo independiente del protocolo de comunicacin.
Un socket es punto final de comunicacin (direccin IP y
puerto).

Abstraccin que:
Ofrece interfaz de acceso a los servicios de red en el nivel de
transporte.
Representa un extremo de una comunicacin bidireccional con
una direccin asociada.
Jos Mara Pea Snchez
21
Berkeley Sockets
Sujetos a proceso de estandarizacin dentro de POSIX (POSIX
1003.1g).

Actualmente:
Disponibles en casi todos los sistemas UNIX.
En prcticamente todos los sistemas operativos:
WinSock: API de sockets de Windows.
En Java como clase nativa.

Jos Mara Pea Snchez
22
Conceptos Bsicos sobre Sockets
Dominios de comunicacin.
Tipos de sockets.
Direcciones de sockets.
Creacin de un socket.
Asignacin de direcciones.
Solicitud de conexin.
Preparar para aceptar conexiones.
Aceptar una conexin.
Transferencia de datos.

1.- Creacin del socket
2.- Asignacin de direccin
3.- Aceptacin de conexin
Jos Mara Pea Snchez
23
Dominios de Comunicacin
Un dominio representa una familia de protocolos.
Un socket est asociado a un dominio desde su creacin.
Slo se pueden comunicar sockets del mismo dominio.
Los servicios de sockets son independientes del dominio.

Algunos ejemplos:
PF_UNIX (o PF_LOCAL): comunicacin dentro de una mquina.
PF_INET: comunicacin usando protocolos TCP/IP.
Jos Mara Pea Snchez
24
Tipos de Sockets
Stream (SOCK_STREAM):
Orientado a conexin.
Fiable, se asegura el orden de entrega de mensajes.
No mantiene separacin entre mensajes.
Si PF_INET se corresponde con el protocolo TCP.
Datagrama (SOCK_DGRAM):
Sin conexin.
No fiable, no se asegura el orden en la entrega.
Mantiene la separacin entre mensajes.
Si PF_INET se corresponde con el protocolo UDP.
Raw (SOCK_RAW):
Permite el acceso a los protocolos internos como IP.
Jos Mara Pea Snchez
25
Direcciones de Sockets
Cada socket debe tener asignada una direccin nica.
Dependientes del dominio.
Las direcciones se usan para:
Asignar una direccin local a un socket (bind).
Especificar una direccin remota (connect o sendto).

Se utiliza la estructura genrica de direccin:
struct sockaddr mi_dir;
Cada dominio usa una estructura especfica.
Uso de cast en las llamadas.
Direcciones en PF_INET (struct sockaddr_in).
Direcciones en PF_UNIX (struct sockaddr_un).
Jos Mara Pea Snchez
26
Direcciones de Sockets en PF_INET
Una direccin destino viene determinada por:
Direccin del host: 32 bits.
Puerto de servicio: 16 bits.
Estructura struct sockaddr_in:
Debe iniciarse a 0 (bzero).
sin_family: dominio (AF_INET).
sin_port: puerto.
sin_addr: direccin del host.
Una transmisin est caracterizada por cinco parmetros nicos:
Direccin host y puerto origen.
Direccin host y puerto destino.
Protocolo de transporte (UDP o TCP).
Jos Mara Pea Snchez
27
Obtencin de la Direccin del Host
Usuarios manejan direcciones en forma de texto:
decimal-punto: 138.100.8.100
dominio-punto: laurel.datsi.fi.upm.es

Conversin a binario desde decimal-punto:
int inet_aton(char *str,struct in_addr *dir)
str: contiene la cadena a convertir.
dir: resultado de la conversin en formato de red.
Conversin a binario desde dominio-punto:
struct hostent *gethostbyname(char *str)
str: cadena a convertir.
Devuelve la estructura que describe al host.

Jos Mara Pea Snchez
28
Creacin de un Socket
La funcin socket crea uno nuevo:
int socket(int dom,int tipo,int proto)
Devuelve un descriptor de fichero (igual que un open de fichero).
Dominio (dom): PF_XXX
Tipo de socket (tipo): SOCK_XXX
Protocolo (proto): Dependiente del dominio y del tipo:
0 elige el ms adecuado.
Especificados en /etc/protocols.

El socket creado no tiene direccin asignada.
Jos Mara Pea Snchez
29
Asignacin de Direcciones
La asignacin de una direccin a un socket ya creado:
int bind(int s,struct sockaddr* dir,int tam)
Socket (s): Ya debe estar creado.
Direccin a asignar (dir): Estructura dependiendo del dominio.
Tamao de la direccin (tam): sizeof().

Si no se asigna direccin (tpico en clientes) se le asigna
automticamente (puerto efmero) en la su primera utilizacin
(connect o sendto).
Jos Mara Pea Snchez
30
Asignacin de Direcciones (PF_INET)
Direcciones en dominio PF_INET
Puertos en rango 0..65535.
Reservados: 0..1023.
Si se le indica el 0, el sistema elige uno.
Host: una direccin IP de la mquina local.
INADDR_ANY: elige cualquiera de la mquina.
Si el puerto solicitado est ya asignado la funcin bind
devuelve un valor negativo.

El espacio de puertos para streams (TCP) y datagramas (UDP)
es independiente.

Jos Mara Pea Snchez
31
Solicitud de Conexin
Realizada en el cliente por medio de la funcin:
int connect(int s,struct sockaddr* d,int tam)
Socket creado (s).
Direccin del servidor (d).
Tamao de la direccin (tam).

Si el cliente no ha asignado direccin al socket, se le asigna una
automticamente.

Normalmente se usa con streams.
Jos Mara Pea Snchez
32
Preparar para Aceptar Conexiones
Realizada en el servidor stream despus de haber creado
(socket) y reservado direccin (bind) para el socket:
int listen(int sd, int baklog)
Socket (sd): Descriptor de uso del socket.
Tamao del buffer (backlog): Nmero mximo de peticiones
pendientes de aceptar que se encolarn (algunos manuales
recomiendan 5)

Hace que el socket quede preparado para aceptar conexiones.
Jos Mara Pea Snchez
33
Aceptar una Conexin
Realizada en el servidor stream despus de haber preparado la
conexin (listen):
int accept(int s,struct sockaddr *d,int *tam)
Socket (sd): Descriptor de uso del socket.
Direccin del cliente (d): Direccin del socket del cliente devuelta.
Tamao de la direccin (tam): Parmetor valor-resultado
Antes de la llamada: tamao de dir
Despus de la llamada: tamao de la direccin del cliente que se
devuelve.
Jos Mara Pea Snchez
34
Aceptar una Conexin
La semntica de la funcin accept es la siguiente:
Cuando se produce la conexin, el servidor obtiene:
La direccin del socket del cliente.
Un nuevo descriptor (socket) que queda conectado al socket del
cliente.
Despus de la conexin quedan activos dos sockets en el
servidor:
El original para aceptar nuevas conexiones
El nuevo para enviar/recibir datos por la conexin establecida.
Idealmente se pueden plantear servidores multithread para
servicio concurrente.
Jos Mara Pea Snchez
35
Otras Funcionalidades
Obtener la direccin a partir de un descriptor:
Direccin local: getsockname().
Direccin del socket en el otro extremo: getpeername().
Transformacin de valores:
De formato host a red:
Enteros largos: htonl().
Enteros cortos: htons().
De formato de red a host:
Enteros largos: ntohl().
Enteros cortos: ntohs().
Cerrar la conexin:
Para cerrar ambos tipos de sockets: close().
Si el socket es de tipo stream cierra la conexin en ambos sentidos.
Para cerrar un nico extremo: shutdown().
Jos Mara Pea Snchez
36
Transferencia de Datos con Streams
Envo:
Puede usarse la llamada write sobre el descriptor de socket.
int send(int s,char *mem,int tam,int flags)
Devuelve el n de bytes enviados.
Recepcin:
Puede usarse la llamada read sobre el descriptor de socket.
int recv(int s,char *mem,int tam,int flags)
Devuelve el n de bytes recibidos.

Los flags implican aspectos avanzado como enviar o recibir
datos urgentes (out-of-band).
Jos Mara Pea Snchez
37
Escenario de Uso de Sockets streams
Proceso cliente
Proceso servidor
socket()
socket()
bind()
listen()
accept()
Posible
Ejecucin
en Paralelo
accept()
connect()
Abrir conexin
close()
Peticin
send()/write()
Respuesta
close()
recv()/read()
send()/write() recv()/read()
Jos Mara Pea Snchez
38
Transferencia de Datos con Datagramas
Envo:
int sendto(int s,char *mem,int tam,
int flags,struct sockaddr *dir,
int *tam)
Recepcin:
int recvfrom(int s,char *mem,int tam,
int flags,struct sockaddr *dir,
int *tam)
No se establece una conexin (connect/accept) previa.
Para usar un socket para transferir basta con crear el socket y
reservar la direccin (bind).
Jos Mara Pea Snchez
39
Escenario de Uso de Sockets Datagrama
Proceso
socket()
bind()
close()
Peticin
sendto()
Respuesta
recvfrom()
Proceso
socket()
bind()
close()
recvfrom()
sendto()
Jos Mara Pea Snchez
40
Configuracin de Opciones
Existen varios niveles dependiendo del protocolo afectado como
parmetro:
SOL_SOCKET: opciones independientes del protocolo.
IPPROTO_TCP: nivel de protocolo TCP.
IPPTOTO_IP: nivel de protocolo IP.

Consultar opciones asociadas a un socket: getsockopt()
Modificar opciones asociadas a un socket: setsockopt()
Ejemplos (nivel SOL_SOCKET):
SO_REUSEADDR: permite reutilizar direcciones
Jos Mara Pea Snchez
41
Sockets en Java
Engloba en objetos cada una de las estructuras de la
comunicacin. Las funciones se tratan como mtodos de
dichos objetos:
InetAddress
Socket DatagramSocket ServerSocket
Connection
DatagramPacket

Define un nivel de abstraccin mayor, proporcionando
constructores que realizan parte del proceso de inicializacin
de los elementos.
Jos Mara Pea Snchez
42
Sockets en Java (Direccionamiento)
Las direcciones de Internet se asocian a objetos de la clase
InetAddress. Estos objetos se construyen en base a
mtodos estticos de la clase:

static InetAddress getByName(String host)
Obtiene una direccin IP en base al nombre (dominios o nmeros).
static InetAddress getLocalHost()
Obtiene la direccin IP local.

Jos Mara Pea Snchez
43
Sockets en Java (UDP)
La informacin a trasmitir se asocia a un objetos de la clase
DatagramPacket. Estos objetos se construyen con un array
de bytes a transmitir:

DatagramPacket(byte[] datos, int tam)
Crea un datagrama para el vector de bytes a transmitir.

Adicionalmente se le puede pasar una direccin IP
(InetAddress) y un puerto para indicar el destino de
transmisin del paquete cuando se enve.
Jos Mara Pea Snchez
44
Sockets en Java (UDP)
La comunicacin va UDP se realiza por medio de objetos de la
clase DatagramSocket.
DatagramSocket(int puerto,InetAddress dir)
Crea un socket UDP con un bind a la direccin y puerto indicados.
Direccin y puerto son opcionales (se elige uno libre).
void send(DatagramPacket paquete)
Enva el datagrama a la direccin del paquete.
void receive(DatagramPacket paquete)
Se bloquea hasta la recepcin del datagrama.
Otros mtodos:
void close(): Cierra el socket.
void setSoTimeout(int timeout): Define el tiempo
de bloqueo en un receive().
Jos Mara Pea Snchez
45
Sockets en Java (TCP)
Se utilizan dos clases de socket (una para el cliente y otra para
socket servidor).
Para el cliente:
Socket(InetAddress dir, int puerto)
Crea un socket stream para el cliente conectado con la direccin y puerto
indicados. Existen otros constructores con diferentes argumentos.
Para el servidor:
ServerSocket(int puerto)
Crea un socket stream para el servidor. Existen otros constructores con
diferentes argumentos.
Socket accept()
Prepara la conexin y se bloquea a espera de conexiones. Equivale a
listen y accept de BSD Sockets. Devuelve un Socket.
Jos Mara Pea Snchez
46
Sockets en Java (TCP)
La lectura y la escritura sobre sockets TCP se realiza por medio
de objetos derivados de las clases de Stream (en concreto
subclases de InputStream y OutputStream).
InputStream getInputStream()
Obtiene el stream de lectura.
OutputStream getOutputStream()
Obtiene el stream de escritura.

Los objetos devueltos son transformados a la subclase apropiada
para manejarlo (por ejemplo DataInputStream).
Jos Mara Pea Snchez
47
Sockets en Java
Para la confeccin de diferentes protocolos o variantes de los
mismos Java proporciona un interfaz denominado
SocketImplFactory.
SocketImpl createSocketImpl()
Crea una instancia de la superclase de sockets.

SocketImpl es la superclase de todos las implementaciones
de sockets. Un objeto de esta clase es usado como argumento
para la creacin de sockets.

Llamadas a
Procedimientos
Remotos
<RPC>
Sun RPCs
Jos Mara Pea Snchez
49
Llamadas a Procedimientos Remotos
...
send(msg)
...
receive(rpy)
...
receive(msg)
...
send(rpy)
Paso de mensajes (visin de bajo nivel)
...
...
x=buscar(1556)
...
int buscar(int cod)
{
...
...
return val;
}
Llamadas a procedimientos remotos (ms alto nivel) Comodidad
C
l
i
e
n
t
e

C
l
i
e
n
t
e

S
e
r
v
i
d
o
r

S
e
r
v
i
d
o
r

msg
rpy
Jos Mara Pea Snchez
50
Llamadas a Procedimientos Remotos
Remote Procedure Call: RPC.

Evolucin:
Propuesto por Birrel y Nelson en 1985.
Sun RPC es la base para varios servicios actuales (NFS o NIS).
Llegaron a su culminacin en 1990 con DCE (Distributed Computing
Environment) de OSF.
Han evolucionado hacia orientacin a objetos: invocacin de mtodos
remotos (CORBA, RMI).

Jos Mara Pea Snchez
51
Funcionamiento General de RPC
Cliente:
El proceso que realiza una la llamada a una funcin.
Dicha llamada empaqueta los argumentos en un mensaje y se los
enva a otro proceso.
Queda la espera del resultado.
Servidor:
Se recibe un mensaje consistente en varios argumentos.
Los argumentos son usados para llamar una funcin en el servidor.
El resultado de la funcin se empaqueta en un mensaje que se
retransmite al cliente.

Objetivo: acercar la semntica de las llamadas a procedimiento
convencional a un entorno distribuido (transparencia).
Jos Mara Pea Snchez
52
Elementos Necesarios
Cdigo cliente.
Cdigo del servidor.
Formato de representacin.
Definicin del interfaz.
Localizacin del servidor.
Semnticas de fallo.
...
...
x=buscar(1556)
...
int buscar(int cod)
{
...
...
return val;
}
C
l
i
e
n
t
e

S
e
r
v
i
d
o
r

Jos Mara Pea Snchez
53
Cdigo Cliente/Cdigo Servidor
Las funciones de abstraccin de una llamada RPC a intercambio de
mensajes se denominan resguardos (stubs).
SISTEMA CLIENTE
CDIGO DE LA APLICACIN
PREPARA
ENTRADA
CONVIERTE
SALIDA
INICIO
LLAMADA
FIN
LLAMADA
BIBLIOT.
EJECUCIN
RPC
ENVA
ENTRADA
RECIBE
SALIDA
RESGUARDO
CLIENTE
1
2
8
9
5
3
PROCEDIMIENTOS
EJECUTA
PROCEDIMIENTO
REMOTO
SISTEMA SERVIDOR
RECIBE
Y PASA
RESGUARDO
SERVIDOR
PREPARA
SALIDA
TRANSMITE
SALIDA
CONVIERTE
ENTRADA
BIBLIOT.
EJECUCIN
RPC
4
6
7
Jos Mara Pea Snchez
54
Resguardos (stubs)
Se generan automticamente por el software de RPC en base a
la interfaz del servicio.
Son independientes de la implementacin que se haga del cliente y
del servidor. Slo dependen de la interfaz.
Tareas que realizan:
Localizan al servidor.
Empaquetan los parmetros y construyen los mensajes.
Envan el mensaje al servidor.
Espera la recepcin del mensaje y devuelven los resultados.

Se basan en una librera de funciones RPC para las tareas ms
habituales.
Jos Mara Pea Snchez
55
Formato de Representacin
Una de las funciones de los resguardos es empaquetar los
parmetros en un mensaje: aplanamiento (marshalling).

Problemas en la representacin de los datos
Servidor y cliente pueden ejecutar en mquinas con arquitecturas
distintas.
XDR (external data representation) es un estndar que define la
representacin de tipos de datos.
Pasos de parmetros (entrada/salida):
Problemas con los punteros: Una direccin slo tiene sentido en un
espacio de direcciones.
Jos Mara Pea Snchez
56
Definicin de Interfaces: IDL
IDL (Interface Definition Language) es un lenguaje de
representacin de interfaces:
Hay muchas variantes de IDL:
Integrado con un lenguaje de programacin (Cedar, Argus).
Especfico para describir las interfaces (RPC de Sun y RPC de DCE).
Define procedimientos y argumentos (No la implementacin).
Se usa habitualmente para generar de forma automtica los
resguardos (stubs).
Server ServidorTickets
{
procedure void reset();
procedure int getTicket(in string ident);
procedure bool isValid(in int ticket);
}
Jos Mara Pea Snchez
57
Localizacin del Servidor
La comunicacin de bajo nivel entre cliente y servidor por medio
de paso de mensajes (por ejemplo sockets). Esto requiere:
Localizar la direccin del servidor: tanto direccin IP como nmero de
puerto en el caso de sockets.
Enlazar con dicho servidor (verificar si esta sirviendo).

Estas tareas las realiza el resguardo cliente.
En el caso de servicios cuya localizacin no es estndar se
recurre al enlace dinmico (dynamic binding).
Jos Mara Pea Snchez
58
Enlace Dinmico
Enlace dinmico: permite localizar objetos con nombre en un
sistema distribuido, en concreto, servidores que ejecutan las
RPC.

Tipos de enlace:
Enlace no persistente: la conexin entre el cliente y el servidor se
establece en cada llamada RPC.
Enlace persistente: la conexin se mantiene despus de la primera
RPC:
til en aplicaciones con muchas RPC repetidas.
Problemas si lo servidores cambian de lugar o fallan.
Jos Mara Pea Snchez
59
Enlazador Dinmico
Enlazador dinmico (binder): Es el servicio que mantiene una
tabla de traducciones entre nombres de servicio y direcciones.
Incluye funciones para:
Registrar un nombre de servicio (versin).
Eliminar un nombre de servicio.
Buscar la direccin correspondiente a un nombre de servicio.

Como localizar al enlazador dinmico:
Ejecuta en una direccin fija de un computador fijo.
El sistema operativo se encarga de indicar su direccin.
Difundiendo un mensaje (broadcast) cuando los procesos comienzan
su ejecucin.

Jos Mara Pea Snchez
60
RPC: Protocolo Bsico
cliente servidor

Desempaqueta
la respuesta
Se registra con un
servicio de nombres

recibe peticin
Ejecuta el
procedimiento
enva peticin
enlaza con
el servidor

prepara
parmetros,
enva peticin
Jos Mara Pea Snchez
61
Semntica Fallos
Problemas que pueden plantear las RPC:
El cliente no es capaz de localizar al servidor. [1]
Se pierde el mensaje de peticin del cliente al servidor. [2]
Se pierde el mensaje de respuesta del servidor al cliente. [3]
El servidor falla despus de recibir una peticin. [4]
El cliente falla despus de enviar una peticin. [5]
?
[1]
[2]
[4]
[5]
Jos Mara Pea Snchez
62
Cliente no Puede Localizar al Servidor
El servidor puede estar cado
El cliente puede estar usando una versin antigua del servidor
La versin ayuda a detectar accesos a copias obsoletas
Cmo indicar el error al cliente
Devolviendo un cdigo de error (-1)
No es transparente
Ejemplo: sumar(a,b)
Elevando una excepcin
Necesita un lenguaje que tenga excepciones

Jos Mara Pea Snchez
63
Prdida de Mensajes del Cliente
Es la ms fcil de tratar.
Se activa una alarma (timeout) despus de enviar el mensaje.
Si no se recibe una respuesta se retransmite.
Depende del protocolo de comunicacin subyacente.
Jos Mara Pea Snchez
64
Prdidas de Mensajes de Respuesta
Ms difcil de tratar
Se pueden emplear alarmas y retransmisiones, pero:
Se perdi la peticin?
Se perdi la respuesta?
El servidor va lento?
Algunas operaciones pueden repetirse sin problemas
(operaciones idempotentes)
Una transferencia bancaria no es idempotente
Solucin con operaciones no idempotentes es descartar
peticiones ya ejecutadas
Un n de secuencia en el cliente
Un campo en el mensaje que indique si es una peticin original o una
retransmisin

Jos Mara Pea Snchez
65
Fallos en los Servidores
El servidor no ha llegado a ejecutar la operacin
Se podra retransmitir
El servidor ha llegado a ejecutar la operacin
El cliente no puede distinguir los dos
Qu hacer?
No garantizar nada
Semntica al menos una vez
Reintentar y garantizar que la RPC se realiza al menos una vez
No vale para operaciones no idempotentes
Semntica a lo ms una vez
No reintentar, puede que no se realice ni una sola vez
Semntica de exactamente una
Sera lo deseable

Jos Mara Pea Snchez
66
Fallos en los Clientes
La computacin est activa pero ningn cliente espera los
resultados (computacin hurfana)
Gasto de ciclos de CPU
Si cliente rearranca y ejecuta de nuevo la RPC se pueden crear
confusiones

Jos Mara Pea Snchez
67
Aspectos de Implementacin
Protocolos RPC
Orientados a conexin
Fiabilidad se resuelve a bajo nivel, peor rendimiento
No orientados a conexin
Uso de un protocolo estndar o un especfico
Algunos utilizan TCP o UDP como protocolos bsicos
Coste de copiar informacin aspecto dominante en
rendimiento:
buffer del cliente buffer del SO local red buffer del SO
remoto + buffer del servidor
Puede haber ms copias en cliente para aadir cabeceras
scatter-gather: puede mejorar rendimiento
Jos Mara Pea Snchez
68
RPC de Sun
Utiliza como lenguaje de definicin de interfaz IDL:
Una interfaz contiene un n de programa y un n de versin.
Cada procedimiento especfica un nombre y un n de procedimiento
Los procedimientos slo aceptan un parmetro.
Los parmetros de salida se devuelven mediante un nico resultado
El lenguaje ofrece una notacin para definir:
constantes
definicin de tipos
estructuras, uniones
programas

Jos Mara Pea Snchez
69
RPC de Sun
rpcgen es el compilador de interfaces que genera:
Resguardo del cliente
Resguardo del servidor y procedimiento principal del servidor.
Procedimientos para el aplanamiento (marshalling)
Fichero de cabecera (.h) con los tipos y declaracin de prototipos.
Enlace dinmico
El cliente debe especificar el host donde ejecuta el servidor
El servidor se registra (n de programa, n de versin y n de
puerto) en el port mapper local
El cliente enva una peticin al port mapper del host donde ejecuta
el servidor
Jos Mara Pea Snchez
70
Ejemplo de Fichero IDL (Sun RPC)
struct peticion {
int a;
int b;
};

program SUMAR {
version SUMAVER {
int SUMA(peticion) = 1;
} = 1;
} = 99;

Jos Mara Pea Snchez
71
Programacin con un Paquete de RPC
El programador debe proporcionar:
La definicin de la interfaz (fichero idl)
Nombres de las funciones
Parmetros que el cliente pasa al servidor
Resultados que devuelve el servidor al cliente
El cdigo del cliente
El cdigo del servidor
El compilador de idl proporciona:
El resguardo del cliente
El resguardo del servidor
Jos Mara Pea Snchez
72
Programacin con RPC
COMPILADOR C COMPILADOR C
COMPILADOR C COMPILADOR C
CABECERA CABECERA
FICHEROS
FUENTE DEL
CLIENTE
FICHEROS
OBJETO DEL
CLIENTE
FICHEROS
OBJETO DEL
SERVIDOR
EJECUTABLE
DEL
CLIENTE
EJECUTABLE
DEL
SERVIDOR
FICHEROS
FUENTE DEL
SERVIDOR
OBJETO
RESGUARDO
EN CLIENTE
OBJETO
RESGUARDO
EN SERVIDOR
MONTADOR MONTADOR
BIBLIOT.
RPC
BIBLIOT.
RPC
DESARROLLO
DE LA
INTERFAZ
DESARROLLO
DEL
CLIENTE
DESARROLLO
DEL
SERVIDOR
COMPILADOR IDL
RESGUARDO
EN SERVIDOR
RESGUARDO
EN CLIENTE
CABECERA
FICHERO
DE DEFINICIN
DE INTERFAZ
Jos Mara Pea Snchez
73
idl.x
repcgen
idl_svc.c
servidor.c
idl.h
idl_xdr.c
idl_clnt.c
cliente.c
Archivos para
el cliente
Archivos
comunes
Archivos para
el servidor
Esquema de una Aplicacin
Entornos de
Objetos
Distribuidos
<Objetos Remotos>
Java RMI
CORBA
Jos Mara Pea Snchez
75
Motivacin
La extensin de los mecanismos de RPC a una programacin
orientada a objetos dio lugar a los modelos de objetos
distribuidos.

Ventajas:
Los mtodos remotos estn asociados a objetos remotos.
Ms natural para desarrollo orientado a objetos.
Admite modelos de programacin orientada a eventos.

Problemas:
El concepto de referencia a objeto es fundamental.
Objetos voltiles y objetos persistentes.
Jos Mara Pea Snchez
76
Objetos-Distribuidos
Caractersticas:
Uso de un Middleware: Nivel de abstraccin para la comunicacin de
los objetos distribuidos. Oculta:
Localizacin de objetos.
Protocolos de comunicacin.
Hardware de computadora.
Sistemas Operativos.
Modelo de objetos distribuidos: Describe los aspectos del paradigma
de objetos que es aceptado por la tecnologa: Herencia, Interfaces,
Excepciones, Polimorfismo, ...
Recogida de basura (Garbage Collection): Determina los objetos que
no estn siendo usados para a liberar recursos.

Jos Mara Pea Snchez
77
Tecnologas de Objetos Distribuidos
Actualmente existen tres tecnologas de desarrollo de sistemas
distribuidos basados en objetos:
ANSA (1989-1991) fue el primer proyecto que intent desarrollar una
tecnologa para modelizar sistemas distribuidos complejos con
objetos.
DCOM de Microsoft.
CORBA de OMG.
Tecnologas Java de Sun Microsytems:
Remote Method Invocation (RMI).
Enterprise Java Beans (EJB).
Jini.
Diferentes entornos de trabajo propietarios.
Jos Mara Pea Snchez
78
Java RMI
El soporte para RMI en Java est basado en las interfaces y
clases definidas en los paquetes:
java.rmi
java.rmi.server

Caractersticas de Java RMI:
Los argumentos y resultados se pasan mediante RMI por valor (nunca por
referencia).
Un objeto remoto se pasa por referencia.
Es necesario tratar mayor nmero de excepciones que en el caso de invocacin de
mtodos locales.

Jos Mara Pea Snchez
79
Java RMI
Localizacin de objetos remotos:
Servidor de nombres: java.rmi.Naming

Ejemplo:
Cuenta cnt = new CuentaImpl();
String url = rmi://java.Sun.COM/cuenta;
// enlazamos una url a un objeto remoto
java.rmi.Naming.bind(url, cnt);
....
// bsqueda de la cuenta
cnt=(Cuenta)java.rmi.Naming.lookup(url);
Jos Mara Pea Snchez
80
Arquitectura de Java RMI
Jos Mara Pea Snchez
81
Arquitectura de Java RMI
Nivel de transporte: se encarga de las comunicaciones y de
establecer las conexiones necesarias
Nivel de gestin de referencias remotas: trata los aspectos
relacionados con el comportamiento esperado de las
referencias remotas (mecanismos de recuperacin, etc.)
Nivel de resguardo/esqueleto (proxy/skeleton) que se
encarga del aplanamiento (serializacin) de los parmetros
proxy: resguardo local. Cuando un cliente realiza una invocacin
remota, en realidad hace una invocacin de un mtodo del resguardo
local.
Esqueleto (skeleton): recibe las peticiones de los clientes, realiza la
invocacin del mtodo y devuelve los resultados.
Jos Mara Pea Snchez
82
Desarrollo de Aplicaciones RMI
Definicin de la
interfaz remota
javac
(.java)
1
2
3
4
10
9
5
6
7
8
(.java)
usa
Cliente
Ejectuar
Cliente
(.class)
CLIENTE
SERVIDOR
(.class)
Esqueleto
(.class)
Implementacin de la
interfaz remota
Esqueleto
(.class)
Servidor
(.class)
Arrancar RMIRegistry
Crear los objetos
Registrar los objetos
javac
rmic
Jos Mara Pea Snchez
83
Registro de Objetos
Cualquier programa que quiera instanciar un objeto de esta clase
debe realizar el registro con el servicio de nombrado de la
siguiente forma:

Cuenta mi_cuenta=
(Cuenta)Naming.lookup("rmi://"+host+"/"+MiCuenta");

Antes de arrancar el cliente y el servidor, se debe arrancar el
programa rmiregistry en el servidor para el servicio de nombres
Jos Mara Pea Snchez
84
OMG
(Object Management Group)

Conjunto de organizaciones que cooperan en la definicin de
estndares para la interoperabilidad en entornos heteregneos.

Fundado en 1989, en la actualidad lo componen ms de 700
empresas y otros organismos.

Jos Mara Pea Snchez
85
OMA
(Object Management Architecture)

Arquitectura de referencia sobre cual se pueden definir
aplicaciones distribuidas sobre un entorno heteregneo. CORBA
es la tecnologa asociada a esta arquitectura genrica.

Formalmente esta dividida en una serie de modelos:
Modelo de Objetos
Modelo de Interaccin
...
Jos Mara Pea Snchez
86
ORB
Servicios
Facilidades
Comnes
Interfaces
de Dominio
Aplicaciones
OMA
Una aplicacin definida sobre OMA esta compuesta por una serie
de objetos distribuidos que cooperan entre si. Estos objetos se
clasifican en los siguientes grupos:
Jos Mara Pea Snchez
87
OMA
Servicios:
Proporcionan funciones elementales necesarias para cualquier tipo
de entorno distribuido, independientemente del entorno de aplicacin.

Los tipos de funciones proporcionados son cuestiones tales como la
resolucin de nombres, la notificacin asncrona de eventos o la
creacin y migracin de objetos.

Concede un valor aadido sobre otras tecnologas (por ejemplo RMI).

Estn pensados para grandes sistemas.
Jos Mara Pea Snchez
88
OMA
Facilidades Comunes:
Proporcionan funciones, al igual que los servicios vlidas para varios
dominios pero ms complejas. Estn orientadas a usuarios finales
(no al desarrollo de aplicaciones).

Un ejemplo de este tipo de funciones es el DDCF (Distributed
Document Component Facility) formato de documentacin basado en
OpenDoc.

(Tambin denominadas Facilidades Horizontales)
Jos Mara Pea Snchez
89
OMA
Interfaces de Dominio:
Proporcionan funciones complejas, al igual que las Facilidades, pero
restringidas a campos de aplicacin muy concretos. Por ejemplo,
telecomunicaciones, aplicaciones mdicas o financieras, etc.

Muchos grupos de inters (SIGs) trabajan sobre estas
especificaciones.

(Tambin denominadas Facilidades Verticales)
Jos Mara Pea Snchez
90
OMA
Aplicaciones:
El resto de funciones requeridas por una aplicacin en concreto. Es
el nico grupo de objetos que OMG no define, pues esta compuesto
por los objetos propios de cada caso concreto.

Estos son los objetos que un sistema concreto tiene que desarrollar.
El resto (servicios, facilidades) pueden venir dentro del entorno de
desarrollo.
Jos Mara Pea Snchez
91
OMA
ORB:
(Object Request Broker)

Es el elemento central de la arquitectura. Proporciona las
funcionalidades de interconexin entre los objetos distribuidos
(servicios, facilidades y objetos de aplicacin) que forman una
aplicacin.

Representa un bus de comunicacin entre objetos.
Jos Mara Pea Snchez
92
Servidor
void ingresar(long){
....
.... }
Cliente
x->ingresar(30)
ORB
ORB
Para posibilitar la comunicacin entre dos objetos cualesquiera
de una aplicacin se realiza por medio del ORB. El escenario de
aplicacin elemental es:
Jos Mara Pea Snchez
93
IDL de CORBA
(Interface Definition Language)
Es el lenguaje mediante el cual se describen los mtodos que un
determinado objeto del entorno proporciona al resto de
elementos del mismo.

interface Cuenta
{
void ingresar(in long cantidad);
void retirar(in long cantidad);
long balance();
};
Jos Mara Pea Snchez
94
IDL de CORBA
Language Mappings:
Traducen la definicin IDL a un lenguaje de programacin como:
C++,
Ada,
COBOL,
SmallTalk,
Java,
...

Este proceso genera dos fragmentos de cdigo denominados Stub y
Skeleton que representan el cdigo de cliente y servidor
respectivamente.
Jos Mara Pea Snchez
95
IDL de CORBA
El cdigo cliente generado en
base a la definicin IDL (stub)
contiene las llamadas para
realizar el proceso de
marshalling.

Marshalling: Traduccin de los
argumentos a un formato
intermedio y pedir al ORB su
ejecucin.
Interface Cuenta
{
void ingresar(in long cantidad);
}
Cuenta.idl
Compilador IDL
Cuenta_Skel.c++
class Cuenta_Stub : ...
{
void ingresar(CORBA::Long &cantidad)
{ <MARSHALLING> }
}
Cuenta_Stub.c++
Jos Mara Pea Snchez
96
IDL de CORBA
El cdigo servidor generado en
base a la definicin IDL
(skeleton) contiene las
llamadas para realizar el
proceso inverso (de-
marshalling).

De-marshalling: Recuperar del
ORB los parametros con los
que se invoc el mtodo,
construir la llamada y realizar la
peticin.
Compilador IDL
Cuenta_Stub.c++
class Cuenta_Skel : ...
{
virtual
void ingresar(CORBA::Long &cantidad)=0;

void __ingresar()
{
<DE-MARSHALLING>
ingresar(c);
}
}
Cuenta_Skel.c++
Jos Mara Pea Snchez
97
IDL de CORBA
Implementacin del Objeto:
La implementacin del objeto es invocada por los mtodos definidos
en el Skeleton. Por lo general se trata de una clase derivada del
mismo.

class Cuenta_Impl: public Cuenta_Skel
{
void ingresar(CORBA::Long &cantidad)
{
dinero += cantidad;
}
};
Jos Mara Pea Snchez
98
ORB ORB
DII Stub
ORB
Interface
ORB
Interface
Skel. DSI
Object Adapter (OA)
Cliente Objeto Servidor
Componentes de un ORB
La arquitectura completa de comunicaciones de CORBA es la
siguiente:
Jos Mara Pea Snchez
99
Stub:
Cdigo cliente asociado al objeto remoto con el que se desea
interactuar. Simula para el cliente los mtodos del objeto remoto,
asociando a cada uno de los mtodos una serie de funciones que
realizan la comunicacin con el objeto servidor.

Skeleton:
Cdigo servidor asociado al objeto. Representa el elemento anlogo
al stub del cliente. Se encarga de simular la peticin remota del
cliente como una peticin local a la implementacin real del objeto.

Jos Mara Pea Snchez
100
DII:
(Dynamic Invocation Interface)
Alternativa al uso de stubs estticos que permite que un cliente
solicite peticiones a servidores cuyos interfaces se desconocan en
fase de compilacin.

DSI:
(Dynamic Skeleton Interface)
Alternativa dinmica al uso de skeletons estticos definidos en
tiempo de compilacin del objeto. Es usado por servidores que
durante su ejecucin pueden arrancar diferentes objetos que pueden
ser desconocidos cuando se compil el servidor.
Jos Mara Pea Snchez
101
ORB/Interface ORB:
Elemento encargado de (entre otras) las tareas asociadas a la
interconexin entre la computadora cliente y servidor, de forma
independiente de las arquitecturas hardware y SSOO.
Debido a que tanto clientes como servidores pueden requerir de
ciertas funcionalidades del ORB, ambos son capaces de acceder a
las mismas por medio de un interfaz.
Las dos principales responsabilidades del ORB son:
Localizacin de objetos: El cliente desconoce la computadora donde
se encuentra el objeto remoto.
Comunicacin entre cliente y servidor: De forma independiente de
protocolos de comunicacin o caractersticas de implementacin
(lenguaje, sistema operativo, ...)
Jos Mara Pea Snchez
102
Adaptado de Objetos:
En este elemento se registran todos los objetos que sirven en un
determinado nodo. Es el encargado de mantener todas las
referencias de los objetos que sirven en una determinada
computadora de forma que cuando llega una peticin a un mtodo es
capaz de redirigrla al cdigo del skeleton adecuado.

Existen dos tipos de Adaptadores de Objetos especificados por
OMG:
BOA: (Basic Object Adapter).
POA: (Portable Object Adapter).
Jos Mara Pea Snchez
103
Las principales tareas del Adaptador de Objetos son:
Multiplexar a dos niveles (obnjeto y mtodo) las llamadas.
Mantiene informacin (almacenada en el Repositorio de
Implementaciones) sobre los objetos servidos, siendo el encargado
de activarlos si al llegar una peticin no se encontraban en ejecucin.
Permite diferente modos de activacin de los objetos:
Persistente: El estado del objeto se almacena entre varias ejecuciones.
Compartido: Todos los clientes comparten la instancia de objeto.
No-compartido: Cada cliente accede a una instancia diferente del
objeto.
Por-mtodo: Cada mtodo solicitado es servido por una instancia de
objeto diferente.
Genera las referencias de los objetos dentro del entorno. Esta
referencia es nica para todos los objetos.
Jos Mara Pea Snchez
104
ORB ORB
DII Stub
ORB
Interface
ORB
Interface
Skel. DSI
Object Adapter (OA)
Comunicacin va CORBA
Pasos de una comunicacin:
1- El cliente invoca el mtodo asociado en el stub que realiza el proceso
de marshalling. (Stub cliente)
2- El stub solicita del ORB la transmisin de la peticin hacia el objeto
servidor. (ORB cliente)
3- El ORB del servidor toma la peticin y la transmite el Adaptador de
Objetos asociado, por lo general slo hay uno. (ORB servidor)
1
2
3
4
5
6
7
Jos Mara Pea Snchez
105
Comunicacin va CORBA
4- El Adaptador de Objetos resuelve cul es el objeto invocado, y dentro
de dicho objeto cul es el mtodo solicitado (Adaptador de Objetos)
5- El skeleton del servidor realiza el proceso de de-marshalling de los
argumentos e invoca a la implementacin del objeto. (Skeleton servidor)
6- La implementacin del objeto se ejecuta y los resultados y/o parmetros
de salida se retornan al skeleton. (Implementacin del objeto)
7- El proceso de retorno de los resultados es anlogo.
ORB ORB
DII Stub
ORB
Interface
ORB
Interface
Skel. DSI
Object Adapter (OA)
1
2
3
4
5
6
7
Jos Mara Pea Snchez
106
Implementacin de un ORB
El ORB representa a nivel lgico el bus de objetos que
comparten tanto clientes como servidores. A nivel de prctico
puede estar implementado como:
Residente cliente/servidor: Cdigo que tanto clientes como objetos
tiene que enlazar.
Demonio del sistema: Un servicio del sistema encargado de
centralizar las peticiones.
Interno al sistema: Integrado dentro del SO.
Librera: Usado cuando tanto clientes como servidores residen dentro
del mismo espacio de memoria.
Jos Mara Pea Snchez
107
Localizacin de Objetos
Los objetos de servicio de una aplicacin CORBA se
encuentran identificados por medio de una referencia nica
(Identificador de Objeto).
Esta referencia es generada al activar un objeto en el
Adaptador de Objetos.
Por medio de esta referencia el ORB es capaz de localizar la
computadora y el Adaptador de Objetos donde se encuentra, y
ste ltimo es capaz de identificar el objeto concreto dentro del
Adaptador.

Jos Mara Pea Snchez
108
Localizacin de Objetos
El ORB proporciona mecanismos para transformar a cadena de
caracteres y de cadena de caracteres a dicha referencia :
object_to_string, string_to_object
Ejemplo:

IOR:010000000f00000049444c3a4375656e74613a312e300000020
00000000000003000000001010000160000007175696e6f2e646174
73692e66692e75706d2e65730041040c000000424f418a640965000
009f403010000002400000001000000010000000100000014000000
0100000001000100000000000901010000000000
Jos Mara Pea Snchez
109
Implementacin del Servidor
La implementacin del objeto se
disea como una subclase de la
clase generada por el compilador (el
skeleton) de IDL en base a la
definicin.

Si el lenguaje usado para la
implementacin no soporta objetos el
mecanismo es diferente.
Cuenta.idl
idl
Cuenta_skel

<DEMARSHALLING>
Cuenta_impl

<implementacin>
Clase generada
automticamente
Implementacin
del objeto
Jos Mara Pea Snchez
110
Tareas Tpicas de un Servidor
El servidor debe realizar las siguientes tareas:
Inicializar el ORB (obtiene el interfaz con el ORB).
CORBA::ORB_init
Obtener la referencia del Adaptador de objetos.
orb->BOA_init
Crear un un objeto (de la clase Cuenta_impl).
new Cuenta_impl()
Activar el objeto.
boa->impl_is_ready(...)
Iniciar el bucle de servicio.
orb->run()
Jos Mara Pea Snchez
111
Tareas Tpicas de un Cliente
El cliente debe realizar las siguientes tareas:
Inicializar el ORB (obtiene el interfaz con el ORB).
CORBA::ORB_init
Obtener la referencia del Adaptador de objetos.
orb->BOA_init
Obtener la referencia al objeto (desde un string).
orb->string_to_object(...)
Cambiar la clase del objeto obtenido (down-casting).
Cuenta::_narrow(obj)
Realizar las llamadas al objeto.
cc->...
Jos Mara Pea Snchez
112
Otros Modos de Activacin
Como alternativa al proceso de arrancar cada uno de los objetos
de servicio, existe la posibilidad de indicar al Adaptador de
Objetos otros modos de activacin:
Esto permite no arrancar la instancia hasta que un cliente la solicite o
sea activada explcitamente.

Esta alternativa requiere un ORB del tipo demonio o interno al
sistema.
Jos Mara Pea Snchez
113
Otros Modos de Activacin
1- En primer lugar es necesario arrancar el
demonio.
Para la implementacin MICO es:
micod -ORBIIOPAddr <direc.>

2- Se registra en el repositorio de
implementaciones un nuevo objeto,
indicando el mandato para ejecutarlo.
imr create <nombre> <modo>
<programa>
-ORBImplRepoAddr <direc.>

3- En cualquier otro momento se activa el
objeto
imr activate <nombre>
-ORBImplRepoAddr <direc.>
ORB
Adaptador de Objetos
Repositorio de
Implementaciones
Nombre Estado Referencia
CuentaCorriente active IOR:0f.....
Cuenta
Jos Mara Pea Snchez
114
Servicios CORBA
Conjunto de objetos o grupos de objetos, que proporcionan una
serie de funcionalidades elementales. Estos objetos esta
definidos de forma estndar (interfaces IDL concretos).
Sus especificaciones se encuentran recogidas en los documentos
COSS (Common Object Services Specifications).
Los servicios definidos son:
Servicio de Nombres
Servicio de Eventos
Servicio de Ciclo de Vida
Servicio de Objetos Persistentes
Servicio de Transacciones
Servicio de Control de Concurrencia
Servicio de Relacin
Servicio de Externalizacin
Servicio de Consulta
Servicio de Licencias
Servicio de Propiedad
Servicio de Tiempo
Servicio de Seguridad
Servicio de Negociacin
Servicio de Coleccin de Objetos
Jos Mara Pea Snchez
115
Uso del Servicio de Nombres
Permite asociar un nombre a una referencia de objeto. De esta
forma los objetos al activarse pueden darse de alta en el
servidor, permitiendo que otros objetos los obtengan su
referencia en base a dicho nombre.

Los nombres de los objetos se encuentran organizados en una
jerarqua de contextos de nombre.
Jos Mara Pea Snchez
116
NameService

Servicio de Nombres
El Servidos de Nombres, al igual que todo objeto del sistema se
encuentra previamente activo.
Jos Mara Pea Snchez
117
NameService

MiCuenta=IOR:X
Cuenta

bind(MiCuenta,IOR:X)
Servicio de Nombres
Un nuevo objeto se arranca y se registra en el servidor de
nombres:
Jos Mara Pea Snchez
118
NameService

MiCuenta=IOR:X
Cuenta

IOR:NS=resolve_initial_references(NameService)
Cliente
Servicio de Nombres
Un cliente localiza al servidor de nombres. Suele existir una
funcin interna del ORB para localizar al servidor de nombres
(resolve_initial_references) .
Jos Mara Pea Snchez
119
NameService

MiCuenta=IOR:X
Cuenta

IOR:X=resolve(MiCuenta)
Cliente
Servicio de Nombres
El cliente le pide al servidor de nombres que resuelva el nombre.
As obtiene la referencia al objeto buscado.
Jos Mara Pea Snchez
120
Servicio de Negociacin
Este servicio tambin permite obtener referencias a objetos
usando otra informacin:
Los objetos se exportan en el servidor con una serie de
caractersticas del servicio que proporcionan.
Los clientes consultan con el servidor cules son los objetos
ofertados con una serie de caractersticas.
Un cliente que buscase un servicio de impresin podra construir
una consulta del tipo:
Service=Printer AND
PrinterType=HP AND
OS!=WinNT
A lo cual el servidor le indicar los objetos que existen con dichas
caractersticas.
Jos Mara Pea Snchez
121
Comparativa
CORBA vs DCOM
CORBA es un estndar abierto y no propietario.
CORBA proporciona soporte para diversos SO.
CORBA es ms completo y flexible.
CORBA da una salida a los legacy systems

DCOM esta integrado con la tecnologa MicroSoft.
DCOM ha tenido una fuerte penetracin en el mercado.

Jos Mara Pea Snchez
122
Comparativa
CORBA vs RMI
CORBA permite una mayor heterogeneidad en el desarrollo de
aplicaciones (RMI slo se puede desarrollar con Java).
CORBA ademas de las funcionalidades de comunicacin,
proporciona servicios.
RMI funciona sobre CORBA (IIOP).

RMI es mucho ms sencillo y cmodo de usar.
RMI permite el paso de objetos por valor y por referencia.
Jos Mara Pea Snchez
123
Ejemplo
El ejemplo esta compuesto por cinco ficheros:
Definicin IDL del objeto. (Cuenta.idl)
Cabecera de la implementacin del objeto. (Cuenta_impl.h++)
Implementacin del objeto.
(Cuenta_impl.c++)
Cdigo servidor. (servidor.c++)
Cdigo cliente. (cliente.c++)

Comunica C I Ones

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Comunica C I Ones

Încărcat de

Drepturi de autor:

Formate disponibile

Sistemas Operativos Distribuidos

S-ar putea să vă placă și