SISTEMAS DISTRIBUIDOS

TEMA 2: COMUNICACIN ENTRE PROCESOS Y

OBJETOS DISTRIBUIDOS

DAVID RODRGUEZ HERNNDEZ

FECHA DE REVISIN: 30 Noviembre 2008
ZAMORA (CURSO 2008/2009)
david.rgh@gmail.com

Nota importante:
Este documento no pretende reemplazar al material propuesto por la UNED para la asignatura Sistemas
Distribuidos.
Su finalidad es presentar de una forma esquematizada los contenidos de la asignatura, para facilitar el
estudio de la misma. Es conveniente disponer de la bibliografa propuesta por la Universidad para su
estudio completo.
Cualquier sugerencia, comentario o correccin sobre este documento, envelo a david.rgh@gmail.com
para poder realizar los cambios necesarios.

LAS CARACTERSTICAS DE LA COMUNICACIN ENTRE PROCESOS

El paso de mensajes entre procesos se basa en dos operaciones: enviar y recibir. Es decir, un proceso
emisor enva una secuencia de bytes (mensaje) y un proceso receptor los recibe y lee. Esto requiere a
veces una sincronizacin entre ambos externos.
COMUNICACIN SNCRONA Y ASNCRONA
Los mensajes se almacenan en colas. El emisor deposita el mensaje en la cola remota adecuada y el
receptor lo lee y lo elimina de su cola local. La comunicacin puede ser de dos formas:

Sncrona: El emisor se bloquea hasta el que receptor lea el mensaje. Si el receptor espera un
mensaje, se bloquea hasta recibirlo.

Asncrona: Tan pronto como el mensaje sea escrito en el buffer, el emisor contina su
ejecucin. El receptor puede continuar su ejecucin mientras se llena el buffer, siendo avisado
por separado.

En entornos multihilo, como Java, las llamadas son sncronas pueden utilizarse por un hilo mientras el
resto continan su ejecucin. Las asncronas seran ms eficientes, pero son ms complejas. Los
sistemas actuales no proporcionan la orden recibe asncrona.
DESTINOS DE LOS MENSAJES
Una direccin est constituida por la direccin de Internet y por el puerto local. Un puerto slo tiene un
receptor, pero puede tener varios emisores. Por ejemplo, un servicio web escucha por un puerto
concreto aquello que le envan varios clientes.
Para evitar que un servicio web tenga que estar siempre en la misma ubicacin (por su direccin de
Internet), se suelen usar nombres registrados en un servidor de nombres, que traducen los nombres
a direcciones y que pueden variar en el tiempo. Tambin el SO (ej: Mach) puede asignar identificadores
que pueden variar con el tiempo, manteniendo el mismo de cara al cliente. Tambin puede entregarse
directamente al proceso, como en el sistema V.
Algunos sistemas pueden entregar el mismo mensaje a un grupo de procesos o puertos.
FIABILIDAD
Un servicio de mensajes punto a punto es fiable si se garantiza la entrega aunque se pierdan algunos. Se
considera que tiene integridad si los mensajes no se corrompen ni duplican.
ORDENACIN
Algunas aplicaciones necesitan que los mensajes lleguen en orden. De lo contrario, se considera un fallo.

REPRESENTACIN EXTERNA DE DATOS Y EMPAQUETADO

Cuando se transmite un mensaje, lo hace en forma de secuencia de bytes, independientemente de la
estructura original de los datos. Esta secuencia se reconstruye en el destino. Esto es as porque la
representacin de los datos (incluso los primitivos) puede no ser igual en cada sistema. Adems, el
conjunto de cdigos para representar caracteres tambin puede cambiar.
Para lograr la comunicacin, los valores pueden convertirse a un formato convenido previamente (a no
ser que ambos computadores sean del mismo tipo y conozcan ese hecho). Tambin puede enviarse con
el formato del emisor con una indicacin de ello, para el receptor pueda convertirlos si es necesario.
A este estndar acordado por ambas partes se le llama representacin externa de datos. La
transformacin a esa representacin se llama empaquetado y a la operacin contraria se la llama
desempaquetado.
Para esto tenemos dos alternativas: CORBA, que es una representacin comn de datos; y la
serializacin de objetos Java, que realiza una representacin de cualquier objeto simple o un rbol de
objetos, y que es exclusiva de Java.
Estas operaciones se realizan mediante middleware sin intervencin del programador, ya que acta a
bajo nivel y hacerlo manualmente puede producir fallos. Estas dos alternativas empaquetan los datos en
forma binaria; existe la opcin tambin de transmitirlos en texto ASCII (ms fcil, pero un empaquetado
ms grande), como HTTP.
REPRESENTACIN COMN DE DATOS DE CORBA (CDR)
Consta de 15 tipos primitivos. Algunos ejemplos son short, long, unsigned short, unsigned long, float,
double, char, boolean, octet y any. Adems, tiene un abanico de tipos compuestos (ver figura 4.7 de la
pgina 131 del libro base).
En cuanto a los primitivos, CDR define representacin para el orden big-endian (byte ms significativo el
primero) y para el Little-endian (byte ms significativo el ltimo). El orden lo define el emisor, y el
receptor lo traduce si es necesario (vase el ejemplo mostrado en la pgina 131). La figura 4.8 muestra
un mensaje en CDR CORBA.
Junto a la representacin no se acompaa el tipo correspondiente, ya que se supone que ambos
sistemas tienen conocimiento del orden empleado y los tipos de datos empaquetados. Para RMI o RPC,
cada invocacin tiene unos argumentos concretos y devuelve un tipo concreto.
La interfaz del compilador CORBA genera las operaciones de empaquetado y desempaquetado. Los tipos
de las estructuras de datos y los tipos de los tems de los datos bsicos estn descritos en CORBA IDL.
SERIALIZACIN DE OBJETOS EN JAVA
Para serializar un objeto, ste debe implementar la interfaz Serializable. Serializar consiste en aplanar
un objeto o un conjunto de ellos para tener una forma lineal para transmitir. Deserializar consiste en
restablecer estos objetos a partir de la forma lineal.
El receptor no conoce los tipos de datos que se envan, por lo que se debe incluir informacin de stos
junto al mensaje. Una clase tiene como informacin su nombre y su nmero de versin.
Los objetos Java pueden referenciar a otros, los cuales se serializan con el que los referencia. Estas
referencias se serializan como handlers. Una referencia y un apuntador (handler) deben tener una
relacin de 1:1.

Al serializar un objeto, se escribe la informacin de su clase y los tipos y nombre de sus campos. Si un
campo pertenece a una clase nueva, sta tambin se serializa. Cada clase se escribe slo una vez.
Los datos primitivos se escriben en un formato binario utilizando mtodos de la clase
ObjectOutputStream. Los String y los caracteres se escriben mediante writeUTF. En las pginas 133 y
134 se muestra un ejemplo de serializacin.
Se conoce como reflexin a la habilidad de preguntar sobre las propiedades de una clase. Esto posibilita
la serializacin y deserializacin de una forma genrica, por lo que no se necesitan operaciones
especiales para cada tipo de objeto.
La serializacin usa la reflexin para obtener las propiedades a escribir, y la deserializacin la usa para
crear un constructor para crear una nueva instancia del objeto.
REFERENCIAS A OBJETOS REMOTOS
Un cliente puede enviar un mensaje para invocar un objeto remoto. Se conoce como referencia a objeto
remoto al identificador de este objeto. Estas referencias son nicas en el espacio y en el tiempo. Incluso
cuando un objeto es borrado, su identificador no debe reutilizarse.
Una forma de lograr esta unicidad consiste en concatenar la direccin Internet de su computador, el
nmero de puerto, el instante de creacin y un nmero de objeto local, que va incrementndose cada
vez que se crea un nuevo objeto (ver figura 4.10 de la pgina 135; el ltimo campo contiene informacin
adicional para el receptor del mensaje, como por ejemplo, los mtodos que posee el objeto remoto).
Las referencias de objetos remotos no deberan utilizarse como direccin del objeto; para as permitir su
reubicacin.

COMUNICACIN CLIENTE-SERVIDOR
Generalmente, este tipo de comunicacin es sncrona (el cliente se bloquea hasta que reciba la
respuesta del servidor); pero en algunos casos tambin puede ser asncrona en situaciones donde el
cliente pueda esperar la respuesta para ms tarde.
La Figura 4.11 de la pgina 136 muestra la comunicacin cliente-servidor sobre datagramas (UDP). UDP
evita las sobrecargas que podran darse por streams TCP, ya que no realiza establecimiento de la
conexin ni control de flujo (ste es redundante en envos pequeos, como los argumentos y
resultados). Adems, evita tambin los acuses de recibo, ya que al ser las respuestas seguidas a las
peticiones, son innecesarios.
EL PROTOCOLO PETICIN-RESPUESTA
Est basado en tres primitivas de comunicacin: hazOperacion, damePeticion y enviaRespuesta. A cada
peticin le corresponde una respuesta. Esta respuesta hace las veces de acuse de recibo (recordemos
que UDP no garantiza la entrega del mensaje).
hazOperacion se usa para invocar a las operaciones remotas, indicando en los argumentos el objeto y el
mtodo a invocar, as como la informacin adicional que requiera ese mtodo. Recibe como resultado
una respuesta RMI. Los argumentos son empaquetados en una secuencia de bytes para ser enviados.
Una vez enviada la peticin, hazOperacion llama a recibe, que bloquea al cliente en espera de la
respuesta.
El servidor usa damePeticion para poder atender a las peticiones de los clientes. Una vez recibe una
peticin, ejecuta el mtodo solicitado y llama a enviaRespuesta para enviar el resultado al cliente; el
cual se desbloquea y contina su ejecucin. En la figura 4.13 (pgina 137) puede observarse la
estructura de estos mensajes peticin-respuesta.
Cada mensaje debe tener un identificador nico si el sistema proporciona servicios como la entrega
fiable de mensajes o una comunicacin peticin-respuesta. ste se compone de un identificador de
peticin (idPeticion) y un identificador para el proceso emisor (ej: su puerto y direccin Internet).
Cuando idPeticion llega a su valor mximo, se inicializa a 0, siendo ese tiempo necesario mucho mayor
que el tiempo de vida del identificador.
MODELO DE FALLOS DEL PROTOCOLO PETICIN-RESPUESTA
Si el protocolo se implementa sobre UDP, tendr sus mismos fallos (ej: no se garantiza la entrega).
hazOperacion utiliza un timeout para el caso de que un servidor falle o se elimine un mensaje de
peticin o respuesta.

