Introduccin

Los sistemas distribuidos suponen un paso ms en la evolucin de los sistemas

informticos, entendidos desde el punto de vista de las necesidades que las
aplicaciones plantean y las posibilidades que la tecnologa ofrece. Antes de
proporcionar una definicin de sistema distribuido resultar interesante
presentar, a travs de la evolucin histrica, los conceptos que han
desembocado en los sistemas distribuidos actuales, caracterizados por la
distribucin fsica de los recursos en mquinas interconectadas. Utilizaremos
aqu el trmino recurso con carcter general para referirnos a cualquier
dispositivo o servicio, hardware o software, susceptible de ser compartido.

CAPTULO I
Sistemas distribuidos

Historia de los sistemas distribuidos

Antecedentes de los sistemas distribuidos.
El desarrollo de los sistemas distribuidos vino de la mano de las redes locales de
alta velocidad a principios de 1970. Ms recientemente, la disponibilidad de
computadoras personales de altas prestaciones, estaciones de trabajo y
ordenadores servidores ha resultado en un mayor desplazamiento hacia los
sistemas distribuidos en detrimento de los ordenadores centralizados multiusuario.
RMI (Java Remote Method Invocation) es un mecanismo ofrecido por Java para
invocar un mtodo de manera remota. Forma parte del entorno estndar de
ejecucin de Java y proporciona un mecanismo simple para la comunicacin de
servidores en aplicaciones distribuidas basadas exclusivamente en Java.
Esta tendencia se ha acelerado por el desarrollo de software para sistemas
distribuidos, diseado para soportar el desarrollo de aplicaciones distribuidas. Este
software permite a los ordenadores coordinar sus actividades y compartir los
recursos del sistema - hardware, software y datos.
Los sistemas distribuidos se implementan en diversas plataformas hardware,
desde unas pocas estaciones de trabajo conectadas por una red de rea local,
hasta Internet, una coleccin de redes de rea local y de rea extensa
interconectados, que en lazan millones de ordenadores.

Historia
Los comienzos: la dcada de 1940

