Mecanismos de Comunicacion M1

Mecanismos de
comunicacin
Xavier Vilajosana Guilln
Leandro Navarro Moldes
PID_00184782
FUOC PID_00184782
Ninguna parte de esta publicacin, incluido el diseo general y la cubierta, puede ser copiada,
reproducida, almacenada o transmitida de ninguna forma, ni por ningn medio, sea ste elctrico,
qumico, mecnico, ptico, grabacin, fotocopia, o cualquier otro, sin la previa autorizacin escrita
de los titulares del copyright.
Mecanismos de comunicacin
FUOC PID_00184782
ndice
Introduccin...............................................................................................
Objetivos.......................................................................................................
1.
Paradigmas de comunicacin.........................................................
1.1.
Paso de mensajes .........................................................................
1.2.
Memoria compartida ...................................................................
11
1.3.
Invocacin remota ......................................................................
12
1.4.
Publicacin suscripcin ...............................................................
14
1.5.
Modelo de programacin por eventos ........................................
17
Mecanismos de comunicacin........................................................
19
2.1.
Codificacin de datos .................................................................
19
2.1.1.
2.
La problemtica de la codificacin de datos .................
19
Formatos de codificacin de datos .............................................
23
2.2.1.
Codificacin textual con XML ......................................
23
2.2.2.
Codificacin textual con JSON .....................................
25
2.2.3.
Codificacin binaria con XDR ......................................
26
2.2.4.
Codificacin binaria con ASN.1 ....................................
26
Mecanismos de invocacin remota ............................................
28
2.3.1.
Servicios de nombres .....................................................
30
2.3.2.
Conectores (sockets) .......................................................
31
2.3.3.
Protocolos RPC ..............................................................
34
2.3.4.
Localizacin de servicios ...............................................
48
2.3.5.
REST ...............................................................................
49
Resumen.......................................................................................................
53
Bibliografa.................................................................................................
55
2.2.
2.3.
FUOC PID_00184782
Introduccin
Hoy en da no nos podemos plantear la existencia de ninguna aplicacin que

no utilice un mecanismo de comunicacin, ya sea porque la aplicacin ha
sido desarrollada como un conjunto de hilos o procesos que se comunican
entre ellos o bien porque la aplicacin est en red y distribuida donde sus
componentes interactan de una forma ordenada, como por ejemplo con un
modelo cliente-servidor. Desde las aplicaciones web que consultamos a diario
y las aplicaciones que se ejecutan en nuestros dispositivos mviles hasta las
aplicaciones que se ejecutan en los microcontroladores de nuestros electrodomsticos, se usan primitivas de comunicacin para sincronizar e intercambiar
informacin o reproducir contenidos.
El objetivo de este mdulo es dar a conocer qu son las tcnicas y los paradigmas de comunicacin de aplicaciones o procesos que rigen el funcionamiento
de la mayora del software de hoy. As pues, en este mdulo presentamos los
mecanismos de comunicacin entre procesos, objetos y aplicaciones que han
surgido de la necesidad de comunicar aplicaciones que se ejecutan de forma
distribuida, paralela o concurrente.
En el mdulo veremos los paradigmas fundamentales de comunicacin de
aplicaciones, de los cuales destacamos el paso de mensajes y la invocacin
remota como mximos exponentes. El mdulo presenta seguidamente mecanismos de comunicacin ms ampliamente usados. Los sockets, que son una
implementacin del paradigma de paso de mensajes, la invocacin remota de
objetos y los procedimientos remotos, que consisten en la ejecucin de cdigo de forma remota. En el mdulo se presentan las tcnicas de codificacin
de datos, que pueden ser binarias o textuales, se introduce la problemtica
de la comunicacin donde los participantes no son homogneos, que requiere acuerdos en la representacin de la informacin. Finalmente, se presentan
mecanismos de comunicacin como RMI, XML-RPC y SOAP extensamente
usados a da de hoy.
FUOC PID_00184782
Objetivos
Con el estudio de este mdulo alcanzaris los objetivos siguientes:
1. Conocer los diferentes paradigmas de comunicacin entre procesos, aplicaciones u objetos.

2. Conocer la problemtica de la transmisin de informacin de datos y las
diferentes formas de codificar la informacin. Diferenciar la codificacin
binaria de la textual.
3. Conocer el funcionamiento de los mecanismos de comunicacin con conectores (sockets).
4. Conocer la invocacin remota de procesos y objetos. Saber los principales
protocolos que la implementan as como las caractersticas principales de
los servicios web.
FUOC PID_00184782
1. Paradigmas de comunicacin
Desde el momento en que existe la posibilidad de ejecutar procesos de forma

paralela, concurrente o distribuida, surge la necesidad de establecer comunicacin entre estos procesos. La comunicacin se puede llevar a cabo haciendo
uso de diferentes metodologas y tcnicas que se conocen como paradigmas
de comunicacin.
La comunicacin entre procesos puede ser sncrona o bien asncrona:
Comunicacinsncrona (o sincrnica): es el intercambio de informacin

entre procesos en tiempo real y requiere simultaneidad de los procesos.
Ejemplo de comunicacin sncrona
Un ejemplo de comunicacinsncrona es la telefona, en la que emisor y receptor coinciden en el espacio temporal en cuanto al hecho de transmitir la informacin, es decir,
hablar por telfono.
Comunicacinasncrona (o asincrnica): es aquella comunicacin que

se establece entre dos o ms procesos de manera diferida en el tiempo, es
decir, cuando no existe simultaneidad.
Ejemplo de comunicacin asncrona
Un ejemplo muy antiguo de comunicacinasncrona es la carta postal, en la que emisor y receptor no coinciden en el espacio temporal en cuanto al hecho de transmitir la
informacin, es decir, enviar la carta. Ejemplos actuales de la comunicacin asncrona
son el mail o correo electrnico y foros.
Todo mecanismo de comunicacin tiene que considerar aspectos como la fiabilidad en el envo, es decir, que el mecanismo nos asegurar que cualquier
informacin que se enva llegar, o en caso contrario, el mecanismo nos notificar que no ha podido enviar la informacin. Un mecanismo de comunicacin tambin puede garantizar la remisin en orden de la informacin que
se enva y definir la topologa del proceso de comunicacin, es decir, si los
mensajes se envan uno a uno (unicast o de igual a igual), uno a muchos (multicasting o broadcasting) o muchos a uno (cliente-servidor).
FUOC PID_00184782
Figura 1
Los paradigmas de comunicacin comparten un mismo objetivo pero su mbito de aplicacin es diverso, dado que depende directamente de la aplicacin,
del hardware, de la interconexin entre procesos y de las caractersticas de la
Red. Hay paradigmas que slo sirven para establecer conexiones sncronas,
mientras que otros solo permiten conexiones asncronas. Tambin hay paradigmas que pueden ser usados tanto sncronamente como asncronamente.
Seguidamente veremos los paradigmas de comunicacin ms relevantes y que
engloban la mayora de formas de comunicacin entre procesos, programas
u objetos, ya sean en una misma mquina o en mquinas remotas. Hay que
remarcar que los paradigmas que se presentan no representan siempre un mismo escenario ni son adecuados para cualquier situacin. Algunos de ellos son
ms adecuados para la comunicacin de procesos a bajo nivel o incluso para
escenarios caracterizados por muchas restricciones, como es el caso de la comunicacin entre microcontroladores; otros son ms adecuados para estructurar la comunicacin en programas complejos y a alto nivel. Vemoslos.
1.1. Paso de mensajes
El paso de mensajes es un paradigma de comunicacin usado en programacin
orientada a objetos, computacin concurrente y paralela y computacin distribuida. En este modelo los procesos u objetos pueden enviar mensajes a los
otros procesos y recibirlos, e incluso sincronizarse en espera de algn mensaje.
FUOC PID_00184782
En este paradigma, los programadores organizan sus programas como

una coleccin de tareas con variables locales privadas y la habilidad de
enviar y recibir datos entre tareas por medio del intercambio de mensajes. Se caracteriza por tener un espacio de direcciones distribuido y
conocido que permite la comunicacin entre tareas u objetos.
Los mensajes pueden ser enviados va red o usar memoria compartida, si est
(1)
En ingls, one-sided.
disponible. Las comunicaciones entre dos tareas ocurren a dos bandas, donde
los dos participantes tienen que invocar una operacin (enviar, por parte del
emisor, y recibir, por parte del receptor). Podemos denominar a estas comunicaciones operaciones cooperativas, puesto que tienen que ser realizadas por cada
proceso: el proceso que tiene los datos y el proceso que quiere acceder a los
datos. Tambin en algunas implementaciones, puede haber comunicaciones
de tipo unilateral1, si es un nico proceso el que invoca la operacin, colocando todos los parmetros necesarios; y la sincronizacin se hace de forma
implcita.
Conceptualmente, el paso de mensajes es el paradigma de comunicacin ms
explcito; el emisor genera un mensaje que enva a travs de un canal de comunicacin usando una primitiva especfica para llevar a cabo esta tarea. El
receptor, usando una primitiva, es capaz de leer el mensaje del canal. Este paradigma admite perfectamente tanto la comunicacin sncrona como la asncrona, que en todo caso solo tendra la limitacin de memoria del canal.
Como ventajas, el paso de mensajes permite enlazar con el hardware existente, puesto que se corresponde bien con arquitecturas que tengan una serie de
procesadores conectados por una red de comunicaciones (sea interconexin
interna o red cableada). En cuanto a la funcionalidad, incluye una mayor expresin disponible para los algoritmos concurrentes, dado que proporciona
control explcito y no habitual en la comunicacin entre procesos.
Por el contrario, el principal problema del paso de mensajes es la responsabilidad que el modelo hace recaer en el programador. Este tiene que implementar
explcitamente el esquema de distribucin de datos, las comunicaciones entre
las tareas, y su sincronizacin. En estos casos, su responsabilidad es evitar las
dependencias de datos, evitar abrazos mortales y condiciones de carrera en
las comunicaciones, as como implementar mecanismos de tolerancia a fallos
para sus aplicaciones.
En el paradigma de paso de mensajes es el programador quien directamente
controla el flujo de las operaciones y los datos. El medio ms usado para implementar este modelo de programacin es una biblioteca, que implementa la
API de primitivas habituales en entornos de paso de mensajes.
Abrazos mortales
Un abrazomortal (tambin
conocido como deadlock o interbloqueo) es una situacin
donde dos o ms acciones se
esperan mutuamente, incapaces de continuar hasta que las
otras acaben, con lo que ninguna de ellas logra acabar.
10
FUOC PID_00184782
Estas API de paso de mensajes suelen incluir:
Primitivas de paso de mensajes punto a punto. Desde las tpicas operacio-
(2)
En ingls, send y receive.
nes de transmisin y recepcin , hasta variaciones especializadas de estas.
Primitivas de sincronizacin. La ms habitual es la primitiva de barrera,

que implementa un bloqueo en todas (o parte de) las tareas de la aplicacin
paralela.
Primitivas de comunicaciones colectivas. Varias tareas participan en un

intercambio de mensajes entre ellas.
Creacin esttica (y/o dinmica) de grupos de tareas dentro de la aplicacin, para restringir el mbito de aplicacin de algunas primitivas. Permite separar conceptualmente unas interacciones de las otras dentro de la
aplicacin.
La implementacin especfica de un mecanismo de paso de mensajes tiene

que considerar:
Si el envo ser fiable.
Si el envo garantizar el orden de la informacin transmitida.
Si los mensajes se envan uno a uno (unicast o de igual a igual), uno a

muchos (multicasting o broadcasting ) o muchos a uno (cliente-servidor).
Si la comunicacin es sncrona o asncrona.
Hay multitud de implementaciones de este paradigma, de las cuales podemos

destacar sockets, SOAP, CORBA, REST o D-Bus, entre otros.
Figura 2
Primitivas de barrera
Las primitivas de barrera (o barrier, en ingls) son puntos de
sincronizacin o bloqueo de
mltiples tareas en un programa. La barrera tambin puede
ser el punto de sincronizacin
de varios programas o procesos distribuidos.
FUOC PID_00184782
11
1.2. Memoria compartida

