pc1 Informe Final SD CGT Grupo 3

lOMoARcPSD|5217480
PC1 Informe Final SD-CGT Grupo 3
Sistemas Distribuidos (Universidad Tecnológica del Perú)

StuDocu no está patrocinado ni avalado por ningún colegio o universidad.
Descargado por Jose Rojas (joserm18@yahoo.es)
lOMoARcPSD|5217480
UNIVERSIDAD TECNOLÓGICA DEL PERÚ
FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS E INFORMÁTICA
TRABAJO GRUPAL - PRACTICA N°1
SISTEMAS DISTRIBUIDOS ARQUITECTURAS
DOCENTE:
Curso: Sistemas Distribuidos
INTEGRANTES:
1. Torres Quiroz Henry Isvel
2. Luis Angel Ramirez Revilla
3. Villa Quiste Jossy
4. Marin Concha Fernández, Carlos
LIMA-PERÚ
2019

lOMoARcPSD|5217480
ÍNDICE DE CONTENIDO
1. Introducción.....................................................................................................................................2
2. Objetivos...........................................................................................................................................3
3. Conceptos previos.........................................................................................................................3
3.1. Definición.................................................................................................................................
.4
3.1.1 Ventajas.............................................................................................................................5
3.1.2 Desventajas......................................................................................................................6
4. Arquitectura de Sistemas Distribuidos.....................................................................................7
4.1. Arquitectura de
Software.......................................................................................................7
4.1.1 Estilos (Modelos)
Arquitectónicos...................................................................................8
4.2. Arquitectura de
Sistema.........................................................................................................9
4.2.1 Introducción........................................................................................................................
...9
4.2.2 Desarrollo de Arquitecturas
Centralizadas..................................................................10
4.2.3 Paradigma Cliente -
Servidor...........................................................................................10
4.2.4 Características de la Arquitectura Cliente-
Servidor...................................................12 4.2.5 Ventajas y Desventajas de la
Arquitectura Cliente-Servidor...................................12
4.2.6 Conclusiones.......................................................................................................................13
4.2.7 Recomendaciones..............................................................................................................13
4.2.8 Bibliografía...........................................................................................................................13
5. Anexos.....................................................................................................................................13
5.1. Anexo 1: mapa mental de................................................................................................13
6. Referencias.............................................................................................................................13
ÍNDICE DE FIGURAS

lOMoARcPSD|5217480
Figura 1 -. José Alejandro Reyes Ortiz (2018), Arquitecturas de los sistemas distribuidos .........5
Figura 2 - Katu Arkonada (2011), Estilos Arquitectónico..............................................................7
Figura 3 - Roberto Gómez (2018), Arquitectura de los sistemas distribuidos................................9
Figura 4 - Roberto Gómez (2018), Arquitectura de los sistemas distribuidos.............................10
Figura 5 - Roberto Gómez (2018), Arquitectura de los sistemas distribuidos .............................10
Figura 6 - Roberto Gómez (2018), Arquitectura de los sistemas distribuidos .............................11
Figura 7 - Ramsés Gallego (2009), Entel Security & Risk Management ....................................12
Figura 8 - Interacción entre un cliente y un servidor ...................................................................12
Figura 9 - Interacción general en un Modelo cliente y un servidor .............................................13
Figura 10 - Plataformas Cliente y Servidor ...................................................................................6
1. Introducción
La computación desde sus inicios ha sufrido varios cambios, desde los grandes
ordenadores que permitían realizar las tareas en forma limitada hasta los actuales
ordenadores que tienen mayores capacidades que los primeros, las cuales son de gran
importancia para las actividades cotidianas de las personas. Este cambio se atribuye
principalmente al desarrollo de los microprocesadores y al desarrollo de las redes de
área local que permitieron conectar ordenadores a alta velocidad.
La arquitectura que se impone en esta nueva etapa es la arquitectura web, basada en el

Modelo cliente-servidor. Un concepto muy importante es que Internet se convierte en
una oportunidad de negocio y este carácter comercial de Internet se construye en torno
a la centralización que ofrece la arquitectura cliente-servidor de la web. En ese
momento se empieza a extender el uso de aplicaciones que necesitan una arquitectura
diferente de la que ofrece el modelo cliente-servidor, siendo primer ejemplo claro la
mensajería instantánea.
Las arquitecturas nos permitirán conocer las formas de organizar los componentes que
forman una aplicación distribuida. Es en este contexto que aparece el concepto de
"Sistemas Distribuidos" que se ha popularizado tanto en la actualidad y que tiene como
ámbito de estudio las redes como por ejemplo: Internet, redes de teléfonos móviles,
redes corporativas, redes de empresas, etc.

lOMoARcPSD|5217480
Por ello, es importante conocer las diferentes maneras de organizar la interacción entre
estos componentes a fin de que el sistema se comporte de la manera que más nos
interese. Entonces en este aparatado veremos con mayor claridad cada uno de los
siguientes temas relacionado a la Arquitectura de los Sistemas Distribuidos, como son:
Tipos de estilos (modelos) arquitectónicos y las Arquitecturas de Sistemas
 Arquitecturas centralizadas Desarrollo de aplicaciones de capas.

 Desarrollo de arquitecturas multiniveles.
 Desarrollo de arquitecturas descentralizadas y arquitecturas estructuradas de
punto a punto.
2. Objetivos
El objetivo de una arquitectura es asegurar que la estructura reúna presentes y futuras

demandas sobre el mismo. Las principales preocupaciones son que el sistema sea fiable,
manejable, adaptable y rentable. 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, el estilo
arquitectónico y proporciona una referencia para el diseño.
Todos los tipos de sistemas distribuidos tienen características básicas comunes. Un

modelo de arquitectura es una descripción abstracta simplificada pero consistente de
cada aspecto relevante del diseño de un sistema distribuido.
En este capítulo describiremos los principales modelos arquitectónicos de los sistemas

distribuidos, particularmente en paradigmas de cliente-servidor y de igual a igual, así
como también se conocerán los niveles de aplicación de capas y las arquitecturas de dos
y 3 capas.
3. Conceptos previos
Los sistemas distribuidos son generalmente piezas complejas de software cuyos

componentes están dispersos en varias máquinas. Si se desea tener control sobre esta
complejidad, es crucial que estos sistemas estén apropiadamente organizados, debido a

lOMoARcPSD|5217480
que los sistemas distribuidos dependerán mayormente de los componentes de software

que constituyen al sistema y estas arquitecturas establecen como son organizados los
componentes del software y cómo van a interactuar entre sí.
Una arquitectura de sistemas distribuidos determina cómo se identifican y se asignan
los componentes del sistema; cómo interactúan los componentes para formar el sistema;
la cantidad y la comunicación que se necesita para la interacción; y los protocolos de
comunicación.
Cuando se construye un sistema distribuido, no se persigue la creación de una topología

de interacciones determinada ni el uso de ningún tipo de componente determinado. Lo
que se quiere es construir un sistema que satisfaga las necesidades de la aplicación.
Una característica sencilla es la gran cantidad tanto de ordenadores como de millones

de usuarios que navegan diariamente en Internet. Otra característica es la autonomía de
los diferentes ordenadores que forman el sistema informático ya que es habitual que
diferentes partes de un sistema distribuido estén administradas por distinto personal
responsable.
Y la última característica es la calidad de servicio donde un sistema distribuido a gran
escala como lo es Internet, vendrá muy condicionado por su misma latencia de red, los
cortes de comunicación que sufran y otros fenómenos externos que la pueda ser
afectado.
4. Definición
En la actualidad, los sistemas distribuidos están cada vez más presentes en

nuestra sociedad con un gran crecimiento en los últimos años el cual es motivado
por el deseo de compartir muchos recursos como ficheros, bases de datos,
imágenes, videos y otro tipo de información que este dentro de un sistema de
dispositivos, que generalmente son computadoras que están interconectadas
mediante redes de comunicación.

lOMoARcPSD|5217480
Prácticamente todos los grandes sistemas informáticos son en la actualidad

sistemas distribuidos. Además, representan a un conjunto de procesadores que
están conectados por red donde cada cliente tiene la capacidad de procesamiento
local, permitiendo unas interfaces de usuario sofisticadas.
Los sistemas de distribución vendrían hacer la parte de los componentes de
hardware y software que tienen las computadoras, las cuales mediante la
conexión en red se comunican y coordinan sus acciones por mensajes con el
propósito de conseguir su objetivo.
¿Y que es un Sistema Distribuido?
“Un sistema distribuido es una colección de ordenadores autónomos enlazados

por una red de ordenadores y soportados un software que hace que la colección
actúe como un servicio integrado” Joan (Manuel Marques i Puig/ Xavier
Vilajosana i Guillen/ Pedro A. García López, 2011, pag 9)
"Conjunto de computadores independientes que se muestran al usuario como un

sistema único coherente" (Tanenbaum, 2008, pag 2)
Figura N°1 - José Alejandro Reyes Ortiz (2018), Arquitecturas de los sistemas
distribuidos

lOMoARcPSD|5217480
Entonces, un sistema distribuido es un sistema de información en el cual las

funciones se reparten por áreas de trabajo diferentes que trabajan de forma
coordinada para asumir los objetivos que la organización asigna a ese sistema de
información.
3.1.1 Ventajas
1. Compartir recursos. Un sistema distribuido permite compartir recursos

