SD S4 ComunicacionProcesos

Sistemas Distribuidos
Comunicación de
Procesos
Fuente: Universidad Politécnica de Madrid – Fernando Pérez Costoya / José María Peña Sánchez
Comunicación en Sistemas Distribuidos
Permite la interacción entre aplicaciones y servicios del sistema.
Mecanismos de comunicación entre procesos:

– Memoria compartida (Sólo uni/multiprocesador no distribuido).
– Paso de mensajes.
El nivel de abstracción en la comunicación:

– Sockets: Paso de mensajes puro (Cliente-Servidor).
– Llamadas a procedimientos remotos.
– Modelos de objetos distribuidos.
Sistemas Distribuidos 2
Tecnologías y Modelos
Tecnologías Modelos
Cómo se realiza la programación. Cómo se diseña el servicio
– Sockets
Berkeley Sockets Modelo cliente/servidor
Java Sockets
– Llamadas a procedimientos – Modelos con
remotos: intermediario:
Sun RPC Modelo proxy/cache
– Objetos distribuidos: Modelo multinivel
Java RMI
CORBA
Peer-to-peer
– Servicios web:
SOAP
Otras tecnologías o variantes de ellas Código Móvil
Implementación de las Funcionalidades
de Comunicación
1) Paso de 2) Funcionalidades de 3) Llamadas a
mensajes puro. comunicación de bajo nivel. procedimientos
Aplicaciones en Sistemas Distribuidos. remotos y objetos
red. distribuidos.
App./Servicios App./Servicios
Aplicaciones
y RMI/RPC
Servicios Interfaz
Protocolo y
y
API (sockets) Representación
Lógica de
TCP/UDP Comunicación TCP/UDP
ATM/Ethernet
Primitivas (instrucciones) de Comunicación
Cada una de las funciones de comunicación de una tecnología

determinada. Las primitivas básicas son:
– Envío: send(destino,mensaje).
– Recepción: receive(fuente,mensaje).
Otras primitivas:
– Conexión: connect(destino).
– Desconexión: close().
Cada una de las primitivas tiene las siguientes características:

– Modelo de operación: Bloqueantes vs No - bloqueantes.
– Sincronización: Síncronas vs Asíncronas.
– Fiabilidad: Fiables vs No-fiables.
Bloqueantes vs. No-bloqueantes
Las características de bloqueo son:

– Primitivas bloqueantes: La operación bloquea al elemento que la
solicita hasta que ésta sea completada.
– Primitivas no-bloqueantes: La operación no detiene la ejecución del
elemento que la solicita.
Las llamadas no bloqueantes tienen distinto sentido dependiendo

de la primitiva que se trate:
– Envío no bloqueante: El emisor almacena el dato en un buffer del
núcleo (que se encarga de su transmisión) y reanuda su ejecución.
– Recepción no bloqueante: Si hay un dato disponible el receptor lo
lee, en otro caso indica que no había mensaje.
Síncronas vs. Asíncronas
Esta característica afecta no tanto a la primitiva como a la

transmisión en sí (envío+recepción).
– Comunicación síncrona: Envío y recepción se realizan de forma
simultánea.
– Comunicación asíncrona: El envío no requiere que el receptor este
esperando.
La comunicación asíncrona usa un buffer de almacenamiento.

Implica ciertas condiciones de bloqueo en envío y recepción.
Fiabilidad
El envío fiable de datos garantiza que un mensaje enviado ha

sido recibido por el receptor:
– Implica la retransmisión de mensajes de validación (ACKs).
– Garantía de que se han recibido correctamente en el/los nodo(s)
destino.
– Se mantiene el orden de emisión.
– Control de la fragmentación de mensajes para eliminar limitaciones
de tamaño.
La fiabilidad la puede garantizar:
– El protocolo de comunicación (TCP si y UDP no).
– La lógica de la aplicación del emisor y del receptor.
Primitivas de Comunicación
EMISOR 8 5 RECEPTOR
7 RED 6
1 Núcleo ACK Núcleo 4
Emisor msg Receptor
2 3
Envío no bloqueante (comunicación asíncrona): [1:8] El emisor continua al pasar el
mensaje al núcleo.
Envío bloqueante (comunicación asíncrona): [1:2:7:8] El emisor espera a que el
núcleo transmita por red el mensaje.
Envío bloqueante fiable (comunicación asíncrona): [1:2:3:6:7:8]: El emisor espera a
que el núcleo receptor recoge el mensaje.
Envío bloqueante explícito (comunicación síncrona): [1:2:3:4:5:6:7:8]: Idem al
anterior, pero es la aplicación receptora la que confirma la recepción.
Petición-Respuesta: [1:2:3:4:<servicio>:5:6:7:8]: El emisor espera a que el receptor
procese la operación para reanudar la ejecución.
Direccionamiento
Información válida para la identificación de elementos del