En el paradigma de la memoria compartida, se considera como tal a la memoria que es compartida por los diferentes procesos. Se puede acceder a esta memoria mediante mltiples programas con la intencin de compartir objetos o
variables y disminuir as la redundancia.
En este modelo, los programadores ven sus programas como una coleccin de
procesos que acceden a variables locales y un conjunto de variables compartidas. Cada proceso accede a los datos compartidos mediante una lectura o escritura asncrona. Por lo tanto, dado que ms de un proceso puede realizar las
operaciones de acceso a los mismos datos compartidos en el mismo tiempo,
es necesario implementar mecanismos para resolver los problemas de exclusiones mutuas que se puedan plantear mediante mecanismos de semforos o
bloqueos.
En el modelodememoriacompartida, el programador ve la aplicacin como una coleccin de tareas que normalmente son asignadas a
hilos de ejecucin en forma asncrona. Los hilos de ejecucin tienen
acceso al espacio compartido de memoria con los mecanismos de control mencionados antes.
La memoria compartida es una forma muy rpida de comunicar procesos (en
(3)
En ingls, sockets.
oposicin al paso de mensajes, como en el caso de los conectores ). Por otro

lado, sin embargo, es menos potente que la comunicacin con primitivas de
paso de mensajes, dado que es imprescindible poder compartir la memoria y,
por lo tanto, los procesos tienen que estar en la misma mquina.
No obstante, hay aproximaciones a sistemas de memoria compartida distri4
buida . Estos sistemas permiten compartir una cantidad de memoria de forma

remota. Una restriccin de estos sistemas es que formen parte de un clster,
dado que es necesaria una interconexin de red muy rpida para que el hecho de compartir memoria tenga sentido. La memoria compartida se organiza
frecuentemente en pginas de memoria que son direccionables y accesibles
remotamente. Otra forma de organizar la memoria es con los llamados tuple
space, donde la mnima unidad de comparticin de informacin viene definida por una medida mnima llamada tuplo.
Clsteres
Un clster es una estructura formada por colecciones de computadores de caractersticas
similares interconectados a travs de una red de rea local. Los computadores hacen uso
de un mismo sistema operativo y un software intermediario (middleware) que se encarga
de abstraer y virtualizar los diferentes computadores del sistema, de forma que da la
visin al usuario de un sistema operativo nico. Los clsteres son sistemas dedicados
a la supercomputacin. El sistema operativo de un clster es estndar y por lo tanto,
es el software intermediario el que provee de bibliotecas que permiten la computacin
paralela.
(4)
En ingls, distributed shared memory.
FUOC PID_00184782
12
La implementacin de sistemas de memoria compartida distribuida requiere
Algunos ejemplos tpicos
de un modelo de consistencia de los datos logrado por un protocolo que man-
Ejemplos tpicos de sistemas

de memoria compartida incluyen el kernel de Linux 2.6 que
ofrece /dev/shm como punto de montaje de la memoria
compartida o las implementaciones de OpenMP.
tiene la coherencia de los datos.

Figura 3
(5)
RPC es la sigla de la expresin

inglesa remote procedure call.
1.3. Invocacin remota

La invocacin remota o ejecucin remota de procedimientos (RPC5) es una de
las tcnicas, conjuntamente con el paso de mensajes, ms usada a la hora de
desarrollar aplicaciones distribuidas.
(6)
La invocacin remota es un paradigma de comunicacin de procesos

u objetos6 que consiste en la posibilidad de ejecutar una subrutina o
mtodo en otro espacio de direcciones (normalmente, otro ordenador
al que se accede a travs de la Red).
La particularidad de los mtodos RPC es que el programador de la aplicacin

es totalmente ajeno al hecho de que la ejecucin del mtodo se hace de forma
remota. Tampoco se hace necesario por parte del programador codificar todos
los detalles de esta interaccin remota. La invocacin remota es en cierto modo anloga a la tcnica de paso de mensajes, dado que el emisor tiene que
invocar una primitiva en el receptor y este, cuando obtiene el resultado, enva
la respuesta de nuevo al emisor. La diferencia radica en el hecho de que la
invocacin remota no requiere que el receptor invoque ningn mtodo para
recibir la peticin y que normalmente el proceso de transmisin de la informacin es atmico.
En el caso de la ejecucin de
mtodos de objetos remotos, el
paradigma se denomina invocacin
remota de mtodos (en ingls, remote method invocation (RMI).
Lectura recomendada
En el artculo Implementing
remote procedure calls de
Birrell, Nelson, etc. se describe la primera realizacin de
un sistema de invocacin remota transparente. Hay que
destacar las comparaciones
de eficiencia.
FUOC PID_00184782
13
Un RPC es iniciado por un cliente, que enva una peticin a un servidor remoto para ejecutar un procedimiento o mtodo especfico. En esta llamada,
el cliente enva los parmetros al servidor, proceso que se denomina serializa7
cin y que veremos ms adelante. El servidor computa la respuesta y la enva

al cliente que est bloqueado esperando la respuesta. Al recibirla, la aplicacin
cliente contina su proceso. Hay multitud de implementaciones del paradigma de RPC, normalmente incompatibles entre ellas.
Una diferencia importante de los RPC respecto a las llamadas locales entre objetos o procesos se halla en el hecho de que las llamadas remotas pueden fallar
por problemas de red. Cuando hay un fallo, el emisor tiene que gestionarlo
teniendo en cuenta los aspectos siguientes:
que el mtodo no se haya ejecutado remotamente porque ha fallado la

llamada antes de invocar al mtodo.
que haya fallado la ejecucin del mtodo.
que haya fallado la respuesta con los resultados de la ejecucin del mtodo.
De este modo, y para evitar una compleja gestin de las excepciones, se buscan
mtodos remotos que sean idempotentes, es decir, que en caso de ser ejecutados ms de una vez, el resultado sea el mismo.
Figura 4
La invocacin remota normalmente usa una arquitectura de componentes formada por los elementos siguientes:
El proceso u objeto cliente.
La interfaz del mtodo remoto que es local al cliente y que contiene la

firma de los mtodos que ofrece el objeto remoto. Este componente se
denomina generalmente stub.
(7)
En ingls, marshalling.
FUOC PID_00184782
14
El proceso u objeto remoto.
La interfaz e implementacin del mtodo remoto que es contactada por el
stub y que despus, ya de forma local, invoca el mtodo del objeto remoto.
Generalmente, se le denomina skeleton.
Figura 5
1.4. Publicacin suscripcin

(8)
Se trata de un paradigma de comunicacin asncrono en el que los emisores de mensajes8 no envan sus mensajes a receptores especficos. Por
el contrario, los mensajes se publican en diferentes categoras sin saber
quines son los suscriptores.
Los suscriptores expresan inters en una o ms categoras y solo reciben los

mensajes de aquellas categoras. Este paradigma permite un desacoplamiento
de los emisores y receptores que proporciona una mayor escalabilidad del sistema y topologas de red ms cambiantes o dinmicas.
En ingls, publishers.
FUOC PID_00184782
15
Figura 6
Para poder tener el comportamiento descrito, en el paradigma de publicacin-suscripcin los procesos actan con los siguientes roles:
a) Productor de informacin: aplicacin que tiene la informacin que se
quiere difundir. El productor publica esta informacin sin tener que saber
quin est interesado en recibirla. Enva la informacin a travs de canales.
b) Consumidor de informacin: aplicacin interesada en recibir informacin. El consumidor se suscribe en los canales que diseminan la informacin
que le interesa. Recibe esta informacin por los canales a los que est suscrito.
c)Mediador9: est entre el productor y el consumidor de informacin. Recibe
informacin de los productores y peticiones de suscripcin de los consumidores. Tambin se encarga de encaminar la informacin publicada a los destinatarios suscritos en el canal. Este mediador puede estar distribuido. En este caso,
hace falta que los diferentes mediadores se organicen para proveer los canales.
d)Canal: son los conectores (lgicos) entre los productores y los consumidores de informacin. El canal determina varias de las propiedades de la informacin que se distribuye y de las funcionalidades que se soportan: tipo de
informacin; formato de los datos; posibilidades de personalizacin del canal
por parte del usuario (por ejemplo, la seleccin de contenidos o los modos de
operacin); si el contenido expira o es persistente; la estrategia que se seguir
para hacer las actualizaciones; si los datos se entregan solo una vez (como en
la televisin) o si, en cambio, garantizamos que se pueda recibir el contenido independientemente del momento en que se haya generado; el modo de
operacin (si se le da apoyo por el modo de operacin en desconectado); el
pago (cul es la poltica de pago que se usa: pagar por ver, por tiempo, por
contenido...).
(9)
En ingls, broker.
FUOC PID_00184782
16
Tal como hemos visto, el paradigma de publicacin-suscripcin permite una

distribucin asncrona de informacin. A continuacin indicamos algunas situaciones y aspectos en los que este paradigma puede ser una alternativa apropiada:
a)Localizacin: para los procesos es un problema saber dnde est la informacin que les interesa. Se produce un desacoplamiento entre el proceso y
los datos, dado que es el proceso el que se suscribe a unos canales y entonces
es el proveedor de informacin quien asume el rol activo de hacer llegar su
informacin a los interesados.
b)Focalizacin: como el proceso dice explcitamente cules son sus preferencias, es fcil proporcionar la informacin centrada en sus intereses.
c)Actualidad: los datos se pueden distribuir a medida que se tienen disponibles. El proveedor de informacin puede invalidar los datos obsoletos.
d)Adaptacin10: el proveedor tambin puede decidir qu informacin ve el
receptor y cul no.
e)Reduccindeltrnsito: como el sistema disemina la informacin a quien
est interesado en recibirla, se reduce mucho el trfico en la Red.
El paradigma de publicacin-suscripcin est pensado para proporcionar tres tipos de servicios:

1) Coordinar procesos.
2) Reproducir contenidos.
3) Informar a personas.
Algunos de los campos en que se utilizan aplicaciones implementadas con el

paradigma de publicacin-suscripcin son los siguientes:
a)Gruposdenoticiasylistasdedistribucindecorreo. Los mensajes Usenet y las listas de distribucin de correo se pueden considerar como sistemas
de publicacin-suscripcin algo primitivos. Por ejemplo, los mensajes Usenet
distribuyen artculos por todo Internet. Un servidor de mensajes se suscribe a
otros servidores de mensajes y recibe los mensajes de los grupos a los cuales
est suscrito. Cuando en un grupo se genera un artculo nuevo, el servidor
donde se ha generado el artculo se encarga de que este artculo sea distribuido
hacia otros servidores. Los Usenet estn en desuso hoy en da a pesar de que
todava conservan grandes cantidades de informacin.
(10)
En ingls, tailoring.
FUOC PID_00184782
17
Usenet
Usenet es un histrico sistema de comunicaciones entre redes de computadoras que se
cre en 1979, antes del Internet que hoy conocemos. Se trata de una red formada por
grupos de noticias que incluye discusiones sobre diferentes cuestiones, contenidos musicales, pelculas, series de televisin y documentos digitales.
El funcionamiento es muy similar al de las redes de igual a igual porque los usuarios
comparten los contenidos sin nimo de lucro y sin que una nica empresa los gestione
o controle las descargas.
Como las redes de igual a igual, tambin funciona a travs de un protocolo abierto y
descentralizado.
Actualmente se trata de una alternativa poco utilizada frente a las opciones existentes
en la web o en comparacin con los sistemas de igual a igual de mayor popularidad. Sin
embargo, contienen una importante cantidad de informacin disponible y millones de
archivos compartidos.
b)Bolsaynoticias. Los sistemas que informan sobre la evolucin de las acciones en la bolsa o las agencias de noticias son otro ejemplo de sistemas de
publicacin-suscripcin. En estos sistemas, los usuarios especifican unos intereses y el sistema tiene que garantizar que los usuarios dispongan en todo
momento de la informacin tan actualizada como sea posible.
c) Sistemas de informacin de trnsito. Como en las aplicaciones para la
bolsa y las noticias, la informacin debe enviarse la mayora de las veces en
tiempo real. La informacin tambin se distribuye por medio de ordenadores
o dispositivos mviles.
d)Distribucindesoftware. Muchos sistemas requieren que el software se
actualice frecuentemente, por ejemplo, el gestor de actualizaciones de algunos
sistemas operativos. Utilizando una aplicacin de publicacin-suscripcin se
consigue que el sistema est en funcionamiento continuo y actualizado en la
ltima versin sin problemas de seguridad para las actualizaciones.
e)Serviciosdealertas,monitorizaciones,vigilanciaycontrol.
El paradigma de publicacin-suscripcin normalmente se implementa siguiendo un paradigma de programacin por eventos que facilita la existencia
de publicadores y suscriptores.
1.5. Modelo de programacin por eventos
El paradigma de publicacin-suscripcin requiere de modelos de programacin que faciliten la asincrona y el desacoplamiento entre componentes. De
este modo uno de los paradigmas de programacin ms usados para implementar este modelo de comunicacin es el que se denomina programacin por
eventos.
FUOC PID_00184782
18
En la programacin por eventos, tanto la estructura como la ejecucin