En 1946 se present en pblico el ENIAC (siglas en ingls de "calculador e

integrador numrico electrnico"), la primera computadora de propsito general
utilizada por el ejrcito de los Estados Unidos, que utilizaba la tecnologa de
vlvulas electrnicas o tubos de vaco. En esta poca los ordenadores no
disponan de sistema operativo. Todas las instrucciones de los programas eran
codificados a mano a travs de interruptores, y ms tarde utilizando tarjetas
perforadas de forma totalmente manual.

Los sistemas de trabajo por lotes

Hasta la dcada de 1950 era una persona (el operador) el que se encargaba de
cambiar fsicamente entre los trabajos que ejecutaba el ordenador. Se perda un
tiempo considerable entre trabajo y trabajo debido a que esta labor se haca
manualmente, as que se pens enrealizar la labor del cambio de tareas de
manera automtica. Fue entonces cuando surgieron los primeros sistemas
operativos (llamados as porque sustituyeron en parte el trabajo del operador) con
la intencin de acelerar y automatizar la transicin entre trabajos. Se agrupaban
los trabajos en grupos llamados lotes, de manera que cuando una tarea

terminaba, el sistema operativo se encargaba de leer e iniciar el siguiente trabajo

dentro del lote. La introduccin de los primeros sistemas operativos, y el uso
de transistores que sustituyeron a los tubos de vaco hizo que la velocidad de
proceso de las mquinas aumentase considerablemente.
El primer sistema operativo de la historia es el GM-NAA I/O (Sistema de
Entrada/Salida de General Motors y North American Aviation), que fue diseado en
1956 para ejecutarse en un ordenador IBM 704. Entre los primeros sistemas
operativos cabe tambin destacar el Fortran Monitor Sistem (FMS) y el IBSYS.

Los sistemas multitarea

A comienzos de la dcada de 1960 surgen los sistemas de tiempo compartido, en
los que varios programas se encuentran en memoria, y parece que se estn
ejecutando de manera simultnea, ya que el ordenador va alternando entre ellos
rpidamente asignando pequeas franjas de tiempo de ejecucin a cada uno. De
esta poca cabe destacar sistemas operativos como CTSS (Sistema de Tiempo

Compartido Compatible) y su sucesor MULTICS, precursor de los actuales

sistemas UNIX.
En 1964 IBM lanz la familia de ordenadores Sistemas/360, que utilizaban
circuitos integrados como tecnologa principal, y el OS/360 como sistema
operativo. El sistema fu evolucionando para poder servir a mltiples usuarios
simultneamente, soportando entornos de proceso por lotes multiusuario con
tiempo compartido y multiprocesamiento, y que dio muchos quebraderos de
cabeza a sus creadores y usuarios debido a su complejidad y enorme tamao.

Los sistemas para ordenadores personales

La tecnologa de los circuitos integrados a gran escala (LSI) que permita incluir
miles de transistores por centmetro cuadrado, hizo que a principios de la dcada
de 1980 comenzasen a proliferar los primeros ordenadores personales y sistemas
operativos para ellos. Entre los muchos sistemas de esta poca destacan elCP/M,
el MS/DOS (precursor

de

los

actuales

sistemas

de

Microsoft),

el OS/2 (inicialmente una iniciativa conjunta de Microsoft e IBM) y el Sistema

1 (precursor de Mac OS).

Los sistemas UNIX, y Linux

El desarrollo del sistema operativo MULTICS fue un enorme proyecto que acab
discontinundose. Sin embargo una de las personas que haba intervenido en su
desarrollo, Ken Thompson, junto con Dennis Ritchie (uno de los creadores del
lenguaje de programacin C), decidieron desarrollar por su cuenta un sistema
operativo que cumpliese con las premisas originales del proyecto Multics, pero que
corriese en un ordenador ms pequeo. El proyecto naci con el nombre
de UNICS, y posteriormente se renombr a UNIX. Muchas son las versiones de
UNIX que han evolucionado hasta la actualidad, entre ellas se encuentra LINUX,
desarrollado inicialmente por Linus Torvalds y liberado como cdigo abierto por
primera vez en 1991. Actualmente existen multitud de distribuciones (versiones
independientes) de Linux, que se ha convertido en uno de los sistemas operativos
ms utilizados en la actualidad debido a su robustez. Red Hat es una de las
distribuciones ms utilizadas en entornos de servidor, mientras que en los
entornos de escritorio se abren paso otras como Ubuntu, cuyo eslogan es Linux
para seres humanos.

Sistemas distribuidos

Los recursos de diferentes mquinas en red se integran de forma que desaparece

la dualidad local/remoto. La diferencia fundamental con los sistemas en red es que
la ubicacin del recurso es transparente a las aplicaciones y usuarios, por lo que,
desde este punto de vista, no hay diferencia con un sistema de tiempo compartido.
El usuario accede a los recursos del sistema distribuido a travs de una interfaz
grfica de usuario desde un terminal, despreocupndose de su localizacin. Las
aplicaciones ejecutan una interfaz de llamadas al sistema como si de un sistema
centralizado se tratase, por ejemplo POSIX. Un servicio de invocacin remota (por
ejemplo a procedimientos, RPC, o a objetos, RMI) resuelve los accesos a los
recursos no locales utilizando para ello la interfaz de red. Los sistemas distribuidos
proporcionan de forma transparente la comparticin de recursos, facilitando el
acceso y la gestin, e incrementando la eficiencia y la disponibilidad.
El modelo de sistema distribuido es el ms general, por lo que, aunque no se ha
alcanzado a nivel comercial la misma integracin para todo tipo de recursos, la
tendencia eslara a favor de este tipo de sistemas. La otra motivacin es la relacin
de costes a la que ha llevado la evolucin tecnolgica en los ltimos aos. Hoy en
da existe un hardware estndar de bajo coste, los ordenadores personales, que
son los componentes bsicos del sistema. Por otra parte, la red de comunicacin,
a no ser que se requieran grandes prestaciones, tampoco constituye un gran
problema econmico, pudindose utilizar infraestructura cableada ya existente
(Ethernet, la red telefnica, o incluso la red elctrica) o inalmbrica.
A continuacin explicaremos brevemente uno de los casos de sistemas
distribuidos que se hizo famoso en la decada de los 90's:

Proyecto SETI:
SETI@Home es un experimento cientfico de la Universidad Berkeley de California
que combina el poder de computo de millones de computadoras alrededor del
mundo conectadas a travs de la Internet para analizar datos obtenidos por un
radio

telescopio

que

capta

ondas

provenientes

del

espacio.

Este experimento es el primero en tomar ventaja de la enorme capacidad de

computo que se puede obtener utilizando un sistema distribuido en la Internet, red
a la cual estn actualmente conectados millones de PCs de todo el mundo. Fue
lanzado

al

publico

en

el

ao

1999,

actualmente

La idea de SETI es que en algn lugar de alguna galaxia en el espacio puede

haber alguna civilizacin, obviamente extraterrestre, suficientemente avanzada,
que esta lanzando seales al espacio para que alguien las capte y as poder hacer
contacto. SETI@Home intenta encontrar uno de estos mensajes en las ondas de
audio que se analizan.
Estas seales podran llegar hasta la Tierra en forma de dbiles ondas de sonido,
que solo podran ser captadas por un dispositivo muy sensible, como el radio
telescopio de 305 metros de dimetro ubicado en Arecibo, Costa Rica, y tambin
estaran muy mezcladas por toda la interferencia producida por seales
provenientes de la tierra, por ese motivo, las ondas captadas deben ser
profundamente analizadas, en diferentes rangos de frecuencia, lo que requiere
una gran cantidad de tiempo de CPU.
SETI@Home basa su funcionamiento en un sistema de distribucin de datos, que
se reciben desde Arecibo en grandes cintas magnticas de varios Gibabytes de
capacidad, luego el servidor de SETI va partiendo los datos de las cintas en
pedazos de 250kb de informacin, lo que se conoce como una work unit (w.u.) ,
que luego ser enviada a los usuarios conectados corriendo el software cliente de
SETI@Home para que la procesen.
Los resultados del anlisis de las work units son enviados de vuelta al servidor de
SETI@Home, que vuelve a enviar otra w.u. a la PC que termino su trabajo, y as

sucesivamente. Teniendo en cuenta la velocidad de la CPU que est procesando

los datos y la frecuencia y cantidad de interferencia que posea la onda procesada,
el tiempo que se tarda en procesar una w.u. puede variar enormemente.
Por seguridad, las w.u. son enviadas a dos o tres usuarios, asi se puede
comprobar la veracidad de los resultados obtenidos por un usuario y otro de la
misma onda, asegurndose de que no haya ningn tipo de sabotaje ni de error de
cmputos posible.
Luego de enviar la w.u. a dos o tres usuarios, el servidor espera un cierto tiempo a
que los resultados sean devueltos, y al ser devueltos dos de ellos, la w.u. es
borrada del servidor. En caso contrario, si alguno de los usuarios no devuelve los
resultados en el tiempo disponible, la misma w.u. es enviada a otro usuario para
su procesamiento, asegurndose as de que no quede ningn pedazo de
informacin sin ser procesada.

Que es un sistema distribuido

Un sistema computacional distribuido est formado por varios elementos de

procesamiento autnomos que cooperan en un objetivo comn o para lograr una
meta comn.
Resulta til clasificar los sistemas distribuidos en fuertemente acoplados, en los
que los elementos de proceso, o nodos, tienen acceso a una memoria comn, y
dbilmente acoplados, que carecen de ella. La importancia de esta clasificacin
radica en que la sincronizacin y la comunicacin en un sistema fuertemente
acoplado pueden efectuarse mediante tcnicas basadas en el empleo de variables
compartidas, mientras que en un sistema dbilmente acoplado se requiere, en
ltimo trmino, paso de mensajes o invocaciones remotas. En la presente tesis, la
expresin sistema distribuido har referencia a una arquitectura dbilmente
acoplada. Se supondr adems una conectividad completa (sin considerar
enrutado de mensajes), y que cada procesador slo tiene acceso a su propio reloj,
el cual se encuentra dbilmente sincronizado con el resto. Partiendo de la
variedad de procesadores del sistema, se puede establecer otra clasificacin. Un
sistema homogneo, es aqul en el que todos los procesadores son del mismo
tipo; un sistema heterogneo contiene procesadores de tipos diferentes. Es muy
interesante disponer de herramientas, lenguajes de programacin, etc. que
permitan su utilizacin en sistemas heterogneos. En este sentido cabe destacar
la importancia de CORBA, que puede ser utilizado independientemente del
sistema operativo, plataforma hardware o lenguaje de programacin. En un
sistema distribuido hay ciertos factores que cobran especial importancia: Soporte
del lenguaje: el desarrollo de un programa distribuido se facilita en gran medida si
el lenguaje y su entorno de programacin soportan el particionado, la
configuracin, asignacin y reconfiguracin de la aplicacin distribuida, junto a un
acceso independiente de la ubicacin de los recursos remotos. Fiabilidad:
disponer de varios procesadores permite que la aplicacin sea tolerante a fallos; si
bien, la aplicacin deber ser capaz de explotar esta redundancia. El 5 disponer

de varios procesadores tambin introduce la posibilidad de que aparezcan fallos

distintos a los que aparecen en un sistema monoprocesador. Algoritmos de
control distribuidos: La presencia de paralelismo real en la aplicacin,
procesadores fsicamente distribuidos, y la posibilidad de que fallen los
procesadores y los elementos de proceso, implica la necesidad de nuevos
algoritmos para el control de los recursos. Planificacin con tiempos lmite
(deadlines): cuando los procesos son distribuidos, los algoritmos ptimos para un
procesador dejan de serlo. Se precisan nuevos algoritmos.

Ejemplos de sistemas distribuidos.

INTERNET.
Internet es una vasta coleccin de redes de computadas de diferentes tipos
interconectados.
El diseo y la construccin de los mecanismos de comunicacin Internet (los
protocolos Internet) es una

realizacin tcnica fundamental, que permite que un

programa que se est ejecutando en cualquier parte dirija mensajes a programas

en cualquier otra parte.
Internet es tambin un sistema distribuido muy grande, permite a los usuarios
hacer uso de servicios como el World Wide Web, el correo electrnico, y la
transferencia de ficheros. A veces se confunde incorrectamente el Web con
Internet. El conjunto de servicios es abierto, puede ser extendido por la adicin de
los servidores y nuevos tipos de servicios. Los proveedores de servicios de
Internet (ISP) son empresas que proporcionan enlaces de mdem y otros tipos de
conexin a usuarios individuales y pequeas organizaciones. Las intranets estn
enlazadas conjuntamente por conexiones troncales (backbone). Una conexin o
red troncal es un enlace de red con una gran capacidad de transmisin, que puede
emplear conexiones de satlite, cables de fibra ptica y otros circuitos de gran
ancho de banda.
En Internet hay disponibles servicios multimedia, que permite a los usuarios el
acceso de datos de audio y video.

INTRANETS.
Una Intranet es una porcin de Internet que es administrada separadamente y que
tiene un lmite que puede ser configurado para hacer cumplir polticas de
seguridad local. Est compuesta de varias redes de rea local (LANs) enlazadas

por conexiones backbone. La configuracin de red de una Intranet particular es

responsabilidad de la organizacin que la administra. Una Intranet est conectada
a Internet por medio de un encaminador (router), lo que permite a los usuarios
hacer uso de servicios de otro sitio y acceder a los servicios que ella proporciona a
los usuarios de otras intranets. Muchas organizaciones necesitan proteger sus
propios servicios frente al uso no autorizado de programa nocivos.
El papel del cortafuegos es proteger una intranet impidiendo que entren o salgan
mensajes no autorizados.
Algunas organizaciones no desean conectar sus redes internas a Internet. La
solucin que se adopta es realizar una intranet, pero sin conexiones a Internet.

COMPUTACIN MOVIL Y UBICUA.

Los avances tecnolgicos han llevado cada vez ms a la integracin de
dispositivos de computacin pequeos y porttiles en sistemas distribuidos. Estos
dispositivos incluyen:
Computadores porttiles.
Dispositivos de mano (handheld), entre los que se incluyen asistentes digitales
personales (PDA), telfonos mviles, etc.
Dispositivos que se pueden llevar puestos.
Dispositivos insertados en aparatos.
La facilidad de transporte en muchos de estos dispositivos, junto con su capacidad
para conectarse adecuadamente a redes en diferentes lugares, hace posible la
computacin mvil. Los usuarios acceden a los recursos mediante los dispositivos
que llevan con ellos.

Y se est incrementando la posibilidad de que utilicen recursos, como impresoras,

que estn suficientemente prximos a donde se encuentren. Esto ltimo se
conoce como computacin independiente de posicin.
Computacin ubicua es la utilizacin concertada de muchos dispositivos de
computacin pequeos y baratos que estn presentes en los entornos fsicos de
los usuarios, sin que estos se den cuenta de ellos. O sea, su comportamiento
computacional estar ligado con su funcin fsica de forma ntima y transparente.
La computacin ubicua y mvil se solapan. Pero, son distintas. La computacin
ubicua podr beneficiar a los usuarios mientras permanecen en un entorno
sencillo como su casa o un hospital. De forma similar, la computacin mvil tiene
ventajas si slo se consideran computadores convencionales y dispositivos como
computadores porttiles e impresoras.

CARACTERSTICAS DE UN SISTEMA DISTRIBUIDO

a) Concurrencia.- Esta caracterstica de los sistemas distribuidos permite que los
recursos disponibles en la red puedan ser utilizados simultneamente por los
usuarios y/o agentes que interactan en la red.
b) Carencia de reloj global.- Las coordinaciones para la transferencia de
mensajes entre los diferentes componentes para la realizacin de una tarea, no
tienen una temporizacin general, est ms bien distribuida en los componentes.
c) Fallos independientes de los componentes.- Cada componente del sistema
pudiera fallar de manera independientemente, y los dems continuar ejecutando
sus acciones.
Esto permite el logro de las tareas con mayor efectividad, pues el sistema en su
conjunto continua trabajando.
d) Separacin funcional.- Las funciones se reparten entre diferentes entidades
e) Distribucin inherente.- Evidentemente, los recursos se comparten de manera
remota, adems las tareas se realizan sin que el usuario sea consciente de qu
recursos se utilizan ni dnde estn localizados
f) Heterogeneidad.- Diversidad de dispositivos, aplicaciones, sistemas operativos,
lenguajes de programacin, etc.
Sin embargo otros autores sealan las siguientes caractersticas de un sistema
distribuido:
-Las mquinas son autnomas.
-Las mquinas estn unidas a una red de computadoras.
-Proveen facilidades de cmputo, son tan flexibles y ampliamente aplicables como
las computadoras convencionales, centralizadas o mainframes.