hardware y software (discos, impresoras, ficheros y compiladores) que
se
asocian con computadoras de una red.
2. Apertura. Son normalmente sistemas abiertos: se diseñan sobre
protocolos estándares que permiten combinar equipamiento y software
de diferentes vendedores.
3. Concurrencia. Varios procesos pueden operar al mismo tiempo sobre
diferentes computadoras de la red. Hasta pueden comunicarse con otros
durante su funcionamiento.
4. Escalabilidad. Los sistemas distribuidos son escalables mientras la
capacidad del sistema pueda incrementarse, añadiendo nuevos recursos
para cubrir nuevas demandas sobre el sistema.
En la práctica, si se añaden muchas computadoras nuevas, la capacidad
de la red puede
5. Tolerancia a defectos. Contar con varias computadoras y el potencial
para reproducir información significa que los sistemas distribuidos
pueden ser tolerantes a algunas fallas de funcionamiento del hardware y
del software. En la mayoría de los sistemas distribuidos, puede haber un
servicio degradado, ante fallas de funcionamiento. Una completa pérdida
de servicio sólo ocurre cuando existe una falla de funcionamiento en la
red.

lOMoARcPSD|5217480
3.1.2 Desventajas
1. Complejidad. Los sistemas distribuidos son más complejos que los

sistemas centralizados; lo que hace más difícil comprender sus
propiedades emergentes y probar estos sistemas. Por ejemplo, en vez de
que el rendimiento del sistema dependa de la velocidad de ejecución de
un procesador, depende del ancho de banda y de la velocidad de los
procesadores de la red. Mover los recursos de una parte del sistema a
otra puede afectar de forma radical al rendimiento del sistema
2. Seguridad. Puede accederse al sistema desde varias computadoras
diferentes, y el tráfico en la red puede estar sujeto a escuchas
indeseadas. Es más difícil mantener la integridad de los datos en el
sistema y que los servicios del sistema no se degraden por ataques.
3. Manejabilidad. Las computadoras en un sistema pueden ser de
diferentes tipos y ejecutar versiones diferentes de sistemas operativos
Los defectos en una máquina pueden propagarse a otras, con
consecuencias inesperadas. Esto significa que se requiere más esfuerzo
para gestionar y mantener el funcionamiento del sistema.
4. Impredecibilidad. Los sistemas distribuidos tienen una respuesta
impredecible. La respuesta depende de la carga total en el sistema, de su
organización y de la carga de la red. Como todos ellos pueden cambiar
rápidamente, el tiempo requerido para responder a una petición de
usuario puede variar drásticamente, de una petición a otra.
5. Arquitectura de Sistemas Distribuidos
La implementación de un sistema distribuido requiere de la división de aplicaciones,

servidores y otros procesos, así como también de la identificación de sus componentes
en la red, su instalación en computadoras u otros equipos y a la colocación final de su
arquitectura se le conoce como “arquitectura de software”, siendo está el aspecto más
importante en el diseño de un sistema distribuido.

lOMoARcPSD|5217480
Es por ello, que vamos a mencionar la diferencia entre la arquitectura de software y

arquitectura de sistema.
4.1 Arquitectura de Software
¿Qué es una Arquitectura?
Es el Arte de ordenar las superficies y volúmenes en un espacio para habitación humana,

lugares de reuniones públicas o monumentos conmemorativos.
Teniendo un concepto más claro de lo que es la arquitectura, ahora mencionaremos
sobre la arquitectura de software. Una arquitectura de software, define la forma de
trabajar en un sistema, es decir la manera como construir nuevos módulos o
ambientes.
Figura N°2 - Katu Arkonada (2011), Estilos Arquitectónicos
La Arquitectura de Software es un conjunto de patrones y abstracciones

relacionados entre sí que brindan el marco de referencia necesario para orientar y
dirigir la línea de construcción del software para un sistema de información.

lOMoARcPSD|5217480
“La arquitectura de software, tiene que ver con el diseño y la implementación de

estructuras de software de alto nivel. Es el resultado de ensamblar un cierto número
de elementos arquitectónicos de forma adecuada para satisfacer la mayor
funcionalidad y requerimientos de desempeño de un sistema, así como
requerimientos no funcionales, como la confiabilidad, escalabilidad, portabilidad y
disponibilidad” (Kruchten, Philippe, 1995). La arquitectura de software también
involucra:
 Funcionalidad
 Usabilidad
 Tolerancia a cambios
 Performance
 Reutilización
 Restricciones económicas y tecnológicas (equilibrio)
 Aspectos estéticos
4.1.1 Estilos (Modelos) Arquitectónicos
¿Qué es un estilo Arquitectónico?
Se define un estilo arquitectónico como el medio de expresión que aparece en

la arquitectura a través de la composición y los materiales con los que se
construye en diferentes periodos históricos (Edad Antigua, Edad Media y
Edad Moderna).
Un estilo arquitectónico típicamente define un vocabulario de tipos para

componentes, conectores, interfaces y propiedades, además de un conjunto de
reglas que rigen cómo los elementos de dichos tipos pueden componerse
(Garlan, 2003, pág. 23).
Entonces decimos que el estilo arquitectónico de un sistema distribuido está

contemplado en términos de componentes, la forma como se conectan estos

lOMoARcPSD|5217480
componentes con los conectores y las restricciones que definen la integración

con los componentes del sistema.
El Componente. Es una unidad modular con interfaces bien definidas, y que
puede ser reemplazado en el sistema.
El Conector. Es un mecanismo que media la comunicación, coordinación o
cooperación entre los componentes. Por ejemplo, un conector puede
implementarse mediante transferencia de mensajes o flujos de datos.
Los estilos arquitectónicos más importantes son:

 Arquitecturas en capas
 Arquitecturas basadas en objetos
 Arquitecturas centradas en datos
 Arquitecturas basadas en eventos
1. Arquitecturas en Capas
Los componentes están organizados en forma de capas, en la que un
componente en una determinada capa puede llamar a componentes en la
capa inmediata inferior.
Figura N°3 - Roberto Gómez (2018), Arquitectura de los sistemas distribuidos

lOMoARcPSD|5217480
2. Arquitecturas en Objetos
En esencia, cada objeto corresponde a lo que hemos definido como

componente, y estos componentes están conectados mediante un
mecanismo RPC (Llamada Procedimiento Remoto).
3. Arquitecturas en Datos
Los datos evolucionan en torno a la idea de que los procesos se comunican
a través de un repositorio o medio común, ya sea pasivo o activo. Por
ejemplo, una cantidad importante de aplicaciones distribuidas en las que la
comunicación se establece por medio de un archivo compartido a través de
un sistema de archivos distribuidos.
4. Arquitecturas en Eventos
Los procesos se comunican esencialmente por medio de la propagación de
eventos, los cuales de manera opcional pueden llevar datos consigo.

lOMoARcPSD|5217480
4.2 Arquitectura de Sistema
Ya que se ha discutido brevemente sobre algunos estilos arquitectónicos comunes,

se verá cómo muchos sistemas distribuidos están organizados, considerando la
manera en que sus componentes de software fueron establecidos. El determinar que
componentes de software se usarán, cómo interactuarán y cómo se distribuirán es lo
que se conoce como una instancia de arquitectura de software o también llamada
arquitectura de sistema.
4.2.1 Introducción
Ante esta situación ha surgido la necesidad de crear un rol conocido como
Arquitecto de Sistema en el cual se ha delegado la responsabilidad de
investigar, evaluar y seleccionarlas mejores alternativas tecnológicas para
entender las necesidades específicas del negocio a un costo razonable.
4.2.2 Desarrollo de Arquitecturas Centralizadas
A pesar de las diferencias en cuanto a varios aspectos de los sistemas

distribuidos, solo hay un aspecto en los que muchos expertos coinciden:
pensar en términos de clientes que solicitan servicios a servidores ayuda a
entender y administrar la complejidad de los sistemas distribuidos. En el
modelo básico cliente-servidor, los procesos en un sistema distribuido están
divididos en dos grupos, que posiblemente se entrelazan parcialmente.

lOMoARcPSD|5217480
Figura N°7 - Ramsés Gallego (2009), Entel Security & Risk Management
Un servidor. Es un proceso que implementa un servicio específico, por

ejemplo, un servicio de sistema de archivos distribuido o de base de datos.
Un cliente. Es un proceso que solicita un servicio a un servidor, enviándole
una petición y subsecuentemente esperando la respuesta del servidor. La
interacción cliente-servidor, también conocida como solicitud-respuesta, se
muestra en la Figura N°8.
Figura N°8 - Interacción entre un cliente y un servidor
La comunicación entre un cliente y un servidor puede ser

implementada por medio de un simple protocolo no orientado a la
conexión (sin conexión) cuando la red subyacente es suficientemente
confiable como es el caso de muchas redes de área local (LANs).
Protocolo de comunicación. Es una serie de normas que usan los equipos
informáticos para gestionar sus diálogos en los intercambios de
información.

lOMoARcPSD|5217480
4.2.3 Paradigma Cliente - Servidor
La Arquitectura Cliente servidor consiste básicamente en un cliente que

