1.4 se centran en recursos compartidos los usuarios están tan acostumbrados a los beneficios de compartir recursos

que fácilmente puede pasar por alto su importancia. Solemos compartir recursos de hardware como impresoras, recursos tales como archivos, datos y recursos con más funcionalidades específicas, tales como los motores de búsqueda.

Mirado desde el punto de vista de la disposición de hardware, compartimos equipos tales como impresoras y discos para reducir costes. Pero de mayor importancia para los usuarios es el uso compartido de los recursos de nivel superior que desempeñan un papel en sus aplicaciones y en su labor diaria y actividades sociales. Por ejemplo, los usuarios están interesados en compartir los datos en la forma de una base de datos compartida o un conjunto de páginas web - no los discos y procesadores en los que se implementan. Igualmente, los usuarios piensan en términos de recursos compartidos, como un motor de búsqueda o un conversor de divisas, sin tener en cuenta el servidor o los servidores que proporcionan estos.

En la práctica, los patrones de intercambio de recursos varían ampliamente en su alcance y en cómo los usuarios trabajan estrechamente juntos. En un extremo, un motor de búsqueda en la Web ofrece un servicio para los usuarios de todo el mundo, los usuarios que necesitan nunca entran en contacto el uno con el otro directamente. En el otro extremo, apoyado por ordenador de trabajo cooperativo (CSCW), un grupo de usuarios que colaboran directamente compartir recursos como documentos, en un pequeño grupo cerrado. El modelo de reparto y la distribución geográfica de los usuarios particulares determina qué mecanismos el sistema deberá suministrar a coordinar las acciones de los usuarios.

Utilizamos el término servicio para una parte diferenciada de un sistema informático que gestiona una colección de recursos relacionados y presenta su funcionalidad para los usuarios y las aplicaciones. Por ejemplo, tenemos acceso a los archivos compartidos a través de un servicio de archivos; enviamos documentos a impresoras a través de un servicio de impresión; compramos mercancías mediante un servicio de pago electrónico. El único acceso que tenemos al servicio es a través del conjunto de operaciones que exporta. Por ejemplo, un servicio de archivos proporciona a leer, escribir y eliminar operaciones sobre archivos.

El hecho de que limitar el acceso a los recursos a los servicios de un conjunto bien definido de operaciones es en parte la práctica de ingeniería de software estándar. Pero también refleja la organización física de los sistemas distribuidos. Los recursos en un sistema distribuido físicamente están encapsulados en equipos y sólo se puede acceder desde otras computadoras por medio de la comunicación. Para intercambio efectivo, cada recurso debe ser

gestionado por un programa que ofrece una interfaz de comunicación permitiendo que el recurso al que se accede y actualiza de forma confiable y coherente.

El término servidor es probablemente conocida por la mayoría de los lectores. Se refiere a un programa en ejecución (un proceso) en un ordenador conectado a la red que acepta solicitudes de los programas que se ejecutan en otros equipos para realizar un servicio y responde apropiadamente. El Estado requirente procesos son contemplados como clientes, y, en general, el enfoque es conocido como computación cliente-servidor. En este enfoque, las solicitudes se envían en mensajes de clientes a un servidor y las respuestas se envían mensajes desde el servidor a los clientes. Cuando el cliente envía una solicitud de una operación que se lleva a cabo, podemos decir que el cliente llama a una operación en el servidor. Una completa interacción entre un cliente y un servidor, desde el momento en que el cliente envía su solicitud a cuando recibe la respuesta del servidor, se llama una invocación remota.

El mismo proceso puede ser tanto un cliente y un servidor, desde servidores a veces invocan operaciones en otros servidores. Los términos 'cliente' y 'servidor' sólo se aplican al papel desempeñado en una sola solicitud. Clientes activos (haciendo peticiones) y servidores son pasivos (sólo despertarse cuando reciben peticiones); los servidores ejecutan continuamente, mientras que los clientes sólo duran tanto tiempo como las aplicaciones de las que forman parte.

Tenga en cuenta que, aunque de forma predeterminada los términos 'cliente' y 'servidor' se refieren a los procesos más que en los ordenadores que ejecutan, en lenguaje cotidiano esos términos se refieren también a los propios ordenadores. Otra distinción, que discutiremos en el Capítulo 5, es que, en un sistema distribuido, escrito en un lenguaje orientado a objetos, los recursos pueden ser encapsulados como objetos y visitada por objetos de cliente, en cuyo caso hablamos de un objeto cliente invoca un método en un objeto del servidor.

Muchos, pero no todos, los sistemas distribuidos pueden ser construidos enteramente en la forma de interacción de clientes y servidores. La World Wide Web, el correo electrónico y las impresoras de red se adaptan a este modelo. Discutimos alternativas para sistemas cliente-servidor en el Capítulo 2.

Ejecutar un navegador de web es un ejemplo de un cliente. El navegador web se comunica con un servidor web, a petición de las páginas web. Consideramos que la Web y sus asociados arquitectura cliente-servidor en más detalle en la sección 1.6.

1.5 Desafíos

En los ejemplos de la sección 1.2 están destinados a ilustrar el alcance de los sistemas distribuidos y sugerir las cuestiones que se plantean en su diseño. En muchos de ellos se encontraron importantes desafíos y superar. Como el alcance y la escala de sistemas distribuidos y aplicaciones se extiende la misma y otros desafíos son probablemente para ser encontrado. En esta sección se describen los principales retos.

1.5.1 la heterogeneidad

la Internet permite a los usuarios acceder a los servicios y ejecutar las aplicaciones en una colección heterogénea de ordenadores y redes. La heterogeneidad (es decir, la variedad y la diferencia) se aplica a todos los siguientes:

Redes; el hardware del equipo; Sistemas operativos; Lenguajes de programación; implementaciones por diferentes desarrolladores.

Aunque la Internet se compone de muchos tipos diferentes de red (ilustrado en la figura 1.3), sus diferencias son enmascaradas por el hecho de que todos los equipos conectados a ellos utilizan los protocolos de Internet para comunicarse el uno con el otro. Por ejemplo, un equipo conectado a una red Ethernet con una implementación de los protocolos de Internet a través de la Ethernet, mientras que un equipo en un tipo diferente de red necesitará una implementación de los protocolos de Internet para esa red. El capítulo 3 explica cómo se implementan los protocolos de Internet a través de una variedad de diferentes redes.

Tipos de datos como números enteros pueden ser representados en diferentes formas en diferentes clases de hardware - por ejemplo, hay dos alternativas para el ordenamiento de bytes de enteros. Esta diferencia de representación debe tratarse si los mensajes se intercambian entre los programas que se ejecutan en un hardware diferente.

Aunque los sistemas operativos de todos los equipos de Internet deben incluir una implementación de los protocolos de Internet, no necesariamente todos ofrecen la misma interfaz de programación de aplicaciones para estos protocolos. Por ejemplo, las llamadas para intercambiar mensajes en UNIX son diferentes de las llamadas en Windows.

Diferentes lenguajes de programación utilizan distintas representaciones de caracteres y estructuras de datos como matrices y registros. Estas diferencias deben ser abordadas si programas escritos en diferentes idiomas para poder comunicarse uno con el otro. El programa escrito por desarrolladores diferentes no

se puede comunicar con uno a no ser que otro utilice normas comunes, por ejemplo, para la comunicación de red y la representación de los elementos de datos primitivos y estructuras de datos en los mensajes. Para que esto suceda, las normas deben ser acordadas y aprobadas, así como los protocolos de Internet.

Middleware

el término middleware se aplica a una capa de software que proporciona una abstracción de programación, así como enmascarar la heterogeneidad de las redes subyacentes, hardware, sistemas operativos y lenguajes de programación. La Common Object Request Broker (CORBA), que se describe en los capítulos 4, 5 y 8, es un ejemplo. Algunos, como middleware Java RMI (Remote Method Invocation) (véase el capítulo 5), sólo admite un único lenguaje de programación. La mayoría de middleware es implementada a través de los protocolos de Internet, que encubren las diferencias de las redes subyacentes, pero todas las ofertas de middleware con las diferencias de los sistemas operativos y hardware - cómo se hace esto es el tema principal del capítulo 4.

Además de resolver los problemas de heterogeneidad, el middleware proporciona un modelo computacional uniforme para su uso por parte de los programadores de servidores y aplicaciones distribuidas. Posibles modelos incluyen un objeto remoto de invocación remota, notificación de eventos, acceso SQL remoto y procesamiento de transacciones distribuidas. Por ejemplo, CORBA proporciona acceso remoto a la invocación de objetos, que permite que un objeto en un programa que se ejecuta en un equipo para invocar un método de un objeto en un programa que se ejecuta en otro equipo. Su aplicación se esconde el hecho de que los mensajes se transmiten a través de una red para enviar la solicitud de invocación y su respuesta.

La heterogeneidad y el código móvil

El término código móvil se utiliza para referirse al código del programa que pueden transferirse de un equipo a otro y se ejecute en el destino - los applets de Java son un ejemplo. Idóneo para ejecutar código en un ordenador no es necesariamente adecuado para su ejecución en otro porque los programas ejecutables normalmente son específicos tanto para el conjunto de instrucciones y el sistema operativo del host.