-Un sistema distribuido da la impresin que se esta usando una computadora

integrada de una forma sencilla.
-La instalacin de un sistema distribuido esta dada de ms de una computadora y
ellas se pueden encontrar en diferentes localizaciones.
-Cada computadora tiene la capacidad de comunicarse con otras dentro del
sistema.
-En un sistema distribuido los usuarios pueden acceder a recursos remotos del
mismo modo como lo hacen a los recursos locales.

VENTAJAS DE LOS SISTEMAS DISTRIBUIDOS

3.1. Ventajas con respecto a Sistemas Centralizados:
Algunas ventajas de los sistemas distribuidos sobre los centralizados son:
Elemento

Descripcin

Economa

Los microprocesadores ofrecen mejor

proporcin precio/rendimiento que los
mainframes

Velocidad

Un sistema distribuido puede tener mayor

poder de cmputo que un mainframe

Distribucin inherente

Algunas aplicaciones utilizan maquinas que

estn separadas a cierta distancia

Confiabilidad

Si una mquina se descompone, el sistema

puede sobrevivir como un todo

Crecimiento por incrementos

Se puede aadir poder de cmputo en

pequeos incrementos

Tabla 1.Ventajass de los SD sobre los centralizados

Fuente: www.geocities.ws

3.2. Ventajas con respecto a PCs Independientes:

Algunas ventajas de los sistemas distribuidos sobre las computadoras aisladas
son:
Elemento

Descripcin

Datos compartidos

Permiten que varios usuarios tengan acceso a una

base de datos comn

Dispositivos
compartidos

Permiten que varios usuarios compartan perifricos

caros, como las impresoras de color

Comunicacin

Facilita la comunicacin de persona a persona; por

ejemplo mediante el correo electrnico

Flexibilidad

Difunde la carga de trabajo entre las mquinas

disponibles en la forma ms eficaz en cuanto a los
costos.

Tabla 2.Ventajas de los SD sobre computadoras aisladas

Fuente: www.geocities.ws

4. DESVENTAJAS DE LOS SISTEMAS DISTRIBUIDOS

Algunas desventajas de los sistemas distribuidos son:
Elemento

Descripcin

Software

Existe poco software para los sistemas

distribuidos

Redes

La red se puede saturar o causar otros

problemas

Seguridad

Un acceso sencillo tambin se aplica a datos

secretos

Tabla 3.Desventajas de los SD.

Fuente: www.geocities.ws
4.1. Software: Es una de las principales desventajas de los sistemas distribuidos.
Existe poco software para los sistemas distribuidos en la actualidad en razn del
diseo, implantacin y uso. Estos problemas estn relacionados con el uso de
sistema operativo, lenguajes de programacin y aplicaciones, as como del nivel
de conocimiento por parte del usuario y la certeza de saber qu tanto debe hacer
el sistema y qu tanto deben hacer los usuarios. Mientras mas se realice
investigacin, este problema disminuir, pero por el momento no puede
subestimarse.
4.2. Redes: La red se puede saturar o causar otros problemas como prdida y
saturacin de mensajes, costo de instalacin de tendidos de cable o dispositivos
inalmbricos e interfaces de red.
4.3. Seguridad: Un acceso sencillo tambin se aplica a los datos secretos. Se
recomienda que la computadora principal est aislada contra accesos no
permitidos, as como contemplar polticas de acceso a los sistemas, el cual debe
estar presente en el sistema distribuido o es un software aparte que apoya al
sistema distribuido.

OBJETIVOS DE LOS SISTEMAS DISTRIBUIDOS

Objetivo principal
El objetivo primordial de un sistema distribuido consiste en proporcionar a los
usuarios un entorno de utilizacin de un nico sistema donde no se perciban la
existencia de mltiples sistemas.
Objetivos secundarios
Economa. Es la razn nmero uno de la tendencia hacia los sistemas distribuidos,
ya que stos tienen, en potencia, una proporcin precio/desempeo mucho mejor
que la de un sistema centralizado.
Velocidad. Un sistema distribuido puede tener mayor poder de cmputo que un
mainframe.
Distribucin. Otra razn para la construccin de un sistema distribuido es que
ciertas aplicaciones son distribuidas en forma inherente; es decir, algunas
aplicaciones utilizan mquinas que estn separadas a cierta distancia.
Confiabilidad. Un sistema distribuido ofrece mayor confiabilidad al distribuir la
carga de trabajo en muchas mquinas. La falla de un circuito descompondr a lo
ms una mquina y el resto seguir intacto.
Crecimiento. Si se necesita aadir poder de cmputo, con un sistema distribuido
bastara agregar procesadores al sistema, lo que permite un desarrollo gradual
conforme surjan las necesidades.
Datos compartidos. Un sistema distribuido permite que varios usuarios tengan
acceso a una base de datos comn.
Dispositivos compartidos. De igual manera, se pueden compartir perifricos entre
diversos usuarios, como puede ser una impresora.
Comunicacin. Un sistema distribuido facilita la comunicacin entre computadoras
aisladas (e-mail, por ejemplo)

Alto rendimiento. Una aplicacin paralela puede ser tambin distribuida. Por
ejemplo, puede utilizarse una red local para distribuir los procesos de la tarea
entre los nodos de la red con el fin de aprovechar los recursos de cmputo
disponibles (generalmente PCs de bajo coste) para reducir el tiempo de
finalizacin. Precisamente, este tipo de esquema de cmputo (computacin en
cluster) ofrece hoy una excelente relacin rendimiento/coste y se encuentra en
expansin frente a los tradicionales supercomputadores. Aunque hoy en da se
siguen utilizando sistemas basados en paso de mensajes (por ejemplo, MPI) con
mecanismos de distribucin no transparentes, la tendencia es clara hacia la
integracin transparente de los recursos de cmputo, y en ese sentido estn
apareciendo nuevos productos (por ejemplo, MOSIX9 ). La memoria compartida
distribuida (DSM) es uno de los retos para proporcionar la integracin completa.
En redes de rea amplia se habla de computacin en grid. En este caso, la
disponibilidad de recursos para la aplicacin es abierta y abarca unidades de
cmputo dispersas que en ese momento estn ociosas. Un ejemplo de software
para soportar computacin en grid es el Globus Toolkit10 .

Tolerancia a fallos. En otras aplicaciones la distribucin viene dictada por criterios