de los programas vienen determinados por los sucesos que ocurren en
el sistema, ya sea definidos por los usuarios o que el programa mismo
provoca.
En la programacin secuencial (o estructurada), es el programador quien define cul es el flujo del programa, mientras que en la programacin dirigida
por eventos, es el propio usuario que acciona el programa quien dirige el flujo
de ejecucin. A cada accin del usuario, se generar un evento al cual el programa dar respuesta.
Un programa dirigido por eventos normalmente implementa una mquina de
estados donde las transiciones de estado vienen dadas por eventos. La tcnica ms usada para la implementacin de la comunicacin por eventos es el
patrn de diseo llamado observador. En este patrn, un proceso u objeto
observador es el encargado de recibir las notificaciones de sus sujetos, es decir, aquellos procesos que generan eventos conocen a los observadores y les
notifican el evento en cuanto sucede.
Este paradigma de programacin se usa para implementar el paradigma de publicacin-suscripcin, pero tambin en el desarrollo de las interfaces grficas
de usuario, en la programacin de sistemas embebidos y en protocolos estndar de mensajera instantnea como XMPP.
Figura 7
En el diagrama de clases UML representado en la figura 7 podemos ver que

el sujeto conoce una lista de observadores que se registran en un momento
dado y que a partir de entonces pueden recibir la notificacin del sujeto. Cada
observador implementa la recepcin de la notificacin segn su conveniencia.
19
FUOC PID_00184782
2. Mecanismos de comunicacin
Hay un amplio abanico de mecanismos de comunicacin que implementan

los paradigmas descritos en el apartado anterior. En este apartado presentaremos los mecanismos con un uso ms amplio.
Cuando dos procesos se comunican, intercambian informacin. Veremos que
este intercambio tiene algunos requisitos.
2.1. Codificacin de datos
Cualquier procedimiento de invocacin remota necesita traspasar datos por la
(11)
En ingls, bytes.
11
Red en forma de secuencia de octetos .

Este intercambio es posible si hay un acuerdo de representacin y de interpretacin de los datos entre ambas partes. Este acuerdo tiene que ser coherente
por lo que se refiere a los aspectos siguientes:
a) El mecanismodecodificacin (y descodificacin) de los argumentos y los
resultados de los datos: un proceso que transforma la informacin, expresada
en forma de estructuras de datos, en una secuencia de octetos. Este proceso
recibe el nombre de conversin, seriacin o marshalling.
b) La interpretacin de los datos: depende del entorno de trabajo y a su vez
est condicionado por la arquitectura del computador, el sistema operativo y
el lenguaje de programacin. Se complica cuando las mquinas que se comunican tienen caractersticas diferentes.
Estos aspectos forman un protocolo, en cuanto al transporte que pone en comunicacin dos procesos situados en los extremos de la Red, con el mecanismo de invocacin (RPC), en lugar del modelo de tubo fiable que ofrece TCP.
2.1.1. La problemtica de la codificacin de datos
Para codificar los datos es necesario seleccionar o convenir un formato de representacin de los datos que van a ser usados como argumentos y resultados
de la invocacin de operaciones remotas. Esto incluye definir qu tipos de
datos se utilizarn: carcter, entero, real, etc., el orden en que se envan los
octetos12, qu repertorio o juego de caracteres se utilizar, y qu caractersticas
tendr nuestro lenguaje de especificacin de datos. Por ejemplo, si se podrn
definir tipos de datos que puedan usar punteros; y cmo hacer corresponder
El marshalling
El mecanismo de seriacin y
deseriacin se denomina marshalling y un-marshalling en honor al general Marshall, un militar que organiz el desembarco de Normanda de la Segunda Guerra Mundial: las tropas
y los efectivos militares se dispusieron con gran orden sobre
la playa de Dover. Un mecanismo cuidadoso y ordenado de
transporte en serie por barco
acab reproduciendo la misma organizacin sobre la playa
de Normanda. Un tanque sera una estructura de datos en
nuestras aplicaciones, un barco
sera un paquete IP, un soldado sera un entero, etc.
(12)
Se conoce con el neologismo

ingls de endianness.
FUOC PID_00184782
20
los tipos de datos y las maneras de construir tipos de datos complejos con el
formato escogido, y con los tipos de datos de los lenguajes de programacin
habituales.
La representacinexternadelosdatos es el convenio que se sigue para

representar estructuras de datos durante el transporte por la Red: para
convertir o seriar argumentos y resultados.
Los tipos de datos ms habituales se corresponden con los tipos de datos primitivos de los procesadores y de los lenguajes de programacin ms populares,
como el C o el C++.
Tipo base: entero, real, carcter, enumerado.
Tipos planos: agregaciones, estructuras, vectores (relleno).
Tipos complejos: con punteros, por ejemplo, rbol (que se ha de allanar,

etc.).
Hay varias estrategias posibles de conversin de los datos representados en cada computador para ser transferidos desde formatos internos hasta un formato
de serie. El objetivo es reducir la complejidad y el coste de conversin de datos:
a) Enviar en el formato interno del emisor.
b) Transformar los datos para enviarlos en el formato interno del receptor.
En ambos casos el problema es complejo, puesto que uno de los extremos no
tiene que hacer nada mientras que el otro tendra que saber cmo representar
los datos para cualquier posible representacin (arquitectura). No parece una
solucin viable.
c) Enviar en una forma cannica intermedia (por ejemplo, como se representan las cabeceras IP que son big-endian). Cada computador slo tiene que saber cmo tiene que hacer la conversin entre su formato interno y el formato
cannico.
d) No conversin, si los dos computadores son similares. En el caso anterior,
puede pasar que dos mquinas con la misma arquitectura interna tengan que
hacer dos conversiones innecesarias para que los datos viajen en el formato
cannico cuando se podran haber comunicado sin hacer ninguna conversin.
Si se pudiera conocer el formato del computador del otro extremo, se podra
optimizar la transferencia ahorrando conversiones superfluas.
FUOC PID_00184782
21
e) En el formato del emisor, que incluye una indicacin de formato, el receptor

convierte. De este modo, el emisor no ha ni de conocer al receptor ni tiene
que efectuar ninguna conversin. El trabajo recae sobre el receptor, que tiene
que aplicar la transformacin necesaria para cada formato posible. En algunos
casos se fijan los formatos y las medidas de los datos, y todo lo que tiene que
hacer el receptor es cambiar el orden de los octetos en algunos datos. Este
ltimo caso se conoce con el trmino endianness, y puede ser de dos tipos:
Little-endian: el octeto menos significativo se guarda en la direccin de

memoria menor, que ser la direccin del dato.
Big-endian: el octeto ms significativo se guarda en la direccin de memoria menor, que ser la direccin del dato.
Figura 8
Formatos little-endian
Son little-endian los procesadores Intel 80X86, Pentium, Alfa, los sistemas operativos Windows, OSF/1 y varios formatos
de archivos.
Formatos big-endian
Son big-endians los procesadores Motorola 680x0, el PARISC de Hewlett-Packard y
el SuperSPARC de Sun. Los
procesadores MIPS de Silicon
Graphics y el PowerPC de IBM/
Motorola pueden trabajar como little-endian y big-endian.
El sistema operativo de Apple
tambin es big-endian, y tambin la mquina virtual de Java. Internet tambin es big-endian: en TCP y en IP se transmite primero el octeto ms
significativo.
La codificacinbinaria consiste en codificar los datos en el nmero

de bits mnimo posible para reducir la cantidad de informacin que se
va a transmitir.
Ejemplos de codificacin
binaria
Algunos ejemplos de protocolos que usan este tipo de codificacin son: el DNS, el LDAP,
el SNMP, el NFS.
En la codificacin binaria, los datos no son legibles una vez transformados y

requieren de un proceso inverso para reconstruir el mensaje inicial. La codificacin binaria permite una comunicacin ms eficiente.
La codificacintextual consiste en transformar cada uno de los datos

que se quieren transmitir a un formato textual, es decir, a un carcter
del alfabeto ASCII.
En esta codificacin, los datos estructurados tambin son transformados a texto, de forma que se necesitan convenios o protocolos de transformacin de
los mismos. Los datos, una vez codificados, mantienen en cierto modo su legibilidad con detrimento de la cantidad de espacio que ocupan.
Ejemplos de codificacin
textual
La codificacin textual es usada por protocolos como HTTP,
SMTP, POP o IMAP.
FUOC PID_00184782
22
En las dos codificaciones, surge el problema de la codificacindelaestructuradelainformacin:
Delimitacin de elementos: cmo marcar el final o el inicio de un elemento en una secuencia.
Tipo de informacin (e interpretacin): cmo expresar qu dato es cada

componente de una coleccin: sobre todo si omitimos alguno al enviarlos
o si su orden es variable.
Estructuracin (pertenencia a un conjunto): cmo indicar que cierto dato

pertenece a una agrupacin.
Delimitacin de datos
Cualquier codificacin tiene que determinar una manera de separar las
partes que componen una secuencia de datos.
Algunas opciones habituales en protocolos de Internet son las siguientes:
Longitudfija: compacta pero inflexible. Slo parece recomendable para

datos de longitud siempre fija, puesto que en datos de longitud variable,
o se desaprovecha mucho espacio o se corre el riesgo de no poder expresar
algn dato, y no habra manera de arreglarlo al omitir la longitud; es un
convenio entre los participantes en una comunicacin: todos tendran que
acordar el cambio para hacer ajustes.
Porlongitud: mejora el anterior, pero se tiene que conocer la longitud

desde el principio. Esto puede ser un inconveniente para el productor de la
informacin, puesto que podra ser necesario tener que generar todos los
datos para poder calcular la longitud y enviar este primer dato. En cambio,
el receptor sabe primero cunto le ocupar el dato y despus puede leer
exactamente los octetos indicados sin dificultad.
Porlongitudafragmentos: se usa cuando la longitud total del dato se

ignora desde el comienzo. Se pueden ir enviando trozos de datos tal como
se van produciendo, hecho que permite que los datos se empiecen a emitir
antes, y que el productor pueda ahorrar memoria dedicada a mantener
datos preparados para la remisin.
Delimitada: en lugar de calcular la longitud, se reserva un smbolo para

separar datos. Si el delimitador aparece entre los datos, se tiene que definir
una manera de ignorarlo.
FUOC PID_00184782
23
2.2. Formatos de codificacin de datos

Hay muchos formatos de datos para el transporte13. Estos formatos que se han
especificado y que se utilizan ampliamente permiten superar la diversidad de
(13)
Tambin denominados con el

trmino ingls wire formats.
lenguajes, sistemas operativos y mquinas. Los formatos ms relevantes son

los siguientes:
a)Textuales:
XML: se usa en el XML-RPC, el SOAP.
JSON: se usa en aplicaciones AJAX.
b)Binarios:
External data representation (XDR): se usa en el RPC (v2; ONC-RPC).
Abstract syntax notation (ASN.1): se usa en varios protocolos, como por

ejemplo: X.509, el SNMP.
Network data representation (NDR): se usa en el DCOM, el DCE-RPC.
Common data representation (CDR): se usa en el CORBA (GIOP, IIOP).
Java remote messaging protocol (JRMP): se usa para comunicar mquinas

virtuales Java (Java-RMI).
2.2.1. Codificacin textual con XML