Tiempos de espera lmite: Cuando se supera un timeout, se pueden tomar varias decisiones:
devolver el control al cliente con un error, reenviar las peticiones hasta recibir respuesta (o
hasta sospechar que el servidor no recibe las comunicaciones)

Eliminacin de mensajes de peticin duplicados: Un servidor puede recibir la peticin, pero

tardar en responder. Esto generara un reenvo de la peticin. El servidor reconocer que el
identificador de la peticin es duplicado y eliminar los que lleguen a posteriori.

Prdida de mensajes de respuesta: Si el servidor recibe un reenvo de peticin cuando ya ha

enviado la respuesta, corre el riesgo de que se vuelva a ejecutar. Si las operaciones en cuestin

no son idempotentes (es decir, cada sucesiva ejecucin tiene un resultado distinto), debe
tomar medidas.

Historial: Si las operaciones no son idempotentes, se debe almacenar un historial con los
resultados obtenidos, para poder reenviarlos sin volver a ejecutar la operacin. Este historial es
un registro de los mensajes de respuesta enviados. Supone un coste de almacenamiento. Como
el cliente se bloquea hasta recibir respuesta, un servidor slo necesitar almacenar una
respuesta por cliente (ya que la siguiente peticin sirve de acuse de recibo de la respuesta
anterior).

Protocolo de intercambio de RPC: Se utilizan 3 protocolos: el protocolo peticin (R), el

protocolo peticin-respuesta (RR) y el protocolo peticin-respuesta-confirmacin de la
respuesta (RRA) (Figura 4.14, Pgina 139).
El primero se usa cuando el servidor no tiene que responder nada (el cliente contina su
ejecucin sin esperar respuesta), el segundo se basa en el protocolo peticin-respuesta y, como
ya vimos antes, no necesitan acuse de recibo; y el tercero se basa en el intercambio de 3
mensajes: el cliente enva un acuse de recibo, que permite al servidor descartar mensajes del
historial; adems, un acuse sirve como reconocimiento de todos los idPeticion menores que el
suyo (el cliente, adems, no necesita bloquearse).

UTILIZACIN DE STREAMS TCP PARA IMPLEMENTAR EL PROTOCOLO PETICIN-RESPUESTA

Con esta implementacin se evita la implementacin de protocolos multi-paquete, lo que permite el
envo de argumentos y resultados de cualquier tamao. Un ejemplo es la serializacin de Java.
TCP asegura la entrega fiable y ordenada de los mensajes. Tambin proporciona control de flujo, por lo
que el servidor no tiene que tomar medidas especiales para evitar desbordamientos en la comunicacin.
Si hay peticiones sucesivas entre el mismo par cliente-servidor, no se sobrecarga la comunicacin con
repetidos establecimientos de conexin.
A veces se utilizar UDP, en los casos en que no se requieran las propiedades de TCP (ej: Sun NFS).
HTTP: UN EJEMPLO DE PROTOCOLO PETICIN-RESPUESTA
Lo usan los navegadores web para realizar peticiones a los servidores web y recibir su respuesta. Estas
peticiones indican un URL que incluye el nombre DNS del host, el identificador del recurso pedido y,
opcionalmente, el puerto.
Aqu, cada objeto tiene sus propios mtodos. Adems, este protocolo permite la negociacin de
contenidos (las peticiones pueden especificar las representaciones que pueden aceptan) y una
autenticacin (credenciales y desafos para lograr una autenticacin tipo clave de acceso).
Est implementado sobre TCP. Antiguamente, cada peticin abra una conexin nica y exclusiva (un
solo documento puede contener varias peticiones, una por recurso). Pero con la aparicin de HTTP 1.1,
se crearon conexiones persistentes; es decir, conexiones que permanecen abiertas hasta que finalice los
intercambios entre el cliente y servidor.
Las peticiones y respuestas se empaquetan como cadenas de caracteres ASCII. Esto proporciona una
mayor simplicidad a los programadores que trabajen con este protocolo.

Los recursos considerados como datos se envan en forma de estructura MIME (Multipurpose Internet
Mail Extensions), que permite enviar emails compuestos por varias partes de contenidos a la vez. El
receptor sabr cmo procesar los datos en funcin de las cabeceras MIME (tipo+subtipo).
HTTP tiene los siguientes mtodos:

GET: Solicita un recurso. Pueden ser datos (se envan como respuesta) o un programa (se
ejecuta y enva el resultado). Se pueden aadir parmetros al URL. Esta operacin puede
condicionarse a la fecha de modificacin del recurso en cuestin.

HEAD: Parecida a GET, pero no devuelve datos. Slo devuelve la informacin sobre esos datos
(fecha de modificacin, tipo, tamao).

POST: El recurso referenciado puede tratar los datos aportados con la peticin. Puede enviar
un bloque de datos a un proceso, enviar un mensaje a un tabln de anuncios (por ejemplo) o
modificar una BBDD aadiendo un registro.

PUT: Los datos aportados se almacenan con la URL como su identificador. Puede ser una
creacin o una modificacin de datos.

DELETE: Se borra el recurso referenciado.

OPTIONS: Devuelve las operaciones aplicables al URL (como las anteriores) y sus requisitos.

TRACE: Devuelve el propio mensaje de peticin. Se usa para depuracin.

La estructura de una peticin HTTP se muestra en la figura 4.15 (pgina 142) y la de una respuesta HTTP
en la figura 4.16 (pgina 143). Vase que algunos campos no siempre son necesarios (por ejemplo, el
cuerpo del mensaje de una peticin HTTP es intil en una operacin GET; pero necesaria en una
operacin POST).

COMUNICACIN EN GRUPO
Para la comunicacin entre un proceso y un grupo de procesos es preferible utilizar una operacin de
multidifusin (enviar un nico mensaje que se transmitir a todo un grupo de procesos). La
infraestructura proporcionada por estas operaciones tiene las siguientes caractersticas:

Tolerancia a fallos basada en servicios replicados: Estos servicios constan de un grupo de

servidores. Una solicitud se dirige a todos ellos y todos hacen la misma operacin. Proporciona
seguridad frente a cadas de un servidor.

Bsqueda de los servidores de descubrimiento en redes espontneas: Los mensajes de

multidifusin pueden utilizarse para descubrir los servicios disponibles en una red y registrar
sus interfaces.

Mejores prestaciones basada en datos replicados:

servidores mejora las prestaciones a los clientes.

Propagacin de las notificaciones de eventos: La multidifusin puede usarse para notificar al

resto de equipos de lo que sucede (ej: descubrir un nuevo servicio).

La rplica de los datos en diferentes

MULTIDIFUSIN IP: UNA IMPLEMENTACIN DE LA COMUNICACIN EN GRUPO

Un emisor puede difundir un mensaje a todos los miembros de un grupo de multidifusin, sin necesidad
de que conozca las identidades de estos miembros. Estos grupos se especifican mediante direcciones
Internet de clase D. No es necesario pertenecer a un grupo de multidifusin para enviar mensajes a l.
A nivel de aplicacin, la multidifusin est slo disponible a travs de UDP. En el nivel IP, un computador
pertenece a un grupo de multidifusin cuando uno o ms de sus procesos tienen conectores que
pertenezcan a dicho grupo (al llegar un mensaje, se envan copias a los conectores locales que
pertenecen a la direccin de multidifusin destino del mensaje). Veamos algunos detalles de IPv4:

Routers multidifusin: Estos routers pueden reenviar los datagramas nicamente a otros
routers de redes con miembros del grupo en cuestin. Puede limitarse estableciendo un valor
de TTL (tiempo de vida), que indica el n de routers que puede cruzar.

Reserva de direcciones de multidifusin:

stas pueden reservarse temporal o
permanentemente. Existe un rango permanente (an cuando no tengan miembros): de
224.0.0.1 a 224.0.0.255. El resto de direcciones pueden usarlo grupos temporales, que deben
crearse antes de su uso. Cuando la comunicacin es a nivel local, se pone un bajo TTL, para
evitar conflictos con otros grupos. Cuando es a nivel de Internet, se requiere un mayor control:
el programa de directorio de sesiones permite a los usuarios detectar las sesiones
multidifusin existentes y anunciar la suya propia (indicando el tiempo y direccin de la
reserva).

La multidifusin de datagramas tiene los mismos problemas de fallos que UDP (fallos de omisin). No se
garantiza la entrega a cualquier miembro particular. Esto se conoce como multidifusin no fiable.
Existe una API Java para la multidifusin IP, que proporciona una interfaz de datagramas a travs de la
clase MulticastSocket (subclase de DatagramSocket). Tiene dos constructores, que permiten crear un
conector a un puerto concreto o a cualquier puerto local libre. El mtodo JoinGroup permite a un
proceso pasar a pertenecer a un grupo de multidifusin. Puede dejar de pertenecer a l mediante
leaveGroup.

