2. SISTEMAS OPERATIVOS DISTRIBUIDOS

2.1. INTRODUCCIÓN

Un sistema distribuido se define como una colección de computadores autónomos conectados por una red, y con el software distribuido adecuado para que el sistema sea visto por los usuarios como una única entidad capaz de proporcionar facilidades de computación.
El desarrollo de los sistemas distribuidos vino de la mano de las redes locales de alta velocidad a principios de 1970. Más 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. Esta tendencia se ha acelerado por el desarrollo de software para sistemas distribuidos, diseñado 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 colección de redes de área local y de área extensa interconectados, que en lazan millones de ordenadores.
Las aplicaciones de los sistemas distribuidos varían desde la provisión de capacidad de cómputo a grupos de usuarios, hasta sistemas bancarios, comunicaciones multimedia y abarcan prácticamente todas las aplicaciones comerciales y técnicas de los ordenadores. Los requisitos de dichas aplicaciones incluyen un alto nivel de fiabilidad, seguridad contra interferencias externas y privacidad de la información que el sistema mantiene. Se deben proveer accesos concurrentes a bases de datos por parte de muchos usuarios, garantizar tiempos de respuesta, proveer puntos de acceso al servicio que están distribuidos geográficamente, potencial para el crecimiento del sistema para acomodar la expansión del negocio y un marco para la integración de sistema usados por diferentes compañías y organizaciones de usuarios.

2.2. HISTORIA Y EVOLUCIÓN DE LOS SISTEMAS DISTRIBUIDOS.


Inicialmente, los ordenadores eran grandes centros de computación con entidad propia en centros de investigación o gubernamentales y Universidades. Con el boom de los PC en los 80, todos pudieron tener parte de esa capacidad de cómputo. Los PC, mucho más baratos que minis o mainframes, fueron una gran aportación para empresas y particulares. Aunque el ordenador personal estaba pensado para ser un elemento de computación autónomo y no formar redes de ordenadores, la posibilidad de compartir recursos gracias a la comunicación de varios PC, supone una ventaja que los fabricantes no pudieron ignorar, empezando así la carrera hacia los sistemas distribuidos, que tratan de aunar lo mejor de microordenadores y superordenadores a la vez, creando un ordenador virtual a partir de varios PC.

2.2.1. Orientado a Procedimiento

La comunicación entre dos PC en sistemas UNIX, mejoró mucho cuando BSD introdujo el concepto de socket, que permitía que la comunicación entre procesos situados en ordenadores distintos no fuera mucho más complicada que la de un programa que supiese leer y escribir ficheros. Los programas que emplean sockets establecen un protocolo de comunicación para poder entenderse.

El RPC, de Sun Micrososystems, es el siguiente nivel de abstracción y permite realizar llamadas a procedimientos independientemente de su localización, buscando con ello la transparencia de acceso para el programador.

2.2.2. Orientada a Objetos

Las tecnologías Orientadas a Objeto, hacen que estas abstracciones orientadas a procedimiento resulten inadecuadas, y propicia la aparición de sistemas como CORBA, RMI y COM/DCOM.

En este trabajo el término sistema distribuido hará referencia al uso de objetos por parte de otros que pueden estar situados o no en la misma máquina, de forma casi transparente. También se hablará de objetos servidores que ofrecen servicios, y de objetos cliente, que los usan, aunque esta distinción carece de sentido en sistemas distribuidos, donde un objeto puede adoptar simultáneamente ambos roles.

2.3. DESCRIPCIÓN GENERAL DE LOS SISTEMAS DISTRIBUIDOS

En un sistema operativo distribuido los usuarios pueden acceder a recursos remotos de la misma manera en que lo hacen para los recursos locales. La migración de datos y procesos de una instalación a otra queda bajo el control del sistema operativo distribuido.

Permiten distribuir trabajos, tareas o procesos, entre un conjunto de procesadores. Puede ser que este conjunto de procesadores esté en un equipo o en diferentes, en este caso es transparente para el usuario. Existen dos esquemas básicos de éstos. Un sistema fuertemente acoplado es aquel que comparte la memoria y un reloj global, cuyos tiempos de acceso son similares para todos los procesadores. En un sistema débilmente acoplado los procesadores no comparten ni memoria ni reloj, ya que cada uno cuenta con su memoria local.
Los sistemas distribuidos deben de ser muy confiables, ya que si un componente del sistema se descompone otro componente debe de ser capaz de reemplazarlo.

Características generales de los Sistemas Operativos distribuidos:

  • Colección de sistemas autónomos capaces de comunicación y cooperación mediante interconexiones hardware y software.
  • Proporciona abstracción de máquina virtual a los usuarios.
  • Objetivo clave es la transparencia.
  • Generalmente proporcionan medios para la compartición global de recursos.

clip_image001.gifServicios añadidos: denominación global, sistemas de archivos distribuidos, facilidades para distribución de cálculos (a través de comunicación de procesos internodos, llamadas a procedimientos remotos, etc.).


2.3_Sistema_Operativo_Distribuido.JPG
Sistema Operativo Distribuido.



2.3.1. CARACTERÍSTICAS DE LOS SISTEMAS OPERATIVOS
Los sistemas operativos distribuidos están basados en las ideas básicas:

Transparencia
Eficiencia
Flexibilidad
Escalabilidad
Tolerancia a Fallos
Concurrencia
Apertura
Compartición de recursos

Existen dos esquemas básicos: Los Fuertemente Acoplados y los débiles.
Un sistema fuertemente acoplado es aquel que comparte la memoria y un reloj global, cuyos tiempos de acceso son similares para todos los procesadores.
En un sistema débilmente acoplado los procesadores no comparten ni memoria ni reloj, ya que cada uno cuenta con su memoria local.

2.3.1.1. TRANSPARENCIA

La transparencia se define como la ocultación al usuario y al programador de aplicaciones de la separación de los componentes de un sistema distribuido, de manera que el sistema se percibe como un todo, en vez de una colección de componentes independientes. La transparencia ejerce una gran influencia en el diseño del software de sistema.
El manual de referencia RM-ODP [ISO 1996a] identifica ocho formas de transparencia. Estas proveen un resumen útil de la motivación y metas de los sistemas distribuidos. Las transparencias definidas son:

  • Transparencia de Acceso: Permite el acceso a los objetos de información remotos de la misma forma que a los objetos de información locales.
  • Transparencia de Localización: Permite el acceso a los objetos de información sin conocimiento de su localización
  • Transparencia de Concurrencia: Permite que varios procesos operen concurrentemente utilizando objetos de información compartidos y de forma que no exista interferencia entre ellos.
  • Transparencia de Replicación: Permite utilizar múltiples instancias de los objetos de información para incrementar la fiabilidad y las prestaciones sin que los usuarios o los programas de aplicación tengan por que conoces la existencia de las replicas.
  • Transparencia de Fallos: Permite a los usuarios y programas de aplicación completar sus tareas a pesar de la ocurrencia de fallos en el hardware o en el software.
  • Transparencia de Migración: Permite el movimiento de objetos de información dentro de un sistema sin afectar a los usuarios o a los programas de aplicación.
  • Transparencia de Prestaciones. Permite que el sistema sea reconfigurado para mejorar las prestaciones mientras la carga varia.
  • Transparencia de Escalado: Permite la expansión del sistema y de las aplicaciones sin cambiar la estructura del sistema o los algoritmos de la aplicación.
Las dos más importantes son las transparencias de acceso y de localización; su presencia o ausencia afecta fuertemente a la utilización de los recursos distribuidos. A menudo se las denomina a ambas transparencias de red. La transparencia de red provee un grado similar de anonimato en los recursos al que se encuentra en los sistemas centralizados.


El concepto de transparencia de un Sistema operativo distribuido va ligado a la idea de que todo el sistema funcione de forma similar en todos los puntos de la red, debido a esto queda como labor del sistema operativo coordinar el mecanismo que logre la unificación de todos los sistemas y recursos totalmente transparente para el usuario o aplicación.
El que el sistema disponga de varios procesadores debe lograr un mayor rendimiento del sistema, pero el sistema operativo debe controlar que tanto los usuarios como los programadores vean el núcleo del sistema distribuido como un único procesador, Es decir que la programación y la ejecución de los programas y tareas sean exactamente iguales que las de los sistemas operativos normales en aspectos visuales y de programación, pero más rápidos y eficientes por la distribución de la tareas.

2.3.1.2. EFICIENCIA

La idea base de los sistemas operativos distribuido es la de obtener sistemas mucho más rápidos que los utilizados de procesador único, Y para lograr esto tenemos que olvidar la idea antigua de ejecutar los programas en estos procesadores y pensar en distribuir las tareas a los procesadores libres más rápidos en cada momento.
El concepto global de que un procesador haga todas las tareas y la desarrolle rápido depende de muchos factores concretos: Velocidad, Memoria y tipo de procesamiento, Pero para un sistema operativo distribuido esto es mucho más fácil y eficiente, solo buscara un procesador más rápido y más libre para que desarrolle las tareas y hará un display de los resultados obtenidos.

2.3.1.3. FLEXIBILIDAD

La Flexibilidad dentro de sistema operativo distribuido, describe su capacidad para soportar cambios, actualizaciones y mejoras que le permitan irse desarrollando al mismo ritmo de la evolución tecnológica.

Dicha capacidad es una virtud y un conflicto. Una Virtud debido a las grandes necesidades de los sistemas operativos de mejorar después de las primeras versiones y un conflicto que surge entre los sistemas de con Núcleo Monolítico y los sistemas con Micro núcleo las cuales son dos arquitecturas distintas del núcleo del sistema operativo.

2.3.1.4. ESCALABILIDAD