El lenguaje XML14 es, segn el Consorcio Web, el formato universal para documentos estructurados y datos en la web. Por eso se ha convertido en un
estndar masivamente utilizado para la codificacin de datos interoperables
en Internet.
Varios protocolos usan el XML para codificar (seriar) los datos que se intercambian: por ejemplo, WEBDAV, que es una extensin del protocolo HTTP
para tratar un servidor web como si fuera un servidor de ficheros en red, o el
SOAP, que es un mecanismo de invocacin remota de operaciones.
Aun as, el XML presenta algunas restricciones:
a) Es un formato de codificacin textual y los datos binarios se tienen que
enviar codificados en formato Base64 o se tienen que enviar adems del documento XML (usando un enlace, como hace el HTML para las imgenes).
(14)
XML es la sigla de la expresin

inglesa extensible markup language,
lenguaje extensible de marcas.
FUOC PID_00184782
24
b) Puede requerir bastante texto, aunque despus se puede comprimir usando

un compresor general como gzip o compress, o con un compresor especfico
para el XML como el que estudia el grupo de trabajo sobre caracterizacin
binaria de la XML.
Ejemplo de codificacin textual con XML
En el ejemplo siguiente podis ver un documento XML que se transporta en el protocolo
HTTP para invocar una operacin de un servicio web en el protocolo XML-RPC.
<?xml version="1.0"?>
<methodCall>
<methodName>buscar</methodName>
<params>
<param>
<value>
<struct>
<member>
<name>nombre</name>
<value>Juan</value>
</member>
<member>
<name>edad</name>
<value><i4>42</i4></value>
</member>
</struct>
</value>
</param>
</params>
</methodCall>
</methodCall>
Podis ver que no es una representacin compacta pero s que es muy informativa y fcil de entender. En el caso del XML-RPC, los tipos de los parmetros
se especifican como etiquetas XML, como la i4 para tipos enteros que observamos en el ejemplo anterior. En cambio, otros mecanismos de invocacin ms
complejos como el SOAP se aprovechan ms de las posibilidades del XML.
Ms concretamente, uno de los puntos a destacar de los documentos XML es
la validacin o restriccin de documentos en base a contratos establecidos. En
general, podemos decir que un documento que cumple la sintaxis del XML se
dice que est bien formado. Si adems el documento cumple un conjunto
de restricciones adicionales especificadas por cierto contrato, se puede decir
que es vlido.
Las caractersticasdellenguajedelcontrato, su gramtica (elementos de una
lengua y sus combinaciones), se pueden expresar en una seccin del documento, o en un documento aparte, de dos maneras:
1) DTD, o definicin del tipo de documento, que es el nico formato que
exista a comienzos del XML. La sintaxis de un DTD no es XML y carece de
tipos de datos para restringir los valores.
FUOC PID_00184782
25
2) Esquema XML. Es un formato ms reciente, basado en el XML, con tipos

de datos y capacidad de expresar ms restricciones. Es preferible frente a los
DTD y nos centraremos en ellos a partir de ahora.
El esquema XML es una herramienta muy potente que permite definir tipos
de datos e imponer una serie de restricciones a los datos del documento. As,
el XML Schema permite las restricciones siguientes:
Control sobre los datos: longitud length (nmero de caracteres de la cadena, binario), maxlength (mxima longitud de la cadena, binario), lexical representation (representaciones posibles, por ejemplo, DD-MM-AAAA),
enumeration, maxInclusive (mximo posible), maxExclusive (mximo exclusivo), minInclusive (mnimo posible), minExclusive (mnimo exclusivo), precision (nmero de dgitos), scale (dgitos con parte decimal), encoding (binario).
Control sobre el refinamiento: mecanismos de herencia y extensin.
Control sobre la extensibilidad: abierta, refinable, cerrada.
Estas caractersticas del XML y su XML Schema lo hacen idneo como lenguaje de codificacin de datos interoperable. En esta lnea, se han creado muchos
contratos basados en esquemas XML como el SensorML, MathML, BioML,
XMPP o el SOAP entre otros.
2.2.2. Codificacin textual con JSON
La codificacin JSON15 ha adquirido cierta relevancia como formato ligero para el intercambio de datos en entornos AJAX, sobre todo desde la evolucin de
la web a la Web 2.0. El JSON es un subconjunto de la notacin literal de objetos del Javascript, pero no est restringido a este lenguaje, sino que es usado
por multitud de entornos de programacin.
Tipos de datos del XML

Schema
El XML Schema soporta los tipos de datos siguientes: String
(secuencia de caracter, ISO
10646, unicode), boolean,
real, decimal (real,no Exp), integer [T,0,T], non-negative integer[0,T], positive integer [1,T], non-positive integer
[T,0], negative integer [T,1],
date-Time (iso8601), date (dateTime), time (dateTime), timePeriod (dateTime), binary (dades+codif. hex / base64), uri
(rfc2396), language (es, ca, en,
rfc1766), adems de permitir
los tipos definidos por el usuario.
Una de las ventajas del JSON sobre el XML como formato de intercambio de
datos es que escribir un analizador semntico del JSON es mucho ms sencillo.
En Javascript, el JSON se puede analizar trivialmente usando el procedimiento
eval y por eso se ha popularizado en entornos web de invocacin remota como AJAX. Tambin se ha utilizado como lenguaje de codificacin de servicios
REST16 y en mecanismos de invocacin, como por ejemplo el JSON-RPC.
De todas maneras, el JSON no especifica tipo de datos ni permite restricciones
como el XML y su XML Schema. Es simplemente un formato textual para
agrupar y estructurar contenidos. Aun as, su simplicidad y rapidez hacen que
lo utilicen servidores de Google o Yahoo, donde el volumen del flujo de datos
entre cliente y servidor es muy importante.
(15)
JSON es acrnimo de Javascript

object notation.
(16)
REST es acrnimo de representational state transfer.
FUOC PID_00184782
26
Ejemplo de codificacin textual con JSON

--> {"method": "postMessage", "params": ["Hello all!"], "id": 99}
<-- {"result": 1, "error": null, "id": 99}]]]
2.2.3. Codificacin binaria con XDR

XDR17 es un protocolo de presentacin de datos. Permite la transferencia de
datos entre mquinas de diferentes arquitecturas y sistemas operativos. Sopor-
(17)
XDR es acrnimo de eXternal

data representation.
ta todos los tipos del lenguaje C excepto el puntero a funcin. Define la forma
cannica intermedia que usa para transmitir los datos.
El sistema de archivos distribuido NFS utiliza XDR como un lenguaje de descripcin de datos para el intercambio de datos; se utiliza con las llamadas a
procedimiento remoto ONC RPC.
El estndar de XDR
El estndar de XDR est definido en el RFC 4506 (RFC 1014
y RFC 1832 obsoletos).
Figura 9
(18)
ASN.1 es acrnimo de abstract

syntax notation one.
2.2.4. Codificacin binaria con ASN.1

La notacin sintctica abstracta 1 o ASN.118 es un metalenguaje para representar datos independientemente del hardware, del sistema operativo y de sus
formas de representacin de datos internos. Es usado entre otros por el protocolo SNMP. Se caracteriza por permitir la representacin de objetos de longitud
muy grande de una manera compacta.
Caractersticas:
Formato: {etiqueta, longitud, valor}.
Usa etiquetas de tipos, 8 bits, multiocteto.
Longitud en octetos del valor: si < 127 ocupa 1 octeto.
Valor: por ejemplo, entero (integer) complemento a 2, big-endian.
Reglasdecodificacin:
FUOC PID_00184782
27
BER: basic ...; no muy eficientes, mucha redundancia, admite extensin.
DER: distinguished ...; no tiene opciones (por seguridad); longitud codificacin definida.
CER: canonical ...; no tiene opciones (por seguridad); longitud codificacin

no definida.
PER: packet ...; muy compactos, poco extensible.
LWER: light weight; casi estructura interna, codificacin/descodificacin rpida.
Campodelongitud:
Si longitud: 0-127 octetos 0, longitud, valor
Si longitud > 127 1, valor, valor (incluye longitud)
Tipocompuesto:
Figura 10
Tiene un rendimiento menor que el XDR, puesto que es ms complejo, el alineamiento de valores en palabras es peor, la (des)seriacin es algo ms compleja (por ejemplo, para tratar el campo longitud).
Figura 11
28
FUOC PID_00184782
Finalmente, presentamos una tabla resumen de algunos metalenguajes de codificacin.

Nombre
Binario
Legible
ASN.1
S (BER, CER, DER, PER, ECN)
S (XER, va ECN)
BSON
No
Comma-separated values
(CSV)
No
JSON
No, pero vase BSON
Netstrings
OGDL
Si (Esquema 1.0 binario)
Property list
Protocol buffers
Parcial
S-expressions
No
Structured data eXchange For- S

mats
No
Thrift
Parcial
eXternal Data Representation
No
XML
Parcial (XML binario)
YAML
No
2.3. Mecanismos de invocacin remota

Como hemos visto, el mecanismo de invocacin remota, o RPC19, es una ampliacin del mecanismo de invocacin de funciones que permite invocar cdigos remotos como si fueran locales. El proceso cliente invoca una funcin
que parece ser el cdigo servidor (stub cliente) pero slo recoge y enva los datos de entrada por red a otro cdigo del servidor (stub servidor) que invoca la
funcin solicitada. Los resultados de la invocacin siguen el camino inverso.
Sera ideal que la separacin no se notara (diramos un mecanismo transparente,
en el sentido que no se percibe), pero no es fcil, puesto que una red como
Internet tiene un comportamiento ms complejo que el bus interno de un PC:
se pierden, desordenan y duplican paquetes, y a veces la Red falla.
Para hacer transparente (invisible) la llamada, hace falta introducir nuevos
mecanismos para transportarla por la Red. Esta tarea la hacen unos nuevos
componentes llamados stubs.
(19)
RPC es la sigla de la expresin

inglesa remote procedure call.
FUOC PID_00184782
29
(20)
En ingls, middleware.
(21)
En ingls, interfaces.
Los stubs constituyen el cdigo intermedio encargado de gestionar conexiones remotas entre el cliente y el servidor, y establecer protocolos
de codificacin y de parmetros y resultados de la invocacin remota.
Los stubs son as los artfices de la transparencia de acceso y localizacin
en el software intermediario20 de invocacin remota de procedimientos.
Para la generacin de estos stubs, es necesario comprender el papel de las in21
terfaces
remotas.
En local, los lenguajes de programacin organizan el programa en mdulos que se comunican entre ellos mediante llamadas a procedimientos. Para controlar las interacciones entre mdulos, la interfaz de cada
mdulo define la firma de los procedimientos o funciones que pueden
ser invocados.
En invocacin remota, es imprescindible definir una interfaz de los procedimientos o servicios que se van a llamar remotamente. A partir de la informacin de firmas y parmetros de esta interfaz, las herramientas de generacin
de stubs podrn crear el cdigo intermedio necesario para hacer estas llamadas
remotas transparentes al programador.
Siguen este modelo de invocacin los mecanismos de llamada de ONC-RPC
y RMI, que operan en un entorno homogneo: el mismo lenguaje de programacin y, en el caso de Java-RMI, la misma mquina (la mquina virtual de
Java). Esta separacin entre la mquina proceso que solicita un servicio y
quien lo lleva a cabo posibilita la introduccin de variantes que permiten, en
general, la interaccin entre sistemas heterogneos en los aspectos siguientes:
Arquitectura (formato: medida y organizacin de datos).
Lenguaje de programacin (afecta a la forma de invocar y trasladar argumentos).
Entorno a ejecucin (sistema operativo).
El soporte a la heterogeneidad provoca una complejidad ms grande del entorno. Se pueden controlar ms parmetros, pero el programador est obligado a tratar con estos: la llamada no es transparente, sino que el programador tiene que escribir mucho (decidir varios aspectos) para hacer cualquier
invocacin remota.
FUOC PID_00184782
30
De este modo, en los mecanismos de invocacin remota que soportan la heterogeneidad, es usual la utilizacin de un lenguaje de definicin de interfaces
(IDL22).
(22)
IDL es la sigla de la expresin

inglesa interface definition language.
Este IDL es independiente del lenguaje de programacin y a partir de l se