Puede verse un ejemplo de esta API en la Figura 4.17 de la pgina 145 (explicacin en pginas 145-146).
FIABILIDAD Y ORDEN EN MULTIDIFUSIN
En una transmisin de multidifusin, cualquier receptor podra perder un paquete al encontrarse lleno
su buffer. Tambin puede perderse al enviar a otro router (lo que implica una prdida para todos los
destinos del otro lado del router).
Adems, los paquetes pueden no llegar en el orden correcto a los destinos.
Vase en las pginas 146 y 147 algunos ejemplos de los efectos de estos fallos.
Es evidente que algunas aplicaciones necesitan un protocolo de multidifusin ms fiable que la
multidifusin IP. Esto es, requieren la multidifusin fiable (puede consultarse informacin sobre ella en
el apartado 11.4 (capitulo 11) del libro base). Puede requerirse an algo ms estricto: la multidifusin
totalmente ordenada.
SOCKETS
Un socket es un conector de un proceso por el que se puede comunicar con otros procesos (algo as
como una puerta).
Un socket en un proceso receptor debe asociarse a un puerto local y a una direccin Internet. Todo
mensaje enviado a dicha direccin y puerto lo recibir slo ese socket. El mismo socket puede ser usado
para el envo y la recepcin. Un computador permite 2^16 sockets. Cada conector se asocia a UDP o a
TCP.
Java proporciona InetAddress para representar las direcciones Internet. A esta clase puede invocarse
con un nombre DNS, el cual se traduce.
COMUNICACIN DE DATAGRAMAS UDP
Recordemos que UDP no implica acuses de recibo ni reintentos. El proceso que deba comunicarse crea
un socket asociado a un puerto y una direccin internet (un servidor lo liga a un puerto conocido por los
clientes (puerto de servidor) y un cliente a cualquier puerto local libre). Veamos algunos aspectos sobre
los datagramas:

Tamao del mensaje: Si el mensaje es demasiado grande para el receptor, se truncar. La

capa IP permite paquetes de 2^16 bytes, aunque la mayora de entornos lo limitan a 8 KB. Si
una aplicacin necesita tamaos mayores, debe fragmentarlo.

Bloqueo: En UDP, las operaciones enviar son no bloqueantes, y las recibir son bloqueantes. El
mensaje almacenado en el buffer podr ser recuperado con una invocacin recibir pendiente o
futura. El mensaje se descarta si no hay ningn proceso ligado al conector. El servidor puede
establecer un timeout para limitar el bloqueo de recibe. Cualquier proceso que deba hacer (por
ejemplo, por una recepcin anterior de instrucciones) debe realizarse en un hilo separado.

Tiempo lmite de espera: El timeout debe ser lo suficientemente grande respecto al tiempo de
transmisin de un mensaje.

Recibe de cualquiera: recibe no especifica ningn origen de los envos. El mensaje recibido
incluye informacin del emisor. Sin embargo, se puede vincular un socket con un puerto y
direccin remotas, por lo que slo recibir de dicho origen.

UDP adolece de dos puntos dbiles: en primer lugar, un mensaje puede desecharse ocasionalmente (ej:
no queda espacio en algn buffer). En segundo lugar, los mensajes pueden llegar al destino
desordenados.
Las aplicaciones que usan UDP deben disponer de sus propias medidas para comprobar y corregir estos
fallos.
Algunas aplicaciones pueden tolerar estos fallos ocasionales (como el DNS), por lo que se implementan
sobre UDP. As, se evitan las sobrecargas que padecen las entregas garantizadas, como el
almacenamiento de la informacin de estado en el origen y en el destino, la transmisin de mensajes
extra, y la latencia para el emisor.
Java proporciona dos clases para la comunicacin por datagramas: DatagramPacket y DatagramSocket.
El primero proporciona un constructor que crea una instancia compuesta por una cadena de bytes que
almacena el mensaje, su longitud y los datos del origen (direccin y puerto) (Pgina 123). Asimismo,
proporciona otro constructor para los mensajes recibidos (se recupera el mensaje mediante getData y
los datos de origen mediante getPort y getAddress). El segundo maneja conectores para el envo y
recepcin. Su constructor permite elegir un puerto o que se elija uno libre cualquiera. Tiene varios
mtodos, como send, receive, setSoTimeout (establecer tiempo de espera) o connect (conectarse con un
puerto y direccin remotos, con lo que slo puede enviar y recibir de ese). Vase la figura 4.3 y la figura
4.4 de las pginas 124 y 125.
COMUNICACIN DE STREAMS TCP
Consiste en un flujo de bytes (stream) sobre el que se pueden escribir y leer datos. Tenemos las
siguientes caractersticas:

Tamao de los mensajes:

Puede ser un conjunto pequeo o grande de datos. La
implementacin de TCP decide cuntos datos recoge antes de transmitirlos. El receptor los va
leyendo segn los solicita. La aplicacin puede forzar el envo inmediato.

Mensajes perdidos: Tiene un sistema de acuses de recibo. El emisor registra lo que enva y el
receptor enva un acuse de recibo de todos los paquetes que le llegan. Si el emisor no recibe el
acuse en un tiempo determinado, reenviar el paquete. El uso de desplazamiento de ventana
reduce el n de reenvos.

Control del flujo:

sincronizacin.

Duplicacin y ordenacin de los mensajes: Cada paquete tiene un identificador, que permite
al receptor detectar duplicados y reordenar paquetes.

Destinos de los mensajes: Entre los dos procesos se establece una conexin previa para luego
no tener que preocuparse de las direcciones y puertos. El establecimiento implica el acuerdo
en tres fases, que puede suponer una sobrecarga. El cliente toma la iniciativa para el
establecimiento.

Ajusta las velocidades de lectura y escritura en el stream para mejorar la

El par de conectores se conectan por dos streams, uno para cada sentido. Al cerrar uno de los
conectores, su buffer de salida se enva al otro proceso junto con una indicacin de dicho cierre.
Veamos algunos de los aspectos de estos streams:

Concordancia de tems de datos: Los dos procesos han de estar de acuerdo en el tipo de datos
transmitidos.

Bloqueo: Cuando se escriben datos en el stream, se almacenan en el buffer de entrada del

destino. El receptor los lee o, si no hay datos, se bloquea hasta recibir alguno. Si no hay espacio
en el destino, el emisor se bloquea hasta que pueda enviar todo.

Hilos: Al aceptar el servidor una conexin, crea un nuevo hilo para la comunicacin. Eso
permite que vuelva a la espera de nuevas peticiones mientras atiende al cliente anterior. Si el
entorno no acepta hilos, se puede comprobar si hay datos antes de intentar leer el buffer (ej:
en UNIX es con el comando select).

Se utiliza una suma de comprobacin para cumplir con la propiedad de integridad. Adems, se usan
nmeros de secuencia para detectar duplicados. Respecto a la validez, se utilizan timeouts y la
retransmisin de paquetes perdidos.
Si la tasa de prdidas es demasiado elevada o la red est congestionada, el sistema TCP declara la
conexin rota. En ese caso, se notifica al proceso que utiliza la conexin cuando intente leer o escribir.
Es decir, los procesos no distinguen entre un fallo en la red y uno en el proceso del otro extremo.
Adems, los procesos no saben si sus mensajes recientes se han recibido o no.
Es as que TCP no proporciona comunicacin fiable (no garantiza la entrega si hay problemas).
Algunos ejemplos de procesos funcionando bajo TCP son HTTP, FTP, SMTP y Telnet.
Java proporciona dos clases para esta comunicacin:
ServerSocket: Se usa para crear un conector en el puerto de servidor que escucha y espera
peticiones. Recibe una peticin connect y ejecuta accept que crea una instancia de Socket.
Socket: La utilizan los procesos de la conexin. Su constructor recibe el nombre DNS de host y
el puerto de servidor. Crea el conector asociado con el puerto local y se conecta con el conector
remoto. Proporciona los mtodos getInputstream y getOutputStream para acceder a los
streams. Vase el ejemplo de la Figura 4.5 en la pgina 128.

LLAMADA A UN PROCEDIMIENTO REMOTO

El cliente llama a un procedimiento de un proceso servidor. Se pueden crear cadenas de RPC, ya que un
servidor puede ser cliente de otro. Suele implementarse sobre un protocolo de peticin-respuesta.
En la figura 5.7 (pgina 173) puede verse el software que soporta RPC. El cliente dispone de un
procedimiento de resguardo para cada procedimiento en la interfaz del servicio. Esto sirve para
empaquetar el identificador del procedimiento y los argumentos en un mensaje de peticin, que se
enva mediante el mdulo de comunicacin.
A su vez, el servidor tiene un distribuidor, que se encarga de seleccionar uno de los procedimientos de
resguardo del servidor, que desempaqueta los argumentos y llama al procedimiento invocado. Adems,
se encarga de empaquetar los datos del resultado para crear el mensaje de respuesta. Tambin dispone
de procedimientos de servicio, que se encargan de implementar los procedimientos de interfaz del
servicio.
CASO DE ESTIDIO SUN RPC
Puede realizar llamadas a procedimientos remotos tanto sobre UDP como sobre TCP. Sobre UDP, el
lmite de mensajes es de 64 KB, aunque es comn encontrar lmites reales de 8 9 KB. Tambin existe la
posibilidad de difusin de RPC.

Lenguaje de definicin de interfaz: Es el lenguaje Sun XDR, que se puede usar para definir una
interfaz de servicio para Sun RPC, con una notacin bastante primitiva: no puede especificar
nombres de interfaces, sino que hay que indicar un nmero de programa y de versin. Esos dos
datos se envan en el mensaje de peticin. Slo permite un parmetro de entrada y los
parmetros de salida se devuelven como un solo resultado. La definicin de procedimiento
indica una firma (tipo de resultado, nombre del procedimiento y tipo de parmetro de entrada)
y un nmero de procedimiento. Vase un ejemplo en la pgina 174.

Enlazado:
Sun RPC dispone de un enlazador de puertos, que almacena el nmero de
programa, el nmero de versin y el nmero de puerto en uso por cada servicio que se ejecuta
localmente. Al arrancar un servidor, se registran sus datos en el enlazador. Al arrancar un
cliente, consulta al enlazador para averiguar el puerto del procedimiento pedido. Si un proceso
atiende por varios puertos y se necesita enviar un mensaje a todos, se utiliza multidifusin de
RPC mediante una difusin a todos los enlazadores de puertos, indicando el procedimiento
deseado.

Autenticacin: Los mensajes de Sun RPC tienen campos extra que permiten llevar informacin
de autenticacin. El programa servidor es el responsable del control de acceso en base a estos
campos. Un campo de la cabecera RPC indica el protocolo de autentificacin usado (por uid y
gid, por clave compartida, por el sistema de Kerberos).

OBJETOS DISTRIBUIDOS
Se han extendido algunos modelos de programacin conocidos para que sean de aplicacin a los
programas distribuidos. Por ejemplo:

Se extendi el modelo de llamada a procedimiento convencional a llamada a procedimiento

