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.
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.
Niveles de Comunicacin
1) Paso de 2) Funcionalidades de 3) Llamadas a
mensajes puro. comunicacin de bajo procedimientos
Aplicaciones en nivel. Sistemas remotos y objetos
red. Operativos Distribuidos. distribuidos.

App./Servicios App./Servicios
Aplicaciones
y RMI/RPC
Servicios Interfaz
Protocolo y
y
API (sockets) Representacin
Lgica de
TCP/UDP Comunicacin TCP/UDP

ATM/Ethernet
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.
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.
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.
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.
Primitivas de Comunicacin

EMISOR 8 5 RECEPTOR
7 RED 6
1 Ncleo ACK Ncleo 4
Emisor msg Receptor
2 3
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.
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.
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.
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).
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.
Sistemas Operativos Distribuidos

Cliente-Servidor

<Paso de Mensajes>
Berkeley Sockets
Java Sockets
 Paso de Mensajes
Los modelos de comunicacin basados en cliente-servidor con paso
de mensajes responden al esqueleto:

msg CLIENTE SERVIDOR msg

Send(msg) Receive(msg)
msg

Mensaje msg,reply;
Mensaje op,ack;
msg=<dato a trasmitir>
receive(op);
send(msg);
if(validOp(op))
receive(reply);
ack=<operacin OK>
if(isOK(reply))
else
<operacin correcto>
ack=<operacin ERROR>
else
send(ack);
<error en operacin>
...
...
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,
...
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.
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);
 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 Arquitectura
little-endian big-endian
0005 0 1 2 3
0005
Dato a enviar: 5
3 2 1 0 Valor: 5x224+0x216+0x28+0
0005
Dato a recibido: 83.886.080
Valor: 0x224+0x216+0x28+5
 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.
 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.
 Conceptos Bsicos sobre Sockets

Dominios de comunicacin.
Tipos de sockets.
Direcciones de sockets.
Creacin de un socket. 1.- Creacin del socket
Asignacin de direcciones.
Solicitud de conexin.
Preparar para aceptar conexiones.
2.- Asignacin de direccin
Aceptar una conexin.
Transferencia de datos.

3.- Aceptacin de conexin

 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.
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.
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).
Direcciones de Sockets en
PF_INET
Una direccin destino viene determinada por:
Direccin del host: 32 bits.
Puerto de servicio: 16 bits.
Una transmisin est caracterizada por cinco
parmetros nicos:
Direccin host y puerto origen.
Direccin host y puerto destino.
Protocolo de transporte (UDP o TCP).
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
Escenario de Uso de Sockets
streams Proceso servidor
socket()

bind()
Proceso cliente
socket() listen()

Abrir conexin
accept() Posible
connect()
Ejecucin
en Paralelo
accept()

Peticin
send()/write() recv()/read()

Respuesta
recv()/read() send()/write()

close() close()
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.
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.
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.
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().
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.
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).
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.
Sistemas Operativos Distribuidos

Llamadas a
Procedimientos
<RPC> Remotos
Sun RPCs
 Llamadas a Procedimientos Remotos

Servidor
... ...
Cliente

msg
send(msg) receive(msg)
... ...
rpy
receive(rpy) send(rpy)
Paso de mensajes (visin de bajo nivel)

int buscar(int cod)

Servidor
... {
Cliente

... ...
x=buscar(1556) ...
... return val;
}
Llamadas a procedimientos remotos (ms alto nivel) Comodidad
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).
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).
Elementos Necesarios

Cdigo cliente.
Cdigo del servidor.
Formato de representacin.
Definicin del interfaz.
Localizacin del servidor.
Semnticas de fallo.
int buscar(int cod)

Servidor
Cliente

... {
... ...
x=buscar(1556) ...
... return val;
}
 Cdigo Cliente/Cdigo Servidor