podrn crear generadores de stubs para diferentes lenguajes de programacin.
La ventaja fundamental del soporte a la heterogeneidad reside en el hecho
de que se podrn comunicar programas escritos en diferentes lenguajes de
programacin que se ejecutarn en diferentes sistemas operativos. Siguen este
modelo de invocacin en entorno heterogneo los mecanismos de llamada de
CORBA y SOAP.
En un sentido amplio, el protocolo HTTP que se utiliza en la web tambin
es una RPC: es un protocolo de peticin/respuesta. Todos los navegadores
invocan las mismas operaciones a los servidores: doc=get(uri), hede(uri, doc),
tabla(uri, text), y las operaciones de edicin que usan datos codificados en
XML: res=propfind(uri, args), res=proppatch(uri, args), etc. Una generalizacin de
estos mecanismos para el RPC es el adoptado en el XML-RPC o en SOAP, por
ejemplo.
2.3.1. Servicios de nombres
Otro aspecto que se tiene que tener en cuenta es cmo encontrar un servicio
distribuido que se ejecuta en otra mquina en la Red. La manera ms inmediata
es conocer la direccin IP y el puerto donde el servicio se ejecuta. Aun as, esto
va en contra del principio de transparencia de acceso esencial en cualquier
tipo de software intermediario. Si el servicio remoto cambiara de localizacin
en la Red, todos los clientes tendran que cambiar la direccin.
Para conseguir esta transparencia se utilizan los denominados servicios de nom23
bres .
Un servicio de nombres mantiene una lista de asociaciones entre

nombres (identificadores simblicos) y valores (direcciones de red). Por
ejemplo, el DNS mantiene, en ASCII, las asociaciones entre nombres de
dominio e IP asociadas.
(23)
En ingls, naming systems.
FUOC PID_00184782
31
Figura 12. Funcionamiento del RMI Registry
(1) El servidor registra el objeto remoto.

(2) El cliente busca el objeto remoto en el registro.
(3) El cliente invoca el mtodo en el objeto remoto.
De este modo, ya no tenemos que conocer la IP de la pgina web que queremos

solicitar y adems se consigue transparencia de acceso. Es decir, puede cambiar
(24)
ce.
En ingls, CORBA Naming Servi-
la IP del servidor de manera transparente para los clientes. En el caso de la

invocacin remota de procedimientos, los servicios de nombres almacenan el
identificador simblico del servicio (echoService) y su IP y los puertos asociados.
Los clientes usan el identificador simblico para obtener la direccin real del
servicio y conectarse. Es el caso del RMIRegistry en el Java RMI o el servicio de
nombres24 de CORBA.
Finalmente, puede destacarse que hay servicios de nombres ms sofisticados,
como UDDI o LDAP, que permiten bsquedas sofisticadas de informacin asociadas al servicio. Por otro lado, en el contexto de los servicios web, es muy
comn localizar servicios directamente usando la URL.
2.3.2. Conectores (sockets)
En el ao 1983 se desarrollaron una serie de llamadas en el mbito del ncleo25
de Unix para facilitar el diseo de aplicaciones que se comunicaran en red.
Estas llamadas, junto con algunas funciones auxiliares de la biblioteca estndar
de UNIX, pasaron a formar la llamada interfaz de programacin de sockets.
Un conector o socket es un punto de acceso a los servicios de comunicacin en el mbito de transporte. Cada socket tiene asociada una direccin que lo identifica. Conocindola, se puede establecer una comunicacin con un socket para que acte como extremo de un canal bidireccional.
(25)
En ingls, kernel.
FUOC PID_00184782
32
Los conectores26 representan la implementacin del paradigma de paso de

mensajes que hemos visto anteriormente. La importancia de los conectores
radica en el hecho de que la mayora de mecanismos de comunicacin acaban
usando los conectores como mecanismo final de transmisin de datos. Con
esto queremos decir que, por ejemplo, la implementacin de los servicios web
con SOAP o de una invocacin remota con RMI acaba usando un conector
para transmitir la informacin, a pesar de que esto es transparente al usuario
del mecanismo.
La biblioteca de conectores se caracteriza por ser simple y ofrecer las funcionalidades bsicas para la creacin del conector y la lectura y escritura a travs
de l. Hay varias implementaciones de esta biblioteca, entre otros, los Berkeley Sockets, que son los que ofrece el ncleo de Linux. WinSock es otra implementacin usada por los sistemas operativos de Microsoft que tambin se basa
en los Berkeley Sockets.
Ejemplos de los mtodos que ofrece la biblioteca de Berkeley Sockets
Algunos ejemplos de los mtodos que ofrece esta biblioteca son:
socket(): crea un conector de un cierto tipo.
bind(): usado en el lado del servidor para asociar el conector a una direccin y un
puerto.
listen(): utilizado en la banda servidor para poner el conector en estado de LISTEN.
connect(): usado en el cliente para conectarse a una direccin y puerto del servidor.
Al finalizar la llamada, se establece la conexin.
accept(): utilizado en el servidor para aceptar una conexin.
send() y recv(), o write() y read(), o recvfrom() y sendto(): se usan para recibir y leer datos
de un conector.
close(): se cierra la conexin (en caso de ser TCP). Se liberan los recursos.
gethostbyname() y gethostbyaddr(): se usan para resolver nombres y direcciones.
select(): se usa para seleccionar los conectores que estn preparados para lectura/escritura o con errores.
piojo(): se usa para verificar el estado del conector.
La figura 13 ilustra el ciclo de vida de un conector TCP u orientado a la conexin. Una vez el conector se ha creado en el lado del servidor y se vincula a
una direccin y un puerto, se mantiene a la espera de peticiones por parte del
cliente. Cuando el cliente invoca el connect, el servidor acepta la peticin y se
establece la comunicacin.
(26)
En ingls, sockets.
FUOC PID_00184782
33
Figura 13. Ciclo de vida de un conector TCP
La figura 14 muestra los diagramas de operaciones en el ciclo de vida de un

conector UDP o no orientado a la conexin. Un conector del lado del servidor
se crea, se vincula, a una direccin y un puerto, y espera hasta que recibe datos
de un cliente.
Figura 14. Ciclo de vida de un conector UDP
Los conectores son mecanismos de comunicacin ofrecidos por la capa de

transporte, que no se encarga de ofrecer mecanismos de seguridad y proteccin
de la informacin que se transmite por un canal. Por ello, tienen que ser las
capas superiores las que se encarguen de proteger los datos que se transmiten
por un canal. Entre otros, hay protocolos de nivel aplicacin que permiten
establecer comunicaciones seguras como son Transporte Layer Security (TLS)
o Secure Socket Layer (SSL), que proveen de mecanismos criptogrficos para
asegurar las conexiones extremo a extremo sobre la capa de transporte.
34
FUOC PID_00184782
2.3.3. Protocolos RPC

En este subapartado se presentarn algunos de los protocolos RPC ms relevantes.
RMI
La invocacin remota de mtodos de Java es un modelo de objetos distribuidos diseado especficamente para el lenguaje Java, por lo cual mantiene la
(27)
VM es la sigla de la expresin
inglesa virtual machine.
semntica del modelo de objetos locales de Java y facilita de este modo la implantacin y el uso de objetos distribuidos. En el modelo de objetos distribuidos de Java, un objeto remoto es aquel cuyos mtodos pueden ser invocados
por objetos que se encuentran en una mquina virtual (VM27) diferente. Los
objetos de este tipo se describen por una o ms interfaces remotas que contienen la definicin de los mtodos del objeto que es posible invocar remotamente.
(28)
28
La invocacinremotadeunmtodo ( RMI ) es la accin de invocar

un mtodo de una interfaz remota de un objeto remoto. La invocacin
de un mtodo de un objeto remoto tiene exactamente la misma sintaxis
de invocacin que la de un objeto local.
Las metas que se pretende conseguir al soportar objetos distribuidos en Java

son:
Proporcionar invocacin remota de objetos que se encuentran en VM diferentes.
Permitir llamadas a los servidores desde los applets.
Integrar el modelo de objetos distribuidos en el lenguaje Java de una manera natural, conservando en la medida de lo posible la semntica de los
objetos Java.
Hacer tan simple como sea posible la escritura de aplicaciones distribuidas.
Preservar la seguridad proporcionada por el entorno Java.
Proporcionar varias semnticas para las referencias de los objetos remotos

(persistentes, no persistentes y de activacin retrasada).
En general, una invocacin remota implicar los siguientes pasos:

A)Enelservidor
RMI es la sigla de la expresin

inglesa correspondiente a invocacin remota de un mtodo.
35
FUOC PID_00184782
1) Definir la interfaz del servicio que ser accesible remotamente. En el RMI,

para hacer que un objeto sea remoto se tiene que declarar que implementa la
interfaz Remote. Como la invocacin remota puede fallar, cada mtodo de la
interfaz declara tambin la excepcin java.rmi.RemoteException en la seccin
throws.
2) Implementar el cdigo del servicio cumpliendo esta interfaz y generar los
stubs correspondientes. En el RMI, el compilador o generador de stubs se denomina rmic y es el encargado de generar cdigo intermedio. En las versiones
actuales ya no es necesario generar stubs de servidor (skeletons) en tiempo de
compilacin (en versiones anteriores a la 1.2 es necesario). El entorno RMI usa
reflexin en tiempo de ejecucin para hacer las invocaciones.
3) Finalmente, se instancia el objeto servidor y se publica o registra en un servicio de nombres para hacerlo accesible a los clientes. En el RMI, el servicio de
nombres se denomina RMIRegistry, accesible a travs del API java.rmi.Naming.
B)Enelcliente
1) A partir de la interfaz del servicio remoto, generar los stubs de cliente. Esto
(29)
En ingls, dynamic proxies.
se puede realizar en tiempo de compilacin o de ejecucin. En compilacin,

rmic genera los stubs (por defecto, en el protocolo JRMP) necesarios para la
invocacin remota. Aun as, no es necesario con los servidores intermediarios
dinmicos29, permite obviar el uso de rmic. Se produce as una generacin de
stubs dinmica en tiempo de ejecucin.
2) El cliente puede ahora localizar el servidor mediante el servicio de nombres
e invocar las operaciones remotamente. En esta fase, tambin se pueden obtener stubs de cliente dinmicamente bajndolos de un servidor al localizar
el servicio.
Finalmente, hay que destacar que el Java RMI permite el paso por referencia30
31
o el paso por valor . Para invocar los mtodos de un objeto remoto, en lugar
de una copia del objeto, la mquina donde est el objeto remoto enva un
objeto stub (su servidor intermediario o representante que acta en referencia
al objeto remoto), que se construye dinmicamente y se carga durante la ejecucin, cuando es necesario.
Para hacer que un objeto pueda viajar se tiene que seriar (Java object serialization). Los datos y el cdigo de la implementacin tienen que trasladarse y crear
una copia de estos en el lugar remoto. Esto implica que cualquier clase Java que
sea serializable puede ser pasada por parmetro entre objetos remotos RMI.
(30)
porreferencia: los mtodos de

objetos remotos se pueden invocar desde lejos (otras mquinas
virtuales).
(31)
porvalor: el objeto migra

completamente por la Red; resulta un objeto local y sus mtodos se
invocan localmente.
Reflexin en Java
La reflexin es la posibilidad de
que un programa pueda averiguar las propiedades de un objeto, como la lista de mtodos,
los argumentos y los tipos. Permite construir en tiempo de
ejecucin, de una manera dinmica, un stub para cualquier
objeto.
FUOC PID_00184782
36
Ejemplo de invocacin de un mtodo remoto en una aplicacin Java

