Introduccin a la programacin distribuida

Diego J. Bodas Sagi

INTRODUCCIN A LA PROGRAMACIN DISTRIBUIDA

Diego J. Bodas Sagi
CES Felipe II (UCM)
dbodas@cesfelipesegundo.com
RESUMEN: Pretendemos en estas lneas realizar una breve introduccin a los conceptos
bsicos de la programacin distribuida, qu es y por qu surge. Al mismo tiempo analizaremos
las distintas tecnologas surgidas para la realizacin de entornos de programacin distribuida,
todo ello teniendo como referencia JAVA, dado el potencial de este lenguaje para la creacin
de sistemas distribuidos.
Introduccin a la programacin distribuida
Los sistemas distribuidos surgen para dar solucin a las siguientes necesidades:
1. Repartir el volumen de informacin.
2. Compartir recursos, ya sea en forma de software o hardware.
La construccin de sistemas distribuidos presenta una solucin que aumenta nuestras
capacidades, ya no estamos sujetos a las restricciones de la mquina, ahora somos capaces
de utilizar los recursos de toda una red.
Los dos tipos principales de sistemas distribuidos son los sistemas computacionales
distribuidos y los sistemas de procesamiento paralelo. En programacin distribuida, un conjunto
de ordenadores conectados por una red son usados colectivamente para realizar tareas
distribuidas. Por otro lado en los sistemas paralelos, la solucin a un problema importante es
dividida en pequeas tareas que son repartidas y ejecutadas para conseguir un alto
rendimiento.
Los sistemas distribuidos se pueden implementar usando dos modelos: el modelo
cliente servidor y el modelo basado en objetos.
El modelo de cliente-servidor contiene un conjunto de procesos clientes y un conjunto
de procesos servidor, se precisan adems de unos recursos (software), todos los estos
recursos son manejados por los procesos servidor. Cliente y Servidor deben hablar el mismo
lenguaje para conseguir una comunicacin efectiva, el primero solicita al segundo unos
recursos y este ltimo los concede, le hace esperar o lo deniega segn los permisos que tenga.
En el modelo Orientado a Objetos hay una serie de objetos que solicitan servicios
(clientes) a los proveedores de los servicios (servidores) a travs de una interfaz de
encapsulacin definida. Un cliente enva un mensaje a un objeto (servidor) y ste decide qu
ejectutar, RMI y CORBA son algunos de esos sistemas basados en objetos.
La programacin distribuida no es fcil:
-

Hay mltiples modelos, dependiendo de los sistemas a los que accedemos.

Debemos considerar seriamente muchos aspectos de seguridad.
Se mezclan diversas tecnologas de varios vendedores.
Dificultar para probar y depurar.

Llegados a este punto ya podemos darnos cuenta de una de las principales dificultades de
la programacin distribuida cmo se comunican cliente y servidor?, a travs de que
lenguaje, entorno o herramienta?, es aqu cuando debemos hacer referencia a Java, Java es
una herramienta ideal para programacin distribuida debido a su portabilidad, seguridad y
amplio abanico de componentes. Desarrollando en Java podemos llegar a olvidarnos de dnde
vamos a ejecutar nuestro programa, ser en una mquina UNIX o en un servidor Windows

Introduccin a la programacin distribuida

Diego J. Bodas Sagi

2000 Server?, y es ms, lo podemos preparar para que se ejecute en varios entornos
diferentes? Con Java todo esto es posible.
Finalicemos esta seccin dando una definicin muy bsica:
-Un sistema distribuido consiste en una coleccin de ordenadores autnomos unidos por
una red y con un sistema que les permite compartir recursos de hardware, software y
datos.
La cuestin bsica en la programacin de un sistema distribuido es cmo comunicarse con
otras mquinas a travs de la red. Resumiremos aqu diversas formas de atacar la
programacin de aplicaciones a travs de la red.
SOCKETS
Los sockets son puntos finales de enlaces de comunicaciones entre procesos. Los
procesos los tratan como descriptores de ficheros, de forma que se pueden intercambiar datos
con otros procesos recibiendo y transmitiendo a travs de sockets, el tipo de socket describe la
forma en la que se transfiere la informacin.
Sockets proveen al usuario de un interfaz para comunicarse a travs de la red con otro
sistema. Cada direccin de identificacin para sockets consiste en una direccin de Internet y
en un puerto. Se suelen utilizar los conocidos protocolos TCP/IP o UDP/IP, preferentemente el
primero.
Distinguimos los siguientes tipos de sockets:
-