Los sistemas distribuidos operan de manera efectiva y eficiente a muchas escalas diferentes. La escala más pequeña consiste en dos estaciones de trabajo y un servidor de ficheros, mientras que un sistema distribuido construido alrededor de una red de área local simple podría contener varios cientos de estaciones de trabajo, varios servidores de ficheros, servidores de impresión y otros servidores de propósito específico. A menudo se conectan varias redes de área local para formar internetworks, y éstas podrían contener muchos miles de ordenadores que forman un único sistema distribuido, permitiendo que los recursos sean compartidos entre todos ellos.
Tanto el software de sistema como el de aplicación no deberían cambiar cuando la escala del sistema se incrementa. La necesidad de escalabilidad no es solo un problema de prestaciones de red o de hardware, sino que está íntimamente ligada con todos los aspectos del diseño de los sistemas distribuidos. El diseño del sistema debe reconocer explícitamente la necesidad de escalabilidad o de lo contrario aparecerán serias limitaciones.
La demanda de escalabilidad en los sistemas distribuidos ha conducido a una filosofía de diseño en que cualquier recurso simple -hardware o software- puede extenderse para proporcionar servicio a tantos usuarios como se quiera. Esto es, si la demanda de un recurso crece, debería ser posible extender el sistema para dar el servicio,. Por ejemplo, la frecuencia con la que se accede a los ficheros crece cuando se incrementa el número de usuarios y estaciones de trabajo en un sistema distribuido. Entonces, debe ser posible añadir ordenadores servidores para evitar el cuello de botella que se produciría si un solo servidor de ficheros tuviera que manejar todas las peticiones de acceso a los ficheros. En este caso el sistema deberá estar diseñado de manera que permita trabajar con ficheros replicados en distintos servidores, con las consideraciones de consistencias que ello conlleva.
Cuando el tamaño y complejidad de las redes de ordenadores crece, es un objetivo primordial diseñar software de sistema distribuido que seguirá siendo eficiente y útil con esas nuevas configuraciones de la red. Resumiendo, el trabajo necesario para procesar una petición simple para acceder a un recurso compartido debería ser prácticamente independiente del tamaño de la red. Las técnicas necesarias para conseguir estos objetivos incluyen el uso de datos replicados, la técnica asociada de caching, y el uso de múltiples servidores para manejar ciertas tareas, aprovechando la concurrencia para permitir una mayor productividad. Una explicación completa de estas técnicas puede encontrarse en [ Colouris 1994 ].

2.3.1.5. TOLERANCIA A FALLOS
Los sistemas informáticos a veces fallan. Cuando se producen fallos en el software o en el hardware, los programas podrían producir resultados incorrectos o podrían pararse antes de terminar la computación que estaban realizando. El diseño de sistemas tolerantes a fallos se basa en dos cuestiones, complementarias entre sí: Redundancia hardware (uso de componentes redundantes) y recuperación del software (diseño de programas que sean capaces de recuperarse de los fallos).
En los sistemas distribuidos la redundancia puede plantearse en un grano más fino que el hardware, pueden replicarse los servidores individuales que son esenciales para la operación continuada de aplicaciones criticas.
La recuperación del software tiene relación con el diseño de software que sea capaz de recuperar (roll-back) el estado de los datos permanentes antes de que se produjera el fallo.
Los sistemas distribuidos también proveen un alto grado de disponibilidad en la vertiente de fallos hardware. La disponibilidad de un sistema es una medida de la proporción de tiempo que está disponible para su uso. Un fallo simple en una maquina multiusuario resulta en la no disponibilidad del sistema para todos los usuarios. Cuando uno de los componentes de un sistema distribuidos falla, solo se ve afectado el trabajo que estaba realizando el componente averiado. Un usuario podría desplazarse a otra estación de trabajo; un proceso servidor podría ejecutarse en otra máquina.

2.3.1.6. CONCURRENCIA
Cuando existen varios procesos en una única maquina decimos que se están ejecutando concurrentemente. Si el ordenador está equipado con un único procesador central, la concurrencia tiene lugar entrelazando la ejecución de los distintos procesos. Si la computadora tiene N procesadores, entonces se pueden estar ejecutando estrictamente a la vez hasta N procesos.
En los sistemas distribuidos hay muchas maquinas, cada una con uno o más procesadores centrales. Es decir, si hay M ordenadores en un sistema distribuido con un procesador central cada una entonces hasta M procesos estar ejecutándose en paralelo.
En un sistema distribuido que está basado en el modelo de compartición de recursos, la posibilidad de ejecución paralela ocurre por dos razones:
  1. Muchos usuarios interactúan simultáneamente con programas de aplicación.
  2. Muchos procesos servidores se ejecutan concurrentemente, cada uno respondiendo a diferentes peticiones de los procesos clientes.
El caso (1) es menos conflictivo, ya que normalmente las aplicaciones de interacción se ejecutan aisladamente en la estación de trabajo del usuario y no entran en conflicto con las aplicaciones ejecutadas en las estaciones de trabajo de otros usuarios.
El caso (2) surge debido a la existencia de uno o más procesos servidores para cada tipo de recurso. Estos procesos se ejecutan en distintas maquinas, de manera que se están ejecutando en paralelo diversos servidores, junto con diversos programas de aplicación. Las peticiones para acceder a los recursos de un servidor dado pueden ser encoladas en el servidor y ser procesadas secuencialmente o bien pueden ser procesadas varias concurrentemente por múltiples instancias del proceso gestor de recursos. Cuando esto ocurre los procesos servidores deben sincronizar sus acciones para asegurarse de que no existen conflictos. La sincronización debe ser cuidadosamente planeada para asegurar que no se pierden los beneficios de la concurrencia.

NÚCLEO MONOLÍTICO

Como ejemplo de sistema operativo de núcleo monolítico esta UNIX, estos sistemas tienen en núcleo grande y complejo, que engloba todos los servicios del sistema. Esta programado de forma no modular, y tiene un rendimiento mayor que un micro núcleo. Sin embargo, cualquier cambio a realzar en cualquiera de los servicios, requiere de hacer un STOP a todos los servicios y la recopilación del núcleo.

MICRO NÚCLEO.

La arquitectura ofrece la alternativa al núcleo monolítico, se basa en una programación altamente modular y tiene un tamaño mucho menor que el núcleo monolítico. Como consecuencia, el refinamiento y el control de errores son más rápidos y sencillos. Además, la actualización de los servicios es más sencilla y ágil. Ya que solo es necesario la recopilación del servicio y no de todo el núcleo. Como desventaja, El rendimiento se ve afectado negativamente.
En la actualidad la mayoría de los sistemas operativos distribuidos en desarrollo tienden a un diseño de micro núcleo el cual aun siendo un poco más lento, garantiza una estabilidad mayor y un aumento de la flexibilidad del sistema.

ESCALABILIDAD.
Un sistema operativo distribuido debería funcionar tanto para una docena de computadoras como para mil en una sola red, el tipo de red utilizada no debe de ser un problema ni su topología (LAN o WAN) (TOKEN RING o ETHERNET) y mucho menos la distancia entre los equipos. Sin embargo todo esto influye, Aunque estos puntos serian muy deseables, puede que la solución válida para unas cuantas computadoras no sean aplicables como para mil. Del mismo modo el tipo de red condiciona grandemente el rendimiento del sistema y puede que lo funcione para un tipo de red requiera modificaciones para otro.
Los sistemas operativos distribuidos necesitan de grandes estándares para trabajar y sobre todo de ajustes a las necesidades principales de cada red y sus usuarios. Este concepto propone que cualquier computador debe funcionar perfectamente como un sistema operativo distribuido, pero de la misma forma debe de formar parte y trabajar como más equipos no importan la cantidad o los recursos que estos le puedan proporcionar.

2.3.1.7. APERTURA (OPENNESSS)
Un sistema informático es abierto si el sistema puede ser extendido de diversas maneras. Un sistema puede ser abierto o cerrado con respecto a extensiones hardware (añadir periféricos, memoria o interfaces de comunicación, etc.) o con respecto a las extensiones software (añadir características al sistema operativo, protocolos de comunicación y servicios de compartición de recursos, etc.). La apertura de los sistemas distribuidos se determina primariamente por el grado hacia el que nuevos servicios de compartición de recursos se pueden añadir sin perjudicar ni duplicar a los ya existentes.
Básicamente los sistemas distribuidos cumplen una serie de características:
  1. Los interfaces software clave del sistema están claramente especificados y se ponen a disposición de los desarrolladores. En una palabra, los interfaces se hacen públicos.
  2. Los sistemas distribuidos abiertos se basan en la provisión de un mecanismo uniforme de comunicación entre procesos e interfaces publicados para acceder a recursos compartidos.
  3. Los sistemas distribuidos abiertos pueden construirse a partir de hardware y software heterogéneo, posiblemente proveniente de vendedores diferentes. Pero la conformidad de cada componente con el estándar publicado debe ser cuidadosamente comprobada y certificada si se quiere evitar tener problemas de integración.

2.3.1.8. COMPARTICIÓN DE RECURSOS
El término 'recurso' es bastante abstracto, pero es el que mejor caracteriza el abanico de entidades que pueden compartirse en un sistema distribuido. El abanico se extiende desde componentes hardware como discos e impresoras hasta elementos software como ficheros, ventanas, bases de datos y otros objetos de datos.
La idea de compartición de recursos no es nueva ni aparece en el marco de los sistemas distribuidos. Los sistemas multiusuario clásicos desde siempre han provisto compartición de recursos entre sus usuarios. Sin embargo, los recursos de una computadora multiusuario se comparten de manera natural entre todos sus usuarios. Por el contrario, los usuarios de estaciones de trabajo monousuario o computadoras personales dentro de un sistema distribuido no obtienen automáticamente los beneficios de la compartición de recursos.
Los recursos en un sistema distribuido están físicamente encapsulados en una de las computadoras y sólo pueden ser accedidos por otras computadoras mediante las comunicaciones (la red). Para que la compartición de recursos sea efectiva, ésta debe ser manejada por un programa que ofrezca un interfaz de comunicación permitiendo que el recurso sea accedido, manipulado y actualizado de una manera fiable y consistente. Surge el término genérico de gestor de recursos.
Un gestor de recursos es un modulo software que maneja un conjunto de recursos de un tipo en particular. Cada tipo de recurso requiere algunas políticas y métodos específicos junto con requisitos comunes para todos ellos. Éstos incluyen la provisión de un esquema de nombres para cada clase de recurso, permitir que los recursos individuales sean accedidos desde cualquier localización; la traslación de nombre de recurso a direcciones de comunicación y la coordinación de los accesos concurrentes que cambian el estado de los recursos compartidos para mantener la consistencia.
Un sistema distribuido puede verse de manera abstracta como un conjunto de gestores de recursos y un conjunto de programas que usan los recursos. Los usuarios de los recursos se comunican con los gestores de los recursos para acceder a los recursos compartidos del sistema. Esta perspectiva nos lleva a dos modelos de sistemas distribuidos: el modelo cliente-servidor y el modelo basado en objetos.

