Comunicación Indirecta. 

    En la comunicación indirecta la naturaleza del intermediario y del acoplamiento varían de

un enfoque a otro y entre sistemas: se puede establecer conceptos de acoplamiento tanto

temporal como espacial que determinan como el receptor y el emisor coinciden o no en el

tiempo y en espacio.

    En la tabla 1 se plasman las posibles variantes en este tipo de enfoque. Por ejemplo,

las técnicas consideradas hasta ahora se basan en un acoplamiento directo o sistemas fuertemente

acoplado, como las arquitecturas clientes-servidor. Son arquitecturas acopladas en tiempo y espacio. Por otra parte, las aplicaciones como el correo electrónico, son arquitecturas desacopladas en tiempo y acopladas en espacio, ver descripción en la parte superior, derecha de la tabla 1.

Tabla 1. Acoplamiento en Espacio y Tiempo. Adaptado de [2]

    Mientras que la multidifusión puede catalogarse como arquitecturas acoplada en tiempo,

desacopladas en espacio, descrita en la parte inferior e izquierda de la tabla 1. Y las arquitecturas que calzan en la categoría de desacoplamiento en espacio y tiempo, como las arquitecturas Pub-sub y colas de mensajes, ubicada en la parte inferior, derecha.

Acoplamiento

    El acoplamiento se define como la fuerza de la interconexión entre dos módulos de software:

cuanto mayor es la fuerza de la interconexión, mayor es el acoplamiento. Para que el software sea más fácil de entender, corregir y mantener, un sistema debe estar dividido de modo que el acoplamiento entre los módulos sea lo más flojo o débil posible.

    Un sistema débilmente acoplado es aquel sistema donde  cada componente tiene poco o ningún conocimiento de las partes internas de los otros componentes. Por su parte,  el sistema tiene acoplamiento fuerte si cada componente de un sistema tiene conocimiento de partes de los otros componentes, como memoria común, almacenamiento secundario, entrada y salida de datos.

    El concepto de Acoplamiento fue propuesto por Yourdon y Constantine en su libro,

Structured Design: Fundamentals of a Discipline of Computer Program and Systems

Design.

Bibliografia:

[1] M van Steen and A.S. Tanenbaum. Distributed Systems. Edited by Pearson Prentice

Hall. Third. distributed-systems.net, 2017 

[2]  George Coulouris et al. Distributed Systems: Concepts and Design. 5th. USA:

Addison-Wesley Publishing Company, 2011. ISBN: 0132143011 

[3] Roberto Vitillo. Understanding Distributed Systems. 2021

Principios de Diseño de Sistemas Distribuidos

 Los principios de  diseño de Sistemas Distribuidos describe los objetivos que se deben tomar en cuenta cuando se diseña un sistema sistema distribuido. A continuación se describen.

•  Concurrencia. Tanto los servicios como las aplicaciones proporcionan recursos que los clientes pueden compartir en un sistema distribuido. Por tanto, existe la posibilidad de que varios clientes intenten acceder a un recurso compartido al mismo tiempo. La concurrencia se hace más compleja cuando existen  actividades paralelas que interactúan o comparten los mismos recursos. 

• Compartir Recursos.  Los recursos, como los  periféricos,  datos en bases de datos,  bibliotecas, así como los datos (variables/archivos),  no pueden replicar por completo en todos los sitios porque no resulta practico ni rentable. Estos recursos se distribuyen normalmente por todo el sistema, para que su acceso no se convierta en un potencial cuello de botella. 

• Transparencia.    El objetivo de la  transparencia es hacer que ciertos aspectos de la distribución sean invisibles para el programador de aplicaciones. Por ejemplo, no necesitan preocuparse por la ubicación o los detalles de cómo otros componentes acceden a sus operaciones, o si serán replicados o migrados. Incluso se pueden presentar fallas en la redes y procesos  en forma de excepciones, pero estas deben poder manejarse.  En el cuadro Tipos de transparencias, adaptado de [4],  se detallan los niveles de transparencia que se deben tomar en cuenta acompañado de su descripción.

                                Tipos de Transparencia.

