1. Estilos
1.1. El estilo se formula en términos de componentes, los cuales están conectados entre sí intercambiando los datos entre componentes para configurarse conjuntamente en un sistema
1.1.1. Componente
1.1.1.1. Es una unidad modular con interfaces requeridas y proporcionadas bien definidas las cuales pueden ser remplazadas dentro de su entorno.
1.1.1.2. Puede ser remplazado mientras el sistema continúa funcionando
1.1.2. Conector
1.1.2.1. Mecanismo que media la comunicación, coordinación y cooperación entre los componentes
1.1.2.2. Permite el flujo de control y datos entre componentes
1.2. Utilizando componentes y conectores se puede llegar a varias configuraciones
1.2.1. Arquitectura de capas
1.2.1.1. Los componentes se organizan en forma de capas donde un componente de una capa puede llamar de forma descendente a un componente en una capa de nivel inferior.
1.2.1.2. Existen tres casos comunes
1.2.1.2.1. Organización de capas pura
1.2.1.2.2. Organización de capas Mixta
1.2.1.2.3. Organización de capas con llamadas ascendentes
1.2.1.3. Protocolos de comunicación en capas
1.2.1.3.1. Una arquitectura en capas bien conocida son las llamadas pilas de protocolos de comunicación
1.2.1.3.2. Capas de Aplicación
1.2.2. Arquitectura orientada a objetos y orientada a servicios
1.2.2.1. Se sigue una organización mucho más flexible
1.2.2.2. Cada objeto corresponde a lo que hemos definido como componente, y estos componentes están conectados a través de un mecanismo de llamada a procedimiento
1.2.2.3. una llamada a procedimiento también puede tener lugar a través de una red
1.2.2.3.1. El objeto que llama no necesita ser ejecutado en la misma máquina que el objeto llamado
1.2.2.3.2. Estados del objeto
1.2.2.3.3. métodos de un objeto
1.2.3. Arquitecturas basadas en recursos
1.2.3.1. Uno de los problemas con la composición del servicio es que conectar varios componentes puede convertirse fácilmente en una pesadilla de integración.
1.2.3.2. Se puede ver un sistema distribuido como una gran colección de recursos que son administrados individualmente por componente
1.2.3.3. Aplicaciones remotas
1.2.3.3.1. Pueden agregar o eliminar recursos y, de la misma forma, pueden recuperarse o modificarse
1.2.4. Arquitecturas de publicación y suscripción
1.2.4.1. La idea es ver un sistema como una colección de procesos que operan de forma autónoma.
1.2.4.2. La coordinación se lleva a cabo de manera directa, lo que se conoce como coordinación directa
1.2.4.2.1. Los procesos que se están comunicando tendrán que estar en funcionamiento
1.2.4.3. Coordinación de buzones
1.2.4.3.1. no es necesario que se estén ejecutando dos procesos de comunicación al mismo tiempo
1.2.4.3.2. La comunicación se lleva a cabo poniendo los mensajes en un buzón
2. Middleware organization
2.1. la organización real del middleware, independiente de la organización general de un sistema distribuido o una aplicación se divide en dos:
2.1.1. Lo que ofrecen los contenedores e interceptores son medios para ampliar y adaptar el middleware.
2.1.2. 1. Wrappers - envoltorios
2.1.2.1. Es un componente especial que ofrece una interfaz aceptable para una aplicación cliente, cuyas funciones se transforman en las disponibles en el componente. En esencia, resuelve el problema de las interfaces incompatibles
2.1.2.2. transformadores de interfaz
2.1.2.3. disminuir la implemantacion de wrappers se realiza a travez de un broker
2.1.2.3.1. Broker
2.1.3. 2. Interceptors - interceptores
2.1.3.1. Es un medio principal para adaptar el middleware a las necesidades específicas de una aplicación.
2.1.3.2. tener solo instalaciones de interceptación limitadas mejorará la gestión del software y del sistema distribuido en su conjunto
2.1.3.3. interceptación =compatible con muchos sistemas distribuidos basados en objetos
2.1.3.4. invocación de objeto, en tres pasos:
2.1.3.4.1. 1. Objeto A se ofrece una interfaz local que es exactamente la misma que la interfaz rostro ofrecido por objeto B. A llama al método disponible en esa interfaz
2.1.3.4.2. 2. La llamada de A se transforma en una invocación de objeto genérico, posible a través de una interfaz de invocación de objeto general ofrecida por el middleware en la máquina donde A reside
2.1.3.4.3. 3. Finalmente, la invocación del objeto genérico se transforma en un mensaje que se envía a través de la interfaz de red a nivel de transporte ofrecida por A sistema operativo local.
2.2. Modifiable middleware
2.2.1. deberíamos poder modificarlo intencionalmente sin dejarlo de funcionar
2.2.1.1. A medida que aumenta el tamaño de un sistema distribuido, rara vez se pueden cambiar sus partes apagándolo temporalmente. Lo que se necesita es poder hacer cambios sobre la marcha.
2.2.2. Diseño en componentes
2.2.2.1. se enfoca en apoyar la modificabilidad a través de la composición
2.2.2.2. sigue siendo complejo el proceso de seleccionar automáticamente la mejor implementación de un componente durante el tiempo de ejecución para los sistemas distribuidos, especialmente cuando se considera que el reemplazo de un componente requiere saber exactamente cuál es el efecto de ese reemplazo.
2.2.2.3. necesitamos al menos soporte básico para cargar y descargar componentes en tiempo de ejecución
3. Arquitectura del sistema
3.1. Organizacion centralizada
3.1.1. Pensar en términos de clientela que solicitan servicios de servidores
3.1.2. Arquitectura simple Cliente -Servidor
3.1.2.1. Se dividen en procesos
3.1.2.1.1. Cliente
3.1.2.1.2. Servidor
3.1.2.2. comportamiento de solicitud-respuesta
3.1.2.2.1. comunicación : cliente-servidor utilizan un protocolo orientado a la conexión confiable
3.1.3. Arquitectura de varios niveles
3.1.3.1. Estas se puden distribuir entre las dos maquinas de diferentes maneras , todo depende de que sea lo mas conveniente
3.1.3.2. Partir de la existencia en una estructura donde solo hay dos maquinas, cliente y servidor
3.1.3.3. Arquitectura de tres niveles
3.1.3.3.1. Se distribuye ,las tres partes escenciales , la interfaz del usuario, la aplicación y la base de datos.
3.1.3.3.2. Es habitual encontrar esta arquitectura en la organización de los sitios web
3.2. Organizacion descentralizada :peer to peer systems
3.2.1. clase de arquitecturas de sistemas modernas que admiten la distribución horizontal
3.2.2. las funciones que deben llevarse a cabo están representadas por cada proceso que constituye el sistema distribuido
3.2.2.1. Como consecuencia, gran parte de la interacción entre procesos es simétrica
3.2.3. cada proceso actuará como cliente y servidor al mismo tiempo
3.2.4. Las arquitecturas peer-to-peer evolucionan en torno a la cuestión de cómo organizar los procesos en una red superpuesta
3.2.4.1. Donde los nodos están formados por los procesos
3.2.4.2. Los enlaces representan los posibles canales de comunicación
3.2.4.3. Existen dos tipos de redes superpuestas
3.2.4.4. Estructuradas
3.2.4.4.1. están organizados en una superposición que se adhiere a una topología específica
3.2.4.4.2. Esta topología es utilizado para buscar datos de manera eficiente
3.2.4.4.3. Se caracterizan generalmente por que se basan en el uso de un índice llamado libre de semántica
3.2.4.5. No estructuradas
3.2.4.5.1. cada nodo mantiene una lista ad hoc de vecinos
3.2.4.5.2. cuando un nodo se une, a menudo se pone en contacto con un nodo conocido para obtener una lista inicial de otros pares en el sistema
3.2.4.5.3. la búsqueda de datos no puede seguir una ruta predeterminada cuando las listas de vecinos se construyen de forma ad hoc
3.3. Arquitectura hibrida
3.3.1. cliente-servidor se combinan con arquitecturas descentralizadas.
3.3.1.1. se despliegan notablemente en sistemas distribuidos colaborativos
3.3.2. Sistemas de servidor de borde
3.3.2.1. Se implementa en internet
3.3.2.2. Los usuarios finales, o los clientes en general, se conectan a Internet mediante un servidor perimetral
3.3.2.3. Proposito
3.3.2.3.1. Servir contenido, posiblemente después de aplicar funciones de filtrado y transcodificación
3.3.2.4. Ejemplos
3.3.2.4.1. nube
3.3.2.4.2. niebla
3.3.3. Sistemas distribuidos colaborativos
3.3.3.1. BitTorrent
3.3.3.1.1. es un sistema de descarga de archivos de igual a igual.
3.3.3.1.2. combina soluciones centralizadas con descentralizadas
4. Arquitecturas de ejemplo
4.1. Sistema de archivos de red
4.1.1. NFS
4.1.1.1. Cada servidor de archivos proporciona una vista estandarizada de su sistema de archivos local.
4.1.1.1.1. cada servidor NFS admite el mismo modelo
4.1.1.2. Protocolo de comunicación
4.1.1.2.1. Permite a los clientes acceder a los archivos almacenados en un servidor, lo que permite que una colección heterogénea de procesos, posiblemente ejecutándose en diferentes sistemas operativos y máquinas, compartan un sistema de archivos común
4.1.2. Servicio de archivo remoto
4.1.2.1. los clientes normalmente desconocen la ubicación real de los archivos.
4.1.2.2. los clientes normalmente desconocen la ubicación real de los archivos.
4.1.2.3. Modelo de acceso remoto
4.1.3. Modelo de carga / descarga
4.1.3.1. Pasos
4.1.3.1.1. 1.Un cliente accede a un archivo localmente después de haberlo descargado del servidor
4.1.3.1.2. 2Cuando el cliente termina con el archivo, se vuelve a cargar en el servidor para que pueda ser utilizado por otro cliente. .
4.1.3.2. Servicio FTP
4.1.3.2.1. Descargar, editar y volver a subir en internet.
4.1.4. La web
4.1.4.1. Documentos dinamicos
4.1.4.2. Sistemas sencillos basados en web
4.1.4.2.1. URL
4.1.4.2.2. HTTP
4.1.4.2.3. HTML
4.1.4.2.4. Javascript
4.1.4.3. Arquitectura de varios niveles
4.1.4.3.1. Interfaz de entrada común CGI