2.4. SINCRONIZACIÓN.
La sincronización es un punto clave para los sistemas operativos distribuidos. Para computadores únicos no es nada importante, pero en el caso de los recursos compartidos de la red, la sincronización es sumamente importante.
Los sistemas operativos distribuidos tienen un reloj por cada ordenador del sistema, con lo que es fundamental una coordinación entre todos los relojes para mostrar una hora única. Los osciladores de cada ordenador son ligeramente diferentes, y como consecuencia todo los relojes sufren un desfase y deben ser sincronizados continuamente. La sincronización no es trivial, porque se realiza a través de mensajes por la red. Cuyo tiempo de envió pude ser variable y depender de muchos factores como la distancia, la velocidad de transmisión y la propia estructura de la red.

2.5. EL RELOJ.
La sincronización del reloj no tiene que ser exacta y bastara con que sea aproximadamente igual en todos los ordenadores. Hay que tener en cuenta eso sí. El modo de actualizar la hora de un reloj es particular. Es fundamenta no retrasar nunca la hora, aunque el reloj adelante. En vez de eso, hay que atrasar la actualizaron del reloj. Frenarlo. Hasta que alcance la hora aproximada. Existen diferentes algoritmos de actualizan de la hora.
El Reloj es únicamente uno de los tantos problemas de sincronización que existen en los sistemas operativos distribuidos.

2.6. FUNCIONAMIENTO LÓGICO DEL SISTEMA
A medida en la que hemos ido desarrollando el tema, hemos declarado que un sistema operativo distribuido dentro de sus funciones básicas, es capaz de encontrar mecanismos para la asignación de tareas a procesadores que pueden estar dentro o fuera del equipo que está ejecutando el programa.
Añadido a esto los sistemas operativos distribuidos brindan más servicios de distribución como son los siguientes:
Servicios de Comunicación
Sistemas de Ficheros (File Sharing)
Servicios de Nombres
Servicios de Sincronización y Coordinación
Memoria Compartida Distribuida
Gestión de Procesos
Servicio de Seguridad

2.6.1. SERVICIOS DE COMUNICACIÓN

Los servicios de comunicación son los típicos servicios de red, pero en el caso de los sistemas operativos distribuidos son más especializados en ciertas áreas.
Los sistemas operativos distribuidos utilizan un concepto de interconexión llamado Multicast (Comunicación en Grupo) que le permite a todos los computadores del sistema trabajar como un solo elemento de la red. Toda la coordinación de los SOD son sincronizados por medio de SOCKETS lo cuales son paso de mensajes por la red que le permiten a los sistemas verificar cual es el equipo que está disponible o simplemente el estado de un equipo actual. Los SOCKETS también son utilizados para la actualización del reloj.

2.6.2. SISTEMAS DE FICHEROS (FILE SHARING)

El concepto del sistema de ficheros está basado en la gestión de distintos dispositivos en diferentes nodos ofreciendo a usuarios la misma visión que un Sistema Centralizado. Dicho sistema permite que los usuarios compartan información de forma transparente. Un buen ejemplo de esto es los contactos compartidos de cada terminal los cuales se reflejan en un solo modulo de contactos cada vez que una persona abre sus contactos.

2.6.3. SERVICIOS DE NOMBRES

Estos servicios identifican y localizan los recursos en el entorno distribuido. Existen dos:
Páginas Blancas y
Páginas Amarillas.
El servicio de páginas blancas es el propiamente dicho de nombres y el de páginas amarillas es el de directorios.


2.6.4. SERVICIOS DE SINCRONIZACIÓN

Los servicios de Sincronización son los que nos permiten mantener el los relojes de las computadoras individuales en un tiempo aproximado y apropiado. La sincronización puede ser de relojes Físicos, los cuales sincronizan los relojes de hardware y de Relojes Lógicos, los cuales ordenan la entrada, ejecución y salida de los eventos.

2.6.5. MEMORIA COMPARTIDA DISTRIBUIDA (DSM)

En un sistema operativo distribuido, la memoria pasa a ser físicamente privada pero lógicamente compartida. Es decir, un computador ejecuta los programas en su memoria propia, pero en caso de necesitar más memoria utilizara los recursos disponibles de otra computadora que este capacitada y preparada dentro de la red para compartir su memoria.

La Memoria compartida distribuida ayuda a que no se formen los famosos cuellos de botella, debido que busca los recursos necesarios para lograr cumplir todas las tareas asignadas.

2.6.6. SERVICIOS DE SEGURIDAD

Los servicios de seguridad de un SOD van ligados a permisos de acceso tanto a los datos compartidos como a los recursos. Los recursos de memoria por ejemplo, son asignados permisos a la cantidad de memoria compartida siguiendo las necesidades físicas de cada computadora.

Ejemplo: Una computadora de 128 MB RAM, la cual trabaja mucho es muy probable que en vez de poder compartir memoria requiera de memoria compartida de otras computadoras. Debido a esto, el DSM (Distribuid Shared Memory o Memoria Distribuida Compartida) es Deshabilitado para que no se disponga de recursos libres de este computador.

2.6.7. SISTEMA OPERATIVO DISTRIBUIDO VS SISTEMA DISTRIBUIDO

Existe una diferencia vital entre los sistemas operativos distribuidos y los sistemas distribuidos. Podríamos llamar a un Sistema Distribuido una capacidad del Sistema operativo Distribuido, es decir: Un sistema distribuido es la relación que existe entre una computadora independiente y un servidor de archivos o dispositivos compartidos. Cada computadora ejecuta sus programas en su memoria propia haciendo uso de su único microprocesador y memoria, este no comparte memoria ni asigna tareas a otros procesadores de la red. Sin embargo, un Sistema operativo distribuido tiene acceso a todos los dispositivos compartidos de la red incluyendo procesadores y memoria RAM.

2.7. EL MODELO CLIENTE SERVIDOR

El modelo cliente-servidor de un sistema distribuido es el modelo más conocido y más ampliamente adoptado en la actualidad. Hay un conjunto de procesos servidores, cada uno actuando como un gestor de recursos para una colección de recursos de un tipo, y una colección de procesos clientes, cada uno llevando a cabo una tarea que requiere acceso a algunos recursos hardware y software compartidos. Los gestores de recursos a su vez podrían necesitar acceder a recursos compartidos manejados por otros procesos, así que algunos procesos son ambos clientes y servidores. En el modelo, cliente-servidor, todos los recursos compartidos son mantenidos y manejados por los procesos servidores. Los procesos clientes realizan peticiones a los servidores cuando necesitan acceder a algún recurso. Si la petición es válida, entonces el servidor lleva a cabo la acción requerida y envía una respuesta al proceso cliente.
El termino proceso se usa aquí en el sentido clásico de los sistemas operativos. Un proceso es un programa en ejecución. Consiste en un entorno de ejecución con al menos un thread de control.
El modelo cliente-servidor nos da un enfoque efectivo y de propósito general para la compartición de información y de recursos en los sistemas distribuidos. El modelo puede ser implementado en una gran variedad de entornos software y hardware. Las computadoras que ejecuten los programas clientes y servidores pueden ser de muchos tipos y no existe la necesidad de distinguir entre ellas; los procesos cliente y servidor pueden incluso residir en la misma máquina.
En esta visión simple del modelo cliente-servidor, cada proceso servidor podría ser visto como un proveedor centralizado de los recursos que maneja. La provisión de recursos centralizada no es deseable en los sistemas distribuidos. Es por esta razón por lo que se hace una distinción entre los servicios proporcionados a los clientes y los servidores encargados de proveer dichos servicios. Se considera un servicio como una entidad abstracta que puede ser provista por varios procesos servidores ejecutándose en computadoras separadas y cooperando vía red.
El modelo cliente-servidor se ha extendido y utilizado en los sistemas actuales con servicios manejando muchos diferentes tipos de recursos compartidos - correo electrónico y mensajes de noticias, ficheros, sincronización de relojes, almacenamiento en disco, impresoras, comunicaciones de área extensa, e incluso las interfaces gráficas de usuario. Pero no es posible que todos los recursos que existen en un sistema distribuido sean manejados y compartidos de esta manera; algunos tipos de recursos deben permanecer locales a cada computadora de cara a una mayor eficiencia - RAM, procesador, interfaz de red local -. Estos recursos clave son manejados separadamente por un sistema operativo en cada máquina; solo podrían ser compartidos entre procesos localizados en el mismo ordenador.
Aunque el modelo cliente-servidor no satisface todos los requisitos necesarios para todas las aplicaciones distribuidos, es adecuado para muchas de las aplicaciones actuales y provee una base efectiva para los sistemas operativos distribuidos de propósito general.

2.8. MIDDLEWARE

El término middleware se discute en [Lewandosky 1998]. El software distribuido requerido para facilitar las interacciones cliente-servidor se denomina middleware. El acceso transparente a servicios y recursos no locales distribuidos a través de una red se provee a través del middleware, que sirve como marco para la comunicaciones entre las porciones cliente y servidor de un sistema.
El middleware define: el API que usan los clientes para pedir un servicio a un servidor, la transmisión física de la petición vía red, y la devolución de resultados desde el servidor al cliente. Ejemplos de middleware estándar para dominios específicos incluyen: ODBC, para bases de datos, Lotus para groupware, HTTP y SSL para Internet y CORBA, DCOM y JAVA RMI para objetos distribuidos.
El middleware fundamental o genérico es la base de los sistemas cliente-servidor. Los servicios de autentificación en red, llamadas a procedimiento remoto, sistemas de ficheros distribuidos y servicios de tiempo en red se consideran parte del middleware genérico. Este tipo de middleware empieza a ser parte estándar de los sistemas operativos modernos como Windows NT. En sistemas donde no se disponga deberá recurrirse a middlware del tipo OSD DCE (Distributed Computing Environment) [OSF 1994]. El middleware específico para un dominio complementa al middlware genérico de cara a aplicaciones mucho mas especificas.
El protocolo de comunicaciones más usado por el middlware, tanto genérico como específico, es TCP/IP. Esto se debe a su amplia difusión en todos los sistemas operativos del mercado y en especial en los ordenadores personales.