sistema. Posibles receptores de un mensaje.
Mecanismos:
– Dirección dependiente de la localización:
• Por ejemplo: dirección máquina + dirección puerto local.
• No proporciona transparencia.
– Dirección independiente de la localización (dir. lógica):
• Facilita transparencia.
• Necesidad de proceso de localización:
– Mediante broadcast.
– Uso de un servidor de localización que mantiene relaciones entre
direcciones lógicas y físicas.
• Uso de cache en clientes para evitar localización.
Modelos con/sin Estado
• Servicio Con estado vs. Sin estado:
– Determina si el servidor mantiene información de los clientes o no.
• Ventajas de servicio con estado:
– Mensajes de petición más cortos.
– Mejor rendimiento (se mantiene información en memoria).
– Favorece estrategias de optimización:
• Estrategias predictivas: análisis del patrón de operaciones del cliente.
• Ventajas de servicio sin estado:
– Más tolerantes a fallos (rearranque del servidor).
• Peticiones autocontenidas.
– Reduce el número de mensajes: no hay comienzos/finales de sesión.
– Más económicos para el servidor (no consume recursos de memoria)
• Servicios inherentes con estado (cerrojos distribuidos).
• Estado sobre servicios sin estado (HTTP+cookies).
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 (visión de bajo nivel)
int buscar(int cod)
Servidor
... {
Cliente
... ...
x=buscar(1556) ...
... return val;
}
Llamadas a procedimientos remotos (más alto nivel) Comodidad
Llamadas a Procedimientos Remotos
Remote Procedure Call: RPC. SON BLOQUEANTES Y

SINCRONAS
Evolución:
– Propuesto por Birrel y Nelson en 1985.
– Sun RPC es la base para varios servicios actuales (NFS o NIS).
– Llegaron a su culminación en 1990 con DCE (Distributed Computing
Environment) de OSF.
– Han evolucionado hacia orientación a objetos: invocación de métodos
remotos (CORBA, RMI).
Funcionamiento General de RPC
Cliente:
– El proceso que realiza la llamada a una función.
– Dicha llamada empaqueta los argumentos en un mensaje y se los
envía a otro proceso.
– Queda la espera del resultado.
Servidor:
– Se recibe un mensaje consistente en varios argumentos.
– Los argumentos son usados para llamar una función en el servidor.
– El resultado de la función se empaqueta en un mensaje que se
retransmite al cliente.
Objetivo: acercar la semántica de las llamadas a procedimiento

convencional a un entorno distribuido (transparencia).
Elementos Necesarios
• Código cliente.
• Código del servidor.
• Formato de representación.
• Definición de la interfaz.
• Localización del servidor.
• Semánticas de fallo.
int buscar(int cod)
Servidor
Cliente
... {
... ...
Call buscar(1556) ...
... return val;
}
Código Cliente/Código Servidor
Las funciones de abstracción de una llamada RPC a intercambio de
mensajes se denominan interfaces (stubs).
SISTEMA CLIENTE SISTEMA SERVIDOR
CÓDIGO DE LA APLICACIÓN PROCEDIMIENTOS
5
INICIO FIN EJECUTA
LLAMADA LLAMADA PROCEDIMIENTO
REMOTO
INTERFASE PREPARA INTERFASE CONVIERTE 4
CLIENTE 1 ENTRADA SERVIDOR ENTRADA
CONVIERTE 9
SALIDA
6 PREPARA
SALIDA
BIBLIOT. ENVÍA BIBLIOT. RECIBE 3
EJECUCIÓN 2 ENTRADA EJECUCIÓN Y PASA
RPC RECIBE RPC
8 7 TRANSMITE
SALIDA SALIDA
Interfaces (stubs)
Se generan automáticamente por el software de RPC en base a

la interfaz del servicio.
– Son independientes de la implementación que se haga del cliente y
del servidor. Sólo dependen de la interfaz.
Tareas que realizan:
– Localizan al servidor.
– Empaquetan los parámetros y construyen los mensajes.
– Envían el mensaje al servidor.
– Espera la recepción del mensaje y devuelven los resultados.
Se basan en una librería de funciones RPC para las tareas más

habituales.
Formato de Representación
Una de las funciones de las interfaces es empaquetar los

parámetros en un mensaje: empaquetamiento (marshalling).
Problemas en la representación de los datos

– Servidor y cliente pueden ejecutar en máquinas con arquitecturas
distintas.
– XDR (external data representation) es un estándar que define la
representación de tipos de datos.
– Pasos de parámetros (entrada/salida):
• Problemas con los punteros: Una dirección sólo tiene sentido en un
espacio de direcciones.
Definición de Interfaces: IDL
IDL (Interface Definition Language) es un lenguaje de