Las funciones de abstraccin de una llamada RPC a
intercambio de mensajes se denominan resguardos (stubs).
SISTEMA CLIENTE SISTEMA SERVIDOR
CDIGO DE LA APLICACIN PROCEDIMIENTOS
5
INICIO FIN EJECUTA
LLAMADA LLAMADA PROCEDIMIENTO
REMOTO
RESGUARDO PREPARA RESGUARDO CONVIERTE 4
CLIENTE 1 ENTRADA SERVIDOR ENTRADA
CONVIERTE 9 6 PREPARA
SALIDA SALIDA
BIBLIOT. ENVA BIBLIOT. RECIBE 3
EJECUCIN 2 ENTRADA EJECUCIN Y PASA
RPC RECIBE RPC
8 7 TRANSMITE
SALIDA SALIDA
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.
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.
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);
}
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).
 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.
 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.
 RPC: Protocolo
Bsico
enlaza con cliente servidor
el servidor Se registra con un
servicio de nombres
prepara
parmetros,
enva peticin recibe peticin
Ejecuta el
procedimiento

enva peticin
Desempaqueta
la respuesta
 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] ?
[4]
[5]

[2]
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
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.
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
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
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
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
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
 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
Ejemplo de Fichero IDL
(Sun RPC)
struct peticion {
int a;
int b;
};

program SUMAR {
version SUMAVER {
int SUMA(peticion) = 1;
} = 1;
} = 99;
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
Programacin con
RPC
DESARROLLO
DE LA
INTERFAZ
FICHERO
DE DEFINICIN
DE INTERFAZ

COMPILADOR IDL

RESGUARDO CABECERA RESGUARDO

EN CLIENTE EN SERVIDOR

FICHEROS CABECERA CABECERA

FICHEROS
FUENTE DEL FUENTE DEL
COMPILADOR C CLIENTE SERVIDOR COMPILADOR C

COMPILADOR C COMPILADOR C

OBJETO FICHEROS FICHEROS OBJETO

RESGUARDO OBJETO DEL BIBLIOT. BIBLIOT. OBJETO DEL RESGUARDO
EN CLIENTE CLIENTE RPC RPC SERVIDOR EN SERVIDOR

MONTADOR MONTADOR

EJECUTABLE EJECUTABLE
DESARROLLO DEL DEL DESARROLLO
DEL CLIENTE SERVIDOR DEL
CLIENTE SERVIDOR
Esquema de una
Aplicacin cliente.c
Archivos para
el cliente
idl_clnt.c

idl_xdr.c
repcgen Archivos
idl.x
comunes
idl.h

idl_svc.c
Archivos para
el servidor
servidor.c
Sistemas Operativos Distribuidos

Entornos de
Objetos
<Objetos Remotos> Distribuidos
Java RMI
CORBA
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.
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.
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.
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.
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);
Arquitectura de Java
RMI
 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.
Desarrollo de Aplicaciones
RMI
1
Definicin de la
interfaz remota

2
Implementacin de la
interfaz remota

(.java)
3
javac

(.class)
4
rmic Servidor
(.class)
8 usa Esqueleto
Esqueleto
Cliente (.class)
(.class)
(.java)
5
9 Arrancar RMIRegistry
javac
6
(.class) Crear los objetos
10
Ejectuar 7
Cliente Registrar los objetos

CLIENTE SERVIDOR
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+"/"+M
iCuenta");

Antes de arrancar el cliente y el servidor, se debe

arrancar el programa rmiregistry en el servidor para
el servicio de nombres
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.
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
...
 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:

Facilidades Interfaces
Servicios
Comnes de Dominio

ORB

Aplicaciones
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.

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)

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)

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.
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.

 ORB
Para posibilitar la comunicacin entre dos objetos cualesquiera de
una aplicacin se realiza por medio del ORB. El escenario de
aplicacin elemental es:

Servidor
Cliente void ingresar(long){
x->ingresar(30) ....
.... }

ORB
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();
};
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.
 IDL de CORBA
El cdigo cliente Cuenta.idl

generado en base a la
Interface Cuenta
{

definicin IDL (stub) }

void ingresar(in long cantidad);

contiene las llamadas