2.9. MIDDLEWARE PARA SISTEMAS CLIENTE-SERVIDOR: RPC
Un servicio proporcionado por un servidor no es más que un conjunto de operaciones disponibles para los clientes. El acceso al servicio se realiza mediante un protocolo de peticiones respuesta con llamadas bloqueantes. Ejemplo: Un servicio de ficheros. El servidor mantiene como recurso compartido los ficheros. Sobre el recurso compartido se pueden realizar diversas operaciones: Crear, Abrir, Leer, etc.
Los mecanismos RPC persiguen que los clientes se abstraigan e invoquen procedimientos remotos (operaciones) para obtener servicios. Así, el procedimiento llamado se ejecuta en otro proceso de otra máquina (servidor). El objetivo de RPC es mantener la semántica de la llamada a procedimiento normal en un entorno de implementación totalmente distinto. La ventaja está en que el desarrollador se preocupa de los interfaces que soporta el servidor. Para especificar dichos interfaces se dispones de un IDL (lenguaje de definición de interfaces).
Los sistemas RPC disponen de mecanismos de RPC integrados en un lenguaje de programación particular que incluye además una notación para definir interfaces entre clientes y servidores (IDL específico). Un IDL permite definir el nombre de las operaciones soportadas por el servidor y sus parámetros (tipo y dirección). También se deben proveer mecanismos para manejo de excepciones, garantizar la ejecución de las operaciones, así como la detección de fallos. Todo ello de la forma más transparente posible.
El software (middleware) que soporta RPC tiene tres tareas fundamentales:
  1. Procesamiento relacionado con los interfaces: Integrar RPC en el entorno de programación, empaquetamiento (marshalling)/desempaquetamiento (unmarshalling) y despachar las peticiones al procedimiento adecuado.
  2. Gestionar las comunicaciones
  3. Enlazado (Binding): Localizar al servidor de un servicio.
La interfaz no es más que un número de procedimiento acordado entre cliente y servidor. Este número viaja dentro del mensaje RPC transmitido por la red. En la parte cliente existe un procedimiento de 'stub' encargado de empaquetar/desempaquetar los argumentos de la llamada, convertir la llamada local en una llamada remota. Esto supone enviar un mensaje, esperar la respuesta y retornar los resultados. En la parte del servidor esta el despachador, junto con el conjunto de procedimientos de stub de servidor, que tienen una misión similar a los de la parte cliente. El despachador selecciona el procedimiento de stub adecuado a partir del número de procedimiento requerido.
El compilador de IDL genera los procedimientos de stub de cliente y de servidor, las operaciones de empaquetamiento y desempaquetamiento así como los ficheros de cabecera necesarios.
Las peticiones de los clientes son con respecto a un nombre de servicio. En última instancia deben ser dirigidas a un puerto en el servidor. En un sistema distribuido un binder es un servicio separado que mantiene una tabla que contiene correspondencias de nombres de servicios con puertos de servidor. Se trata, como veremos más adelante, de un servicio de nombres. Importar un servicio es pedir al binder que busque el nombre del interfaz y retorne el puerto del servidor. Exportar un servicio es registrarlo de cara el binder. El binder deberá estar en un puerto bien conocido o, al menos, se le podrá localizar.
Una implementación bastante habitual de RPC es la de SUN. Incorpora todo un conjunto de primitivas para trabajar con RPC en lenguaje C. Dispone de una representación neutral de los datos para su empaquetamiento, XDR (External Data Representation). XDR también se denomina al IDL que se proporciona.
El compilador de IDL, que se denomina rpcgen, genera los procedimientos de stub, el procedimiento main del servidor y el despachador, el código de conversión de los parámetros a XDR, así como los ficheros de cabecera correspondientes.
El binder recibe el nombre de port mapper. Cuando se activa un servidor en una máquina remota ésta se registra con el port mapper, obteniendo un puerto de comunicación a través del cual escuchar. Cuando se quiere acceder a un servicio hay que contactar con el port mapper de la máquina remota, preguntándole por el nombre de un determinado servicio, devolviéndose el puerto de comunicación en el que está a la escucha el servidor correspondiente. Por tanto para acceder a una determinada operación de un servicio hace falta la siguiente información: [host:servicio:procedimiento].

2.10. SERVIDORES PESADOS VS CLIENTES PESADOS
[Lewandowsky 1008] realiza una discusión de este concepto dentro del marco de los sistemas cliente-servidor. Los especialistas en sistemas de información califican como 'pesada' (fat) una parte de un sistema con una cantidad de funcionalidad desproporcionada. Por el contrario, una parte de sistema se considera ligera (thin) si tiene menos responsabilidades [Orfali 1996].
En un sistema cliente-servidor la porción del servidor casi siempre mantiene los datos, mientras que la porción del cliente es responsable de la interfaz de usuario. El desplazamiento de la lógica de la aplicación constituye la distinción entre clientes 'pesados' y servidores 'pesados'. Los sistemas servidores 'pesados' delegan más responsabilidad de la lógica de la aplicación en los servidores, mientras que los clientes 'pesados' dan al cliente mayor responsabilidad. Ejemplo de servidor pesado es un servidor Web, mientras que muchos de los clientes en sistemas de bases de datos constituyen clientes 'pesados'.
Aunque los sistemas basados en servidores 'pesados' han sido los más utilizados en el pasado, en la actualidad muchos diseñadores prefieren sistemas con clientes 'pesados', debido a que son más fáciles de implementar. Los clientes 'pesados' permiten a los usuarios crear aplicaciones y modificar los front-end del sistema fácilmente, pero a costa de reducir la encapsulación de los datos; cuanta más responsabilidad se coloque en un cliente, el cliente requerirá un conocimiento más íntimo de la organización de los datos del servidor.
Por otra parte, un servidor 'pesado' es más fácilmente explotable, esto es, más fácil de explotar. Además este tipo de servidor asegura una mayor compatibilidad entre clientes y servidores. Por ejemplo, una página Web diseñada bajo este modelo supondría que no hay disponibilidad de applets de Java, plugins o ActiveX's debido a que el usuario está usando un cliente 'ligero', (un navegador básico), y el servidor estaría restringido al estándar HTML 2.0. El uso de este modelo de cliente 'ligero' asegura que todos los usuarios visualizan una página "aceptable", aunque no se pueden proveer las características avanzadas disponibles con un cliente 'pesado'.

2.11. SISTEMAS N-TIERED
El modelo canónico cliente-servidor asume exactamente dos participantes discretos en el sistema. Se denomina sistema 'two-tier'; la lógica de la aplicación puede estar en el cliente, el servidor, o compartida entre los dos. También puede darse el caso de tener la lógica de la aplicación separada de los datos y de la interfaz de usuario, convirtiéndose el sistema en 'three-tiered'. En un sistema 'three-tiered' ideal toda la lógica de la aplicación reside en una capa separada. Esto ocurre raramente en los sistemas actuales. Siempre hay ciertas partes que permanecen o bien del lado del cliente o del lado del servidor.
Las aplicaciones Web estándar son un ejemplo clásico de sistemas 'three-tiered'. Por un lado se tienen la interfaz de usuario, provista por la interpretación de HTML, por un navegador. Los componentes embebidos visualizados por el navegador residen en la capa media; pueden ser applets de Java, ActiveX's o cualquier otra clase de entidad que provea lógica de aplicación para el sistema. Por último se tienen los datos suministrados por el servidor Web.
2.12. VENTAJAS DE LOS SISTEMAS CLIENTE-SERVIDOR
La principal ventaja de los sistemas cliente-servidor está en la correspondencia natural de las aplicaciones en el marco cliente-servidor. Un ejemplo de esto es una agenda electrónica. Debido a que los datos son relativamente estáticos y son vistos de manera uniforme por todos los usuarios del sistema parece lógico colocarlos en un servidor que acepte peticiones sobre dichos datos. Es más, en este caso la lógica de aplicación debería estar colocada del lado del servidor, para proporcionar una mayor flexibilidad al sistema de búsquedas (cambios en los algoritmos, etcétera...).
Como resultado de la disponibilidad de middleware compatible para múltiples plataformas y de los avances recientes de la interoperabilidad binaria, los sistemas cliente-servidor pueden conectar clientes ejecutándose en una plataforma con servidores ejecutándose en otra plataforma completamente distinta. Las tecnologías como Java y los ORBs (Object Request Brokers), de los que trata en profundidad este trabajo, esperan proveer una total integración de todas las plataformas en unos pocos años. Si las porciones de un sistema cliente-servidor encapsulan una única función y siguen un interfaz perfectamente definido, aquellas partes del sistema que proveen los servicios pueden ser intercambiadas sin afectar a otras porciones del sistema. Esto permite a los usuarios, desarrolladores y administradores adecuar el sistema con sus necesidades en cada momento.
Otra ventaja es la posibilidad de ejecutar aplicaciones que hacen uso intensivo de los recursos en plataformas hardware de bajo coste. También el sistema es más escalable, pudiéndose añadir tanto nuevo clientes como nuevos servidores.

2.13. SINCRONIZACION DE LOS SISTEMAS DISTRIBUIDOS

2.13.1.ALGORITMOS PARA LA SINCRONIZACIÓN DE RELOJES

La sincronización de relojes en un sistema distribuido consiste en garantizar que los procesos se ejecuten en forma cronológica y a la misma vez respetar el orden de los eventos dentro del sistema. Para lograr esto existen varios métodos o algoritmos que se programan dentro del sistema operativo, entre los cuales tenemos:

2.13.1.1. Algoritmo de Cristian

Este algoritmo está basado en el uso del tiempo coordenado universal (siglas en inglés, UTC), el cual es recibido por un equipo dentro del sistema distribuido. Este equipo, denominado receptor de UTC, recibe a su vez solicitudes periódicas del tiempo del resto de máquinas del sistema a cada uno de los cuales les envía una respuesta en el menor plazo posible informando el tiempo UTC solicitado, con lo cual todas las máquinas del sistema actualicen su hora y se mantenga así sincronizado todo el sistema. El receptor de UTC recibe el tiempo a través de diversos medios disponibles, entre los cuales se menciona las ondas de radio, Internet, entre otros.

Un gran problema en este algoritmo es que el tiempo no puede correr hacia atrás:

i. El tiempo del receptor UTC no puede ser menor que el tiempo de la máquina que le solicitó el tiempo.
ii. El servidor de UTC debe procesar las solicitudes de tiempo con el concepto de interrupciones, lo cual incide en el tiempo de atención.
iii. El intervalo de transmisión de la solicitud y su respuesta debe ser tomado en cuenta para la sincronización. El tiempo de propagación se suma al tiempo del servidor para sincronizar al emisor cuando éste recibe la respuesta.

2.13.1.2. Algoritmo de Berkeley

Un sistema distribuido basado en el algoritmo de Berkeley no dispone del tiempo coordenado universal (UTC); en lugar de ello, el sistema maneja su propia hora. Para realizar la sincronización del tiempo en el sistema, también existe un servidor de tiempo que, a diferencia del algoritmo de Cristian, se comporta de manera activa. Este servidor realiza un muestreo periódico del tiempo que poseen algunas de las máquinas del sistema, con lo cual calcula un tiempo promedio, el cual es enviado a todas las máquinas del sistema a fin de sincronizarlo.

2.13.1.3. Algoritmo con Promedio

Este algoritmo no dispone de un servidor que controle, centralice y mantenga la sincronización del tiempo en el sistema. A diferencia de ello, cada máquina del sistema informa su hora local con cada mensaje que requiera enviar a otra máquina o máquinas del sistema. A partir de ese momento, cada máquina inicializa localmente un cronómetro, cuya duración es de intervalo y longitud fija. A partir de ese momento, cada máquina promedia su hora local con el uso de las horas que le informan el resto de las máquinas que interactúan con ella.

2.13.1.4. Algoritmos para la Exclusión Mutua

Estos algoritmos están definidos para asegurar el cumplimiento de exclusión mutua entre procesos que requieren acceder a una región crítica del sistema.

i. Centralizado
Este algoritmo simula la filosofía de operación de exclusión mutua utilizada en sistemas monoprocesadores. Para ello, existe una máquina en el sistema distribuido que se encarga de controlar el acceso a las diferentes secciones críticas, la cual es denominada coordinador. Cada proceso del sistema que requiera acceso a una sección crítica, debe solicitar acceso al coordinador, el cual lo otorgará en caso que la sección crítica esté disponible; caso contrario, colocará en una cola de espera al proceso solicitante. Cuando un proceso que recibió acceso a la sección crítica culmina su tarea, informa por igual al coordinador a fin de que éste pueda otorgar acceso a un próximo proceso solicitante o que se encuentre en cola de espera.
Este algoritmo presenta una gran limitante, consistente en que el coordinador representa un único punto de control para el acceso a las diferentes secciones críticas del sistema distribuido, lo cual se convierte en un cuello de botella que puede afectar la eficiencia de los procesos que se ejecutan en el sistema. Igualmente, cualquier falla que presente el coordinador ocasionará la paralización de los procesos.
ii. Distribuido
Este algoritmo fue desarrollado a fin de eliminar el problema latente en el algoritmo centralizado. Por lo tanto, su enfoque está basado en no disponer de un único coordinador para el control de acceso a las secciones críticas del sistema distribuido.
En este sentido, cada proceso que requiere acceso a una sección crítica, envía su solicitud a todos los procesos existentes en el sistema, identificándose así mismo y a la sección crítica que desea acceder. Cada proceso receptor envía su respuesta al proceso solicitante, indicando una de las siguientes posibles respuestas:
§ Sección crítica no en uso por el proceso receptor. Mensaje de respuesta: OK.
§ Sección crítica en uso por el proceso receptor. Mensaje de respuesta: no aplica, coloca al proceso emisor en cola de espera.
§ Sección crítica no en uso pero solicitada por el proceso receptor.
o Mensaje de respuesta: OK, si la solicitud es anterior a la del receptor.
o Mensaje de respuesta: No aplica, si la solicitud es posterior a la del receptor, coloca al proceso de emisor en cola de espera.
Sin embargo, este algoritmo también contiene un problema, consistente en que si un proceso presenta una falla no podrá enviar su respuesta ante la solicitud de un proceso emisor, por lo cual esto será interpretado como una negación de acceso, bloqueando a todos los procesos que soliciten acceso a cualquier sección crítica.
iii. De Anillo de Fichas (Token Ring)
Este algoritmo establece un anillo lógico de procesos, controlado por software, a través del cual se hace circular una ficha o testigo (token) entre cada proceso. Cuando un proceso recibe la ficha, puede entrar a una sección crítica si lo requiere, procesar todas sus tareas, abandonar la sección crítica y entregar la ficha al próximo proceso del anillo. Este proceso se repite continuamente en el anillo de procesos. Cuando un proceso recibe la ficha y no requiere entrar a una sección crítica, pasa la ficha inmediatamente al siguiente proceso.
Este algoritmo contiene una debilidad, asociada a la posible pérdida de la ficha de control para el acceso a las secciones críticas. Si esto ocurre, los procesos del sistema asumirán que la ficha está en uso por algún proceso que se encuentra en la sección crítica.
iv. De Elección
Estos algoritmos están diseñados para elegir un proceso coordinador. En los mismos, se garantiza que una vez realizada la elección del proceso coordinador, la misma concluya con el acuerdo de todos los procesos el sistema en la elección de un nuevo coordinador.
v. Del Grandulón (García Molina)
Este algoritmo se inicia cuando un proceso cualquiera determina que no hay respuesta a las solicitudes hechas al proceso coordinador. En este momento, este proceso envía a todos los procesos mayores que él un mensaje de elección del nuevo coordinador, lo cual puede conllevar a los siguientes escenarios:
§ Un proceso, con un número mayor que el proceso emisor del mensaje, responda OK, con lo cual queda elegido como coordinador del sistema.
§ Ningún proceso responde el mensaje de elección, con lo cual el proceso emisor queda electo como proceso coordinador.
vi. De Anillo
Este algoritmo opera de manera similar al algoritmo del Grandulón, con la diferencia que en este método se presenta las siguientes variantes:
El mensaje de elección se hace circular a todos los procesos del sistema, y no solo a los procesos mayores que el emisor.
Cada proceso inscribe en el mensaje su identificación.
Una vez que el mensaje completa el anillo y regresa a proceso emisor, quien establece como nuevo coordinador al proceso con el número mayor.
Se hace circular a través del anillo un nuevo mensaje indicando quién es el coordinador del sistema.

2.13.1.5. Transacciones Atómicas

Es un método de sincronización a alto nivel, que a diferencia de los métodos revisados hasta el momento, no ocupa al programador en los aspectos de exclusión mutua, prevención de bloqueos y recuperación ante fallos. Por el contrario, este método orienta el esfuerzo del programador a los verdaderos problemas y esencia de la sincronización de sistemas distribuidos.
El concepto de transacciones atómicas consiste en garantizar que todos los procesos que conforman una transacción deben ejecutarse en forma completa y satisfactoria. De producirse falla en alguno de los procesos, toda la transacción falla, revirtiéndose la misma y procediéndose a su reinicio.

2.13.2 PROCESOS Y PROCESADORES

a. Hilos de Procesos (Threads)
Hoy en día los sistemas operativos pueden soportar múltiples hilos de control dentro de un proceso. Dos características notorias en los hilos de procesos es que comparten un único espacio de direcciones, y a su vez, simulan un ejecútese de múltiples procesos independientes como si fuera en paralelo.
Solo en una maquina que tenga multiprocesador se pueden ejecutar realmente procesos en paralelo. Los hilos se pueden colocar en cuatro estados:
§ En ejecución, cuando el proceso se está ejecutando.
§ Bloqueado, cuando un proceso depende de un recurso critico.
§ Listo, cuando puede utilizarse nuevamente.
§ Terminado, cuando culmina su tarea.
b. Implantación de un Paquete de Hilos
Existen dos formas de implantar los hilos:
i. En el usuario
Cuando se realiza la instalación de los paquetes a nivel de usuario, el núcleo no debe saber de su existencia, por lo cual el núcleo solo va a manejar un único hilo. Los hilos se ejecutan en el sistema por tiempo de ejecución en grupos de procedimientos. En el caso que el sistema o procedimiento requiera suspender un hilo dentro de su manejo, almacena los registros del hilo en una tabla, busca los no bloqueados y vuelve a cargar los registros de la máquina con los valores iníciales.
Sus principales ventajas son:
§ Cada proceso o hilo puede tener su propio algoritmo o planificación de proceso.
§ El intercambio es más rápido, ya que se utilizan los identificadores en el núcleo.
§ Tiene una mayor escalabilidad en el incremento de procesos.
ii. En el Núcleo
A diferencia de la implementación en el cliente, la implementación en el núcleo no necesita el manejo de tiempo de ejecución; cada proceso dentro del mismo maneja su tabla de procesos, aunque esto signifique un costo mayor en recursos de máquina y tiempo de procesamiento.
Una de las ventajas más relevantes es que no se requiere de llamadas de bloqueo al sistema.

2.14. GESTION DE ARCHIVOS DISTRIBUIDOS