El enfoque de máquina virtual proporciona una manera de hacer que el código ejecutable en una variedad de equipos host: el compilador de un lenguaje en particular genera código para una máquina virtual en lugar de un código de pedido de hardware en particular. Por ejemplo, el compilador de Java genera código para una máquina virtual de Java, que se ejecuta por la interpretación. La

máquina virtual de Java debe llevarse a cabo una vez para cada tipo de equipo para habilitar la ejecución de programas Java.

Hoy, la forma más comúnmente utilizada de código móvil es la inclusión de programas de JavaScript en algunas páginas web cargan en los exploradores de los clientes. Esta extensión de la tecnología de la Web se analiza con más detalle en la sección 1.6.

1.5.2 Apertura

La apertura de un sistema informático es la característica que determina si el sistema puede ampliarse y re-implementarse de diversas maneras. La apertura de los sistemas distribuidos es determinada principalmente por el grado en que la nueva repartición de recursos se pueden agregar servicios y estar disponible para su uso por parte de una variedad de programas de cliente.

Apertura, no puede lograrse a menos que las especificaciones y la documentación de las interfaces de software clave de los componentes de un sistema estén disponibles para los desarrolladores de software. En una palabra, las interfaces clave son publicados. Este proceso es parecido a la estandarización de las interfaces, pero a menudo elude los procedimientos de normalización oficial, que normalmente son engorrosos y lentos.

Sin embargo, la publicación de interfaces es sólo el punto de partida para añadir y ampliar los servicios en un sistema distribuido. El desafío para los diseñadores es hacer frente a la complejidad de los sistemas distribuidos que consta de muchos componentes diseñados por diferentes personas.

El diseñador de los protocolos de Internet presenta una serie de documentos llamados "Solicitudes de comentarios", o RFC, cada uno de los cuales es conocido por un número. Las especificaciones de los protocolos de comunicación de Internet fueron publicadas en esta serie a principios de la década de 1980, seguidos por las especificaciones para aplicaciones que se ejecutan en ellos, tales como transferencia de archivos, correo electrónico y telnet a mediados del decenio de 1980. Esta práctica ha continuado y constituye la base de la documentación técnica de la Internet. Esta serie incluye debates, así como las especificaciones de los protocolos. Se pueden obtener copias de [www.ietf.org].Así, la publicación de los protocolos de comunicación de Internet original ha permitido una variedad de sistemas y aplicaciones de Internet, incluida la Web para ser construido. Rfc no son el único medio de publicación. Por ejemplo, el World Wide Web Consortium (W3C) desarrolla y publica normas relacionadas con el funcionamiento de la Web [www.w3.org].

Los sistemas que están diseñados para apoyar a compartir recursos de esta manera se denominan sistemas distribuidos abiertos para enfatizar el hecho de

que son extensibles. Pueden ampliarse a nivel del hardware mediante la adición de equipos a la red y en el nivel de software mediante la introducción de nuevos servicios y la re-implementación de los antiguos, lo que permite a los programas de aplicación para compartir recursos. Un beneficio adicional que a menudo se cita el caso de los sistemas abiertos es su independencia de proveedores individuales.

Para resumir: Los sistemas abiertos se caracterizan por el hecho de que sus interfaces

clave son publicados.

Abra los sistemas distribuidos se basa en la prestación de un mecanismo uniforme para la comunicación e interfaces publicadas para el acceso a los recursos compartidos.

Abrir sistemas distribuidos puede construirse de hardware y software heterogéneos, posiblemente de diferentes proveedores. Pero la conformidad de cada componente para el estándar publicado debe ser cuidadosamente probado y verificado si el sistema está funcionando correctamente.

1.5.3 La seguridad

Muchos de los recursos de información que están disponibles y se mantienen en sistemas distribuidos tienen un alto valor intrínseco a sus usuarios. Su seguridad es por lo tanto de gran importancia. La seguridad de los recursos de información tiene tres componentes: confidencialidad (protección contra la revelación a personas no autorizadas), integridad (protección contra la alteración o corrupción) y la disponibilidad (protección contra la interferencia con los medios para tener acceso a los recursos).

Sección 1.1 señaló que, aunque la Internet permite a un programa en un equipo para comunicarse con un programa en otro ordenador, independientemente de su ubicación, los riesgos de seguridad asociados a permitir el libre acceso a todos los recursos en una intranet. Aunque un firewall puede usarse para formar una barrera alrededor de una intranet, restringiendo el tráfico que puede entrar y salir, esto no se trata de garantizar el uso apropiado de los recursos por parte de los usuarios dentro de una intranet, o con el uso adecuado de recursos en Internet, que no están protegidos por firewalls.

En un sistema distribuido, los clientes envían peticiones para acceder a los datos gestionados por servidores, lo que implica el envío de información en mensajes a través de una red. Por ejemplo:

1. Un médico puede solicitar el acceso a los datos del paciente en el hospital o enviar las adiciones a los datos. En el comercio electrónico y la banca, los usuarios envían sus números de tarjeta de crédito.

2. a través de la Internet.

En ambos ejemplos, el reto consiste en enviar información sensible en un mensaje a través de una red de forma segura. Pero la seguridad no es sólo una cuestión de ocultar el contenido de mensajes - también implica conocer con certeza la identidad del usuario o de otro agente en cuyo nombre se ha enviado el mensaje. En el primer ejemplo, el servidor necesita saber que el usuario es realmente un médico, y en el segundo ejemplo, el usuario debe estar seguro de la identidad de la tienda o banco que tratan. El segundo reto es identificar a un usuario remoto u otro agente correctamente. Ambos de estos retos pueden satisfacerse mediante la utilización de técnicas de codificación desarrollado para este propósito. Se utilizan ampliamente en la Internet y se discuten en el Capítulo 11.

Sin embargo, los siguientes dos retos de seguridad aún no se han cumplido plenamente:

ataques de denegación de servicio: Otro problema de seguridad es que un usuario podría querer interrumpir un servicio por alguna razón. Esto puede lograrse mediante el bombardeo el servicio con un número tan elevado de solicitudes inútiles que los usuarios graves pueden hacer uso de ella. Esto se llama un ataque de denegación de servicio. Se han producido varios ataques de denegación de servicio en el bien conocidas de los servicios web. En la actualidad dichos ataques son contrarrestadas por intentar capturar y castigar a los autores después del evento, pero que no es una solución general para el problema. Contramedidas basadas en mejoras en la gestión de redes están en desarrollo, y estas serán tratadas en el Capítulo 3.

La seguridad del código móvil: Móvil de código debe manipularse con cuidado. Considerar a alguien que recibe un programa ejecutable como un archivo adjunto de correo electrónico: los posibles efectos de la ejecución del programa son impredecibles; por ejemplo, puede parecer para mostrar una imagen muy interesante, pero en realidad pueden acceder a recursos locales o, tal vez, ser parte de un ataque de denegación de servicio. Algunas medidas para proteger el código móvil se describen en el Capítulo 11.

1.5.4 Escalabilidad

sistemas distribuidos funcionen eficaz y eficientemente a muchas escalas diferentes, que van desde una pequeña intranet a Internet. Es descrito como un sistema escalable si seguirá siendo eficaz cuando hay un aumento significativo en el número de recursos y el número de usuarios. El número de ordenadores y servidores en Internet ha aumentado dramáticamente. La figura 1.6 muestra el número cada vez mayor de ordenadores y servidores web durante los 12 años de

historia de la Web hasta 2005 [zakon.org]. Es interesante observar el crecimiento significativo en ambos ordenadores y servidores web en este período, sino también que los porcentajes relativos es achatamiento - una tendencia que se explica por el crecimiento de la informática personal fijo y móvil. Un servidor web puede ser también cada vez más alojadas en varios equipos.

El diseño de sistemas distribuidos escalables presenta los siguientes retos:

controlar el coste de los recursos físicos: Como la demanda de un recurso crece, debería ser posible extender el sistema a un costo razonable, a reunirse con ella. Por ejemplo, la frecuencia con la que se obtiene acceso a los archivos en una intranet es probable que aumente el número de usuarios y equipos aumenta. Debe ser posible agregar equipos servidor para evitar los cuellos de botella que se produciría si un solo servidor de archivos tenía para gestionar todas las solicitudes de acceso de archivo. En general, para un sistema con n usuarios para ser escalable, la cantidad de recursos físicos necesarios para darles apoyo debería ser en la mayoría de O(n), es decir, proporcional a n. Por ejemplo, si un único servidor de archivos puede admitir 20 usuarios y, a continuación, dos de estos servidores deben ser capaces de admitir 40 usuarios. A pesar de que suena un objetivo evidente, no es necesariamente fácil de lograr en la práctica, como veremos en el Capítulo 12.

Controlar la pérdida de rendimiento: Estudiar la gestión de un conjunto de datos cuyo tamaño es proporcional al número de usuarios o recursos del sistema - por ejemplo, la tabla con la correspondencia entre los nombres de dominio de los ordenadores y sus direcciones de Internet mantenida por el Sistema de nombres de dominio, que se usa principalmente para buscar nombres DNS como www.amazon.com. Los algoritmos que utilizan estructuras jerárquicas escalan mejor que aquellos que usan estructuras lineales. Pero incluso con estructuras jerárquicas un aumento en el tamaño resultará en una pérdida en rendimiento: el tiempo de acceso a datos estructurados jerárquicamente es O(log n), donde n es el tamaño del conjunto de datos. Para que un sistema sea escalable, la máxima pérdida de rendimiento no debería ser peor que esto.

