SlideShare une entreprise Scribd logo
1  sur  18
ARQUITECTURA DE SOFTWARE
MODELOS DE ARQUITECTURA
Manuel Campos Villar
14/11/2013
Índice
Portada

1

Índice

2

Introducción

3

¿Qué es la Arquitectura de Software?

4

Modelo de Arquitectura Centralizada

5

Modelo de Arquitectura Distribuido

6/7

Modelo de Arquitectura Servidor de Archivos

8/9

Modelo de Arquitectura Cliente / Servidor

10/14

Modelo de Arquitectura Peer to Peer

15/16

Conclusión

17

Bibliografía

18

2
Introducción
En los inicios de la informática, la programación se consideraba un arte y se
desarrollaba como tal, debido a la dificultad que entrañaba para la mayoría de las
personas, pero con el tiempo se han ido descubriendo y desarrollando formas y
guías generales, con base a las cuales se puedan resolver los problemas. A estas,
se les ha denominado Arquitectura de Software, porque, a semejanza de los
planos de un edificio o construcción, estas indican la estructura, funcionamiento e
interacción entre las partes del software. En el libro "Anintroductionto Software
Architecture", David Garlan y Mary Shaw definen que la Arquitectura es un nivel de
diseño que hace foco en aspectos "más allá de los algoritmos y estructuras de
datos de la computación; el diseño y especificación de la estructura global del
sistema es un nuevo tipo de problema".

3
¿Qué es la Arquitectura de Software?
La arquitectura de software define, de manera abstracta, los componentes
que llevan a cabo alguna tarea de computación, sus interfaces y la comunicación
entre ellos. Toda arquitectura debe ser implementable en una arquitectura física,
que consiste simplemente en determinar qué computadora tendrá asignada cada
tarea.
“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.”
(1)Kruchten, Philippe

(1)

PhilippeKruchten (nacido en 1952) es un ingeniero canadiense de software, y el profesor de Ingeniería de
Software de la Universidad de British Columbia en Vancouver, Canadá, conocido como director de desarrollo de
proceso (RUP) en Rational Software, y desarrollador del 4 +1.

4
1. Modelo de Arquitectura Centralizada
Esta arquitectura se desarrolla cuando el software se estructura en grupos
funcionales muy acoplados. No hay distribución, tanto a nivel físico como a nivel
lógico. Está formado por la presentación, los datos y el procesamiento. Es una
arquitectura rígida de programación en un solo computador.

Es la arquitectura de los primeros sistemas operativos constituidos
fundamentalmente por un solo programa compuesto de un conjunto de rutinas
entrelazadas de tal forma que cada una puede llamar a cualquier otra.
Características de la arquitectura centralizada o monolítica.
Construcción del programa final a base de módulos compilados
separadamente que se unen a través del ligado.
Buena definición de parámetros de enlace entre las distintas rutinas
existentes, que puede provocar mucho acoplamiento.
Carecen de protecciones y privilegios al entrar a rutinas que manejan
diferentes aspectos de los recursos de la computadora, como memoria,
disco, etc.
Generalmente están hechos a medida, por lo que son eficientes y rápidos
en su ejecución y gestión, pero por lo mismo carecen de flexibilidad para
soportar diferentes ambientes de trabajo o tipos de aplicaciones.
Ventajas
Muy eficiente ya que se producen pocos cambios de contexto.
Gran nivel de seguridad.
Fácil administración.
Desventajas
Difícil de depurar, un error en una función se puede manifestar en otra
distinta.
Alto Costo.
Maquina Servidora muy cargada.
Difícil de ampliar.

5
2. Modelo de Arquitectura Sistemas Distribuidos
Prácticamente todo los grandes sistemas informáticos son en la actualidad
sistemas distribuidos. Un sistema distribuido es un sistema en el que el
procesamiento de información se distribuye sobre varias computadoras en vez de
estar confinado en una única máquina. Obviamente, la ingeniería de sistemas
distribuidos tiene mucho en común con la ingeniería de cualquier otro software,
pero existen cuestiones específicas que deben tenerse en cuenta cuando se
diseña este tipo de sistemas.
Se identifican las siguientes ventajas del uso de una aproximación distribuida
para el desarrollo de sistemas:
Compartición de recursos: Un sistema distribuido permite compartir
recursos hardware y software – como discos, impresoras, ficheros y
compiladores – que se asocian con computadoras de una red.
Apertura: Los sistemas distribuidos son normalmente sistemas abiertos, lo
que significa que se diseñan sobre protocolos estándar que permiten
combinar equipamiento y software de diferentes vendedores.
Concurrencia. En un sistema distribuido, varios procesos pueden operar al
mismo tiempo sobre diferentes computadoras de la red. Estos procesos
pueden (aunque no necesariamente) comunicarse con otros durante su
funcionamiento normal.
Escalabilidad: Al menos en principio, los sistemas distribuidos son
escalables en tanto que la capacidad del sistema puede incrementarse
añadiendo nuevos recursos para cubrir nuevas demandas sobre el sistema.
En la práctica, la red que una las computadoras individuales del sistema
puede limitar la escalabilidad del sistema. Si se añaden muchas
computadoras nuevas, entonces la capacidad de la red puede resultar
inadecuada.
Tolerancia a defectos: La disponibilidad de varias computadoras y el
potencial para reproducir información significa que los sistemas distribuidos
pueden ser tolerantes a algunos fallos de funcionamiento del hardware y del
software. En la mayoría de los sistemas distribuidos, se puede proporcionar
un servicio degradado cuando ocurren fallos de funcionamiento; una
completa pérdida de servicio sólo ocurre cuando existe un fallo de
funcionamiento en la red.
Para sistemas organizacionales a gran escala, estas ventajas significan que los
sistemas distribuidos han reemplazado ampliamente a los sistemas heredados
centralizados que fueron desarrollados en los años 80 y 90. Sin embargo,
comparados con sistemas que se ejecutan sobre un único procesador o un clúster
de procesadores, los sistemas distribuidos tienen varias desventajas:
Complejidad: Los sistemas distribuidos son más complejos que los
sistemas centralizados. Esto 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.
Seguridad: Puede accederse al sistema desde varias computadoras
diferentes, y el tráfico en la red puede estar sujeto a escuchas indeseadas.
Esto hace más difícil el asegurar que la integridad de los datos en el
sistema se mantenga y que los servicios del sistema no se degraden por
ataques de denegación de servicio.