representación de interfaces:
– Hay muchas variantes de IDL:
• Integrado con un lenguaje de programación (Cedar, Argus).
• Específico para describir las interfaces (RPC de Sun y RPC de DCE).
– Define procedimientos y argumentos (No la implementación).
– Se usa habitualmente para generar de forma automática las
interfaces (stubs).
Server ServidorTickets
{
procedure void reset();
procedure int getTicket(in string ident);
procedure bool isValid(in int ticket);
}
Localización del Servidor
La comunicación de bajo nivel entre cliente y servidor por medio

de paso de mensajes (por ejemplo sockets). Esto requiere:
– Localizar la dirección del servidor: tanto dirección IP como número de
puerto en el caso de sockets.
– Enlazar con dicho servidor (verificar si esta sirviendo).
Estas tareas las realiza la interfaz cliente.

En el caso de servicios cuya localización no es estándar se
recurre al enlace dinámico (dynamic binding).
Enlace Dinámico
Enlace dinámico: permite localizar objetos con nombre en un

sistema distribuido, en concreto, servidores que ejecutan las
RPC.
Tipos de enlace:
– Enlace no persistente: la conexión entre el cliente y el servidor se
establece en cada llamada RPC.
– Enlace persistente: la conexión se mantiene después de la primera
RPC:
• Útil en aplicaciones con muchas RPC repetidas.
• Problemas si lo servidores cambian de lugar o fallan.
Enlazador Dinámico
Enlazador dinámico (binder): Es el servicio que mantiene una
tabla de traducciones entre nombres de servicio y direcciones.
Incluye funciones para:
– Registrar un nombre de servicio (versión).
– Eliminar un nombre de servicio.
– Buscar la dirección correspondiente a un nombre de servicio.
Como localizar al enlazador dinámico:

– Ejecuta en una dirección fija de un computador fijo.
– El sistema operativo se encarga de indicar su dirección.
– Difundiendo un mensaje (broadcast) cuando los procesos comienzan
su ejecución.
RPC: Protocolo Básico
“enlaza con cliente servidor

el servidor” Se registra con un
servicio de nombres
prepara
parámetros,
envía petición recibe petición
Ejecuta el
procedimiento
envía petición
Desempaqueta
la respuesta
Semántica Tratamiento de Fallos
Problemas que pueden plantear las RPC:

– El cliente no es capaz de localizar al servidor. [1]
– Se pierde el mensaje de petición del cliente al servidor. [2]
– Se pierde el mensaje de respuesta del servidor al cliente. [3]
– El servidor falla después de recibir una petición. [4]
– El cliente falla después de enviar una petición. [5]
[1] ?
[4]
[5]
[2]
Cliente no Puede Localizar al Servidor
• El servidor puede estar caído

• El cliente puede estar usando una versión antigua del servidor
• La versión ayuda a detectar accesos a copias obsoletas
• Cómo indicar el error al cliente
– Devolviendo un código de error (-1)
• No es transparente
– Ejemplo: sumar(a,b)
– Elevando una excepción
• Necesita un lenguaje que tenga excepciones
Pérdida de Mensajes del Cliente
• Es la más fácil de tratar.

• Se activa una alarma (timeout) después de enviar el mensaje.
• Si no se recibe una respuesta se retransmite.
• Depende del protocolo de comunicación subyacente.
Pérdidas de Mensajes de Respuesta
• Más difícil de tratar
• Se pueden emplear alarmas y retransmisiones, pero:
– ¿Se perdió la petición?
– ¿Se perdió la respuesta?
– ¿El servidor va lento?
• Algunas operaciones pueden repetirse sin problemas (operaciones
idempotentes)
– Una transferencia bancaria no es idempotente
• Solución 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 petición original o una
retransmisión
Fallos en los Servidores
• El servidor no ha llegado a ejecutar la operación

– Se podría retransmitir
• El servidor ha llegado a ejecutar la operación
• El cliente no puede distinguir los dos
• ¿Qué hacer?
– No garantizar nada
– Semántica al menos una vez
• Reintentar y garantizar que la RPC se realiza al menos una vez
• No vale para operaciones no idempotentes
– Semántica a lo más una vez
• No reintentar, puede que no se realice ni una sola vez
– Semántica de exactamente una
• Sería lo deseable
Fallos en los Clientes
• La computación está activa pero ningún cliente espera los