como la integridad de la informacin. As, en un sistema bancario es preciso
mantener replicada la informacin acerca del estado de las cuentas de los clientes
en diferentes servidores, pues el riesgo de perder informacin por el fallo de una
mquina resulta inaceptable por las consecuencias que acarreara. En estos
sistemas es crtico conseguir una actualizacin consistente de las rplicas. Hoy en
da, fundamentalmente por motivos de rendimiento, los sistemas comerciales
utilizan tcnicas muy conservadoras y poco transparentes, pero, como veremos,
las bases tericas para una gestin transparente de la replicacin estn bien
establecidas.
Alta disponibilidad. Hay aplicaciones donde la distribucin se realiza para
acercar la informacin al usuario y disminuir los tiempos de respuesta. En los
casos ms simples, se utilizan tcnicas de replicacin que tienen en cuenta la

distribucin geogrfica (caching y mirroring). La consistencia en la actualizacin no

suele ser un aspecto crtico; en cambio importa mucho la escalabilidad. Hoy en da
estn muy extendidos los sistemas peer-to-peer, caracterizados por su gran
escalabilidad al evitar los cuellos de botella del servidor, ofreciendo disponibilidad
de recursos de manera prcticamente indiscriminada. Un ejemplo son las redes de
distribucin de contenidos, como BitTorrent.
Movilidad. La abundancia de dispositivos fsicos (ordenadores personales y
porttiles, tabletas, telfonos mviles, etc) introduce una dificultad adicional para el
acceso a la informacin del usuario, de forma que este no tenga que gestionar la
actualizacin de la informacin en cada dispositivo. Por ejemplo, un mensaje de
correo borrado desde el telfono mvil debera aparecer como borrado cuando
posteriormente el usuario acceda a su correo desde un ordenador personal. Se
hace imprescindible desligar la informacin de su soporte, gestionando
convenientemente las actualizaciones. Cada vez ms se trabaja sobre espacios
virtuales de informacin en vez de sobre dispositivos fsicos concretos, que se
convierten en meras caches del espacio de informacin del usuario. As, el usuario
se mueve desde un dispositivo a otro y y accede al espacio de su informacin de
forma actualizada y consistente. Ejemplos de productos actuales son Gmail de
Google para el correo electrnico y Dropbox para documentos.
Ubicuidad. A veces los recursos estn inherentemente distribuidos. El usuario se
mueve en un entorno con recursos (ubicuos) no previstos a priori, y la aplicacin
trata de ofrecer un comportamiento inteligente en funcin de las necesidades del
usuario y la naturaleza y disponibilidad de los recursos. Es el caso de las
aplicaciones de Inteligencia Ambiental (AmI), un campo que est creando enormes
expectativas.

Conceptos y arquitecturas de hardware.

Con el paso de los aos, se han propuesto diversos esquemas de clasificacin
para los sistemas de cmputo con varios CPU, pero ninguno de ellos ha tenido un
xito completo ni se ha adoptado de manera amplia. A continuacin se muestra la
taxonoma presentada por Flynn (1972) que considera dos caractersticas
esenciales: el nmero de flujo de instrucciones y nmero de flujos de datos.
SISD: una computadora con un flujo de instrucciones y uno de datos. Todas las
computadoras tradicionales de un procesador caen dentro de esta categora.
SIMD: un flujo de instrucciones y varios flujos de datos. Este tipo se refiere a
ordenar procesadores con unidad de instruccin que busca una instruccin y
despus instruye a varias unidades de datos para que la lleven a cabo en paralelo,
cada una con sus propios datos.
MISD: un

flujo

de

varias

instrucciones

un

flujo

de

datos.

MIMD: un grupo de computadoras independientes, cada una con su propio

contador de programa y datos. Todos los sistemas distribuidos son MIMD.
Las computadoras MIMD se clasifican en dos grupos: aquellas que tienen
memoria compartida, que por lo general se llaman multiprocesadores y aquellas
que no, que a veces reciben el nombre de multicomputadoras. La diferencia
esencial es sta: en un multiprocesador, existe un espacio de direcciones
virtuales, compartido por todos los CPU. En contraste, en una multicomputadora,
cada mquina tiene su propia memoria.
Cada una de estas categoras se puede subdividir en base a la arquitectura de la
red de interconexin: con bus y con conmutador. En la primera queremos indicar
que existe una red, plano de base, bus, cable u otro medio que conecta todas las
mquinas. Los sistemas con conmutador no tienen slo una columna vertebral
como en la televisin por cable, sino que tienen cables individuales de una
mquina a otra y utilizan varios patrones diferentes de cableado.

Otra dimensin de la taxonoma es que, en ciertos sistemas, las mquinas

estn fuertemente acopladas y en otras estn dbilmente acopladas. En un
sistema fuertemente acoplado, el retraso que se experimenta al enviar un mensaje
de una computadora a otra es corto y la tasa de transmisin de los datos, es decir,
el nmero de bits por segundo que se puede transferir, es alta. En un sistema
dbilmente acoplado ocurre lo contrario: el retraso de los mensajes entre las
mquinas es grande y la tasa de transmisin de los datos es baja. Los sistemas
fuertemente acoplados tienden a utilizarse como sistemas distribuidos aunque
esto no siempre es cierto.
Multiprocesadores con base en buses
Los multiprocesadores con base en buses constan de cierta cantidad de
procesadores conectados a un bus comn, junto con un mdulo de memoria. Una
configuracin sencilla consta de un plano de base de alta velocidad o tarjeta
madre, en el cual se pueden insertar las tarjetas de memoria y el CPU. Un bus
tpico tiene 32 64 lneas de direcciones, 32 64 lneas de datos y 32 ms
lneas de control, todo lo cual opera en paralelo. Para leer una palabra de
memoria, un CPU coloca la direccin de la palabra deseada en las lneas de
direcciones del bus y coloca una seal en las lneas de control adecuadas para
indicar que desea leer. La memoria responde y coloca el valor de la palabra en las
lneas de datos para permitir la lectura de sta por parte del CPU solicitante. La
escritura funciona de manera similar.
Multiprocesadores con conmutador
Para construir un multiprocesador con ms de 64 procesadores, es necesario un
mtodo distinto para conectar cada CPU con la memoria. Una posibilidad es dividir
la memoria en mdulos y conectarlos a las CPU con un conmutador de cruceta,
cada CPU y cada memoria tiene una conexin que sale de l. En cada
interseccin est un delgado conmutador de punto de cruce electrnico que el
hardware puede abrir y cerrar. Cuando un CPU desea tener acceso a una
memoria particular, el conmutador del punto de cruce que los conecta se cierra de

manera momentnea para permitir dicho acceso. La virtud del conmutador de

cruceta es que muchos CPU pueden tener acceso a la memoria al mismo tiempo,
aunque si dos CPU intentan tener acceso a la misma memoria en forma
simultnea, uno de ellos deber esperar.

Multicomputadoras con base en buses

Por otro lado, la construccin de una multicomputadora es fcil. Cada CPU tiene
conexin directa con su propia memoria local. El nico problema restante es la
forma en que los CPU se comunicarn entre s. Es claro que aqu tambin se
necesita cierto esquema de interconexin, pero como slo es para la
comunicacin entre un CPU y otro, el volumen del trfico ser de varios rdenes
menor en relacin con el uso de una red de interconexin para el trfico CPUmemoria.
Multicomputadoras con conmutador
Se han propuesto y construido varias redes de interconexin, pero todas tienen la
propiedad de que cada CPU tiene acceso directo y exclusivo a su propia memoria
particular. Hay dos topologas populares: retcula e hipercubo. Las retculas se
basan en las tarjetas de circuitos impresos. Se adecan mejor a los problemas con
naturaleza bidimensional inherente, como la teora de grficas o la visin. Un
hipercubo es un cubo n-dimensional. Se puede pensar como dos cubos ordinarios,
cada uno de los cuales cuenta con 8 vrtices y 12 aristas. Cada vrtice es un
CPU. Cada arista es una conexin entre dos CPU. Se conectan los vrtices
correspondientes de cada uno de los cubos.

Conceptos y arquitecturas de software.

Aunque el hardware es importante, el software lo es ms. La imagen que presenta
y la forma de pensar de los usuarios de un sistema queda determinada en gran

medida

por

el

software

del

sistema

operativo,

no

por

el

hardware.

Se pueden distinguir dos tipos de sistemas operativos para los de varios CPU:
los dbilmente acoplados y los fuertemente acoplados.

El software dbilmente acoplado permite que las mquinas y los usuarios de un

sistema distribuido sean independientes entre s en lo fundamental, pero que
interacten en cierto grado cuando sea necesario.

En el software fuertemente acoplado el programa de aplicacin y el sistema