Conceptos	Descripción
Acceso	Permitir el acceso con las mismas operaciones   de los recursos locales y remotos.
Ubicación	Que los recursos sean alcanzados  sin   conocer su ubicación física o de red.
Red	Combina ambas transparencias: en el acceso  y en  la ubicación.
Concurrencia	Permite que varios procesos operen  simultáneamente usando recursos compartidos  sin interferencia entre ellos.
Replicación	Permite que múltiples instancia de recursos  sean usados para aumentar  la confiabilidad  y    rendimiento sin que el usuario  de aplicaciones conozca de ellas.
Fallas	Ocultamiento de fallas, permitiendo que    usuarios y aplicaciones culminen sus tareas   sin percatarse de ellas.
Movilidad	Permite el movimiento de recursos y clientes  dentro del sistema  sin afectar la operación   de usuarios o programas..
Rendimiento	Permite que el sistema sea reconfigurado  para    mejorar el rendimiento cuando su carga varía.
Escalamiento	Permite que el sistema y la aplicación se    incremente sin cambios   en la estructura   del    sistema o en los algoritmos de aplicación.

•  Sistemas Abiertos.  Los  sistemas abiertos  son aquellos que  puede ampliarse e implementarse de varias formas. La apertura  está determinado principalmente por el grado en que los nuevos servicios de intercambio de recursos puede agregarse y estar disponible para su uso por una variedad de programas de cliente. Se caracterizan por el hecho de que sus interfaces son públicas; en otras palabras, las aplicaciones proveen un mecanismo de comunicación uniforme e interfaces  publicadas para el acceso a recursos compartidos. 

• Simplicidad.  Es importante que un diseño sea lo más simple posible y al mismo tiempo pueda satisfacer las necesidades del servicio ya que los sistemas crecen y se vuelven más complejos con el tiempo. Esto facilita su mantenimiento.

• Acoplamiento.  El grado de  acoplamiento  entre un conjunto de módulos, ya sea hardware o software, se mide en términos de la interdependencia y vinculación y/o homogeneidad entre los módulos. 

• Cuando el grado de acoplamiento es alto, se dice que los módulos están acoplados de manera ajustada o fuerte; por el contrario cuando el grado de acoplamiento es bajo, los módulos están acoplados de manera floja o débil.

• Un sistema  débilmente acoplado  facilita la sustitución o adicción de componentes  mientras  está en funcionamiento. Por el contrario, en  los sistemas   fuertemente acoplado  es necesario que se compartan recursos comunes, como la memoria central, almacenamiento secundario (disco) y entrada/salida a través de un bus común. 

El concepto de acoplamiento fue presentado por Edward Yourdon en  Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design, Yourdon, 1979. En Geeksforgeeks pueden ampliar las diferencias entre acoplamiento débil y fuerte

• Escalable. Un sistema se describe como escalable  si permanece efectivo cuando hay un aumento significativo en el número de recursos y el número de usuarios. El diseño de sistemas distribuidos escalable presenta los siguientes retos: 
• Controlar el costo de los recursos físicos.  Es posible ampliar un sistemas, a un costo razonable, a medida que crece la demanda de un recurso. 
• Controlar la pérdida de rendimiento. La gestión de un conjunto de datos cuyo tamaño debe ser proporcional al número de usuarios o recursos en el sistema, para evitar el congestionamiento en el acceso a los recursos y afectación del rendimiento. 
• Evitar cuellos de botella.  En general, los algoritmos deben estar descentralizados para evitar cuellos de botella.  
• Un ejemplo de un problema  con cuello de botella es el  predecesor del sistema de dominio de nombres  DNS , en el que la tabla de nombres se mantenía en un archivo maestro único que se podía descargar a cualquier computador. Esto estuvo bien cuando solo había unos pocos cientos de computadoras en internet. Luego  se eliminó este cuello de botella al dividir la tabla de nombres entre servidores ubicado en Internet y administrado localmente.  

• Heterogeneidad. Los sistemas distribuidos son heterogéneos, ya que se pueden construirse a partir de una variedad de redes, sistemas operativos, hardware informático y lenguajes de programación. Contemplar, por ejemplo, codigo movil o maquina virtual. El middleware se usa para ocultar estar diferencias y permitir la comunicación y administración de datos entre aplicaciones distribuidas. 

Bibliografia:

1. George Coulouris et al. Distributed Systems: Concepts and Design. 5th. USA: Addison-Wesley Publishing Company, 2011. ISBN: 0132143011
2. Paulo Veríssimo and Luís Rodrigues. Distributed Systems for System Architects. Advances in Distributed Computing and Middleware Ser. 1. Springer, 2012. ISBN: 9781461356660. 
3. Christina J. Hogan Thomas A. Limoncelli Strata R. Chalup. The Practice of Cloud System Administration: Designing and Operating Large Distributed Systems. Volume 2. Addison Wesley, 2014. ISBN: 032194318X 
4. M van Steen and A.S. Tanenbaum. Distributed Systems. Edited by Pearson Prentice Hall. Third. distributed-systems.net, 2017