A continuacin, un ejemplo de una pequea aplicacin Java que invoca un mtodo remoto. El objeto Java HelloImpl.java contiene la implementacin del objeto remoto (el
servidor):
public class HelloImpl extends UnicastRemoteObject implements Hello {
public HelloImpl() throws RemoteException {
super();
}
public String sayHello() {
return "Hola amigos!";
}
public static void main(String args[]) {
if (System.getSecurityManager() == null) {
// Crear e instalar un gestor de seguridad
System.setSecurityManager(new RMISecurityManager());
}
try {
HelloImpl obj = new HelloImpl();
// Asociar esta instancia al nombre "HelloServer"
Naming.rebind("//myhost/HelloServer", obj);
System.out.println("HelloServer asociado al registro");
} catch (Exception y) {}{
System.out.println("Error" + e.getMessage());
}
}
}
Un cliente que localiza el objeto servidor obtiene a cambio un stub dinmico, e invoca
el mtodo remoto sayHello():
try {
obj = (Hello)Naming.lookup("/server/HelloServer");
message = obj.sayHello();
} catch (Exception y) {
System.out.println("Excepcin:" + e.getMessage());
}
RMI y Java ofrecen en su API objetos para gestionar la seguridad de la aplicacin, como por ejemplo evitando que un applet pueda acceder a disco, o
controlando los puertos que pueden abrir para establecer conexiones. Uno de
estos objetos es el SecurityManager, al que se le pueden especificar diferentes
polticas de seguridad para una aplicacin.
Hay que mencionar que con posterioridad han aparecido mecanismos parecidos en otros lenguajes de programacin como es el caso de Remoting en Csharp (C#).
SUN-RPC
El RFC 1831 describe el SUN-RPC, que fue diseado para la comunicacin
cliente-servidor por el sistema de ficheros en red NFS de SUN. Tambin se
denomina ONC-RPC (open network computing) y es usado por varios sistemas
operativos de SUN as como en las distribuciones de NFS. En este protocolo, los
desarrolladores pueden hacer uso de RPC sobre conexiones UDP o TCP segn
sus preferencias. SUN-RPC usa XDR como metalenguaje de codificacin de
datos y un generador de stubs para el lenguaje de programacin C denominado
rpcgen.
Lectura complementaria
R.Srinivasan (agosto, 1995).
RPC: Remote Procedure Call
Protocol Specification Version 2. Internet RFC 1831.
FUOC PID_00184782
37
El programa cliente importa la interfaz de servicio apropiada y hace la llamada

a los procedimientos remotos, como por ejemplo READ o WRITE. Los stubs
generados por rpcgen se encargan de seriar y deseriar la informacin y hacen
transparente el proceso de invocacin remota. SUN-RPC no tiene un servicio
de nombres, sino que los vnculos se hacen de forma local mediante un servicio llamado port mapper que se ejecuta en cada ordenador. Cada port mapper mantiene informacin de los servicios locales que se ejecutan. Cuando un
cliente importa una interfaz, tiene que especificar la direccin del servidor,
as como el nmero que identifica el programa y la versin, que se usan para
discernir el servicio que se devuelve.
En el cdigo siguiente vemos cmo un cliente invoca un mtodo read de un
servidor remoto.
/* File: C.c - cliente del FileReadWrite service. */
#include <stdio.h>
#include <rpc/rpc.h>
#include "FileReadWrite .h"
main(int argc, char ** argv)
{
CLIENT *clientHandle;
char *serverName = "coffee";
readargs a;
Data *data;
/* crea el socket y obtiene un apuntador al servicio*/
clientHandle= clnt_create(serverName, FILEREADWRITE, VERSION, "udp");
if (clientHandle==NULL){
clnt_pcreateerror(serverName); /* no podemos contactar servidor */
exit(1);
}
a.f = 10;
a.position = 100;
a.length = 1000;
data = read_2(&a, clientHandle);/* llamamos al read remoto */
...
clnt_destroy(clientHandle);
/* cierra el socket */
}
El implementador de la parte del servidor usa el fichero de cabecera creado por

rpcgen como interfaz que define los mtodos que tiene que ofrecer el servidor.
El cdigo servidor es, pues, un compendio de implementaciones de mtodos
ms un programa principal y un conjunto de rutinas para la seriacin y deseriacin creadas por rpcgen.
/* File S.c - servidor del FileReadWrite service */
FUOC PID_00184782
38
#include <stdio.h>
#include <rpc/rpc.h>
#include"FileReadWrite.h"
void * write_2(writeargs *a)
{
/* do the writing to the file */
}
Data * read_2(readargs * a)
{
static Data result;
/* tiene que ser static */
result.buffer = ...
/* leemos el fichero */
result.length = ...
/* cantidad leda del fichero */
return &result;
}
Las caractersticas principales de SUN-RPC se pueden resumir en los puntos

siguientes:
Utiliza el XDR como lenguaje de codificacin.
No garantiza la semntica como mximo una vez.
Funciona sobre el UDP, permite la difusin32.
Seleccin: el UDP selecciona el proceso, el RPC, el procedimiento.
Port mapper (puerto 111): nm. de programapuerto.
Mensajes limitados a un tamao de como mximo IP (32 kb).
Autenticacin en cada peticin.
Servidor sin estado.
Si la retransmisin llega al servidor mientras la respuesta viaja hacia el
(32)
En ingls, broadcast.
cliente, no nota el duplicado; s que lo nota durante proceso, y lo elimina. Esta memoria de corto plazo no es problema en una red local.
XML-RPC o invocacin sobre web (HTTP)
El protocolo de transferencia de la web, el HTTP, fue concebido como un mecanismo de peticin/respuesta en el que se intercambian mensajes y se invocan mtodos predefinidos (GET, HEAD, HEDE, TABLA, DELETE, PROPFIND,
(33)
CGI es la sigla de la expresin

inglesa common gateway interface.
39
FUOC PID_00184782
PROPPATCH). Con la aparicin del servidor HTTPD de NCSA se defini un

mecanismo simple (interfaz comn de pasarela o CGI33) para invocar mandos
al estilo de los filtros Unix: el servidor web invoca un mando con entrada estndar y argumentos proporcionados en la peticin HTTP y con salida estndar de vuelta a la respuesta HTTP. Se trata de servicios que reciben de un navegador el contenido de un formulario HTML codificado en un formato simple
y devuelven un cdigo HTML para que un navegador lo presente. Sirven para
que las personas que utilizan un navegador puedan acceder a servicios, pero
no para que un proceso pueda invocar operaciones.
Aun as, y a pesar de la orientacin del protocolo HTTP a la obtencin y el
acceso a documentos remotos, varios mecanismos de invocacin remota lo
han utilizado como protocolo de comunicacin entre cliente y servidor. Esto
se debe en primer lugar al hecho de que es un protocolo abierto y flexible
utilizado masivamente en Internet, pero tambin a razones de seguridad. La
mayora de organizaciones permiten el trnsito HTTP externo pero limitan con
cortafuegos las comunicaciones TCP o UDP no conocidas. Por eso, el CORBA
o la RMI que funcionen sobre TCP o UDP pueden encontrar problemas de
comunicacin entre puntos remotos de la red Internet.
Uno de los primeros mecanismos de invocacin remota que adopt el HTTP
como protocolo de comunicacin es el denominado XML-RPC. Como su nombre indica, este protocolo ha escogido el XML como lenguaje de codificacin
de datos entre cliente y servidor. La utilizacin del XML y el HTTP hace que
el XML-RPC sea un protocolo idneo para intercomunicar servicios heterogneos en diferentes lenguajes y plataformas.
Invocacin de una operacin (en lenguaje Python):
-> x.buscar({'nombre':'juan','edad':42})
<- {'id': 123456}
La invocacin de la operacin anterior desencadena los siguientes intercambios de objetos en el HTTP:

Invocacin:
<methodCall>
<methodName>buscar</methodName>
<params>
<param>
<value>
<struct>
<member>
<name>nombre</name>
40
FUOC PID_00184782
<value>juan</value>
</member>
<member>
<name>edad</name>
<value><i4>42</i4><value>
</member>
</struct>
</value>
</param>
</params>
</methodCall>
</html>
Para construir un servicio web, son necesarios diferentes componentes:
Un protocolo de peticin/respuesta que se pueda comunicar con un proceso en un servidor: el HTTP.
Un formato de representacin de los datos que se intercambian en una

invocacin: el XML puede ser la base para construirlo, aunque otros como
el JSON tambin se pueden utilizar.
Una interfaz de programacin para invocar servicios de las aplicaciones

web. El XML-RPC define un conjunto de tipo limitado al hecho de que
cada lenguaje tendr que mapear sus tipos propios. Adems, los tipos son
etiquetas XML y no tipos predefinidos en el XML Schema. Es una aproximacin muy sencilla para favorecer que su implementacin tambin sea
muy sencilla. Como consecuencia de esto, se han implementado bibliotecas XML-RPC en gran cantidad de los lenguajes de programacin existentes.
Respuesta:
<?xml version='1.0'?>
<methodResponse>
<params>
<param>
<value>
<struct>
<member>
<name>id</name>
<value><int>123456</int></value>
</member>
<member>
<name>nombre_completo</name>
<value>juan perez</value>
</member>
Tipo de datos XML-RPC

<y4> o <int>
<boolean>
<string>
<double>
<dateTime.iso8601>
<struct>
<array>
<base64>
41
FUOC PID_00184782
</struct>
</value>
</param>
</params>
</methodResponse>
Se tiene que tener en cuenta que el XML-RPC se ha diseado para ser muy
ligero y muy simple. Por eso, no es comparable en funcionalidades a sistemas
como el CORBA o la RMI. As, el XML-RPC no define interfaces remotas, no
tiene compilador o generador de stubs, no dispone de servicios de nombres, no
tiene excepciones y no ofrece paso por referencia. Est diseado para servicios
sin estado con una interfaz muy simple, donde para localizar el servicio se
utiliza la URL estndar del servidor. Adems, el cliente tiene que conocer los
parmetros y los tipos del servicio previamente para poderlo invocar; toda la
responsabilidad queda en el cliente. Por eso no es necesaria la generacin de
stubs.
SOAP
La invocacin de objetos distribuidos mediante tecnologas RMI, CORBA o
DCOM tiene un problema fundamental de interoperabilidad entre sistemas
heterogneos. En consecuencia, ha sido necesario utilizar complejos puentes
y pasarelas34 que permitieran la traduccin de protocolos y su comunicacin.
De este modo, sistemas desarrollados en tecnologas Microsoft (DCOM) encontraban dificultades para comunicarse con sistemas basados en el CORBA.
Adems, el uso de puertos propietarios y codificacin binaria ha ocasionado
tambin problemas debido a cortafuegos y redes corporativas protegidas. Para
resolver estos problemas, la tendencia actual es apostar por protocolos abiertos e interoperables, como el HTTP como canal de transporte y el XML como
lenguaje de codificacin de informacin. En esta lnea, la compaa Userland
empez definiendo el protocolo XML-RPC como protocolo sencillo de invocacin remota basado en el HTTP y el XML. Ms tarde, Userland y Microsoft
desarrollaron un protocolo de invocacin remota ms completo y complejo
denominado SOAP.
SOAP son las siglas de simple object access protocol, especificacin de un

protocolo para el intercambio de informacin estructurada de la implementacin de los Servicios Web. SOAP usa XML como metalenguaje de
codificacin de los datos y hace uso de otros protocolos como HTTP
y RPC para la negociacin y transmisin de mensajes. SOAP ofrece los
servicios y funcionalidades de mensajera bsicas para permitir la definicin de otros servicios web a ms alto nivel, dado que, en cierto modo, se puede considerar la capa fundamental de los protocolos de los
servicios web.
(34)
En ingls, bridges.
FUOC PID_00184782
42
1)LosmensajesSOAP
Como hemos visto, SOAP es un protocolo simple basado en XML que permite
que las aplicaciones intercambien informacin sobre HTTP.
Un mensaje SOAP es un documento ordinario en XML que contiene los siguientes elementos:
Un elemento envelope, que identifica el documento XML como mensaje

