Clientes Multihilos

En el contexto de arquitecturas cliente-servidor, la implementación de hilos en el lado del cliente proporciona los siguientes beneficios [2]:

• Ocultar latencias de red: El navegador web escanea una página HTML entrante y encuentra que hay más archivos que necesita, entonces continúa con el proceso de recuperación de los mismos. Los archivos recuperados se despliegan conforme van llegando. De esta manera, el usuario no necesita esperar hasta que todos los componentes de la página sean recuperados por completo.

• Cada archivo es recuperado por un hilo: La programación de la configuración de una conexión y la lectura desde el servidor pueden llevarse a cabo mediante una solicitud de tipo HTTP(bloqueo). Las llamadas de este tipo no suspende el proceso por completo.

• Conexiones simultáneas: Cuando se utiliza cliente multihilos, las conexiones pueden configurarse como réplicas diferentes lo cual permite que los datos sean transferidos en paralelo asegurando efectivamente que se despliega la página web completa en un tiempo más corto que con un servidor no replicado.

Ejemplo: Múltiples llamadas a RPC  

Un cliente realiza varias llamadas al mismo tiempo a procesos remotos, cada una por una diferente hilo. Luego, espera hasta que se hayan devuelto todos los resultados. Si las llamada son a diferentes servidores, podemos tener una rapidez lineal en la respuesta a la solicitud.

Interfases de Usuario en la Red 

Las interfases de usuario en la red pueden implementarse a nivel de aplicación y a nivel de middleware. Este ejemplo, tomado de [2], ilustra la diferencia de la implementación de interfases a nivel del cliente o en el middleware. Aqui se ilustra el comportamiento de una agenda que se ejecuta en una PDA de un usuario y que requiere sincronizarse con una agenda compartida remota. 

En este caso, un protocolo a nivel de aplicación manipulará esta sincronización, como podemos ver en la Figura 1 parte (a). En la parte (b) de la Figura 1 se muestra una solución donde se proporciona acceso directo a servicios remotos solamente por medio de la oferta en la interfaz de usuario. Esto significa que la máquina cliente sólo se utiliza como terminal sin necesidad de almacenamiento local. En este caso de interfaces de usuario en red, todo es procesado y almacenado en el servidor. Este método de cliente ligero llamado también clientes delgados, recibe mayor atención al incrementarse la conectividad a internet, y a medida que los dispositivos portátiles (hand-held) se han vuelto más sofisticados. 

Figura 1: (a) Aplicación en red con su protocolo.  Adaptado de [2]
 

Figura 1:   (b) Aplicación con acceso a aplicaciones remotas. Adaptado de [2]

            

Software del lado del Cliente para transparencia en la distribución.

 Un cliente no solo consta de una interfaz de usuario y de la aplicación, el software del cliente tiene los componentes necesarios para lograr la transparencia en el acceso, migración, distribución y fallas. A continuación se menciona cada una de este tipo de transparencia [2]:

• Transparencia de acceso: Implementando stubs (apéndices o conectores) del lado del cliente para las llamadas a procedimientos remotos (RPC). La transparencia en el acceso es gestionada a partir de una definición de interfaz donde se muestra lo que el cliente tiene que ofrecer.

• Transparencia de ubicación/migración: deje que el software del lado del cliente realice un seguimiento de ubicación actual. Para ello es importante el uso de un adecuado sistema de nombres, 

• Transparencia de replicación: múltiples invocaciones manejadas por el código auxiliar del cliente. El software del lado del cliente puede recopilar de manera transparente todas las respuestas y pasar solamente una respuesta a la aplicación del cliente. Esquema de este comportamiento se muestra en la Figura 2.

• Transparencia de falla: El enmascaramiento de las fallas de la comunicación con un servidor se hace a través del middleware del cliente: ejemplo, la configuración del middleware del cliente para intentar repetidamente la conexión a un servidor, o tratar con otro servidor después de varios intentos fallidos; también cuando middleware del cliente devuelve datos que tenía en caché durante una sesión previa.

Figura 2: Transparencia de replicación de un servidor mediante una solución del lado del 

cliente. Adaptado de [2]

Bibliografía

    [1]George Coulouris et al. Distributed Systems: Concepts and Design. 5th. USA: Addison-Wesley Publishing Company, 2011

    [2]M van Steen and A.S. Tanenbaum. Distributed Systems. Edited by Pearson Prentice Hall. Third. distributed-systems.net, 2017

Modelos Arquitectónicos. Correspondencia con la infraestructura física distribuida. Parte 1

 Modelos Arquitectónicos. 

Correspondencia con la infraestructura física distribuida I

En esta clasificación se considera cómo las entidades, objetos o servicios se asignan o forman parte de la infraestructura física distribuida subyacente. Se exploran tres aspectos [1] [2]: Elementos que conforman la arquitectura, Patrones que usa la arquitecura y Soluciones basadas en middleware

1. Elementos de la Arquitectura