Sockets Stream: Son un servicio orientado a la conexin, donde los datos se

transfieren sin encuadrarlos en registros o bloques.

Sockets Datagram: Son un servicio de transporte sin conexin, son ms eficientes que
TCP pero su utilizacin no es del todo fiable. Los datos se envan y reciben en
paquetes cuya entrega no est garantizada.

Sockets Raw: son sockets que dan acceso a protocolos de ms bajo nivel, no estn
soportados por Java.

Existe un nuevo tipo de sockets muy particular e importante:

-

Un socket Multicast es un DatagramSocket con una serie de capacidades adicionales

para enlazar con grupos y hosts en Internet

Una de las ventajas principales de la programacin con sockets es su sencillez.

Enviando Proceso

Recibiendo Proceso

Sistema Operativo

Sistema Operativo

Socket
A la hora de desarrollar una aplicacin con sockets debemos tener en cuenta lo siguiente:

Introduccin a la programacin distribuida

Diego J. Bodas Sagi

Es necesario tratar de manera especial los sockets para evitar problemas de seguridad, lo
hacemos a travs de la clase de Java SecurityManager y del paquete java security,
podemos a travs de estos recursos incluso generar mensajes codificados a travs de
algoritmos DSA.

Generalmente conectamos con servidores PROXY.

A la hora de conectar con BBDD, JDBC debe ser una opcin a tener en cuenta, JDBC es
un modelo de conexin a BBDD diseado por JAVA, su utilidad radica en que es til para
acceso a bases de datos de diferentes tipos y vendedores, SQL Server, Oracle, etc.

Dentro de las diversas tcnicas de programacin destaca la serializacin. La

serializacin de objetos es una tcnica mediante la cual un programa puede salvar el estado de
los objetos a un fichero y despus recuperar los datos a la memoria y enviarlos a travs de la
red usando sockets de bajo nivel. Esta es una opcin muy interesante que hara posible evitar
lo que hoy en da se hace continuamente en proyectos comerciales, el recurrir a una base de
datos para guardar el estado de un objeto, lo que repercute en el rendimiento final de la
aplicacin y sobre todo en su arquitectura. Java lo implementa con la interfaz
java.io.Serializable.
RMI (Remote Method Invocation)
RMI fue el primer framework con la idea de crear sistemas distribuidos que apareci para Java.
Adems, viene integrado en cualquier mquina virtual Java posterior a la versin 1.0 y est
pensado para hacer fcil la creacin de sistemas distribuidos a partir de una aplicacin cuyas
clases ya estn implementadas. RMI es una forma de RPC (Remote Procedure Call).
La invocacin de mtodos remotos permite que un objeto que se ejecuta en una mquina
puede invocar mtodos de un objeto que se encuentra en ejecucin bajo el control de otra
mquina (por supuesto no hay problemas para las relaciones entre los objetos cuando ambos
son locales). En definitiva, RMI permite crear e instanciar objetos en mquinas locales y al
mismo tiempo crearlos en otras mquinas (mquinas remotas), de forma que la comunicacin
se produce como si todo estuviese en local. RMI se convierte as en una alternativa muy viable
a los sockets de bajo nivel con una serie de particularidades destacables:
-

RMI permite abstraer las interfaces de comunicacin a llamadas locales, no

necesitamos fijarnos en el protocolo y las aplicaciones distribuidas son de fcil
desarrollo.
RMI te permite trabajar olvidndote del protocolo.
RMI es flexible y extensible, destaca su recolector de basura.

Cliente

Servidor

Stubs

Skeletons

Remote Reference Layer

Transport Layer

Arquitectura RMI

Introduccin a la programacin distribuida

Diego J. Bodas Sagi

Arquitectura de RMI:
-

stub/skeleton: es responsable de transferir datos a Remote Reference Layer, permite a

los objetos java ser transmitidos a diferentes espacios de direcciones.
Remote Reference Layer es responsable de crear independencia de los protocolos.
Transpor Layer es responsable de establecer las conexiones a los espacios remotos de
direcciones.