2.14.1.Estructura del Sistema de Archivos Distribuidos
Básicamente, un sistema de archivos distribuidos está conformado por dos componentes principales, sobre las cuales reposa todo el funcionamiento efectivo que permite a un sistema distribuido almacenar programas y datos, así como mantenerlos disponibles a dicho sistema cuando este lo necesite, en las tareas relevantes al acceso de lectura y escritura.
Estos componentes son denominados servicio de archivos y servicio de directorios, los cuales se pasan a explicar de inmediato.
2.14.1.1. Servicio de Archivos
Este servicio, propio del sistema operativo, es el encargado de controlar y poner a disposición todas las operaciones, definiciones y características propias de los archivos del sistema. Este servicio no está relacionado en lo absoluto con el manejo de la lógica o significado interno de la data contenida en los archivos, ni mucho menos en la relación o jerarquización que esta data mantienen entre sí, puesto que todo ello es materia de interés y trabajo para los aplicativos que se ejecutan en el sistema y que acceden a estos datos contenidos en el archivo.
Realmente el servicio de archivos del sistema operativo se encarga de establecer el método de acceso que dispondrán los archivos, así como la organización que tendrán físicamente los datos dentro de ellos. Dependiendo del tipo de distribución y sistema operativo, se podrá establecer la conformación de los archivos como cadenas secuenciales de bytes, o bien como agrupación lógica secuencial de registros identificables o no. De aquí parte obviamente el método de acceso que aceptarán estos archivos para su lectura y escritura. Por ello nos encontramos en cada sistema operativo, distribuido o no, definiciones propias del sistema de archivos; tal es el caso de los archivos VSAM o QSAM en la plataforma centralizada mainframe, o sistemas de archivos FAT32 o NTFS en el sistema distribuido Windows, así como Ext2/Ext3 en Linux, entre otros.
Adicionalmente, el servicio de archivos tiene un papel primordial en cuanto al establecimiento de atributos o características de los archivos, con lo cual el sistema operativo establece políticas de acceso sobre los mismos. Aunque estos atributos no son parte de la data contenida en los archivos, permiten establecer parámetros de propiedad o autoría, permisología en el acceso bajo niveles de lectura, escritura, modificación y/o eliminación, así como atributos para bitácora de modificaciones.
2.14.1.2. Servicio de Directorios
Básicamente brinda las capacidades para la creación y eliminación de directorios en el sistema, los cuales contendrán internamente al conjunto de archivos. Así mismo, el servicio de directorios establece la estructura y nomenclatura que se aplicará a los nombres de archivos, así como a los nombres de los propios directorios. De esta manera, todas las piezas de software que requieran acceder datos contenidos en los archivos deberán hacerlo bajo esta nomenclatura.

2.14.2.Niveles de Jerarquía en un Sistema de Archivos Distribuidos
El servicio de directorios del sistema operativo, permite que se establezca una relación de tipo jerárquica entre los archivos. Esta relación, al igual que se mencionó en la descripción del servicio de archivos, no está asociada a la data interna de los archivos. En este caso, se trata de mantener una relación jerárquica de arriba hacia abajo en cuanto a la definición de directorios dentro de directorios. Cuando entra en escena el concepto de subdirectorios, se permite entonces la agrupación lógica de archivos que guardan alguna relación entre sí.
El hecho de que los directorios puedan contener internamente subdirectorios, con una dimensionalidad máxima establecida por el propio sistema operativo, da origen a niveles de jerarquía en el sistema de archivos distribuidos, jerarquías que serán conocidas por todas las máquinas y procesos que conformen el sistema.

2.15. GESTIÓN DE MEMORIA
2.15.1.Administración de Memoria Distribuida

A fin de manejar la memoria en un sistema distribuido, es establecen dos métodos aceptados:
§ Proveer un espacio de direccionamiento virtual que sea compartido entre todas las computadoras que conforman el sistema distribuido. La mayor complejidad de implementar un espacio de memoria compartida distribuida, es el mantener la consistencia de los datos que son actualizados en dicha área, así como reducir los retardos en el acceso de los mismos. Es decir, el control y bloqueo de los equipos que escriben en esta área debe ser eficiente.
§ Análogo al esquema monoprocesador, manejando páginas o bloques de memoria (virtualización) de aquellos datos del sistema menos accedidos. Estos bloques o páginas son enviados por el administrador de memoria a petición de cada máquina del sistema. Aunque la duplicidad de los bloques de memoria compartidos aumenta el rendimiento y evita los problemas de acceder una única área de memoria, se origina un problema de consistencia entre las diferentes copias de la página que se reparten en el sistema. Adicionalmente, con cada escritura es necesario actualizar todas las copias del bloque de memoria, con lo cual el envío de la página por la red provocaría un tiempo de espera inaceptable.
§
Para solucionar estos problemas, se han propuesto diferentes modelos que aseguren la consistencia y que establezcan un nivel aceptable de rendimiento.

2.15.2.Modelos de Consistencia

i. Estricta
Cualquier lectura a una localidad de memoria, regresa el valor guardado por la operación de escritura más reciente en dicha localidad.
ii. Secuencial
El resultado de cualquier ejecución es el mismo que si las operaciones de todos los procesos fueran ejecutadas en algún orden secuencial, y las operaciones de cada proceso individual aparecen en esta secuencia en el orden especificado por su programa.
iii. Causal
Las escrituras potencialmente relacionadas de forma causal son vistas por todos los procesos en el mismo orden. Las escrituras concurrentes pueden ser vistas en un orden diferente en maquinas diferentes.


iv. PRAM
Las escrituras realizadas por un proceso son recibidas por los otros procesos en el orden en que son realizadas, pero las escrituras de procesos diferentes pueden verse en un orden diferente por procesos diferentes.
v. Del Procesador
Para cada posición de memoria existe un acuerdo local acerca del orden de las escrituras en ella. Las escrituras en diferentes posiciones no tienen que ser vistas en el mismo orden por los diferentes procesos.
vi. Débil
Los accesos a las variables de sincronización son secuencialmente consistentes.
No se permite realizar un acceso a una variable de sincronización hasta que las escrituras anteriores hayan terminado en todas partes.
No se permite realizar un acceso a los datos (L/E) hasta realizar todos los accesos anteriores a las variables de sincronización
vii. De Liberación
Antes de realizar un acceso ordinario a una variable compartida, deben terminar con éxito todas las adquisiciones anteriores del proceso en cuestión.
Antes de permitir la realización de una liberación, deben terminar las (L/E) anteriores del proceso.
Los accesos de adquisición y liberación deben ser consistentes con el procesador (no se pide la consistencia secuencial).
viii. De Entrada
No se permite realizar un acceso de adquisición a una variable de sincronización con respecto de un proceso hasta que se realicen todas las actualizaciones de los datos compartidos protegidos con respecto de ese proceso.
Antes de permitir la realización de un acceso en modo exclusivo a una variable de sincronización por un proceso, ningún otro proceso debe poseer la variable de sincronización, ni siquiera en modo exclusivo.
Después de realizar un acceso en modo exclusivo a una variable de sincronización, no se puede realizar el siguiente acceso en modo no exclusivo de otro proceso a esa variable de sincronización hasta haber sido realizado con respecto del propietario de esa variable.

2.16. SISTEMAS OPERATIVOS MAS CONOCIDOS

2.16.1.Cuadro Comparativo


Sistema operativo
Windows XP
Mac OS
Debian GNU/Linux
Solaris
Creador
Microsoft
Apple
Proyecto Debian
Sun
Año de primera distribución
2001
1984
1993
1989
Última versión estable
5.1 build 2600 con Service Pack 2
9.2
4.0 Etch
10
Costo
143,526€ (Home)
217,593€ (Pro)

Gratuito hasta 7.5.5, 9.2 cuesta 15,60€ para dueños de Mac OS X
Gratuito
Gratuito
Licencia
No Libre
No Libre
Libre: GPL
No Libre
Semilibre: CDDL

Tipo de usuario
Hogar, negocios y redes
Hogar, diseño, negocios
Hogar, ciencia, servidores, redes, diseño, negocios
Servidores, negocios
Tipo de kernel
Monolítico
Ninguno/Microkernel
Monolítico
Monolítico
Arquitecturas de procesador soportadas
Intel x86, Intel x86_64, Intel IA64
PowerPC
Intel x86, Intel IA64, AMD64, DEC Alpha, ARM, HP PA-RISC, MIPS (big endian), MIPS (little endian), PowerPC, IMB S/390, Sparc
Intel x86, AMD64, Sparc, UltraSparc, PowerPC (sólo en versión 2.5.1), Sun4d, Sun4m
Sistema de archivos por defecto
NTFS
HFS/HFS+
ext3
UFS/ZFS
Soporte de sistemas de archivo de 16 bits


No se encontró Información
No se encontró Información
Soporte de sistemas de archivo de 32 bits




Soporte de sistemas de archivo de 64 bits
Si
No

No se encontró Información



Herramienta de actualización por defecto
Windows Update
Software Update
apt
pkgadd
Entorno gráfico
Basado en el kernel
Basado en el kernel
Aplicación: X Window System
Aplicación: X Window System
Sistema de ventanas por defecto
Standard Windows
Macintosh Finder
GNOME
CDE o GNOME


Estilo de Interfaz gráfica de usuario
Estilo Luna
Platinum
Metacity
dtwm con CDE, Metacity con GNOME


Estados de procesos
Ejecución
Suspendido
Parado
Zombie



New
Runnable
Blocked
dead
Administración de procesos
Colas de espera
Semáforos
Secciones críticas
Mutex
Semáforos
sucesos

Semáforos
Adaptative mutex

Administración de memoria
Memoria paginada segmentación
Intercambio
Memoria virtual
Api de memoria
Pila del sistema
Memoria virtual
Paginación
X demanda
Combinación de segmentos
paginados
Administración de archivos
Núcleo dedl sistema
Llamadas al sistema
No se encontró Información
No se encontró Información
Organización jerárquica
Sistema de direccionamiento de archivos
Llamadas al sistema

2.17. Desventajas de los SOD
Por muy maravillosos que nos puedan pareces los sistemas operativos distribuidos, también tienen sus desventajas. La sincronización del sistema es una tarea Árdea de la cual nunca se descansa y la estandarización del sistema es un tanto complicada y limitante. Debido a que no todos los sistemas operativos son de de carácter distribuido enlazar los distintos tipos de sistemas operativos es un poco complicado.