Comprende los siguientes • Correspondencia de servicios con servidores. • Memoria Cache. • Código Móvil. • Agentes Móviles.

• Correspondencia de servicios con servidores. Los servicios pueden implementarse como varios servidores de procesos en computadoras separadas que interactúan según sea necesario para proporcionar un servicio a procesos del cliente. En la Figura 1 se muestra un ejemplo

Figure 1: Arquitectura con múltiples servidores. Tomado de [1]

• Cache. Los navegadores web mantienen un caché con las páginas web visitadas recientemente y otros recursos web en el sistema de archivos  local del cliente, utilizando una solicitud HTTP para verificar con el servidor original que las páginas en caché del cliente, utilizando una solicitud HTTP para verificar con el servidor original que las páginas en caché están actualizadas. Un servidor proxy web (ver Figura 2) proporciona un caché compartido de recursos web para las máquinas cliente en un sitio o en varios sitios.

Figure 2: Arquitectura web proxy.

• Código móvil. El applet es un ejemplo de código móvil: el usuario que ejecuta un navegador selecciona un enlace a un subprograma cuyo código se almacena en un servidor web; el código se descarga en el navegador y lo ejecuta , como se muestra en la Figura 3.

Figure 3: Arquitectura web applet.

• Agentes móviles El agente móvil puede realizar invocaciones a los recursos locales en cada sitio que visita, por ejemplo, acceder a entradas individuales de la base de datos. Los agentes móviles pueden usarse para instalar y mantener software en las computadoras dentro de una organización o para comparar los precios de productos de varios proveedores visitando el sitio de cada proveedor y realizando una serie de operaciones de base de datos.

2. Patrones de Arquitectura

Los patrones arquitectónicos [3] dan una descripción de los elementos y el tipo de relación que tienen junto con un conjunto de restricciones. Un patrón arquitectónico expresa un esquema de organización estructural esencial para un sistema de software, que consta de subsistemas, sus responsabilidades e interrelaciones. No son necesariamente soluciones completas en sí mismas, sino que ofrecen conocimientos parciales que, cuando se combinan con otros patrones, llevan al diseñador a una solución para un dominio de problema dado.

• Capas. En un enfoque por capas, un sistema complejo se divide en varias capas, con un capa dada haciendo uso de los servicios ofrecidos por la capa siguiente. La capa referida ofrece una abstracción de software, con capas superiores que desconocen detalles de su implementación, o de cualquier otra capa debajo de ellos. En términos de sistemas distribuidos, esto equivale a una organización vertical de servicios en capas de servicio. Ejemplo de esta estructura es el middleware.

• Arquitectura de capas. Las arquitecturas de capas es una técnica para organizar la funcionalidad de una capa determinada y colocarla en servidores apropiados y, como consideración secundaria, en los nodos físicos. Esta técnica se asocia más comúnmente con la organización de aplicaciones y servicios. Por ejemplo, en la figura 4 se observa una arquitectura de dos capas, cliente y servidor; mientras la Figura 5 es el esquema de una arquitectura de tres capas: cliente, servidor y servidor de base de datos.

Figure 4: Arquitectura de capas de dos niveles.

Figure 5: Arquitectura de capas de tres niveles.

• Clientes flacos La tendencia en la computación distribuida es alejar la complejidad del dispositivo del usuario final hacia los servicios en Internet. Esto es más evidente en la computación en la nube, pero también se puede ver en la arquitectura de niveles. Esta tendencia ha suscitado el interés en cliente ligero, que permite el acceso a sofisticados servicios en red, proporcionados por una solución en la nube, con pocas suposiciones o demandas en el dispositivo del cliente, entre otros. La Figura 6 ilustra un cliente ligero que accede a un servidor informático a través de Internet.

Figure 6: Arquitectura de cliente ligero.

• Patron Proxy. El patrón proxy es un patrón recurrente en sistemas distribuidos, diseñados para apoyar la transparencia de la ubicación en llamadas de procedimiento remoto (RPC) o invocación del método (RMI). Es un intermediario entre un objeto y el resto que lo invoque.

• Brokerage. El uso de corredores o brokerage en servicios web puede verse como un patrón que admite la interoperabilidad en infraestructuras distribuidas potencialmente complejas. Este patrón consta del trío de proveedores de servicios, solicitante de servicios y corredor de servicios (un servicio que coincide con los servicios prestados a los solicitados), como se muestra en la Figura 7.

Figure 7: Patrón arquitectónico en servicios web.

Bibliografía

[1]George Coulouris et al. Distributed Systems: Concepts and Design. 5th. USA: Addison-Wesley Publishing Company, 2011

[2]Christina J. Hogan Thomas A. Limoncelli Strata R. Chalup. The Practice ofCloud System Administration: Designing and Operating Large Distributed Systems. Volume 2. Addison Wesley, 2014.

[3]Roger S. Pressman and Bruce R. Maxim. Software Engineering: A Practitioner’s Approach. 9th edition. McGraw-Hill Education, 2019.