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 ISistemas distribuidos

Historia de los sistemas distribuidosAntecedentes 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 elENIAC (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 lotesHasta 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 llamadoslotes, 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 detransistoresque 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 elGM-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 elIBSYS.

Los sistemas multitareaA 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 comoCTSS(Sistema de Tiempo Compartido Compatible) y su sucesor MULTICS, precursor de los actuales sistemasUNIX.En 1964 IBM lanz la familia de ordenadores Sistemas/360, que utilizaban circuitos integrados como tecnologa principal, y elOS/360como 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 personalesLa 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, elMS/DOS(precursor de los actuales sistemas de Microsoft), elOS/2(inicialmente una iniciativa conjunta de Microsoft e IBM) y elSistema 1(precursor de Mac OS).Los sistemas UNIX, y LinuxEl desarrollo del sistema operativoMULTICSfue 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 deUNICS, y posteriormente se renombr aUNIX. Muchas son las versiones de UNIX que han evolucionado hasta la actualidad, entre ellas se encuentraLINUX, 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 Hates una de las distribuciones ms utilizadas en entornos de servidor, mientras que en los entornos de escritorio se abren paso otras comoUbuntu, 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, y actualmenteLa 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 DISTRIBUIDOa) 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 entidadese) 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 localizadosf) 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 DISTRIBUIDOS3.1. Ventajas con respecto a Sistemas Centralizados:Algunas ventajas de los sistemas distribuidos sobre los centralizados son: ElementoDescripcin

EconomaLos microprocesadores ofrecen mejor proporcin precio/rendimiento que los mainframes

VelocidadUn sistema distribuido puede tener mayor poder de cmputo que un mainframe

Distribucin inherenteAlgunas aplicaciones utilizan maquinas que estn separadas a cierta distancia

ConfiabilidadSi una mquina se descompone, el sistema puede sobrevivir como un todo

Crecimiento por incrementosSe puede aadir poder de cmputo en pequeos incrementos

Tabla 1.Ventajass de los SD sobre los centralizadosFuente: www.geocities.ws3.2. Ventajas con respecto a PCs Independientes:Algunas ventajas de los sistemas distribuidos sobre las computadoras aisladas son:ElementoDescripcin

Datos compartidosPermiten que varios usuarios tengan acceso a una base de datos comn

Dispositivos compartidosPermiten que varios usuarios compartan perifricos caros, como las impresoras de color

ComunicacinFacilita la comunicacin de persona a persona; por ejemplo mediante el correo electrnico

FlexibilidadDifunde 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 aisladasFuente: www.geocities.ws4. DESVENTAJAS DE LOS SISTEMAS DISTRIBUIDOSAlgunas desventajas de los sistemas distribuidos son: ElementoDescripcin

SoftwareExiste poco software para los sistemas distribuidos

RedesLa red se puede saturar o causar otros problemas

SeguridadUn 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 DISTRIBUIDOSObjetivo 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 secundariosEconoma.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 y 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 llamanmultiprocesadoresy aquellas que no, que a veces reciben el nombre demulticomputadoras. 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: conbusy conconmutador. 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 estnfuertemente acopladasy en otras estndbilmente 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 busesLos 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 conmutadorPara 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 busesPor 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 CPU-memoria.

Multicomputadoras con conmutadorSe 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:retculaehipercubo. 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: losdbilmente acopladosy losfuertemente 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 compartidoLos 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 / ServidorLaarquitectura cliente-servidorconsiste 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 y clarifica el diseo del sistema.Una disposicin muy comn son lossistemas multicapaen los que el servidor se descompone en diferentes programas que pueden ser ejecutados por diferentes computadoras aumentando as el grado de distribucin del sistema.Laarquitectura cliente-servidorsustituye a laarquitectura monolticaen la que no hay distribucin, tanto a nivel fsico como a 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:

EscalabilidadLas 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 funcionamientoRobustezLa naturaleza distribuida de las redespeer-to-peertambin 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.DescentralizacinEstas 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 y 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 y 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 cuatro servicios muy comnmente usados, como son Transacciones, Persistencia, Seguridad y Notificacin. Sera 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 y 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.