para realizar el proceso Compilador IDL
de marshalling.
Cuenta_Skel.c++

Marshalling: Traduccin
de los argumentos a un
formato intermedio y
Cuenta_Stub.c++
class Cuenta_Stub : ...
pedir al ORB su{
ejecucin. void ingresar(CORBA::Long &cantidad)
{ <MARSHALLING> }
}
 IDL de CORBA
El cdigo servidor Compilador IDL
generado en base a la
definicin IDL (skeleton)
contiene las llamadas Cuenta_Skel.c++
para realizar el proceso class Cuenta_Skel : ...

inverso (de-
{
virtual

marshalling). Cuenta_Stub.c++
void ingresar(CORBA::Long &cantidad)=0;

void __ingresar()
{

De-marshalling: <DE-MARSHALLING>

Recuperar del ORB los

ingresar(c);
}

parametros con los que }

se invoc el mtodo,
construir la llamada y
realizar la peticin.
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;
}
};
 Componentes de un ORB
La arquitectura completa de comunicaciones de CORBA es la
siguiente:

Cliente Objeto Servidor

ORB ORB Skel. DSI

DII Stub Interface Interface
Object Adapter (OA)

ORB ORB
Componentes de un ORB

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.
Componentes de un ORB

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.
Componentes de un ORB

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, ...)
Componentes de un ORB

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).
Componentes de un ORB

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.
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
Cliente lo general
Objeto slo
Servidor
hay uno. (ORB servidor) 6

5
ORB ORB Skel. 7 DSI
DII Stub Interface Interface
1 4 Object Adapter (OA)

2 3
ORB ORB
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 Objeto
Cliente se retornan al
Servidor
skeleton. (Implementacin del objeto) 6
7- El proceso de retorno de los resultados es anlogo.
5
ORB ORB Skel. 7 DSI
DII Stub Interface Interface
1 4 Object Adapter (OA)

2 3
ORB ORB
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.
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.
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:010000000f00000049444c3a4375656e74613a
312e30000002000000000000003000000001010000
160000007175696e6f2e64617473692e66692e7570
6d2e65730041040c000000424f418a640965000009
f40301000000240000000100000001000000010000
001400000001000000010001000000000009010100
00000000
Implementacin del
Servidor
Cuenta.idl
La implementacin del
objeto se disea como una
subclase de la clase
idl generada por el
compilador (el skeleton) de
Cuenta_skel Clase generada
IDL en base a la definicin.
<DEMARSHALLING>
automticamente

Cuenta_impl Si el lenguaje usado para la

Implementacin
del objeto implementacin no soporta
<implementacin>
objetos el mecanismo es
diferente.
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()
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->...
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.
 Otros Modos de
Activacin
1- En primer lugar es necesario
arrancar el demonio.
Para la implementacin MICO es:
Cuenta
micod -ORBIIOPAddr <direc.>

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

3- En cualquier otro momento se activa

Nombre Estado Referencia
el objeto
CuentaCorriente active IOR:0f.....
imr activate <nombre>
-ORBImplRepoAddr <direc.>
 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 Consulta

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 Licencias
Servicio de Propiedad
Servicio de Tiempo
Servicio de Seguridad
Servicio de Negociacin
Servicio de Coleccin de Objetos
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.
Servicio de Nombres

El Servidos de Nombres, al igual que todo objeto del

sistema se encuentra previamente activo.

NameService
Servicio de Nombres

Un nuevo objeto se arranca y se registra en el

servidor de nombres:

bind(MiCuenta,IOR:X)

NameService Cuenta

MiCuenta=IOR:X
 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) .
IOR:NS=resolve_initial_references(NameService)

NameService Cuenta
Cliente
MiCuenta=IOR:X
Servicio de Nombres

El cliente le pide al servidor de nombres que

resuelva el nombre. As obtiene la referencia al
objeto buscado.

IOR:X=resolve(MiCuenta)

NameService Cuenta
Cliente
MiCuenta=IOR:X
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.
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.
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.
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++)