remoto (RPC).

El modelo de programacin orientada a objetos (POO) se extendi para permitir la invocacin a

un mtodo remoto (RMI).

Se extendi el modelo de programacin orientada a eventos para permitir escribir programas

distribuidos basados en eventos (recurdese que este modelo permite que un objeto reciba
notificaciones de los eventos en otros objetos en los que tenga inters).

Usaremos el trmino RMI de forma genrica para las invocaciones a mtodos remotos (no confundir con
el API Java RMI).
MIDDLEWARE
Se conoce como middleware al software que proporciona un modelo de programacin sobre bloques
bsicos arquitectnicos. Proporciona transparencia de ubicacin e independiencia de los detalles de los
protocolos de comunicacin, los SSOO y el hardware de los computadores. Veamos sus caractersticas:

Transparencia frente a ubicacin: Tanto en RPC como en RMI, el proceso que hace la
invocacin no sabe si el procedimiento o mtodo pertenece al mismo proceso o a otro, dnde
est o si es local o remoto. En los modelos basados en eventos, los objetos no necesitan saber
dnde est el que ha generado el evento.

Protocolos de comunicacin:
Los protocolos de las abstracciones del middleware son
independientes de los de transporte.

Hardware de los computadores: Ya vimos dos estndares comunes para el empaquetado y

desempaquetado (serializacin y CORBA).

SSOO: Las abstracciones de mayor nivel del middleware son independientes del SSOO.

Utilizacin de diversos lenguajes de programacin: Las aplicaciones distribuidas deberan

poder escribirse en ms de un lenguaje de programacin, sin necesidad de que un extremo
conozca el lenguaje del otro extremo.

INTERFACES
Una interfaz sirve para controlar las interacciones posibles entre los mdulos de un programa. Los
mdulos ocultan su informacin, exceptuando sus interfaces. As, se puede cambiar la implementacin
siempre que no se cambie la interfaz.
En los sistemas distribudos, un mdulo no puede acceder directamente a las variables de otro; en todo
caso, lo har a travs de los mtodos de sus interfaces.
En las llamadas a procesos remotos, no es conveniente usar los mecanismos de paso de parmetros que
se usan para procedimientos locales. La especificacin de un mtodo o procedimiento remoto describe
los parmetros como de entrada (mediante el envo de los valores en el mensaje de peticin), de salida
(se envan en el mensaje de respuesta) o ambos.

Es imporante notar que los punteros de un proceso no son vlidos en un proceso remoto.
Las interfaces de servicio son las especificaciones de los procedimientos que ofrece un servidor,
definiendo los argumentos de entrada y salida de los mismos.
Las interfaces remotas especifican los mtodos de un objeto disponibles para su invocacin por objetos
de otros procesos. Aqu se pueden pasar objetos y referencias a ellos (no confundir con punteros) como
argumentos o como resultado.
LENGUAJES DE DEFINICIN DE INTERFACES
Se puede integrar un mecanismo RMI con un lenguaje que proporcione una notacin para definir
interfaces (ej: Java con Java RMI). Un servicio no tiene que estar escrito todo en el mismo lenguaje;
puede estar una parte, por ejemplo, escrita en C++ y las dems en otros lenguajes.
Los IDL estn diseados para que puedan invocarse objetos en distintos lenguajes de programacin.
Puede verse un ejemplo en la figura 5.2 (Pgina 159) de CORBA IDL. En l se puede ver cmo se define
una interfaz que describe los mtodos aadePersona, damePersona con sus atributos y tipos (vase que
uno de los tipos es una estructura definida previamente).

COMUNICACIN ENTRE OBJETOS DISTRIBUIDOS

EL MODELO DE OBJETOS
Los programas orientados a objetos se componen de un conjunto de objetos que interactan entre ellos
a travs de invocaciones a sus mtodos. Aunque algunos lenguajes (Java, C++) permiten programarlos
de forma que sus variables sean directamente accesibles, en los sistemas distribuidos deben serlo slo a
travs de sus mtodos.

Referencias a objetos: Pueden accederse a objetos a travs de referencias (aparentemente

contiene el objeto, pero slo se hace referencia a l). Se invoca mediante el nombre de la
referencia y el mtodo a invocar.

Interfaces: Proporciona la definicin de las firmas de un conjunto de mtodos sin especificar

su implementacin. Tambin puede usarse para declarar el tipo de las variables o parmetros y
los valores devueltos de los mtodos.

Acciones: El receptor que recibe una invocacin, ejecuta el mtodo invocado y devuelve el
control al objeto que lo invoca (incluyendo a veces un resultado). Una invocacin puede
cambiar el estado del receptor o dar lugar a nuevas invocaciones de mtodos de otros objetos.
Una accin es una cadena de invocaciones.

Excepciones: Sirven para tratar errores producidos con limpieza en el cdigo. Adems, puede
especificarse el tipo de excepciones que se pueden capturar (pasa el control a un bloque catch
que realiza el tratamiento). Tngase en cuenta que el control NO vuelve al lugar donde se lanz
la excepcin.

Compactacin automtica de la memoria: Hay que tener en cuenta que un objeto que ya no
se usa debe liberar la memoria que ocupaba. Algunos lenguajes pueden reconocer esto
automticamente (por ejemplo, Java).

OBJETOS DISTRIBUIDOS
En la programacin orientada a objetos, el estado de un programa est dividido por sus objetos. En los
sistemas distribuidos, puede darse la arquitectura cliente-servidor; en cuyo caso, los objetos estn
gestionados por el servidor y los clientes invocan sus mtodos mediante RMI. Los objetos de los
servidores pueden ser a su vez clientes de otros objetos.
Esta distribucin favorece la encapsulacin. Para acceder al estado de un objeto, hay que pasar por sus
mtodos. Esto permite la implementacin de mtodos que protejan de accesos no autorizados. Adems,
por ello se pueden usar diferentes formatos de datos en diferentes lugares.
EL MODELO DE OBJETOS DISTRIBUIDO
Algunos objetos pueden ser invocados de forma remota (procesos distintos, ya sea en el mismo
computador o no; invocaciones de mtodos remotas), y otros slo de forma local (invocaciones de
mtodos locales) (vase figura 5.3 (pgina 162)).
Se puede invocar un objeto remoto si se tiene acceso a su referencia de objeto remoto. Cada objeto
remoto tiene una interfaz remota que especifica los mtodos que pueden invocarse remotamente.

Referencias a objetos remotos: Es un identificador que se usa para referirse de forma nica a
un objeto remoto concreto. Pueden usarse como argumentos y resultados de invocaciones.

Interfaces remotas:
Ya habamos visto antes un ejemplo de interfaz en CORBA y ya
comentamos lo que era. Se definen mediante lenguajes de definicin de interfaces (IDL).

Acciones de un sistema de objetos distribuido: Es similar a las acciones que se describieron

antes, pero con la diferencia que cada eslabn de la cadena de invocaciones puede estar en
distintas ubicaciones (procesos o computadores). Para realizar una invocacin remota, se
necesita una referencia a objeto remoto del objeto destino.

Compactacin automtica de memoria en un sistema de objetos distribuido: Se logra

mediante la cooperacin entre el compactador automtico de memoria local y un mdulo
adicional que realiza una forma de compactacin automtica de memoria basada
generalmente en una cuenta de referencias.

Excepciones:
timeouts.

Una invocacin a un mtodo remoto debe poder lanzar excepciones como

CUESTIONES DE DISEO PARA RMI

Semntica de la invocacin RMI: Ya vimos que hazOperacion se poda implementar de

distintas formas, como reintentar el envo del mensaje de peticin durante un tiempo
prudencial, filtrar las peticiones duplicadas en el servidor o la retransmisin de resultados. Se
pueden combinar para obtener distintas semnticas.
Tenemos tambin la semntica de invocacin pudiera ser, en el que invoca no puede decir si
un mtodo se ha ejecutado una vez o ninguna. Esta semntica aparece cuando no se aplica
ninguna medida de tolerancia de fallos. Pueden ocurrir fallos de omisin y fallos por cada si el
servidor del objeto remoto falla. Con esta semntica se asume que es aceptable que haya
invocaciones fallidas. Sun RPC proporciona esta semntica.
Otra semntica es al menos una vez. Si el invocante recibe respuesta, sabr que se habr
ejecutado el mtodo al menos una vez. Cubre los fallos de omisin mediante el reenvo de
peticiones. Sin embargo, adolece de fallos por cada del servidor o por fallos arbitrarios (ej: ms
de una ejecucin por la retransmisin provocando resultados errneos; slo las operaciones
idempotentes se vern libres de este fallo). CORBA permite esta semntica para mtodos que
no devuelven resultados.
Otra semntica es como mximo una vez. El invocante recibe una respuesta o una excepcin,
con lo que sabr si se ha ejecutado exactamente una vez o ninguna. Se enmascaran los fallos de
omisin mediante reintentos. Sus medidas adicionales de tolerancia frente a fallos previenen
los fallos arbitrarios (asegura que para cada RMI no se ejecuta el mtodo ms que una vez).
Java RMI y CORBA contemplan esta semntica.

Transparencia: Es preferible que el invocante no deba distinguir entre una invocacin remota
y una invocacin local. Se oculta el empaquetado, el paso de mensajes y la tarea de ubicacin y
contacto con el objeto remoto (ej: Java RMI utiliza la misma sintaxis para invocaciones remotas
y locales). Pero adems, los objetos que realizan invocaciones remotas deben ser capaces de
recuperarse de fallos nuevos, cuya posibilidad es inevitable al tener una red y otro computador
de por medio. Adems, debe tener en cuenta la latencia. Los diseadores de un IDL pueden
elegir si las invocaciones remotas deben ser transparentes. El consenso actual es que las
invocaciones remotas sean transparentes (es decir, debe tener la misma sintaxis; mientras que
la diferencia se indicar en las interfaces remotas (ej: en Java RMI, se diferencian porque
implementan la interfaz Remote y lanzan RemoteExceptions)).

IMPLEMENTACIN DE RMI
En la figura 5.6 (pgina 166) pueden verse los objetos implicados en una invocacin de mtodo remoto:

Mdulo de comunicacin: Proporciona una semntica de invocacin (ej: como mximo una
vez). En el servidor, selecciona el distribuidor para la clase del objeto que se invoca, pasando su
referencia local.

Mdulo de referencia remota: Traduce las referencias entre objetos locales y remotos. El
mdulo de cada proceso tiene una tabla de objetos remotos con la correspondencia entre estas
referencias. Si se pasa un objeto remoto por primera vez (ya sea argumento o resultado), este
mdulo crea una referencia a un objeto remoto (se aade a su tabla). Si se pasa una referencia,
se le pide a este mdulo que indique la referencia local correspondiente (si no existe, se crea
un nuevo proxy que se aade a la tabla).

El software de RMI: Es una capa de software entre los objetos del nivel de aplicacin y los
mdulos de comunicacin y de referencia remota. Veamos los papeles de los objetos de
middleware:
o

Proxy: hace que la invocacin sea transparente para los clientes. Aparenta ser el
objeto invocado, pero en realidad redirige la peticin. Hay uno por cada objeto remoto
del que se tenga referencia y oculta los detalles de la referencia remota, el
empaquetado y desempaquetado y el envo y recepcin desde el cliente. Es decir,
hace de intermediario.

Distribuidor: Recibe el mensaje desde el mdulo de comunicacin y, en base a

idMetodo, selecciona el mtodo apropiado para pasarle la peticin.

Esqueleto: Implementa los mtodos de la interfaz remota. Desempaqueta la peticin

e invoca al objeto correspondiente. Luego empaqueta el resultado en un mensaje de
respuesta para el mtodo de envo del proxy.

Generacin de las clases para cada proxy, distribuidor y esqueleto:

automticamente mediante un compilador de interfaces.

Programas cliente y servidor: El programa servidor tiene las clases para los distribuidores y
esqueletos y las implementaciones de las clases de todos los objetos remotos a que da soporte
(clases servidoras). Contiene tambin una seccin de inicializacin, que crea e inicia al menos
un objeto remoto. El programa cliente contiene las clases de cada proxy para todos los objetos
remotos que invoque. Los objetos remotos se crean en la inicializacin o en mtodos diseados
para ello (mtodos factora).

El enlazador: Es un servicio separado que da soporte a una tabla de relaciones entre nombres
textuales y referencias a objetos remotos. En ella se registran los objetos remotos de un
servidor mediante su nombre y permite bsquedas por parte de los clientes.

Hilos del servidor: Si una invocacin implica otra, se crean hilos para que el servidor no quede
bloqueado a la espera del resultado de la nueva invocacin.

Activacin de objetos remotos: Algunos objetos pueden contener informacin requerida en

un largo periodo de tiempo; pero sera un gasto intil de recursos mantener en ejecucin el
objeto todo ese tiempo. Un objeto pasivo o inactivo consta de la implementacin de sus
mtodos y de su estado en forma empaquetada. La activacin es la creacin de un objeto

Se generan

activo desde el pasivo correspondiente (se crea una instancia y se inicializa segn el estado del
pasivo). El activador debe registrar los objetos pasivos disponibles, arrancar procesos de
servicio con nombre y activar sus objetos remotos y mantener la pista de las ubicaciones de los
servidores de objetos remotos ya activados.

Almacenes de objetos persistentes: Un objeto persistente es aquel cuya vida se garantiza

entre procesos de activacin. Suelen gestionarse por los almacenes de objetos persistentes (se
guarda su estado empaquetado en el disco). La activacin es transparente (el invocador no
sabe si el objeto estaba en memoria o tuvo que ser activado). Se requiere una estrategia para
decidir cunto desactivar los objetos que no se necesiten en memoria (por peticin, por
finalizacin). Estos almacenes mantienen algunas races persistentes: cualquier objeto
alcanzable por ellas se define para ser persistente. Tambin proporciona algunas clases sobre
las que se basa la persistencia.

Ubicacin de objetos: Ya habamos visto que un objeto puede localizarse mediante su

direccin Internet y el puerto; pero eso lo limita a una ubicacin concreta. Si el objeto se
reubica en otra localizacin, esta direccin ya no es vlida.
Se conoce como servicio de localizacin al servicio que ayuda a los clientes a localizar un objeto
remoto a partir de su referencia. Para ello, tiene una BBDD que relaciona las referencias con sus
posibles situaciones actuales. Por ejemplo, el sistema Clouds tiene una cache en cada
computador con estas relaciones. Si el objeto no est en uno concreto, la llamada a su cach
fallar y se difundir una peticin para localizar el objeto.

COMPACTACIN AUTOMTICA DE MEMORIA

Se asegura de que cuando nadie haga referencia a un objeto, ste se borre. El compactador automtico
de memoria distribuido coopera con el compactador automtico de memoria local. Puede verse cmo
realiza esta cooperacin en la pgina 171. Se basa principalmente en que un servidor mantiene un
conjunto de procesos que guardan referencias a objetos remotos para cada uno de sus propios objetos
remotos. Si un cliente detecta que no puede acceder ya al proxy del objeto remoto, invoca al servidor
para que destruya el proxy y elimine al cliente de la lista de procesos.
Por otra parte, el sistema distribuido Jini mantiene un sistema de concesiones. Es decir, se cede un
recurso durante un periodo de tiempo llamado concesin, que puede ser negociable entre el que cede y
el que recibe la cesin. Pasado este tiempo, el recurso se elimina. De esta forma, se evita el riesgo de
tener que mantener un recurso aunque ningn objeto haga uso de l. El objeto que representa la
concesin implementa la interfaz Lease.

EVENTOS Y NOTIFICACIONES
En las aplicaciones interactivas, una accin que realice el usuario sobre un objeto se conoce como
evento. ste genera una notificacin hacia otros objetos.
Se utiliza el paradigma publica-suscribe; es decir, un objeto publica los tipos de eventos que pueden
notificar y los objetos interesados se suscriben a dichas notificaciones. Los eventos se representan por
unos objetos llamados notificaciones o anuncios. Estas notificaciones pueden almacenarse, enviarse,
consultarse cuando se genera un evento, los objetos suscritos a l reciben una notificacin.
El hecho de suscribirse se llama registrar el inters por ese tipo de evento.
Tenemos dos caractersticas importantes para los sistemas basados en eventos:

Heterogneos: Gracias a las notificaciones; dos componentes, que en principio no pueden

interoperar entre ellos, podrn comunicarse. Slo se necesita que los objetos que generan
eventos publiquen los tipos de eventos y que los que se suscriban, indiquen su interfaz para
poder recibir las notificaciones.

Asncronos:
El envo de las notificaciones es asncrono. De esta manera, los objetos
generadores de eventos y los objetos suscritos no necesitan sincronizarse. Se puede ver un
ejemplo de un sistema en la pgina 176.

Es importante ver el ejemplo de la pgina 177 sobre la sala de contratacin.

Cada evento tiene una serie de atributos que especifican informacin sobre dicho evento 8identificador,
parmetros). Un objeto se suscribe a un tipo de evento, pudiendo especificar criterios sobre sus
atributos.
LOS PARTICIPANTES EN UNA NOTIFICACIN DE EVENTOS DISTRIBUIDA
La arquitectura est diseada para desacoplar los anunciantes de los suscriptores; as, ambos tipos se
pueden desarrollar independientemente. A continuacin, se presentan los papeles de los objetos
participantes:

El objeto de inters: Experimenta cambios debidos a las operaciones sobre l. Estos cambios
pueden ser de inters para otros objetos.

Evento: Es el resultado de la finalizacin de la ejecucin de un mtodo. Aparece sobre el

objeto de inters.

Notificacin: Contiene informacin sobre un evento: tipo y sus atributos.

Suscriptor: Objeto que se ha suscrito a uno o varios tipos de evento de otro objeto.

Objetos observadores: Desacopla un objeto de inters de sus suscriptores. Se encarga de

filtrar los suscriptores que deben recibir una notificacin; ya que si lo tuviese que hacer el
objeto de inters, se complicara en exceso.

Anunciante: Genera notificaciones de tipos concretos de eventos. Puede ser un observador o

un objeto de inters a la vez que anunciante.

Vase la figura 5.10 (pgina 178).

Se garantizarn las notificaciones en funcin de los requisitos de las aplicaciones (ej: si se usa
multidifusin IP, el modelo de fallo estar relacionado con el que vimos con anterioridad para este tipo
de difusin; otras aplicaciones pueden tener requisitos ms estrictos, como el ejemplo de la sala de
contratacin).
Algunas aplicaciones tiene restricciones de tiempo real (eventos de una planta nuclear, monitorizacin
de un paciente de un hospital). Se pueden disear protocolos de multidifusin que proporcionen
garantas de tiempo real y de fiabilidad y ordenamiento para un sistema distribuido sncrono.
La tarea de procesar las notificaciones puede dividirse entre los procesos observadores. Por ejemplo:

Encaminamiento:
Un observador encaminador puede realizar la tarea de enviar las
notificaciones en nombre de uno o ms objetos de inters. Recibe la notificacin del objeto de
inters.

Filtrado de notificaciones: Aplica filtros para reducir el nmero de notificaciones recibidas.

Patrones de eventos:
determinado.

Buzones de notificaciones: Puede que el suscriptor no est listo para recibir las notificaciones.
El observador las enva en el momento adecuado.

Un objeto puede suscribirse a un tipo de evento que siga un patrn

ESPECIFICACIN DE EVENTOS DISTRIBUIDOS DE JINI

Permite que un suscriptor potencial en una JVM se suscriba y reciba notificaciones de un objeto de
inters en otra JVM. Los objetos involucrados son:

Generadores de eventos: Permite que otros objetos se suscriban a l.

Oyentes de eventos remotos: Objeto que puede recibir notificaciones.

Eventos remotos: Objeto enviado por valor a un oyente (equivalente a una notificacin).

Agentes terceros: Equivalente a los observadores.

El generador utiliza Java RMI para el envo de las notificaciones, posiblemente a travs de uno o ms
agentes terceros. Los agentes deben retransmitirlo lo antes posible. Para suscribirse tambin se usa Java
RMI.
Tenemos las siguientes interfaces y clases:

RemoteEventListener:
mtodo notify.

RemoteEvent: Contiene la referencia al generador de eventos en cuestin, un identificador del

tipo de evento, un nmero de secuencia (se incrementa segn se suceden los eventos, para
poder ordenar y evitar duplicados) y el objeto empaquetado (la notificacin), si es necesario.

EventGenerator: Tiene el mtodo register, para suscribirse a los eventos. Sus argumentos son
el identificador del tipo de evento, el objeto que se devolver con cada notificacin, una
referencia remota a un objeto oyente de eventos (donde se enviarn las notificaciones) y el
periodo de cesin solicitado (recurdese anteriormente la concesin).

La implementan los suscriptores y los agentes terceros. Tiene el

EventGenerator es solo un ejemplo de interfaz que puede usarse. Algunas aplicaciones podran requerir
otras.
AGENTES TERCEROS
Son intermediarios entre el generador y oyente. Puede formarse una cadena de agentes terceros.
Puede tener una gran variedad de papeles (ej: responsable del reparto fiable de las notificaciones).

EL CASO DE ESTUDIO JAVA RMI

Aunque la programacin en Java RMI es simple por ser de un solo lenguaje. Sin embargo, debe
considerar el comportamiento del sistema distribuido en un entorno concurrente
Las interfaces remotas en Java RMI se definen con la extensin de una interfaz llamada Remote (est en
el paquete java.rmi). Puede verse un ejemplo del uso de esta interfaz en la figura 5.11 (pgina 183).
En Java RMI pueden existir mltiples parmetros de entrada de un mtodo, pero solamente uno de
salida. Cualquier objeto que implemente Serializable puede empaquetarse y enviarse como parmetro
en una peticin o una respuesta de RMI.
Si el tipo de valor pasado implementa una interfaz remota, el argumento o resultado se pasa siempre
como una referencia a objeto remoto. Si esta referencia est en la respuesta, puede utilizarse para
hacer llamadas RMI sobre dicho objeto remoto.
Los objetos no remotos serializables se copian y se pasan por valor. En el receptor se crea un nuevo
objeto, pudiendo invocar sus mtodos localmente (tngase en cuenta que los cambios en su estado no
afectarn al objeto original). La figura 5.11 muestra todo esto.
El resultado se enva serializado; pero si el objeto resultado implementa Remote se sustituye por su
referencia. Cuando se enva serializado, se anota su informacin de clase con la ubicacin de clase, de
forma que el receptor pueda descargar la clase.
Java permite que una mquina descargue una clase de otra mquina virtual. Si el receptor no posee la
clase que se pasa por valor, realizar dicha descarga. Si el receptor no posee la clase de un proxy cuando
se pasa un objeto por referencia, se descarga su cdigo.
As, no es necesario que cada usuario tenga el mismo conjunto de clases; y los programas hacen un uso
transparente de las instancias de las clases nuevas.
Se conoce como RMIregistry al enlazador para Java RMI. Debe existir en todo computador que aloje
objetos remotos. Tiene una tabla con nombres y referencias a objetos remotos de dicho computador. Se
accede a ellos mediante la clase Naming (sus mtodos tienen un argumento de la forma
//nombreComputador:puerto/nombreObjeto). Si no se indica el parmetro, se asumo que es el
computador local.
CONSTRUCCIN DE PROGRAMAS CLIENTES Y SERVIDORES
Como la explicacin de la construccin de los programas cliente y servidor se realiza a travs de
ejemplos, se deja su lectura en las pginas 185 y 186.
Se conoce como devolucin de llamada a la accin del servidor en que notifica a los clientes acerca de
un evento. De esa manera, el cliente no tiene que sondear continuamente al servidor. El cliente crea un
objeto remoto que implementa una interfaz (objeto de devolucin de llamada o de retrointerfaz). El
servidor tiene una operacin que permite a los clientes informarle de sus referencias a objetos remotos
(segn las recibe, las almacena). Cuando aparezca un evento de inters, el servidor llamar a los clientes
interesados.
Esto tiene algunos problemas: Puede que el servidor termine antes de que los clientes informen de su
inters; podra usarse las concesiones para solventar esto. Por otra parte, el servidor tiene que realizar
una serie de RMI sncronas a los objetos de retrollamada.
Puede verse un ejemplo de esto en las pginas 187 y 188.

DISEO E IMPLANTACIN DE JAVA RMI

Se utiliza la reflexin para pasar informacin en los mensajes de peticin sobre el mtodo que desea
invocarse. Se realiza mediante la clase Method. Esta clase (cada instancia) representa las caractersticas
de un mtodo particular (clase, tipos de argumentos, el valor devuelto, las excepciones). Tiene un
mtodo invoke que tiene dos argumentos: uno especifica el objeto que recibir la invocacin y el otro es
una cadena de Object que contiene los argumentos. El resultado devuelto es del tipo Object.
El proxy empaqueta un objeto Method y pone los argumentos en la cadena de Object y la empaqueta. El
distrubuidor desempaqueta el objeto Method y sus argumentos. As, habr obtenido la referencia a
objeto remoto. El distribuidor llamar al mtodo invoke con el destino y los argumentos especificados.
Una vez ejecutado, el distribuidor empaqueta el resultado de cualquier excepcin en la respuesta.
Vase la figura 5.16 (pgina 189) para ver la estructura hereditaria de las clases que dan soporte a los
servidores RMI en Java.

CORBA RMI
La programacin en CORBA RMI es ms compleja que en JAVA RMI, por ser un sistema multilenguaje.

El modelo de objetos de CORBA: Es similar al que ya vimos, con la salvedad de que un cliente
puede ser cualquier programa (no tiene por qu ser un objeto) que enve mensajes de peticin
a objetos remotos y reciba las respuestas. Un objeto CORBA se refiere a un objeto remoto, que
implementa una interfaz de un IDL, tiene una referencia a un objeto remoto y puede responder
a las invocaciones de los mtodos. En CORBA no existe el concepto de clase, ya que puede
implementarse en lenguajes no orientados a objetos (esto implica que no se le pueden pasar
clases como argumentos (aunque s estructuras de datos)).

CORBA IDL: Una interfaz CORBA IDL especifica un nombre y un conjunto de mtodos
disponibles. Vase la figura 17.1 (pgina 640) donde se muestra el cdigo de un ejemplo. Los
parmetros se marcan como de entrada (in), de salida (out) o ambos (inout) (para todo esto
sgase el ejemplo de la figura 17.1). El retorno se representa mediante un parmetro out o void
si no hubiese. Los parmetros pueden ser de tipos primitivos (long y boolean) o de tipos
construidos (struct y array). Puede pasarse como parmetro una referencia a un objeto CORBA
(el tipo es Object) o un tipo primitivo o construido (estos se pasan por valor).
Se pueden definir excepciones en sus interfaces que sean lanzadas por sus mtodos.
Por defecto, la invocacin remota en CORBA define la semntica como mximo una vez, aunque
puede especificarse puede ser con la palabra oneway (esto slo se emplea en las invocaciones
de mtodos sin resultado, ya que no se bloquea).

El Servicio de Nombres de CORBA: Es un enlazador que proporciona operaciones para

registrar referencias a objetos remotos mediante su nombre (rebind) y para buscarlas (resolve).
Veremos esto ms adelante.

Pseudo objetos CORBA: Son interfaces que no pueden usarse como si fueran objetos CORBA
(ej: no pueden ser parmetros en una RMI). La interfaz se llama ORB e incluye un mtodo init
(inicializar el ORB), un mtodo connect (para registrar objetos CORBA con el ORB) y otros
mtodos para conversiones entre referencias a objetos remotos y cadenas de texto.

EJEMPLO DE CLIENTE Y SERVIDOR CORBA

(Para poder seguir esta seccin, hay que mirar a la vez los cdigos de ejemplo de las pginas 641 a 644
y las explicaciones que el libro va dando sobre las lneas de cdigo)
Se aplica el compilador de interfaz idltojava a las interfaces CORBA para generar cada interfaz Java
equivalente, un esqueleto de servicio para cada interfaz IDL, una clase proxy o resguardo de cliente por
cada interfaz IDL, una clase Java para cada struct y clases ayudantes (convierte una referencia en la clase
a la que pertenece, mediante narrow) y propietarios (trata con los parmetros out e inout, que no
existen en Java) para cada tipo definido en la interfaz IDL.
Cuando un servidor crea una instancia de una clase sirviente, se registra frente al ORB (la convierte en
un objeto CORBA y le da una referencia a objeto remoto). Esto sirve para que pueda recibir invocaciones
remotas. Cada clase sirviente extiende la clase esqueleto correspondiente e implementa los mtodos de
una interfaz IDL.
Cuando se crea un nuevo objeto, hay que registrarlo en el ORB para poder hacer un objeto CORBA
(evidentemente, ese ORB hay que crearlo en el main del servidor).

Por su parte, un cliente debe atrapar siempre las excepciones CORBA SystemExceptions (informan de los
errores a causa de la distribucin).
Respecto a las retrollamadas, se pueden implementar en CORBA de una forma similar a Java RMI. Vase
el ejemplo de la pgina 644: la interfaz permite que el servidor enve al cliente un nmero de versin al
aadir objetos nuevos. Pero, evidentemente, el cliente tiene que informar al servidor de la referencia a
ese objeto remoto, con lo que la interfaz requiere mtodos adicionales.
El mtodo retrollamada se declara como oneway. De esa forma, el servidor puede utilizar llamadas
asncronas al notificar al cliente.
LA ARQUITECTURA DE CORBA
Est diseada de modo que los clientes y servidores se puedan implementar en mltiples lenguajes. En
la figura 17.6 (pgina 645) se pueden ver los componentes principales de CORBA. Hay que decir que
CORBA distingue entre invocaciones estticas (se conoce durante la compilacin la interfaz remota del
objeto CORBA) y dinmicas (no se conoce en compilacin). Veamos los componentes:

El ncleo de ORB: Es similar al mdulo de comunicacin que habamos visto con anterioridad.
Pero, adems, proporciona una interfaz que permite realizar operaciones de arranque y
parada, operaciones para la conversin entre referencias a objetos remotos y cadenas de texto;
y operaciones para obtener listas de argumentos para las llamadas que emplean invocacin
dinmica.

Adaptador de objeto: sirve de puente entre los objetos con interfaces IDL y las interfaces del
lenguaje de programacin de las clases sirviente. Entre sus usos, est la creacin de referencias
a objetos remotos para objetos CORBA, despachar cada RMI por un esqueleto hacia el sirviente
apropiado y activar objetos.
Le da a cada objeto CORBA un nombre nico que forma parte de su referencia (puede
especificarse por el programa de aplicacin o ser generado por el adaptador). Cada adaptador
tiene su propio nombre, que tambin forma parte de todas las referencias que gestione.

Esqueletos: Se generan mediante un compilador de IDL en el lenguaje de servidor. Mediante

l se despachan las RMI al sirviente adecuado. Desempaqueta las peticiones (sus argumentos) y
empaqueta las respuestas.

Resguardo/proxy del cliente: En el lenguaje del cliente. El proxy es para los lenguajes
orientados a objetos y el resguardo (conjunto de procedimientos) para lenguajes procedurales.
Se genera mediante un compilador de IDL desde una interfaz IDL. Empaqueta los argumentos
de los mensajes de invocacin y desempaqueta las respuestas y excepciones.

Repositorio de implementacin: Activa bajo demanda los servidores registrados y localiza

aquellos que estn en ejecucin. Se usa el nombre de adaptador de objeto. Tiene la
correspondencia de los nombres de ciertos adaptadores de objetos con las rutas de los archivos
que contiene los objetos de la implementacin (se registran al instalar los programas
servidores). Vase en la pgina 646 la estructura de una entrada. Recurdese que algunos
objetos (como las retrollamadas) no se activan por demanda, por lo que no necesitan (esos
concretos) el repositorio de implementacin.

Repositorio de interfaz:
Proporciona informacin sobre las interfaces IDL registradas
(nombres de mtodos y de argumentos (con sus tipos), excepciones). Si un cliente no tiene

proxy para un objeto CORBA, se puede consultar el repositorio sobre los mtodos del objeto y
sus argumentos. El compilador de IDL asigna un identificador a cada tipo IDL de interfaz que
compila. Este identificador se incluye en las referencias a objetos remotos para los objetos
CORBA del tipo en cuestin. Esto sirve slo para la invocacin dinmica.

Interfaz de invocacin dinmica: CORBA no permite (al contrario que Java RMI) cargar clases
de ms objetos nuevos en tiempo de ejecucin. Para ello tenemos esta interfaz, con la que los
clientes pueden hacer invocaciones dinmicas sobre objetos remotos CORBA. Se usa si no es
prctico el empleo de proxies. El cliente obtiene del repositorio de interfaz informacin sobre
los mtodos disponibles de un objeto CORBA.

Interfaz de esqueleto dinmica: Permite que un objeto CORBA acepte invocaciones para una
interfaz que no tiene esqueleto (ej: si no se conoca el tipo de interfaz en la compilacin). Este
esqueleto inspecciona los contenidos de la peticin para determinar el objeto destino, el
mtodo invocado y sus argumentos. As, puede invocar sobre el objetivo.

Cdigo de legado: Es el cdigo que no fue diseado para los sistemas distribuidos. Se puede
convertir un fragmento del mismo en un objeto CORBA mediante una interfaz IDL para l y
proporcionando la implementacin de un adaptador de objeto y los esqueletos.

LENGUAJE DE DEFINICIN DE INTERFAZ DE CORBA (IDL)

Proporciona el modo de definir mdulos, interfaces, tipos, atributos y firmas de mtodos. De algunas de
estas cosas ya hemos visto ejemplos antes.

Mdulos IDL: Agrupa las interfaces y otras definiciones de tipo IDL en una unidad lgica.
Define un lmite lxico, para evitar conflictos entre nombres dentro del mdulo y nombres
fuera de l. Vase un ejemplo en la figura 17.7 (pgina 648).

Interfaces IDL: Describe los mtodos disponibles de un objeto con esa interfaz.

Mtodos IDL: En la pgina 648 se puede ver la estructura de un mtodo IDL. Los parmetros
se etiquetan como in (entrada), out (salida) o inout (ambos; se emplea raramente). Si no hay
valor devuelto, se indica por void. Se puede usar oneway para que el cliente no se bloquee
esperando un resultado, utilizando la semntica de llamadas pudiera ser. Pueden lanzarse
excepciones mediante raises (pgina 648). Si la excepcin tiene variables, pueden usarse para
aportar informacin al cliente.

Tipos IDL: Soporta tipos primitivos (short, long, unsigned short, unsigned long, float, double,
char, boolean, octet y any; entre otros, pudiendo utilizar const para declarar constantes) y tipos
construidos (sequence, String, array, record, enumerated, unin (pgina 649)). Hay un tipo
especial: Object, que indica referencias a objetos remotos.

Atributos: Indican el estado de una interfaz IDL (similar a los campos pblicos de clase en
Java). Pueden ser readonly si se necesita. Son privados, pero se generan un par de mtodos de
acceso automticamente por el compilador de IDL.

Herencia: Al igual que en Java, las interfaces IDL pueden extenderse. La extendida puede
redefinir tipos, constantes y excepciones, pero no mtodos (vase pgina 650). Una interfaz IDL
puede extender ms de una interfaz, y heredar los componentes de todas. IDL no permite que
se hereden mtodos o atributos con nombres comunes desde interfaces diferentes. Todas las

interfaces IDL heredan de Object (as, todas las interfaces IDL pueden enviar y recibir
referencias a objetos remotos).

Nombres de tipo IDL: Ya mencionamos que para cada tipo de una interfaz IDL se generan
identificadores de tipo nico mediante el compilador de IDL. Un nombre de tipo IDL consta del
prefijo IDO, un nombre de tipo y un nmero de versin (pgina 650). Se puede usar el prefijo
pragma para prefijar una cadena de texto adicional al nombre del tipo, para distinguir sus
propios tipos de los de otros desarrolladores.

Extensiones a CORBA: Veamos algunas caractersticas aadidas recientemente a CORBA:

o

Objetos que pueden pasarse por valor: Habamos dicho que los tipos primitivos y
construidos se pasaban por valor y las referencias a objetos remotos CORBA por
referencia. Pues bien, se ha incluido el poder pasar por valor objetos no-CORBA. Este
es el tipo valuetype, que pasa el estado al proceso remoto y ste crea un nuevo objeto
a partir de ese estado. Pasar la implementacin de los mtodos es ms difcil, si los
lenguajes son distintos. Si ambos son en Java, el cdigo puede descargarse. Si es en
C++, el cdigo debe estar ya presente tanto en el cliente como en el servidor.
Recurdese que los cambios en el nuevo objeto no afectarn al objeto original.

RMI asncrono: Un cliente puede desconectarse temporalmente. Con objeto de servir

a estos clientes tenemos el RMI asncrono, que permite que las peticiones viajen
mediante un agente intermediario, que en caso de necesitarlo almacenar la
respuesta y la entregar cuando el cliente est disponible. La semntica de invocacin
aqu tiene dos variantes nuevas: callback (pasa una referencia a una devolucin de
llamada para que el servidor devuelva la llamada con los resultados) y polling (el
servidor devuelve un valuetype que se puede usar para sondear o esperar por la
respuesta).

REFERENCIAS A OBJETOS REMOTOS EN CORBA

En la pgina 651 puede observarse el formato de una referencia a objeto remoto (IOR: Interoperable
Object Reference).
El primer campo contiene el nombre de tipo de la interfaz IDL del objeto CORBA. Si el ORB tiene un
repositorio de interfaz, tambin es el identificador de la interfaz en dicho repositorio.
El segundo campo tiene el protocolo de transporte y los detalles para identificar al servidor. El protocolo
Internet Inter-ORB (IIOP) usa TCP/IP. Si especifica el nombre de dominio del host y el puerto, puede
aparecer varias veces, si el objeto est replicado en varias ubicaciones.
El tercer campo identifica un objeto CORBA (nombre de adaptador de objeto en el servidor y nombre de
objeto CORBA especificado por el adaptador). Lo usa el ORB.
Podemos distinguir entre IOR transistorio (dura mientras dure el proceso que lo aloje y contiene los
detalles de las direcciones del servidor que tiene el objeto CORBA) e IOR persistente (perdura entre las
activaciones de los objetos CORBA y tiene los detalles de las direcciones del repositorio de
implementacin).
En el transistorio, el ncleo del ORB recibe la peticin, extrae el nombre de adaptador, con lo que
localiza al adaptador y, mediante su uso, localiza el sirviente adecuado.

En el persistente, el repositorio de implementacin recibe la peticin. Extrae el nombre de adaptador de

objeto del IOR y, si es necesario, activa el objeto CORBA. Entonces devuelve la direccin detallada al
ORB del cliente, el cual lo usa como destino de los mensajes de peticin RMI (que incluyen el nombre
del adaptador y del objeto). Entonces el proceso sigue como en los transistorios.
La respuesta en el protocolo peticin-respuesta incluye un encabezado con informacin que permite
llevar a cabo el mecanismo de IOR persistente
CORRESPONDENCIA CON LENGUAJE EN CORBA
Como se ha podido comprobar, la correlacin de los tipos en el IDL con los tipos en Java es directa. Pero
hay ms problemas en la correspondencia de la semntica de paso de los parmetros (ej: IDL permite la
devolucin de varios valores por separado y Java slo uno). Para solventar esto, se proporcionan clases
Holder, que permite que el cliente proporcione una instancia de esa clase como argumento de la
invocacin (vase pgina 652).
C++ tiene problemas con los parmetros (a pesar de poder gestionar out e inout) cuando se pasan
referencias y entidades de longitud variables (como cadenas de texto).
En resumen: un programador que use IDL, debe aprender (adems de la notacin IDL) la correlacin de
sus parmetros con los del lenguaje de implementacin.

SERVICIOS DE CORBA
CORBA incluye especificaciones de distintos servicios que pudieran ser necesarios en los objetos
distribuidos. Veamos algunos de ellos:

Servicio de nombres: Lo veremos ms adelante.

Servicio de eventos y servicios de notificacin: Lo veremos ms adelante.

Servicio de seguridad: Lo veremos ms adelante.

Servicio de comercio: Similar al servicio de nombres, pero permite localizar objetos a travs
de sus atributos en lugar de su nombre. Tiene una base de datos que relaciona los tipos de
servicio (nombre) y sus atributos (par nombre-valor). El cliente especifica restricciones sobre
los atributos para hacer la bsqueda. Un servicio de comercio no slo busca en su base de
datos, sino que puede colaborar con otros para buscar en varias ubicaciones.

Servicio de transacciones y servicio de control de concurrencia: Permite que los objetos

CORBA participen en transacciones tanto sencillas como anidadas. Estas transacciones son
varias llamadas RMI que comienzan con begin y terminan con commit o rollback, segn se
confirmen o se deshagan respectivamente. Por su parte, el de control de concurrencia permite
establecer bloqueos para permitir un control de la concurrencia del acceso a objetos CORBA.

Servicio de objetos persistentes: Cada objeto CORBA se responsabiliza de guardar y recuperar

su propio estado en las activaciones. Este servicio (POS) sirve como almacn de objetos
persistentes de objetos CORBA. La especificacin define interfaces para sus componentes.
Puede implementarse de varias formas (ej: con archivos o BBDD).
Cada objeto persistente tiene un identificador con la identidad de su almacn de dato y un
nmero de objeto dentro del almacn. Un objeto CORBA hereda una interfaz con operaciones
para almacenarlo, restaurarlo o eliminarlo. La implementacin debe elegir un protocolo de
comunicacin con un almacn.

EL SERVICIO DE NOMBRES DE CORBA

Permite enlazar nombres con referencias a objetos remotos de objetos CORBA con contextos de
nombres. Se conoce como contexto de nominacin al alcance dentro del que se aplican un conjunto de
nombres. En un contexto dado, cada nombre es nico.
Mediante el contexto inicial de nominacin se proporciona una raz para un conjunto de enlaces. Ms
de un contexto inicial puede apuntar al mismo grafo (Figura 17.9, pgina 654). Aunque en la prctica,
cada instancia de un ORB tiene un nico contexto inicial, pueden formar federaciones.
Los programas cliente y servidor solicitan el contexto inicial desde el ORB mediante
resolve_initial_references. La respuesta es una referencia a un objeto NamingContext. Si un nombre
tiene varios componentes, el servicio busca en el contexto de arranque un enlace que concuerde con el
primer componente. Si ste es una referencia a un contexto de nominacin, se resuelve el segundo
componente en ese contexto, y as sucesivamente.
Los nombres empleados son del tipo NameComponent y constan de una cadena para el nombre y otra
para la clase del objeto. Es importante notar que los nombres no se pueden expresar con rutas como las
de archivos en UNIX (separados por slash (/)), ya que ese carcter puede formar parte del propio
nombre.

En la figura 17.10 (pgina 655) se muestra parte de la interfaz IDL NamingContext del servicio de
nombres.
Para buscar referencias, los clientes usan resolve. Esto devuelve un Object, que deber ser estrechado
(narrow) antes de ser usado para convocar un mtodo en un objeto remoto. Su argumento es de tipo
Name (secuencia de componentes de nombre, que debe ser construida antes de realizar la llamada).
Los servidores de objetos remotos usan bind para registrar los nombres de sus objetos y unbind para
eliminarlos (tambin para contextos). rebind permite reemplazar enlaces (no se puede hacer bind sobre uno ya
existente).
bind_new_context se usa para crear un contexto nuevo y enlazarlo con un nombre dado. cind_context se usa para
enlazar un nombre de contexto a un nombre dado en el contexto sobre el que fue invocado.
list devuelve una lista de enlaces (nombre + tipo/objeto/contexto) desde el NameContext. Si hay demasiados
enlaces, se pueden enviar en varias tandas (devuelve un iterador como resultado secundario). En la figura 17.10
(pgina 655) se puede observar el mtodo lista.
Se permite la federacin de servicios de nombres, de forma que cada servidor proporciona un subconjunto de
grafos de nombres (ver figura 17.9 (pgina 654)).
La implementacin Java de este servicio es simple y almacena sus enlaces en memoria voltil (es transistoria).
SERVICIO DE EVENTOS DE CORBA
Define interfaces que permiten a los objetos de inters (proveedores) comunicar notificaciones a sus subscriptores
(consumidores). stas pueden ser impulsadas (push, mediante la interfaz PushConsumer) por el proveedor o
extradas (pull, mediante la interfaz PullSuplier) por el consumidor.
La notificacin se transmiten como un argumento o resultado de tipo any. Los objetos que las intercambian deben
ponerse de acuerdo sobre el contenido de las notificaciones.
Se conoce como canal de eventos a objetos CORBA que pueden usarse para que mltiples proveedores se
comuniquen con mltiples consumidores. Acta como un buffer entre ambos. Si se comunican por aqu, tambin
puede ser por impulsin o por extraccin (incluso ambas, los proveedores impulsan al canal y los consumidores
extraen del canal).
En notificaciones asncronas, se puede crear un canal de eventos, cuya referencia se aporta a travs del servicio de
nombres o por un RMI. Los proveedores obtienen los proxies de consumidor desde el canal de eventos y los
consumidores obtienen de l los proxies de proveedor.
Cuando un proveedor genera una notificacin por impulsin, llama a push del proxy de consumidor por impulsin.
La notificacin va al canal y se entrega a los proxy de consumidores. Si los consumidores emplrean la extraccin,
llamarn a pull del proxy de un proveedor. Esto posibilita la construccin de cadenas de canales de eventos (cada
canal genera notificaciones que consume el siguiente canal).
Estos canales de eventos son similares a los observadores que ya habamos visto. Pueden programarse para adoptar
algunos de los papeles que mencionamos en su momento. Debe tenerse en cuenta que las notificaciones no
conllevan ninguna forma de identificadores, as que los patrones de reconocimiento y los filtrados de notificaciones
deben usar la informacin de tipo puesta en las propias notificaciones.
SERVICIO DE NOTIFICACIN DE CORBA
Extiende el servicio de eventos. Aade las siguientes funciones:

Las notificaciones pueden definirse como estructuras de datos. As, el tipo no se limita a any o al que
especifique el programador.

Los consumidores de eventos puede usar filtros para indicar qu eventos desean. Estos filtros pueden
adherirse a cada proxy de un canal. El proxy se encarga de redirigir los eventos segn los filtros.

Los proveedores de eventos pueden descubrir qu tipos de eventos son de inters para los consumidores.
As, pueden generar slo esos eventos.

Los consumidores pueden descubrir los eventos que generan los proveedores de un canal. As, pueden
suscribirse a los que surjan nuevos.

Se pueden configurar las propiedades de un canal, proxy o evento concreto; como la confiabilidad del
reparto de eventos, su prioridad, el ordenamiento necesario, la poltica de descarte de eventos

Proporciona un repositorio de tipos de eventos, que permite acceso a la estructura de eventos (bueno
para definir restricciones de filtrado).

Tenemos un tipo Evento Estructura con los siguientes campos (puede verse en la pgina 659):

Tipo de dominio: Es el dominio de definicin (finanzas, hotel).

Tipo de evento: Categoriza el evento dentro del dominio.

Nombre de evento: Identifica unequvocamente la instancia especfica del evento transmitido.

Requisito: Una lista de pares nombre-valor para ser usadas al especificar la fiabilidad y otros requisitos.

El cuerpo de un evento tiene la siguiente estructura (pgina 659):

Nombre-valor: Secuencia de pares. La usan los filtros.

Resto del cuerpo: Contiene datos referentes a un evento particular (ver ejemplo en la pgina 659).

Un filtro es una coleccin de restricciones, que tienen dos componentes: una lista de estructuras de datos (cada una
indica un tipo de evento en trminos de su nombre de dominio y tipo de evento; permite indicar todos los tipos de
eventos a los que se aplica la restriccin) y una cadena de texto con una expresin booleano que incluye los tipos de
datos listados (ejemplo en pgina 659).
La especificacin del servicio de notificacin incluye la definicin de un lenguaje de restricciones (extiende el
lenguaje usado por el servicio de comercio).
SERVICIO DE SEGURIDAD DE CORBA
Incluye lo siguiente:

Autenticacin de principales: Son los usuarios y los servidores. Permite generar credenciales para ellos.

Control de acceso a objetos CORBA: Pueden expresarse derechos de acceso, por ejemplo, con listas de
control de acceso (ACL).

Auditora de las invocaciones por los servidores.

Medios para el no repudio: El servidor crea y almacena credenciales que dejan constancia de que un
principal hizo una invocacin.

Al realizar una invocacin segura, se envan las credenciales del cliente junto con la peticin. El servidor valida las
credenciales y decide, en su caso, si el principal tiene derecho a acceder al objeto en cuestin. Si todo es correcto,
se realiza la invocacin y se enva la respuesta (si es necesario, junto con las credenciales del servidor).
CORBA permite especificar una variedad de polticas de seguridad: si el cliente o el servidor se deben autenticar, si
hay que proteger la privacidad o la integridad

Hay un tipo especial de credencial (privilegio) que se asigna a los usuarios a la medida de sus funciones.
Los objetos se agrupan en dominios, que tienen una poltica de control de acceso que especifica los derechos de
acceso de conjuntos de usuarios con privilegios concretos. Cada mtodo se clasifica en trminos de uno de cuatro
mtodos: get (devuelven partes del estado de un objeto), set (alteran el estado de un objeto), use (provoca que el
objeto haga alguna tarea) y manage (realizan funciones especiales no pensadas para el uso general). Cada nueva
interfaz de un objeto CORBA debe tener especificados los derechos de acceso en trminos de los anteriores
mtodos genricos. As, los diseadores de la interfaz estarn involucrados en la aplicacin del control de acceso.
Puede simplificarse la seguridad utilizando datos de autenticacin como, por ejemplo, claves de acceso.