6
Manejabilidad: Las computadoras en un sistema pueden ser de diferentes
tipos y pueden ejecutar versiones diferentes de sistemas operativos. Los
defectos en una máquina pueden propagarse a otras máquinas con
consecuencias inesperadas. Esto significa que se requiere más esfuerzo
para gestionar y mantener el funcionamiento del sistema.
Impredecible: Como todos los usuarios de la WWW saben, 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 con mucha rapidez, el tiempo requerido para
responder a una petición de usuario puede variar drásticamente de una
petición a otra.
El reto para el diseño es diseñar el software y hardware para proporcionar
características deseables a los sistemas distribuidos y, al mismo tiempo, minimizar
los problemas inherentes a estos sistemas. Para hacer eso, se necesita
comprender las ventajas y desventajas de las diferentes arquitecturas de sistemas
distribuidos. Aquí se tratan dos tipos genéricos de arquitecturas de sistemas
distribuidos:
1. Arquitectura cliente-servidor. En esta aproximación, el sistema puede ser
visto como un conjunto de servicio que se proporcionan a los clientes que
hacen uso de dichos servicios. Los servidores y los clientes se tratan de
forma diferente en estos sistemas.
2. Arquitecturas de objetos distribuidos. En este caso, no hay distinción entre
servidores y clientes, y el sistema puede ser visto como un conjunto de
objetos que interaccionan cuya localización es irrelevante. No hay distinción
entre un proveedor de servicios y el usuario de estos servicios.
Ambas arquitecturas se usan ampliamente en la industria, pero la distribución
de las aplicaciones generalmente tiene lugar dentro de una única organización. La
distribución soportada es, por lo tanto, inter organizacional. Aquí también se
plantean dos tipos más de arquitecturas distribuidas que son más adecuadas para
la distribución inter organizacional: Arquitectura de sistemas peer-to-peer (p2p) y
Arquitecturas orientadas a servicios.Los componentes en un sistema distribuido
pueden implementarse en diferentes lenguajes de programación y pueden
ejecutarse en tipos de procesadores completamente diferentes. Los modelos de
datos, la representación de la información y los protocolos de comunicación
pueden ser todos diferentes. Un sistema distribuido, por lo tanto, requiere software
que pueda gestionar estas partes distintas, y asegurar que dichas partes se
puedan comunicar e intercambiar datos. El término middleware se usa para hacer
referencia a ese software; se sitúa en medio de los diferentes componentes
distribuidos del sistema.
El middleware es un software de propósito general que normalmente se
compra como un componente comercial más que escribirse especialmente por los
desarrolladores de la aplicación. Ejemplos de middleware son software para
gestionar comunicaciones con bases de datos, administradores de transacciones,
convertidores de datos y controladores de comunicación.
Los sistemas distribuidos se desarrollan normalmente utilizando una
aproximación orientada a objetos. Estos sistemas están formados por partes
independientes pobremente integradas, cada una de las cuales pueden
interaccionar directamente con los usuarios o con otras partes del sistema.
Algunas partes del sistema pueden tener que responder a eventos
independientes. Los objetos software reflejan estas características; por lo tanto,
son abstracciones naturales para los componentes de sistemas distribuidos.
7
3. Modelo de Arquitectura Servidor de Archivos
El concepto de " Servidor de Archivos" 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.
El Modelo de Servidor de Archivos distingue cliente de sistemas de servidor de
sistemas, que se comunican sobre a red de ordenadores. Un uso del servidor de
cliente es a sistema distribuido abarcado de cliente y de software del servidor. Un
proceso del software del cliente puede iniciar una sesión de la comunicación,
mientras que el servidor espera peticiones de cualquier cliente.
El cliente/servidor describe la relación entre dos programas de computadora en
los cuales un programa, el cliente, marcas una petición del servicio de otro
programa, el servidor, que satisface la petición. Aunque la idea del cliente/del
servidor se puede utilizar por programas dentro de una sola computadora, es una
idea más importante en una red. En una red, elmodelo del cliente/del servidor
proporciona una manera conveniente de interconectar eficientemente los
programas que se distribuyen a través de diversas localizaciones. El modelo del
cliente/del servidor tiene convertido de las ideas centrales del computar de la red.
La mayoría de los usos de negocio que son escritos hoy utilizan el modelo del
cliente/del servidor. Haga tan los protocolos de uso principal del Internet, por
ejemplo HTTP, Smtp, Telnet, DNS, etc. En la comercialización, el término ha sido
utilizado para distinguir computar distribuido por computadoras dispersadas más
pequeñas de computar centralizado “monolítico” de los ordenadores centrales.
Pero esta distinción ha desaparecido en gran parte como chasis y sus usos
también han dado vuelta al modelo del cliente/del servidor y se convierten en parte
de computar de la red.
Cada un caso de cliente el software puede enviar datos peticiones con uno o
más conectó servidor. Alternadamente, los servidores pueden aceptar estas
peticiones, procesarlas, y volver la información solicitada al cliente. Aunque este
concepto se puede solicitar una variedad de razones a muchas diversas clases de
usos, la arquitectura sigue siendo fundamental igual.
El tipo más básico de servidor de cliente arquitectura emplea solamente dos
tipos de anfitriones: clientes y servidores. Este tipo de arquitectura se refiere a
veces como de dos niveles. Permite que los dispositivos compartan archivos y
recursos
Ventajas
En la mayoría de los casos, una arquitectura del servidor de cliente permite
los papeles y las responsabilidades de un sistema de cálculo de ser
distribuido entre varias computadoras independientes que se sepan el uno
al otro solamente a través de una red. Esto crea una ventaja adicional a
esta arquitectura: mayor facilidad del mantenimiento. Por ejemplo, es
posible substituir, reparar, aumentar, o aún volver a poner un servidor
mientras que sus clientes siguen siendo inconscientes e inafectados por
ese cambio. Esta independencia del cambio también se refiere como
encapsulación.
Todos los datos se almacenan en los servidores, que tienen generalmente
controles lejos mayores de la seguridad que la mayoría de los clientes. Los
servidores pueden mejorar el acceso y recursos del control, para garantizar
que solamente esos clientes con los permisos apropiados pueden tener
acceso y cambiar a datos.
Puesto que se centraliza el almacenaje de datos, las actualizaciones a esos
datos son lejos más fáciles de administrar que sea posible bajo paradigma

8
del P2P. Bajo arquitectura del P2P, las actualizaciones de los datos pueden
necesitar ser distribuido y aplicado a cada “par” en la red, que es
desperdiciadora de tiempo y error-prone, como puede haber millares o aún
millones de pares.
Muchas tecnologías maduras del servidor de cliente son ya que fueron
diseñadas para asegurar seguridad, “amistad disponible” del interfaz
utilizador, y facilidad de empleo.
Funciona con diversos clientes múltiples de diversas capacidades.
Desventajas
La congestión del tráfico en la red ha sido una edición desde el inicio del
paradigma del servidor de cliente. Mientras que el número de las peticiones
simultáneas del cliente a un servidor dado aumenta, el servidor puede
sobrecargarse seriamente. Ponga en contraste eso con una red del P2P,
donde su anchura de banda aumenta realmente como se agregan más
nodos, desde la anchura de banda total de la red del P2P se puede
computar áspero como la suma de las anchuras de banda de cada nodo en
esa red.
El paradigma del servidor de cliente carece la robustez de una buena red
P2P. Debajo del servidor de cliente, un fall crítico del servidor, peticiones de
los clientes que no pueden ser satisfechas. En redes P2P, los recursos se
distribuyen generalmente entre muchos nodos. Aunque unos o más nodos
salen y abandonan un archivo que descarga, por ejemplo, los nodos
restantes si inmóvil tenga los datos necesitados para terminar la
transferencia directa.

9
4. Modelo de Arquitectura Cliente/Servidor
Sistema distribuido entre múltiples procesadores donde hay clientes que
solicitan servicios y servidores que los proporcionan. Separa los servicios situando
cada uno en su plataforma más adecuada.
Desde el punto de vista funcional, se puede definir la computación
Cliente/Servidor como una arquitectura distribuida que permite a los usuarios
finales obtener acceso a la información en forma transparente aún en entornos
multiplataforma.
En el modelo cliente servidor, el cliente envía un mensaje solicitando un
determinado servicio a un servidor (hace una petición), y este envía uno o varios
mensajes con la respuesta (provee el servicio).
En un sistema distribuido cada máquina puede cumplir el rol de servidor para
algunas tareas y el rol de cliente para otras.
Esta arquitectura consiste básicamente en un cliente que realiza peticiones a
otro programa (el servidor) que le da respuesta. Aunque esta idea se puede
aplicar a programas que se ejecutan sobre una sola computadora es más
ventajosa en un sistema operativo multiusuario distribuido a través de una red de
computadoras.
En esta arquitectura la capacidad de proceso está repartida entre los clientes y
los servidores, aunque son más importantes las ventajas de tipo organizativo
debidas a la centralización de la gestión de la información y la separación de
responsabilidades, lo que facilita y clarifica el diseño del sistema.
La separación entre cliente y servidor es una separación de tipo lógico, donde
el servidor no se ejecuta necesariamente sobre una sola máquina ni es
necesariamente un sólo programa. Los tipos específicos de servidores incluyen los
servidores web, los servidores de archivo, los servidores del correo, etc. Mientras
que sus propósitos varían de unos servicios a otros, la arquitectura básica seguirá
siendo la misma.
Un sistema cliente/servidor funciona tal como se detalla en el siguiente
diagrama:

El cliente envía una solicitud al servidor mediante su dirección IP y el
puerto, que está reservado para un servicio en particular que se ejecuta en
el servidor.
El servidor recibe la solicitud y responde con la dirección IP del equipo
cliente y su puerto.
El término cliente/servidor es originalmente aplicado a la arquitectura de
software que describe el procesamiento entre dos o más programas: una
aplicación y un servicio soportante.
10
IBM define al modelo Cliente/Servidor. "Es la tecnología que proporciona al
usuario final el acceso transparente a las aplicaciones, datos, servicios de
cómputo o cualquier otro recurso del grupo de trabajo y/o, a través de la
organización, en múltiples plataformas. El modelo soporta un medio ambiente
distribuido en el cual los requerimientos de servicio hechos por estaciones de
trabajo inteligentes o "clientes'', resultan en un trabajo realizado por otros
computadores llamados servidores".
Características de la arquitectura cliente/servidor.
Combinación de un cliente que interactúa con el usuario, y un servidor que
interactúa con los recursos compartidos. El proceso del cliente proporciona
la interfaz entre el usuario y el resto del sistema. El proceso del servidor
actúa como un motor de software que maneja recursos compartidos tales
como bases de datos, impresoras, módems, etc.
Las tareas del cliente y del servidor tienen diferentes requerimientos en
cuanto a recursos de cómputo como velocidad del procesador, memoria,
velocidad y capacidades del disco e input-output devices.
Se establece una relación entre procesos distintos, los cuales pueden ser
ejecutados en la misma máquina o en máquinas diferentes distribuidas a lo
largo de la red.
Existe una clara distinción de funciones basada en el concepto de
"servicio", que se establece entre clientes y servidores.
La relación establecida puede ser de muchos a uno, en la que un servidor
puede dar servicio a muchos clientes, regulando su acceso a recursos
compartidos.
Los clientes corresponden a procesos activos en cuanto a que son éstos los
que hacen peticiones de servicios a los servidores. Estos últimos tienen un
carácter pasivo ya que esperan las peticiones de los clientes.
No existe otra relación entre clientes y servidores que no sea la que se
establece a través del intercambio de mensajes entre ambos. El mensaje es
el mecanismo para la petición y entrega de solicitudes de servicio.
El ambiente es heterogéneo. La plataforma de hardware y el sistema
operativo del cliente y del servidor no son siempre la misma. Precisamente
una de las principales ventajas de esta arquitectura es la posibilidad de
conectar clientes y servidores independientemente de sus plataformas.
El concepto de escalabilidad tanto horizontal como vertical es aplicable a
cualquier sistema Cliente/Servidor. La escalabilidad horizontal permite
agregar más estaciones de trabajo activas sin afectar significativamente el
rendimiento. La escalabilidad vertical permite mejorar las características del
servidor o agregar múltiples servidores.

11
4.1.