resultados (computación huérfana)
– Gasto de ciclos de CPU
– Si cliente rearranca y ejecuta de nuevo la RPC se pueden crear
confusiones
Aspectos de Implementación
• Protocolos RPC
– Orientados a conexión
• Fiabilidad se resuelve a bajo nivel, peor rendimiento
– No orientados a conexión
– Uso de un protocolo estándar o un específico
• Algunos utilizan TCP o UDP como protocolos básicos
• Coste de copiar información aspecto dominante en
rendimiento:
– buffer del cliente  buffer del SO local  red  buffer del SO
remoto + buffer del servidor
– Puede haber más copias en cliente para añadir cabeceras
– scatter-gather: puede mejorar rendimiento
RPC de Sun
Utiliza como lenguaje de definición de interfaz IDL:

– Una interfaz contiene un nº de programa y un nº de versión.
– Cada procedimiento específica un nombre y un nº de procedimiento
– Los procedimientos sólo aceptan un parámetro.
– Los parámetros de salida se devuelven mediante un único resultado
– El lenguaje ofrece una notación para definir:
• constantes
• definición 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 declaración de prototipos.
• Enlace dinámico
– El cliente debe especificar el host donde ejecuta el servidor
– El servidor se registra (nº de programa, nº de versión y nº de
puerto) en el port mapper local
– El cliente envía una petición 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;
Programación con un Paquete de RPC
• El programador debe proporcionar:

– La definición de la interfaz (fichero idl)
• Nombres de las funciones
• Parámetros que el cliente pasa al servidor
• Resultados que devuelve el servidor al cliente
– El código del cliente
– El código del servidor
• El compilador de idl proporciona:
– La interfaz del cliente
– La interfaz del servidor
Programación con RPC
DESARROLLO
DE LA ARCHIVO
DE DEFINICIÓN
INTERFAZ DE INTERFAZ
COMPILADOR IDL
INTERFAZ CABECERA INTERFAZ

EN CLIENTE EN SERVIDOR
ARCHIVOS CABECERA CABECERA

ARCHIVOS
FUENTE DEL FUENTE DEL
COMPILADOR C CLIENTE SERVIDOR COMPILADOR C
COMPILADOR C COMPILADOR C
OBJETO FICHEROS ARCHIVOS OBJETO

INTERFAZ OBJETO DEL BIBLIOT. BIBLIOT. OBJETO DEL INTERFAZ
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 Aplicación
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
Entornos de
Objetos
<Objetos Remotos> Distribuidos
•Java RMI
•CORBA
Motivación
La extensión de los mecanismos de RPC a una programación

orientada a objetos dio lugar a la aparición de los modelos de
objetos distribuidos.
Ventajas:
– Los métodos remotos están asociados a objetos remotos.
– Más natural para desarrollo orientado a objetos.
– Admite modelos de programación orientada a eventos.
Problemas:
– El concepto de referencia a objeto es fundamental.
– Objetos volátiles y objetos persistentes.
Objetos-Distribuidos
Características:
– Uso de un Middleware: Nivel de abstracción para la comunicación de
los objetos distribuidos. Oculta:
• Localización de objetos.
• Protocolos de comunicación.
• Hardware de computadora.
• Sistemas Operativos.
– Modelo de objetos distribuidos: Describe los aspectos del paradigma
de objetos que es aceptado por la tecnología: Herencia, Interfaces,
Excepciones, Polimorfismo, ...
– Recogida de basura (Garbage Collection): Determina los objetos que
no están siendo usados para a liberar recursos.
Tecnologías de Objetos Distribuidos
Actualmente existen tres tecnologías de desarrollo de sistemas

distribuidos basados en objetos:
– ANSA (1989-1991) fue el primer proyecto que intentó desarrollar una
tecnología para modelizar sistemas distribuidos complejos con
objetos.
– DCOM de Microsoft.
– CORBA de OMG.
– Tecnologías 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
Características 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 número de excepciones que en el caso de invocación de
métodos locales.
Java RMI
Localización 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);
....
// búsqueda 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 gestión de referencias remotas: trata los aspectos
relacionados con el comportamiento esperado de las
referencias remotas (mecanismos de recuperación, etc.)
• Nivel de interfaz/esqueleto (proxy/skeleton) que se encarga
del empaquetamiento (serialización) de los parámetros
– proxy: resguardo local. Cuando un cliente realiza una invocación
remota, en realidad hace una invocación de un método del resguardo
local.
– Esqueleto (skeleton): recibe las peticiones de los clientes, realiza la
invocación del método y devuelve los resultados.
Desarrollo de Aplicaciones RMI
1
Definición de la
interfaz remota
2
Implementación 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 nombres 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
OMG
(Object Management Group)
Conjunto de organizaciones que cooperan en la definición de

estándares para la interoperabilidad en entornos heteregéneos.
Fundado en 1989, en la actualidad lo componen más de 700

empresas y otros organismos.
OMA
(Object Management Architecture)
Arquitectura de referencia sobre cual se pueden definir

