S.E.
S.N.E.S.T
D.G.E.S.T
INSTITUTO TECNOLGICO
Del Istmo
ING. EN SISTEMAS COMPUTACIONALES.
CATEDRATICO:
Ing. Jos Antonio Lpez 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 Arquitectnicos
1.4. Arquitecturas en capas
1.5. Arquitecturas Centralizadas
1.6. Implementacin de aplicaciones en capas
1.7. Arquitecturas Descentralizadas
1.8. Arquitecturas Hibridas
1.9. Arquitectura vs Middleware.
EQUIPO:
Antonio Cruz Flor Dennis
12190283
Antonio Lpez Jos Francisco 12190
ndice
Cruz Mendoza Anselmo Enrique 12190
SEMESTRE: 8
GRUPO: o
Introduccin
1.1. Qu es una Arquitectura Distribuida
1.2. Prerrequisitos de una Arquitectura Distribuida
1.3. Estilos Arquitectnicos
1.4. Arquitecturas en capas
1.5. Arquitecturas Centralizadas
1.6. Implementacin de aplicaciones en capas
1.7. Arquitecturas Descentralizadas
1.8. Arquitecturas Hibridas
1.9. Arquitectura vs Middleware
INTRODUCCIN
En la actualidad los grandes sistemas de informacin son sistemas distribuidos, es
aqu donde se procesa informacin sobre varias computadoras. La ingeniera de
sistemas distribuidos tiene mucho en comn con la ingeniera de cualquier otro
software, pero existen cuestiones especficas que deben tenerse en cuenta
cuando se disea este tipo de sistemas. Un sistema distribuido es una coleccin
de ordenadores autnomos, enlazados por una red de ordenadores y soportados
por un software que hace que la coleccin acte como un servicio integrado. Para
ello tambin existen diversos estilos de arquitectura que ms adelante estarn
haciendo presencia en el desarrollo, as como cuales son los prerrequisitos para
llevar a cabo dicha distribucin de informacin.
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
clculo, de direcciones, etc. en la que el elemento de control se sita prximo 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 ubicacin fsica 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 fsicamente distribuidos no tienen
la capacidad de ubicar los procesos de control, que son ejecutados en uno o
varios procesadores fsicamente centralizados. (Arquitectura distribuida, 2012).
En los sistemas de arquitectura distribuida que utilizan como medio de transmisin
el cable, existe un concepto a tener en cuenta que es la topologa de la red de
comunicaciones. La topologa de la red se define como la distribucin fsica de los
elementos de control respecto al medio de comunicacin (cable). (Arquitectura
distribuida, 2012).
La arquitectura distribuida o informtica en malla es un nuevo modelo para
resolver problemas de computacin masiva utilizando un gran nmero de
ordenadores organizadas en racismos incrustados en una infraestructura de
Telecomunicaciones distribuidas. Cuando hace ms de 10 aos se cre el
concepto de redes de rea local (LAN) Que la mayora de las empresas utilizan
hoy en da, no se contaba con los poderosos equipos de cmputo que existen
actualmente, por esta razn 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 informacin, 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 ms que decir la arquitectura distribuida es un sistema lgico ordenado que se
encarga de conectar varios ordenadores. Es el sistema que conecta servidor -
cliente en tal forma que se pueda distribuir informacin en forma recproca.
(Arquitectura distribuida, 2012).
1.1.1.- Arquitectura distribuida Cliente/Servidor
La arquitectura cliente-servidor es un modelo de aplicacin 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 tambin se puede
aplicar a programas que se ejecutan sobre una sola computadora, aunque es ms
ventajosa en un sistema operativo multiusuario distribuido a travs de una red de
computadoras. (Arquitectura cliente- servidor, 2011).
Algunos ejemplos de aplicaciones computacionales que usen el modelo clienteservidor son el Correo electrnico, un Servidor de impresin y la World Wide Web.
La tecnologa Cliente/Servidor es el procesamiento cooperativo de la informacin
por medio de un conjunto de procesadores, en el cual mltiples clientes,
distribuidos geogrficamente, solicitan requerimientos a uno o ms servidores
centrales. (Arquitectura cliente- servidor, 2011).
Desde el punto de vista funcional, se puede definir la computacin Cliente/Servidor
como una arquitectura distribuida que permite a los usuarios finales obtener
acceso a la informacin de forma transparente an en entornos multiplataforma.
Se trata pues, de la arquitectura ms extendida en la realizacin de Sistemas
Distribuidos. (Arquitectura cliente- servidor, 2011).
Un sistema Cliente/Servidor es un Sistema de Informacin distribuido basado en
las siguientes caractersticas:
-
Servicio: unidad bsica de diseo. El servidor los proporciona y el cliente
los utiliza.
Recursos compartidos: Muchos clientes utilizan los mismos servidores y, a
travs de ellos, comparten tanto recursos lgicos como fsicos.
Protocolos asimtricos: Los clientes inician conversaciones.
servidores esperan su establecimiento pasivamente.
Los
Transparencia de localizacin fsica de los servidores y clientes: El cliente
no tiene por qu saber dnde se encuentra situado el recurso que desea
utilizar.
Independencia de la plataforma HW y SW que se emplee.
Sistemas dbilmente acoplados. Interaccin basada en envo de mensajes.
Encapsulamiento de servicios. Los detalles de la implementacin de un
servicio son transparentes al cliente.
Escalabilidad horizontal (aadir 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 terminologa
sajona basada en sistemas UNIX/LINUX, traducido como "demonio") se activa y
espera las solicitudes de los clientes. Habitualmente, programas cliente mltiples
comparten los servicios de un programa servidor comn. Tanto los programas
cliente como los servidores son con frecuencia parte de un programa o aplicacin
mayores. (Arquitectura cliente- servidor, 2011).
El Esquema de funcionamiento de un Sistema Cliente/Servidor sera:
-
El cliente solicita una informacin al servidor.
El servidor recibe la peticin del cliente.
El servidor procesa dicha solicitud.
El servidor enva 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 ms de un programa simultneamente.
-
Un sistema multitarea: Capaz de ejecutar sobre una misma mquina ms
de un programa a la vez.
Un sistema con ms de un ordenador: Donde cliente y servidor se ejecutan
sobre mquinas, y posiblemente sistemas operativos, diferentes.
La plataforma Internet: Donde el servicio se pide a travs de la red y se
suministra desde plataformas desconocidas para el cliente.
Un sistema de comunicacin 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 actualizacin o correccin
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 dbilmente acoplados. Es de lgica el
proporcionar independencia entre los servicios que se ofrecen.
Los servicios deben de procurar composicin. Esto se obtiene de la
orquestacin y le coreografa.
Los servicios no pueden tener un estado. Un servicio no puede guardar
informacin, dado que si lo hiciera no sera independiente y no se podra
asegurar su reutilizacin.
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) arquitectnicos
Iniciamos nuestra explicacin sobre arquitecturas considerando primero la
organizacin lgica de los sistemas distribuidos en componentes de software,
tambin conocida como arquitectura de software (Bass y cols., 2003). La
investigacin sobre arquitecturas de software ha madurado considerablemente, y
ahora es comn aceptar que el diseo o la adopcin de una arquitectura resultan
crucial para el desarrollo exitoso de sistemas grandes. Para nuestro estudio, la
idea de estilo arquitectnico es importante. Tal estilo se formula en trminos de
componentes, la forma en que los componentes interactan entre s, el
intercambio de datos entre los componentes y, por ltimo, en cmo 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 ms
adelante, la cuestin importante sobre un componente para sistemas distribuidos
es que pueda ser reemplazado, a condicin de respetar sus interfaces. Un
concepto de cierta manera ms difcil de entender es el de conector, el cual
generalmente se describe como un mecanismo que media la comunicacin,
coordinacin o cooperacin 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 arquitectnicos. Varios
estilos ya estn identificados y los ms 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 bsica 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 captulo 4. Una
observacin clave es que el control generalmente fluye de capa a capa: las
peticiones se mueven hacia abajo en la jerarqua mientras que los resultados se
mueven hacia arriba. Una organizacin 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 travs 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 an son los estilos ms
importantes utilizados para implementar grandes sistemas de software (Bass y
cols., 2003).
Cap.1.3. figure 2. estilos arquitectnicos (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 travs de un repositorio comn (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 travs de archivos. De manera similar, los sistemas distribuidos basados en la
web, que explicaremos ampliamente en el captulo 12, se centran bastante en
datos: los procesos se comunican a travs de servicios de datos compartidos
basados en la web. (Tanenbaum y Steen, 2008).
En las arquitecturas basadas en eventos, los procesos se comunican bsicamente
a travs de la propagacin de eventos, los que opcionalmente transportan datos,
como ilustra la figura 2-2(a). Para sistemas distribuidos, la propagacin de eventos
se ha asociado con lo que se conoce como sistemas de publicacin-suscripcin
(Eugster y cols., 2003). La idea bsica es que los procesos publican eventos
despus de los cuales el middleware asegura que slo aquellos procesos
suscritos a tales eventos los recibirn. La principal ventaja de los sistemas
basados en eventos es que los procesos estn libremente acoplados. En principio,
no necesitan referirse uno a otro explcitamente. A esto se le conoce tambin
como desacoplado en el espacio, o referencialmente desacoplado. (Tanenbaum y
Steen, 2008).
Cap. 1.3 Figura 3. Estilo arquitectnico (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 tambin estn desacoplados en el tiempo: no es necesario que
ambos estn activos cuando la comunicacin se lleva a cabo. Adems, 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 descripcin, en lugar de una referencia explcita, como en el caso
de los archivos. Dedicamos el captulo 13 a este estilo arquitectnico. 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 distribucin.
Sin embargo, como hemos explicado, la transparencia de distribucin requiere
negociar entre el rendimiento, la tolerancia a fallas, la facilidad de programacin,
etc. Como no existe una solucin 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).
Cuntos y cules son los estilos?
En un estudio realizado por Mary Shaw y David Garlan (Garlan, et al., 1994),
proponen la siguiente taxonoma, en la que se entremezclan lo que antes se
llamaba arquitecturas con los modelos de diseo:
1.
Tubera-filtros
2.
Organizacin de abstraccin de datos y orientacin a objetos
3.
Invocacin implcita, basada en eventos
4.
Sistemas en capas
5.
Repositorios
6.
Intrpretes 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 especficas de dominio
10.
Sistemas de transicin de estado
11.
Sistemas de procesos de control
12.
Estilos heterogneos
En Software Architecture in Practice, un texto fundamental de Bass, Clements y
Kazman (Bass, et al., 1998), se proporciona una sistematizacin 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
Tubera-filtros
Llamado y retorno (estilo dominado por orden de computacin, 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 comunicacin
entre procesos independientes, casi siempre concurrentes)
Sistemas orientados por eventos
Procesos de comunicacin
Centrados en datos (dominado por un almacenamiento central complejo,
manipulado por computaciones independientes)
-
Repositorio
Pizarra
Mquina virtual (caracterizado por la traduccin de una instruccin en
alguna otra)
-
Intrprete
Los estilos a diferencia de patrones son unos pocos, y se agrupan en clases de
estilos, siendo la clasificacin ms actual, concisa y que se asume durante la
investigacin la siguiente (Reynoso, 2005):
Estilos de Flujo de Datos
-
Estilos de Llamada y Retorno
-
Arquitectura de Mquinas Virtuales
Estilos heterogneos
-
Model-View-Controller (MVC)
Arquitecturas en Capas
Arquitecturas Orientadas a Objetos
Arquitecturas Basadas en Componentes
Estilos de Cdigo Mvil
-
Tubera 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
Bibliografa
Andrew S. Tanenbaum y Maarten Van Steen, (2008). Sistemas distribuidos
principios y paradigma. (2 edicin). 53519, Naucalpan de Jurez, Estado de
Mxico. PEARSON EDUCACIN.
Internet
Arquitectura distribuida. (s.f.).Recuperado el 29 de enero de 2016, de
http://www.buenastareas.com/ensayos/ArquitecturaDistribuida/3663000.html