Modelo de arquitectura cliente/servidor

La arquitectura cliente-servidor es una aplicación que se modela como un
conjunto de servicios proporcionadospor los servidores y un conjunto de clientes
que usan estos servicios (Orfali yHarkey, 1998). Los clientes necesitan conocer
qué servidores están disponibles, pero normalmenteno conocen la existencia de
otros clientes. Clientes y servidores son procesos diferentes,que representa un
modelo lógico de una arquitecturadistribuida cliente-servidor.

Sistema Cliente / Servidor

La arquitectura cliente-servidor más simple se denomina arquitectura clienteservidor dedos capas, en la que una aplicación se organiza como un servidor (o
múltiples servidores idénticos)y un conjunto de clientes. Las arquitecturas
cliente/servidorde dos capas pueden ser de dos tipos:
1. Modelo de cliente ligero (thin-client). En un modelo de cliente ligero, todo
el procesamientode las aplicaciones y la gestión de los datos se llevan a
cabo en el servidor. Elcliente simplemente es responsable de la capa de
presentación del software.
2. Modelo de cliente rico (fat-client). En este modelo, el servidor solamente
es responsablede la gestión de los datos. El software del cliente
implementa la lógica de la aplicacióny las interacciones con el usuario del
sistema.
Aplicaciones simples
No requieren una gran Base de Datos compartida, pueden ser elaboradas
solamente en el Cliente.
Aplicaciones complejas
Exigen dos capas, una para la aplicación del usuario (Cliente) y otra para la base
de datos (Servidor).
Arquitectura de 2 niveles:
1. Generalmente usa los modelos de función distribuida o datos distribuidos.
2. Muy productivo.
3. Distribución no flexible.
4. Dependiente del suministrador.
Arquitectura de 3 niveles:
La Arquitectura de tres niveles es lógica y no física. Se preocupa con las funciones
y no con la implantación.

12
La Arquitectura puede ser utilizada para desarrollar sistemas Centralizados o
Distribuidos.
La Arquitectura facilitará la distribución de los componentes del sistema.
1. Modelo presentación-negocio-datos.
2. Distribución flexible.
3. Sistema abierto. No dependiente.

Beneficios:
Estructura para la elaboración de aplicativos flexibles y fáciles de modificar,
según las necesidades del negocio (cambio).
Alto nivel de reutilización del software y datos.
Fácil y rápido desarrollo de aplicativos grandes y complejos, para las
transacciones y los SSD.
Fácil y rápido desarrollo de sistemas distribuidos que dan soporte a la
administración central y a equipos auto-gestionados.

Ventajas
Centralización del control: los accesos, recursos y la integridad de los datos
son controlados por el servidor de forma que un programa cliente
defectuoso o no autorizado no pueda dañar el sistema. Esta centralización
también facilita la tarea de poner al día datos u otros recursos (mejor que
en las redes P2P).
Escalabilidad: se puede aumentar la capacidad de clientes y servidores por
separado. Cualquier elemento puede ser aumentado (o mejorado) en
cualquier momento, o se pueden añadir nuevos nodos a la red (clientes y/o
servidores).
Fácil mantenimiento: al estar distribuidas las funciones y responsabilidades
entre varios ordenadores independientes, es posible reemplazar, reparar,
actualizar, o incluso trasladar un servidor, mientras que sus clientes no se
verán afectados por ese cambio (o se afectarán mínimamente). Esta
independencia de los cambios también se conoce como encapsulación.
Existen tecnologías, suficientemente desarrolladas, diseñadas para el
paradigma de C/S que aseguran la seguridad en las transacciones, la
amigabilidad del interfaz, y la facilidad de empleo.
Desventajas
La congestión del tráfico ha sido siempre un problema en el paradigma de
C/S. Cuando una gran cantidad de clientes envían peticiones simultaneas al
mismo servidor, puede ser que cause muchos problemas para éste (a
mayor número de clientes, más problemas para el servidor). Al contrario, en
las redes P2P como cada nodo en la red hace también de servidor, cuantos
más nodos hay, mejor es el ancho de banda que se tiene.
El paradigma de C/S clásico no tiene la robustez de una red P2P. Cuando
un servidor está caído, las peticiones de los clientes no pueden ser
satisfechas. En la mayor parte de redes P2P, los recursos están
generalmente distribuidos en varios nodos de la red. Aunque algunos

13
salgan o abandonen la descarga; otros pueden todavía acabar de
descargar consiguiendo datos del resto de los nodos en la red.
El software y el hardware de un servidor son generalmente muy
determinantes. Un hardware regular de un ordenador personal puede no
poder servir a cierta cantidad de clientes. Normalmente se necesita
software y hardware específico, sobre todo en el lado del servidor, para
satisfacer el trabajo. Por supuesto, esto aumentará el coste.
El cliente no dispone de los recursos que puedan existir en el servidor. Por
ejemplo, si la aplicación es una Web, no podemos escribir en el disco duro
del cliente o imprimir directamente sobre las impresoras sin sacar antes la
ventana previa de impresión de los navegadores.

14
5. Arquitectura Peer to Peer
También se pueden tomar dos tipos más de arquitecturas distribuidas que son
más adecuadas para la distribución inter organizacional: Arquitectura de sistemas
peer-to-peer (p2p) y Arquitecturas orientadas a servicios. A continuación nos
centraremos en los dos tipos principales de arquitecturas lógicas de redque se
pueden usar: arquitecturas descentralizadas y arquitecturas semicentralizadas.
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 hacen 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 nodos están embebidos en la propia
aplicación, y cada nodo debe ejecutar una copia de dicha aplicación.
Usted puede ver 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 otronodo, podría conectarse con él, y podría intercambiar datos. En la
práctica, por supuesto, esto es imposible, ya que los nodos se organizan dentro de
«localidades» con algunos nodos queactúan como puentes a otras localidades de
nodos.
Clasificación de P2P:
Redes P2P Centralizadas:
Este tipo de red P2P se basa en una arquitectura monolítica en la que todas
las transacciones se hacen a través de un único servidor que sirve de punto de
enlace entre dos nodos y que, a la vez, almacena y distribuye los nodos donde se
almacenan los contenidos.
Poseen una administración muy dinámica y una disposición más
permanente de contenido. Sin embargo, está muy limitada en la privacidad de los
usuarios y en la falta de escalabilidad de un sólo servidor, además de ofrecer
problemas en puntos únicos de fallo, situaciones legales y enormes costos en el
mantenimiento, así como el consumo de ancho de banda.
Una red de este tipo reúne las siguientes características:
Se rige bajo un único servidor, que sirve como punto de enlace entre nodos
y como servidor de acceso al contenido, el cual distribuye a petición de los
nodos.
Todas las comunicaciones (como las peticiones y encaminamientos entre
nodos) dependen exclusivamente de la existencia del servidor.
Algunos ejemplos de este tipo de redes son Napster y Audiogalaxy.
Redes P2P Descentralizadas:
Las redes P2P de este tipo son las más comunes, siendo las más versátiles
al no requerir de un gestiona miento central de ningún tipo, lo que permite una
reducción de la necesidad de usar un servidor central, por lo que se opta por los
mismos usuarios como nodos de esas conexiones y también como almacenadores
15
de esa información. En otras palabras, todas las comunicaciones son directamente
de usuario a usuario con ayuda de un nodo (que es otro usuario) quien permite
enlazar esas comunicaciones.
Las redes de este tipo tienen las siguientes características:
Los nodos actúan como cliente y como servidor.
No existe un servidor central que maneje las conexiones de red.
No hay un enrutador central que sirva como nodo y administre direcciones.
Algunos
ejemplos
de
una
red
Galaxy, Gnutella, Freenet y Gnutella2.

P2P

"pura"

son: Kademlia, Ares

Arquitectura p2p descentralizada
Redes P2P Centralizadas:
En este tipo de red, se puede observar la interacción entre un servidor
central que sirve como hub y administra los recursos de banda ancha,
enrutamientos y comunicación entre nodos pero sin saber la identidad de cada
nodo y sin almacenar información alguna, por lo que el servidor no comparte
archivos de ningún tipo a ningún nodo. Tiene la peculiaridad de funcionar (en
algunos casos como en Torrent) de ambas maneras, es decir, puede incorporar
más de un servidor que gestione los recursos compartidos, pero también, en caso
de que el servidor o los servidores que gestionan todo caigan, el grupo de nodos
puede seguir en contacto a través de una conexión directa entre ellos mismos, con
lo que es posible seguir compartiendo y descargando más información en
ausencia de los servidores.
Este tipo de P2P presenta las siguientes características:
Tiene un servidor central que guarda información en espera y responde a
peticiones para esa información.
Los nodos son responsables de hospedar la información (pues el servidor
central no almacena la información) que permite al servidor central
reconocer los recursos que se desean compartir, y para poder descargar
esos recursos compartidos a los usuarios que lo solicitan.
Las terminales de enrutamiento son direcciones usadas por el servidor, que
son administradas por un sistema de índices para obtener una dirección
absoluta.
Algunos
ejemplos
de
una
son BitTorrent, eDonkey y DirectConnect.

16

red

P2P