En RMI toda la informacin sobre los servicios del servidor se dan en una definicin de
interface remota.
Si comparamos RMI con sockets percibiremos que RMI es ms simple. Adems, esta
tecnologa permite despreocuparnos del protocolo, en sockets depende de la aplicacin, si sta
es grande puede que nos tengamos que preocupar del protocolo.
CORBA
Hasta ahora hemos hablado de tcnicas de programacin que adquieren
implementacin a travs de unas clases o interfaces definidas, con CORBA (desarrollado por
OMG un consorcio de 700 compaas) el concepto cambia totalmente, CORBA (Common
Object Request Broker Architecture) ES UNA ESPECIFICACIN PARA CREAR Y USAR
OBJETOS DISTRIBUIDOS NO UN LENGUAJE DE PROGRAMACIN. Desarrollar
aplicaciones distribuidas con CORBA es similar a hacerlo con RMI porque una interfaz debe
ser definida primero, pero las interfaces de RMI son definidas en JAVA mientras que las de
CORBA emplean IDL.
Los objetos CORBA son diferentes porque:
-

Pueden ejecutarse en cualquier plataforma.

Se pueden situar en cualquier punto de la red (ventaja)

El uso de CORBA es ms complejo de lo que hemos visto hasta ahora, pero tambin
bastante ms completo.
Otra de las caractersticas y al mismo tiempo diferencias con RMI es que CORBA fue
desarrollado con un lenguaje independiente donde los objetos de mueven en un sistema
heterogneo, RMI fue desarrollado para un lenguaje simple donde los objetos se desenvuelven
en un entorno con un lenguaje homogneo, adems CORBA soporta parmetros de entrada y
salida pero RMI no, lo cual son una ventajas claras de CORBA sobre RMI sin embargo
debemos tener en cuenta que los objetos CORBA no tienen recolector de basura y es nuestra
obligacin preocuparnos de ello, al contrario que con RMI.

Cliente

Implementacin

IDL

Cliente

IDL

Implimentacin

IDL

ORB

IDL

ORB

RED
CORBA: Ejemplo comunicacin

Introduccin a la programacin distribuida

Diego J. Bodas Sagi

Reflejamos a continuacin algunas ventajas y desventajas de trabajar con CORBA:

A. Ventajas
1) Disponibilidad y Versatilidad
2) Eficiencia
3) Adaptacin a Lenguajes de programacin
B. Desventajas
1) Complejidad
Permitir la interoperabilidad de distintos lenguajes, arquitecturas y
sistemas operativos hace que sea un estndar bastante complejo, y su uso no
sea tan transparente al programador como sera deseable:
1. Hay que usar un compilador que traduce una serie de tipos de datos
estndares a los tipos del lenguaje en el que se vaya a programar (IDL)
2. Hay que ser conscientes a la hora de disear qu objetos van a ser remotos
y cules no (los remotos sufren restricciones en cuanto a sus capacidades con
respecto a un objeto normal)
3. Es necesario emplear tipos de datos que no son los que proporciona de
manera habitual el lenguaje de programacin (muchas veces hay que emplear
tipos de datos adaptados de IDL).
2) Incompatibilidad entre implementaciones
Muchas empresas ofrecen implementaciones CORBA, si bien el grado
de cumplimiento es diverso. Las divergencias entre ORBs radican en detalles
que, aunque no hacen imposible aplicar en uno el mismo diseo de un
programa pensado para otro, hacen que la adaptacin sea fastidiosa.
Cuestiones como la colocacin de libreras o las diferentes formas de
implementar la gestin de la concurrencia, hacen difcil la portabilidad del
cdigo y obligan al programador a reciclarse cuando quiere cambiar de ORB.
Adems, donde el estndar no concreta, las implementaciones pueden variar
entre s, lo que da lugar a molestas incompatibilidades que complican la vida al
usuario.
IDL es el lenguaje especfico que se ha creado para implementar las especificaciones
CORBA, Java tiene soportados todas las caractersticas principales de IDL. Algunas las
caractersticas ms destacables de IDL son:
-

IDL nombres e identificadores son mapeados como nombres Java sin cambios.

Un constructor IDL puede ser mapeados a varios constructores java, los nombres
adicionales se crean aadiendo sufijos descriptivos.

El nombre de un objeto es la nica referencia