El interés de hacer el SOD lo más transparente posible lo hace muy complicado en su programación y el lograr que el sistema operativo no tenga problemas para que no cause problemas a otros equipos que le asignaron tareas es un poco dificultoso.

2.18. Java y las redes
A. SUN
Java es un entorno de computación introducido al público en 1995 por Sun Microsystems 3. Considerado como lenguaje de programación, es simplemente un lenguaje cuya sintaxis recuerda la del C++, y tiene, respecto a este, ventajas, que el marketing de la compañía trata de resaltar, e inconvenientes, que trata de ocultar, sin embargo, las librerías de clases y el que todos sus programas se ejecuten en una máquina virtual lo convierten en un lenguaje altamente portátil, muy apto para una red con ordenadores y sistemas operativos tan heterogéneos como Internet.

B. Máquinas Virtuales
El secreto de la portabilidad binaria de los programas Java reside en las máquinas virtuales. Los compiladores Java no generan binarios para una arquitectura real, sino para una inexistente máquina virtual Java, por lo que para usar los binarios, se necesita un emulador encargado de traducir instrucciones del programa a primitivas de la arquitectura anfitriona.


C. Popularidad
La popularidad actual del lenguaje Java es, en parte, fruto de una agresiva campaña de marketing por parte de Sun, además de pactos con la compañía que anteriormente era líder en la fabricación y distribución de navegadores de Internet, Netscape. En todo caso, hoy en día, Java es una plataforma muy popular y casi todos los ordenadores que se fabrican ahora mismo incluyen una máquina virtual capaz de ejecutar sus programas.

SISTEMAS DISTRIBUIDOS EN JAVA

A. RMI
RMI[4] fue el primer framework4 para crear sistemas distribuidos que apareció para Java. Además, viene integrado en cualquier máquina virtual Java posterior a la 1.0 y está pensado para hacer fácil la creación de sistemas distribuidos a partir de una aplicación cuyas clases ya estén implementadas.

B. CORBA: El estándar de sistemas distribuidos CORBA es el estándar para la creación de sistemas distribuidos creado por el Object Management Group (OMG). Pensado para ser independiente del lenguaje, rápidamente aparecieron implementaciones en las que
se podía usar casi cualquier lenguaje.

C. DCOM: La alternativa de Microsoft. Aunque objeto y componente[2] tienen significado distintos, el nombre utilizado en las tecnologías de Microsoft COM y DCOM, versión distribuida de COM es componente. COM/DCOM es un sistema de componentes implementado en todos los sistemas operativos que fabrica Microsoft. La tecnología para crear sistemas distribuidos proporcionada por Microsoft es una versión orientada a componentes del sistema RPC ya comentado. Si bien es verdad que se han hecho algunos esfuerzos para que DCOM aparezca en arquitecturas diferentes a la Win32 (llegando a acuerdos con el gigante del software alemán Software A.G.), no parece que dichos esfuerzos hayan proporcionado resultados visibles y hoy por hoy, DCOM es una tecnología que solo sirve para los sistemas Microsoft.

CORBA.

CORBA, Common Object Request Broker Architecture, es una tecnología para crear sistemas distribuidos, creada por un consorcio de fabricantes, agrupados bajo el OMG.
El estándar CORBA define qué ha de incluir una implementación estándar, pero no cómo se han de hacer. Esta tarea se deja de la mano de los diferentes fabricantes. Esta es una de las principales características de CORBA: permite una total libertad a los implementadores siempre que estos respeten unos mínimos orientados a la interoperabilidad entre implementaciones.

Ventajas

1) Disponibilidad y Versatilidad
Muchas arquitecturas y sistemas operativos cuentan con una implementación de CORBA, lo que hace suponer que se puede usar CORBA en virtualmente cualquier proyecto de sistemas distribuidos.

2) Eficiencia
La libertad de desarrollo ha favorecido la existencia de una pléyade de implementaciones del estándar que se adaptan a multitud de posibles necesidades de los usuarios, generando una competencia que favorece aquellas implementaciones de mayor calidad y con más características.

3) Adaptación a Lenguajes de programación
Además, es posible emplear los servicios de CORBA desde cualquier lenguaje de programación, desde C++, C ó Java, hasta COBOL ó Ada.

Inconvenientes

1) Complejidad
Permitir la interoperabilidad de distintos lenguajes, arquitecturas y sistemas operativos hace que sea un estándar bastante complejo, y su uso no sea tan transparente al programador como sería deseable:

1. Hay que usar un compilador que traduce una serie de tipos de datos estándares a los tipos del lenguaje en el que se vaya a programar (IDL)

2. Hay que ser conscientes a la hora de diseñar qué objetos van a ser remotos y cuáles no (los remotos sufren restricciones en cuanto a sus capacidades con respecto a un objeto normal)
3. Es necesario emplear tipos de datos que no son los que proporciona de manera habitual el lenguaje de programación (muchas veces hay que emplear tipos de datos adaptados de IDL).

2) Incompatibilidad entre implementaciones
Muchas empresas ofrecen implementaciones CORBA, si bien el grado de cumplimiento es diverso. Las divergencias entre ORBs radican en detalles que, aunque no hacen imposible aplicar en uno el mismo diseño de un programa pensado para otro, hacen que
la adaptación sea fastidiosa. Cuestiones como la colocación de librerías o las diferentes formas de implementar la gestión de la concurrencia, hacen difícil la portabilidad del código y obligan al programador a reciclarse cuando quiere cambiar de CORB. Además, donde el estándar no concreta, las implementaciones pueden variar entre sí, lo que da lugar a molestas incompatibilidades que complican la vida al usuario.

Los ORBs.

Los ORBs, Object Request Brokers, núcleo de cualquier implementación CORBA, transmiten los mensajes que se intercambian cliente y servidor, para lo que se ocupan de:
1. Canalizar las comunicaciones entre los objetos locales y los remotos.
2. Empaquetar los parámetros que el cliente pasa al método remoto y el resultado que el método devuelve al cliente.
3. Localizar al objeto remoto a partir de una referencia.

EL IDL.

IDL (Interface Definition Language) es un lenguaje de programación pensado exclusivamente para especificar los interfaces de las clases cuyas instancias queremos hacer públicas a objetos remotos que las usaran como clientes. La necesidad de un IDL viene dada por la independencia de CORBA respecto a la arquitectura y al lenguaje de programación. Distintos lenguajes soportan diferentes tipos de datos y tienen distintas formas de especificar clases. Incluso limitándonos a un lenguaje, la ordenación5 y el tamaño de un tipo de datos determinado no tiene porqué ser el mismo entre arquitecturas diferentes (por ejemplo, no es lo mismo un entero en un 386 con MS-DOS que en un UltraSparc con Solaris 7).
IDL pone de acuerdo a distintos lenguajes en el formato y tamaño de sus especificaciones. El compilador de IDL transforma una especificación neutral para la plataforma y el lenguaje en otra que puedan entender dicho lenguaje y plataforma.

El IIOP: Interoperabilidad entre ORB.

CORBA es neutral respecto al protocolo de red utilizado para comunicar cliente y servidor. Para ello especifica el GIOP (General Inter ORB Protocol) que define a muy alto nivel la comunicación entre ORBs diferentes. Para redes de tipo TCP/IP se emplea una instancia de GIOP conocida como IIOP (Internet Inter ORB Protocol). Gracias a IIOP, es posible que objetos que emplean ORBs de fabricantes distintos puedan interoperar en redes como Internet.

F. Gestión de la concurrencia.
El comportamiento de un objeto situado en un servidor cuando dos o más clientes quieren hacer uso de sus servicios viene determinado por la política de gestión de la concurrencia que se haya programado en el ORB. CORBA incluye varias políticas que definen cuándo y cómo activa el ORB los objetos en el servidor para atender peticiones.

Desgraciadamente, si se utiliza un mismo proceso para atender todas las peticiones que se hagan, o si se crea uno nuevo para atender cada una de las peticiones es algo de lo que se va a tener que ocupar el programador, aunque algunos ORBs pueden asistir al programador en esa tarea.

G. Servicio de nombrado.
En CORBA hay varias formas de que un objeto situado en una máquina pueda referirse a otro remoto.


1) IOR
Número de gran longitud, que permite identificar de manera única y global a un objeto que ofrece sus servicios en un entorno distribuido. Lo genera automáticamente el ORB de forma que no pueda haber dos objetos con el mismo identificador por muy grande que sea la red. Usa para ello datos aleatorios, y otros escogidos a partir del ordenador sobre el que se ejecuta, la implementación del ORB, etc.

2) Asignación de Nombres
Dándole previamente un nombre al objeto, otro que quiera usar sus servicios podría emplear una notación tipo URL como iiop:nombre_host:puerto/nombre_objeto6. Así, si en máquina.inf.uniovi.es, existe el objeto dns, cualquiera que quiera acceder a dns sólo tiene que solicitar a su ORB una referencia a iiop:máquina.inf.uniovi.es/dns.

Esta forma de nombrado es más fácil de recordar para la mayor parte de los seres humanos, aunque seremos nosotros los que tendremos que asegurarnos de su unicidad (aunque solo dentro de los límites de la máquina en la que se registre). Ambos sistemas de nombrado tienen el inconveniente de no ser transparentes en cuanto a la localización ya que, si movemos los objetos servidores, tendremos que adecuar a los objetos clientes para que los busquen en otro lado.


H. Servicios adicionales de CORBA.
Las implementaciones CORBA pueden ofrecer servicios adicionales voluntariamente (aunque no es necesario para ser certificado CORBA compliant por el OMG).
Un ejemplo de estas facilidades es el sistema de suscripción de eventos, que permite que un objeto se suscriba a eventos generados por otro. El propósito de este servicio es el de mejorar la eficiencia disminuyendo el tráfico de la red. Por ejemplo, si hay varios objetos clientes esperando a que suceda algo en el objeto que presta servicio en el servidor, en vez de hacer polling, podrían solicitarle a este que les envíe una notificación cuando eso ocurra.