realiza peticiones a otro programa (el servidor) y este le da la respuesta. Para
que la comunicación entre dos aplicaciones se lleve a cabo, uno de los
programas de aplicación debe estar esperando por los requerimientos por
parte del programa llamador. En este modelo, un programa espera
pasivamente y el otro inicia la comunicación. A esto se le conoce como el
paradigma de interacción cliente servidor. La aplicación que espera
pasivamente es llamada “Servidor” y la que inicia el contacto es llamada
“Cliente”.
Figura N°9 - Interacción general en un Modelo cliente y un servidor
¿Qué es un paradigma?
Un paradigma refleja algo en específico que funciona como ejemplo a
seguir.
“Un paradigma es una forma de ver el mundo, una perspectiva general, una
manera de fragmentar la complejidad del mundo real” (Patton, 1990)
Definición
El concepto resulta muy amplio, puesto que existen multitud de elementos
que pueden operar usando esta arquitectura (sistemas operativos,
aplicaciones, equipos hardware, servicios...), se puede llevar a cabo de
múltiples formas (acceso local, acceso remoto y en entornos centralizados o

lOMoARcPSD|5217480
distribuidos.) y además puede aplicarse a prácticamente todos los ámbitos de

las tecnologías de la información (comunicaciones, programación, gestión
empresarial, seguridad, etc.).
El cliente es un computador pequeño con una estructura al igual a la que

tenemos en nuestras oficinas u hogares la cual accede a un servidor o a los
servicios del mismo a través de Internet o una red interna.
El servidor al igual que el cliente, es una computadora pero con diferencia de
que tiene una gran capacidad que le permite almacenar gran cantidad de
diversos de archivos, o correr varias aplicaciones en simultaneo para así
nosotros los clientes poder acceder los servicios.
Figura N°10 - Plataformas Cliente y Servidor
Un ejemplo muy familiar de arquitectura cliente / servidor es la consulta,

usando un navegador de Internet, de una página web; en este caso tenemos
un cliente, el navegador de Internet, que demanda a una aplicación servidora
de páginas web, el servidor, el acceso al contenido de una de esas páginas; el
servidor, en respuesta a esta petición, envía los contenidos al navegador para
que sean visualizados, descargados o ejecutados, según el tipo de contenido.
De manera muy simplificada podemos decir que este ejemplo implica una
arquitectura cliente / servidor entre aplicaciones: la aplicación cliente o

lOMoARcPSD|5217480
navegador de Internet, y la aplicación servidora o servidor de páginas webs.

Es importante observar que en ningún momento la existencia de esta
relación cliente servidor en el nivel de aplicación tiene ninguna otra
implicación en otros niveles; así, por ejemplo, puede ocurrir que la
aplicación cliente y la aplicación servidora se estén ejecutando en el mismo
equipo y en el mismo sistema operativo, y no en dos equipos distintos, el
equipo cliente y el equipo servidor.
4.2.4 Características de la Arquitectura Cliente-Servidor
Las características del Cliente son:

 Es una aplicación normal que actúa como cliente cuando se requiere
acceso
remoto.
 Es invocado directamente por el usuario y tiene una existencia dada por la
duración de la sesión del usuario.
 Corre localmente en el computador del usuario.
 Inicia activamente el contacto con un servidor.
 Ejemplo: navegadores web (google, Internet explorer, mozilla, etc)
Las características del Servidor son:

 Corre en un computador compartido.
 Espera pasivamente ser contactado por clientes remotos.
 Acepta ser contactado por clientes diversos clientes pero ofrece un
servicio bien
definido. Ejemplo: servidor WEB (apache)
4.2.5 Ventajas y Desventajas de la Arquitectura Cliente-Servidor
1. Ventajas

lOMoARcPSD|5217480
 Facilita la integración entre sistemas diferentes y comparte información,

permitiendo que las máquinas puedan ser utilizadas utilizando interfaces
para el usuario.
 Al favorecer el uso de interfaces gráficas interactivas, los sistemas
construidos bajo este esquema tienen un mayor desempeño con el
usuario.
 Facilita la integración de nuevas tecnologías y el crecimiento de la
infraestructura computacional, favoreciendo así la escalabilidad de las
soluciones.
2. Desventajas
 El mantenimiento de los sistemas es más difícil pues implica la
interacción de diferentes partes de hardware y de software, distribuidas
por distintos proveedores, lo cual dificulta el diagnóstico de las fallas.
 Es importante que los clientes y los servidores utilicen el mismo
mecanismo (por ejemplo sockets, procesadores, tarjetas, etc.), lo cual
implica que se deben tener mecanismos generales que existan en
diferentes plataformas.
 El desempeño (performance), problemas de este estilo pueden presentarse
por congestión en la red, dificultad de tráfico de datos, etc.
4.2.5 Conclusiones
 Los sistemas distribuidos abarcan una cantidad de aspectos considerables,

sistemas operativos, comunicaciones, modelos de programación, etc, lo
que hace que sus beneficios se pueden traducir en complejidades al
momento de su implantación.
 Existen ciertos aspectos que requieren cuidado especial ya que pueden
pasar de ser una ventaja a una desventaja, por ejemplo, el manejo de
fallos, el control de la concurrencia, etc.
 Es importante señalar que muchas tecnologías están en constante
desarrollo y maduración, esto requiere de un estudio a profundidad de los

lOMoARcPSD|5217480
factores que intervienen en cada aspecto de los sistemas distribuidos antes

de apostar por alguna tecnología en especial.
4.2.7 Recomendaciones
• Es importante escoger la arquitectura en capas dependiendo de lo e se va hacer

y desarrollar
• Para el desarrollo de sistemas de gran magnitud se debe pensar seriamente
enlos sistemas distribuidos y cuál sería la arquitectura más eficiente para la
empresa / proceso
• Se recomienda usar las 3 capas de interfaz de usuario, proceso y base de datos.
Además, tener interacción entre cliente y servidor.
• Los estilos arquitectónicos para sistemas distribuidos no necesariamente están
aislados, muchas veces un sistema posee una arquitectura basada en una
combinación de estilos arquitectónicos
 Es aconsejable escoger la arquitectura en capas dependiendo de lo que se
va hacer y desarrollar en un sistema distribuido.
 Para el desarrollo de sistemas de gran magnitud se debe pensar seriamente
en los sistemas distribuidos y cuál sería la arquitectura más eficiente para
la empresa y también en que aspectos se debe tener mayor cuidado para
evitar fallos.
 Se recomienda mayor atención por parte de las autoridades en apoyar a
las escuelas, institutos y universidades en la investigación de varios
proyectos de índole científico y tecnológico.
• Es importante escoger la arquitectura en capas dependiendo de lo que se va

hacer y desarrollar
• Para el desarrollo de sistemas de gran magnitud se debe pensar seriamente
enlos sistemas distribuidos y cuál sería la arquitectura más eficiente para la
empresa / proceso
• Se recomienda usar las 3 capas de interfaz de usuario, proceso y base de datos.
Además, tener interacción entre cliente y servidor.
• Los estilos arquitectónicos para sistemas distribuidos no necesariamente están
aislados, muchas veces un sistema posee una arquitectura basada en una
combinación de estilos arquitectónicos
4.2.8 Bibliografía
Alvarado, L. A. (2008). Agentes Móviles. Revista de Información, Tecnología y Sociedad, 174-179.

Recuperado el 9 de 9 de 2019, de
http://www.revistasbolivianas.org.bo/pdf/rits/n1/n1a45.pdf

lOMoARcPSD|5217480
Bagheri, E., & Ghorbani, A. (28 de 3 de 2008). Recuperado el 11 de 9 de 2019, de

https://www.ee.ryerson.ca/~bagheri/papers/astrolabe.pdf
Bañares, J. A. (2010). Desarrollo de sistemas Multiagentes con Jade. Recuperado el 26 de 8 de

2019, de http://webdiis.unizar.es/asignaturas/ISBC/lecciones/11.JADE.pdf
Fernández, J. (s.f.). Un poco de Java y +. Recuperado el 26 de 8 de 2019, de

https://unpocodejava.com/2013/02/04/jade/
Fernández, L. M. (16 de abril de 2018). Blog Semillas MatemáticasIngenierías. Recuperado el 9 de

9 de 2019, de https://semillas.konradlorenz.edu.co/2018/04/my-entry.html
Jade site. (2019). Recuperado el 26 de 8 de 2019|, de https://jade.tilab.com/
Martín, M. I. (2012). Un servicio de movilidad de agentes de software para JADE basado en OSGi.
Tesis de Grado de Ingeniería en Informática. Recuperado el 1 de 9 de 2019, de
http://materias.fi.uba.ar/7500/SanMartin.pdf
Mestras, J. P. (s.f.). Agentes Móviles. España. Recuperado el 9 de 9 de 2019, de

