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