aplicaciones distribuidas sobre un entorno heterogéneo. CORBA
es la tecnología asociada a esta arquitectura genérica.
Formalmente esta dividida en una serie de modelos:

– Modelo de Objetos
– Modelo de Interacción
– ...
OMA
Una aplicación 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
Comúnes de Dominio
ORB
Aplicaciones
OMA
Servicios:
– Proporcionan funciones elementales necesarias para cualquier tipo
de entorno distribuido, independientemente del entorno de aplicación.
– Los tipos de funciones proporcionados son cuestiones tales como la

resolución de nombres, la notificación asíncrona de eventos o la
creación y migración de objetos.
– Concede un valor añadido sobre otras tecnologías (por ejemplo RMI).
– Están pensados para grandes sistemas.
OMA
Facilidades Comunes:
– Proporcionan funciones, al igual que los servicios válidas para varios
dominios pero más complejas. Están 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 documentación basado
en OpenDoc.
– (También denominadas Facilidades Horizontales)
OMA
Interfaces de Dominio:
– Proporcionan funciones complejas, al igual que las Facilidades, pero
restringidas a campos de aplicación muy concretos. Por ejemplo,
telecomunicaciones, aplicaciones médicas o financieras, etc.
– Muchos grupos de interés (SIGs) trabajan sobre estas

especificaciones.
– (También denominadas Facilidades Verticales)
OMA
Aplicaciones:
– El resto de funciones requeridas por una aplicación 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 interconexión entre los objetos distribuidos
(servicios, facilidades y objetos de aplicación) que forman una
aplicación.
– Representa un bus de comunicación entre objetos.
ORB
Para posibilitar la comunicación entre dos objetos cualesquiera

de una aplicación se realiza por medio del ORB. El escenario de
aplicación 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 métodos 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 definición IDL a un lenguaje de programación como:
• C++,
• Ada,
• COBOL,
• SmallTalk,
• Java,
• ...
– Este proceso genera dos fragmentos de código denominados Stub y

Skeleton que representan el código de cliente y servidor
respectivamente.
IDL de CORBA
El código cliente generado en Cuenta.idl
base a la definición IDL (stub)

Interface Cuenta
{
contiene las llamadas para }

void ingresar(in long cantidad);
realizar el proceso de
marshalling.
Compilador IDL
Marshalling: Traducción de los Cuenta_Skel.c++
argumentos a un formato
intermedio y pedir al ORB su
ejecución. Cuenta_Stub.c++
class Cuenta_Stub : ...
{
void ingresar(CORBA::Long &cantidad)
{ <MARSHALLING> }
}
IDL de CORBA
El código servidor generado en Compilador IDL
base a la definición IDL
(skeleton) contiene las Cuenta_Skel.c++
llamadas para realizar el class Cuenta_Skel : ...
proceso inverso (Un- {

virtual
marshalling). void ingresar(CORBA::Long &cantidad)=0;
Cuenta_Stub.c++
void __ingresar()
Un-marshalling: Recuperar del {

<DE-MARSHALLING>
ORB los parámetros con los ingresar(c);
que se invocó el método,

}
}
construir la invocación y
realizar la petición.
IDL de CORBA
Implementación del Objeto:

– La implementación del objeto es invocada por los métodos 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
Stub:
– Código cliente asociado al objeto remoto con el que se desea
interactuar. Simula para el cliente los métodos del objeto remoto,
asociando a cada uno de los métodos una serie de funciones que
realizan la comunicación con el objeto servidor.
Skeleton:
– Código servidor asociado al objeto. Representa el elemento análogo
al stub del cliente. Se encarga de simular la petición remota del
cliente como una petición local a la implementación real del objeto.
DII:
– (Dynamic Invocation Interface)
– Alternativa al uso de stubs estáticos que permite que un cliente
solicite peticiones a servidores cuyos interfaces se desconocían en
fase de compilación.
DSI:
– (Dynamic Skeleton Interface)
– Alternativa dinámica al uso de skeletons estáticos definidos en
tiempo de compilación del objeto. Es usado por servidores que
durante su ejecución pueden arrancar diferentes objetos que pueden
ser desconocidos cuando se compiló el servidor.
ORB/Interface ORB:
– Elemento encargado de (entre otras) las tareas asociadas a la
interconexión 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:
– Localización de objetos: El cliente desconoce la computadora donde
se encuentra el objeto remoto.
– Comunicación entre cliente y servidor: De forma independiente de
protocolos de comunicación o características de implementación
(lenguaje, sistema operativo, ...)
Adaptador 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 petición a un método es
capaz de redirigírla al código del skeleton adecuado.
Existen dos tipos de Adaptadores de Objetos especificados

por OMG:
– BOA: (Basic Object Adapter).
– POA: (Portable Object Adapter).
Las principales tareas del Adaptador de Objetos son:

– Multiplexar a dos niveles (objeto y método) las llamadas.
– Mantiene información (almacenada en el Repositorio de
Implementaciones) sobre los objetos servidos, siendo el encargado
de activarlos si al llegar una petición no se encontraban en ejecución.
– Permite diferente modos de activación 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-método: Cada método 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.
Comunicación vía CORBA
Pasos de una comunicación:

1- El cliente invoca el método asociado en el stub que realiza el proceso
de marshalling. (Stub cliente)
2- El stub solicita del ORB la transmisión de la petición hacia el objeto
servidor. (ORB cliente)
3- El ORB del servidor toma la petición y la transmite el Adaptador de
Objetos asociado, por lo general sólo hay uno. (ORB servidor)

6
5
ORB ORB Skel. 7 DSI
1 4 Object Adapter (OA)
2 3
ORB ORB
Comunicación vía CORBA
4- El Adaptador de Objetos resuelve cuál es el objeto invocado, y dentro
de dicho objeto cuál es el método solicitado (Adaptador de Objetos)
5- El skeleton del servidor realiza el proceso de de-marshalling de los
argumentos e invoca a la implementación del objeto. (Skeleton servidor)
6- La implementación del objeto se ejecuta y los resultados y/o parámetros
de salida se retornan al skeleton. (Implementación del objeto)
7- El proceso de retorno de los resultados es análogo.

6
5
ORB ORB Skel. 7 DSI
1 4 Object Adapter (OA)
2 3
ORB ORB
Localización de Objetos
• Los objetos de servicio de una aplicación 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.
Localización 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
Implementación del Servidor
La implementación del objeto se

Cuenta.idl
diseña como una subclase de la
clase generada por el compilador (el
idl
skeleton) de IDL en base a la
Cuenta_skel definición.
Clase generada
<DEMARSHALLING>
automáticamente
Si el lenguaje usado para la
implementación no soporta objetos el
Cuenta_impl Implementación mecanismo es diferente.
<implementación>
del objeto
Servicios CORBA
Conjunto de objetos o grupos de objetos, que proporcionan una