http://www.fdi.ucm.es/profesor/jpavon/doctorado/AgentesMoviles.pdf
Tanenbaum, A., & Van Steen, M. (2008). SISTEMAS DISTRIBUIDOS - Principios y Paradigmas
(segunda edición ed.). México: Pearson Educación. Recuperado el 26 de 8 de 2019
Valdés, D. P. (17 de julio de 2007). Maestros del web. Recuperado el 9 de 9 de 2019, de Maestros
del web: http://www.maestrosdelweb.com/agentes-moviles-y-sus-
principalescaracteristicas/
Van Renesse, R., & Birman, K. (2002). Astrolabe: A Robust and Scalable Technology For Distributed
System Monitoring, Management, and Data Mining. Recuperado el 9 de 9 de 2019, de
https://www.cs.cornell.edu/projects/Quicksilver/public_pdfs/Astrolabe.pdf
Van Renesse, R., Birman, K., Dumitriu, D., & Vogels, W. (2002). Scalable Management and Data
Mining Using Astrolabe. Recuperado el 9 de 9 de 2019, de
https://link.springer.com/chapter/10.1007/3-540-45748-8_27
5. Anexos
5.1. Anexo 1: Mapa mental de la Arquitectura Cliente-Servidor

lOMoARcPSD|5217480
6. (Desarrollo de aplicaciones de capas)

lOMoARcPSD|5217480
Mapa mental

lOMoARcPSD|5217480
Introducción
En la actualidad hablar del termino arquitectura en 2 y 3 capas se aplican al concepto de

arquitectura de software. Una aplicación puede ser dividida en componentes el cual se
denominarán capas. Estas son unidades que se atraen y complementan con
responsabilidades definidas. En el diseño de sistemas informáticos actual se suelen usar
las arquitecturas multinivel o programación por capas. En dichas arquitecturas a cada nivel
se le confía una misión simple, lo que permite el diseño de arquitecturas escalables (que
pueden ampliarse con facilidad en caso de que las necesidades aumenten). A la
organización del software en términos de estos componentes le llamamos arquitectura
lógica. Arquitectura cliente/servidor habla de la topología del software, mientras que decir
que su arquitectura es en capas habla de su arquitectura lógica. Las aplicaciones de
software presentan tres aspectos fundamentales: Se debe hacer que los datos sean
persistentes, se debe procesar los datos de manera que valla acorde a la lógica de
negocios, y estos deben presentarse adecuadamente a los usuarios. Las aplicaciones en 1
capa, donde no se distingue una separación lógica de estos tres aspectos, son muy
grandes, difíciles de mantener, de distribuir, incompatibles con la arquitectura
cliente/servidor, pesadas y con gran consumo de recursos. Un primer acercamiento a la
distribución de las responsabilidades de la aplicación en dos unidades lógicas fue la
arquitectura en 2 capas, que es presentada en la siguiente subsección. Por último, el
modelo más utilizado actualmente es el diseño en tres niveles (o en tres capas), donde
cada uno de los aspectos se corresponde a una unidad lógica.
6.1 Objetivos
La programación por capas es un modelo de desarrollo software que tiene por objetivo
principal la separación (desacoplamiento) de las partes que componen un sistema software
o también una arquitectura cliente-servidor: lógica de negocios, capa de presentación y
capa de datos. De esta forma, al crear diferentes interfaces sobre un mismo sistema resulta
ser más sencillo y fácil de adecuar o modificar sin requerirse cambio alguno en la capa de
datos o lógica.

lOMoARcPSD|5217480
Sistemas Distribuidos Arquitecturas Grupo 3

6.2 Conceptos previos
¿Cuál es la diferencia entre Capa y nivel?
Capa. - hace referencia a la forma como una solución es segmentada desde el punto de
vista lógico:
Presentación. (Conocida como capa Web en aplicaciones Web o como capa de usuario en
Aplicaciones Nativas)
Lógica de Negocio. (Conocida como capa Aplicativa)
Datos. (Conocida como capa de Base de Datos)
Nivel. - Corresponde a la forma en que las capas lógicas se encuentran distribuidas de

forma física. Por ejemplo:
- Una solución de tres capas (presentación, lógica del negocio, datos) que residen en un
solo ordenador (Presentación +lógica +datos). Se dice que la arquitectura de la solución
es de tres capas y un nivel.
- Una solución de tres capas (presentación, lógica del negocio, datos) que residen en dos
ordenadores (Presentación +lógica, por un lado; lógica +datos por el otro lado). Se dice
que la arquitectura de la solución es de tres capas y dos niveles.

lOMoARcPSD|5217480
Imagen de:
https://s3.amazonaws.com/academia.edu.documents/43362329/Guia_Arquitectura_NCapas_DDD_NET_4_Borrador_Marzo_2010.
pdf?
6.3 Definición
¿Qué son las capas?

Al realizar el desarrollo de las aplicaciones, si llegase a ser muy complejo o extenso se
tendría que dividir la aplicación según criterios o responsabilidades, con ello permite
mantener todo el código bien organizado donde sí se requiere encontrar una funcionalidad
determinada esta sería fácil de ubicar.
El código al estar organizado en capas, las funcionalidades de bajo nivel se pueden utilizar
en cualquier parte de la aplicación, esta facilidad trae como beneficio el digitar menos
código, y en una sola implementación.
Adicionalmente, se pueden aplicar restricciones sobre que capas se pueden comunicar con
otras para que si llegase a modificar o reemplazar una de las capas esta solo afecta a
aquellas capas con las que se relaciona, interactúa o funcionan con ella. Esta limitación
permite disminuir el riesgo de que un único cambio afecte a toda la aplicación.

lOMoARcPSD|5217480

Por ejemplo, es posible que una aplicación use inicialmente su propia base de datos de
SQL Server para la persistencia, pero más adelante podría optar por usar una estrategia de
persistencia basada en la nube, o situada detrás de una API web. Si la aplicación ha
encapsulado correctamente su implementación de persistencia dentro de una capa lógica,
esa capa específica de SQL Server se podría sustituir por una nueva que implementara la
misma interfaz pública.
Además, si se llegase a tener futuros requisitos que requieran hacer modificaciones se
podrán hacer intercambio de implementaciones que a su vez este intercambio puede ser
utilizado con fines de prueba. En lugar de tener que escribir pruebas que funcionan en la
capa de datos reales o de la interfaz de usuario de la aplicación, estas capas se pueden
reemplazar en tiempo de prueba con implementaciones falsas que proporcionen respuestas
conocidas a las solicitudes. Esto permite que las pruebas sean sencillas, más fáciles de
desarrollar con una rapidez de ejecución mucho mayor a comparación si se utilizara la
infraestructura real de la aplicación.
Las capas lógicas son una técnica común para mejorar la organización del código en las
aplicaciones de software empresarial, y hay varias formas de organizar el código en capas.
Actualmente el estilo más utilizado es el de 3 capas.
La arquitectura tradicional de cliente/servidor también es conocida como arquitectura de dos

capas. Requiere una interfaz de usuario que se instala y se ejecuta en una PC o estación
de trabajo y envía solicitudes a un servidor para ejecutar operaciones complejas.
6.3.1.1 Arquitectura en 2 Capas

Una arquitectura en 2 capas distribuye la aplicación en dos componentes lógicos. Las
responsabilidades de cada componente hacen a las variantes de esta arquitectura. Surge la
arquitectura en 2 capas como consecuencia de la arquitectura cliente/servidor. Esta
topología permite distribuir la carga de la aplicación a dos computadores diferentes, lo que
llevó naturalmente a distribuir las responsabilidades de la misma a dos unidades lógicas.

lOMoARcPSD|5217480
Arquitectura Presentación +Lógica /Datos

Una primera variante es retirar el manejo de datos de la aplicación. Esto permite a varios
clientes utilizar el mismo juego de datos. Presentación + Lógica es una unidad lógica por sí,
donde el manejo de interfaz de usuario y el manejo de la lógica no se los distingue como
módulos independientes. Típicamente Presentación + Lógica se encuentra en el cliente,
mientras que Datos se encuentra en el servidor. Un ejemplo de aplicaciones con esta
arquitectura es una aplicación que delega la persistencia a un manejador de base de datos.
Imagen inspirada en:

https://moodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/LP/AM/01/Arquitecturas_y_tecnologias_para_el_desarrollo_de_aplicaciones_web.
pdf

lOMoARcPSD|5217480

Arquitectura Presentación/Lógica + Datos
El hecho de tener la misma lógica en cada cliente permitió factorizarla, llevando la misma al
servidor. Aquí la lógica de la aplicación se encuentra integrada al manejo de la persistencia
de datos. En este tipo de aplicaciones la lógica resuelve los problemas de persistencia
encargándose ella misma de dicha tarea, no necesariamente utilizando un manejador de
base de datos, o integrando toda la lógica de negocios en el mismo.

pdf
Arquitectura Presentación +Lógica/ Lógica +Datos

Una tercera variante es repartir la tarea de la lógica, una parte junto a la interfaz de usuario,
y otro junto al manejo de persistencia de datos. Un ejemplo de aplicaciones con esta
arquitectura son aplicaciones similares a las que tienen arquitectura Presentación +Lógica /
Datos, que tienen implementada parte de la lógica en procedimientos almacenados en el
manejador de la base de datos.

lOMoARcPSD|5217480

pdf
Ventajas de Arquitectura en 2 capas

- El desarrollo de aplicaciones en un ambiente de dos capas funciona adecuadamente,
pero no es necesariamente lo más eficiente. Las herramientas para el desarrollo con dos
capas son robustas y amplia mente evaluadas.
- Las técnicas de ingeniería de software de prototipo se emplean fácilmente. Las

soluciones de dos capas trabajan en ambientes no dinámicos, pero no se ejecutan bien
en organizaciones rápidamente cambiantes.
Desventajas de la Arquitectura en 2 capas