Prevención agotando recursos de software: Un ejemplo de la falta de escalabilidad es demostrado por los números utilizados como direcciones de Internet (IP) del equipo (direcciones en Internet). A finales de la década de 1970, se decidió utilizar 32 bits para este propósito, pero como se explica en el Capítulo 3, la oferta de direcciones de Internet se está acabando. Por esta razón, una nueva versión del protocolo con cifrado de 128 bits de direcciones de Internet está siendo adoptado, y esto requerirá modificaciones en muchos componentes de software. Para ser justos, la a principios de los diseñadores de la Internet, no hay una solución correcta a este problema. Es difícil predecir la demanda que se pondrá en un sistema años venideros. Además, la sobrecompensación de crecimiento futuro

puede ser peor que la adaptación a un cambio cuando estamos obligados a - direcciones de Internet más grandes se ocupan espacio extra en los mensajes y en el equipo de almacenamiento.

Figura 1.6 Crecimiento de Internet (ordenadores y servidores web)

Fecha equipos servidores Web

Porcentaje

1993, julio 1,776,000 130 0.0081995, Julio 6,642,000 23.500 0.41997, Julio 19,540,000 1,203,096 61999, Julio 56,218,000 6,598,697 122001, Julio 125,888,19

731,299,592, 25

2003, Julio ~200,000,000

42,298,371 21

2005, Julio 353,284,187

67,571,581 19

Evitar los cuellos de botella del rendimiento: En general, los algoritmos deben descentralizarse para evitar los cuellos de botella en el rendimiento. Podemos ilustrar este punto con referencia al predecesor del Sistema de nombres de dominio, en el cual los nombres de tabla se guardan en un solo archivo maestro que podría ser descargado a todos los equipos que lo necesiten. Eso estaba bien cuando sólo había unos pocos cientos de computadoras en la Internet, pero pronto se convirtió en un grave obstáculo administrativo y rendimiento. El Sistema de nombres de dominio eliminado este obstáculo mediante la partición de la tabla de nombres entre servidores ubicados en todo el Internet y administrado localmente, consulte los capítulos 3 y 13.

Algún recurso compartido se accede con mucha frecuencia; por ejemplo, muchos usuarios pueden acceder a la misma página web, provocando una disminución en el rendimiento. Veremos en el capítulo 2 que el almacenamiento en caché y la replicación puede ser utilizada para mejorar el rendimiento de los recursos que son muy utilizados.

Idealmente, el sistema y el software de la aplicación no debe cambiar cuando la escala del sistema aumenta, pero esto es difícil de lograr. La cuestión de la escala es un tema dominante en el desarrollo de sistemas distribuidos. Las técnicas que han tenido éxito se analizan ampliamente en este libro. Entre ellos se incluyen el uso de datos replicados (capítulo 18), la técnica asociada de caché (Capítulos 2 y 12) y el despliegue de varios servidores para manejar las tareas

realizadas con más frecuencia, permitiendo varias tareas similares a realizarse simultáneamente.

1.5.5 Tratamiento de fallos

los sistemas informáticos a veces fallan. Cuando se producen averías en el hardware o en el software, los programas pueden producir resultados incorrectos o puede detenerse antes de que se haya completado el cálculo. Vamos a analizar y clasificar una gama de posibles tipos de error que pueden producirse en los procesos y redes que conforman un sistema distribuido en el Capítulo 2.

Los fallos en un sistema distribuido son parciales, es decir, algunos componentes fallan, mientras que otros continúan funcionando. Por lo tanto, el manejo de errores es especialmente difícil. Las siguientes técnicas para hacer frente a fallos son discutidos a lo largo de todo el libro:

Detección de errores: Algunos errores pueden ser detectados. Por ejemplo, la suma de comprobación se puede utilizar para detectar datos dañados en un mensaje o un archivo. El capítulo 2 explica que es difícil o incluso imposible de detectar algunos otros errores, como un remoto se estrelló en el servidor de Internet. El reto es gestionar en presencia de fallos que no se pueden detectar, pero pueden ser sospechosos.

Enmascaramiento de Errores: Algunos errores que se han detectado pueden estar ocultos o hacerse menos grave. Dos ejemplos de ocultar los errores:

1. Los mensajes pueden ser retransmitidas cuando fracasan en llegar.2. Datos de archivo pueden ser escritos para un par de discos de forma que, si

uno está dañado, el otro puede ser correcta.

simplemente colocando un mensaje que está dañado es un ejemplo de cómo hacer menos severa: un fallo podría ser retransmitido. Los lectores probablemente se dan cuenta de que la técnica descrita para ocultar los errores no se garantiza que funcione en el peor de los casos; por ejemplo, el dato del segundo disco puede estar dañado demasiado, o que el mensaje no puede llegar en un tiempo razonable sin embargo a menudo es retransmitido.

Tolerar los errores: la mayoría de los servicios en la Internet, mostrar los fracasos- no sería práctico para ellos para intentar detectar y ocultar todas las fallas que pudieran producirse en una red tan amplia, con tantos componentes. Sus clientes pueden ser diseñados para tolerar fallos, lo que generalmente implica que los usuarios tolerarlos. Por ejemplo, cuando un navegador web no puede ponerse en contacto con un servidor web, no hacer esperar al usuario para siempre mientras se sigue tratando - informa al usuario acerca del problema, dejándolos libres para

intentarlo más tarde. Servicios que tolerar fallos son discutidas en el párrafo sobre la redundancia a continuación.

Recuperación de errores: Recuperación involucra el diseño de software para que los estados permanentes de los datos pueden ser recuperados o "revertir" tras un servidor ha fallado. En general, el cálculo realizado por algunos programas será incompleta cuando se produce un fallo, y la permanente actualización de los datos que ellos (los archivos y el material almacenado en el almacenamiento permanente) no puede estar en un estado coherente. La recuperación es descrita en el Capítulo 17.

Redundancia: Los servicios pueden ser hechas para tolerar fallos mediante el uso de componentes redundantes. Considere los siguientes ejemplos:

1. Siempre debe haber al menos dos rutas diferentes entre dos routers en Internet.

2. En el Sistema de nombres de dominio, cada nombre tabla está replicada en al menos dos servidores diferentes.

3. Una base de datos podrá ser replicado en varios servidores para asegurar que los datos permanecen accesibles tras el fracaso de un solo servidor; los servidores pueden ser diseñados para detectar fallos de sus compañeros; cuando se detecta un fallo en un servidor, los clientes son redirigidos a los servidores restantes.

El diseño de técnicas eficaces para mantener réplicas de datos que cambian rápidamente al día sin excesiva pérdida de rendimiento es un reto. Métodos se analizan en el Capítulo 18.

Sistemas distribuidos proporcionan un alto grado de disponibilidad en el rostro de los fallos de hardware. La disponibilidad de un sistema es una medida de la proporción de tiempo que está disponible para el uso. Cuando uno de los componentes de un sistema distribuido falla, sólo el trabajo que estaba utilizando el componente averiado se ve afectada. Un usuario puede mover a otro equipo si uno de los que estaban usando la falla; un proceso de servidor se puede ejecutar en otro ordenador.

1.5.6 la simultaneidadambos servicios y aplicaciones proporcionan recursos que pueden ser

compartidos por los clientes en un sistema distribuido. Por lo tanto, hay una posibilidad de que varios clientes intentarán acceder a un recurso compartido al mismo tiempo. Por ejemplo, una estructura de datos que registra las ofertas para una subasta puede ser visitada con mucha frecuencia cuando nos acerquemos a la hora límite. El proceso que gestiona un recurso compartido puede tener una solicitud del cliente en un momento.Pero este enfoque limita el rendimiento. Por lo tanto, servicios y aplicaciones suele permitir varias solicitudes de cliente para ser

procesadas de manera simultánea. Para concretar más, suponga que cada recurso se encapsula como un objeto y que invocaciones son ejecutados en subprocesos simultáneos. En este caso, es posible que varios subprocesos pueden ejecutarse simultáneamente dentro de un objeto, en cuyo caso sus operaciones sobre el objeto puede entrar en conflicto con otros y producir resultados inconsistentes. Por ejemplo, si dos ofertas simultáneas en una subasta son 'Smith: $122' y 'Jones: $111', y las operaciones correspondientes se intercalan sin control alguno, entonces pueden quedar almacenados como 'Smith: $111' y 'Jones:$122".

La moraleja de esta historia es que cualquier objeto que representa un recurso compartido en un sistema distribuido debe ser responsable de asegurar que funcione correctamente en un entorno concurrente. Esto se aplica no sólo a los servidores, sino también a los objetos de las aplicaciones. Por lo tanto, cualquier programador que tiene una implementación de un objeto que no fue diseñado para su uso en un sistema distribuido debe hacer lo que sea necesario para hacerla segura en un entorno concurrente.

Para que un objeto sea seguro en un entorno concurrente, sus operaciones deberán estar sincronizados, de tal manera que su dato se mantiene constante. Esto puede lograrse mediante técnicas estándar como semáforos, que se utilizan en la mayoría de los sistemas operativos. Este tema y su extensión a las colecciones de objetos compartidos distribuidos se discuten en los capítulos 7 y 17.

