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 "An introduction to 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) Philippe Kruchten (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.

2. Modelo de Arquitectura Sistemas Distribuidos

5

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.

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

6

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.

3. Modelo de Arquitectura Servidor de Archivos

7

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, el modelo 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 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

8

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.

4. Modelo de Arquitectura Cliente/Servidor

9

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.

IBM define al modelo Cliente/Servidor. "Es la tecnología que proporciona al usuario final el acceso transparente a las aplicaciones, datos, servicios de

10

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.

4.1. Modelo de arquitectura cliente/servidor

11

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

Sistema Cliente / Servidor

La arquitectura cliente-servidor más simple se denomina arquitectura cliente-servidor de dos 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/servidor de dos capas pueden ser de dos tipos:

1. Modelo de cliente ligero (thin-client). En un modelo de cliente ligero, todo el procesamiento de las aplicaciones y la gestión de los datos se llevan a cabo en el servidor. El cliente 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 responsable de la gestión de los datos. El software del cliente implementa la lógica de la aplicación y 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. La Arquitectura puede ser utilizada para desarrollar sistemas Centralizados o Distribuidos.

12

 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 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

13

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.

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

14

peer-to-peer (p2p) y Arquitecturas orientadas a servicios. A continuación nos centraremos en los dos tipos principales de arquitecturas lógicas de red que se pueden usar: arquitecturas descentralizadas y arquitecturas semi centralizadas.

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 otro nodo, 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 que actú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 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:

15

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 P2P "pura" son: Kademlia, Ares Galaxy, Gnutella, Freenet y Gnutella2.

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 red P2P híbrida son BitTorrent, eDonkey y Direct Connect.

Conclusión

16

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 procesan los 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.

Bibliografía

17

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-de- archivos.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-arquitectura-

centralizada.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. - Autor Ian Sommerville.

18