- La lógica de la aplicación no puede ser reusada ya que está ligada o a la interfaz de
usuario o al manejo de persistencia de datos.
- Las estaciones de trabajo pueden tener serias restricciones de recursos. Los
desarrolladores deben estar entrenados para optimizar la aplicación de forma que pueda
ser utilizada en dichos entornos.
- Incremento de la carga de la red: dado que el procesamiento de los datos se realiza en el
cliente, gran cantidad de información debe ser transmitida desde el servidor.

lOMoARcPSD|5217480

- El PC procesa y presenta la información. Lleva a aplicaciones monolíticas, caras y
difíciles de mantener. (“fat client”).
- La “lógica de negocios” está implementada en el PC. Notar que la lógica de negocios

nunca usa el sistema de ventanas.
- Implica un procedimiento de distribución complicado, ya que en caso de un cambio todos
los PCs deben ser actualizados. Es difícil garantizar que un cliente está corriendo una
versión anterior

lOMoARcPSD|5217480

6.3.1.2 Arquitectura en 3 capas
La arquitectura en 2 capas, con su variante Presentación /Lógica +Datos, dio lugar a la

arquitectura en 3 capas. El hecho de que la lógica de negocios y el manejo de persistencia
sean una unidad presentaba desventajas importantes: el manejador de base de datos
resultaba pequeño y quería migrarse a otro, debía actualizarse la versión, o se deseaba
incorporar datos de nuevas fuentes.
La arquitectura de tres capas es un diseño reciente que introduce una capa intermedia en el
proceso. Cada capa es un proceso separado y bien definido corriendo en plataformas
separadas. En la arquitectura tradicional de tres capas se instala una interfaz de usuario en
la computadora del usuario final (el cliente). La arquitectura usada en Web transforma la
interfaz de búsqueda existente (el explorador de Web), en la interfaz del usuario final. En
esta arquitectura la lógica de la aplicación ocupa una capa intermedia; está separada tanto
de los datos como de la interfaz de usuario. Los procesos pueden ser administrados y
desplegados en forma autónoma, sin relación con la interfaz de usuario y el manejador de
base de datos. En teoría, los sistemas en 3 capas son de más fácil ampliación y más
robustos y flexibles. Además, pueden integrar datos de múltiples fuentes. Es importante
notar que los límites entre las capas son lógicos, por lo que es posible ejecutar las tres
capas en la misma máquina. Lo importante es que el sistema está claramente estructurado
y que hay una buena planificación de los límites entre las diferentes capas.

lOMoARcPSD|5217480

pdf
Capas y niveles
Capa de presentación
Es la capa responsable de la presentar los datos y controlar la interfaz de usuario.
Esta capa permite presentar el sistema al usuario, le comunica la información y captura la
información del usuario en un mínimo de proceso. También es conocida como interfaz
gráfica y debe tener la característica de ser amigable y fácil de usar para el usuario. Esta
capa se comunica únicamente con la capa de negocio.
Características:
- Debe manejar interfaces que cumplan con el objetivo principal de este componente, el
cual es facilitar al usuario la interacción con la aplicación.
- La interfaz debe ser amigable y fácil de utilizar.
- Las interfaces deben ser consistentes con la información que se requiere, no se deben
utilizar más campos de los necesarios.
Capa de Lógica de Negocio o Control

Es llamada capa de reglas de negocio porque en esta se definen todas las reglas que se
deben cumplir para una correcta ejecución del programa.
Es aquí donde se encuentra toda la lógica del programa, así como las estructuras de datos
y objetos encargados para la manipulación de los datos existentes, así como el
procesamiento de la información ingresada o solicitada por el usuario en la capa de
presentación. Representa el corazón de la aplicación ya que se comunica con todas las
demás capas para poder llevar a cabo las tareas. Por ejemplo, mediante la capa de
presentación obtiene la información ingresada por el usuario, y despliega los resultados. Si
la aplicación se comunica con otros sistemas que actúan en conjunto, lo hace mediante
esta capa.
Se denomina capa de negocio (e incluso de lógica del negocio) porque es aquí donde se
establecen todas las reglas que deben cumplirse. Esta capa se comunica con la capa de
presentación, para recibir las solicitudes y presentar los resultados, y con la capa de datos,

lOMoARcPSD|5217480

para solicitar al gestor de base de datos almacenar o recuperar datos de él. También se
consideran aquí los programas de aplicación. Esta capa es nueva, es decir, no está
presente en la arquitectura en 2 capas en forma explícita, ya que protege del acceso directo
a la información desde la capa de presentación
Capa de datos
Es la capa donde residen los datos y es la encargada de acceder a los mismos.
Es la encargada de realizar transacciones con bases de datos y con otros sistemas para
obtener o ingresar información al sistema.
El manejo de los datos debe realizarse de forma tal que haya consistencia en los mismos,
de tal forma que los datos que se ingresan, así como los que se extraen de las bases de
datos, deben ser consistentes y precisos.
Es en esta capa donde se definen las consultas a realizar en la base de datos, tanto las
consultas simples como las consultas complejas para la generación de reportes más
específicos. Esta capa envía la información directamente a la capa de reglas de negocio
para que sea procesada e ingresada en objetos según se necesite, esta acción se
denomina encapsulamiento.
Todas estas capas pueden residir en un único ordenador, si bien lo más usual es que haya
una multitud de ordenadores en donde reside la capa de presentación (son los clientes de
la arquitectura cliente/servidor). Las capas de negocio y de datos pueden residir en el
mismo ordenador, y si el crecimiento de las necesidades lo aconseja se pueden separar en
dos o más ordenadores. Así, si el tamaño o complejidad de la base de datos aumenta, se
puede separar en varios ordenadores los cuales recibirán las peticiones del ordenador en
que resida la capa de negocio.
Si, por el contrario, fuese la complejidad en la capa de negocio lo que obligase a la

separación, esta capa de negocio podría residir en uno o más ordenadores que realizarían
solicitudes a una única base de datos. En sistemas muy complejos se llega a tener una
serie de ordenadores sobre los cuales corre la capa de negocio, y otra serie de
ordenadores sobre los cuales corre la base de datos.

lOMoARcPSD|5217480
Figura inspirada en: http://arquitecturaencapas.blogspot.com/2011/08/arquitectura-3-capas-programacion-por.html
Ventajas de arquitectura en 3 capas

- La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en varios
niveles y, en caso de que sobrevenga algún cambio, solo afectará al nivel requerido sin
tener que revisar entre el código fuente de otros módulos, dado que se habrá reducido
el Acoplamiento informático hasta una interfaz de paso de mensajes.
- Permite distribuir el trabajo de creación de una aplicación por niveles; de este modo,
cada grupo de trabajo está totalmente abstraído del resto de niveles, de forma que
basta con conocer la API que existe entre niveles.
- Separación clara de la interfaz de usuario de la lógica de la aplicación. Esta separación

permite tener diferentes presentaciones accediendo a la misma lógica
- La redefinición del almacenamiento de información no tiene influencia sobre la

presentación
- En contraste con una arquitectura en 2 capas, donde solamente datos están accesibles
al público, los objetos de negocios pueden brindar servicios (lógica de la aplicación) por
la red Otras ventajas dependen de la distribución de los componentes lógicos sobre los
nodos físicos. Estas serán discutidas en el siguiente capítulo.
- Un mayor grado de flexibilidad.

lOMoARcPSD|5217480

- Mayor seguridad, ya que la seguridad se puede definir independientemente para cada
servicio y en cada nivel.
- Mejor rendimiento, ya que las tareas se comparten entre servidores.

lOMoARcPSD|5217480

Desventajas de arquitectura en 3 capas
- Los ambientes de tres capas pueden incrementar el tráfico en la red cuando muchos
clientes envían peticiones a un solo servidor y requiere más balance de carga u
tolerancia a las fallas.
- Los exploradores actuales no son todos iguales.
- La estandarización entre diferentes proveedores ha sido lenta en desarrollarse. Muchas

organizaciones son forzadas a escoger uno en lugar de otro, mientras que cada uno
ofrece sus propias y distintas ventajas.
- A veces no se logra la contención del cambio y se requiere una cascada de cambios en

varias capas.
- Se realizan trabajos innecesarios por parte de capas más internas o redundante entre
varias capas.
- Dificultad de diseñar correctamente la granularidad de las capas.
6.3.2 Conclusiones.
- La esencia de los modelos de desarrollo por capas es el concepto de separación, es

decir, mantener cada componente tan separado del contexto global como sea posible.
Así, cada capa simplemente es la agrupación de todos los componentes que tienen una
funcionalidad común.
- Una arquitectura de n-capas forma parte de un proceso revolucionario, Estas

tecnologías son los bloques para crear Software de Negocio y Sistemas de Información
adaptables que ayuden a las empresas a integrar todos sus sistemas de Tecnologías de
la Información, mientras que obtienen una ventaja clara en el uso de Internet.

lOMoARcPSD|5217480

- La arquitectura web de tres capas utilizada en el diseño y desarrollo de la aplicación ha
permitido tener un sistema escalable, que puede soportar más carga de trabajo sin
necesidad de modificar software.
6.3.3 Recomendaciones
Este tipo de arquitectura deberá implementarse en las aplicaciones empresariales complejas