I. Seguridad.
El estándar CORBA no se preocupa de la seguridad implementada en el sistema distribuido. Si por alguna razón se requiere restringir el uso de los recursos controlados por un determinado objeto, debe hacerlo el usuario. Algunas de estas librerías son nativas, en vez de emplear implementaciones 100% Java para soportar
Java, lo que puede dar algunos problemas de portabilidad o imposibilitar la ejecución de aplicaciones dentro de los navegadores con soporte para Java. Pero la integración Java-CORBA incluirá interesantes mejoras cuando OMG introduzca la nueva versión del estándar, CORBA 3.0. De hecho, parte de la mejora en esta integración es justo lo inverso de lo que había hasta ahora: una correspondencia java-idl. Al contrario que el compilador de IDL a Java, que convierte una especificación en formato neutral en clases que puede usar un compilador java, el traductor java-idl extraerá la interfaz de las clases java y las traducirá a una especificación IDL, por lo que será más fácil emplear clases java por programas que usen CORBA y que estén implementados en otros lenguajes.

K. Limitaciones e Inconvenientes CORBA.

1. El sistema no es transparente al programador. Las diferencias para el programador que quiera usar un determinado objeto con respecto a las de emplear uno local, se reducen a la inicialización del mismo. En vez de inicializarlo normalmente, hay que pedir al ORB (vía IOR o usando un nombre más inteligible), una referencia al objeto
remoto y luego convertirlo al tipo de objeto a manejar.

2. Los objetos remotos se pueden usar por referencia, pero no por valor. Así, cuando se haga uso de los métodos de un objeto remoto (al que se accede por referencia), solo se le pueden pasar como parámetros (y el método solo podrá devolver como resultado) tipos de datos contemplados en el IDL. Afortunadamente, este problema queda resuelto con CORBA 3, que sí soporta el paso de parámetros por valor.

3. Múltiples implementaciones de CORBA dan lugar a múltiples incompatibilidades. El estándar CORBA define a alto nivel qué funciones debe proporcionar un ORB y cómo han de interoperar estos entre sí, lo que garantiza cierto grado de compatibilidad, pero el cómo se ofrezca esa funcionalidad al programador es algo que está al
libre albedrío del fabricante del ORB. Es más, parte de la funcionalidad del estándar CORBA no es de obligado cumplimiento por parte de las compañías fabricantes para poder anunciarse como CORBA-compliant. En estas condiciones es muy difícil pensar que un programa que haya sido programado pensando en un ORB concreto, pueda funcionar bien con una simple recompilación.

4. El estándar CORBA está poco preparado para usarse en entornos embebidos (electrónica de consumo, asistentes digitales) o que requieran soporte de tiempo real. Para el primer caso, se diseñó en CORBA 3 un subconjunto llamado Minumum CORBA que, al ser más ligero, encaja mejor en los sistemas embebidos, donde el control del consumo de recursos es vital. Para solucionar el segundo problema, CORBA 3 introducirá Real -Time CORBA, que introducirá modelos de prioridad para conseguir un comportamiento predecible de los programas que lo usen.
RMI.

RMI (Remote Method Invocation) es parte de la librería de clases de Java que permite la creación de sistemas distribuidos en Java.

A. Características particulares de RMI.
Al contrario que otras tecnologías de sistemas distribuidos, RMI no busca la colaboración de objetos de distintas plataformas, programados en diferentes lenguajes, Java se encarga de solucionar los problemas de heterogeneidad. Así, su API es más sencillo y natural al no contemplar que tipos de datos (y sus tamaños) existan o no en los lenguajes en los que se implementan cliente y servidor.

B. Gestión de la concurrencia.
La gestión de la concurrencia en RMI, como muchas de las cosas que lo diferencian de CORBA es extraordinariamente sencilla e inflexible. Para cada cliente que trate de acceder a un objeto remoto, el servidor creará un nuevo hilo que se encargará de darle servicio. Si varios hilos del mismo cliente realizan distintas peticiones al servidor, compartirán un mismo hilo en el servidor.

C. Servicio de nombrado.
El nombrado de objetos es sencillo pero dependiente del ordenador donde resida el objeto servidor en cada instante. Aún así, está pensado de tal forma que difícilmente su uso creará problemas al usuario, ya que emplea la notación URL del tipo rmi:nombre_host:puerto/nombre_objeto. Un programa que acompaña a las implementaciones Java es el RMIRegistry. El registro rmi (rmiregistry) comunica objetos clientes con servidores. Conceptualmente, cuando un cliente quiere obtener una referencia a un objeto remoto, pregunta por él al rmiregistry donde resida dicho objeto. El registro lleva la cuenta de los objetos exportados7 que residen en esa máquina (ya que todos ellos han sido dados de alta en el registro por el programa que se haya encargado de crearlos e inicializarlos), por lo que comprueba que la solicitud del cliente puede ser atendida, y caso de ser así, devuelve la referencia esperada.

El RMIRegistry puede ser ejecutado como servicio de Windows NT o como demonio en UNIX (y similares).

D. Paso de parámetros por valor y serialización.
RMI soporta que objetos clientes puedan emplear objetos remotos por valor y por referencia. El uso de un objeto remoto por referencia no es nada nuevo, cualquier objeto exportado ante el RMIRegistry se pasa automáticamente por referencia a cualquier cliente que quiera usarlo. La novedad es el paso de objetos por valor, para lo
que se emplea la librería de serialización del API de Java. Para pasar un objeto por valor del servidor el cliente, debe implementar una clase abstracta que les obliga a definir cómo almacenar en un flujo de datos (como por ejemplo un fichero) los datos importantes del objeto serializable y cómo reconstruirlo a partir de esos mismos datos. Muchas de las clases del API de Java ya son serializables por lo que otras clases que las usen (por herencia o agregación) no tienen que ocuparse de serializarlas.

Cuando se necesita llevar un objeto serializable de una máquina a otra (porque sea un parámetro de un método de un objeto remoto que empleamos por referencia, o porque sea el resultado que devuelve dicho método al cliente), se serializa, se lleva el flujo de una máquina a la otra, y una vez en el ordenador huésped, se reconstruye y se usa.

La ventaja del paso por valor en un sistema distribuido radica en que se minimiza el tráfico en la red ya que, una vez recibido el objeto, todas las comunicaciones con él serán locales.


E. Seguridad.
Por defecto, RMI no incluye ninguna facilidad para restringir el uso de las clases desde clientes no autorizados, aunque el usuario siempre puede suplir parte de esta funcionalidad usando los servicios del sistema operativo, o haciendo ese trabajo él8 mismo. Aún así, no se puede confiar en la seguridad de un sistema solo porque se haya autentificado al usuario al inicio de la conexión si es que el canal de comunicación no es seguro. La plataforma Java 2 incluye el soporte de comunicaciones seguras en RMI usando el estándar SSL (Secure Sockets Layer).

INTEROPERABILIDAD DE TECNOLOGÍAS


Afortunadamente para los usuarios que necesitan crear un sistema distribuido, existen modos de poder utilizar un objeto cliente implementado según un estándar de sistemas distribuidos, desde otro diferente. Un ejemplo es la integración entre COM y
CORBA desarrollada por IONA Technologies. Asimismo, OMG y Sun están trabajando para hacer que CORBA y RMI sean interoperables de manera transparente al programador y al usuario. Además, la plataforma Java 2 viene con soporte de RMI y de CORBA9 simultáneamente. El rendimiento es menor, lo que se agrava especialmente si la comunicación entre dos objetos implementados en estándares distintos es intensa.

Además, la interoperabilidad suele suponer tener que conformarse con el mínimo común denominador de las facilidades que incorporen los sistemas originales.

CONCLUSIONES.

Para saber cuál de las tres tecnologías para crear sistemas distribuidos de las aquí descritas es la apropiada, no existe una respuesta clara.

En algunas ocasiones DCOM está especialmente pensado para poder utilizar componentes de Microsoft. Si en la aplicación se pretende acceder de manera remota a un componente de la suite Office97 o al Internet Explorer, o si se está utilizando como herramienta de programación Microsoft Visual J++, entonces COM/DCOM es posiblemente la única solución. El problema es que al ser DCOM una tecnología centrada casi en exclusiva en los sistemas win32, hay que prescindir de una de las grandes ventajas que permiten los sistemas distribuidos que es la interoperabilidad de entornos heterogéneos.

Por otra parte, si tanto cliente como servidor van a usar Java, se quiere una solución sencilla para crear un sistema distribuido y valen las opciones por defecto de los diseñadores de RMI, esta es la mejor elección. RMI es sin duda la opción más integrada en Java, la de uso más natural para un programador de Java y que además aporta un buen número de utilidades. Sin embargo su sencillez se puede transformar en inflexibilidad si se quieren hacer cosas que los creadores de RMI no contemplan.
Por último, si se quiere garantizar una casi absoluta capacidad de elección para cualquier parámetro del sistema distribuido o si no vale Java para ambos extremos de la comunicación, la solución es CORBA.

Escoger CORBA sería sólo la primera de las decisiones que habría que tomar para crear un sistema distribuido, la siguiente sería escoger qué implementación de CORBA escoger, para lo cual hay muchos factores que evaluar: soporte del lenguaje y plataforma que se quiere usar, precio, cumplimiento del estándar, servicios adicionales, velocidad o soporte son sólo algunas de las posibilidades. La elección de la implementación es algo que no se debe menospreciar porque una vez tomada una decisión es difícil cambiar. Esto es así puesto que aunque las diferentes implementaciones son interoperables, existen bastantes diferencias a la hora de programar como para que exista portabilidad binaria o de fuentes, incluso si ambas implementaciones soportan el mismo subconjunto o superconjunto de CORBA.

Por otro lado, CORBA es casi lo opuesto a RMI. Donde este aporta sencillez, CORBA aporta un cierto nivel de complejidad. El premio a este esfuerzo es un sistema es flexible y que se adapta a casi cualquier entorno de computación existente.