1.5.7 La Transparencia

transparencia se define como la ocultación del usuario y el programador de la aplicación de la separación de los componentes de un sistema distribuido, de manera que el sistema es percibido como un todo en lugar de como una colección de componentes independientes. Las consecuencias de la transparencia son una gran influencia en el diseño del software del sistema.El Manual de referencia ANSA ANSA [1989] y la Organización Internacional para la estandarización en modelo de referencia para el procesamiento distribuido abierto (RM-ODP) [ISO 1992] identificar ocho formas de transparencia. Hemos parafraseado el original ANSA definiciones, reemplazando su migración transparencia con nuestra propia movilidad transparencia, cuyo alcance es más amplio:

la transparencia permite el acceso a recursos locales y remotos que se acceden mediante operaciones idénticas.

Transparencia de ubicación permite que los recursos sean accesibles sin el conocimiento de sus características físicas o ubicación de red (por ejemplo, construcción o dirección IP).

La transparencia permite la simultaneidad de varios procesos para operar simultáneamente utilizando recursos compartidos sin interferencias entre ellos.

Replicación de Sistemas Distribuidos La transparencia permite que múltiples instancias de recursos que se utiliza para aumentar la fiabilidad y el rendimiento sin conocimiento de las réplicas por parte de usuarios o programadores de aplicaciones.

Falta transparencia permite la ocultación de los fallos, permitiendo a los usuarios y a los programas de aplicación para completar sus tareas a pesar de la falla de componentes de hardware o software.

Transparencia La movilidad permite la circulación de recursos y clientes, dentro de un sistema sin afectar el funcionamiento de los usuarios o programas.

Rendimiento transparencia permite que el sistema sea reconfigurado para mejorar el rendimiento, como las cargas varían.

La transparencia permite escalar el sistema y aplicaciones para ampliar su escala sin cambiar la estructura del sistema o la aplicación de algoritmos.

Los dos más importantes son el acceso y ubicación de transparencias Transparencia; su presencia o ausencia afecta más fuertemente la utilización de los recursos distribuidos. A veces se refieren a ellas en conjunto como transparencia de red. Como un ejemplo de transparencia de acceso, considere la posibilidad de una interfaz gráfica de usuario con carpetas, que es el mismo independientemente de si los archivos dentro de la carpeta local o remota. Y otro ejemplo es una API para archivos que utiliza las mismas operaciones para acceder a archivos locales y remotos (véase el capítulo 12). Como un ejemplo de falta de transparencia, acceso a considerar un sistema distribuido que no permiten el acceso a los archivos en un ordenador remoto a menos que usted haga uso del programa ftp para hacerlo.

Recursos Web nombres o direcciones URL de ubicación son transparentes porque la parte de la dirección URL que identifica un servidor web de dominio se refiere al nombre de un equipo en un dominio, en lugar de una dirección de Internet. Sin embargo, las url no son transparentes, la movilidad de una persona porque su página web personal no puede pasar a su nuevo lugar de trabajo en un

dominio diferente - todos los enlaces en otras páginas se siguen apuntando a la página original.

En general, los identificadores tales como direcciones URL que incluyan los nombres de dominio de equipos evitan la replicación de transparencia. Aunque el DNS permite que un nombre de dominio para referirse a varios equipos, elige sólo uno de ellos cuando se busca un nombre. Desde un plan general de replicación debe ser capaz de tener acceso a todos los equipos participantes, tendría que tener acceso a cada una de las entradas de DNS por el nombre.

Como una ilustración de la presencia de la transparencia de la red, considere el uso de una dirección de correo electrónico como Fred.Flintstone@stoneit.com. La dirección se compone de un nombre de usuario y un nombre de dominio. Enviar correo a un usuario no implica conocer sus características físicas o una ubicación de red. Tampoco los procedimientos para enviar un mensaje de correo electrónico dependen de la ubicación del destinatario. Por lo tanto, el correo electrónico dentro de la Internet proporciona transparencia Ubicación y acceso (es decir, transparencia de red).

Falta transparencia también puede ilustrarse en el contexto del correo electrónico, lo que finalmente se entrega, aun cuando los servidores o enlaces de comunicación fallan. Los fallos están enmascarados por intentar retransmitir los mensajes hasta que se ha entregado correctamente, incluso si se toma varios días. Generalmente Middleware convierte las fallas de las redes y de los procesos a nivel de programación excepciones (véase el capítulo 5 para una explicación).

Para ilustrar la movilidad transparencia, consideremos el caso de los teléfonos móviles. Supongamos que ambos Llamador y destinatario están viajando en tren en diferentes partes del país, mover la desde un entorno (celular) a otro. Consideramos que la llamada de teléfono como el cliente y el teléfono del destinatario como un recurso. Los dos usuarios de teléfono que realiza la llamada no son conscientes de la movilidad de los teléfonos (el cliente y los recursos) entre las células.

Transparencia oculta y anónima hace los recursos que no sean de relevancia directa a la tarea para los usuarios y programadores de aplicaciones. Por ejemplo, generalmente es deseable para recursos de hardware similar a ser asignadas indistintamente para realizar una tarea: la identidad de un procesador que se utiliza para ejecutar un proceso generalmente se oculta al usuario y permanece anónima. Como se señaló en la sección 1.3.2, esto puede no ser siempre lo que se necesita: por ejemplo, un viajero que conecta un ordenador portátil a la red local en cada oficina visitado debe hacer uso de los servicios locales, como el servicio de correo de envío, utilizando diferentes servidores en cada ubicación. Incluso

dentro de un edificio, es normal para organizar un documento para ser impreso en una impresora especial, llamado: generalmente, uno que está cerca del usuario.1.5.8 Calidad de servicio

una vez que se proporciona a los usuarios la funcionalidad que requieren de un servicio, como el servicio de archivos en un sistema distribuido, podemos ir a preguntar acerca de la calidad del servicio prestado. Las principales propiedades funcionales de los sistemas que afectan a la calidad del servicio experimentado por los clientes y usuarios son la fiabilidad, seguridad y rendimiento.Adaptabilidad para satisfacer las cambiantes configuraciones del sistema y la disponibilidad de recursos ha sido reconocida como un importante aspecto de la calidad del servicio.

Problemas de fiabilidad y seguridad son fundamentales en el diseño de la mayoría de los sistemas informáticos. El aspecto de rendimiento de la calidad del servicio fue originalmente definido en términos de capacidad de respuesta y rendimiento de cómputo, pero se ha redefinido en términos de capacidad para cumplir con puntualidad garantiza, como se expone en los párrafos siguientes.

Algunas aplicaciones, incluyendo aplicaciones multimedia, gestionar datos de tiempo crítico - flujos de datos que son necesarios para ser procesados o transferirse desde un proceso a otro a una tasa fija. Por ejemplo, un servicio de película podría consistir en un programa cliente que está recuperando una película desde un servidor de vídeo y presentarlo en la pantalla del usuario. Para un resultado satisfactorio de los sucesivos fotogramas de vídeo deben mostrarse al usuario dentro de unos plazos determinados.

De hecho, la abreviatura QoS ha sido efectivamente expropiados para referirse a la capacidad de los sistemas para cumplir esos plazos. Su logro depende de la disponibilidad de los recursos informáticos y de red necesaria en el momento adecuado. Esto implica un requisito para que el sistema proporcione garantizados recursos informáticos y de comunicaciones que sean suficientes para permitir a las aplicaciones para completar cada tarea en el tiempo (por ejemplo, la tarea de mostrar un fotograma de vídeo).

Las redes se utilizan hoy en día tienen alto rendimiento - por ejemplo, BBC iPlayer generalmente realiza aceptablemente, pero cuando las redes están fuertemente cargado su rendimiento puede deteriorarse, y sin garantías. QoS se aplica a los sistemas operativos así como de redes. Cada recurso crítico debe ser reservado por las aplicaciones que requieren QoS, y debe haber administradores de recursos que ofrecer garantías. Las solicitudes de reserva que no pueden satisfacerse son rechazadas. Estas cuestiones se abordarán con más detalle en el Capítulo 20.

1.6 Estudio de Caso: La World Wide Web

el World Wide Web [www.w3.org I, Berners-Lee 1991] está surgiendo un sistema de publicación y acceso a recursos y servicios a través de Internet. A través de los navegadores web comúnmente disponibles, los usuarios recuperan y ven documentos de muchos tipos, escuchar corrientes de audio y ver secuencias de vídeo e interactuar con un conjunto ilimitado de servicios.

La Web comenzó su andadura en el Centro Europeo para la Investigación Nuclear (CERN), Suiza, en 1989, como un vehículo para el intercambio de documentos entre una comunidad de físicos conectados por Internet Berners-Lee [1999]. Una característica clave de la Web es que ofrece una estructura de hipertexto entre los documentos que almacena, reflejando la exigencia de los usuarios para organizar sus conocimientos. Esto significa que los documentos contienen enlaces (o hipervínculos) - referencias a otros documentos y recursos que se almacenan también en la Web.