cuya lógica de negocio cambie bastante y la aplicación vaya a sufrir cambios y mantenimientos
posteriores durante una vida de aplicación, como mínimo, relativamente larga. Por otra parte,
este tipo de arquitectura no debería implementarse en aplicaciones pequeñas que una vez
finalizadas se prevén pocos cambios, la vida de la aplicación será relativamente corta y donde
prima la velocidad en el desarrollo de la aplicación.
6.3.4 Bibliografía.
https://migabeta.wordpress.com/2017/01/12/arquitectura-de-capas/
http://arquitecturaencapas.blogspot.com/2011/08/arquitectura-3-capas-programacion-
por.html http://www.di-mare.com/adolfo/cursos/2007-2/pp-3capas.pdf
https://pdfs.semanticscholar.org/ad45/e96c219fe8fff4a3bae354f8019973252050.pdf
https://docs.microsoft.com/es-es/dotnet/architecture/modern-web-apps-azure/common-
webapplication-architectures https://es.wikipedia.org/wiki/Programaci%C3%B3n_por_capas
7. Desarrollo de arquitecturas multiniveles
7.1. Introducción
Las habilidades de la industria del software tienen que ver con la rapidez y confiabilidad para
entregar soluciones que sean escalables, con alta disponibilidad y basados en tecnología de
Internet.
Para ser exitosos, estos sistemas deben también integrarse con aplicaciones y datos propietarios;
por lo tanto, deben estar disponibles a través de diferentes comunidades y organizaciones
(incluyendo empleados, socios de negocios y clientes) y con la habilidad de funcionar en un
amplio rango de dispositivos
Hoy, la Internet es una plataforma versátil para entregar soluciones de alto valor. Los servicios
pueden ser accedidos virtualmente desde cualquier dispositivo, incluyendo teléfonos celulares y
PDAs. Se han desarrollado tecnologías y protocolos para integrar los procesos de negocios y
recursos existentes para dejarlos disponibles en la Web.
Con la arquitectura multinivel se pueden integrar fácil y rápidamente las diferentes capas
(presentación, negocio e integración) utilizando patrones de software para desarrollar

lOMoARcPSD|5217480

componentes reutilizables y organizados en estructuras flexibles que en su conjunto simplifiquen
el desarrollo de las soluciones de software.
7.2 Definición
Referido como (arquitectura n-tier), es una arquitectura cliente-servidor en la cual la capa de

presentación, el procesamiento la solicitud de los datos y la gestión de los datos son físicamente
procesos por separado.
Los tres niveles lógicos (presentación, procesamiento y datos) que se detalló en la arquitectura de
capas (pag. 11) sugiere cierta cantidad de posibilidades para distribuir físicamente una aplicación
cliente-servidor a través de varias máquinas.
La organización más simple es tener sólo dos tipos de máquina:
1. Una máquina cliente que sólo contenga los programas de implementación del nivel de
interfaz de usuario.
2. Una máquina servidor que contenga el resto, es decir, los programas para implementar el
nivel de procesamiento y el nivel de datos.
Esta distribución la podemos ver en la siguiente imagen.
En
esta organización el servidor maneja todo, mientras que el cliente es básicamente una Terminal
tonta (simple), posiblemente con una linda interfaz gráfica. Existen muchas otras posibilidades
de las cuales exploraremos unas cuantas en esta sección. Un método efectivo para organizar
clientes y servidores es distribuir los programas en capas de aplicación. Como primer paso,
diferenciamos sólo dos tipos de máquinas: máquinas cliente y máquinas servidor, lo cual nos
lleva a lo que se conoce como arquitectura de dos capas (físicamente).

lOMoARcPSD|5217480
Una organización posible es tener en la máquina cliente sólo a la parte que depende de la
terminal de la interfaz de usuario, como ilustra la figura 2-5(a), y dar a las aplicaciones control
remoto sobre la presentación de sus datos. Una alternativa es colocar todo el software de la
interfaz de usuario del lado del cliente, según la figura 2-5(b). En tales casos, básicamente se
divide la aplicación en una parte frontal gráfica, el cual se comunica con el resto de la aplicación
(residente en el servidor) a través de un protocolo específico de la aplicación. En este modelo, la
parte frontal (software del cliente) no procesa más que lo necesario para presentar la interfaz de
la aplicación.
Al continuar con esta línea de razonamiento, también podemos mover parte de la aplicación
hacia la parte frontal, como ilustra la figura 2-5(c). Un ejemplo en el que esto tiene sentido es
cuando la aplicación utiliza una forma que necesita llenarse por completo antes de procesarse. La
parte frontal puede entonces verificar la corrección y consistencia de la forma, y cuando sea
necesario interactuar con el usuario. Otro ejemplo de la organización de la figura 2-5(c) es un
procesador de textos, donde las funciones básicas de edición se ejecutan del lado del cliente,
operan localmente o sobre los datos conservados en la memoria, pero las herramientas avanzadas
de soporte, como el verificador de ortografía y gramática, se ejecutan del lado del servidor. En
muchos ambientes cliente-servidor, las organizaciones que muestra la figura 2-5(d) y (e) son
particularmente populares.
Estas organizaciones se utilizan cuando la máquina cliente es una computadora personal o una
estación de trabajo conectadas a través de una red a un sistema de archivos distribuidos o a una
base de datos. En esencia, la mayoría de las aplicaciones se ejecutan en la máquina cliente, pero
todas las operaciones sobre archivos o entradas de bases de datos van hacia el servidor. Por
ejemplo, muchas aplicaciones bancarias se ejecutan en la máquina de un usuario final donde éste
realiza transacciones y eventos similares. Una vez que el usuario termina, la aplicación contacta
a la base de datos localizada en el servidor del banco y carga las transacciones para efectuar un
procesamiento posterior. La figura 2-5(e) representa la situación en que el disco local del cliente
contiene parte de los datos. Por ejemplo, cuando navega en la web, un cliente puede construir
gradualmente en un disco local un gran depósito de las páginas web más recientemente visitadas.

lOMoARcPSD|5217480

Observamos que durante algunos años ha existido gran tendencia por alejarse de las
configuraciones que aparecen en las figuras 2-5(d) y (e), en aquellos casos en que el software
cliente se ubica en máquinas de usuarios finales. Cuando esto sucede, la mayor parte del
procesamiento y almacenamiento de datos se maneja del lado del servidor. La razón para esto es
simple: aunque las máquinas cliente hacen mucho, también resultan difíciles de manejar. Tener
más funcionalidad en la máquina cliente hace que el software del lado del cliente sea más
propenso a errores, y más dependiente de la plataforma subyacente (es decir, del sistema
operativo y los recursos). Desde una perspectiva de administración de sistemas, tener lo que se
conoce como clientes obeso no es lo óptimo. En cambio, los clientes delgados representados por
las organizaciones que aparecen en las figuras 2-5(a) a (c) son mucho más sencillos, tal vez a un
menor costo en cuanto a interfaces de usuario menos sofisticadas y a rendimiento percibido por
el cliente.
Observe que esta tendencia no implica que ya no necesitemos sistemas distribuidos. Por el
contrario, vemos que las soluciones del lado del servidor se están volviendo cada vez más
distribuidas conforme los servidores únicos son reemplazados por varios servidores que se
ejecutan en diferentes máquinas. En particular, cuando diferenciamos sólo máquinas cliente y
servidor, como lo hemos hecho hasta ahora, perdemos de vista el punto de que un servidor
algunas veces necesita actuar como cliente, lo cual nos lleva a una arquitectura de tres capas
(físicamente).
En esta arquitectura, los programas que forman parte del nivel de procesamiento residen en un
servidor separado, pero también pueden estar parcialmente distribuidos en máquinas cliente y
servidor.
A continuación se presenta un ejemplo de esta arquitectura.
7.3. Ventajas
• Los componentes de la aplicación pueden ser desarrollados en cualquier

lenguaje.

lOMoARcPSD|5217480

• Los componentes son independientes.
• Los componentes pueden estar distribuidos en múltiples servidores.
• La D.B. es solo vista desde la capa intermedia y no desde todos los clientes.
• Mejora la administración de los recursos cuando existe mucha concurrencia.
• Permite reutilización real del software y construir aplicaciones escalables.
7.4 Desventajas
• Modelo más caro de implementar y ejecutar.

• Redundancia de código en los diferentes componentes.
7.5Conclusiones
La arquitectura en 2 niveles es, por lo tanto, una arquitectura cliente/servidor en la que el
servidor es polivalente, es decir, puede responder directamente a todas las solicitudes de
recursos del cliente.
Sin embargo, en la arquitectura en 3 niveles, las aplicaciones al nivel del servidor son
descentralizadas de uno a otro, es decir, cada servidor se especializa en una determinada
tarea, (por ejemplo: servidor web/servidor de bases de datos). La arquitectura en 3 niveles
permite, un mayor grado de flexibilidad, mayor seguridad, ya que la seguridad se puede
definir independientemente para cada servicio y en cada nivel y mejor rendimiento, ya
que las tareas se comparten entre servidores.
7.6. Bibliografía
• Tanenbaum SD-Principios_Paradigmas 2008

• Diseno Aplicaciones Distribuidas-EnricMartinez

lOMoARcPSD|5217480

