37

Capítulo 3. Modelos de arquitecturas

Objetivo: Que el alumno comprenda los diferentes paradigmas de cómpu-

to, desde el cliente-servidor al grid, y cómo se integran en los modelos ar-
quitectónicos de los sistemas distribuidos.

3.1 Introducción

La arquitectura de un sistema es su estructura en términos de los compo-

nentes especificados por separado y sus interrelaciones. El objetivo de una
arquitectura general es asegurar que la estructura reunirá presentes y pro-
bables futuras demandas sobre el mismo. Las principales preocupaciones
son que el sistema sea fiable, manejable, adaptable y rentable [Coulouris et
al., 2012]. La arquitectura de un sistema distribuido guarda algunos aspectos
similares con el diseño arquitectónico de un edificio, los cuales determinan
no solo su apariencia, sino también su estructura general y el estilo arqui-
tectónico (gótico, neoclásico y moderno) y proporciona un marco coherente
de referencia para el diseño. Todos los tipos de sistemas distribuidos tienen
características básicas comunes. Un modelo de arquitectura es una descrip-
ción abstracta simplificada pero consistente de cada aspecto relevante del
diseño de un sistema distribuido. Este capítulo describe los principales mo-
delos arquitectónicos de los sistemas distribuidos, particularmente en pa-
radigmas cliente-servidor, peer-to-peer, grid, proxy, cluster y las principales
diferencias entre estos.

3.2 Modelo cliente - servidor

El modelo cliente-servidor es la arquitectura más citada cuando se discuten

los sistemas distribuidos. Es el modelo más importante y sigue siendo el más
38 Sistemas distribuidos

ampliamente utilizado. La figura 3.1 ilustra la estructura simple de esta arqui-

tectura, en la cual los procesos toman el rol de ser clientes o servidores. En
particular, los procesos de cliente interactúan con los procesos de servidor
individuales en equipos anfitriones (host) potencialmente separados, con el
fin de acceder a los recursos compartidos que administran.

Figura 3.1. Ejemplo de una estructura simple cliente-servidor

El modelo cliente-servidor puede tomar diferentes configuraciones. Por

ejemplo, puede existir más de un cliente conectado a un servidor, como se
indica en la figura 3.2. También se puede tener un grupo de servidores inter-
conectados dedicados a dar servicio a un grupo de clientes. Este escenario
se indica en la figura 3.3.

Figura 3.2. Ejemplo de estructura cliente-servidor para dos clientes

Modelos de arquitecturas 39

Figura 3.3. Grupo de servidores interconectados

basado en el modelo cliente-servidor

3.3 Proxy

Es un servidor que se emplea como intermediario entre las peticiones de re-

cursos que realiza un cliente a otro servidor. Por ejemplo, si una computadora
A solicita un recurso a una computadora C, lo hará mediante una petición a la
computadora B que, a su vez, trasladará la petición a la computadora C. De
esta manera, la computadora C no sabrá que la petición procedió original-
mente de la computadora A. Esta situación estratégica de punto intermedio
suele ser aprovechada para soportar una serie de funcionalidades, como:

• Proporcionar caché.
• Control de acceso.
• Registro del tráfico.
• Prohibir cierto tipo de tráfico.
• Mejorar el rendimiento.
• Mantener el anonimato.

El proxy más conocido es el servidor proxy web, su función principal es

interceptar la navegación de los clientes por páginas web por motivos de se-
guridad, rendimiento, anonimato, entre otros. Las figuras 3.4 y 3.5 muestran
dos ejemplos del uso de proxy.
40 Sistemas distribuidos

Figura 3.4. Arreglo de proxy cliente y proxy servidor

para acceder al servidor desde dos clientes

Figura 3.5. Acceso a servidores web vía un proxy

3.4 Peer-to-Peer

El paradigma peer-to-peer (P2P) ha sido un tema muy atractivo para muchos

investigadores de diferentes áreas, tales como redes, sistemas distribuidos,
teoría de la complejidad, bases de datos y otros.
En el modelo cliente-servidor tradicional, dos tipos de nodos son em-
pleados: clientes y servidores. En este contexto, los clientes solo solicitan
servicios y el servidor solo proporciona a los clientes el servicio apropiado.
Un servidor puede aceptar varias solicitudes, procesarlas y devolver los con-
tenidos solicitados a los clientes. En la Internet actual, los clientes incluyen
navegadores web, clientes de chat en línea y clientes de correo electróni-
co, mientras que los servidores normalmente son servidores web, servidores
FTP y servidores de correo.
En contraste, en los sistemas P2P no se requiere una infraestructura dedica-
da. Los servidores dedicados y clientes no existen, ya que cada peer puede to-
mar el papel tanto de servidor como de cliente al mismo tiempo. Una ventaja
Modelos de arquitecturas 41