híbrida
Conclusión
Para comenzar esta conclusión podríamos decir que la arquitectura a parte del
modelado del software también juega un papel importante en otros aspectos del
desarrollo de software:
Mejora la comprensión de sistemas grandes y complejos.
Permite una mejor comunicación entre los diferentes interesados.
Mejora las posibilidades de reusó.
Proporciona planos para la construcción.
Toma en cuenta la posible evolución del sistema.
En este trabajo prácticamente todo los modelos de arquitectura pertenecen a
los sistemas distribuidos. Un sistema distribuido es un sistema en el que el
procesamiento de información se distribuye sobre varias computadoras en vez de
estar confinado en una única máquina. Y dentro de estos sistemas se encuentran
los Cliente/Servidor y P2P los cuales son muy idénticos pero gana con creces la
Arquitectura Cliente/Servidor por sus características.
En la arquitectura Cliente/Servidor se ve como los tres niveles de aplicación se
relacionan. Focaliza sobre la estructura y la adaptación. Y determina qué entra en
cada nivel y cómo la aplicación se relaciona con otras aplicaciones.
Y la Arquitectura de P2P es una red de computadoras en la que todos o
algunos aspectos funcionan sin clientes ni servidores fijos, sino una serie
de nodos que se comportan como iguales entre sí. Esto quiere decir que no hay
distinción entre cliente y servidor siendo cada un servidor y cliente al mismo
tiempo el cual se comunican directamente con otro similar.
Por otra parte la Arquitectura de Servidor de Archivos se basa en la existencia
de una a varias máquinas servidoras que almacenan datos y estaciones de trabajo
que ejecutan aplicaciones que los procesanlos clientes en este tipo de
aplicaciones son activos.
Y por último unas de las primeras arquitecturas es la centralizada que es la
más básica la cual es un único servidor que ofrece servicio a una red, pero con
limitación ya que se sobre carga el servidor demasiado pero para una pequeña red
es muy eficaz.

17
Bibliografía
http://laurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/arquitecturas_
1pp.pdf “Arquitectura de Sistemas Distribuidos”
http://www-oei.eui.upm.es/Asignaturas/BD/BD/docbd/tema/Arquitectura.pdf
“Tipos de Arquitectura”
http://cs.uns.edu.ar/~gis/ebd/Archivos/Clases/EBD%20%20Clase%2020%202004%20Color.pdf “Elementos de BD”
http://introduccionaoracle.blogspot.com/p/arquitectura-servidor-dearchivos.html “Introducción Oracle”
http://es.wikipedia.org/wiki/Cliente-servidor “Cliente-Servidor”
http://es.wikipedia.org/wiki/Bases_de_datos_distribuidas ”Sistemas
Distribuidos”
http://normalizacion-bd.blogspot.com/2012/11/5-arquitecturacentralizada.html “Sistemas Centralizados”
http://es.wikipedia.org/wiki/Arquitectura_de_software “Arquitectura de
Software”
http://ithroshuejutla.blogspot.com/ “Arquitectura de Software ”
Ingeniería del Software 7ma. Ed. - AutorIanSommerville.

18

Contenu connexe

Tendances

Unidad 1. caracterizacion de los sistemas distribuidos
Unidad 1.  caracterizacion de los sistemas distribuidosUnidad 1.  caracterizacion de los sistemas distribuidos
Unidad 1. caracterizacion de los sistemas distribuidosEManuel Torres
 
Sistema operativos distribuidos
Sistema operativos distribuidosSistema operativos distribuidos
Sistema operativos distribuidospgr95
 
Sistemas operativos distribuidos
Sistemas operativos distribuidosSistemas operativos distribuidos
Sistemas operativos distribuidosnathalyrivasdiaz
 
Sistemas operativos distribuidos
Sistemas operativos distribuidosSistemas operativos distribuidos
Sistemas operativos distribuidosVictor Reyes
 
Sistemas operativos distribuidos
Sistemas operativos distribuidosSistemas operativos distribuidos
Sistemas operativos distribuidoscarlosmax10
 
Sistemas operativos 2
Sistemas operativos 2Sistemas operativos 2
Sistemas operativos 2Chulinneitor
 
Sistemas operativos distribuidos
Sistemas operativos distribuidosSistemas operativos distribuidos
Sistemas operativos distribuidosJohn Anthony Peraza
 
Sistemas operativos distribuidos y sistemas distribuidos
Sistemas operativos distribuidos y sistemas distribuidosSistemas operativos distribuidos y sistemas distribuidos
Sistemas operativos distribuidos y sistemas distribuidoscris_bar
 
Areas donde implementamos los sistemas distribuidos
Areas donde implementamos los sistemas distribuidosAreas donde implementamos los sistemas distribuidos
Areas donde implementamos los sistemas distribuidosOLy Jimenez
 
Sistemas operativos distribuidos
Sistemas operativos distribuidosSistemas operativos distribuidos
Sistemas operativos distribuidosYesenia
 
Sistemas arquitectónicos centralizados, descentralizados e híbridos.
Sistemas arquitectónicos centralizados, descentralizados e híbridos.Sistemas arquitectónicos centralizados, descentralizados e híbridos.
Sistemas arquitectónicos centralizados, descentralizados e híbridos.Universidad de Guadalajara
 
Sistemas distribuidos
Sistemas distribuidosSistemas distribuidos
Sistemas distribuidosLuis Yallerco
 
Sistemas distribuidos
Sistemas distribuidosSistemas distribuidos
Sistemas distribuidosTensor
 
Sistemas operativos distribuidos
Sistemas operativos distribuidosSistemas operativos distribuidos
Sistemas operativos distribuidosVictor Milano
 

Tendances (20)

Unidad 1. caracterizacion de los sistemas distribuidos
Unidad 1.  caracterizacion de los sistemas distribuidosUnidad 1.  caracterizacion de los sistemas distribuidos
Unidad 1. caracterizacion de los sistemas distribuidos
 
sistemas distribuidos
sistemas distribuidossistemas distribuidos
sistemas distribuidos
 
Sistema operativos distribuidos
Sistema operativos distribuidosSistema operativos distribuidos
Sistema operativos distribuidos
 
Sistemas operativos distribuidos
Sistemas operativos distribuidosSistemas operativos distribuidos
Sistemas operativos distribuidos
 
Sistemas operativos distribuidos
Sistemas operativos distribuidosSistemas operativos distribuidos
Sistemas operativos distribuidos
 
Sistemas operativos distribuidos
Sistemas operativos distribuidosSistemas operativos distribuidos
Sistemas operativos distribuidos
 
Sistemas de información distribuidos
Sistemas de información distribuidosSistemas de información distribuidos
Sistemas de información distribuidos
 
Sistemas distribuidos
Sistemas distribuidosSistemas distribuidos
Sistemas distribuidos
 
Sistemas operativos 2
Sistemas operativos 2Sistemas operativos 2
Sistemas operativos 2
 
Trabajo Sistemas Distribuidos Oscar
Trabajo Sistemas Distribuidos OscarTrabajo Sistemas Distribuidos Oscar
Trabajo Sistemas Distribuidos Oscar
 
Sistemas operativos distribuidos
Sistemas operativos distribuidosSistemas operativos distribuidos
Sistemas operativos distribuidos
 
Sistemas operativos distribuidos y sistemas distribuidos
Sistemas operativos distribuidos y sistemas distribuidosSistemas operativos distribuidos y sistemas distribuidos
Sistemas operativos distribuidos y sistemas distribuidos
 
Aspectos de diseno
Aspectos de disenoAspectos de diseno
Aspectos de diseno
 
Areas donde implementamos los sistemas distribuidos
Areas donde implementamos los sistemas distribuidosAreas donde implementamos los sistemas distribuidos
Areas donde implementamos los sistemas distribuidos
 
Sistemas operativos distribuidos
Sistemas operativos distribuidosSistemas operativos distribuidos
Sistemas operativos distribuidos
 
Sistemas arquitectónicos centralizados, descentralizados e híbridos.
Sistemas arquitectónicos centralizados, descentralizados e híbridos.Sistemas arquitectónicos centralizados, descentralizados e híbridos.
Sistemas arquitectónicos centralizados, descentralizados e híbridos.
 
Sistemas distribuidos
Sistemas distribuidosSistemas distribuidos
Sistemas distribuidos
 
Sistemas distribuidos
Sistemas distribuidosSistemas distribuidos
Sistemas distribuidos
 
Sistemas operativos distribuidos
Sistemas operativos distribuidosSistemas operativos distribuidos
Sistemas operativos distribuidos
 
Sistemas distribuidos pnn2
Sistemas distribuidos pnn2Sistemas distribuidos pnn2
Sistemas distribuidos pnn2
 

En vedette

Gestion de la investigacion
Gestion de la investigacionGestion de la investigacion
Gestion de la investigacionEdna Rocio
 
Eval relación div. y multiplic.
Eval relación  div. y multiplic.Eval relación  div. y multiplic.
Eval relación div. y multiplic.Beny Beas
 
G6 m1-d-lesson 28-t
G6 m1-d-lesson 28-tG6 m1-d-lesson 28-t
G6 m1-d-lesson 28-tmlabuski
 
Marketing Digital para empreendedores - Eduardo Sani, CEO Uselink
Marketing Digital para empreendedores - Eduardo Sani, CEO Uselink Marketing Digital para empreendedores - Eduardo Sani, CEO Uselink
Marketing Digital para empreendedores - Eduardo Sani, CEO Uselink JET e-Commerce
 