serie de funcionalidades elementales. Estos objetos esta
definidos de forma estándar (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 Licencias
• Servicio de Ciclo de Vida • Servicio de Propiedad
• Servicio de Objetos Persistentes • Servicio de Tiempo
• Servicio de Transacciones • Servicio de Seguridad
• Servicio de Control de Concurrencia • Servicio de Negociación
• Servicio de Relación • Servicio de Colección de Objetos
• Servicio de Externalización
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

jerarquía 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

función 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 Negociación
Este servicio también permite obtener referencias a objetos

usando otra información:
– Los objetos se exportan en el servidor con una serie de
características del servicio que proporcionan.
– Los clientes consultan con el servidor cuáles son los objetos
ofertados con una serie de características.
Un cliente que buscase un servicio de impresión podría 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
características.
Comparativa
CORBA vs DCOM+
– CORBA es un estándar abierto y no propietario.
– CORBA proporciona soporte para diversos SO.
– CORBA es más completo y flexible.
– CORBA da una salida a los legacy systems
– DCOM+ esta integrado con la tecnología Microsoft.

– DCOM+ ha tenido una fuerte penetración en el mercado.
Comparativa
CORBA vs RMI
– CORBA permite una mayor heterogeneidad en el desarrollo de
aplicaciones (RMI sólo se puede desarrollar con Java).
– CORBA ademas de las funcionalidades de comunicación,
proporciona servicios.
– RMI funciona sobre CORBA (IIOP).
– RMI es mucho más sencillo y cómodo de usar.

– RMI permite el paso de objetos por valor y por referencia.
Servicios Web
<Web Services>
•SOAP + WSDL + UDDI
Evolución de la Web
• Pasado: Web de documentos
– Páginas estáticas
– Web como un enorme repositorio de información
– Tecnologías: HTTP + HTML
• Presente: Web de aplicaciones
– Páginas dinámicamente generadas por aplicaciones web
– Aplicaciones exportan su interfaz a los usuarios a través de la Web
– Entorno de transacciones comerciales (Business to consumer, B2C)
– Tecnologías: CGI, ASP, PHP, JSP, servlets, ...
• Futuro (ya está aquí): Web de servicios (funciones/métodos)
– “Bibliotecas” ofrecen servicios a programas (no a usuarios)
– Web como una enorme API de servicios (Web de componentes)
– Empresas de valor añadido (Business to business, B2B)
– Base de Sistemas distribuidos sobre Internet
• Servicio web: RPC sobre la Web usando XML
Aplicaciones Web: Escenario Típico
Figura extraída de “Understanding Web Services”: http://www7.software.ibm.com/vad.nsf/Data/Document4362

Servicios Web: Escenario Típico
Figura extraída de “Understanding Web Services”:

http://www7.software.ibm.com/vad.nsf/Data/Document4362
Definición de Servicio Web
• Módulo que exporta un conjunto de funciones (métodos) a
aplicaciones a través de la Web proporcionando
independencia de plataformas hardware/software
• Similar a RPC o RMI pero integrado en la Web
– ¿Reinventando la rueda?  ¿Por qué no usar CORBA?
• Estandarización controlada por un grupo del W3C:
– http://www.w3.org/2002/ws/
• Mismas cuestiones que con RPC/RMI:
– ¿Qué protocolo de transporte se usa?  HTTP
– ¿Qué formato de representación se utiliza?  XML
– ¿Qué protocolo de comunicación se usa?  SOAP
– ¿Cómo se especifican los servicios exportados (IDL)?  WSDL
– ¿Cómo localiza el cliente al servidor (binding)?  UDDI
Protocolo de Transporte: HTTP
• Uso típico de operación POST de HTTP:
– datos de formulario y página de respuesta
POST /~ssoo/consultaBD.cgi HTTP/1.0
Content-length: 76
.....................
DNI=87654321&MAT=980000&Asignatura=sod&Curso=2002&Convocatoria=Jun&Tipo=acta
HTTP/1.1 200 OK
Content-Type: text/html; charset=iso-8859-1
.....................
<HTML>
• Uso de POST para petición y respuesta de RPC

– Universalmente disponible
– Atraviesa el firewall de la organización
Formato de Representación: XML
• Información de RPC codificada en XML

– Muy flexible y potente
– XML Schema permite definir con precisión los tipos de datos
• Ej: float GetLastTradePrice(string symbol);
Petición: Esquema:
<GetLastTradePrice> <element name="GetLastTradePrice">
<symbol>DIS</symbol> <complexType><all>
</GetLastTradePrice> <element name="symbol" type="string"/>
</all></complexType>
</element>
<element name="GetLastTradePriceResponse">
Respuesta: <complexType><all>
<GetLastTradePriceResponse> <element name="Price" type="float"/>
<Price>34.5</Price> </all></complexType>
</GetLastTradePriceResponse> </element>
Protocolo de comunicación: SOAP
• Simple Object Access Protocol (Candidate Recommendation)
• SOAP = HTTP + XML
– Especifica cómo mandar mensajes XML sobre HTTP
– Define el contenedor del mensaje (también en XML)
– Protocolo general, no sólo para RPC, también unidireccional
• Estructura de mensaje contenedor SOAP:
– Sobre (Envelope): Cabecera (Header) [opcional] + Cuerpo (Body)
• Cabecera : info. complementaria (p.ej. en RPC un ID de transacción)
• Cuerpo: contiene el mensaje original
• SOAP para RPC:
– En petición: Identificador en POST identifica destino de RPC
• Seguridad:
– Usando HTTPS (SSL)
– Alternativa actual: WS-Security
Un Ejemplo de SOAP en RPC
POST /StockQuote HTTP/1.1
......................
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
Petición
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:GetLastTradePrice xmlns:m="http://example.com/stockquote.xsd">
<symbol>DIS</symbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
HTTP/1.1 200 OK
...............
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
Respuesta
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Body>
<m:GetLastTradePriceResponse xmlns:m="http://example.com/stockquote.xsd">
<Price>34.5</Price>
</m:GetLastTradePriceResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Definición de Interfaz de Servicio: WSDL
• Web Service Description Language

• IDL para servicios Web basado en XML
• Documento WSDL describe servicio web:
– Tipos de datos (XML Schema)
– Funciones exportadas y sus mensajes de petición y respuesta
– Protocolos usados: típicamente SOAP sobre HTTP
– Dirección de servicio  URL con servidor y “componente”
• P. ej. http://www.stockquoteserver.com/StockQuote
• Normalmente, generado automáticamente a partir de código
de servicios
Desarrollo de un Servicio Web
• Programación de biblioteca de servicio

– En algunos entornos hay que incluir información específica
• En VisualStudio .Net: etiqueta [WebMethod] sobre métodos exportados
• Generación automática de fichero WSDL
– Generalmente, dentro de la generación de aplicación de servicio
• En VisualStudio .Net: Proyecto de tipo Web Service
• En servidor: fichero WSDL informa sobre cómo activar servicio
– Normalmente, lo hace un servidor web con soporte de servicios web
• Desarrollo de cliente:
– Obtener fichero WSDL y generar proxy para aplicación cliente
• En VisualStudio .Net: “Add Web Reference”
Localización del Servicio: UDDI
• Universal Description, Discovery, and Integration
– No estándar: Propuesta inicial de Microsoft, IBM y Ariba
• Registro distribuido de servicios web ofrecidos por empresas
• Información clasificada en 3 categorías (guías):
– Páginas blancas: Datos de la empresa
– Páginas amarillas: Clasificación por tipo de actividades
– Páginas verdes: Descripción de servicios web (WSDL)
• Se accede a su vez como un servicio web
• Puede consultarse en tiempo de desarrollo o incluso
dinámicamente en tiempo de ejecución
• Permite búsquedas por distintos criterios
– Tipo de actividad, tipo de servicio, localización geográfica
Registro de un servicio web
Servicios Web vs. RPC/RMI
• Servicio Web similar a RPC/RMI (CORBA, COM+)
– ¿Hay un “ganador”? ¿Reinventando la rueda?
• Convivencia: Distintos ámbitos de aplicación
• Servicios web
– Entornos de interacción “débilmente acoplados”
• Exportar servicios fuera de la organización
• Integrar aplicaciones de la empresa
– Más estándar y extendido, menos problemas con firewalls
• RPC/RMI “tradicionales”
– Aplicación distribuida “fuertemente acoplada”
– Más funcionalidad y eficiencia
• Ejemplo de escenario de convivencia:
– Exportar un servicio interno CORBA mediante un servicio web
Entornos de Desarrollo de Servicios Web
• Número creciente de entornos de desarrollo

• Algunas implementaciones de interés:
– .Net de Microsoft
– Web Services Project de Apache
– Java Web Services Developer Pack
– IBM WebSphere SDK for Web services (WSDK)
– WASP de Systinet
• Cursos sobre SOAP, WSDL y otras tecnologías web:

– http://www.w3schools.com/

SD S4 ComunicacionProcesos

Cargado por

Copyright:

Formatos disponibles

SD S4 ComunicacionProcesos

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

SD S4 ComunicacionProcesos

Cargado por

Copyright:

Formatos disponibles

Sistemas Distribuidos

Permite la interacción entre aplicaciones y servicios del sistema.

Mecanismos de comunicación entre procesos:

El nivel de abstracción en la comunicación:

Cada una de las funciones de comunicación de una tecnología

Cada una de las primitivas tiene las siguientes características:

Las características de bloqueo son:

Las llamadas no bloqueantes tienen distinto sentido dependiendo

Esta característica afecta no tanto a la primitiva como a la

La comunicación asíncrona usa un buffer de almacenamiento.

El envío fiable de datos garantiza que un mensaje enviado ha

Información válida para la identificación de elementos del

int buscar(int cod)

Remote Procedure Call: RPC. SON BLOQUEANTES Y

Objetivo: acercar la semántica de las llamadas a procedimiento

int buscar(int cod)

Se generan automáticamente por el software de RPC en base a

Se basan en una librería de funciones RPC para las tareas más

Una de las funciones de las interfaces es empaquetar los

Problemas en la representación de los datos

IDL (Interface Definition Language) es un lenguaje de

La comunicación de bajo nivel entre cliente y servidor por medio

Estas tareas las realiza la interfaz cliente.

Enlace dinámico: permite localizar objetos con nombre en un

Como localizar al enlazador dinámico:

“enlaza con cliente servidor

Problemas que pueden plantear las RPC:

• El servidor puede estar caído

• Es la más fácil de tratar.

• El servidor no ha llegado a ejecutar la operación

• La computación está activa pero ningún cliente espera los

Utiliza como lenguaje de definición de interfaz IDL:

• rpcgen es el compilador de interfaces que genera:

• El programador debe proporcionar:

INTERFAZ CABECERA INTERFAZ

ARCHIVOS CABECERA CABECERA

OBJETO FICHEROS ARCHIVOS OBJETO

La extensión de los mecanismos de RPC a una programación

Actualmente existen tres tecnologías de desarrollo de sistemas

El soporte para RMI en Java está basado en las interfaces y

Características de Java RMI:

Localización de objetos remotos:

• Nivel de transporte: se encarga de las comunicaciones y de

Cualquier programa que quiera instanciar un objeto de esta clase

Antes de arrancar el cliente y el servidor, se debe arrancar el

(Object Management Group)

Conjunto de organizaciones que cooperan en la definición de

Fundado en 1989, en la actualidad lo componen más de 700

(Object Management Architecture)

Arquitectura de referencia sobre cual se pueden definir

Formalmente esta dividida en una serie de modelos:

– Los tipos de funciones proporcionados son cuestiones tales como la

– Concede un valor añadido sobre otras tecnologías (por ejemplo RMI).

– Están pensados para grandes sistemas.

– Un ejemplo de este tipo de funciones es el DDCF (Distributed

– (También denominadas Facilidades Horizontales)

– Muchos grupos de interés (SIGs) trabajan sobre estas

– (También denominadas Facilidades Verticales)