operativo necesario para soportarlo estn muy acoplados.

Sistemas Operativos de red

Los Sistemas Operativos de red permiten a los usuarios en estaciones de trabajo

independientes la comunicacin por medio de un sistema compartido de archivos,
pero dejan que cada

usuario

domine

su

propia

estacin de trabajo.

Sistemas realmente distribuidos

Los sistemas operativos distribuidos convierten toda la coleccin de hardware y

software en un sistema integrado, muy parecido a un sistema tradicional de tiempo
completo.
Sistemas de multiprocesador con tiempo compartido
Los multiprocesadores con memoria compartida tambin ofrecen la imagen de
nico sistema, pero lo hacen mediante la va de centralizar todo, por lo que, en

realidad, este caso es un sistema. Los multiprocesadores con memoria compartida

no son sistemas distribuidos.

Las dos arquitecturas ms importantes en los sistemas distribuidos: son las

de Cliente-Servidor y la de Igual-Igual (Peer-To-Peer P2P). A continuacin las
veremos mas detalladamente:
Arquitecturas Cliente / Servidor
La arquitectura cliente-servidor consiste bsicamente en un cliente que realiza
peticiones a otro programa (el servidor) que le da respuesta. Aunque esta idea se
puede aplicar a programas que se ejecutan sobre una sola computadora es ms
ventajosa en un sistema operativo distribuido a travs de una red de
computadoras.
La separacin entre cliente y servidor es una separacin de tipo lgico, donde el
servidor no se ejecuta necesariamente sobre una sola mquina ni es
necesariamente un slo programa. Los tipos especficos de servidores incluyen los
servidores web, los servidores de archivo, los servidores del correo, etc. Mientras
que sus propsitos varan de unos servicios a otros, la arquitectura bsica seguir
siendo la misma.
En esta arquitectura la capacidad de proceso est repartida entre los clientes y los
servidores, aunque son ms importantes las ventajas de tipo organizativo debidas
a la centralizacin de la gestin de la informacin y la separacin de
responsabilidades,

lo

que

facilita

clarifica

el

diseo

del

sistema.

Una disposicin muy comn son los sistemas multicapa en los que el servidor se
descompone en diferentes programas que pueden ser ejecutados por diferentes
computadoras

aumentando

as

el

grado

de

distribucin

del

sistema.

La arquitectura cliente-servidor sustituye a la arquitectura monoltica en la que no

hay

distribucin,

tanto

nivel

fsico

como

nivel

lgico.

Arquitecturas Igual-a-Igual (P2P)

La particularidad de esta arquitectura radica en que las computadoras no toman

un rol fijo y constante sino que puede cambiar en el tiempo: Es decir una
computadora puede actuar como servidor enviando informacin a otra
computadora y luego esta computadora puede solicitarle algo a la otra pc
invirtiendo los roles.

Las

redes

P2P

Tienen

las

siguientes

caractersticas:

Escalabilidad
Las redes P2P tienen un alcance mundial con cientos de millones de usuarios
potenciales. En general, lo deseable es que cuantos ms nodos estn conectados
a una red P2P, mejor ser su funcionamiento
Robustez
La naturaleza distribuida de las redes peer-to-peer tambin incrementa la robustez
en caso de haber fallos la rplica de los datos permite que se pueda obtener la
informacin de otra fuente casi inmediatamente.
Descentralizacin
Estas redes por definicin son descentralizadas y todos los nodos son iguales. No
existen nodos con funciones especiales, y por tanto ningn nodo es imprescindible
para el funcionamiento de la red.

Componentes de los sistemas distribuidos

La Ingeniera del Software evolucion desde los lenguajes imperativos como
COBOL, Pascal, Fortran, etc. hasta lenguajes basados en objetos por las
exigencias de las aplicaciones: mayor complejidad, difcil mantenimiento,
necesidad de reutilizacin etc. La programacin orientada a objetos pareca la
panacea para todos estos problemas y permita abarcar proyectos ms complejos
y de una forma ms segura. A pesar del xito de la programacin orientada a
objetos, surgieron nuevos problemas o desafos, como por ejemplo, las
posibilidades de reutilizacin, un objetivo importante de cualquier modelo de
objetos. En lenguajes como C++, se utiliza la herencia de implementacin, que
permite a un objeto heredar (subclase) algunas de las funciones de otro objeto y
sobrescribir otras. Sin embargo, este tipo de reutilizacin no deja claro qu ocurre,
cuando se hacen cambios, en el comportamiento de otros objetos: el contrato es
implcito y ambiguo, o al menos, propenso a errores. En aplicaciones simples, los
problemas de la programacin orientada a objetos pueden no ser problemticos,
pero en aplicaciones mayores con distintos equipos, la actualizacin de alguna
clase, puede afectar a otras sin que llegue al conocimiento de otros miembros del
equipo. Con el tiempo, un nuevo paradigma basado en componentes ha surgido
[Szypersky et al., 2002]. Los componentes software son bloques reutilizables para
la construccin de aplicaciones. Difieren de otro tipo de software reutilizable en
que pueden ser modificados en tiempo de diseo como ejecutables binarios, sin
tener que conocer absolutamente nada sobre su implementacin. En el campo de
tiempo real, se han usado fundamentalmente lenguajes como Ada, C y
ltimamente C++. Ninguno de estos lenguajes est basado en componentes, por
lo que adaptar estos, o definir un nuevo lenguaje basado en componentes sera un
reto y posiblemente tambin un paso adelante en el desarrollo de aplicaciones de
tiempo real. Un modelo de componentes define cmo deben ser los componentes
y cmo interoperan con otros componentes y con el sistema. Algunas de las
caractersticas deseables de los modelos de componentes son las siguientes:
Estandarizado: el modelo debera ser aprobado por un amplio grupo de
profesionales e investigadores.

 Independiente del lenguaje: un modelo de componentes no est desarrollado

para un lenguaje de programacin especfico ni para ninguna caracterstica
especial de ningn lenguaje. Define interfaces: un modelo de componentes
debera proporcionar un mecanismo para definir las interfaces de un componente.
Facilita el empaquetado: cmo el componente es suministrado al usuario.
Permite introspeccin: un modelo de componentes permite la introspeccin de los
componentes en varias fases de desarrollo, desde la fase de diseo hasta la de
ejecucin. Soporte para dinamismo: un modelo de componentes debe permitir al
sistema reorganizarse en tiempo de ejecucin: los componentes y sus conexiones.
A continuacin se describirn los principales modelos actuales para la
programacin con componentes, entre los que encontramos .NET de Microsoft,
CCM de OMG y los beans de Java. 1.2.1. La plataforma .NET Recientemente
Microsoft ha dirigido todos sus esfuerzos hacia la tecnologa .NET [Microsoft .NET,
2005]. En el estado anterior a .NET, la tecnologa basada en los sistemas
operativos y lenguajes de Microsoft sufra de algunas deficiencias como puedan
ser los continuos parches en sistemas operativos; el mantenimiento de la
compatibilidad con versiones previas (no se aprovechaban al mximo las
capacidades de las nuevas mquinas) y la continua extensin de la interfaz de
programacin (API) en vez de su reemplazamiento por una nueva, lo que
dificultaba enormemente la labor de los programadores. Todos estos problemas, y
algunos ms, llevan a Microsoft el replantearse los modelos de programacin
utilizados, entornos de ejecucin, etc. Surge as la plataforma .NET y la amalgama
de tecnologas relacionadas a este trmino, destacando as, por ejemplo, el
lenguaje C# [Robinson et al., 2002] diseado para aprovechar al mximo las
caractersticas de esta nueva plataforma. Se pueden tener dos visiones de .NET:
Librera para el desarrollo de aplicaciones: .NET puede verse como una nueva
librera o API para el desarrollo de aplicaciones.
Entorno de ejecucin en el que los programas se van a ejecutar,
proporcionando un nivel de abstraccin sobre el sistema operativo: en esta
visin, .NET funciona como una mquina virtual que va a permitir la ejecucin
de las distintas aplicaciones. Common Language Specification Common

Language Runtime VB C++ C# ASP.NET: Web Services y Web Forms JScript

Windows Forms .NET Framework Base Classes ADO.NET: Datos y XML Visual
Studio.NET Figura 1.2. La plataforma .NET

Dentro de la plataforma .NET existen distintos lenguajes para el desarrollo de