G6 m1-d-lesson 28-s
G6 m1-d-lesson 28-sG6 m1-d-lesson 28-s
G6 m1-d-lesson 28-smlabuski
 
Personas For Outreach - State Of Search
Personas For Outreach - State Of SearchPersonas For Outreach - State Of Search
Personas For Outreach - State Of SearchZeph Snapp
 
Plano de carreira dos servidores municipais
Plano de carreira dos servidores municipaisPlano de carreira dos servidores municipais
Plano de carreira dos servidores municipaisAssmef
 
Trabajo proceso tecnologico emf
Trabajo proceso tecnologico emfTrabajo proceso tecnologico emf
Trabajo proceso tecnologico emfwetuu
 
Nota à imprensa versão final - 19.11.13
Nota à imprensa   versão final - 19.11.13Nota à imprensa   versão final - 19.11.13
Nota à imprensa versão final - 19.11.13Hélio Júnior
 

En vedette (15)

Google
GoogleGoogle
Google
 
Gestion de la investigacion
Gestion de la investigacionGestion de la investigacion
Gestion de la investigacion
 
Eval relación div. y multiplic.
Eval relación  div. y multiplic.Eval relación  div. y multiplic.
Eval relación div. y multiplic.
 
DERECHOS
DERECHOSDERECHOS
DERECHOS
 
Cursos en linea
Cursos en lineaCursos en linea
Cursos en linea
 
G6 m1-d-lesson 28-t
G6 m1-d-lesson 28-tG6 m1-d-lesson 28-t
G6 m1-d-lesson 28-t
 
Anyel
AnyelAnyel
Anyel
 
Cartelera 12 de noviembre de 2013
Cartelera 12  de noviembre de 2013Cartelera 12  de noviembre de 2013
Cartelera 12 de noviembre de 2013
 
Marketing Digital para empreendedores - Eduardo Sani, CEO Uselink
Marketing Digital para empreendedores - Eduardo Sani, CEO Uselink Marketing Digital para empreendedores - Eduardo Sani, CEO Uselink
Marketing Digital para empreendedores - Eduardo Sani, CEO Uselink
 
G6 m1-d-lesson 28-s
G6 m1-d-lesson 28-sG6 m1-d-lesson 28-s
G6 m1-d-lesson 28-s
 
Personas For Outreach - State Of Search
Personas For Outreach - State Of SearchPersonas For Outreach - State Of Search
Personas For Outreach - State Of Search
 
Plano de carreira dos servidores municipais
Plano de carreira dos servidores municipaisPlano de carreira dos servidores municipais
Plano de carreira dos servidores municipais
 
Mapa empatía
Mapa empatíaMapa empatía
Mapa empatía
 
Trabajo proceso tecnologico emf
Trabajo proceso tecnologico emfTrabajo proceso tecnologico emf
Trabajo proceso tecnologico emf
 
Nota à imprensa versão final - 19.11.13
Nota à imprensa   versão final - 19.11.13Nota à imprensa   versão final - 19.11.13
Nota à imprensa versão final - 19.11.13
 

Similaire à Arquitectura software

Sistemas operativos distribuidos
Sistemas operativos distribuidosSistemas operativos distribuidos
Sistemas operativos distribuidosTensor
 
diseño de arquitectura de un sistema de informacion
diseño de arquitectura de un sistema de informaciondiseño de arquitectura de un sistema de informacion
diseño de arquitectura de un sistema de informacionzulaymaylin
 
Clase De Fds22
Clase De Fds22Clase De Fds22
Clase De Fds22masa832
 
Unidad 1 sistemas operativos
Unidad 1 sistemas operativosUnidad 1 sistemas operativos
Unidad 1 sistemas operativosFenix Sven
 
Desarrollo de aplicaciones web distribuidas.
Desarrollo de aplicaciones web distribuidas.Desarrollo de aplicaciones web distribuidas.
Desarrollo de aplicaciones web distribuidas.Jomicast
 
1 unidad jacinto s.o 2
1 unidad jacinto s.o 21 unidad jacinto s.o 2
1 unidad jacinto s.o 2Dianaledezma94
 
Sistemas Operativos Distribuidos
Sistemas Operativos DistribuidosSistemas Operativos Distribuidos
Sistemas Operativos DistribuidosVectorinox01
 
Escalabilidad
EscalabilidadEscalabilidad
EscalabilidadPaul Loor
 
Sistemas operativos distribuidos
Sistemas operativos distribuidosSistemas operativos distribuidos
Sistemas operativos distribuidosalbertoisaacs13
 
Sistemas operativos distribuidos
Sistemas operativos distribuidosSistemas operativos distribuidos
Sistemas operativos distribuidosJperez98
 
Sistemas operativos distribuidos
Sistemas operativos distribuidosSistemas operativos distribuidos
Sistemas operativos distribuidoserwin portillo
 
Investigacion eq.3 inf-5 e
Investigacion eq.3 inf-5 eInvestigacion eq.3 inf-5 e
Investigacion eq.3 inf-5 eEduardo Diaz
 
Sistemas operativos distribuidos.
Sistemas operativos distribuidos.Sistemas operativos distribuidos.
Sistemas operativos distribuidos.scorpion_esab
 

Similaire à Arquitectura software (20)

Sistemas operativos distribuidos
Sistemas operativos distribuidosSistemas operativos distribuidos
Sistemas operativos distribuidos
 
Sistemas distribuidos
Sistemas distribuidosSistemas distribuidos
Sistemas distribuidos
 
diseño de arquitectura de un sistema de informacion
diseño de arquitectura de un sistema de informaciondiseño de arquitectura de un sistema de informacion
diseño de arquitectura de un sistema de informacion
 
Clase De Fds22
Clase De Fds22Clase De Fds22
Clase De Fds22
 
Unidad 1 sistemas operativos
Unidad 1 sistemas operativosUnidad 1 sistemas operativos
Unidad 1 sistemas operativos
 
Desarrollo de aplicaciones web distribuidas.
Desarrollo de aplicaciones web distribuidas.Desarrollo de aplicaciones web distribuidas.
Desarrollo de aplicaciones web distribuidas.
 
1 unidad jacinto s.o 2
1 unidad jacinto s.o 21 unidad jacinto s.o 2
1 unidad jacinto s.o 2
 
Sistemas Operativos Distribuidos
Sistemas Operativos DistribuidosSistemas Operativos Distribuidos
Sistemas Operativos Distribuidos
 
Escalabilidad
EscalabilidadEscalabilidad
Escalabilidad
 
Sistemas operativos distribuidos
Sistemas operativos distribuidosSistemas operativos distribuidos
Sistemas operativos distribuidos
 
Sistemas operativos distribuidos
Sistemas operativos distribuidosSistemas operativos distribuidos
Sistemas operativos distribuidos
 
Sistemas operativos distribuidos
Sistemas operativos distribuidosSistemas operativos distribuidos
Sistemas operativos distribuidos
 
Investigacion eq.3 inf-5 e
Investigacion eq.3 inf-5 eInvestigacion eq.3 inf-5 e
Investigacion eq.3 inf-5 e
 
Sistemas operativos distribuidos.
Sistemas operativos distribuidos.Sistemas operativos distribuidos.
Sistemas operativos distribuidos.
 
Sistemas Distribuidos
Sistemas DistribuidosSistemas Distribuidos
Sistemas Distribuidos
 
Jacinto 1
Jacinto 1Jacinto 1
Jacinto 1
 
sistemas operativos 2
sistemas operativos 2sistemas operativos 2
sistemas operativos 2
 
Sistemas operativos 2
Sistemas operativos 2Sistemas operativos 2
Sistemas operativos 2
 
Majitop
MajitopMajitop
Majitop
 
Majitop
MajitopMajitop
Majitop
 