8. Desarrollo de Arquitecturas descentralizadas y punto a punto
8.1. Introducción
Desde la antigüedad, la información se ha convertido en la materia prima del
conocimiento. Hoy en día no se concibe una organización institucional sin un adecuado
tratamiento, tanto de la información externa que necesita para su inserción en el mercado,
como de la información interna que necesite manejar para el mejor control y adecuado
uso de todos sus propios recursos, con vistas a potenciarlos de forma más efectiva y
eficiente. El uso adecuado de la información implica disponer de ella en el lugar y en el
momento preciso. Para esto, los sistemas de búsqueda y recuperación de información
constituyen una herramienta indispensable en el ejercicio de cualquier actividad de la
vida moderna. Con el acelerado desarrollo tecnológico de las últimas décadas, las
actuales formas de acceder al conocimiento humano han revolucionado. Para cualquier
profesional, el conocimiento acerca del funcionamiento de las tecnologías de la
información y la comunicación, se han convertido en un reto; pero para los profesionales
encargados de seleccionar, organizar y brindar acceso a la información a comunidades de
usuarios, más que un reto, constituye una obligación.
8.2 Definición
Los sistemas peer-to-peer (p2p) son sistemas descentralizados en los que los cálculos
pueden llevarse a cabo en cualquier nodo de la red y , al menos en el principio , no se
hace distinciones entre clientes y servidores. En las aplicaciones peer-to-peer el sistema
en su totalidad se diseña para aprovechar la ventaja de la potencia computacional y
disponibilidad de almacenamiento a través de una red de computadoras potencialmente
enorme. Los estándares y protocolos que posibilitan las comunicaciones a través de los

lOMoARcPSD|5217480

nodos están embebidos en la propia aplicación , y cada nodo debe ejecutar una copia de
dicha aplicación.
La arquitectura de las aplicaciones p2p desde dos puntos de vista. La arquitectura lógica
de la red es la distribución de la arquitectura del sistema, mientras que la arquitectura de
la aplicación es la organización genérica de los componentes en cada tipo de aplicación.
En principio, en los sistemas peer-to-peer cada nodo en la red podría conocer cualquier
otro nodo , podría conectarse con él , y podría intercambiar datos . En la práctica, por su
puesto, esto es imposible, ya que los nodos se organizan dentro de localidades con
algunos nodos que actúan como puentes a otras localidades de nodos.
8.3. Arquitecturas descentralizadas
Las arquitecturas cliente-servidor multiniveles son una consecuencia directa de dividir
aplicaciones para obtener una interfaz de usuario, componentes de procesamiento, y un
nivel de datos. Los diferentes niveles corresponden directamente a la organización lógica
de las aplicaciones. En la mayor parte de los ambientes de negocios, el procesamiento
distribuido equivale a organizar una aplicación cliente-servidor en la forma de una
arquitectura multiniveles. Nos referimos a este tipo de distribución como distribución
vertical. La característica clásica de la distribución vertical es que se logra colocando
lógicamente los diferentes componentes en diferentes máquinas. El término se relaciona
con el concepto de fragmentación vertical según es utilizado en bases de datos

lOMoARcPSD|5217480

relacionales distribuidas, donde significa que las tablas se dividen por ancho de columna,
y posteriormente se distribuyen a través de diversas máquinas (Oszu y Valduriez, 1999).
De nuevo, desde un punto de vista de administración de sistemas, tener una distribución
vertical puede ayudar puesto que: las funciones están lógica y físicamente divididas en
diversas máquinas, y cada máquina se configura a la medida para un grupo específico de
funciones. Sin embargo, la distribución vertical es sólo una manera de organizar
aplicaciones cliente-servidor. En arquitecturas modernas, con frecuencia lo que cuenta es
la distribución de clientes y servidores, y a esto nos referimos como distribución
horizontal. En este tipo de distribución, un cliente o un servidor pueden dividirse
físicamente en partes lógicas equivalentes, pero cada parte opera en su propio espacio del
conjunto de datos, lo que equilibra la carga. En esta sección veremos un tipo de
arquitectura moderna, llamada sistemas punto a punto, que da soporte a la distribución
horizontal. Desde una perspectiva de alto nivel, todos los procesos que constituyen un
sistema de punto a punto son iguales. Esto significa que las funciones que necesitan
realizarse están representadas por cada proceso constituyente del sistema distribuido.
Como consecuencia, mucha de la interacción ocurrida entre los procesos es simétrica:
cada proceso actuará como cliente y servidor al mismo tiempo (a esto se le denomina
también que actúa como sirviente). Dado este comportamiento simétrico, las
arquitecturas de punto a punto evolucionan alrededor de la forma de cómo organizar los
procesos en una red sobrepuesta, es decir, una red en la que los nodos estén formados por
los procesos, y los vínculos representan los posibles canales de comunicación (a los
cuales generalmente se les conoce como conexiones TCP). En general, un proceso no
puede comunicarse directamente con otro proceso cualquiera, en vez de eso, necesita

lOMoARcPSD|5217480

enviar mensajes a través de los canales de comunicación disponibles. Existen dos tipos de
redes sobrepuestas: las que están estructuradas, y las que no lo están. Estos dos tipos son
ampliamente tratados en Lúa y colaboradores (2005), junto con muchos ejemplos. Aberer
y colaboradores (2005) proporciona una arquitectura de referencia que permite hacer una
comparación más formal de los diferentes tipos de sistemas de punto a punto.
Androutsellis-Theotokis y Spinellis (2004) proporcionan una explicación desde una
perspectiva de distribución de contenidos.
8.4 Arquitecturas estructuradas de punto a punto
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 empleados: 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 contenidos
solicitados a los clientes. En la Internet actual, los clientes incluyen navegadores web,
clientes de chat en línea y clientes de correo electrónico, 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 dedicada. Los servidores dedicados y
clientes no existen, ya que cada peer puede tomar el papel tanto de servidor como de
cliente al mismo tiempo. Una ventaja 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

lOMoARcPSD|5217480

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. 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 servicios a otros procesos similares
en otros peers.
En una arquitectura estructurada de punto a punto, la red sobrepuesta se construye
mediante un procedimiento determinista. Por mucho, el procedimiento más utilizado es el
de organizar los procesos a través de una tabla hash distribuida (DHT). En un sistema
basado en una DHT, a los elementos de datos se les asigna una llave aleatoria a partir de
un identificador grande, digamos un identificador de 128 o de 160 bits. De igual manera,
a los nodos del sistema también se les asigna un número aleatorio a partir del propio
espacio identificador. La esencia de todo sistema basado en una DHT es, entonces,
implementar un esquema eficiente y determinista que sólo mapee la llave de un elemento
de datos hacia el identificador de un nodo, basándose en cierta distancia métrica
(Balakrishnan, 2003). Algo más importante todavía es que, al buscar un elemento de
datos, la dirección de red del nodo responsable de ese elemento de datos es devuelta. En
efecto, esto se logra enrutando una petición de un elemento de datos hacia el nodo
responsable. Por ejemplo, en el sistema Chord (Stoica y cols., 2003), los nodos están
organizados lógicamente en un anillo de tal forma que un elemento de datos con llave k
se mapea hacia el nodo con el identificador más pequeño id ≥ k. El nodo se conoce como
sucesor de la llave k, y se denota como succ(k). Para buscar realmente un elemento de
datos, una aplicación que se ejecute en un nodo cualquiera llamaría entonces a la función
LOOKUP(k), la cual posteriormente devolvería la dirección de la red de succ(k). En ese

lOMoARcPSD|5217480

punto, la aplicación puede contactar al nodo para obtener una copia del elemento de
datos.
Se organizan por sí mismos los nodos en una red sobrepuesta, o, en otras palabras, en la
gestión de membresía. En lo que veremos enseguida, es importante advertir que buscar
una llave no sigue la organización lógica de nodos en cambio cada nodo establecerá
atajos hacia otros nodos, de tal manera que las búsquedas pueden realizarse en cierto
número de pasos O (log(N)), donde N es la cantidad de nodos que participan en la
superposición. Ahora consideremos nuevamente el sistema Chord. Cuando un nodo
quiere unirse al sistema, comienza por generar un identificador aleatorio, id. Observe que
si el espacio identificador es lo suficientemente grande, entonces proporcionar el
generador del número aleatorio es de buena calidad; la probabilidad de generar un
identificador que ya está asignado a un nodo real es cercana a cero. Entonces, el nodo
puede simplemente realizar la búsqueda en un id, lo cual devolverá la dirección de la red
de succ(id). En ese punto, el nodo de unión puede simplemente contactar a succ(id) y a su
predecesor, e insertarse él mismo en el anillo. Desde luego, este esquema requiere que
cada nodo también almacene información sobre su predecesor. La inserción provoca
además que cada elemento de datos, cuya llave está ahora asociada con el nodo id, sea
transferido desde succ(id). En términos sencillos: el id del nodo informa su punto de
inicio a su predecesor y a su sucesor, y transfiere sus elementos de datos a succ(id). En
otros sistemas basados en una DHT se siguen métodos similares. Como ejemplo,
consideremos la CAN (Content Addresable Network; red de contenido direccionable)
descrita en Ratnasamy y colaboradores (2001). CAN utiliza un espacio d-dimensional de
coordenadas cartesianas, el cual es dividido completamente entre todos los nodos que

lOMoARcPSD|5217480