Un cliente primero debe obtener una referencia a un objeto, despus establece una
conexin con l a travs de un interfaz y finalmente crea un objeto proxy si es
necesario, y devuelve una referencia al objeto.

IDL soporta herencia simple y mltiple (destacar que la herencia mltiple no est
soportada por java, para este tipo de cosas tenemos tie mechanist).

Introduccin a la programacin distribuida

Diego J. Bodas Sagi

Dentro de las mltiples tecnologas desarrolladas en torno a CORBA cabe mencionar a

Caffeine (Inprise Corporation - Visibroker for Java). Caffeine tiene las siguientes ventajas:
-

Podemos definir nuestras interfaces mejor que con IDL.

Podemos pasar objetos por valor y por referencia.
Proporciona aplicaciones con una estructura similar a una de RMI pero generamos
IIOP compiladores de Stubs y Skeletons.

Por otra parte y si tanto cliente como servidor van a usar Java, y buscamos una
solucin sencilla para crear un sistema distribuido, la mejor opcin ser RMI. RMI es sin duda
la opcin ms integrada en Java, la de uso ms natural para un programador de Java y que
adems aporta un buen nmero de utilidades. Sin embargo su sencillez se puede transformar
en inflexibilidad si se quieren hacer cosas que los creadores de RMI no contemplan.
Por ltimo, si se quiere garantizar una casi absoluta capacidad de eleccin para
cualquier parmetro del sistema distribuido o si no vale Java para ambos extremos de la
comunicacin, la solucin es CORBA. Escoger CORBA sera slo la primera de las decisiones
que habra que tomar para crear un sistema distribuido, la siguiente sera escoger qu
implementacin de CORBA elegir, para lo cual hay muchos factores que evaluar: soporte del
lenguaje y plataforma que se quiere usar, precio, cumplimiento del estndar, servicios
adicionales, velocidad o soporte son slo algunas de las posibilidades. La eleccin de la
implementacin es algo que no se debe menospreciar porque una vez tomada una decisin es
difcil cambiar. Esto es as puesto que aunque las diferentes implementaciones son
interoperables, existen bastantes diferencias a la hora de programar como para que exista
portabilidad binaria o de fuentes, incluso si ambas implementaciones soportan el mismo
subconjunto o superconjunto de CORBA.
Por otro lado, CORBA es casi lo opuesto a RMI. Donde este aporta sencillez, CORBA
aporta un cierto nivel de complejidad. El premio a este esfuerzo es un sistema es flexible y que
se adapta a casi cualquier entorno de computacin existente.
AGENTES MOVILES
Los agentes mviles son entidades que circulan libremente por la red esperando
llamadas del cliente. Representan un nuevo paradigma en la programacin distribuida.
Estos agentes mviles presentan una serie de ventajas principales:
- Eficiencia: consumen menos recursos de red
- Utilizan menos ancho de banda
- Son robustos y tolerantes a fallos.
- Soportan entornos heterogneos.
- Buenos para aplicaciones de comercio electrnico.
- Fcil desarrollo.
Las cuestiones de seguridad son especialmente importantes en los agentes mviles, se
pretende cubrir dos objetivos:
-

Proteger a los host de agentes destructivos.

Proteger a los agentes de host maliciosos.

La solucin estndar a estas cuestiones de seguridad consiste en utilizar la autentificacin

y la firma digital.
Voyager es una plataforma de computacin 100% distribuida en Java que es til para crear
sistemas distribuidos de alto impacto rpidamente.
El uso de Voyager lleva consigo una serie de beneficios como pueden ser:
-

Productividad

Introduccin a la programacin distribuida

-

Diego J. Bodas Sagi

Compatibilidad
Eficiencia
Flexibilidad

Adems presenta una serie de innovaciones:

-

Remote enabling a class

Control de excepciones
Basura distribuida
Agregacin dinmica
CORBA
Movilidad
Agentes mviles autnomos
Activacin
Seguridad