Arquitectura software

  • 1. ARQUITECTURA DE SOFTWARE MODELOS DE ARQUITECTURA Manuel Campos Villar 14/11/2013
  • 2. Índice Portada 1 Índice 2 Introducción 3 ¿Qué es la Arquitectura de Software? 4 Modelo de Arquitectura Centralizada 5 Modelo de Arquitectura Distribuido 6/7 Modelo de Arquitectura Servidor de Archivos 8/9 Modelo de Arquitectura Cliente / Servidor 10/14 Modelo de Arquitectura Peer to Peer 15/16 Conclusión 17 Bibliografía 18 2
  • 3. Introducción En los inicios de la informática, la programación se consideraba un arte y se desarrollaba como tal, debido a la dificultad que entrañaba para la mayoría de las personas, pero con el tiempo se han ido descubriendo y desarrollando formas y guías generales, con base a las cuales se puedan resolver los problemas. A estas, se les ha denominado Arquitectura de Software, porque, a semejanza de los planos de un edificio o construcción, estas indican la estructura, funcionamiento e interacción entre las partes del software. En el libro "Anintroductionto Software Architecture", David Garlan y Mary Shaw definen que la Arquitectura es un nivel de diseño que hace foco en aspectos "más allá de los algoritmos y estructuras de datos de la computación; el diseño y especificación de la estructura global del sistema es un nuevo tipo de problema". 3
  • 4. ¿Qué es la Arquitectura de Software? La arquitectura de software define, de manera abstracta, los componentes que llevan a cabo alguna tarea de computación, sus interfaces y la comunicación entre ellos. Toda arquitectura debe ser implementable en una arquitectura física, que consiste simplemente en determinar qué computadora tendrá asignada cada tarea. “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.” (1)Kruchten, Philippe (1) PhilippeKruchten (nacido en 1952) es un ingeniero canadiense de software, y el profesor de Ingeniería de Software de la Universidad de British Columbia en Vancouver, Canadá, conocido como director de desarrollo de proceso (RUP) en Rational Software, y desarrollador del 4 +1. 4
  • 5. 1. Modelo de Arquitectura Centralizada Esta arquitectura se desarrolla cuando el software se estructura en grupos funcionales muy acoplados. No hay distribución, tanto a nivel físico como a nivel lógico. Está formado por la presentación, los datos y el procesamiento. Es una arquitectura rígida de programación en un solo computador. Es la arquitectura de los primeros sistemas operativos constituidos fundamentalmente por un solo programa compuesto de un conjunto de rutinas entrelazadas de tal forma que cada una puede llamar a cualquier otra. Características de la arquitectura centralizada o monolítica. Construcción del programa final a base de módulos compilados separadamente que se unen a través del ligado. Buena definición de parámetros de enlace entre las distintas rutinas existentes, que puede provocar mucho acoplamiento. Carecen de protecciones y privilegios al entrar a rutinas que manejan diferentes aspectos de los recursos de la computadora, como memoria, disco, etc. Generalmente están hechos a medida, por lo que son eficientes y rápidos en su ejecución y gestión, pero por lo mismo carecen de flexibilidad para soportar diferentes ambientes de trabajo o tipos de aplicaciones. Ventajas Muy eficiente ya que se producen pocos cambios de contexto. Gran nivel de seguridad. Fácil administración. Desventajas Difícil de depurar, un error en una función se puede manifestar en otra distinta. Alto Costo. Maquina Servidora muy cargada. Difícil de ampliar. 5
  • 6. 2. Modelo de Arquitectura Sistemas Distribuidos Prácticamente todo los grandes sistemas informáticos son en la actualidad sistemas distribuidos. Un sistema distribuido es un sistema en el que el procesamiento de información se distribuye sobre varias computadoras en vez de estar confinado en una única máquina. Obviamente, la ingeniería de sistemas distribuidos tiene mucho en común con la ingeniería de cualquier otro software, pero existen cuestiones específicas que deben tenerse en cuenta cuando se diseña este tipo de sistemas. Se identifican las siguientes ventajas del uso de una aproximación distribuida para el desarrollo de sistemas: Compartición de recursos: Un sistema distribuido permite compartir recursos hardware y software – como discos, impresoras, ficheros y compiladores – que se asocian con computadoras de una red. Apertura: Los sistemas distribuidos son normalmente sistemas abiertos, lo que significa que se diseñan sobre protocolos estándar que permiten combinar equipamiento y software de diferentes vendedores. Concurrencia. En un sistema distribuido, varios procesos pueden operar al mismo tiempo sobre diferentes computadoras de la red. Estos procesos pueden (aunque no necesariamente) comunicarse con otros durante su funcionamiento normal. Escalabilidad: Al menos en principio, los sistemas distribuidos son escalables en tanto que la capacidad del sistema puede incrementarse añadiendo nuevos recursos para cubrir nuevas demandas sobre el sistema. En la práctica, la red que una las computadoras individuales del sistema puede limitar la escalabilidad del sistema. Si se añaden muchas computadoras nuevas, entonces la capacidad de la red puede resultar inadecuada. Tolerancia a defectos: La disponibilidad de varias computadoras y el potencial para reproducir información significa que los sistemas distribuidos pueden ser tolerantes a algunos fallos de funcionamiento del hardware y del software. En la mayoría de los sistemas distribuidos, se puede proporcionar un servicio degradado cuando ocurren fallos de funcionamiento; una completa pérdida de servicio sólo ocurre cuando existe un fallo de funcionamiento en la red. Para sistemas organizacionales a gran escala, estas ventajas significan que los sistemas distribuidos han reemplazado ampliamente a los sistemas heredados centralizados que fueron desarrollados en los años 80 y 90. Sin embargo, comparados con sistemas que se ejecutan sobre un único procesador o un clúster de procesadores, los sistemas distribuidos tienen varias desventajas: Complejidad: Los sistemas distribuidos son más complejos que los sistemas centralizados. Esto 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. Seguridad: Puede accederse al sistema desde varias computadoras diferentes, y el tráfico en la red puede estar sujeto a escuchas indeseadas. Esto hace más difícil el asegurar que la integridad de los datos en el sistema se mantenga y que los servicios del sistema no se degraden por ataques de denegación de servicio. 6
  • 7. Manejabilidad: Las computadoras en un sistema pueden ser de diferentes tipos y pueden ejecutar versiones diferentes de sistemas operativos. Los defectos en una máquina pueden propagarse a otras máquinas con consecuencias inesperadas. Esto significa que se requiere más esfuerzo para gestionar y mantener el funcionamiento del sistema. Impredecible: Como todos los usuarios de la WWW saben, 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 con mucha rapidez, el tiempo requerido para responder a una petición de usuario puede variar drásticamente de una petición a otra. El reto para el diseño es diseñar el software y hardware para proporcionar características deseables a los sistemas distribuidos y, al mismo tiempo, minimizar los problemas inherentes a estos sistemas. Para hacer eso, se necesita comprender las ventajas y desventajas de las diferentes arquitecturas de sistemas distribuidos. Aquí se tratan dos tipos genéricos de arquitecturas de sistemas distribuidos: 1. Arquitectura cliente-servidor. En esta aproximación, el sistema puede ser visto como un conjunto de servicio que se proporcionan a los clientes que hacen uso de dichos servicios. Los servidores y los clientes se tratan de forma diferente en estos sistemas. 2. Arquitecturas de objetos distribuidos. En este caso, no hay distinción entre servidores y clientes, y el sistema puede ser visto como un conjunto de objetos que interaccionan cuya localización es irrelevante. No hay distinción entre un proveedor de servicios y el usuario de estos servicios. Ambas arquitecturas se usan ampliamente en la industria, pero la distribución de las aplicaciones generalmente tiene lugar dentro de una única organización. La distribución soportada es, por lo tanto, inter organizacional. Aquí también se plantean dos tipos más de arquitecturas distribuidas que son más adecuadas para la distribución inter organizacional: Arquitectura de sistemas peer-to-peer (p2p) y Arquitecturas orientadas a servicios.Los componentes en un sistema distribuido pueden implementarse en diferentes lenguajes de programación y pueden ejecutarse en tipos de procesadores completamente diferentes. Los modelos de datos, la representación de la información y los protocolos de comunicación pueden ser todos diferentes. Un sistema distribuido, por lo tanto, requiere software que pueda gestionar estas partes distintas, y asegurar que dichas partes se puedan comunicar e intercambiar datos. El término middleware se usa para hacer referencia a ese software; se sitúa en medio de los diferentes componentes distribuidos del sistema. El middleware es un software de propósito general que normalmente se compra como un componente comercial más que escribirse especialmente por los desarrolladores de la aplicación. Ejemplos de middleware son software para gestionar comunicaciones con bases de datos, administradores de transacciones, convertidores de datos y controladores de comunicación. Los sistemas distribuidos se desarrollan normalmente utilizando una aproximación orientada a objetos. Estos sistemas están formados por partes independientes pobremente integradas, cada una de las cuales pueden interaccionar directamente con los usuarios o con otras partes del sistema. Algunas partes del sistema pueden tener que responder a eventos independientes. Los objetos software reflejan estas características; por lo tanto, son abstracciones naturales para los componentes de sistemas distribuidos. 7
  • 8. 3. Modelo de Arquitectura Servidor de Archivos El concepto de " Servidor de Archivos" 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. El Modelo de Servidor de Archivos distingue cliente de sistemas de servidor de sistemas, que se comunican sobre a red de ordenadores. Un uso del servidor de cliente es a sistema distribuido abarcado de cliente y de software del servidor. Un proceso del software del cliente puede iniciar una sesión de la comunicación, mientras que el servidor espera peticiones de cualquier cliente. El cliente/servidor describe la relación entre dos programas de computadora en los cuales un programa, el cliente, marcas una petición del servicio de otro programa, el servidor, que satisface la petición. Aunque la idea del cliente/del servidor se puede utilizar por programas dentro de una sola computadora, es una idea más importante en una red. En una red, elmodelo del cliente/del servidor proporciona una manera conveniente de interconectar eficientemente los programas que se distribuyen a través de diversas localizaciones. El modelo del cliente/del servidor tiene convertido de las ideas centrales del computar de la red. La mayoría de los usos de negocio que son escritos hoy utilizan el modelo del cliente/del servidor. Haga tan los protocolos de uso principal del Internet, por ejemplo HTTP, Smtp, Telnet, DNS, etc. En la comercialización, el término ha sido utilizado para distinguir computar distribuido por computadoras dispersadas más pequeñas de computar centralizado “monolítico” de los ordenadores centrales. Pero esta distinción ha desaparecido en gran parte como chasis y sus usos también han dado vuelta al modelo del cliente/del servidor y se convierten en parte de computar de la red. Cada un caso de cliente el software puede enviar datos peticiones con uno o más conectó servidor. Alternadamente, los servidores pueden aceptar estas peticiones, procesarlas, y volver la información solicitada al cliente. Aunque este concepto se puede solicitar una variedad de razones a muchas diversas clases de usos, la arquitectura sigue siendo fundamental igual. El tipo más básico de servidor de cliente arquitectura emplea solamente dos tipos de anfitriones: clientes y servidores. Este tipo de arquitectura se refiere a veces como de dos niveles. Permite que los dispositivos compartan archivos y recursos Ventajas En la mayoría de los casos, una arquitectura del servidor de cliente permite los papeles y las responsabilidades de un sistema de cálculo de ser distribuido entre varias computadoras independientes que se sepan el uno al otro solamente a través de una red. Esto crea una ventaja adicional a esta arquitectura: mayor facilidad del mantenimiento. Por ejemplo, es posible substituir, reparar, aumentar, o aún volver a poner un servidor mientras que sus clientes siguen siendo inconscientes e inafectados por ese cambio. Esta independencia del cambio también se refiere como encapsulación. Todos los datos se almacenan en los servidores, que tienen generalmente controles lejos mayores de la seguridad que la mayoría de los clientes. Los servidores pueden mejorar el acceso y recursos del control, para garantizar que solamente esos clientes con los permisos apropiados pueden tener acceso y cambiar a datos. Puesto que se centraliza el almacenaje de datos, las actualizaciones a esos datos son lejos más fáciles de administrar que sea posible bajo paradigma 8
  • 9. del P2P. Bajo arquitectura del P2P, las actualizaciones de los datos pueden necesitar ser distribuido y aplicado a cada “par” en la red, que es desperdiciadora de tiempo y error-prone, como puede haber millares o aún millones de pares. Muchas tecnologías maduras del servidor de cliente son ya que fueron diseñadas para asegurar seguridad, “amistad disponible” del interfaz utilizador, y facilidad de empleo. Funciona con diversos clientes múltiples de diversas capacidades. Desventajas La congestión del tráfico en la red ha sido una edición desde el inicio del paradigma del servidor de cliente. Mientras que el número de las peticiones simultáneas del cliente a un servidor dado aumenta, el servidor puede sobrecargarse seriamente. Ponga en contraste eso con una red del P2P, donde su anchura de banda aumenta realmente como se agregan más nodos, desde la anchura de banda total de la red del P2P se puede computar áspero como la suma de las anchuras de banda de cada nodo en esa red. El paradigma del servidor de cliente carece la robustez de una buena red P2P. Debajo del servidor de cliente, un fall crítico del servidor, peticiones de los clientes que no pueden ser satisfechas. En redes P2P, los recursos se distribuyen generalmente entre muchos nodos. Aunque unos o más nodos salen y abandonan un archivo que descarga, por ejemplo, los nodos restantes si inmóvil tenga los datos necesitados para terminar la transferencia directa. 9
  • 10. 4. Modelo de Arquitectura Cliente/Servidor Sistema distribuido entre múltiples procesadores donde hay clientes que solicitan servicios y servidores que los proporcionan. Separa los servicios situando cada uno en su plataforma más adecuada. Desde el punto de vista funcional, se puede definir la computación Cliente/Servidor como una arquitectura distribuida que permite a los usuarios finales obtener acceso a la información en forma transparente aún en entornos multiplataforma. En el modelo cliente servidor, el cliente envía un mensaje solicitando un determinado servicio a un servidor (hace una petición), y este envía uno o varios mensajes con la respuesta (provee el servicio). En un sistema distribuido cada máquina puede cumplir el rol de servidor para algunas tareas y el rol de cliente para otras. Esta arquitectura consiste básicamente en un cliente que realiza peticiones a otro programa (el servidor) que le da respuesta. Aunque esta idea se puede aplicar a programas que se ejecutan sobre una sola computadora es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras. En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores, aunque son más importantes las ventajas de tipo organizativo debidas a la centralización de la gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el diseño del sistema. La separación entre cliente y servidor es una separación de tipo lógico, donde el servidor no se ejecuta necesariamente sobre una sola máquina ni es necesariamente un sólo programa. Los tipos específicos de servidores incluyen los servidores web, los servidores de archivo, los servidores del correo, etc. Mientras que sus propósitos varían de unos servicios a otros, la arquitectura básica seguirá siendo la misma. Un sistema cliente/servidor funciona tal como se detalla en el siguiente diagrama: El cliente envía una solicitud al servidor mediante su dirección IP y el puerto, que está reservado para un servicio en particular que se ejecuta en el servidor. El servidor recibe la solicitud y responde con la dirección IP del equipo cliente y su puerto. El término cliente/servidor es originalmente aplicado a la arquitectura de software que describe el procesamiento entre dos o más programas: una aplicación y un servicio soportante. 10
  • 11. IBM define al modelo Cliente/Servidor. "Es la tecnología que proporciona al usuario final el acceso transparente a las aplicaciones, datos, servicios de cómputo o cualquier otro recurso del grupo de trabajo y/o, a través de la organización, en múltiples plataformas. El modelo soporta un medio ambiente distribuido en el cual los requerimientos de servicio hechos por estaciones de trabajo inteligentes o "clientes'', resultan en un trabajo realizado por otros computadores llamados servidores". Características de la arquitectura cliente/servidor. Combinación de un cliente que interactúa con el usuario, y un servidor que interactúa con los recursos compartidos. El proceso del cliente proporciona la interfaz entre el usuario y el resto del sistema. El proceso del servidor actúa como un motor de software que maneja recursos compartidos tales como bases de datos, impresoras, módems, etc. Las tareas del cliente y del servidor tienen diferentes requerimientos en cuanto a recursos de cómputo como velocidad del procesador, memoria, velocidad y capacidades del disco e input-output devices. Se establece una relación entre procesos distintos, los cuales pueden ser ejecutados en la misma máquina o en máquinas diferentes distribuidas a lo largo de la red. Existe una clara distinción de funciones basada en el concepto de "servicio", que se establece entre clientes y servidores. La relación establecida puede ser de muchos a uno, en la que un servidor puede dar servicio a muchos clientes, regulando su acceso a recursos compartidos. Los clientes corresponden a procesos activos en cuanto a que son éstos los que hacen peticiones de servicios a los servidores. Estos últimos tienen un carácter pasivo ya que esperan las peticiones de los clientes. No existe otra relación entre clientes y servidores que no sea la que se establece a través del intercambio de mensajes entre ambos. El mensaje es el mecanismo para la petición y entrega de solicitudes de servicio. El ambiente es heterogéneo. La plataforma de hardware y el sistema operativo del cliente y del servidor no son siempre la misma. Precisamente una de las principales ventajas de esta arquitectura es la posibilidad de conectar clientes y servidores independientemente de sus plataformas. El concepto de escalabilidad tanto horizontal como vertical es aplicable a cualquier sistema Cliente/Servidor. La escalabilidad horizontal permite agregar más estaciones de trabajo activas sin afectar significativamente el rendimiento. La escalabilidad vertical permite mejorar las características del servidor o agregar múltiples servidores. 11
  • 12. 4.1. Modelo de arquitectura cliente/servidor La arquitectura cliente-servidor es una aplicación que se modela como un conjunto de servicios proporcionadospor los servidores y un conjunto de clientes que usan estos servicios (Orfali yHarkey, 1998). Los clientes necesitan conocer qué servidores están disponibles, pero normalmenteno conocen la existencia de otros clientes. Clientes y servidores son procesos diferentes,que representa un modelo lógico de una arquitecturadistribuida cliente-servidor. Sistema Cliente / Servidor La arquitectura cliente-servidor más simple se denomina arquitectura clienteservidor dedos capas, en la que una aplicación se organiza como un servidor (o múltiples servidores idénticos)y un conjunto de clientes. Las arquitecturas cliente/servidorde dos capas pueden ser de dos tipos: 1. Modelo de cliente ligero (thin-client). En un modelo de cliente ligero, todo el procesamientode las aplicaciones y la gestión de los datos se llevan a cabo en el servidor. Elcliente simplemente es responsable de la capa de presentación del software. 2. Modelo de cliente rico (fat-client). En este modelo, el servidor solamente es responsablede la gestión de los datos. El software del cliente implementa la lógica de la aplicacióny las interacciones con el usuario del sistema. Aplicaciones simples No requieren una gran Base de Datos compartida, pueden ser elaboradas solamente en el Cliente. Aplicaciones complejas Exigen dos capas, una para la aplicación del usuario (Cliente) y otra para la base de datos (Servidor). Arquitectura de 2 niveles: 1. Generalmente usa los modelos de función distribuida o datos distribuidos. 2. Muy productivo. 3. Distribución no flexible. 4. Dependiente del suministrador. Arquitectura de 3 niveles: La Arquitectura de tres niveles es lógica y no física. Se preocupa con las funciones y no con la implantación. 12
  • 13. La Arquitectura puede ser utilizada para desarrollar sistemas Centralizados o Distribuidos. La Arquitectura facilitará la distribución de los componentes del sistema. 1. Modelo presentación-negocio-datos. 2. Distribución flexible. 3. Sistema abierto. No dependiente. Beneficios: Estructura para la elaboración de aplicativos flexibles y fáciles de modificar, según las necesidades del negocio (cambio). Alto nivel de reutilización del software y datos. Fácil y rápido desarrollo de aplicativos grandes y complejos, para las transacciones y los SSD. Fácil y rápido desarrollo de sistemas distribuidos que dan soporte a la administración central y a equipos auto-gestionados. Ventajas Centralización del control: los accesos, recursos y la integridad de los datos son controlados por el servidor de forma que un programa cliente defectuoso o no autorizado no pueda dañar el sistema. Esta centralización también facilita la tarea de poner al día datos u otros recursos (mejor que en las redes P2P). Escalabilidad: se puede aumentar la capacidad de clientes y servidores por separado. Cualquier elemento puede ser aumentado (o mejorado) en cualquier momento, o se pueden añadir nuevos nodos a la red (clientes y/o servidores). Fácil mantenimiento: al estar distribuidas las funciones y responsabilidades entre varios ordenadores independientes, es posible reemplazar, reparar, actualizar, o incluso trasladar un servidor, mientras que sus clientes no se verán afectados por ese cambio (o se afectarán mínimamente). Esta independencia de los cambios también se conoce como encapsulación. Existen tecnologías, suficientemente desarrolladas, diseñadas para el paradigma de C/S que aseguran la seguridad en las transacciones, la amigabilidad del interfaz, y la facilidad de empleo. Desventajas La congestión del tráfico ha sido siempre un problema en el paradigma de C/S. Cuando una gran cantidad de clientes envían peticiones simultaneas al mismo servidor, puede ser que cause muchos problemas para éste (a mayor número de clientes, más problemas para el servidor). Al contrario, en las redes P2P como cada nodo en la red hace también de servidor, cuantos más nodos hay, mejor es el ancho de banda que se tiene. El paradigma de C/S clásico no tiene la robustez de una red P2P. Cuando un servidor está caído, las peticiones de los clientes no pueden ser satisfechas. En la mayor parte de redes P2P, los recursos están generalmente distribuidos en varios nodos de la red. Aunque algunos 13
  • 14. salgan o abandonen la descarga; otros pueden todavía acabar de descargar consiguiendo datos del resto de los nodos en la red. El software y el hardware de un servidor son generalmente muy determinantes. Un hardware regular de un ordenador personal puede no poder servir a cierta cantidad de clientes. Normalmente se necesita software y hardware específico, sobre todo en el lado del servidor, para satisfacer el trabajo. Por supuesto, esto aumentará el coste. El cliente no dispone de los recursos que puedan existir en el servidor. Por ejemplo, si la aplicación es una Web, no podemos escribir en el disco duro del cliente o imprimir directamente sobre las impresoras sin sacar antes la ventana previa de impresión de los navegadores. 14
  • 15. 5. Arquitectura Peer to Peer También se pueden tomar dos tipos más de arquitecturas distribuidas que son más adecuadas para la distribución inter organizacional: Arquitectura de sistemas peer-to-peer (p2p) y Arquitecturas orientadas a servicios. A continuación nos centraremos en los dos tipos principales de arquitecturas lógicas de redque se pueden usar: arquitecturas descentralizadas y arquitecturas semicentralizadas. 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 hacen 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 nodos están embebidos en la propia aplicación, y cada nodo debe ejecutar una copia de dicha aplicación. Usted puede ver 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 otronodo, podría conectarse con él, y podría intercambiar datos. En la práctica, por supuesto, esto es imposible, ya que los nodos se organizan dentro de «localidades» con algunos nodos queactúan como puentes a otras localidades de nodos. Clasificación de P2P: Redes P2P Centralizadas: Este tipo de red P2P se basa en una arquitectura monolítica en la que todas las transacciones se hacen a través de un único servidor que sirve de punto de enlace entre dos nodos y que, a la vez, almacena y distribuye los nodos donde se almacenan los contenidos. Poseen una administración muy dinámica y una disposición más permanente de contenido. Sin embargo, está muy limitada en la privacidad de los usuarios y en la falta de escalabilidad de un sólo servidor, además de ofrecer problemas en puntos únicos de fallo, situaciones legales y enormes costos en el mantenimiento, así como el consumo de ancho de banda. Una red de este tipo reúne las siguientes características: Se rige bajo un único servidor, que sirve como punto de enlace entre nodos y como servidor de acceso al contenido, el cual distribuye a petición de los nodos. Todas las comunicaciones (como las peticiones y encaminamientos entre nodos) dependen exclusivamente de la existencia del servidor. Algunos ejemplos de este tipo de redes son Napster y Audiogalaxy. Redes P2P Descentralizadas: Las redes P2P de este tipo son las más comunes, siendo las más versátiles al no requerir de un gestiona miento central de ningún tipo, lo que permite una reducción de la necesidad de usar un servidor central, por lo que se opta por los mismos usuarios como nodos de esas conexiones y también como almacenadores 15
  • 16. de esa información. En otras palabras, todas las comunicaciones son directamente de usuario a usuario con ayuda de un nodo (que es otro usuario) quien permite enlazar esas comunicaciones. Las redes de este tipo tienen las siguientes características: Los nodos actúan como cliente y como servidor. No existe un servidor central que maneje las conexiones de red. No hay un enrutador central que sirva como nodo y administre direcciones. Algunos ejemplos de una red Galaxy, Gnutella, Freenet y Gnutella2. P2P "pura" son: Kademlia, Ares Arquitectura p2p descentralizada Redes P2P Centralizadas: En este tipo de red, se puede observar la interacción entre un servidor central que sirve como hub y administra los recursos de banda ancha, enrutamientos y comunicación entre nodos pero sin saber la identidad de cada nodo y sin almacenar información alguna, por lo que el servidor no comparte archivos de ningún tipo a ningún nodo. Tiene la peculiaridad de funcionar (en algunos casos como en Torrent) de ambas maneras, es decir, puede incorporar más de un servidor que gestione los recursos compartidos, pero también, en caso de que el servidor o los servidores que gestionan todo caigan, el grupo de nodos puede seguir en contacto a través de una conexión directa entre ellos mismos, con lo que es posible seguir compartiendo y descargando más información en ausencia de los servidores. Este tipo de P2P presenta las siguientes características: Tiene un servidor central que guarda información en espera y responde a peticiones para esa información. Los nodos son responsables de hospedar la información (pues el servidor central no almacena la información) que permite al servidor central reconocer los recursos que se desean compartir, y para poder descargar esos recursos compartidos a los usuarios que lo solicitan. Las terminales de enrutamiento son direcciones usadas por el servidor, que son administradas por un sistema de índices para obtener una dirección absoluta. Algunos ejemplos de una son BitTorrent, eDonkey y DirectConnect. 16 red P2P híbrida
  • 17. Conclusión Para comenzar esta conclusión podríamos decir que la arquitectura a parte del modelado del software también juega un papel importante en otros aspectos del desarrollo de software: Mejora la comprensión de sistemas grandes y complejos. Permite una mejor comunicación entre los diferentes interesados. Mejora las posibilidades de reusó. Proporciona planos para la construcción. Toma en cuenta la posible evolución del sistema. En este trabajo prácticamente todo los modelos de arquitectura pertenecen a los sistemas distribuidos. Un sistema distribuido es un sistema en el que el procesamiento de información se distribuye sobre varias computadoras en vez de estar confinado en una única máquina. Y dentro de estos sistemas se encuentran los Cliente/Servidor y P2P los cuales son muy idénticos pero gana con creces la Arquitectura Cliente/Servidor por sus características. En la arquitectura Cliente/Servidor se ve como los tres niveles de aplicación se relacionan. Focaliza sobre la estructura y la adaptación. Y determina qué entra en cada nivel y cómo la aplicación se relaciona con otras aplicaciones. Y la Arquitectura de P2P es una red de computadoras en la que todos o algunos aspectos funcionan sin clientes ni servidores fijos, sino una serie de nodos que se comportan como iguales entre sí. Esto quiere decir que no hay distinción entre cliente y servidor siendo cada un servidor y cliente al mismo tiempo el cual se comunican directamente con otro similar. Por otra parte la Arquitectura de Servidor de Archivos se basa en la existencia de una a varias máquinas servidoras que almacenan datos y estaciones de trabajo que ejecutan aplicaciones que los procesanlos clientes en este tipo de aplicaciones son activos. Y por último unas de las primeras arquitecturas es la centralizada que es la más básica la cual es un único servidor que ofrece servicio a una red, pero con limitación ya que se sobre carga el servidor demasiado pero para una pequeña red es muy eficaz. 17
  • 18. Bibliografía http://laurel.datsi.fi.upm.es/_media/docencia/asignaturas/sod/arquitecturas_ 1pp.pdf “Arquitectura de Sistemas Distribuidos” http://www-oei.eui.upm.es/Asignaturas/BD/BD/docbd/tema/Arquitectura.pdf “Tipos de Arquitectura” http://cs.uns.edu.ar/~gis/ebd/Archivos/Clases/EBD%20%20Clase%2020%202004%20Color.pdf “Elementos de BD” http://introduccionaoracle.blogspot.com/p/arquitectura-servidor-dearchivos.html “Introducción Oracle” http://es.wikipedia.org/wiki/Cliente-servidor “Cliente-Servidor” http://es.wikipedia.org/wiki/Bases_de_datos_distribuidas ”Sistemas Distribuidos” http://normalizacion-bd.blogspot.com/2012/11/5-arquitecturacentralizada.html “Sistemas Centralizados” http://es.wikipedia.org/wiki/Arquitectura_de_software “Arquitectura de Software” http://ithroshuejutla.blogspot.com/ “Arquitectura de Software ” Ingeniería del Software 7ma. Ed. - AutorIanSommerville. 18