importante de los sistemas peer-to-peer es que todos los recursos disponibles

son proporcionados por los peers. Durante la distribución de un contenido,
los peers aportan sus recursos para transmitir el contenido a los demás peers.
Por lo tanto, cuando un nuevo peer se agrega al sistema al sistema P2P, la
demanda se incrementa pero la capacidad general del sistema también. Esto
no es posible en un modelo cliente-servidor con un número fijo de servidores.
El paradigma P2P se muestra en la figura 3.6, donde se puede ver que
en un peer están ejecutándose al mismo tiempo tanto un proceso servidor
como uno cliente, también ambos ofrecen y solicitan respectivamente servi-
cios a otros procesos similares en otros peers.

Beneficios de un sistema peer-to-peer:

• Nodos comparten recursos.
• Se pueden desplegar algoritmos distribuidos.
• Escalamiento más fácil del sistema.
• Ahorro de costos.
• Flexibilidad.
• Ningún punto único de falla.
• Mayor robustez del sistema.

Figura 3.6. Paradigma peer-to-peer

42 Sistemas distribuidos

Una infraestructura de comunicación P2P está formada por un grupo de

nodos ubicados en una red física. Estos nodos construyen una abstracción
de red en la parte superior de la red física conocida como red superpuesta,
que es independiente de la red física subyacente. La figura 3.7 muestra este
escenario. La red superpuesta se establece para cada sistema P2P a través
de conexiones TCP o HTTP. Debido a la capa de abstracción de la pila de
protocolo TCP, las conexiones físicas no son reflejadas por la red de super-
posición. La red superpuesta construye túneles lógicas entre pares de nodos
[Ripeanu, Foster, Iamnitchi & Rogers, 2007], con el fin de implementar su
propio mecanismo de enrutamiento para transportar sus mensajes.

Figura 3.7. Ejemplo de una red superpuesta peer-to-peer [López-Fuentes, 2009]

3.5 Applets

Un applet es un código que se ejecuta en el contexto de otro programa, por

ejemplo, en un navegador web. El código se descarga en el navegador y
se ejecuta allí, como se muestra en la figura 3.8.
Modelos de arquitecturas 43

Figura 3.8. a) A solicitud del cliente el servidor web, responde con el código del
applet. b) El cliente interactúa con el applet (adaptado de [Coulouris et al., 2012])

Un applet normalmente lleva a cabo una función muy específica, que ca-
rece de uso independiente, y son ampliamente utilizados en aplicaciones
de telefonía móvil. Un applet puede dar una buena respuesta interactiva,
ya que no sufre de los retrasos o variabilidad de ancho de banda asociado
con la comunicación de la red. Sin embargo, un applet típicamente carece
de sesión y tiene privilegios restringidos de seguridad. A menudo, un applet
consiste en un código poco confiable, por eso se les impide tener acceso
al sistema de archivos local. Los applet que se cargan a través de la red con
frecuencia son considerados como códigos de poca confianza [Flanagan,
1998], a excepción de que lleven la firma digital de una entidad especificada
como confiable. Ejemplos de los applets más comunes son:

• Java applets.
• Animaciones Flash.
• Windows media player.
• Modelos 3D.
44 Sistemas distribuidos

3.6 Clúster

En informática, el término clúster (“grupo” o “racimo”) hace referencia a

conjuntos o conglomerados de computadoras construidos mediante el uso
de hardware común y que se comportan como si fueran una única computa-
dora. Un ejemplo de clúster se muestra en la figura 3.9. El uso de los clúste-
res varía desde las aplicaciones de supercómputo, servidores web y comer-
cio electrónico hasta el software de misiones críticas y bases de datos de alto
rendimiento. El cómputo con clústeres es el resultado de la convergencia de
varias tendencias tecnológicas actuales, entre las que se pueden destacar:

• Microprocesadores de alto rendimiento.

• Redes de alta velocidad.
• Software para cómputo distribuido de alto rendimiento.
• Crecientes necesidades de potencia computacional.

Los servicios esperados de un clúster principalmente son:

• Alto rendimiento.
• Alta disponibilidad.
• Escalabilidad.
• Balanceo de carga.

Típicamente respecto a la rapidez y disponibilidad, se espera que un clús-

