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