investigacionDescripción completa
Views 147 Downloads 1 File size 723KB
S.E.P
S.N.E.S.T
D.G.E.S.T
INSTITUTO TECNOLÓGICO Del Istmo
ING. EN SISTEMAS COMPUTACIONALES. CATEDRATICO: Ing. José Antonio López Posada
MATERIA: Arquitectura de sistemas distribuidos
TEMA:
FUNDAMENTOS DE ARQUITECTURA DISTRIBUIDA SUBTEMAS: 1.1. Qué es una Arquitectura Distribuida 1.2. Prerrequisitos de una Arquitectura Distribuida 1.3. Estilos Arquitectónicos 1.4. Arquitecturas en capas 1.5. Arquitecturas Centralizadas 1.6. Implementación de aplicaciones en capas 1.7. Arquitecturas Descentralizadas 1.8. Arquitecturas Hibridas 1.9. Arquitectura vs Middleware. EQUIPO: Antonio Cruz Flor Dennis
12190283
Antonio López José Francisco 12190
Índice
Cruz Mendoza Anselmo Enrique 12190 SEMESTRE: “8”
GRUPO: “o”
Introducción 1.1. Qué es una Arquitectura Distribuida 1.2. Prerrequisitos de una Arquitectura Distribuida 1.3. Estilos Arquitectónicos 1.4. Arquitecturas en capas 1.5. Arquitecturas Centralizadas 1.6. Implementación de aplicaciones en capas 1.7. Arquitecturas Descentralizadas 1.8. Arquitecturas Hibridas 1.9. Arquitectura vs Middleware
INTRODUCCIÓN
En la actualidad los grandes sistemas de información son sistemas distribuidos, es aquí donde se procesa información sobre varias computadoras. La ingeniería de sistemas distribuidos tiene mucho en común con la ingeniería de cualquier otro software, pero existen cuestiones específicas que deben tenerse en cuenta cuando se diseña este tipo de sistemas. Un sistema distribuido es una colección de ordenadores autónomos, enlazados por una red de ordenadores y soportados por un software que hace que la colección actúe como un servicio integrado. Para ello también existen diversos estilos de arquitectura que más adelante estarán haciendo presencia en el desarrollo, así como cuales son los prerrequisitos para llevar a cabo dicha distribución de información.
1.- Fundamentos de Arquitecturas Distribuidas
1.1.-Que es la arquitectura distribuida Son sistemas multiprocesadores en los que las diferentes funciones del sistema se encuentran distribuidas en procesadores especializados: de instrucciones, de cálculo, de direcciones, etc. en la que el elemento de control se sitúa próximo al elemento a controlar. (Arquitectura distribuida, 2012). Hay sistemas que son de arquitectura distribuida en cuanto a la capacidad de proceso, pero no lo son en cuanto a la ubicación física de los diferentes elementos de control y viceversa. Los sistemas que son de arquitectura distribuida en cuanto a su capacidad para ubicar elementos de control físicamente distribuidos no tienen la capacidad de ubicar los procesos de control, que son ejecutados en uno o varios procesadores físicamente centralizados. (Arquitectura distribuida, 2012). En los sistemas de arquitectura distribuida que utilizan como medio de transmisión el cable, existe un concepto a tener en cuenta que es la topología de la red de comunicaciones. La topología de la red se define como la distribución física de los elementos de control respecto al medio de comunicación (cable). (Arquitectura distribuida, 2012). La arquitectura distribuida o informática en malla es un nuevo modelo para resolver problemas de computación masiva utilizando un gran número de ordenadores organizadas en racismos incrustados en una infraestructura de Telecomunicaciones distribuidas. Cuando hace más de 10 años se creó el concepto de redes de área local (LAN) Que la mayoría de las empresas utilizan hoy en día, no se contaba con los poderosos equipos de cómputo que existen actualmente, por esta razón y para no saturar la capacidad de los equipos servidores, las aplicaciones de bases de datos, no solo las que utilizan archivos DBF, utilizaban el CPU de los PC Terminales, para procesar la información, este modelo,
llamado arquitectura
distribuida no
ha
cambiado
desde
que
se
implementaron las primeras LANS y se mantiene sin cambios a la fecha, sin importar situ Red es Novell, NT/2000/2003, o Windows 9x/ME/XP punto a punto. Sin más que decir la arquitectura distribuida es un sistema lógico ordenado que se encarga de conectar varios ordenadores. Es el sistema que conecta servidor -
cliente en tal forma que se pueda distribuir información en forma recíproca. (Arquitectura distribuida, 2012). 1.1.1.- Arquitectura distribuida Cliente/Servidor La arquitectura cliente-servidor es un modelo de aplicación distribuida en el que las tareas se reparten entre los proveedores de recursos o servicios, llamados servidores, y los demandantes, llamados clientes. Un cliente realiza peticiones a otro programa, el servidor, quien le da respuesta. Esta idea también se puede aplicar a programas que se ejecutan sobre una sola computadora, aunque es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras. (Arquitectura cliente- servidor, 2011). Algunos ejemplos de aplicaciones computacionales que usen el modelo clienteservidor son el Correo electrónico, un Servidor de impresión y la World Wide Web. La tecnología Cliente/Servidor es el procesamiento cooperativo de la información por medio de un conjunto de procesadores, en el cual múltiples clientes, distribuidos geográficamente, solicitan requerimientos a uno o más servidores centrales. (Arquitectura cliente- servidor, 2011). Desde el punto de vista funcional, se puede definir la computación Cliente/Servidor como una arquitectura distribuida que permite a los usuarios finales obtener acceso a la información de forma transparente aún en entornos multiplataforma. Se trata pues, de la arquitectura más extendida en la realización de Sistemas Distribuidos. (Arquitectura cliente- servidor, 2011). Un sistema Cliente/Servidor es un Sistema de Información distribuido basado en las siguientes características: -
Servicio: unidad básica de diseño. El servidor los proporciona y el cliente
-
los utiliza. Recursos compartidos: Muchos clientes utilizan los mismos servidores y, a
-
través de ellos, comparten tanto recursos lógicos como físicos. Protocolos asimétricos: Los clientes inician “conversaciones”. servidores esperan su establecimiento pasivamente.
Los
-
Transparencia de localización física de los servidores y clientes: El cliente no tiene por qué saber dónde se encuentra situado el recurso que desea
-
utilizar. Independencia de la plataforma HW y SW que se emplee. Sistemas débilmente acoplados. Interacción basada en envío de mensajes. Encapsulamiento de servicios. Los detalles de la implementación de un
-
servicio son transparentes al cliente. Escalabilidad horizontal (añadir clientes) y vertical (ampliar potencia de los
-
servidores). Integridad: Datos y programas centralizados en servidore s facilitan su integridad y mantenimiento.
En el modelo usual Cliente/Servidor, un servidor, (daemon en la terminología sajona basada en sistemas UNIX/LINUX, traducido como "demonio") se activa y espera las solicitudes de los clientes. Habitualmente, programas cliente múltiples comparten los servicios de un programa servidor común. Tanto los programas cliente como los servidores son con frecuencia parte de un programa o aplicación mayores. (Arquitectura cliente- servidor, 2011). El Esquema de funcionamiento de un Sistema Cliente/Servidor sería: -
El cliente solicita una información al servidor. El servidor recibe la petición del cliente. El servidor procesa dicha solicitud. El servidor envía el resultado obtenido al cliente. El cliente recibe el resultado y lo procesa.
1.2.- Prerrequisitos de una Arquitectura Distribuida Prerrequisitos de una Arquitectura Distribuida Cliente/Servidor: Capacidad de ejecutar más de un programa simultáneamente. -
Un sistema multitarea: Capaz de ejecutar sobre una misma máquina más
-
de un programa a la vez. Un sistema con más de un ordenador: Donde cliente y servidor se ejecutan
-
sobre máquinas, y posiblemente sistemas operativos, diferentes. La plataforma Internet: Donde el servicio se pide a través de la red y se suministra desde plataformas desconocidas para el cliente.
-
Un sistema de comunicación y de intercambio de mensajes entre programas: Sobre el que se montará el transportista. Por ejemplo, una
-
plataforma TCP/IP. Potencia de proceso en los clientes en las aplicaciones basadas en sistema operativo. (sistemas distribuidos, 2010).
Una arquitectura basada en SOA tiene que cumplir los siguientes prerrequisitos: -
Los servicios tienen que ser reutilizables: con esto se ganan “costes de tiempo” al no tener que recodificar todo para una actualización o corrección
-
software. Los servicios deben proporcionar un contrato formal: en todo momento se deben tener claro el nombre del servicio al que se accede, funciones que
-
procura y datos de entrada y salida ofrece el servicio. Los servicios deben de estar débilmente acoplados. Es de lógica el
-
proporcionar independencia entre los servicios que se ofrecen. Los servicios deben de procurar “composición”. Esto se obtiene de la
-
orquestación y le coreografía. Los servicios no pueden tener un estado. Un servicio no puede guardar información, dado que si lo hiciera no sería independiente y no se podría
-
asegurar su reutilización. Los servicios deben ser descubiertos para poder ser utilizados o consumidos. Para poder conseguir tal fin se usara UDDI (que publica las interfaces de los servicios en dicho mecanismo). (Desarrollo de aplicaciones distribuidas, 2014).
Cap.1.2 Figura 1. Estructura general de una arquitectura SOA
1.3 Estilos (modelos) arquitectónicos Iniciamos nuestra explicación sobre arquitecturas considerando primero la organización lógica de los sistemas distribuidos en componentes de software, también conocida como arquitectura de software (Bass y cols., 2003). La investigación sobre arquitecturas de software ha madurado considerablemente, y ahora es común aceptar que el diseño o la adopción de una arquitectura resultan crucial para el desarrollo exitoso de sistemas grandes. Para nuestro estudio, la idea de estilo arquitectónico es importante. Tal estilo se formula en términos de componentes, la forma en que los componentes interactúan entre sí, el intercambio de datos entre los componentes y, por último, en cómo es que estos elementos se configuran juntos en un sistema. Un componente es una unidad modular con las interfaces requeridas bien definidas; dicha unidad es reemplazable dentro de su ambiente (OMG, 2004b). Tal como explicaremos más adelante, la cuestión importante sobre un componente para sistemas distribuidos es que pueda ser reemplazado, a condición de respetar sus interfaces. Un concepto de cierta manera más difícil de entender es el de conector, el cual generalmente se describe como un mecanismo que media la comunicación, coordinación o cooperación entre componentes (Mehta y cols., 2000; y Shaw y Clements, 1997). Por ejemplo, un conector puede formarse por los medios disponibles para hacer llamadas a procedimientos (remotos), paso de mensajes, o flujo de datos. Por medio de componentes y conectores podemos lograr varias configuraciones, las cuales se han clasificado en estilos arquitectónicos. Varios estilos ya están identificados y los más importantes para sistemas distribuidos son: 1. Arquitecturas en capas. 2. Arquitecturas basadas en objetos. 3. Arquitecturas centradas en datos. 4. Arquitecturas basadas en eventos.
La idea básica para el estilo en capas es sencilla: los componentes se estructuran (organizan) a modo de capas, donde al componente de la capa Li se le permite llamar a componentes de la capa subyacente Li1, pero no del resto de capas, como ilustra la figura 2-1(a). Este estilo se ha adopta- do ampliamente en la comunidad de redes, y lo revisaremos brevemente en el capítulo 4. Una observación clave es que el control generalmente fluye de capa a capa: las peticiones se mueven hacia abajo en la jerarquía mientras que los resultados se mueven hacia arriba. Una organización bastante libre es la que siguen las arquitecturas basadas en objetos, la cual aparece en la figura 2-1(b). En esencia, cada objeto corresponde a lo que hemos definido como componente, y estos componentes se conectan a través de un mecanismo de llamadas a procedimientos (remotos). Sin ser sorprendente, esta arquitectura de software coincide con la arquitectura de sistemas cliente-servidor que describimos antes. La arquitectura basada en capas y la basada en objetos aún son los estilos más importantes utilizados para implementar grandes sistemas de software (Bass y cols., 2003).
Cap.1.3. figure 2. estilos arquitectónicos (a) en capas y (b) basado en objetos.
Las arquitecturas centradas en datos evolucionaron alrededor de la idea de que los procesos se comunican a través de un repositorio común (activo o pasivo). Se puede argumentar que, para sistemas distribuidos, estas arquitecturas son tan importantes como las basadas en capas y objetos. Por ejemplo, un punto a favor que han desarrollado las aplicaciones en red es que se basan en un sistema de
archivos distribuidos compartidos donde casi todas las comunicaciones se realizan a través de archivos. De manera similar, los sistemas distribuidos basados en la web, que explicaremos ampliamente en el capítulo 12, se centran bastante en datos: los procesos se comunican a través de servicios de datos compartidos basados en la web. (Tanenbaum y Steen, 2008).
En las arquitecturas basadas en eventos, los procesos se comunican básicamente a través de la propagación de eventos, los que opcionalmente transportan datos, como ilustra la figura 2-2(a). Para sistemas distribuidos, la propagación de eventos se ha asociado con lo que se conoce como sistemas de publicación-suscripción (Eugster y cols., 2003). La idea básica es que los procesos publican eventos después de los cuales el middleware asegura que sólo aquellos procesos suscritos a tales eventos los recibirán. La principal ventaja de los sistemas basados en eventos es que los procesos están libremente acoplados. En principio, no necesitan referirse uno a otro explícitamente. A esto se le conoce también como desacoplado en el espacio, o referencialmente desacoplado. (Tanenbaum y Steen, 2008).
Cap. 1.3 Figura 3. Estilo arquitectónico (a) basado en eventos, y (b) espacio de datos compartidos
Las arquitecturas basadas en eventos pueden combinarse con arquitecturas centradas en datos, y arrojan lo que conocemos como espacios de datos compartidos. La esencia de los espacios de datos compartidos es que los procesos ahora también están desacoplados en el tiempo: no es necesario que
ambos estén activos cuando la comunicación se lleva a cabo. Además, muchos espacios de datos compartidos utilizan una interfaz similar a la SQL para el repositorio compartido en el sentido de que es posible acceder a los datos utilizando una descripción, en lugar de una referencia explícita, como en el caso de los archivos. Dedicamos el capítulo 13 a este estilo arquitectónico. Lo que hace importantes a estas arquitecturas de software para los sistemas distribuidos es que todas intentan lograr (a un nivel razonable) la transparencia de distribución. Sin embargo, como hemos explicado, la transparencia de distribución requiere negociar entre el rendimiento, la tolerancia a fallas, la facilidad de programación, etc. Como no existe una solución única que satisfaga todos los requerimientos para todas las aplicaciones distribuidas, los investigadores han abandonado la idea de que un solo sistema distribuido pueda utilizarse para cubrir el 90 por ciento de todos los casos posibles. (Tanenbaum y Steen, 2008).
¿Cuántos y cuáles son los estilos? En un estudio realizado por Mary Shaw y David Garlan (Garlan, et al., 1994), proponen la siguiente taxonomía, en la que se entremezclan lo que antes se llamaba “arquitecturas” con los “modelos de diseño”:
1.
Tubería-filtros
2.
Organización de abstracción de datos y orientación a objetos
3.
Invocación implícita, basada en eventos
4.
Sistemas en capas
5.
Repositorios
6.
Intérpretes orientados por tablas
7.
Procesos distribuidos. Una forma particular de proceso distribuido es, por
ejemplo, la arquitectura cliente-servidor.
8.
Organizaciones programa principal / subrutina.
9.
Arquitecturas de software específicas de dominio
10.
Sistemas de transición de estado
11.
Sistemas de procesos de control
12.
Estilos heterogéneos
En Software Architecture in Practice, un texto fundamental de Bass, Clements y Kazman (Bass, et al., 1998), se proporciona una sistematización de clases de estilo en cinco grupos: •
Flujo de datos (movimiento de datos, sin control del receptor de lo que viene
“corriente arriba”) •
Proceso secuencial por lotes Red de flujo de datos Tubería-filtros Llamado y retorno (estilo dominado por orden de computación, usualmente
con un solo thread de control) Programa principal / Subrutinas •
Tipos de dato abstracto Objetos Cliente-servidor basado en llamadas Sistemas en capas
Componentes independientes (dominado por patrones de comunicación
entre procesos independientes, casi siempre concurrentes) •
Sistemas orientados por eventos Procesos de comunicación
Centrados en datos (dominado por un almacenamiento central complejo,
manipulado por computaciones independientes) -
Repositorio Pizarra
•
Máquina virtual (caracterizado por la traducción de una instrucción en
alguna otra) -
Intérprete
Los estilos a diferencia de patrones son unos pocos, y se agrupan en clases de estilos, siendo la clasificación más actual, concisa y que se asume durante la investigación la siguiente (Reynoso, 2005): •
Estilos de Flujo de Datos -
•
Estilos de Llamada y Retorno -
•
Arquitectura de Máquinas Virtuales
Estilos heterogéneos -
•
Model-View-Controller (MVC) Arquitecturas en Capas Arquitecturas Orientadas a Objetos Arquitecturas Basadas en Componentes
Estilos de Código Móvil -
•
Tubería y filtros Estilos Centrados en Datos Arquitecturas de Pizarra o Repositorio
Sistemas de control de procesos Arquitecturas Basadas en Atributos
Estilos Peer-to-Peer -
Arquitecturas Basadas en Eventos Arquitecturas Orientadas a Servicios (SOA) Arquitecturas Basadas en Recursos
FUENTES CONSULTADAS
Bibliografía
Andrew S. Tanenbaum y Maarten Van Steen, (2008). Sistemas distribuidos principios y paradigma. (2° edición). 53519, Naucalpan de Juárez, Estado de México. PEARSON EDUCACIÓN. Internet
-
Arquitectura distribuida. (s.f.).”Recuperado el 29 de enero de 2016, de http://www.buenastareas.com/ensayos/ArquitecturaDistribuida/3663000.html