SOAP.
Un elemento header, que contiene informacin de cabecera del mensaje.
Un elemento body, que contiene informacin sobre la llamada y la respuesta.
Un elemento fault, que contiene informacin de error y de estado.
Todos los elementos se declaran en el espacio de nombres por defecto del elemento envelope.
Esqueleto de un mensaje SOAP
<?xmlv version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Header>
...
</soap:Header>
<soap:Body>
...
<soap:Fault>
...
</soap:Fault>
</soap:Body>
</soap:Envelope>
a)Elelementoenvelope
El elemento envelope es la raz del mensaje SOAP y define el documento como mensaje SOAP. El xmlns:soap namespace siempre tomar el valor http://
www.w3.org/2001/12/soap-envelope, dado que define el envelope como envelope de SOAP. Si se usara otro espacio de nombres, la aplicacin generara un
error y descartara el mensaje.
El atributo encodingStyle se usa para definir los tipos de datos del documento.
El atributo puede aparecer en cualquier elemento SOAP y se aplica al propio
elemento y a sus descendientes (hijos). Un mensaje SOAP no tiene una definicin de tipo por defecto sino que siempre se tiene que enlazar a alguna. Para
hacerlo usaremos:
FUOC PID_00184782
43
soap:encodingStyle="URI"
b)Elelementoheader
El elemento header es opcional y contiene informacin especfica de la aplicacin, como por ejemplo, informacin de autenticacin, de pago, etc.
Si existe un elemento header, este ser el primero de los hijos (descendientes)
del elemento envelope.
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
<soap:Header>
<m:Trans xmlns:m="http://www.uoc.edu/transaction/" soap:mustUnderstand="1">
234
</m:Trans>
</soap:Header>
...
...
</soap:Envelope>
El ejemplo contiene un header con el elemento trans, un atributo mustUnderstand con valor 1 y un valor 234.
SOAP define tres atributos en el espacio de nombres por defecto http://
www.w3.org/2001/12/soap-envelope. Estos atributos son mustUnderstand, actor, y encodingStyle.
Los atributos de header definen cmo lo tiene que procesar el receptor del
mensaje. El atributo mustUnderstand se usa para indicar al receptor si tiene
que saber procesar el elemento, o no. Si el elemento mustUnderstand = 1, el
receptor tiene que entender el valor que recibe por este elemento. En caso de
que no lo reconozca, el receptor fallar indicando que no ha podido procesar
el header.
<soap:Header>
<m:Trans xmlns:m="http://www.uoc.edu/transaction/" soap:actor="http://www.uoc.edu/appml/">
234
</m:Trans>
</soap:Header>
...
FUOC PID_00184782
44
...
</soap:Envelope>
El atributo actor se usa para dirigir el elemento header a un destinatario especfico. La sintaxis es:
soap:actor="URI"
c)Elelementobody
Cada uno de los hijos del elemento body tiene que indicar su espacio de nombres.
<soap:Body>
<m:GetNotes xmlns:m="http://www.uoc.edu/notes">
<m:Item>Redes</m:Item>
</m:GetNotes>
</soap:Body>
</soap:Envelope>
El ejemplo hace una peticin de la nota de la asignatura Redes de la UOC. Se

hace notar que los elementos m:GetNotes e item son elementos especficos de
la aplicacin. La respuesta tendra un aspecto parecido a:
<soap:Body>
<m:GetNotesResponse xmlns:m="http://www.uoc.edu/notes">
<m:Nota>Notable</m:Nota>
</m:GetNotesResponse>
</soap:Body>
</soap:Envelope>
d)Elelementofault
Elemento opcional que es usado para indicar errores e informacin de estado.
Si este elemento est presente, siempre ser descendiente del elemento body.
El elemento fault slo aparecer una vez como hijo del elemento body.
45
FUOC PID_00184782
El elemento fault tiene los siguientes subelementos:

Subelemento
Descripcin
<faultcode>
Cdigo para identificar el error.
<faultstring>
La explicacin del error.
<faultactor>
Informacin sobre quin ha causado el error.
<detail>
Informacin especfica de la aplicacin.
2)CdigosfaultdeSOAP
Los cdigos del subelemento faultcode son:
Error
Descripcin
VersionMismatch
Se ha encontrado un namespace invlido en el elemento envelope.
MustUnderstand
No ha sido entendido un hijo del elemento header con el atributo

mustUnderstand con valor 1.
Cliente
El mensaje est mal formado o el contenido es incorrecto.
Server
Ha habido algn error en el servidor, o el mensaje no ha podido