participan en el sistema. A manera de ejemplo, consideremos sólo el caso bidimensional
que aparece en la figura 2-8.
La figura 2-8(a) muestra cómo el espacio bidimensional [0,1][0,1] se divide en seis

nodos. Cada nodo tiene una región asociada. Cada elemento de datos organizado en CAN
se asignará a un único punto de datos de este espacio, después de lo cual también queda
claro qué nodo es responsable de ese dato (y se ignoran los elementos de datos que caen
en el límite de múltiples regiones, para ello se utiliza una regla de asignación
determinista). Cuando un nodo P quiere unirse a un sistema CAN, éste elige un punto
cualquiera del espacio coordenado, y posteriormente busca al nodo Q en cuya región cae
ese punto. Esta búsqueda se logra a través del enrutamiento basado en posiciones.
Después el nodo Q divide su región en dos mitades, y una mitad se asigna al nodo P. Los
nodos rastrean a sus vecinos, es decir, a los nodos responsables de regiones adyacentes.
Cuando una región se divide, el nodo P que se une puede saber fácilmente quiénes son
sus nuevos vecinos preguntando al nodo Q. Como en Chord, los elementos de datos de
los que el nodo P ahora es responsable se transfieren desde el nodo Q. Salir es un poco
más problemático en CAN. Supongamos que en la figura 2-8 sale el nodo que tiene las
coordenadas (0.6, 0.7). Su región será asignada a uno de sus vecinos, digamos al nodo

lOMoARcPSD|5217480

ubicado en (0.9, 0.9), pero es claro que no puede hacerse con tan sólo fusionarla y
obtener un rectángulo. En este caso, el nodo en (0.9, 0.9) simplemente se encargará de
esa región e informará a los antiguos vecinos sobre este hecho. Desde luego, esto puede
ocasionar una división menos simétrica del espacio coordenado, y es por esta razón que
periódicamente se inicia un proceso en segundo plano para volver a dividir todo el
espacio.
8.5 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.

lOMoARcPSD|5217480

• Mayor robustez del sistema.Paradigma peer-to-peer
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 a continuación 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 superposición. La red superpuesta construye túneles lógicas entre pares de nodos
con el fin de implementar su propio mecanismo de enrutamiento para transportar sus
mensajes. Ejemplo de una red superpuesta peer-to-peer

lOMoARcPSD|5217480

lOMoARcPSD|5217480
• ¿Qué es un Sistema
Distribuido?
Un sistemas distribuido es un
conjunto complejo de piezas de
software cuyos

lOMoARcPSD|5217480
8.6 Especificaciones P2P descentralizados
- Todos los nodos con la misma funcionalidad

- Tiene una Red superpuesta de topología arbitraria
- Nodos intercambian conocimiento de otros nodos “vecinos”
- Localización de recursos por “inundación”
– Alta: nodo N obtiene de alguna forma direcciones de nodos de red
– A partir de entonces intercambian periódicamente información de “vecinos”
– Permite mantenimiento de red lógica aunque implica sobrecarga
– Publicar: NOP

lOMoARcPSD|5217480

– Buscar: N propaga petición a vecinos y éstos a los suyos.
– Uso de TTL para limitar propagación pero impide encontrar recursos
–Descargar: N pide recurso al nodo que lo posee
- Problemas de rendimiento y escalabilidad.
8.7 Conclusiones
• Los nodos actúan como cliente y como servidor
• No existe un servidor central que maneje las conexiones en red
• No hay un enrutador central que sirva como nodo y administre las direcciones
8.8 Recomendaciones
• Cada nodo debe ejecutar una copia de dicha aplicación.
• Cada cliente ponga a disposición de otros clientes sus recursos configurado por
el usuario.
• Evitar tratar de sincronizar totalmente los distintos nodos no se asume la
existencia de un reloj físico global.

lOMoARcPSD|5217480

8.9 Bibliografía
-Dr. Roberto Cárdenas. Curso: Sistemas Distribuidos I. Obtenido de Web site:
http://cryptomex.org/SlidesDist/ArquiSistDist.pdf
-Santo Tomas. Arquitectura de Software. Obtenido de Web site: SlideShare
https://es.slideshare.net/JesusCamposVillar/arquitectura-software-28426208?qid=d65f1d0d-
523e-4fb0-b982-375bef9f9d02&v=&b=&from_search=67
- Andrews S.Tanenbaum Maarten Van Steen .Sistemas distribuidos principios y paradigmas.
Obtenido de Web site:
https://www.academia.edu/21420808/SISTEMAS_DISTRIBUIDOS_SISTEMAS_DISTRIBUIDOS_Pri
ncipios_y_Paradigmas
- Fernando Pérez Costoya.Arquitectura de los sistemas distribuidos2. Obtenido de Web site:
http://laurel.datsi.fi.upm.es/_media/docencia/asignaturas/sd/arquitecturas_parte2-1pp.pdf
-Francisco de Asís López Fuentes. Sistemas Distribuidos. Obtenido de Web site:

http://dccd.cua.uam.mx/libros/archivos/03IXStream_sistemas_distribuidos.pdf

pc1 Informe Final SD CGT Grupo 3

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

pc1 Informe Final SD CGT Grupo 3

Cargado por

Copyright:

Formatos disponibles

lOMoARcPSD|5217480

PC1 Informe Final SD-CGT Grupo 3

Sistemas Distribuidos (Universidad Tecnológica del Perú)

UNIVERSIDAD TECNOLÓGICA DEL PERÚ

INGENIERÍA DE SISTEMAS E INFORMÁTICA

TRABAJO GRUPAL - PRACTICA N°1

SISTEMAS DISTRIBUIDOS ARQUITECTURAS

Curso: Sistemas Distribuidos

1. Torres Quiroz Henry Isvel

2. Luis Angel Ramirez Revilla

3. Villa Quiste Jossy

4. Marin Concha Fernández, Carlos

Descargado por Jose Rojas (joserm18@yahoo.es)

Descargado por Jose Rojas (joserm18@yahoo.es)

La arquitectura que se impone en esta nueva etapa es la arquitectura web, basada en el

Descargado por Jose Rojas (joserm18@yahoo.es)

 Arquitecturas centralizadas Desarrollo de aplicaciones de capas.

El objetivo de una arquitectura es asegurar que la estructura reúna presentes y futuras

Todos los tipos de sistemas distribuidos tienen características básicas comunes. Un

En este capítulo describiremos los principales modelos arquitectónicos de los sistemas

Los sistemas distribuidos son generalmente piezas complejas de software cuyos

Descargado por Jose Rojas (joserm18@yahoo.es)

que los sistemas distribuidos dependerán mayormente de los componentes de software

Cuando se construye un sistema distribuido, no se persigue la creación de una topología

Una característica sencilla es la gran cantidad tanto de ordenadores como de millones

En la actualidad, los sistemas distribuidos están cada vez más presentes en

Descargado por Jose Rojas (joserm18@yahoo.es)

Prácticamente todos los grandes sistemas informáticos son en la actualidad

¿Y que es un Sistema Distribuido?

“Un sistema distribuido es una colección de ordenadores autónomos enlazados

"Conjunto de computadores independientes que se muestran al usuario como un

Descargado por Jose Rojas (joserm18@yahoo.es)

Entonces, un sistema distribuido es un sistema de información en el cual las

1. Compartir recursos. Un sistema distribuido permite compartir recursos

Descargado por Jose Rojas (joserm18@yahoo.es)

1. Complejidad. Los sistemas distribuidos son más complejos que los

5. Arquitectura de Sistemas Distribuidos

La implementación de un sistema distribuido requiere de la división de aplicaciones,

Descargado por Jose Rojas (joserm18@yahoo.es)

Es por ello, que vamos a mencionar la diferencia entre la arquitectura de software y

¿Qué es una Arquitectura?

Es el Arte de ordenar las superficies y volúmenes en un espacio para habitación humana,

Figura N°2 - Katu Arkonada (2011), Estilos Arquitectónicos

La Arquitectura de Software es un conjunto de patrones y abstracciones

Descargado por Jose Rojas (joserm18@yahoo.es)

“La arquitectura de software, tiene que ver con el diseño y la implementación de

4.1.1 Estilos (Modelos) Arquitectónicos

¿Qué es un estilo Arquitectónico?

Se define un estilo arquitectónico como el medio de expresión que aparece en

Un estilo arquitectónico típicamente define un vocabulario de tipos para

Entonces decimos que el estilo arquitectónico de un sistema distribuido está

Descargado por Jose Rojas (joserm18@yahoo.es)

componentes con los conectores y las restricciones que definen la integración

Los estilos arquitectónicos más importantes son:

Figura N°3 - Roberto Gómez (2018), Arquitectura de los sistemas distribuidos

Descargado por Jose Rojas (joserm18@yahoo.es)

En esencia, cada objeto corresponde a lo que hemos definido como

Figura N°4 - Roberto Gómez (2018), Arquitectura de los sistemas distribuidos

Figura N°5 - Roberto Gómez (2018), Arquitectura de los sistemas distribuidos

Descargado por Jose Rojas (joserm18@yahoo.es)

Figura N°6 - Roberto Gómez (2018), Arquitectura de los sistemas distribuidos

4.2 Arquitectura de Sistema

Ya que se ha discutido brevemente sobre algunos estilos arquitectónicos comunes,