Es fundamental para la experiencia del usuario de la Web que cuando encuentran una imagen determinada o un pedazo de texto dentro de un documento, este será con frecuencia acompañada de enlaces a documentos y otros recursos. La estructura de los enlaces puede ser arbitrariamente complejo y el conjunto de recursos que puede añadirse es ilimitado - el 'web' de enlaces es realmente mundial. Bush [1945] concebido de estructuras hipertextuales hace más de 50 años; fue con el desarrollo de Internet que esta idea podría ser manifestado a escala mundial.

La Web es un sistema abierto: puede extenderse y aplicarse en nuevas formas sin perturbar su funcionalidad existente (véase la sección 1.5.2). En primer lugar, su funcionamiento está basado en estándares de comunicación y documento o contenido estándares que son libremente publicados y ampliamente implementados. Por ejemplo, hay muchos tipos de navegador, cada una de ellas, en muchos casos implementado en varias plataformas; y hay muchas implementaciones de servidores web. Cualquier navegador compatible puede recuperar recursos desde cualquier servidor compatible. Para que los usuarios tengan acceso a los exploradores en la mayoría de los dispositivos que utilizan, desde teléfonos móviles a ordenadores de sobremesa.

Segundo, la Web está abierta con respecto a los tipos de recursos que puede ser publicado y compartido. En su forma más simple, un recurso en la Web es una página web o algún otro tipo de contenido que puede ser presentado al usuario, como, por ejemplo, archivos multimedia y documentos en formato PDF (Portable Document Format). Si alguien inventa, digamos, un nuevo formato de almacenamiento de imágenes, la imagen en este formato puede ser inmediatamente publicados en la Web. Los usuarios necesitan un medio de

visualización de imágenes en este nuevo formato, pero los navegadores están diseñados para dar cabida a la nueva funcionalidad de presentación de contenido en forma de aplicaciones 'auxiliares' y 'plug-ins'.

La Web se ha movido más allá de estos simples datos recursos para abarcar los servicios, como la compra de productos electrónicos. Ha evolucionado sin cambiar su arquitectura básica. La Web está basada en tres principales componentes tecnológicos estándar:

El código HTML (HyperText Markup Language), un lenguaje para especificar el contenido y el diseño de las páginas que se muestran en los navegadores web;

Localizadores uniformes de recursos (URL), también conocidos como identificadores de recursos uniformes (URI), que identifican a los documentos y demás recursos almacenados como parte de la Web;