ser procesado.
3)InterfacesSOAP:lenguajededescripcindeservicioswebowebservice
descriptionlanguage(WSDL)
Como en cualquier tecnologa de invocacin remota, es necesario establecer
un contrato que defina el servicio ofrecido. Este contrato definir el nombre de
los mtodos y los tipos de los parmetros y el resultado de estos. El WSDL es un
lenguaje XML que define el nombre de los mtodos y los tipos de parmetros
que aceptan. Adems, en cada lenguaje habr herramientas que generen stubs
a partir del contrato (WSDL2Java, WSDL2C#, WSDL2Python...).
A diferencia del Java RMI, tanto los clientes como los servidores SOAP se
pueden implementar en cualquier lenguaje de programacin (con bibliotecas
SOAP, est claro). WSDL es tambin un estndar del W3C.
Veamos un ejemplo de WSDL para la siguiente clase Java:
public class Calculator {
public int add(int y1, int y2) {
return y1 + y2;
}
public int subtract(int y1, int y2) {
return y1 - y2;
}
FUOC PID_00184782
46
El WSDL tendra el aspecto siguiente:

<wsdl:definitions targetNamespace="http://localhost:8080/axis/Calculator.jws">
<!-WSDL created by Apache Axis version: 1.2RC3
Built on Feb 28, 2005 (10:15:14 EST)
-->
<wsdl:message name="subtractRequest">
<wsdl:part name="i1" type="xsd:int"/>
</wsdl:message>
<wsdl:message name="subtractResponse">
<wsdl:part name="subtractReturn" type="xsd:int"/>
</wsdl:message>
<wsdl:message name="addResponse">
<wsdl:part name="addReturn" type="xsd:int"/>
</wsdl:message>
<wsdl:message name="addRequest">
</wsdl:message>
<wsdl:portType name="Calculator">
<wsdl:operation name="add" parameterOrder="i1 i2">
<wsdl:input message="impl:addRequest" name="addRequest"/>
<wsdl:output message="impl:addResponse" name="addResponse"/>
</wsdl:operation>
<wsdl:operation name="subtract" parameterOrder="i1 i2">
<wsdl:input message="impl:subtractRequest" name="subtractRequest"/>
<wsdl:output message="impl:subtractResponse" name="subtractResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="CalculatorSoapBinding" type="impl:Calculator">
<wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="add">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="addRequest">
<wsdlsoap:body encodingStyle=http://schemas.xmlsoap.org/soap/encoding/
namespace="http://DefaultNamespace" use="encoded"/>
</wsdl:input>
<wsdl:output name="addResponse">
namespace="http://localhost:8080/axis/Calculator.jws" use="encoded"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="subtract">
FUOC PID_00184782
47
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="subtractRequest">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://DefaultNamespace" use="encoded"/>
</wsdl:input>
<wsdl:output name="subtractResponse">
namespace="http://localhost:8080/axis/Calculator.jws" use="encoded"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="CalculatorService">
<wsdl:port binding="impl:CalculatorSoapBinding" name="Calculator">
<wsdlsoap:address location="http://localhost:8080/axis/Calculator.jws"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
Podemos observar que en este fichero encontramos una definicin de las operaciones ofrecidas por el servicio (portType, operation), de los mensajes de solicitud y respuesta intercambiados (message) incluidos el tipo de parmetros
(type), y de los protocolos de comunicacin (bindings).
Figura 15
En general, no ser necesario que el programador conozca el formato del lenguaje WSDL. Hay herramientas automatizadas que generan el WSDL a partir
de cdigo en cada lenguaje de programacin. Aun as, slo los tipos bsicos
estn estandarizados en el SOAP.
As, por ejemplo, la correspondencia estndar para Java es la siguiente:
xsd:base64Binary byte[]
xsd:boolean boolean
xsd:byte byte
xsd:dateTime java.util.Calendar
xsd:decimal java.math.BigDecimal
FUOC PID_00184782
48
xsd:double double
xsd:float float
xsd:hexBinary byte[]
xsd:int int
xsd:integer java.math.BigInteger
xsd:long long
xsd:QName javax.xml.namespace.QName
xsd:short short
xsd:string java.lang.String
Observamos en la figura 15 que el SOAP s que utiliza en su codificacin tipo estndar XML del XML Schema como xsd:string o xsd int entre otros. En
realidad, se pueden usar otros esquemas XML de codificacin.
Lo que se describe de este modo sigue el esquema referenciado con la URL
http://schemas.xmlsoap.org/soap/encoding/.
La utilizacin de otros tipos complejos ya depende de cada lenguaje y entorno.
Algunas veces se tiene que implementar la codificacin (o usar alguna herramienta del entorno). En general los arrays son aceptados en la mayora de
implementaciones como estructura de datos compuesta. Aun as, colecciones
complejas pueden no ser reconocidas por otras implementaciones del SOAP
en lenguajes diferentes.
En trminos de seguridad, SOAP ofrece ampliaciones para la inclusin de certificados en cada mensaje. Aparte, un mensaje SOAP se puede enviar a travs
de un canal asegurado con TLS o SSH, del mismo modo que lo podemos hacer
con las conexiones HTTP.
2.3.4. Localizacin de servicios
Para invocar servicios remotos desde un cliente, primero hay que localizarlos
mediante algn mtodo. As, es posible usar localizaciones directas al servicio
(incluyendo el servidor y el puerto) o bien mediante algn servicio de nom-
(35)
IOR es la sigla de la expresin

inglesa interoperable object reference.
bres remoto. En CORBA, por ejemplo, los localizadores directos se denominan

IOR35 y el servicio de nombre es el CORBA naming service.
En el RMI podemos usar el RMIRegistry como servicio de nombres para localizar
objetos. Para localizar servicios SOAP podemos utilizar la URL de su WSDL
como localizador directo o bien usar el servicio denominado UDDI36.
De todas maneras, por la simplicidad de la localizacin directa por la URL,
los desarrolladores acostumbran a evitar el uso de UDDI en favor del mtodo
directo. En esta lnea, los servicios web en Internet publican la URL de su WSDL
en pginas web para que los clientes los puedan invocar.
(36)
IOR es la sigla de la expresin

inglesa universal description, discovery and integration.
49
FUOC PID_00184782
Tambin hay pginas web especializadas, como www.xmethods.net, con listas

de servicios pblicos que incluyen la URL de cada uno de ellos. El uso de UDDI se asocia ms a modelos empresariales en los que, de manera similar a las
pginas amarillas, los clientes puedan descubrir los servicios web empresariales que necesitan. En esta lnea, Microsoft ofrece su Microsoft UDDI Business
Registry como herramienta para acceder.
El nivel de descubrimiento37 permite as que un consumidor de servicios pue-
(37)
En ingls, discovery.
(38)
En ingls, bind.
da obtener descripciones de servicios. Los dos mecanismos disponibles son

Universal Description, Discovery And Integration (UDDI) y el lenguaje de inspeccin de servicios web (WS-inspection).
Esto permite cerrar el ciclo de un servicio web:
Un proveedor de servicio que publica su oferta de servicio en un registro

de servicios.
Un registro de servicios que recoge ofertas y puede ser examinado por un

consumidor de servicios.
Un consumidor de servicios que busca cierto servicio en un registro de

38
servicios y, cuando lo encuentra, conecta
con el proveedor de servicio
seleccionado para invocarle operaciones con SOAP.

A su vez, sobre estos niveles se construyen sistemas ms complejos como .NET,
de Microsoft, o ebXML, de las Naciones Unidas, para apoyar a servicios de
integracin entre empresas.
2.3.5. REST
La sigla REST39 da nombre a un protocolo de comunicacin de aplicaciones
basado en HTTP y XML.
Originariamente, REST haca referencia a una arquitectura de aplicaciones en red, pero el trmino ha sido generalizado para referirse a cualquier interfaz web que usa HTTP y XML para el intercambio de informacin. Se diferencia de SOAP o XML-RPC porque REST no usa ninguna abstraccin adicional fuera de las que ofrece el propio HTTP.
(39)
REST es la sigla de la expresin

inglesa representational state transfer.
RESTful
Los sistemas que siguen los
principios REST se llaman con
frecuencia RESTful.
FUOC PID_00184782
50
REST, pues, engloba dos conceptos, el de una arquitectura de aplicaciones, y

el de una forma de comunicacin entre aplicaciones basada en XML. En este
subapartado nos interesa especialmente la segunda de las definiciones de REST.
Para comprender REST tenemos que tener muy presente cmo funciona hoy
en da la web, y ms concretamente, HTTP:
En la web los agentes de usuario interactan con los recursos, y los recursos
son todo aquello que puede ser denominado y representado. Cada recurso
se puede resolver a travs de una nica interfaz (URI).
La interaccin con los recursos (ubicados a travs de su URI nico) se realiza mediante una interfaz uniforme usando los verbos estndar de HTTP
(GET, POST, PUT y DELETE). Tambin es importante en la interaccin la
declaracin del tipo del recurso, que es designado mediante el encabezamiento HTTP Content-Type (XHTML, XML, JPG, PNG y JSON son algunos
tipos de medios conocidos).
Los recursos se describen a ellos mismos. Toda la informacin necesaria

para procesar una solicitud de un recurso est dentro de la misma solicitud
(que permite que los servicios sean sin estado).
Los recursos contienen vnculos a otros recursos (enlaces multimedia).
Figura 17
Una arquitectura de
aplicaciones
Un estilo de arquitectura es un
conjunto de restricciones que
se pueden aplicar al crear algo. Un estilo de arquitectura
de software es un conjunto de
restricciones que describen las
caractersticas que pueden utilizarse para guiar la implementacin de un sistema de software. REST es un estilo de arquitectura que se puede utilizar para crear software, en el
cual los clientes (agentes de
usuario) pueden efectuar peticiones de servicios (extremos).
REST es una forma de implementar un estilo de arquitectura de cliente/servidor, de hecho, REST explcitamente se
basa en el estilo de arquitectura de cliente/servidor.
FUOC PID_00184782
51
Un pequeo ejemplo
Imaginmonos que la UOC os quiere ofrecer un servicio de consulta de notas. Este servicio nos podra dar nuestra nota de la asignatura que le pidiramos.
Al crear el servicio RESTful, podramos responder a las siguientes preguntas:
1) Cules sern los recursos?
2) Cules sern los identificadores URI que se usarn para identificar los recursos?
3) Qu verbos de HTTP permitiremos?
Los recursos en nuestro servicio REST son las asignaturas, los estudiantes y las notas. De
este modo se construira la representacin en XML de estos tres recursos: notas, asignaturas y estudiantes. (La representacin de los recursos puede ser en otro meta-lenguaje de
definicin. No hace falta que sea XML.)
Una vez definidos los recursos se definiran las URI para estos recursos. La definicin solo
hace falta que sea relativa, dado que la identificacin absoluta vendr dada por la URL
del servidor en la que se ejecutar el servicio. En nuestro ejemplo podramos utilizar /
{alumno}, /{asignatura} y /{nota} como URI de cada uno de los recursos. As pues, /{Jos
Armengol}/{Estructura de redes de computadores (05.098)/{B} correspondera a la nota B
del alumno Juan Armengol para la asignatura Estructura de redes de computadores (75.098).
Finalmente, para determinar las operaciones que se pueden hacer sobre el recurso, solamente tenemos que ver que este ser de solo lectura, puesto que es una aplicacin de
consulta para los estudiantes; as pues, permitiramos la operacin GET.
VentajasdeREST
REST se est convirtiendo en un mecanismo bastante usado, dado que ofrece
un conjunto de ventajas que lo hacen idneo para aplicaciones web de gran
escala. Las caractersticas son las siguientes:
Almacenableenmemoriascach (cacheable). Como una peticin REST

no deja de ser una peticin HTTP sin estado, es fcilmente almacenable
en las memorias cach que hay en la Red. Esto hace que el mecanismo
favorezca la escalabilidad del sistema, dado que peticiones consecutivas
slo consultan una vez el servidor, para reducir as la carga del sistema.
Escalable. El hecho de que los mecanismos REST estn basados en HTTP,

permite que hereden las propiedades de HTTP. Por lo tanto, REST es ampliamente escalable, y esta caracterstica se ve favorecida por el hecho de
que los recursos son autodescritos y, en consecuencia, no establecen dependencias ni requerimiento del mantenimiento de un estado.
Inalterable. Como REST utiliza los verbos de HTTP (GET, POST, PUT y
DELETE), el protocolo no se puede alterar y mantiene as la simplicidad
de su utilizacin.
Interoperable. El hecho de que los recursos se definan en un lenguaje independiente del cdigo de las mquinas cliente y servidor, y que la comunicacin se haga usando un protocolo estndar como es HTTP permite a
diferentes tecnologas y arquitecturas de hardware utilizar este mecanismo
FUOC PID_00184782
52
de comunicacin sin la necesidad de conocer las particularidades de cada

extremo.
Simple. REST ofrece cuatro primitivas bsicas que permiten interactuar

con recursos descritos con URI. Cualquier conjunto de funcionalidades se
puede desarrollar con estas herramientas, y convierte REST en un protocolo extremadamente sencillo.
Finalmente, hay quien puede pensar que REST es un poco restrictivo si los
sistemas que se tienen que construir son muy complejos, dado que ciertas
funcionalidades pueden parecer difciles de implementar con las primitivas
(GET, POST, PUT y DELETE). Como siempre, esta decisin queda en manos
del desarrollador.
FUOC PID_00184782
53
Resumen
El mdulo ha presentado los principales paradigmas de comunicacin, que

incluyen el paso de mensajes en los que dos objetos, procesos o aplicaciones,
usan primitivas para la comunicacin explcita bidireccional. El paso de mensajes es uno de los paradigmas de comunicacin ms usados y es implementado, por ejemplo, por los conectores (sockets).
Hemos visto tambin que hay otros paradigmas como la memoria compartida,
donde, si los procesos se encuentran en la misma mquina, pueden compartir
un espacio de direcciones que les permite intercambiar informacin. En caso
de que las aplicaciones sean distribuidas, hay implementaciones que permiten
compartir memoria de manera remota; una de ellas son las tuple spaces.
La invocacin remota de procesos y la invocacin remota de mtodos dan
nombre a un paradigma en el que procesos u objetos pueden invocar mtodos
a otras aplicaciones u objetos remotos como si fueran la misma mquina. Este
paradigma requiere de mecanismos de codificacin de la informacin que se
quiere transmitir, puesto que los procesos u objetos pueden estar implementados en lenguajes de programacin diferentes o estarse ejecutando en hardwares diferentes. Como mximos exponentes de este paradigma, hemos visto
RMI, XML-RPC y SOAP.
El mdulo nos ha presentado el paradigma de comunicacin basado en eventos, en los que la comunicacin es del todo asncrona y nos permite un desacoplamiento entre los emisores de los eventos y sus receptores.
Tambin hemos visto el paradigma de publicacin-suscripcin, muy usado en
modelos orientados a objetos, en el desarrollo de entornos grficos de usuario
y aplicaciones distribuidas de gran escala.
FUOC PID_00184782
55
Bibliografa
Birman, K. P. (2005). Reliable distributed systems: technologies, web services, and applications.
springer middleware for communications. Qusay Mahmoud: Wiley 2004.
Burke, B. (2006). Enterprise JavaBeans 3.0. OReilly Media.
Cerami, E. (2002). Web services essentials (OReilly XML). OReilly Media.
Cornell, G.; Horsmann, C. (1996). Core Java. Prentice Hall.
Coulouris, G.; Dollimore, J.; Kindberg, T. (2005). Distributed systems: concepts & design
(4. ed.). Addison-Wesley. [Traduccin al castellano: Sistemas distribuidos: conceptos y diseo
(2001, 3. ed.). Pearson.]
Englander, R. (2002). Java and SOAP. OReilly Media.
Loosemore, S.; Stallman, R. M.; McGrath, R.; Oram, A.; Drepper, U. (1992). The
GNU. C library reference manual. Boston: Free Software Foundation.
Mrquez Garca, F. M. (1996). UNIX. Programacin avanzada. Madrid: Ra-ma.
Oberg, R. (2001). Mastering RMI: developing enterprise applications in Java and EJB. John Wiley
& Sons.
Orfali, R. (1998). Client/server programming with Java and CORBA. Nueva York: Wiley & sons.
Pacheco, P. (2000). Parallel programming with MPI. Morgan Kaufmann.
Peterson, L.; Davie, B. (2003). Computer networks: a system approach (3. ed.). EUA: Morgan-Kauffman.
Rifflet, J. M. (1992). Comunicaciones en UNIX. Madrid: McGraw-Hill.
Sinha, P. (1997). Distributed operating systems: concepts & design. IEEE Press.
Sridharan, P. (1997). Advanced Java networking. Prentice Hall.
St. Laurent, S. (2001). Programming web services with XML-RPC. Reilly Media.
Stevens, W. R. (2005). Advanced programming in the UNIX environment (2. ed.). Addison-Wesley Professional.
Tanembaum, A.; Steen, M. (2007). Distributed systems: principles and paradigms, 2/E. Prentice Hall.
Pginas web:
RMI
W3C, Web Services Architecture
JAX-WS
DCOM

Mecanismos de Comunicacion M1

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Mecanismos de Comunicacion M1

Загружено:

Авторское право:

Доступные форматы

Mecanismos de

Paso de mensajes .........................................................................

Memoria compartida ...................................................................

Invocacin remota ......................................................................

Publicacin suscripcin ...............................................................

Modelo de programacin por eventos ........................................

Codificacin de datos .................................................................

La problemtica de la codificacin de datos .................

Formatos de codificacin de datos .............................................

Codificacin textual con XML ......................................

Codificacin textual con JSON .....................................

Codificacin binaria con XDR ......................................

Codificacin binaria con ASN.1 ....................................

Mecanismos de invocacin remota ............................................

Servicios de nombres .....................................................

Conectores (sockets) .......................................................

Protocolos RPC ..............................................................

Localizacin de servicios ...............................................

Hoy en da no nos podemos plantear la existencia de ninguna aplicacin que

Con el estudio de este mdulo alcanzaris los objetivos siguientes:

1. Conocer los diferentes paradigmas de comunicacin entre procesos, aplicaciones u objetos.

Desde el momento en que existe la posibilidad de ejecutar procesos de forma

Comunicacinsncrona (o sincrnica): es el intercambio de informacin

Comunicacinasncrona (o asincrnica): es aquella comunicacin que

En este paradigma, los programadores organizan sus programas como

Estas API de paso de mensajes suelen incluir:

Primitivas de paso de mensajes punto a punto. Desde las tpicas operacio-

En ingls, send y receive.

nes de transmisin y recepcin , hasta variaciones especializadas de estas.

Primitivas de sincronizacin. La ms habitual es la primitiva de barrera,

Primitivas de comunicaciones colectivas. Varias tareas participan en un

La implementacin especfica de un mecanismo de paso de mensajes tiene

Si el envo ser fiable.

Si el envo garantizar el orden de la informacin transmitida.

Si los mensajes se envan uno a uno (unicast o de igual a igual), uno a

Si la comunicacin es sncrona o asncrona.

Hay multitud de implementaciones de este paradigma, de las cuales podemos

1.2. Memoria compartida

La memoria compartida es una forma muy rpida de comunicar procesos (en

oposicin al paso de mensajes, como en el caso de los conectores ). Por otro

buida . Estos sistemas permiten compartir una cantidad de memoria de forma

En ingls, distributed shared memory.

La implementacin de sistemas de memoria compartida distribuida requiere

Algunos ejemplos tpicos

de un modelo de consistencia de los datos logrado por un protocolo que man-

Ejemplos tpicos de sistemas

tiene la coherencia de los datos.

RPC es la sigla de la expresin

1.3. Invocacin remota

La invocacin remota es un paradigma de comunicacin de procesos

La particularidad de los mtodos RPC es que el programador de la aplicacin

cin y que veremos ms adelante. El servidor computa la respuesta y la enva

que el mtodo no se haya ejecutado remotamente porque ha fallado la

que haya fallado la ejecucin del mtodo.

El proceso u objeto cliente.

La interfaz del mtodo remoto que es local al cliente y que contiene la

El proceso u objeto remoto.

La interfaz e implementacin del mtodo remoto que es contactada por el

1.4. Publicacin suscripcin

Los suscriptores expresan inters en una o ms categoras y solo reciben los

Tal como hemos visto, el paradigma de publicacin-suscripcin permite una

El paradigma de publicacin-suscripcin est pensado para proporcionar tres tipos de servicios:

Algunos de los campos en que se utilizan aplicaciones implementadas con el

En la programacin por eventos, tanto la estructura como la ejecucin