aplicaciones. Dentro de estos lenguajes desempea un papel destacado el
lenguaje C#, el primer lenguaje de la familia C/C++ orientado a componentes y
que incluye conceptos de orientacin a componentes como conceptos de primera
clase en el lenguaje, tales como eventos, propiedades, etc. Con .NET el modelo
COM [Box, 1997] va a ser reemplazado por los denominados assemblies
(ensamblados), intentando superar los problemas que COM tena. Este
subapartado se centrar en el estudio de los componentes de .NET y su utilizacin
para tiempo real, teniendo la plataforma .NET numerosas caractersticas que
quedan fuera del mbito de estudio de la presente tesis. Los componentes de
.NET En .NET los componentes van a estar contenidos en ensamblados. Un
ensamblado es el trmino .NET para una unidad de configuracin y despliegue.
Sin embargo, un ensamblado no es un componente en .NET. Para .NET un
componente es la forma binaria de una clase y un simple ensamblado puede
contener muchos componentes de este tipo.

Un ensamblado consta de metadatos, descripcin de tipos exportados y mtodos,

cdigo intermedio de .NET y recursos. Todas estas partes pueden estar en un solo
fichero o en varios. Las principales caractersticas de los ensamblados son las
siguientes: Autodescriptivos: los ensamblados incluyen metadatos que los
describen. Los metadatos incluyen los tipos exportados desde el ensamblado y un
manifiesto. Dependencias: las dependencias estn almacenadas en el manifiesto
del ensamblado. De esta forma es posible conocer exactamente las versiones
exactas de otros ensamblados necesitados por el que se est desarrollando.
Posibilidad de cargar mltiples versiones de un mismo ensamblado en la misma
aplicacin. Evita posibles problemas por mltiples dependencias sobre el mismo
ensamblado pero con diferentes versiones. Aislamiento de aplicaciones a travs
de los dominios de aplicacin. Los fallos de una aplicacin no pueden afectar
directamente a otras aplicaciones. Instalacin sencilla: bastara una simple copia.
Dentro de los ensamblados, una parte importante est formada por el manifiesto,
parte de los metadatos. Un manifiesto describe el ensamblado con toda la
informacin

que

se

necesita

para

referenciarlo

listando

todas

sus

independencias, consta de: Identidad. Lista de ficheros que pertenecen al

ensamblado. Lista de ensamblados utilizados (nmero de versin y clave
pblica). Lista de solicitudes de permisos: permisos necesitados para ejecutar el
ensamblado. Tipos exportados: no son parte del manifiesto, a menos que los
tipos sean incluidos en un mdulo (unidad de reutilizacin). La descripcin del tipo
es almacenada como metadatos dentro del ensamblado. .NET y tiempo real .NET
no est diseado para tiempo real, es una tecnologa para sistemas genricos.
Los ensamblados de .NET presentan las mismas carencias para tiempo real que
pueda presentar el modelo de componentes COM. A pesar de sus numerosas
mejoras con respecto a COM, no se han incluido caractersticas necesarias para
tiempo real. No obstante, existen caractersticas, apropiadas para el desarrollo de
aplicaciones orientadas a componentes y cuya utilizacin para sistemas en tiempo
real puede ser factible, como, por ejemplo, el modelo de eventos u otras
caractersticas como los delegados multicast (punteros a funciones orientados a
objetos). Puede ser interesante la utilizacin de C# como un lenguaje de base

para la implementacin de componentes, puesto que proporciona numerosos

conceptos de la programacin orientada a componentes de forma intrnseca al
lenguaje. Tambin podra ser factible, dado que .NET funciona de forma similar a
Java (mediante una mquina virtual), la alteracin del entorno de ejecucin de
.NET para que soportara la construccin de aplicaciones predecibles. As, por
ejemplo, .NET incorpora un recolector de basura de forma similar a Java. Al igual
que en Java, el comportamiento no predecible del recolector de basura no es
recomendable para aplicaciones de tiempo real, por lo que se podra pensar en
una extensin o modificacin de .NET para su utilizacin en sistemas empotrados
y/o de tiempo real.

1.2.2. El modelo de componentes de Java JavaBeans presenta un modelo de

componentes independiente de la plataforma, pero dependiente del lenguaje Java,
recibiendo los componentes el nombre de beans. Adems de los JavaBeans, que
bsicamente son componentes grficos, Sun ha desarrollado los denominados
Enterprise JavaBeans (EJB) [EJB, 2005]. Dentro de las principales caractersticas
que las interfaces de JavaBeans ofrecen, encontramos las siguientes:
Propiedades: un bean puede definir un nmero arbitrario de propiedades de
cualquier tipo. Una propiedad es un atributo con nombre que puede afectar a la
apariencia o comportamiento de un bean. Adems de propiedades con simples y
mltiples valores, se pueden definir propiedades de tipos bound y constrained. Las
propiedades de tipo bound usan eventos Java para notificar a otros componentes
el cambio de valor. Las propiedades de tipo constrained, permiten vetar cambios.
Este tipo de propiedades no aparecen en muchos sistemas orientados a objetos y
permiten a los desarrolladores realizar la lgica de la aplicacin en una forma
modular y con un mantenimiento fcil. Eventos: el mecanismo de eventos que
utiliza JavaBeans afecta a tres interfaces relacionadas: Event, EventSource y
EventListener. Las fuentes de eventos (EventSources) notifican a todos los
consumidores de eventos (EventListeners) los eventos a travs de objetos de tipo
Event.

El modelo de eventos permite utilizar, adems, caractersticas como multicast y los

adaptadores de eventos, que permiten ayudar al programador para no tener que
escribir manejadores para todos los eventos. Introspeccin: el uso de tcnicas de
reflexin permite a las herramientas el descubrimiento del soporte de ciertas
caractersticas en los beans. Para ello se utiliza una terminologa a la hora de
declarar mtodos, propiedades, etc. Por su parte, los EJB se ejecutarn dentro de
contenedores que aislarn al bean del entorno de ejecucin del servidor. El
contenedor automticamente asigna hebras para los componentes y gestiona
aspectos

como

concurrencia,

seguridad

actividades

relacionadas

con

transacciones. El entorno servidor de los EJB incluye: Protocolo para

comunicaciones remotas. Servicios de directorios, seguridad, gestin del sistema
y transacciones. Beans y tiempo real Una ventaja para el desarrollador del
componente con respecto a otros modelos, puede ser la independencia de la
plataforma, ya que, una vez desarrollado el componente, podra distribuirse y
utilizarse en otras plataformas sin necesidad de realizar modificaciones,
independientemente de si el componente va a ser utilizado en aplicaciones
estndares o de tiempo real, aunque en este ltimo caso habra que verificar si el
componente cumple con sus requisitos en la nueva plataforma. Este modelo de
componentes no es adecuado inicialmente para el desarrollo de aplicaciones de
tiempo real, ya que, aunque en este caso es independiente de la plataforma, no lo
es del lenguaje, al depender de Java, un lenguaje que no contempla aspectos de
tiempo real. Sin embargo, si se modificara el propio lenguaje Java, bien a travs
de la implementacin de tiempo real de Java [Bollella et al., 2000], bien a travs de
una extensin propia; los componentes basados en este modelo s podran
utilizarse para desarrollar un modelo de componentes que incorporara
caractersticas de tiempo real. Algunas caractersticas del modelo son interesantes
para tiempo real. Por ejemplo, se podra utilizar la caracterstica de introspeccin
para que el entorno pudiera obtener informacin de los componentes (eventos
producidos, eventos consumidos, etc.) y adems utilizando una terminologa
adecuada, se podran indicar, por ejemplo, distintas calidades de servicio (QoS)
que el entorno podra detectar y utilizar.

El modelo de eventos podra ser adecuado, siempre y cuando se extendiera para

permitir la incorporacin de tiempo o prioridades en los mismos. Las
caractersticas de multicast que incorpora este modelo pueden ser muy tiles para
la implementacin de canales de tiempo real con mltiples consumidores. Esto
podra llevar a la necesidad de un servicio de planificacin de eventos que
garantizara el cumplimiento de las restricciones de tiempo. Una solucin similar ha
sido adoptada en TAO [Harrison et al., 1997]. Otra caracterstica muy interesante
que incorporan los EJB son los contenedores, que controlan aspectos como la
concurrencia y se pueden extender para controlar planificacin, gestin de
eventos, etc. Los contenedores permiten tambin realizar planificacin en distintos
niveles. En cada contenedor, de forma transparente se contar con un planificador
(que puede ser configurable) que ser el encargado de su nivel, con
independencia de niveles superiores o inferiores. Esta misma caracterstica de
mltiples niveles puede ser tambin utilizada para los eventos, de forma que un
gestor de eventos por contenedor permita una planificacin independiente en cada
nivel. Este modelo de contenedores/niveles permite realizar un estudio ms
sencillo de planificabilidad que con un solo nivel para todas las aplicaciones del
sistema, esto puede ser especialmente adecuado para sistemas dinmicos.