ter sea más económico que el uso de computadoras individuales.
Un clúster puede ser:

• Homogéneo.
• Semihomogéneo.
• Heterogéneo.

Un clúster es homogéneo cuando todas las computadoras tienen la mis-

ma configuración en hardware y sistema operativo. Es semihomogéneo
cuando las computadoras tienen diferente rendimiento pero guardan una
similitud con respecto a su arquitectura y sistema operativo. Finalmente, un
clúster es heterogéneo cuando las computadoras tienen diferente hardware
y sistema operativo.
Modelos de arquitecturas 45

Figura 3.9. Ejemplo de clúster

3.7 Grid

El cómputo grid es un paradigma del cómputo distribuido, frecuentemente

usado para indicar una infraestructura de gestión de recursos distribuidos
que se centra en el acceso coordinado a los recursos informáticos remotos
[Foster & Kesselman, 1999]. Estos recursos de cómputo son colectados des-
de múltiples localizaciones para alcanzar una meta común. A diferencia del
cómputo de cluster (en grupo o racimo), el cómputo grid tiende a ser más
heterogéneo y disperso geográficamente. Generalmente las grids son usa-
das para una variedad de propósitos pero puede haber grids especializadas
para fines específicos. Los recursos que son integrados por una infraestruc-
tura grid son típicamente plataformas de cómputo dedicadas a supercompu-
tadoras de alta gama o clústers de propósito general.
Algunos autores [Foster & Kesselman, 2013] ubican como antecedente
del cómputo grid al sistema de tiempo compartido Multics. Sin embargo,
este concepto ha sufrido múltiples transformaciones a lo largo de los años
y diversas definiciones sobre el cómputo grid pueden ser encontradas en la
literatura. Jacob, Brown, Fukui y Trivedi [2005] definen la computación grid
como cualquiera de una variedad de niveles de virtualización a lo largo de un
continuo, donde a lo largo de ese continuo se podría decir que una solución
particular es una implementación de cómputo grid frente a una relativamente
simple aplicación usando recursos virtuales, pero incluso en los niveles más
simples de virtualización, siempre se requieren habilitar tecnologías de redes.
46 Sistemas distribuidos

Beneficios del cómputo grid [Jacob et al., 2005]:

• Explotación de recursos infrautilizados.

• Capacidad de CPU paralelos.
• Recursos virtuales y organizaciones virtuales para la colaboración.
• Acceso a recursos adicionales.
• Balanceo de recursos.
• Fiabilidad.
• Mejor gestión de infraestructuras de TI más grandes y distribuidos.

La conceptualización del cómputo grid se muestra en la figura 3.10.

Figura 3.10. Ejemplo de cómputo grid

3.8 Arquitectura de capas

Una arquitectura de capa resulta familiar en los sistemas distribuidos y está re-
lacionado con la abstracción. Con este enfoque, un sistema complejo puede
ser dividido en cierto número de capas, donde las capas superiores hacen uso
de los servicios ofrecidos por las capas inferiores. De esta manera, una deter-
minada capa ofrece una abstracción de software, sin que las capas superiores
o inferiores a esta deban de estar al tanto de los detalles de implementación.
En el caso de los sistemas distribuidos, los servicios se organizan de una
manera vertical como capas de servicio. Un servicio distribuido puede ser
proporcionado por uno o más procesos del servidor, que interactúan entre
sí y con los procesos de cliente para mantener una visión de todo el sistema,
Modelos de arquitecturas 47

coherente de los recursos del servicio. Por ejemplo, el ajuste de hora entre
clientes puede realizarse por un servicio de hora de red a través de Internet,
usando el protocolo de Tiempo de Red (NTP). Es útil organizar este tipo de
servicio en capas debido a la complejidad de los sistemas distribuidos. Una
visión común de una arquitectura de capa se muestra en la figura 3.11.

Figura 3.11. Capas de servicio en un sistema distribuido [Coulouris et al., 2012]

Como se indica en la figura 3.11, un sistema distribuido está constituido

principalmente por los siguientes estratos:

• Plataforma.
• Middleware.
• Aplicaciones y servicios.

La plataforma para sistemas y aplicaciones distribuidas se compone de las

capas de hardware y software de nivel más bajo. Estas capas de bajo nivel
proporcionan servicios a las capas superiores, las cuales son implementa-
das de manera independiente en cada equipo, conduciendo a la interfaz
de programación del sistema hasta un nivel que facilita la comunicación y la
coordinación entre los procesos. Ejemplos de plataformas son:

• Intel x86/Windows.
• Intel x86/Mac OS X.
• Intel x86/Linux.
• Intel x86/Solaris.
48 Sistemas distribuidos

Middleware es un software que tiene como función principal enmascarar

la heterogeneidad del sistema distribuido para proporcionar un modelo de
programación conveniente a los programadores de aplicaciones. Ejemplos
de middleware son:

• CORBA (Common Object Request Broker).

• Java RMI (Java Remote Method Invocation).

Finalmente, la capa de aplicaciones y servicios son las prestaciones que

ofrece el sistema distribuido a los usuarios. Se entiende como las aplicacio-
nes distribuidas.

3.9 Middleware

En la primera generación de los sistemas distribuidos todos los servicios pro-

porcionados por los servidores debían de programarse a la medida. Así, ser-
vicios de acceso a bases de datos, de impresión y transferencias de archivos
tenían que ser desarrollados por las propias aplicaciones. Queda en eviden-
cia la necesidad de crear servicios de uso más común por las aplicaciones,
de tal manera que pueda incluirse en todas las aplicaciones como software
prefabricado. En este escenario surge la idea del middleware, representado
por estándares tales como ODBC, OLE, DCOM y CORBA.
Middleware es un conjunto de servicios que permite distribuir datos y
procesos a través de un sistema multitarea, una red local, una red remota o
Internet [Martínez Gomaríz, 2014]. Los servicios del Middleware pueden ser
clasificados en dos grandes grupos:

• Servicios de desarrollo.
• Servicios de administración.

El objetivo principal del middleware es conseguir la transparencia en los

sistemas distribuidos, por medio de:

• Ofrecer la capacidad, así como solicitar y recibir de manera transparente

al sistema.
• Liberar a los diseñadores y administradores del sistema de problemas
derivados de la complejidad del sistema operativo.
Modelos de arquitecturas 49

En la práctica, middleware es representado por procesos u objetos en un

conjunto de equipos que interactúan entre sí para implementar la comunica-
ción y el intercambio de recursos de soporte para las aplicaciones distribui-
das [Coulouris et al., 2012]. El middleware está relacionado con el suministro
de materiales de construcción útiles para la construcción de componentes de
software que pueden trabajar con otros en un sistema distribuido. Las abs-
tracciones del middleware apoyan a diversas actividades de comunicación,
como la invocación de método remoto, la comunicación entre un grupo de
procesos, notificación de eventos, el particionamiento, la colocación y recu-
peración de objetos de datos compartidos entre los equipos cooperantes,
la replicación de objetos de datos compartidos y la transmisión de datos
multimedia en tiempo real. Un escenario del middleware es mostrado en la
figura 3.12.

Figura 3.12. Escenario del middleware en un sistema distribuido

A pesar de que el middleware tiene como objetivo suministrar transpa-

rencia de distribución, en general las soluciones específicas deben de ser
adaptables a los requerimientos de las aplicaciones. Tanenbaum y Van Steen
[2008] consideran que una solución para este problema es desarrollar diver-
sas versiones de un sistema middleware, donde cada versión sea confeccio-
nada para una clase específica de aplicaciones.

3.10 CORBA

El paradigma orientado a objetos juega un importante rol en el desarrollo

de software y cuenta con gran popularidad desde su introducción. La orien-
50 Sistemas distribuidos

tación a objetos se comenzó a utilizar para el desarrollo de sistemas distri-

buidos en la década de 1980. El Grupo de Gestión de Objetos (OMG-Object
Management Group) se creó en 1989 como una asociación de las empresas
líderes de la tecnología software para definir especificaciones que puedan
ser implementadas por ellas y que faciliten la interoperabilidad de sus pro-
ductos. Los middlewares basados en componentes se han convertido en
una evolución natural de los objetos distribuidos, debido a que apoyan la
gestión de las dependencias entre componentes, ocultando los detalles de
bajo nivel asociados con el middleware, gestión de las complejidades de es-
tablecer aplicaciones distribuidas con propiedades no funcionales apropia-
das –como la seguridad– y el apoyo apropiado de estrategias de implemen-
tación. Los middlewares basados en objetos distribuidos están diseñados
para proporcionar un modelo de programación basado en principios orien-
tados a objetos y, por tanto, para llevar los beneficios del enfoque a objetos
para la programación distribuida. Los principales ejemplos de middleware
basados en objetos distribuidos incluyen Java RMI y CORBA.
CORBA (Common Object Request Broker Architecture) es una herramien-
ta middleware que facilita el desarrollo de aplicaciones distribuidas en en-
tornos heterogéneos tanto en hardware como en software [Coulouris et al.,
2012], ejemplos de estos son:

• Distintos sistemas operativos (Unix, Windows, MacOS, OS/2).

• Distintos protocolos de comunicación (TCP/IP, IPX).
• Distintos lenguajes de programación (Java, C, C++).
• Distinto hardware.

El objetivo principal de CORBA es especificar un middleware para cons-

truir aplicaciones del tipo cliente-servidor multi-nivel, distribuidas y centrali-
zadas, y que sean flexibles y extensibles. Para alcanzar estos objetivos, COR-
BA utiliza diferentes medios, como los que a continuación se describen.
Del paradigma orientado a objeto explota los conceptos de encapsula-
ción, herencia y polimorfismo. En la comunicación a través de invocar mé-
todos remotos es más fácil de programar que los sockets, RPC, etc. Usa el
concepto de esqueleto como el encargado de la comunicación con el clien-
te. Define la separación interfaz-implementación a través de CORBA IDL (In-
terface Definition Language). Para la referencia a objeto, usa el identificador
único de un objeto. CORBA es implementado encima del protocolo TCP/IP
y usa modos de comunicación asíncrona y síncrona. Con el uso de envolturas
(wrappers), CORBA permite integrar los sistemas heredados, y normalmente
Modelos de arquitecturas 51

usa solo una instancia de cada clase. CORBA también hace uso de una capa
de software conocida como ORB (Object Request Broker), que permite a los
objetos realizar llamadas a métodos situados en máquinas remotas a través
de una red. Además, ORB maneja la transferencia de estructuras de datos de
manera que sean compatibles entre los dos objetos. ORB es un componen-
te fundamental de la arquitectura CORBA y su misión es facilitar la comuni-
cación entre objetos. ORB también debe de facilitar diferentes transparen-
cias, tales como de localización, implementación, comunicación y ejecución.
En CORBA [Coulouris et al., 2001], el servidor crea objetos remotos, hace
referencias accesibles a objetos remotos y espera a que los clientes invo-
quen a estos objetos remotos o a sus métodos. Por su parte, el cliente ob-
tiene una referencia de uno o más objetos remotos en el servidor e invoca a
sus métodos.
La arquitectura CORBA (ver figura 3.13) está diseñada para dar soporte al
rol de un intermediario de peticiones de objetos que permita que los clientes
invoquen métodos en objetos remotos, donde tanto los clientes como los
servidores pueden implementarse en diversos lenguajes de programación.

Figura 3.13. Principales componentes

de la arquitectura CORBA [Coulouris et al., 2001]

La función de los principales componentes se describen a continuación

[Coulouris et al., 2001]. El núcleo de ORB es un módulo de comunicación el
cual permite una interfaz que incluye las operaciones de arranque y paro, las
operaciones para la conversión entre referencias a objetos remotos y cade-
nas de texto, así como las operaciones para obtener listas de argumentos
para llamadas que emplean invocación dinámica. El adaptador de objeto
sirve como puente entre los objetos con interfaces IDL y las interfaces IDL,
además de las interfaces del lenguaje de programación de las correspon-
dientes clases sirvientes. Las clases esqueleto se generan en el lenguaje del
52 Sistemas distribuidos

servidor a través de un compilador de IDL. El esqueleto sirve para despachar

las invocaciones a los métodos remotos, asimismo desempaqueta los argu-
mentos desde los mensajes de petición y empaqueta las excepciones y los
resultados en mensajes de respuesta. Los resguardo/proxy son los encarga-
dos de empaquetar los argumentos de los mensajes de invocación y desem-
paqueta las excepciones y los resultados de las respuestas. Cada repositorio
de implementación activa los servidores registrados bajo demanda y localiza
los servidores que están en ejecución en cada momento usando el nombre
del adaptador de objeto. El repositorio de interfaz proporciona información
sobre las interfaces IDL registradas a los clientes y a los servidores que lo
requieran. La interfaz de invocación dinámica permite que los clientes pue-
dan realizar invocaciones dinámicas sobre objetos remotos CORBA cuando
no es práctico el uso de proxies. La interfaz de esqueleto dinámica permite
que un objeto CORBA acepte invocaciones sobre una interfaz para la que no
hay un esqueleto. El código delegado permite convertir a objetos CORBA
aquellos fragmentos de código existente que fue diseñado sin prever los
objetos distribuidos.