un sistema cliente-servidor arquitectura, con reglas estándar para la interacción (el Protocolo de transferencia de hipertexto (HTTP) por qué navegadores y otros clientes obtención de documentos y otros recursos de servidores web. La figura 1.7 muestra algunos servidores web y navegadores, realizar peticiones a ellos. Una característica importante es que los usuarios pueden localizar y administrar sus propios servidores web desde cualquier lugar de Internet.

Figura 1.7 los servidores web y los navegadores web

ahora podemos analizar estos componentes a la vez, y al hacerlo, explicar el funcionamiento de los navegadores y servidores web cuando un usuario recupera las páginas web y haga clic en los enlaces dentro de ellos.

El HTML HyperText Markup Language [www.w3.org II] se utiliza para especificar el texto y las imágenes que componen el contenido de una página web, y especificar la forma en que están establecidas y el formato para su presentación al usuario. Una página web contiene tales ítems estructurados encabezados, párrafos, tablas e imágenes. HTML se usa también para especificar enlaces y recursos que están asociados con ellos.

Los usuarios pueden producir HTML a mano, utilizando un editor de texto estándar, pero más comúnmente usan un HTML WYSIWYG editor "consciente" que genera el HTML a partir de un diseño que crean gráficamente. Un típico trozo de texto HTML:

<IMG SRC = “http://www.cdk5.net/WebExample/Images/earth.jpg”> 1<P> 2Bienvenido a la tierra! Los visitantes también pueden estar interesados en echar un vistazo a las

3

la <A HREF = “http://www.cdk5.net/WebExample/moon.html”>Luna</A>. 4</P> 5

Estos textos HTML se almacenan en un archivo que el servidor web pueda acceder a - digamos el archivo earth.html. Un explorador recupera el contenido de este archivo desde un servidor web, en este caso un servidor en un equipo llamado www.cdk5.net. El navegador lee el contenido devuelto por el servidor y lo hace en formato texto e imágenes expuestas en una página web en la manera familiar. Sólo el navegador, no el servidor - interpreta el texto HTML. Pero el servidor no informar al navegador del tipo de contenido que se está volviendo, a fin de distinguirlo de, digamos, un documento en formato PDF (Portable Document Format). El servidor puede inferir el tipo de contenido de la extensión '.html'.

Tenga en cuenta que las directivas HTML, conocidos como etiquetas, están encerradas entre paréntesis angulares, como <P>. La línea 1 del ejemplo identifica un archivo que contiene una imagen de presentación. Su URL es http://www.cdk5.net/WebExample/Images/earth.jpg. Las líneas 2 y 5 son directivas para comenzar y finalizar un párrafo, respectivamente. Las líneas 3 y 4 contienen el texto que se muestra en la página web en el formato de párrafo estándar.La línea 4 especifica un enlace en la página web. Contiene la palabra 'Moon' rodeada por dos etiquetas HTML <A HREF...> y </A>. El texto entre estas etiquetas es lo que aparece en el enlace como es presentada en la página web. La mayoría de los navegadores están configurados para mostrar el texto de los enlaces subrayados por defecto, por lo que verá el usuario en ese párrafo es:

Bienvenido a la tierra! Los visitantes también pueden estar interesados en echar un vistazo a la Luna.

El registro del listado de la asociación entre el enlace muestra el texto y la URL que figura en la <A HREF...> etiqueta, en este caso:

http://www.cdk5.net/WebExample/moon.html

cuando el usuario hace clic en el texto, el navegador recupera el recurso identificado por la URL correspondiente y lo presenta al usuario. En el ejemplo, el recurso es un archivo HTML especificando una página web sobre la Luna.

URL El propósito de un Localizador uniforme de recursos [www.w3.org III] es identificar un recurso. De hecho, el término utilizado en la arquitectura web documentos es Identificador uniforme de recurso (URI), pero en este libro el mejor conocido término URL será utilizado cuando no haya ninguna confusión. Los exploradores examinar direcciones URL para acceder a los recursos correspondientes. A veces el usuario escribe una dirección URL en el navegador. Más comúnmente, el explorador busca la URL correspondiente cuando el usuario hace clic en un vínculo o selecciona uno de los 'favoritos'; o cuando el navegador obtiene un recurso incrustado en una página web, como una imagen.

Cada URL, en su Pleno, de forma absoluta, tiene dos componentes de nivel superior:

plan: plan-identificador-específico (scheme: echeme-especific-identifier)

el primer componente, el 'scheme' declara que este tipo de URL. Las direcciones URL son necesarios para identificar una variedad de recursos. Por ejemplo, mailto: joe@anISP.net identifica una dirección de correo electrónico del usuario; ftp://ftp.downloadIt.com/software/aProg.exe identifica un archivo que se va a recuperar mediante el protocolo de transferencia de archivos (FTP) en lugar del protocolo HTTP más comúnmente usada. Otros ejemplos de esquemas son 'tel' (que se utiliza para especificar un número de teléfono para marcar, lo que es particularmente útil cuando se navega en un teléfono móvil) y la 'etiqueta' (utilizado para identificar una entidad arbitrario).

La Web está abierta con respecto a los tipos de recursos que puede utilizarse para tener acceso, en virtud del régimen en los designadores de URLs. Si alguien inventa un nuevo tipo de útil 'widget' recurso - quizás con su propio esquema de direccionamiento para ubicar los widgets y su propio protocolo para acceder a ellos, entonces el mundo puede empezar a utilizar las direcciones URL del tipo widget: ... Por supuesto, los navegadores deben tener la capacidad de usar el nuevo protocolo 'widget', pero esto se puede hacer agregando un plug-in.

URLs HTTP son las más utilizadas, para acceder a los recursos mediante el protocolo HTTP estándar. La dirección URL de HTTP tiene dos tareas principales: identificar qué servidor Web mantiene el recurso, y para identificar cuáles de los recursos de dicho servidor es obligatorio. La figura 1.7 muestra tres exploradores emitir solicitudes de recursos administrados por tres servidores web. El primer explorador es emitir una consulta a un motor de búsqueda. La mitad explorador requiere la página predeterminada de otro sitio web. El navegador inferior requiere una página web que se especifica en su totalidad, incluyendo el nombre de una ruta de acceso relativa al servidor. Los archivos de un servidor web determinado se mantienen en uno o más subárboles (directorios) del sistema de archivos del servidor, y cada recurso es identificado por un nombre de ruta relativa al servidor.

En general, los URLs HTTP son de la forma siguiente:

http:// servername[:puerto] [/pathName] [?consulta] [ #fragmento]

donde los elementos entre corchetes son opcionales. Un URL http completo siempre comienzan con la cadena 'http://' seguido de un nombre de servidor, expresado como un sistema de nombres de dominio (DNS) (véase la sección 13.2). El nombre DNS del servidor es opcionalmente seguido por el número del puerto en el que escucha el servidor de peticiones (véase el capítulo 4), el cual es 80 por defecto. Luego viene un nombre de ruta opcional de los recursos del servidor. Si esto está ausente entonces la página web predeterminada del servidor es obligatorio. Por último, opcionalmente la URL termina en un componente de consulta - por ejemplo, cuando un usuario envía las entradas en un formulario como un motor de búsqueda en la página de consulta - y/o un identificador de fragmento, que identifica un componente del recurso.

Considere la URL: Http://www.cdk5.net http://www.w3.org/standards/faq.html#conformance Http://www.google.com/search?q=obama

estos pueden dividirse como sigue:

Servidor nombre DNS nombre de ruta

Fragmento de consulta

Www.cdk5.net (predeterminado)

(Ninguno) (Ninguno)

www.w3.org normas/faq.html

(ninguno) Introducción

www.google.c búsqueda q=obama (ninguno)

om

El primer URL designa la página predeterminada suministrada por

www.cdk5.net. La siguiente identifica un fragmento de un archivo HTML cuyo nombre de ruta es normas/faq.html relativa al servidor www.w3.org. (identificador del fragmento especificado después del carácter '#' en la URL) es preludio, y un navegador buscará que dentro del identificador de fragmento de texto HTML después de que se haya descargado el archivo entero. La tercera URL especifica una consulta a un motor de búsqueda. La ruta identifica un programa llamado 'search', y la cadena después de que el carácter '?' codifica una cadena de consulta suministrado como argumentos a este programa. Discutimos las URL que identifique los recursos programáticos en más detalle cuando consideramos las características más avanzadas de abajo.

Publicar un recurso: mientras que la Web tiene un modelo claramente definidos para acceder a

un recurso de su URL, los métodos precisos para publicar recursos en la Web dependen de la aplicación del servidor web. En términos de mecanismos de bajo nivel, el método más sencillo de publicar un recurso en la Web es colocar el archivo correspondiente en el directorio que el servidor web pueda acceder. Saber el nombre del servidor y el nombre de la ruta de acceso para el archivo P que el servidor puede reconocer, a continuación, el usuario construye la URL como http://S/P. El usuario coloca a esta dirección URL en un enlace de un documento existente o distribuye la URL a otros usuarios, por ejemplo, por correo electrónico.

Es común que tales preocupaciones se ocultan a los usuarios cuando se genera el contenido. Por ejemplo, "bloggers" que suelen utilizar herramientas de software, implementada como páginas web, para crear colecciones organizadas de páginas de la revista. Páginas de productos para el sitio web de una empresa se crean normalmente mediante un sistema de gestión de contenidos, de nuevo directamente interactuando con el sitio web administrativo a través de páginas web. La base de datos o sistema de archivos en el que se basan las páginas de producto es transparente.

Por último, Huang et al. [2000] proporcionan un modelo para la inserción de contenido en la Web con una mínima intervención humana. Esto es particularmente relevante cuando los usuarios necesitan para extraer el contenido de una variedad de dispositivos, como cámaras, para su publicación en las páginas web.

HTTP El Protocolo de transferencia de hipertexto Www.w3.org [IV] define las maneras en que los navegadores y otros tipos de cliente interactúan con los servidores web. El capítulo 5 se consideran HTTP en más detalle, pero aquí

resumimos sus principales características (limitar nuestra discusión a la obtención de recursos de los archivos):

Petición-respuesta interacciones: HTTP es un 'request' protocolo de respuesta. El cliente envía un mensaje de solicitud al servidor que contiene la URL del recurso requerido. El servidor busca el nombre de la ruta y, si existe, devuelve el contenido del recurso en un mensaje de respuesta al cliente. De lo contrario, envía una respuesta de error, como las conocidas "404 Not Found". HTTP define un pequeño conjunto de operaciones o métodos que pueden realizarse en un recurso. Los más comunes son GET, para recuperar datos del recurso, y puesto, a fin de proporcionar datos al recurso.

Tipos de contenido: Los navegadores no son necesariamente capaces de manipular todo tipo de contenido. Cuando un navegador hace una petición, se incluye una lista de los tipos de contenido que prefiere - por ejemplo, en principio, puede ser capaz de mostrar imágenes en formato "GIF" pero no formato 'JPEG'. El servidor puede ser capaz de tener esto en cuenta cuando se devuelve el contenido al explorador. El servidor incluye el tipo de contenido en el mensaje de respuesta de modo que el navegador sabrá cómo procesarlo. Las cadenas que indican el tipo de contenido se denominan tipos MIME, y son uniformes en la RFC 1521 [liberados y Borenstein, 1996]. Por ejemplo, si el contenido es de tipo "text/html" luego un navegador interpretará el texto como HTML y mostrarlo; si el contenido es de tipo "image/GIF" y, a continuación, el navegador lo haría como una imagen en formato "GIF"; si el contenido es de tipo "application/zip' entonces es datos comprimidos en formato 'ZIP', y el explorador lanzará una aplicación auxiliar externo para descomprimirlo. El conjunto de acciones que un navegador tendrá para un determinado tipo de contenido es configurable, y los lectores pueden comprobar estos valores de cuidados para sus propios navegadores.

Un recurso por solicitud: Los clientes especifican un recurso por petición HTTP. Si una página web contiene nueve imágenes, es decir, el navegador se emitirán un total de diez solicitudes separadas para obtener todo el contenido de la página. Los exploradores suelen hacer varias solicitudes simultáneamente, para reducir la demora total para el usuario.

Control de acceso simple: Por defecto, cualquier usuario con conectividad de red a un servidor web puede tener acceso a cualquiera de sus recursos publicados. Si los usuarios desean restringir el acceso a un recurso, entonces se puede configurar el servidor para emitir un "desafío" a cualquier cliente que lo solicite. El usuario correspondiente, entonces, tiene

que demostrar que ellos tienen el derecho de acceso al recurso, por ejemplo, escribiendo una contraseña.

Páginas dinámicas Hasta ahora hemos descrito cómo los usuarios pueden publicar páginas web y otros contenidos almacenados en archivos en la Web. Sin embargo, gran parte de la experiencia de los usuarios de la Web es que a la hora de interactuar con los servicios en lugar de recuperar los datos. Por ejemplo, cuando compra un artículo en una tienda en línea, el usuario a menudo rellena un formulario web para proporcionar detalles personales o para especificar exactamente lo que desean comprar. Un formulario web es una página que contiene las instrucciones para el usuario y widgets de entrada como campos de texto y casillas de verificación. Cuando el usuario envía el formulario (normalmente pulsando un botón o la tecla 'return'), el navegador envía una petición HTTP a un servidor web, que contiene los valores que el usuario ha introducido.

Dado que el resultado de la solicitud depende de la entrada del usuario, el servidor tiene que procesar la entrada del usuario. Por lo tanto, la URL o su componente inicial designa un programa en el servidor, no a un archivo. Si la entrada del usuario es razonablemente pequeño conjunto de parámetros es enviado a menudo como el órgano de consulta de la URL, utilizando el método GET; alternativamente, se envía como datos adicionales en la solicitud mediante el método POST. Por ejemplo, una solicitud que contenga la siguiente URL invoca un programa llamado 'search' en www.google.com y especifica una cadena de consulta de 'Obama':

http://www.google.com/search?q=obama.

Que 'search' programa produce texto HTML como su salida, y el usuario verá una lista de páginas que contienen la palabra 'Obama'. (El lector puede atención para introducir una consulta en su motor de búsqueda favorito y observe la dirección URL que muestra el explorador cuando se devuelve el resultado.) El servidor devuelve el texto HTML que el programa genera sólo como si se hubiera recuperado desde un archivo. En otras palabras, la diferencia entre contenido estático descabellada desde un archivo y el contenido que se genera dinámicamente es transparente para el navegador.

Un programa que se ejecutan en servidores web para generar contenido para sus clientes es conocido como un CGI (Common Gateway Interface). Un programa CGI puede tener cualquier funcionalidad específica de la aplicación, en la medida en que puede analizar los argumentos que el cliente proporciona a ella y producir contenidos de tipo requerido

(normalmente texto HTML). El programa se suele consultar o actualizar una base de datos en el procesamiento de la solicitud.

El código descargado: un programa CGI se ejecuta en el servidor. A veces los diseñadores de servicios web requieren algunos relacionados con el servicio para ejecutar código dentro del navegador en el equipo del usuario. En particular, el código escrito en JavaScript [www.netscape.com] suele ser descargado con una página web que contenga un formulario, con el fin de proporcionar una mejor calidad de interacción con el usuario de lo que admite el estándar HTML widgets. Un JavaScript- página mejorada puede proporcionar al usuario información inmediata sobre las entradas no válidas, en lugar de forzar al usuario a comprobar los valores en el servidor, el cual tomaría mucho más tiempo.

JavaScript puede ser utilizado también para actualizar ciertas partes del contenido de una página web sin la obtención de una versión totalmente nueva de la página y volver a presentarlo. Estas actualizaciones dinámicas se producen debido a una acción del usuario (como hacer clic en un vínculo o un botón de opción), o cuando el navegador adquiere nuevos datos desde el servidor que ha suministrado la página web. En este último caso, desde el momento de la llegada de los datos no está relacionada con ninguna acción del usuario en el propio navegador, se denomina asíncrono. Una técnica conocida como AJAX (Asynchronous Javascript and XML) se utiliza en estos casos. AJAX se describen con más detalle en la sección 2.3.2.

Una alternativa a un programa en JavaScript es un applet: una aplicación escrita en lenguaje Java Flanagan [2002], en el que el navegador se descarga y ejecuta automáticamente cuando se recupera una página web correspondiente. Los applets pueden acceder a la red y proporcionar interfaces de usuario personalizadas. Por ejemplo, aplicaciones de "chat" a veces se implementan como applets que se ejecutan en los navegadores de los usuarios, junto con un programa de servidor. Los applets enviar el texto de los usuarios al servidor, que a su vez lo distribuye a todos los applets para su presentación al usuario. Discutimos applets en más detalle en la sección 2.3.1.

Servicios Web Hasta ahora hemos hablado de la Web principalmente desde el punto de vista de un usuario que opere un explorador. Pero otros programas distintos de los navegadores pueden ser clientes de la Web, demasiado; de hecho, el acceso mediante programación a los recursos web es habitual.

Sin embargo, el HTML es inadecuado para la interoperación de programación. Existe una creciente necesidad de intercambiar muchos tipos de datos estructurados en la Web, pero el html es limitado, ya que no es extensible a las aplicaciones más allá de la información, la navegación. El código HTML tiene un conjunto estático de estructuras tales como párrafos, y están ligadas con la manera en la que los datos se presentan a los usuarios. XML (Extensible Markup Language) (véase la sección 4.3.3) ha sido diseñada como una forma de representar datos en estándar, estructurado, las formas específicas de aplicación. En principio, el dato expresado en XML es portable entre aplicaciones, ya que es auto descriptivo: contiene los nombres, tipos y estructura de los elementos de datos dentro de ella. Por ejemplo, XML puede ser utilizado para describir los productos o información sobre los usuarios, para muchos de los diferentes servicios o aplicaciones. En el protocolo HTTP, XML, los datos pueden ser transmitidos por las operaciones GET y POST. En AJAX puede ser utilizado para proporcionar datos a los programas JavaScript en los navegadores.

Recursos Web proporcionan servicio de operaciones específicas. Por ejemplo, en la tienda de Amazon.com las operaciones de los servicios web incluyen uno a pedir un libro y otro para comprobar el estado actual de la orden. Como hemos mencionado, HTTP proporciona un pequeño conjunto de operaciones que son aplicables a cualquier recurso. Estos incluyen principalmente los métodos GET y POST sobre los recursos existentes y las operaciones PUT y DELETE, respectivamente.

Para crear y eliminar recursos web. Cualquier operación en un recurso puede ser invocado usando uno de los métodos GET o POST, con contenido estructurado utilizado para especificar los parámetros de la operación, los resultados y las respuestas de error. Los llamados REST (Representational State Transfer) Arquitectura para servicios web [2000] Fielding adopta este enfoque sobre la base de su extensibilidad: todo el recurso de la Web tiene una dirección URL y responde al mismo conjunto de operaciones, aunque los procesamientos de las operaciones pueden variar ampliamente de un recurso para el recurso. La otra cara de extensibilidad que puede ser una falta de solidez en la forma en que el software funciona. El capítulo 9 describe, además, el descanso y la toma una mirada en profundidad a la estructura de servicios web, que permite a los diseñadores de web servicies para describir a los programadores más específicamente qué operaciones específicas de servicio están disponibles y cómo los clientes deben tener acceso a ellos.

Discusión de la Web La Web es fenomenal, el éxito descansa sobre la relativa facilidad con la que muchas fuentes individuales y organizacionales pueden publicar recursos, la adecuación de su estructura de hipertexto para

organizar muchos tipos de información, y la apertura de su arquitectura del sistema. Las normas en que se basa su arquitectura simple y fueron ampliamente publicadas en una etapa temprana. Esto ha permitido que muchos de los nuevos tipos de recursos y servicios para ser integrados.

El éxito del Web desmiente algunos problemas de diseño. Primero, su modelo de hipertexto es deficiente en algunos aspectos. Si un recurso es eliminado o movido, denominada 'pescar' enlaces a recursos que aún puedan quedar, causando la frustración de los usuarios. Y allí está el conocido problema de que los usuarios reciben "perdido en el hiperespacio". Los usuarios a menudo encuentran confundidos, tras muchos y diversos vínculos, referencias de páginas a partir de una colección de fuentes dispares, y de dudosa fiabilidad en algunos casos.

Los motores de búsqueda son una alternativa muy popular en los siguientes enlaces como una forma de encontrar información en la Web, pero estos son imperfectos en producir lo que el usuario se propone concretamente. Un enfoque de este problema, ejemplificada en la Descripción Marco www.w3.org [V], es producir vocabularios estándar, sintaxis y semántica para expresar metadatos acerca de las cosas en nuestro mundo, y con el fin de encapsular esos metadatos en los correspondientes recursos web para el acceso mediante programación. En lugar de buscar palabras que aparecen en las páginas web, los programas pueden entonces, en principio, realizar búsquedas en los metadatos para compilar listas de enlaces relacionados sobre la base de la coincidencia semántica. Colectivamente, la web de metadatos vinculados los recursos es lo que se entiende por la web semántica.

Como una arquitectura de sistema de la Web se enfrenta a problemas de escala. Servidores web populares pueden experimentar muchos "hits" por segundo y, como consecuencia, las respuestas a los usuarios pueden ser lentos. En el capítulo 2 se describe el uso del almacenamiento en caché de los navegadores y los servidores proxy para aumentar la capacidad de respuesta, y la división de la carga del servidor a través de clusters de ordenadores.

1.7 Resumen

sistemas distribuidos por doquier. La Internet permite a los usuarios de todo el mundo para acceder a sus servicios dondequiera que se encuentren. Cada organización maneja una intranet, que ofrece servicios locales y servicios de Internet para usuarios locales y, en general, presta servicios a otros usuarios en el Internet. Los pequeños sistemas distribuidos pueden ser construidas a partir de los

ordenadores portátiles y otros pequeños dispositivos de cálculo que están conectados a una red inalámbrica.

Intercambio de recursos es el principal factor motivador para la construcción de sistemas distribuidos. Recursos como impresoras, archivos, páginas web o los registros de la base de datos son gestionados por los servidores del tipo apropiado. Por ejemplo, servidores web gestionar páginas web y otros recursos web. Los recursos son accedidos por clientes - por ejemplo, los clientes de los servidores web son generalmente llamados exploradores.

La construcción de sistemas distribuidos produce muchos desafíos:

heterogeneidad: deben ser construidos a partir de una variedad de diferentes redes, sistemas operativos, hardware y lenguajes de programación. Los usos de protocolos de comunicación de Internet enmascaran la diferencia en las redes, y middleware pueden tratar con las otras diferencias.

Apertura: sistemas distribuidos deben ser extensible: el primer paso es publicar las interfaces de los componentes, pero la integración de componentes escritos por distintos programadores, es un verdadero reto.

Seguridad: cifrado puede ser utilizado para proporcionar una protección adecuada de los recursos compartidos y a mantener en secreto la información confidencial cuando se transmite en los mensajes a través de una red. Los ataques de denegación de servicio siguen siendo un problema.

Escalabilidad: un sistema distribuido es escalable si el costo de agregar un usuario es una cantidad constante en términos de los recursos que se deben agregar. Los algoritmos utilizados para tener acceso a los datos compartidos deben evitar los cuellos de botella en el rendimiento y los datos deben ser estructurados jerárquicamente para conseguir los mejores tiempos de acceso. Los datos a los que se accede frecuentemente puede ser replicada.

Manipulación de fallos: cualquier proceso, equipo o red puede fallar independientemente de los otros. Por lo tanto, cada componente debe ser consciente de las posibles maneras en que los componentes pueden fallar y estar diseñado para tratar con cada uno de esos fracasos apropiadamente.

Concurrencia: La presencia de múltiples usuarios en un sistema distribuido es una fuente de solicitudes simultáneas a sus recursos. Cada recurso debe ser diseñado para ser seguro en un entorno concurrente.

Transparencia: El objetivo es hacer que ciertos aspectos de la distribución invisible para el programador de la aplicación, de modo que sólo tienen que estar

preocupados con el diseño de su aplicación concreta. Por ejemplo, no deben estar preocupados con su ubicación o los detalles de la forma en que su operación se accede por otros componentes, o si será replicado o migrar. Incluso los fracasos de las redes y procesos pueden ser presentados a los programadores de aplicaciones en forma de excepciones, pero deben ser manejados.

La calidad del servicio. No es suficiente para facilitar el acceso a los servicios en sistemas distribuidos. En particular, también es importante dar garantías respecto de las cualidades asociadas con tal acceso. Ejemplos de tales cualidades incluyen parámetros relacionados con el rendimiento, seguridad y fiabilidad.

1. Ejercicios

1.1. proporcionan cinco tipos de recursos de hardware y cinco tipos de datos o software de recursos que pueden ser compartidos. Dar ejemplos de su participación, como ocurre en la práctica en sistemas distribuidos. páginas 2, 14

Recursos hardware:o Routero Switcho Servidoro Impresorao Scanner

Recursos Softwareo Páginas webo Documentos en formato pdfo Noticiaso Propagandaso TV online

1.2. ¿Cómo podrían los relojes en dos equipos que están conectados por una red local se sincronicen sin referencia a una fuente horaria externa? ¿Qué factores limitan la precisión del procedimiento que usted ha descrito? ¿Cómo podrían los relojes en un gran número de computadoras conectadas por Internet estén sincronizados? Discutir la exactitud de este procedimiento. página 2

Con el uso de algoritmos como los semáforos que se usan en muchos sistemas operativos para sincronización de procesos.

1.3. Examinar las estrategias de ejecución para los juegos multijugador en línea tal como se describe en Sección 1.2.2. En particular, ¿Qué ventajas ve en la adopción de un enfoque de servidor único para representar el estado del juego multijugador? ¿Qué problemas puede identificar y cómo pueden resolverse? Página 5

Realizando una página web incrustada en el servidor de internet, que al conectarse inalámbricamente a través del punto de acceso cague como página principal los servicios que brinda la estación. Las dificultades que se presentarían a la hora de desarrollar esta solución, son los costos de implantación y mantenimiento que sería necesario cubrir.

1.4. Un usuario llega a una estación de ferrocarril que nunca ha visitado antes, llevando una PDA que es capaz de redes inalámbricas. Sugerir la forma en que el usuario pudiera contar con información acerca de los servicios y comodidades en esa estación, sin necesidad de introducir el nombre de la estación o atributos. ¿Qué desafíos técnicos que deben superarse? Página 13

1.5. ¿Comparar y contrastar el cloud computing con más tradicionales de computación cliente-servidor? ¿Qué es la novela sobre el cloud computing como un concepto? En las páginas 13, 14

1.6. Utilizar la World Wide Web como un ejemplo para ilustrar el concepto de recurso compartido, el cliente y el servidor. ¿Cuáles son las ventajas y desventajas de HTML, HTTP y URL como núcleo de tecnologías de la información de navegacion? ¿Ninguna de estas tecnologías como una base adecuada para la computación cliente-servidor en general? Las páginas 14, 26

El world wide web es un ejemplo de cómo compartir recursos cliente-servidor, haciendo que mediante un software de navegador el cliente accede a una web y solicita un video, siendo esto procesado y llevado al servidor, terminando de gestionar el acceso el servidor devuelve el origen del video para poder ser visualizado por el cliente.

 HTML, las ventajas podrían ser que se utiliza para especificar el texto e imágenes que forman el contenido de una pagina web y para especificar como serán formateados para la presentación al usuario y las desventajas serian el utilizar un editor de texto estándar, cosa que para alguien que no maneje muy bien el html, seria difícil construir una pagina web, por ello seria mejor usar un software especializado.

 URL, las ventajas serian que identifica un recurso de tal forma que permita al navegador localizarlo, identificar que servidor web mantiene el recurso e identifica cual de los recursos del servidor es solicitado, y no veo existir alguna desventaja.

 HTTP, la ventaja es que define las formas en las que los navegadores y otros tipos de clientes interaccionan con los servidores web, siendo esta una tecnología adecuada para la plataforma cliente-servidor.

HTMLVentajas: Desventajas:

Fácil de usar, casi como usar Word.

Las aplicaciones de texto, tienen la ventaja de ocupar poco espacio, ser rápidas y la mayoría tiene mucho desarrollo. Hay que pensar que las terminales existen hace mucho tiempo.

Es muy básico, no ofrece demasiadas opciones; como programa para crear páginas Web, no es el más completo; al realizar acciones complejas se complica todo.Los programas de texto son poco amigables y tienen una interfaz restringida. Son ideales para tareas administrativas de la computadora, terminales con enlaces lentos, y software en general para computadoras de poca capacidad.Como contrapartida existen las aplicaciones gráficas, con una interfaz mejorada, pero con mayor lentitud en mostrar información. Son ideales para tareas de usuarios finales, personas con poca práctica en computación, etc.En este curso se van a usar aplicaciones gráficas en lo posible.Las tareas administrativas más importantes (añadir/eliminar usuarios, configurar hardware, dar permisos, etc.) se pueden hacer en ambas interfaces, tanto en la de texto como en la gráfica.

URL (http://es.wikipedia.org/wiki/Data_URL 2010)

Ventajas DesventajasLas cabeceras HTTP no son requeridas para los datos empotrados, por lo que data: URIs pueden usar menos recursos de la red que la sobrecarga de la codificación del contenido en línea ya que un data: URI es más pequeño que las cabeceras HTTP que de otro modo serían necesarias.Los navegadores están típicamente configurados para usar un máximo de cuatro conexiones simultáneas a un servidor, por lo que los datos en línea liberan una conexión de descarga para otros contenidos.Los navegadores gestionan menos entradas de cache para un fichero que contiene data: URIs.Los entornos con un acceso limitado o restringido a los recursos externos pueden empotrar contenido cuando no se permite o no es práctico hacer referencias externas. Por ejemplo, un campo avanzado de edición de HTML podría aceptar una imagen pegada o insertada y convertirla en un data: URI para ocultar la complejidad de las fuentes externas al usuario.

El contenido empotrado debe ser extraído y decodificado antes de realizarse cambios, y después debe ser recodificado y reempotrado.Los data: URIs codificados en Base64 son aproximadamente un 33% más grandes que sus equivalentes binarias.Las URL codificadas como data: URIs pueden ser hasta un 200% más grandes (en casos extremos) que el contenido del texto original.La información que es empotrada más de una vez es descargada para cada referencia como parte del fichero contenedor, y por lo tanto no se beneficia del caché del navegador.La capacidad máxima del navegador en la longitud del URI limita el tamaño máximo de los datos. Por ejemplo, los URIs en Opera suelen tener un límite de 4KB.Los datos son incluidos como flujos simples, y muchos entornos de procesamiento (como los navegadores web) pueden no soportar dichos contenedores (como multipart/alternative o message/rfc822) para proveer una complejidad mayor como metadatos, compresión de datos o negociación de contenidos.

HTTPVentajas Desventajas

Es más rápido y más funcional para transmitir páginas de internet.

Cada vez que se visita una página, el contenido tiene que ser descargado.

1.7. Programa servidor escrita en un idioma (por ejemplo, C++) ofrece la implementación de un objeto BLOB que se destina a ser visitada por los clientes que pueden estar escritas en un idioma distinto (por ejemplo, Java). Los equipos cliente y servidor pueden tener diferente hardware, pero todos ellos están conectados a internet. Describir los problemas debidos a cada uno de los cinco aspectos de la heterogeneidad que necesitan ser resueltos para hacer posible que un cliente objeto para invocar un método en el objeto servidor. Página 16

1.8. abierto un sistema distribuido que permite compartir recursos nuevos servicios tales como el objeto BLOB en ejercicio 1.7 que se agregan y se accede por una gran variedad de programas de cliente. Discutir en el contexto de este ejemplo, ¿hasta qué punto las necesidades de apertura difieren de las de la heterogeneidad. Página 17

1.9. Suponga que las operaciones del objeto BLOB se dividen en dos categorías: las operaciones públicas que están disponibles para todos los usuarios y operaciones protegidas que sólo están disponibles para determinados usuarios. Estado todos los problemas involucrados en asegurar que sólo el usuario mencionado puede utilizar una operación protegida. ¿Suponiendo que el acceso a una operación protegida proporciona información que no debe ser revelada a todos los usuarios, lo que más problemas plantean? Página 18

1.10. El Info Service administra un potencialmente muy amplio conjunto de recursos, cada una de las cuales puede ser visitada por los usuarios a través de Internet por medio de una tecla (un nombre de tipo string). Hablar de un enfoque para el diseño de los nombres de los recursos que consigue la mínima pérdida de rendimiento como el número de recursos del servicio aumenta. Sugerir la forma en que el servicio de información puede ser implementado para evitar los cuellos de botella en el rendimiento cuando el número de usuarios es muy grande. página 19

1.11. Enumerar los tres principales componentes de software que pueden fallar cuando un proceso cliente invoca un método en un objeto de servidor, dando un ejemplo de fracaso en cada caso. Sugerir cómo los componentes pueden tolerar mutuamente sus fracasos. página 21

1.12. Un proceso servidor mantiene una información compartida como objeto el objeto BLOB de ejercicio 1.7. Dar argumentos a favor y en contra de permitir que el cliente pide ser ejecutado simultáneamente por el servidor. En el caso de que se ejecuten concurrentemente, dar un ejemplo de posibles "interferencias" que puede ocurrir entre las operaciones de los distintos clientes. Sugerir cómo tales interferencias pueden prevenirse. página 22

1.13. es un servicio implementado por varios servidores. Explicar por qué recursos podrían transferirse entre ellos. ¿Sería satisfactorio para los clientes de multidifusión a todas las peticiones del grupo de servidores como una manera de lograr la transparencia de movilidad para los clientes? Página 23

1.14. Recursos en la World Wide Web y otros servicios son nombrados por URL. ¿Qué significan las siglas URL denotan? Dar ejemplos de tres tipos distintos de recursos en la web que pueden ser nombradas por URL. página 26

1.15. dar un ejemplo de una URL HTTP. Enumerar los principales componentes de una URL HTTP, indicando cómo sus límites se identifican e ilustrando cada uno de su ejemplo.¿Hasta qué punto es una dirección URL HTTP locación-transparente? Página 26