1.2.3. El modelo de componentes CCM

CCM es el modelo de componentes propuesto por OMG (Object Management
Group) organizacin que se encarga de la definicin de una arquitectura de
objetos y principal impulsora de CORBA (que ser estudiado en una seccin
aparte). Aunque CORBA proporciona a diseadores y desarrolladores todo lo que
necesitan para el desarrollo de aplicaciones, las numerosas polticas POA,
transacciones, seguridad, etc. combinadas entre s dan un elevado nmero de
posibilidades que hacen difcil seleccionar la mejor para una aplicacin en
concreto. El Modelo de Componentes CORBA, CCM (Corba Component Model)
[OMG, 1999][Wang et al., 2001], intenta solventar estas dificultades utilizando un
subconjunto de combinaciones tiles para un mejor desarrollo de aplicaciones en
la parte del servidor. CCM est formado por un nmero de piezas conceptuales,
que juntas forman el modelo de programacin para servidores. Estas piezas son:
Los componentes, incluyendo un Modelo de Componentes Abstracto y un Marco
de Trabajo de Implementacin de Componentes centrado en el nuevo lenguaje

para la definicin de componentes (CIDL). El Modelo de Programacin de

Componente Contenedor. Integracin con persistencia, transacciones y eventos.
Empaquetamiento de componentes y su despliegue. Interconexin con EJB 1.1.
Modelo de Metadatos de Componentes (repositorio de interfaces). Los
componentes de CCM Un componente es un nuevo meta-tipo en CORBA. En vez
de definir el componente con interface, los componentes se declararn con la
palabra component. CCM ha extendido IDL con un conjunto de nuevas palabras
claves necesarias para su modelo. En tiempo de ejecucin, un componente es
representado por una referencia al componente. Los diversos stubs y skeletons
soportados por los componentes son, en esta ocasin, referidos como ports
(puertos) y cuatro de ellos tienen nombres especiales: Facetas (Facets): son las
mltiples potenciales interfaces que un componente ofrece. Cuando se declara un
componente, existe una interfaz principal, denominada la interfaz equivalente. Se
puede heredar de esta interfaz de la forma tradicional usada en CORBA,
obteniendo las denominadas interfaces soportadas. En CCM, las facetas
conocidas tambin como interfaces proporcionadas, y que no estn relacionadas
con las soportadas por herencia, permiten a los clientes utilizar distintas interfaces.
Receptculos (Receptacles): son los stubs clientes que un componente utiliza
para invocar a otros componentes. Debido a que el modelo de programacin
basado en componentes insiste en la reutilizacin va composicin, un
componente podra delegar algunas de sus operaciones en otros componentes.
En estos casos, un componente debe obtener la referencia a una instancia del otro
componente. Fuentes de eventos (Event sources): son los nombres de los
puntos de conexin que emiten eventos de un tipo especificado a uno o ms
consumidores interesados, o a un canal de eventos. Sumideros de eventos
(Event sinks): son los nombres de las conexiones en las que los eventos de un
tipo especfico deben ser puestos por un suministrador o un canal.

Otras nuevas caractersticas del modelo incluyen: Claves primarias: valores que
identifican a los componentes unvocamente. Atributos y configuracin:
expuestos para permitir la configuracin del componente. Interfaces Home: que
proporcionan funcionamiento de factora y operaciones de bsqueda de
componentes. El marco de trabajo para implementacin de componentes CCM
proporciona un gran nmero de interfaces para soportar la estructura y
funcionalidad de los componentes. La implementacin para muchas de estas
interfaces puede ser generada automticamente. El CORBA Component
Implementation Framework (CIF) est diseado para desarrollar estas tareas y
que los programadores no tengan que preocuparse de ellas. Por ejemplo, la
gestin del ciclo de vida y estados de los componentes podra ser resuelta con
este marco de trabajo. CCM define un lenguaje declarativo, el Component
Implementation

Definition

Language

(CIDL)

que

permite

describir

implementaciones y estados persistentes de los componentes. CIF usa las

descripciones CIDL para generar cdigo que automatiza comportamientos de los
componentes tales como navegacin, consulta de identidades, activacin y
gestin del estado. El modelo de programacin basado en contenedores Un
contenedor es el entorno de ejecucin que es ofrecido por CCM a los
componentes. Los contenedores encapsulan la implementacin de un componente
y usan un conjunto de APIs para acceder al entorno de ejecucin, facilitando as el
desarrollo y/o configuracin de aplicaciones CORBA. Se proporcionan las
siguientes caractersticas: Activacin/Desactivacin de implementaciones de
componentes para preservar recursos limitados del sistema, tales como memoria
principal. Proporcionar un nivel de adaptacin para cuatro servicios comnmente
usados: Transacciones, Persistencia, Seguridad y Notificacin. Este marco libera a
los clientes de tener que localizar estos servicios. Nivel de adaptacin para
callbacks que el contenedor y el Object Request Broker (ORB) utilizan para
informar al componente sobre eventos interesantes tales como mensajes de los
servicios anteriormente mencionados. Gestin de las polticas POA para
determinar la creacin de referencias a los componentes. CCM y tiempo real Al
igual que los modelos anteriores, CCM tampoco est preparado inicialmente para

aplicaciones de tiempo real, ya que, no incorpora la posibilidad de indicar

restricciones temporales (en este caso adems es muy probable que los diferentes
componentes

estn

incluso

en

mquinas

distintas,

con

el

grado

de

impredecibilidad que ello aporta). Y adems, presenta los mismos problemas del
estndar CORBA, que no permite acotar el tiempo de ejecucin de una invocacin
remota. Este modelo presenta mltiples interfaces mediante las facetas. Con esta
caracterstica se pueden conseguir distintas QoS, interfaces funcionales y
especiales para tiempo real, distintas interfaces para una utilizacin esttica o
dinmica (por ejemplo, mediante una prueba de aceptacin) de los componentes y
la posibilidad de implementar un mecanismo de reconfiguracin dinmica.

Adems se contempla un modelo basado en eventos con fuentes y sumideros,

que como en los beans de Java, podra ser extendido de forma que incorpore
restricciones temporales y/o prioridades en la transmisin y recepcin de los
eventos. La caracterstica de activacin/desactivacin de implementaciones de
componentes que incluyen los contenedores de CCM puede utilizarse para tener
implementaciones degradadas de los componentes (distintas QoS) e incluso para
reconfiguracin dinmica. En el modelo actual CCM se suministran niveles de
adaptacin

para

Transacciones,

cuatro

servicios muy comnmente

Persistencia,

Seguridad

Notificacin.

usados, como
Sera

son

aconsejable

incorporar un quinto nivel de adaptacin para los servicios de tiempo real, de

forma que esto facilitara el desarrollo de aplicaciones con CCM y tiempo real.
1.2.4. Tendencias actuales sobre componentes y tiempo real Existen algunos
trabajos intentando relacionar los componentes con tiempo real. Para el estudio de
la composicionalidad de componentes con caractersticas de tiempo real, el
trabajo presentado en [Hooman y Van Roosmalen, 2000] propone un modelo a
seguir para el desarrollo de aplicaciones de tiempo real independiente de la
plataforma y basndose en el concepto de componentes de una forma genrica,
como fragmentos de cdigo software. Hooman propone un modelo de
programacin en tiempo real con un mtodo de verificacin formal de programas

con anotaciones de tiempo. La idea bsica del modelo de programacin ideado es