Voyager viene sobradamente preparado para integrarse con CORBA, generando las
clases IDL de la aplicacin.
SOAP
SOAP (Simple Object Access Protocol) es un protocolo basado en XML que permite
comunicar componentes y aplicaciones mediante el conocido HTTP. Sera similar a hacer RPC
(llamada a procedimientos remotos) mediante HTTP y XML. De hecho es la evolucin del
protocolo XML-RPC que permite hacer llamadas a procedimientos remotos usando XML como
lenguaje comn y HTTP como protocolo de transporte.
Internet fue diseada para que mltiple sistemas se pudiesen comunicar entre si. Lo
ideal es que una aplicacin pueda usar componentes de otras aplicaciones, e incluso
desarrollados en otros lenguajes. Eso se consigue actualmente mediante CORBA y DCOM. No
obstante un desarrollo con estos estndares no es fcil de lograr y, sobre todo, la comunicacin
entre mdulo situados remotamente da problemas. El ms tpico es que haya un "firewall" por
el medio. Entonces la cosa se complica bastante. Como SOAP trabaja sobre HTTP, este
problema se minimiza ya que HTTP es un protocolo que se maneja muy bien con los
"cortafuegos".
Si queremos que la comunicacin SOAP sea segura no tenemos ms que usar el
protocolo HTTPS en lugar de HTTP.
Propiedades de SOAP:

Es un protocolo ligero

Es simple y extensible

Se usa para comunicacin entre aplicaciones

Est diseado para comunicarse va HTTP

No est ligado a ninguna tecnologa de componentes

No est ligado a ningn lenguaje de programacin

Est basado en XML

Est coordinado por el W3C

Se convertir en un estndar del W3C

SOAP es la pieza clave de la tecnologa .NET de Microsoft pero, al ser un protocolo

abierto, nos permite usar todo su potencial desde cualquier lenguaje y plataforma.

Introduccin a la programacin distribuida

Diego J. Bodas Sagi

JINI
JINI construye redes que pueden adaptarse a las demandas de sistemas dinmicos,
requiere una arquitectura innovadora que se acomode con eficiencia a un sistema complejo y a
los cambios. El ideal de JINI es que se adapte de forma automtica a las modificaciones que se
hagan en la red. Sin embargo, a pesar de esta complejidad aparente JINI tambin ha sido
pensado para ser fcil de usar y aprender. Adems, Jini es una ventaja para el programador ya
que el cdigo necesario se simplifica de forma destacable.
Jini puede convivir perfectamente con todas las tecnologas y servicios tpicos de una
red.
Todas las representaciones en Jini se hacen con objetos java, a esos objetos se
accede a travs de interfaces en Java (como se puede comprobar el acceso a travs de una
interfaz es tpico en la programacin distribuida).
Gracias a esta tecnologa podemos:
- Buscar servicios "multicast".
- Buscar servicios para autentificar cdigo.
- Buscar servicios que mandan alertas.
Para encontrar un servicio, un cliente Jini lo localiza por tipo en "Lookup Service"
(Interfaz de Java), despus mueve el servicio al cliente y el cdigo que el servicio necesita usar
es dinmicamente cargado en demanda.
Debemos saber que a la hora de requerir un servicio, la comunicacin se establece
entre el servicio y su proxy, esto acta de forma independiente al cortafuegos, el proceso es
independiente del protocolo, es decir, en el caso de que el protocolo cambiase no afectara al
cliente.
Jini utiliza RMI, varias son las razones de esto:
-

RMI puede pasar de forma completa los objetos (cdigo incluido) programados en
Java.
Se trabaja mejor con la Java Virtual Machine.
Obtenemos serializacin en el proceso.
Hay robustez y las configuraciones de seguridad son diversas.

En Jini tenemos presente el concepto de JavaSpaces. El JavaSpace es un servicio Jini que

se almacena como un objeto persistente y compartido. Es necesaria su consideracin a la hora
de crear sistemas distribuidos, programacin paralela y sistemas cooperativos.
Su uso tiene mltiples ventajas:
- Anominato entre aplicaciones.
- Comunicacin desparejada.
- Los programas se pueden comunicar a travs del tiempo o del espacio.
- Se mejora en diseo y tiempo de desarrollo.
Jini permite tambin la integracin con CORBA.
BIBLIOGRAFA Y REFERENCIAS
Qusay H. Mahmoud, Distributed Programming with JAVA, Manning Editorial 2002
HORSTMANN, JAVA2 Caractersticas Avanzadas, Prentice Hall 2003
SUN, www.sun.es, www.sun.com
Microsoft, www.microsoft.es