que es posible limitar las restricciones de tiempo programadas a las que aparecen
en las especificaciones. Sin embargo, este modelo presenta dos inconvenientes:
El concepto de componente que presenta se limita a fragmentos de cdigo. Si bien
esto puede ser correcto, puede ser algo difcil de utilizar en un sistema completo.
Las posibilidades que ofrece al programador en caso de que el sistema no sea
planificable se limitan a cambiar la plataforma o su programa. El modelo formal
descrito por T.A.Henzinger [Henzinger, 2000] propone una forma estructurada y
formal para el desarrollo de software y hardware interactuando a travs de
componentes en tiempo real, y realizando un estudio de las posibles formas de
composicin de componentes. Otro trabajo formal es el desarrollado por [Sifakis,
1999] donde se presenta la construccin de sistemas reactivos con cuestiones
acerca de su composicionalidad, y en particular en la forma en que sistemas sin
tiempo bien construidos pueden ser extendidos para su utilizacin con requisitos
temporales. Dentro del mbito de los sistemas distribuidos, estn comenzando a
aparecer los primeros resultados para componentes de tiempo real: herramientas,
entornos de ejecucin, mtodos para expresar restricciones, etc. Los resultados
son todava muy preliminares y no se han establecido an modelos de referencia
como en el caso de los modelos de componentes estndares. Los trabajos
estudiados pueden agruparse en tres grandes grupos: plataformas de ejecucin
(con componentes u objetos), estudios sobre planificabilidad e indicacin de
restricciones y finalmente estudios sobre estndares ya consolidados como
puedan ser Java o CORBA (con las mejoras que estos estudios supondran para
los modelos de componentes). En el trabajo desarrollado en [Villela et al., 2001] se
presenta un marco de trabajo con un conjunto de herramientas para el desarrollo
de componentes distribuidos en tiempo real. Las herramientas incluyen plantillas
de componentes, diagramas de despliegue para la configuracin de la aplicacin
en los distintos nodos que forman el sistema, generadores de cdigo, un
repositorio de componentes, etc. Sin embargo, no se garantiza el cumplimiento de
las restricciones de tiempo real por estar en un estado muy preliminar de
desarrollo; se hace un especial nfasis en las herramientas que permitirn

desarrollar las aplicaciones distribuidas. VERTAF es un marco de trabajo para

aplicaciones orientadas a objetos en sistemas empotrados de tiempo real
presentado

en

[Hsiung

et

al.,

2002].

Dispone

de

cinco

herramientas:

Implementador, Modelador, Planificador, Verificador y Generador: El componente

Implementador especifica los objetos de diseo. El componente Modelador pasa
los objetos de una aplicacin, que se ha diseado orientada a objetos, a procesos,
donde cada uno es una tarea de tiempo real. El componente Planificador
comprueba la planificabilidad de las tareas, usando algn algoritmo de
planificacin. El componente Verificador comprueba que es factible, comprobando
si cumple las restricciones de tiempo; y finalmente, el componente Generador
genera el cdigo de la aplicacin. VERTAF pretende incorporar la verificacin en el
proceso de diseo, ahorrando de esta forma costes. Utiliza para ello tcnicas de
comprobacin de modelos (model cheking), modelando los sistemas como
conjuntos de autmatas con tiempo. Otros aspectos interesantes de VERTAF son
la utilizacin de puertos de entrada, salida y

configuracin; adems de la

utilizacin de mtodos disparados por tiempo y por eventos. El trabajo

desarrollado en [Brinkschulte et al., 2002] presenta la arquitectura OSA+: un
middleware con soporte para el diseo de sistemas en tiempo real heterogneos y
que permite el uso de pequeos microprocesadores como nodos (especialmente
pensado para sistemas empotrados). La entidad principal del middleware de
OSA+ son los servicios, comunicndose unos con otros a travs de trabajos, que
estn formados por rdenes (qu y cuando) y resultados. El middleware dispone
de una parte para servicios bsicos y otra, opcional, para extensin de servicios,
hacindolo flexible y escalable. La planificacin es realizada en base a los
trabajos. OSA+ puede garantizar el cumplimiento de restricciones slo si todas las
capas existentes por debajo del middleware pueden manejar sus funciones en
tiempo real: El hardware debe garantizar el cumplimiento de WCETs y el sistema
operativo debe ser de tiempo real. Se presenta adems el proyecto Komodo con la
implementacin

de

OSA+

en

Windows

NT

VxWorks;

utilizacin

de

microprocesadores PicoJava con cuatro hebras como mximo y manejo, tanto de

prioridades como de eventos y la adaptacin de una mquina virtual java. En

[Pfeffer et al., 2002] los autores continan con la arquitectura OSA sobre
microprocesadores Java, exponiendo adems las posibles formas de planificacin
que utilizan directamente sobre hardware: RMA, EDF, GP (porcentaje garantizado
de CPU). Finalizando con las plataformas de ejecucin, en [Yen et al., 2002] se
propone un mecanismo integrado basado en componentes para el desarrollo de
software empotrado; haciendo especial nfasis en dos problemas identificados por
los autores: identificacin de componentes junto con su recuperacin, y
composicin. Sin embargo, este trabajo no est centrado en tiempo real, aunque
la sintaxis presentada es interesante y puede ser ampliada para componentes en
tiempo real. En el trabajo presentado en [Yau y Zhou, 2002] se utilizan modelos
desde las primeras fases del diseo de una aplicacin, hasta su implementacin;
pensando que la utilizacin de modelos facilita el desarrollo de aplicaciones de
tiempo real frente a la utilizacin de los resultados de investigaciones tericas que
se centran ms en modelos basados en tareas en lugar de en modelos basados
en objetos o componentes como suelen ser gran parte de las aplicaciones
actuales. Adems de los modelos, se utilizan tambin aspectos para indicar el
cdigo de planificacin, pudiendo realizarse anlisis de planificabilidad durante el
diseo. Este trabajo est centrado pues en planificabilidad y orientacin a
aspectos. Para disear sistemas distribuidos de tiempo real predecibles se
requieren especificaciones de los componentes en el dominio del tiempo, adems
de las interfaces funcionales. El trabajo desarrollado en [Kopetz y Obermaisser,
2002] trata la especificacin temporal de interfaces y establece los principios de la
composicin. Se presenta una nueva interfaz aadida a los componentes
denominada Temporal firewall: interfaz para intercambios unidireccionales de
informacin de estado entre emisor y receptor. Son indicados adems los cuatro
principios que debe cumplir una arquitectura para que pueda realizarse una
composicin correcta: Desarrollo independiente de nodos. Estabilidad de los
servicios primordiales. El sistema de comunicacin debe ser eficiente. Las
rplicas deben ser deterministas. La interfaz presentada por los autores soporta
composicin temporal y garantiza el cumplimiento de los plazos. El trabajo
presentado en [Wellings et al., 2002] intenta demostrar cmo se puede tratar el

problema de planificacin dinmica en el anlisis de peores tiempos de ejecucin

con un mnimo de anotaciones. Este trabajo puede ser interesante como punto de
partida para la realizacin de herramientas. Sobre estndares normales de
componentes, tanto Java como CORBA estn siendo ampliamente utilizados para
el desarrollo de sistemas distribuidos, de consumo electrnico, tiempo real, etc. La
utilizacin de Java podr aumentar cuando las primeras implementaciones de
Java para Tiempo Real sean estables; por su parte, en el mbito de CORBA
podemos destacar a TAO [Levine et al., 1998], una implementacin de CORBA
diseada para tiempo real y con una amplia comunidad de usuarios. Un ejemplo
de utilizacin de Java para sistemas empotrados electrnicos, lo encontramos en
un trabajo de la Universidad nacional de Taiwan [Fu et al., 2000]. En este trabajo
existen tres componentes por nodo: sistema de tiempo real multitarea, controlador
y puentes entre diferentes sistemas. En el trabajo se tratan tambin temas de
planificacin, pero centrados en el nivel de un nodo concreto, y no de forma
distribuida.
En [Nakamoto et al., 2002] se utiliza CORBA en sistemas empotrados para
satlites. Los autores, sin embargo, no consideran RT-CORBA sino que utilizan un
CORBA empotrado propio. Ambos trabajos previos son interesantes en el sentido
de que muestran cmo los diseadores e implementadores de aplicaciones
resuelven las limitaciones de los modelos estndares y consiguen utilizar estos
modelos en aplicaciones de tiempo real. El inconveniente es que cada uno de
estos trabajos utiliza soluciones propias, con las dificultades de reutilizacin que
ello conlleva. De ah, el inters que supondra contar con un estndar para la
realizacin de aplicaciones con componentes para sistemas de tiempo real
empotrados. Un trabajo muy interesante que mezcla Java y CORBA, es la
implementacin de CORBA, Zen [Klefstad et al., 2002] donde se presenta un ORB
escrito en Real-Time Java, aunque an en sus primeros estados. Este ORB
desarrollado por los autores de TAO puede ser un referente a tener en cuenta en
un futuro prximo. Una ltima aportacin es la realizada por [Singh et al., 2002]
donde se presenta una propuesta basada en aspectos para desarrollar cdigo de
sincronizacin para sistemas distribuidos. Se comentan adems detalles de

implementacin, destacando su implementacin sobre el servicio de eventos de

tiempo real de TAO.