SlideShare ist ein Scribd-Unternehmen logo
1 von 64
Downloaden Sie, um offline zu lesen
Diseño Arquitectónico
A. Organización del Sistema
a. Arquitectura centrada en datos
b. Arquitectura en capas
c. Arquitectura de sistemas distribuidos
c.1. Multiprocesador
c.2. Cliente/Servidor
c.3. Objetos distribuidos
c.4. Peer-to-peer
c.5. Orientada a servidos
d. Arquitecturas de Aplicaciones
Modelos de dominio específico
Sommerville. Cap. 11
Sommerville. Cap. 12
Sommerville. Cap. 13
B. Descomposición modular y estilos de control
a. Orientada a Objetos
b. Orientada a flujos de funciones
c. Control centralizado
d. Control basado en eventos
Sommerville. Sección 11.3
∗ Prácticamente todos los grandes sistemas informáticos
son sistemas distribuidos.
∗ En un sistema distribuido el procesamiento de
información se distribuye sobre varias computadoras
en vez de estar confinado en una única máquina.
∗ Ventajas:
1. Compartir recursos. Un sistema distribuido permite
compartir recursos hardware y software (discos,
impresoras, ficheros y compiladores) que se asocian
con computadoras de una red.
Arquitecturas de Sistemas
Distribuidos
2. Apertura. Son normalmente sistemas abiertos: se
diseñan sobre protocolos estándares que permiten
combinar equipamiento y software de diferentes
vendedores.
3. Concurrencia. Varios procesos pueden operar al
mismo tiempo sobre diferentes computadoras de la
red. Hasta pueden comunicarse con otros durante su
funcionamiento.
4. Escalabilidad. Los sistemas distribuidos son
escalables mientras la capacidad del sistema pueda
incrementarse, añadiendo nuevos recursos para cubrir
nuevas demandas sobre el sistema.
Arquitecturas de Sistemas
Distribuidos: Ventajas
En la práctica, si se añaden muchas computadoras nuevas,
la capacidad de la red puede saturarse.
5. Tolerancia a defectos. Contar con varias computadoras y
el potencial para reproducir información significa que los
sistemas distribuidos pueden ser tolerantes a algunas
fallas de funcionamiento del hardware y del software.
∗En la mayoría de los sistemas distribuidos, puede haber
un servicio degradado, ante fallas de funcionamiento. Una
completa pérdida de servicio sólo ocurre cuando existe
una falla de funcionamiento en la red.
Arquitecturas de Sistemas
Distribuidos: Ventajas
1. Complejidad. Los sistemas distribuidos son más
complejos que los sistemas centralizados; lo que hace
más difícil comprender sus propiedades emergentes y
probar estos sistemas.
∗Por ejemplo, en vez de que el rendimiento del sistema
dependa de la velocidad de ejecución de un procesador,
depende del ancho de banda y de la velocidad de los
procesadores de la red.
∗Mover los recursos de una parte del sistema a otra
puede afectar de forma radical al rendimiento del
sistema.
Arquitecturas de Sistemas
Distribuidos: Desventajas
2. Seguridad. Puede accederse al sistema desde varias
computadoras diferentes, y el tráfico en la red puede estar
sujeto a escuchas indeseadas.
∗Es más difícil mantener la integridad de los datos en el sistema
y que los servicios del sistema no se degraden por ataques.
3. Manejabilidad. Las computadoras en un sistema pueden ser
de diferentes tipos y ejecutar versiones diferentes de sistemas
operativos.
∗Los defectos en una máquina pueden propagarse a otras, con
consecuencias inesperadas.
∗Esto significa que se requiere más esfuerzo para gestionar y
mantener el funcionamiento del sistema.
Arquitecturas de Sistemas
Distribuidos: Desventajas
4. Impredecibilidad. Los sistemas distribuidos tienen
una respuesta impredecible.
∗La respuesta depende de la carga total en el sistema,
de su organización y de la carga de la red.
∗Como todos ellos pueden cambiar rápidamente, el
tiempo requerido para responder a una petición de
usuario puede variar drásticamente, de una petición a
otra.
Arquitecturas de Sistemas
Distribuidos: Desventajas
∗ El desafío es diseñar software y hardware para proporcionar
características deseables a los sistemas distribuidos y minimizar
los problemas propios de ellos.
∗ Para eso, debemos comprender las ventajas y desventajas de
las diferentes arquitecturas de sistemas distribuidos.
∗ Las 2 arquitecturas más importantes de sistemas distribuidos
son :
1. Cliente-Servidor. El sistema se ve como un conjunto de servicios
que se proporcionan a los clientes, que los utilizan.
2. Arquitecturas de objetos distribuidos. No distingue entre
servidores y clientes. El sistema es un conjunto de objetos que
interaccionan, y cuya localización no interesa. No hay distinción
entre un proveedor de servicios y el usuario de los mismos.
Arquitecturas de Sistemas
Distribuidos
∗ El modelo más simple de un sistema distribuido es un
sistema multiprocesador donde el software está
formado por varios procesos que pueden (aunque no
necesariamente) ejecutarse sobre procesadores
diferentes.
∗ Este modelo es común en sistemas grandes de
tiempo real.
∗ Estos sistemas recogen información, toman
decisiones usando esta información y envían señales
para modificar el entorno del sistema.
Arquitecturas Multiprocesador
∗ Lógicamente, los procesos relacionados con la
recopilación de información, toma de decisiones y
control de actuadores podrían ejecutarse todos sobre un
único procesador bajo el control de un planificador
(scheduler).
∗ El uso de múltiples procesadores mejora el rendimiento y
adaptabilidad del sistema.
∗ La distribución de procesos entre los procesadores
puede ser predeterminada o puede estar bajo el control
de un despachador (dispatcher) que decide qué procesos
se asignan a cada procesador.
Arquitecturas Multiprocesador
∗ Un ejemplo de este tipo de sistemas se muestra en la
Figura siguiente.
∗ Es un modelo simplificado de sistema de control de
tráfico.
∗ Un conjunto de sensores distribuidos recogen
información sobre el flujo de tráfico y la procesan
localmente, antes de enviarla a una sala de control.
∗ Los operadores toman decisiones, usando esta
información y dan instrucciones a un proceso de
control de semáforos.
Arquitecturas Multiprocesador
∗ Acá hay varios procesos lógicos para gestionar los
sensores, la sala de control y los semáforos.
∗ Estos procesos lógicos pueden individuales o un
grupo de procesos.
∗ En este caso, se ejecutarán sobre procesadores
diferentes.
Arquitecturas Multiprocesador
∗ Sistema Multiprocesador de Control de Tránsito
Arquitecturas Multiprocesador
∗ En una arquitectura cliente-servidor, una aplicación se
modela como un conjunto de servicios proporcionados por
los servidores y un conjunto de clientes que usan estos
servicios.
∗ Los clientes necesitan conocer qué servidores están
disponibles, pero normalmente no conocen la existencia
de otros clientes.
∗ Clientes y servidores son procesos diferentes.
∗ Varios procesos servidores pueden ejecutarse sobre un
único procesador servidor; por lo tanto, no hay
necesariamente una correspondencia 1:1 entre procesos y
procesadores en el sistema.
Arquitecturas Cliente - Servidor
∗ Esta Figura muestra la arquitectura física de un
sistema con seis computadoras cliente y dos
computadoras servidor.
Arquitecturas Cliente - Servidor
∗ Esa arquitectura FISICA puede ejecutar los procesos
cliente y servidor que se muestran en la figura
siguiente.
∗ Acá, Cuando hablamos de clientes y servidores, nos
referimos a los procesos lógicos, en vez de a las
computadoras físicas sobre las que se ejecutan, como
era el caso anterior.
Arquitecturas Cliente - Servidor
∗ Sistema de “Procesos” Cliente-Servidor:
Arquitecturas Cliente - Servidor
∗ El diseño de sistemas cliente-servidor debería reflejar
la estructura lógica de la aplicación que se está
desarrollando.
∗ Una forma de ver una aplicación se ilustra en la Figura
siguiente, que muestra una aplicación estructurada en
tres capas.
∗ La capa de presentación está relacionada con la
presentación de la información al usuario y con toda
la interacción con él.
Arquitecturas Cliente - Servidor
∗ La capa de procesamiento de la aplicación está
relacionada con la implementación de la lógica de la
aplicación.
∗ La capa de gestión de datos está relacionada con
todas las operaciones sobre la base de datos.
∗ En los sistemas centralizados, no es necesario que
estas capas estén claramente separadas.
∗ Cuando se diseñe un sistema distribuido, debería
hacerse una clara distinción entre ellas, para que sea
posible distribuir cada capa sobre una computadora
diferente.
Arquitecturas Cliente - Servidor
∗ Figura de Capas de las aplicaciones:
Arquitecturas Cliente - Servidor
∗ La arquitectura cliente-servidor más simple se denomina
arquitectura cliente-servidor de dos capas.
∗ Se organiza como un servidor (o múltiples servidores
idénticos) y un conjunto de clientes.
∗ Como se ilustra en la Figura siguiente, las arquitecturas
cliente/servidor de dos capas pueden ser de dos tipos:
1. Modelo de cliente ligero (thin-client). Acá todo el
procesamiento de las aplicaciones y la gestión de los
datos se lleva a cabo en el servidor.
∗ El cliente simplemente es responsable de la capa de
presentación del software.
Arquitecturas Cliente - Servidor
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.
Arquitecturas Cliente - Servidor
∗ Clientes Livianos y Pesados
Arquitecturas Cliente - Servidor
∗ Una arquitectura de dos capas con clientes ligeros es la más
simple que se utiliza cuando los sistemas heredados
centralizados, evolucionan a una arquitectura cliente-servidor.
∗ La interfaz de usuario para estos sistemas se migra a PC’s, y la
aplicación en sí misma actúa como un servidor y maneja todo el
procesamiento de la aplicación y gestión de datos.
∗ Un modelo de cliente ligero también puede implementarse
cuando los clientes son dispositivos de red sencillos en lugar de
PC’s o estaciones de trabajo.
∗ El dispositivo de red ejecuta un navegador de Internet y la
interfaz de usuario es implementada a través de ese sistema.
Modelo de Cliente
Ligero/Pobre/Delgado
∗ Una gran desventaja del modelo de cliente ligero es
que ubica una elevada carga de procesamiento, tanto
en el servidor como en la red.
∗ El servidor es responsable de todos los cálculos, y
esto puede implicar la generación de un tráfico
significativo en la red entre el cliente y el servidor.
∗ Los dispositivos de computación modernos disponen
de una gran cantidad de potencia de procesamiento,
que es desperdiciada en la aproximación de cliente
ligero, liviano o pobre.
Modelo de Cliente
Ligero/Pobre/Delgado
∗ El modelo de cliente rico, pesado o gordo hace uso de
esta potencia de procesamiento disponible y
distribuye, tanto el procesamiento de la lógica de la
aplicación, como la presentación al cliente.
∗ El servidor es esencialmente de transacciones.
∗ Gestiona todas las transacciones de la base de datos.
∗ Ejemplo: arquitectura de los sistemas bancarios ATM
(cajeros automáticos), en donde cada Cajero es un
cliente y el servidor es un mainframe que procesa la
cuenta del cliente en la base de datos.
Modelo de Cliente
Rico/Gordo/Pesado
∗ El hardware de los cajeros automáticos realiza una gran
cantidad de procesamiento relacionado con el cliente y
asociado a la transacción.
∗ Los cajeros automáticos no se conectan directamente con
la base de datos de clientes sino con un monitor de
teleproceso.
∗ Un monitor de teleproceso o gestor de transacciones es un
sistema middleware que organiza las comunicaciones con
los clientes remotos y serializa las transacciones de los
clientes para su procesamiento en la base de datos.
∗ El uso de transacciones serializadas significa que el sistema
puede recuperarse de los defectos sin corromper los datos
del sistema.
Modelo de Cliente
Rico/Gordo/Pesado
∗ Aunque el modelo de cliente rico distribuye el
procesamiento de forma más efectiva que un modelo
de cliente ligero, la gestión del sistema es más
compleja.
∗ La funcionalidad de la aplicación se expande entre
varias computadoras.
∗ Cuando la aplicación software tiene que ser
modificada, esto implica la reinstalación en cada
computadora cliente.
∗ Esto puede significar un costo importante si hay
cientos de clientes en el sistema.
Modelo de Cliente
Rico/Gordo/Pesado
∗ Sistema Cliente – Servidor de Cajeros Automáticos
(ATM):
Modelo de Cliente
Rico/Gordo/Pesado
∗ El problema con una aproximación cliente-servidor de
dos capas es que las tres capas lógicas —-presentación
procesamiento de la aplicación y gestión de los datos
— deben asociarse con dos computadoras: el cliente y
el servidor.
∗ Aquí puede haber problemas con la escalabilidad y
rendimiento si se elige el modelo de cliente ligero, o
problemas con la gestión del sistema si se usa el
modelo de cliente rico.
Modelo Cliente –Servidor de 2
Capas
∗ Para evitar estos problemas, una aproximación
alternativa es usar una arquitectura cliente-servidor de
tres capas.
∗ Aquí, la presentación, el procesamiento de la aplicación
y la gestión de los datos son procesos lógicamente
separados que se ejecutan sobre procesadores
diferentes.
Modelo Cliente –Servidor de 3
Capas
∗ Un sistema bancario por Internet es un ejemplo de una
arquitectura cliente-servidor de tres capas.
∗ La base de datos de clientes del banco (usualmente
ubicada sobre una computadora mainframe)
proporciona servicios de gestión de datos; un servidor
web proporciona los servicios de aplicación tales como
facilidades para transferir efectivo, generar estados de
cuenta, pagar facturas, y así sucesivamente.
∗ La propia computadora del usuario con un navegador
de Internet es el cliente.
Modelo Cliente –Servidor de 3
Capas
∗ El sistema es escalable, porque es relativamente fácil
añadir nuevos servidores web, a medida que el número de
clientes crece.
∗ El uso de una arquitectura de tres capas permite
optimizar la transferencia de información entre el servidor
web y el servidor de la base de datos.
∗ Las comunicaciones entre estos sistemas pueden usar
protocolos de comunicación de bajo nivel muy rápidos.
∗ Para recuperar información de la base de datos se utiliza
un middleware eficiente que soporte consultas a la base
de datos en SQL (Structured Query Language).
Modelo Cliente –Servidor de 3
Capas
∗ Figura de Modelo de Arquitectura Cliente – Servidor
de 3 Capas (Sistema Bancario en Internet)
Modelo Cliente –Servidor de 3
Capas
∗ Cuadro – resumen del uso de diferentes arquitecturas
Cliente – Servidor:
Modelo Cliente –Servidor
∗ A veces sirve extender el modelo cliente-servidor de
tres capas a una variante multicapa en la que se
añaden al sistema servidores adicionales.
∗ Los sistemas multicapa pueden usarse cuando las
aplicaciones necesitan acceder y usar datos de
diferentes bases de datos.
∗ Entonces, un servidor de integración se ubica entre el
servidor de aplicaciones y los servidores de la base de
datos.
∗ El servidor de integración recoge los datos distribuidos
y los presenta a la aplicación como si se obtuviesen
desde una única base de datos.
Modelo Cliente –Servidor
∗ Las arquitecturas cliente-servidor de tres capas y las
variantes multicapa, que distribuyen el procesamiento de
la aplicación entre varios servidores, son más escalables
que las arquitecturas de dos capas.
∗ El tráfico de la red se reduce, al contrario que con las
arquitecturas de dos capas de cliente ligero.
∗ El procesamiento de la aplicación es la parte más volátil del
sistema, y puede ser fácilmente actualizada, porque está
localizada centralmente.
∗ El procesamiento, en algunos casos, puede distribuirse
entre: la lógica de la aplicación y los servidores de gestión
de datos, lo que permite una respuesta más rápida a las
peticiones de los clientes.
Modelo Cliente –Servidor
∗ En el modelo cliente-servidor de un sistema
distribuido, los clientes y los servidores son
diferentes.
∗ Los clientes reciben servicios de los servidores y no de
otros clientes; los servidores pueden actuar como
clientes recibiendo servicios de otros servidores, pero
sin solicitar servicios de clientes.
∗ Los clientes deben conocer los servicios que ofrece
cada uno de los servidores y deben conocer cómo
contactar con cada uno de ellos.
Arquitecturas de Objetos
Distribuidos
∗ El modelo Cliente – Servidor funciona bien para
muchos tipos de aplicaciones.
∗ Sin embargo, limita la flexibilidad del diseñador, que
debe decidir dónde se proporciona cada servicio.
∗ También debe planificar la escalabilidad y
proporcionar algún medio para distribuir la carga
sobre los servidores, cuando más clientes se añadan
al sistema.
Arquitecturas de Objetos
Distribuidos
∗ Una opción superadora es eliminar la distinción entre
cliente y servidor y diseñar una arquitectura de
objetos distribuidos.
∗ Aquí, los componentes del sistema son objetos que
proporcionan y requieren un conjunto de servicios.
∗ Otros objetos realizan llamadas a estos servicios sin
hacer ninguna distinción lógica entre un cliente (el
receptor de un servicio) y un servidor (el proveedor
de un servicio).
Arquitecturas de Objetos
Distribuidos
∗ Los objetos pueden distribuirse a través de varias
computadoras en una red y comunicarse a través de
middleware.
∗ A este middleware se lo denomina intermediario de
peticiones de objetos.
∗ Su misión es proporcionar una interfaz transparente entre
los objetos.
∗ Proporciona un conjunto de servicios que permiten la
comunicación entre los objetos y que éstos sean añadidos y
eliminados del sistema.
Arquitecturas de Objetos
Distribuidos
∗ Ventajas del modelo de objetos distribuido:
1) Permite al diseñador retrasar decisiones sobre dónde
y cómo deberían proporcionarse los servicios.
∗ Los objetos que proporcionan servicios pueden
ejecutarse sobre cualquier nodo de la red.
∗ Por lo tanto, la distinción entre los modelos de cliente
rico y ligero es irrelevante, ya que no hay necesidad
de decidir con antelación dónde ubicamos la lógica de
aplicación de los objetos.
Arquitecturas de Objetos
Distribuidos
2) Es una arquitectura abierta: permite añadir nuevos
recursos si es necesario.
∗Se han desarrollado estándares de comunicación de
objetos, que permiten escribir objetos, en diferentes
lenguajes de programación para comunicarse y
proporcionarse servicios entre ellos.
3) El sistema es flexible y escalable.
∗Pueden añadirse nuevos objetos, a medida que la
carga del sistema se incrementa, sin afectar al resto de
los objetos del sistema.
Arquitecturas de Objetos
Distribuidos
4) Si es necesario, se puede reconfigurar el sistema, de
forma dinámica, mediante la migración de objetos a
través de la red.
∗Esto importa cuando haya fluctuación en los patrones
de demanda de servicios.
∗Un objeto que proporciona servicios puede migrar al
mismo procesador que los objetos que demandan los
servicios, lo que mejora el rendimiento del sistema.
Arquitecturas de Objetos
Distribuidos
∗ Arquitectura de Objetos Distribuidos:
Arquitecturas de Objetos
Distribuidos
∗ Una arquitectura de objetos distribuidos puede ser
usada como un modelo lógico que permita
estructurar el sistema.
∗ Entonces, debemos pensar cómo proporcionar las
funcionalidades de la aplicación únicamente en
términos de servicios y combinaciones de servicios.
∗ Después, debemos identificar cómo proporcionar
estos servicios utilizando varios objetos distribuidos.
Arquitecturas de Objetos
Distribuidos
∗ La principal desventaja de las arquitecturas de objetos
distribuidos es que son mucho más complejas de
diseñar que los sistemas cliente-servidor.
∗ Los sistemas cliente-servidor parecen ser la forma
más natural de concebir a los sistemas.
∗ Estos reflejan muchas transacciones humanas, en las
que la gente solicita y recibe servicios de otra gente
especializada en proporcionárselos.
∗ Es más difícil pensar en una provisión de servicios
generales.
Arquitecturas de Objetos
Distribuidos
∗ 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 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.
Arquitecturas Peer-to-Peer
∗ Los estándares y protocolos que posibilitan las
comunicaciones, a través de los nodos, están
embebidos en la propia aplicación.
∗ Cada nodo debe ejecutar una copia de dicha
aplicación.
∗ Las tecnologías peer-to-peer han sido mayormente
usadas para sistemas personales.
∗ Sin embargo, se está utilizando de forma creciente en
empresas con potentes redes de PCs.
Arquitecturas Peer-to-Peer
∗ Intel y Boeing han implementado sistemas p2p para
aplicaciones que requieren computaciones intensivas.
∗ Para aplicaciones cooperativas que soportan trabajo
distribuido, es la tecnología más efectiva.
∗ Hay dos tipos principales de arquitecturas lógicas de
red que se pueden usar: arquitecturas
descentralizadas y arquitecturas semicentralizadas.
Arquitecturas Peer-to-Peer
∗ En teoría, en los sistemas peer-to-peer, cada nodo podría
conocer cualquier otro nodo, conectarse con él, e
intercambiar datos.
∗ En la práctica, 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.
∗ En una arquitectura descentralizada, los nodos en la red no
son simplemente elementos funcionales, sino que también
son interruptores de comunicaciones que pueden encaminar
los datos y señales de control de un nodo a otro.
∗ En la figura siguiente, si n1 debe buscar un archivo que está
almacenado en n10, esta búsqueda se encamina a través de los
nodos n3, n6 y n9 hasta llegar a n10.
Arquitecturas Peer-to-Peer
∗ Arquitectura p2p descentralizada:
Arquitecturas Peer-to-Peer
∗ Esta arquitectura descentralizada tiene ventajas: es
altamente redundante, y tolerante a defectos y a
nodos desconectados de la red.
∗ Sin embargo, existen sobrecargas obvias en el sistema
ya que la misma búsqueda puede ser procesada por
muchos nodos diferentes y hay una sobrecarga
significativa en comunicaciones.
∗ Un modelo de arquitectura p2p alternativo que parte
de una arquitectura p2p pura es una arquitectura
semicentralizada en la que, dentro de la red, uno o
más nodos actúan como servidores para facilitar las
comunicaciones entre los nodos.
Arquitecturas Peer-to-Peer
∗ Arquitectura p2p SemiCentralizada
Arquitecturas Peer-to-Peer
∗ En una arquitectura semicentralizada, el papel del servidor
es ayudar a establecer contacto entre iguales en la red o
para coordinar los resultados de un cálculo.
∗ Por ejemplo, si la Figura anterior representa un sistema de
mensajería instantánea, entonces los nodos de la red se
comunican con el servidor (indicado por líneas punteadas),
para encontrar qué otros nodos están disponibles.
∗ Una vez que éstos son encontrados, se pueden establecer
comunicaciones directas y la conexión con el servidor es
innecesaria.
∗ Por lo tanto, los nodos n2, n3, n5 y n6 están en
comunicación directa.
Arquitecturas Peer-to-Peer
∗ En un sistema p2p, donde un cálculo (que requiere un
uso intensivo del procesador) se distribuye a través
de un gran número de nodos, es normal que se
distingan algunos nodos cuyo papel es distribuir el
trabajo a otros nodos y reunir y comprobar los
resultados del cálculo.
∗ Si bien hay sobrecargas obvias en los sistemas peer-
to-peer, éstos son una aproximación mucho más
eficiente para la computación interorganizacional
que la aproximación basada en servicios que veremos
seguidamente.
Arquitecturas Peer-to-Peer
∗ Todavía hay problemas en el uso de las arquitecturas
p2p, ya que cuestiones tales como la protección y la
autenticidad no están del todo resueltas.
∗ Esto significa que los sistemas p2p se usan más en
sistemas de información no críticos.
Arquitecturas Peer-to-Peer
∗ Noción de Servicio Web: Por ellos, las organizaciones que
quieren hacer accesible su información a otros programas,
definen y publican una interfaz de servicio web.
∗ Esta interfaz define los datos disponibles y cómo se puede
acceder a ellos.
∗ Un Servicio Web es una representación estándar para
cualquier recurso computacional o de información que
pueda ser usado por otros programas.
∗ La esencia de un servicio, por lo tanto, es que la provisión
de servicio es independiente de la aplicación que utiliza el
servicio.
Arquitectura de Sistemas
orientados a Servicios
∗ Los proveedores de servicios pueden desarrollar
servicios especializados y ofertarlos a un cierto
número de usuarios de servicios de diferentes
organizaciones.
∗ Existen varios modelos de servicios, aunque todos
ellos operan de acuerdo al modelo de la Figura
siguiente.
∗ Un proveedor de servicio oferta un servicio
definiendo su interfaz y definiendo la funcionalidad
del servicio.
Arquitectura de Sistemas
orientados a Servicios
∗ Un solicitante del servicio enlaza este servicio en su
aplicación.
∗ Es decir, la aplicación del solicitante incluye un código
para llamar al servicio y procesa el resultado de esa
llamada al servicio.
∗ Para asegurar que el servicio puede ser accedido por
usuarios externos, el proveedor de servicios registra
una entrada en el servicio de registro, que incluye
información sobre el servicio y lo que hace.
Arquitectura de Sistemas
orientados a Servicios
∗ Arquitectura Conceptual de un Sistema orientado a
Servicios:
Arquitectura de Sistemas
orientados a Servicios
∗ Diferencias entre el Modelo de Servicios y la
aproximación de Objetos Distribuidos:
∗ Los servicios pueden ofertarse por cualquier
proveedor de servicio dentro o fuera de una
organización.
∗ Las organizaciones pueden crear aplicaciones
integrando servicios desde varios proveedores.
∗ Por ejemplo, un compañía industrial puede enlazar
directamente a los servicios de sus proveedores.
Arquitectura de Sistemas
orientados a Servicios
∗ El proveedor de servicios hace pública la información
sobre el servicio para que cualquier usuario autorizado
pueda usarlo.
∗ El proveedor de servicios y el usuario de los servicios no
necesitan negociar sobre lo que el servicio hace.
∗ Las aplicaciones pueden retrasar el enlace de los servicios
hasta que éstas sean desplegadas o hasta que estén en
ejecución.
∗ Es posible la construcción de nuevos servicios.
∗ Un proveedor de servicios puede reconocer nuevos
servicios que se creen.
Arquitectura de Sistemas
orientados a Servicios
∗ De este modo, los usuarios de los servicios pueden pagar por
los servicios con arreglo a su uso en vez de a su provisión.
∗ Por lo tanto, en lugar de comprar un componente de precio
elevado que se usa muy raramente, el desarrollador puede
usar un servicio externo por el que pagará solamente
cuando sea requerido.
∗ Las aplicaciones pueden ser reactivas y adaptar su operación
de acuerdo con su entorno, enlazando con diferentes
servicios según sea cada caso.
Arquitectura de Sistemas
orientados a Servicios

Weitere ähnliche Inhalte

Was ist angesagt?

Modelos de desarrollo de aplicaciones web
Modelos de desarrollo de aplicaciones webModelos de desarrollo de aplicaciones web
Modelos de desarrollo de aplicaciones webYaskelly Yedra
 
Modelado de analisis para aplicaciones web
Modelado de analisis para aplicaciones webModelado de analisis para aplicaciones web
Modelado de analisis para aplicaciones webMaritzaD
 
Distribución y fragmentación de datos
Distribución y fragmentación  de datosDistribución y fragmentación  de datos
Distribución y fragmentación de datosJosé Mendoza
 
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negociosFundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negociosJosé Antonio Sandoval Acosta
 
Ventajas y desventajas de los servidores apache y IIS
Ventajas y desventajas de los servidores apache y IISVentajas y desventajas de los servidores apache y IIS
Ventajas y desventajas de los servidores apache y IISelianaespinoza
 
Programación del lado del cliente
Programación del lado del clienteProgramación del lado del cliente
Programación del lado del clienteGabriel Mondragón
 
Arquitectura flujo de datos(filtros y tuberías)
Arquitectura flujo de datos(filtros y tuberías)Arquitectura flujo de datos(filtros y tuberías)
Arquitectura flujo de datos(filtros y tuberías)katherine revelo gomez
 
DISEÑO DE LA ARQUITECTURA DEL SOFTWARE
DISEÑO DE LA ARQUITECTURA DEL SOFTWAREDISEÑO DE LA ARQUITECTURA DEL SOFTWARE
DISEÑO DE LA ARQUITECTURA DEL SOFTWAREjose_rob
 
Modelado de requisitos
Modelado de requisitosModelado de requisitos
Modelado de requisitosKleo Jorgee
 

Was ist angesagt? (20)

Modelos de desarrollo de aplicaciones web
Modelos de desarrollo de aplicaciones webModelos de desarrollo de aplicaciones web
Modelos de desarrollo de aplicaciones web
 
Transaccion
TransaccionTransaccion
Transaccion
 
Modelado de analisis para aplicaciones web
Modelado de analisis para aplicaciones webModelado de analisis para aplicaciones web
Modelado de analisis para aplicaciones web
 
Distribución y fragmentación de datos
Distribución y fragmentación  de datosDistribución y fragmentación  de datos
Distribución y fragmentación de datos
 
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negociosFundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
Fundamentos de Ingenieria de Software - Unidad 1 modelo de negocios
 
Ventajas y desventajas de los servidores apache y IIS
Ventajas y desventajas de los servidores apache y IISVentajas y desventajas de los servidores apache y IIS
Ventajas y desventajas de los servidores apache y IIS
 
UML
UMLUML
UML
 
RPC
RPCRPC
RPC
 
Metodologia Diseño Web
Metodologia Diseño WebMetodologia Diseño Web
Metodologia Diseño Web
 
Programación del lado del cliente
Programación del lado del clienteProgramación del lado del cliente
Programación del lado del cliente
 
Procedimientos almacenados
Procedimientos almacenadosProcedimientos almacenados
Procedimientos almacenados
 
Arquitectura flujo de datos(filtros y tuberías)
Arquitectura flujo de datos(filtros y tuberías)Arquitectura flujo de datos(filtros y tuberías)
Arquitectura flujo de datos(filtros y tuberías)
 
Diseño de Software
Diseño de SoftwareDiseño de Software
Diseño de Software
 
DISEÑO DE LA ARQUITECTURA DEL SOFTWARE
DISEÑO DE LA ARQUITECTURA DEL SOFTWAREDISEÑO DE LA ARQUITECTURA DEL SOFTWARE
DISEÑO DE LA ARQUITECTURA DEL SOFTWARE
 
Historias de usuario
Historias de usuarioHistorias de usuario
Historias de usuario
 
Qué es el modelado de negocios
Qué es el modelado de negociosQué es el modelado de negocios
Qué es el modelado de negocios
 
Ingeniería web_Unidad 3
Ingeniería web_Unidad 3Ingeniería web_Unidad 3
Ingeniería web_Unidad 3
 
Estilos Arquitectonicos-Capas
Estilos Arquitectonicos-CapasEstilos Arquitectonicos-Capas
Estilos Arquitectonicos-Capas
 
Modelado de requisitos
Modelado de requisitosModelado de requisitos
Modelado de requisitos
 
Rup disciplinas
Rup disciplinasRup disciplinas
Rup disciplinas
 

Ähnlich wie Arquitectura de sistemas

Arquitecturas de software
Arquitecturas de software Arquitecturas de software
Arquitecturas de software Anel Sosa
 
Clase rii 10 11 u3 sistemas cliente servidor
Clase rii 10 11 u3 sistemas cliente servidorClase rii 10 11 u3 sistemas cliente servidor
Clase rii 10 11 u3 sistemas cliente servidorGregorio Tkachuk
 
Arquitecturasdesistemasdebasesdedatos.docx
Arquitecturasdesistemasdebasesdedatos.docxArquitecturasdesistemasdebasesdedatos.docx
Arquitecturasdesistemasdebasesdedatos.docxWilliam Martinez Perez
 
Sistemas operativos 2
Sistemas operativos 2Sistemas operativos 2
Sistemas operativos 2Chulinneitor
 
UNIDAD 1: SISTEMAS OPERATIVOS EN AMBIENTES DISTRIBUIDOS
UNIDAD 1: SISTEMAS OPERATIVOS EN AMBIENTES DISTRIBUIDOSUNIDAD 1: SISTEMAS OPERATIVOS EN AMBIENTES DISTRIBUIDOS
UNIDAD 1: SISTEMAS OPERATIVOS EN AMBIENTES DISTRIBUIDOShoneyjimenez
 
UNIDAD 1 TEMA 2.pptx
UNIDAD 1 TEMA 2.pptxUNIDAD 1 TEMA 2.pptx
UNIDAD 1 TEMA 2.pptxItatyVivar1
 
Fresdes silvasalazar
Fresdes silvasalazarFresdes silvasalazar
Fresdes silvasalazarjulymci
 
DISEÑO DE SOFTWARE DISTRIBUIDO
DISEÑO DE SOFTWARE DISTRIBUIDODISEÑO DE SOFTWARE DISTRIBUIDO
DISEÑO DE SOFTWARE DISTRIBUIDOFidel Antonio
 
Apuntes de-sistemas-operativos-ii-e2
Apuntes de-sistemas-operativos-ii-e2Apuntes de-sistemas-operativos-ii-e2
Apuntes de-sistemas-operativos-ii-e2annyshey
 
Servidores informaticos, modelo cliente servdor
Servidores informaticos, modelo cliente servdor Servidores informaticos, modelo cliente servdor
Servidores informaticos, modelo cliente servdor Erivan Martinez Ovando
 
Unidad 1 Sistemas Operativos en Ambientes Distribuidos.
Unidad 1 Sistemas Operativos en Ambientes Distribuidos.Unidad 1 Sistemas Operativos en Ambientes Distribuidos.
Unidad 1 Sistemas Operativos en Ambientes Distribuidos.A6M0
 
Unidad 1 sistemas operativos
Unidad 1 sistemas operativosUnidad 1 sistemas operativos
Unidad 1 sistemas operativosFenix Sven
 

Ähnlich wie Arquitectura de sistemas (20)

Arquitectura de sistemas distribuidos
Arquitectura de sistemas distribuidosArquitectura de sistemas distribuidos
Arquitectura de sistemas distribuidos
 
Arquitecturas de software
Arquitecturas de software Arquitecturas de software
Arquitecturas de software
 
Clase rii 10 11 u3 sistemas cliente servidor
Clase rii 10 11 u3 sistemas cliente servidorClase rii 10 11 u3 sistemas cliente servidor
Clase rii 10 11 u3 sistemas cliente servidor
 
Base expo
Base expoBase expo
Base expo
 
Arquitecturasdesistemasdebasesdedatos.docx
Arquitecturasdesistemasdebasesdedatos.docxArquitecturasdesistemasdebasesdedatos.docx
Arquitecturasdesistemasdebasesdedatos.docx
 
Sistemas operativos 2
Sistemas operativos 2Sistemas operativos 2
Sistemas operativos 2
 
UNIDAD 1: SISTEMAS OPERATIVOS EN AMBIENTES DISTRIBUIDOS
UNIDAD 1: SISTEMAS OPERATIVOS EN AMBIENTES DISTRIBUIDOSUNIDAD 1: SISTEMAS OPERATIVOS EN AMBIENTES DISTRIBUIDOS
UNIDAD 1: SISTEMAS OPERATIVOS EN AMBIENTES DISTRIBUIDOS
 
S. o. 2 unidad 1
S. o. 2 unidad 1S. o. 2 unidad 1
S. o. 2 unidad 1
 
UNIDAD 1 TEMA 2.pptx
UNIDAD 1 TEMA 2.pptxUNIDAD 1 TEMA 2.pptx
UNIDAD 1 TEMA 2.pptx
 
Arquitectura cliente
Arquitectura cliente Arquitectura cliente
Arquitectura cliente
 
Unidad 1 equipo 4
Unidad 1 equipo 4Unidad 1 equipo 4
Unidad 1 equipo 4
 
Arquitectura web
Arquitectura webArquitectura web
Arquitectura web
 
Fresdes silvasalazar
Fresdes silvasalazarFresdes silvasalazar
Fresdes silvasalazar
 
Arquitectura centralizada
Arquitectura centralizadaArquitectura centralizada
Arquitectura centralizada
 
DISEÑO DE SOFTWARE DISTRIBUIDO
DISEÑO DE SOFTWARE DISTRIBUIDODISEÑO DE SOFTWARE DISTRIBUIDO
DISEÑO DE SOFTWARE DISTRIBUIDO
 
bd
bdbd
bd
 
Apuntes de-sistemas-operativos-ii-e2
Apuntes de-sistemas-operativos-ii-e2Apuntes de-sistemas-operativos-ii-e2
Apuntes de-sistemas-operativos-ii-e2
 
Servidores informaticos, modelo cliente servdor
Servidores informaticos, modelo cliente servdor Servidores informaticos, modelo cliente servdor
Servidores informaticos, modelo cliente servdor
 
Unidad 1 Sistemas Operativos en Ambientes Distribuidos.
Unidad 1 Sistemas Operativos en Ambientes Distribuidos.Unidad 1 Sistemas Operativos en Ambientes Distribuidos.
Unidad 1 Sistemas Operativos en Ambientes Distribuidos.
 
Unidad 1 sistemas operativos
Unidad 1 sistemas operativosUnidad 1 sistemas operativos
Unidad 1 sistemas operativos
 

Mehr von Tensor

Libertad
LibertadLibertad
LibertadTensor
 
Método de la regla falsa (o metodo de la falsa posición)
Método de la regla falsa (o metodo de la falsa posición)Método de la regla falsa (o metodo de la falsa posición)
Método de la regla falsa (o metodo de la falsa posición)Tensor
 
Metodo de la bisección
Metodo de la bisecciónMetodo de la bisección
Metodo de la bisecciónTensor
 
Transito vehicular
Transito vehicularTransito vehicular
Transito vehicularTensor
 
Teoria de colas
Teoria de colasTeoria de colas
Teoria de colasTensor
 
Practica 7 2016
Practica 7 2016Practica 7 2016
Practica 7 2016Tensor
 
Practica 6 2016
Practica 6 2016Practica 6 2016
Practica 6 2016Tensor
 
Game maker
Game makerGame maker
Game makerTensor
 
Practica 5 2016
Practica 5 2016Practica 5 2016
Practica 5 2016Tensor
 
Procesamiento de archivos
Procesamiento de archivosProcesamiento de archivos
Procesamiento de archivosTensor
 
Cadenas y funciones de cadena
Cadenas y funciones de cadenaCadenas y funciones de cadena
Cadenas y funciones de cadenaTensor
 
Simulación en promodel clase 04
Simulación en promodel clase 04Simulación en promodel clase 04
Simulación en promodel clase 04Tensor
 
Reduccion de orden
Reduccion de ordenReduccion de orden
Reduccion de ordenTensor
 
Variación+de+parametros
Variación+de+parametrosVariación+de+parametros
Variación+de+parametrosTensor
 
Coeficientes indeterminados enfoque de superposición
Coeficientes indeterminados   enfoque de superposiciónCoeficientes indeterminados   enfoque de superposición
Coeficientes indeterminados enfoque de superposiciónTensor
 
Bernoulli y ricatti
Bernoulli y ricattiBernoulli y ricatti
Bernoulli y ricattiTensor
 
Practica no. 3 tiempo de servicio
Practica no. 3 tiempo de servicioPractica no. 3 tiempo de servicio
Practica no. 3 tiempo de servicioTensor
 
Clase 14 ondas reflejadas
Clase 14 ondas reflejadasClase 14 ondas reflejadas
Clase 14 ondas reflejadasTensor
 
Ondas em
Ondas emOndas em
Ondas emTensor
 
Clase 7 ondas electromagneticas
Clase 7 ondas electromagneticasClase 7 ondas electromagneticas
Clase 7 ondas electromagneticasTensor
 

Mehr von Tensor (20)

Libertad
LibertadLibertad
Libertad
 
Método de la regla falsa (o metodo de la falsa posición)
Método de la regla falsa (o metodo de la falsa posición)Método de la regla falsa (o metodo de la falsa posición)
Método de la regla falsa (o metodo de la falsa posición)
 
Metodo de la bisección
Metodo de la bisecciónMetodo de la bisección
Metodo de la bisección
 
Transito vehicular
Transito vehicularTransito vehicular
Transito vehicular
 
Teoria de colas
Teoria de colasTeoria de colas
Teoria de colas
 
Practica 7 2016
Practica 7 2016Practica 7 2016
Practica 7 2016
 
Practica 6 2016
Practica 6 2016Practica 6 2016
Practica 6 2016
 
Game maker
Game makerGame maker
Game maker
 
Practica 5 2016
Practica 5 2016Practica 5 2016
Practica 5 2016
 
Procesamiento de archivos
Procesamiento de archivosProcesamiento de archivos
Procesamiento de archivos
 
Cadenas y funciones de cadena
Cadenas y funciones de cadenaCadenas y funciones de cadena
Cadenas y funciones de cadena
 
Simulación en promodel clase 04
Simulación en promodel clase 04Simulación en promodel clase 04
Simulación en promodel clase 04
 
Reduccion de orden
Reduccion de ordenReduccion de orden
Reduccion de orden
 
Variación+de+parametros
Variación+de+parametrosVariación+de+parametros
Variación+de+parametros
 
Coeficientes indeterminados enfoque de superposición
Coeficientes indeterminados   enfoque de superposiciónCoeficientes indeterminados   enfoque de superposición
Coeficientes indeterminados enfoque de superposición
 
Bernoulli y ricatti
Bernoulli y ricattiBernoulli y ricatti
Bernoulli y ricatti
 
Practica no. 3 tiempo de servicio
Practica no. 3 tiempo de servicioPractica no. 3 tiempo de servicio
Practica no. 3 tiempo de servicio
 
Clase 14 ondas reflejadas
Clase 14 ondas reflejadasClase 14 ondas reflejadas
Clase 14 ondas reflejadas
 
Ondas em
Ondas emOndas em
Ondas em
 
Clase 7 ondas electromagneticas
Clase 7 ondas electromagneticasClase 7 ondas electromagneticas
Clase 7 ondas electromagneticas
 

Kürzlich hochgeladen

EL BRILLO DEL ECLIPSE (CUENTO LITERARIO). Autor y diseñador JAVIER SOLIS NOYOLA
EL BRILLO DEL ECLIPSE (CUENTO LITERARIO). Autor y diseñador JAVIER SOLIS NOYOLAEL BRILLO DEL ECLIPSE (CUENTO LITERARIO). Autor y diseñador JAVIER SOLIS NOYOLA
EL BRILLO DEL ECLIPSE (CUENTO LITERARIO). Autor y diseñador JAVIER SOLIS NOYOLAJAVIER SOLIS NOYOLA
 
UNIDAD DE APRENDIZAJE MARZO 2024.docx para educacion
UNIDAD DE APRENDIZAJE MARZO 2024.docx para educacionUNIDAD DE APRENDIZAJE MARZO 2024.docx para educacion
UNIDAD DE APRENDIZAJE MARZO 2024.docx para educacionCarolVigo1
 
CIENCIAS SOCIALES SEGUNDO TRIMESTRE CUARTO
CIENCIAS SOCIALES SEGUNDO TRIMESTRE CUARTOCIENCIAS SOCIALES SEGUNDO TRIMESTRE CUARTO
CIENCIAS SOCIALES SEGUNDO TRIMESTRE CUARTOCEIP TIERRA DE PINARES
 
U2_EA2_descargable TICS PRESENCIAL 2.pdf
U2_EA2_descargable TICS PRESENCIAL 2.pdfU2_EA2_descargable TICS PRESENCIAL 2.pdf
U2_EA2_descargable TICS PRESENCIAL 2.pdfJavier Correa
 
Anna Llenas Serra. El monstruo de colores. Doctor de emociones.pdf
Anna Llenas Serra. El monstruo de colores. Doctor de emociones.pdfAnna Llenas Serra. El monstruo de colores. Doctor de emociones.pdf
Anna Llenas Serra. El monstruo de colores. Doctor de emociones.pdfSaraGabrielaPrezPonc
 
La Gatera de la Villa nº 51. Revista cultural sobre Madrid..
La Gatera de la Villa nº 51. Revista cultural sobre Madrid..La Gatera de la Villa nº 51. Revista cultural sobre Madrid..
La Gatera de la Villa nº 51. Revista cultural sobre Madrid..La Gatera de la Villa
 
PROGRAMACIÓN CURRICULAR ANUAL DE CIENCIA Y TECNOLOGÍA
PROGRAMACIÓN CURRICULAR ANUAL DE CIENCIA Y TECNOLOGÍAPROGRAMACIÓN CURRICULAR ANUAL DE CIENCIA Y TECNOLOGÍA
PROGRAMACIÓN CURRICULAR ANUAL DE CIENCIA Y TECNOLOGÍAJoaqunSolrzano
 
Escrito administrativo técnico y comerciales
Escrito administrativo técnico y comercialesEscrito administrativo técnico y comerciales
Escrito administrativo técnico y comercialesmelanieteresacontrer
 
CARPETA PEDAGÓGICA 2024.docx para educacion
CARPETA PEDAGÓGICA 2024.docx para educacionCARPETA PEDAGÓGICA 2024.docx para educacion
CARPETA PEDAGÓGICA 2024.docx para educacionCarolVigo1
 
Presentación: Actividad de Diálogos adolescentes.pptx
Presentación: Actividad de  Diálogos adolescentes.pptxPresentación: Actividad de  Diálogos adolescentes.pptx
Presentación: Actividad de Diálogos adolescentes.pptxNabel Paulino Guerra Huaranca
 
La Congregación de Jesús y María, conocida también como los Eudistas, fue fun...
La Congregación de Jesús y María, conocida también como los Eudistas, fue fun...La Congregación de Jesús y María, conocida también como los Eudistas, fue fun...
La Congregación de Jesús y María, conocida también como los Eudistas, fue fun...Unidad de Espiritualidad Eudista
 
GUÍA SIANET - Agenda - Tareas - Archivos - Participaciones - Notas.pdf
GUÍA SIANET - Agenda - Tareas - Archivos - Participaciones - Notas.pdfGUÍA SIANET - Agenda - Tareas - Archivos - Participaciones - Notas.pdf
GUÍA SIANET - Agenda - Tareas - Archivos - Participaciones - Notas.pdfNELLYKATTY
 
Herbert James Drape. Erotismo y sensualidad.pptx
Herbert James Drape. Erotismo y sensualidad.pptxHerbert James Drape. Erotismo y sensualidad.pptx
Herbert James Drape. Erotismo y sensualidad.pptxArs Erótica
 
1° GRADO UNIDAD DE APRENDIZAJE 0 - 2024.pdf
1° GRADO UNIDAD DE APRENDIZAJE 0 - 2024.pdf1° GRADO UNIDAD DE APRENDIZAJE 0 - 2024.pdf
1° GRADO UNIDAD DE APRENDIZAJE 0 - 2024.pdfdiana593621
 
Tecnología educativa en la era actual .pptx
Tecnología educativa en la era actual .pptxTecnología educativa en la era actual .pptx
Tecnología educativa en la era actual .pptxJulioSantin2
 
CIENCIAS SOCIALES SEGUNDO TRIMESTRE TERCERO
CIENCIAS SOCIALES SEGUNDO TRIMESTRE TERCEROCIENCIAS SOCIALES SEGUNDO TRIMESTRE TERCERO
CIENCIAS SOCIALES SEGUNDO TRIMESTRE TERCEROCEIP TIERRA DE PINARES
 
Presentación contribuciones socioeconómicas del SUPV 2023
Presentación contribuciones socioeconómicas del SUPV 2023Presentación contribuciones socioeconómicas del SUPV 2023
Presentación contribuciones socioeconómicas del SUPV 2023Ivie
 

Kürzlich hochgeladen (20)

EL BRILLO DEL ECLIPSE (CUENTO LITERARIO). Autor y diseñador JAVIER SOLIS NOYOLA
EL BRILLO DEL ECLIPSE (CUENTO LITERARIO). Autor y diseñador JAVIER SOLIS NOYOLAEL BRILLO DEL ECLIPSE (CUENTO LITERARIO). Autor y diseñador JAVIER SOLIS NOYOLA
EL BRILLO DEL ECLIPSE (CUENTO LITERARIO). Autor y diseñador JAVIER SOLIS NOYOLA
 
UNIDAD DE APRENDIZAJE MARZO 2024.docx para educacion
UNIDAD DE APRENDIZAJE MARZO 2024.docx para educacionUNIDAD DE APRENDIZAJE MARZO 2024.docx para educacion
UNIDAD DE APRENDIZAJE MARZO 2024.docx para educacion
 
CIENCIAS SOCIALES SEGUNDO TRIMESTRE CUARTO
CIENCIAS SOCIALES SEGUNDO TRIMESTRE CUARTOCIENCIAS SOCIALES SEGUNDO TRIMESTRE CUARTO
CIENCIAS SOCIALES SEGUNDO TRIMESTRE CUARTO
 
Sesión de clase ES: Adoración sin fin...
Sesión de clase ES: Adoración sin fin...Sesión de clase ES: Adoración sin fin...
Sesión de clase ES: Adoración sin fin...
 
U2_EA2_descargable TICS PRESENCIAL 2.pdf
U2_EA2_descargable TICS PRESENCIAL 2.pdfU2_EA2_descargable TICS PRESENCIAL 2.pdf
U2_EA2_descargable TICS PRESENCIAL 2.pdf
 
Anna Llenas Serra. El monstruo de colores. Doctor de emociones.pdf
Anna Llenas Serra. El monstruo de colores. Doctor de emociones.pdfAnna Llenas Serra. El monstruo de colores. Doctor de emociones.pdf
Anna Llenas Serra. El monstruo de colores. Doctor de emociones.pdf
 
La Gatera de la Villa nº 51. Revista cultural sobre Madrid..
La Gatera de la Villa nº 51. Revista cultural sobre Madrid..La Gatera de la Villa nº 51. Revista cultural sobre Madrid..
La Gatera de la Villa nº 51. Revista cultural sobre Madrid..
 
PROGRAMACIÓN CURRICULAR ANUAL DE CIENCIA Y TECNOLOGÍA
PROGRAMACIÓN CURRICULAR ANUAL DE CIENCIA Y TECNOLOGÍAPROGRAMACIÓN CURRICULAR ANUAL DE CIENCIA Y TECNOLOGÍA
PROGRAMACIÓN CURRICULAR ANUAL DE CIENCIA Y TECNOLOGÍA
 
Escrito administrativo técnico y comerciales
Escrito administrativo técnico y comercialesEscrito administrativo técnico y comerciales
Escrito administrativo técnico y comerciales
 
CARPETA PEDAGÓGICA 2024.docx para educacion
CARPETA PEDAGÓGICA 2024.docx para educacionCARPETA PEDAGÓGICA 2024.docx para educacion
CARPETA PEDAGÓGICA 2024.docx para educacion
 
Presentación: Actividad de Diálogos adolescentes.pptx
Presentación: Actividad de  Diálogos adolescentes.pptxPresentación: Actividad de  Diálogos adolescentes.pptx
Presentación: Actividad de Diálogos adolescentes.pptx
 
La Congregación de Jesús y María, conocida también como los Eudistas, fue fun...
La Congregación de Jesús y María, conocida también como los Eudistas, fue fun...La Congregación de Jesús y María, conocida también como los Eudistas, fue fun...
La Congregación de Jesús y María, conocida también como los Eudistas, fue fun...
 
GUÍA SIANET - Agenda - Tareas - Archivos - Participaciones - Notas.pdf
GUÍA SIANET - Agenda - Tareas - Archivos - Participaciones - Notas.pdfGUÍA SIANET - Agenda - Tareas - Archivos - Participaciones - Notas.pdf
GUÍA SIANET - Agenda - Tareas - Archivos - Participaciones - Notas.pdf
 
Herbert James Drape. Erotismo y sensualidad.pptx
Herbert James Drape. Erotismo y sensualidad.pptxHerbert James Drape. Erotismo y sensualidad.pptx
Herbert James Drape. Erotismo y sensualidad.pptx
 
Tema 5.- BASES DE DATOS Y GESTIÓN DE LA INF. PARA EL MARKETING.pdf
Tema 5.- BASES DE DATOS Y GESTIÓN DE LA INF. PARA EL MARKETING.pdfTema 5.- BASES DE DATOS Y GESTIÓN DE LA INF. PARA EL MARKETING.pdf
Tema 5.- BASES DE DATOS Y GESTIÓN DE LA INF. PARA EL MARKETING.pdf
 
1° GRADO UNIDAD DE APRENDIZAJE 0 - 2024.pdf
1° GRADO UNIDAD DE APRENDIZAJE 0 - 2024.pdf1° GRADO UNIDAD DE APRENDIZAJE 0 - 2024.pdf
1° GRADO UNIDAD DE APRENDIZAJE 0 - 2024.pdf
 
Actividad de bienestar docente 2016 Pereira
Actividad de bienestar docente 2016 PereiraActividad de bienestar docente 2016 Pereira
Actividad de bienestar docente 2016 Pereira
 
Tecnología educativa en la era actual .pptx
Tecnología educativa en la era actual .pptxTecnología educativa en la era actual .pptx
Tecnología educativa en la era actual .pptx
 
CIENCIAS SOCIALES SEGUNDO TRIMESTRE TERCERO
CIENCIAS SOCIALES SEGUNDO TRIMESTRE TERCEROCIENCIAS SOCIALES SEGUNDO TRIMESTRE TERCERO
CIENCIAS SOCIALES SEGUNDO TRIMESTRE TERCERO
 
Presentación contribuciones socioeconómicas del SUPV 2023
Presentación contribuciones socioeconómicas del SUPV 2023Presentación contribuciones socioeconómicas del SUPV 2023
Presentación contribuciones socioeconómicas del SUPV 2023
 

Arquitectura de sistemas

  • 1. Diseño Arquitectónico A. Organización del Sistema a. Arquitectura centrada en datos b. Arquitectura en capas c. Arquitectura de sistemas distribuidos c.1. Multiprocesador c.2. Cliente/Servidor c.3. Objetos distribuidos c.4. Peer-to-peer c.5. Orientada a servidos d. Arquitecturas de Aplicaciones Modelos de dominio específico Sommerville. Cap. 11 Sommerville. Cap. 12 Sommerville. Cap. 13 B. Descomposición modular y estilos de control a. Orientada a Objetos b. Orientada a flujos de funciones c. Control centralizado d. Control basado en eventos Sommerville. Sección 11.3
  • 2. ∗ Prácticamente todos los grandes sistemas informáticos son sistemas distribuidos. ∗ En un sistema distribuido el procesamiento de información se distribuye sobre varias computadoras en vez de estar confinado en una única máquina. ∗ Ventajas: 1. Compartir recursos. Un sistema distribuido permite compartir recursos hardware y software (discos, impresoras, ficheros y compiladores) que se asocian con computadoras de una red. Arquitecturas de Sistemas Distribuidos
  • 3. 2. Apertura. Son normalmente sistemas abiertos: se diseñan sobre protocolos estándares que permiten combinar equipamiento y software de diferentes vendedores. 3. Concurrencia. Varios procesos pueden operar al mismo tiempo sobre diferentes computadoras de la red. Hasta pueden comunicarse con otros durante su funcionamiento. 4. Escalabilidad. Los sistemas distribuidos son escalables mientras la capacidad del sistema pueda incrementarse, añadiendo nuevos recursos para cubrir nuevas demandas sobre el sistema. Arquitecturas de Sistemas Distribuidos: Ventajas
  • 4. En la práctica, si se añaden muchas computadoras nuevas, la capacidad de la red puede saturarse. 5. Tolerancia a defectos. Contar con varias computadoras y el potencial para reproducir información significa que los sistemas distribuidos pueden ser tolerantes a algunas fallas de funcionamiento del hardware y del software. ∗En la mayoría de los sistemas distribuidos, puede haber un servicio degradado, ante fallas de funcionamiento. Una completa pérdida de servicio sólo ocurre cuando existe una falla de funcionamiento en la red. Arquitecturas de Sistemas Distribuidos: Ventajas
  • 5. 1. Complejidad. Los sistemas distribuidos son más complejos que los sistemas centralizados; lo que hace más difícil comprender sus propiedades emergentes y probar estos sistemas. ∗Por ejemplo, en vez de que el rendimiento del sistema dependa de la velocidad de ejecución de un procesador, depende del ancho de banda y de la velocidad de los procesadores de la red. ∗Mover los recursos de una parte del sistema a otra puede afectar de forma radical al rendimiento del sistema. Arquitecturas de Sistemas Distribuidos: Desventajas
  • 6. 2. Seguridad. Puede accederse al sistema desde varias computadoras diferentes, y el tráfico en la red puede estar sujeto a escuchas indeseadas. ∗Es más difícil mantener la integridad de los datos en el sistema y que los servicios del sistema no se degraden por ataques. 3. Manejabilidad. Las computadoras en un sistema pueden ser de diferentes tipos y ejecutar versiones diferentes de sistemas operativos. ∗Los defectos en una máquina pueden propagarse a otras, con consecuencias inesperadas. ∗Esto significa que se requiere más esfuerzo para gestionar y mantener el funcionamiento del sistema. Arquitecturas de Sistemas Distribuidos: Desventajas
  • 7. 4. Impredecibilidad. Los sistemas distribuidos tienen una respuesta impredecible. ∗La respuesta depende de la carga total en el sistema, de su organización y de la carga de la red. ∗Como todos ellos pueden cambiar rápidamente, el tiempo requerido para responder a una petición de usuario puede variar drásticamente, de una petición a otra. Arquitecturas de Sistemas Distribuidos: Desventajas
  • 8. ∗ El desafío es diseñar software y hardware para proporcionar características deseables a los sistemas distribuidos y minimizar los problemas propios de ellos. ∗ Para eso, debemos comprender las ventajas y desventajas de las diferentes arquitecturas de sistemas distribuidos. ∗ Las 2 arquitecturas más importantes de sistemas distribuidos son : 1. Cliente-Servidor. El sistema se ve como un conjunto de servicios que se proporcionan a los clientes, que los utilizan. 2. Arquitecturas de objetos distribuidos. No distingue entre servidores y clientes. El sistema es un conjunto de objetos que interaccionan, y cuya localización no interesa. No hay distinción entre un proveedor de servicios y el usuario de los mismos. Arquitecturas de Sistemas Distribuidos
  • 9. ∗ El modelo más simple de un sistema distribuido es un sistema multiprocesador donde el software está formado por varios procesos que pueden (aunque no necesariamente) ejecutarse sobre procesadores diferentes. ∗ Este modelo es común en sistemas grandes de tiempo real. ∗ Estos sistemas recogen información, toman decisiones usando esta información y envían señales para modificar el entorno del sistema. Arquitecturas Multiprocesador
  • 10. ∗ Lógicamente, los procesos relacionados con la recopilación de información, toma de decisiones y control de actuadores podrían ejecutarse todos sobre un único procesador bajo el control de un planificador (scheduler). ∗ El uso de múltiples procesadores mejora el rendimiento y adaptabilidad del sistema. ∗ La distribución de procesos entre los procesadores puede ser predeterminada o puede estar bajo el control de un despachador (dispatcher) que decide qué procesos se asignan a cada procesador. Arquitecturas Multiprocesador
  • 11. ∗ Un ejemplo de este tipo de sistemas se muestra en la Figura siguiente. ∗ Es un modelo simplificado de sistema de control de tráfico. ∗ Un conjunto de sensores distribuidos recogen información sobre el flujo de tráfico y la procesan localmente, antes de enviarla a una sala de control. ∗ Los operadores toman decisiones, usando esta información y dan instrucciones a un proceso de control de semáforos. Arquitecturas Multiprocesador
  • 12. ∗ Acá hay varios procesos lógicos para gestionar los sensores, la sala de control y los semáforos. ∗ Estos procesos lógicos pueden individuales o un grupo de procesos. ∗ En este caso, se ejecutarán sobre procesadores diferentes. Arquitecturas Multiprocesador
  • 13. ∗ Sistema Multiprocesador de Control de Tránsito Arquitecturas Multiprocesador
  • 14. ∗ En una arquitectura cliente-servidor, una aplicación se modela como un conjunto de servicios proporcionados por los servidores y un conjunto de clientes que usan estos servicios. ∗ Los clientes necesitan conocer qué servidores están disponibles, pero normalmente no conocen la existencia de otros clientes. ∗ Clientes y servidores son procesos diferentes. ∗ Varios procesos servidores pueden ejecutarse sobre un único procesador servidor; por lo tanto, no hay necesariamente una correspondencia 1:1 entre procesos y procesadores en el sistema. Arquitecturas Cliente - Servidor
  • 15. ∗ Esta Figura muestra la arquitectura física de un sistema con seis computadoras cliente y dos computadoras servidor. Arquitecturas Cliente - Servidor
  • 16. ∗ Esa arquitectura FISICA puede ejecutar los procesos cliente y servidor que se muestran en la figura siguiente. ∗ Acá, Cuando hablamos de clientes y servidores, nos referimos a los procesos lógicos, en vez de a las computadoras físicas sobre las que se ejecutan, como era el caso anterior. Arquitecturas Cliente - Servidor
  • 17. ∗ Sistema de “Procesos” Cliente-Servidor: Arquitecturas Cliente - Servidor
  • 18. ∗ El diseño de sistemas cliente-servidor debería reflejar la estructura lógica de la aplicación que se está desarrollando. ∗ Una forma de ver una aplicación se ilustra en la Figura siguiente, que muestra una aplicación estructurada en tres capas. ∗ La capa de presentación está relacionada con la presentación de la información al usuario y con toda la interacción con él. Arquitecturas Cliente - Servidor
  • 19. ∗ La capa de procesamiento de la aplicación está relacionada con la implementación de la lógica de la aplicación. ∗ La capa de gestión de datos está relacionada con todas las operaciones sobre la base de datos. ∗ En los sistemas centralizados, no es necesario que estas capas estén claramente separadas. ∗ Cuando se diseñe un sistema distribuido, debería hacerse una clara distinción entre ellas, para que sea posible distribuir cada capa sobre una computadora diferente. Arquitecturas Cliente - Servidor
  • 20. ∗ Figura de Capas de las aplicaciones: Arquitecturas Cliente - Servidor
  • 21. ∗ La arquitectura cliente-servidor más simple se denomina arquitectura cliente-servidor de dos capas. ∗ Se organiza como un servidor (o múltiples servidores idénticos) y un conjunto de clientes. ∗ Como se ilustra en la Figura siguiente, las arquitecturas cliente/servidor de dos capas pueden ser de dos tipos: 1. Modelo de cliente ligero (thin-client). Acá todo el procesamiento de las aplicaciones y la gestión de los datos se lleva a cabo en el servidor. ∗ El cliente simplemente es responsable de la capa de presentación del software. Arquitecturas Cliente - Servidor
  • 22. 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. Arquitecturas Cliente - Servidor
  • 23. ∗ Clientes Livianos y Pesados Arquitecturas Cliente - Servidor
  • 24. ∗ Una arquitectura de dos capas con clientes ligeros es la más simple que se utiliza cuando los sistemas heredados centralizados, evolucionan a una arquitectura cliente-servidor. ∗ La interfaz de usuario para estos sistemas se migra a PC’s, y la aplicación en sí misma actúa como un servidor y maneja todo el procesamiento de la aplicación y gestión de datos. ∗ Un modelo de cliente ligero también puede implementarse cuando los clientes son dispositivos de red sencillos en lugar de PC’s o estaciones de trabajo. ∗ El dispositivo de red ejecuta un navegador de Internet y la interfaz de usuario es implementada a través de ese sistema. Modelo de Cliente Ligero/Pobre/Delgado
  • 25. ∗ Una gran desventaja del modelo de cliente ligero es que ubica una elevada carga de procesamiento, tanto en el servidor como en la red. ∗ El servidor es responsable de todos los cálculos, y esto puede implicar la generación de un tráfico significativo en la red entre el cliente y el servidor. ∗ Los dispositivos de computación modernos disponen de una gran cantidad de potencia de procesamiento, que es desperdiciada en la aproximación de cliente ligero, liviano o pobre. Modelo de Cliente Ligero/Pobre/Delgado
  • 26. ∗ El modelo de cliente rico, pesado o gordo hace uso de esta potencia de procesamiento disponible y distribuye, tanto el procesamiento de la lógica de la aplicación, como la presentación al cliente. ∗ El servidor es esencialmente de transacciones. ∗ Gestiona todas las transacciones de la base de datos. ∗ Ejemplo: arquitectura de los sistemas bancarios ATM (cajeros automáticos), en donde cada Cajero es un cliente y el servidor es un mainframe que procesa la cuenta del cliente en la base de datos. Modelo de Cliente Rico/Gordo/Pesado
  • 27. ∗ El hardware de los cajeros automáticos realiza una gran cantidad de procesamiento relacionado con el cliente y asociado a la transacción. ∗ Los cajeros automáticos no se conectan directamente con la base de datos de clientes sino con un monitor de teleproceso. ∗ Un monitor de teleproceso o gestor de transacciones es un sistema middleware que organiza las comunicaciones con los clientes remotos y serializa las transacciones de los clientes para su procesamiento en la base de datos. ∗ El uso de transacciones serializadas significa que el sistema puede recuperarse de los defectos sin corromper los datos del sistema. Modelo de Cliente Rico/Gordo/Pesado
  • 28. ∗ Aunque el modelo de cliente rico distribuye el procesamiento de forma más efectiva que un modelo de cliente ligero, la gestión del sistema es más compleja. ∗ La funcionalidad de la aplicación se expande entre varias computadoras. ∗ Cuando la aplicación software tiene que ser modificada, esto implica la reinstalación en cada computadora cliente. ∗ Esto puede significar un costo importante si hay cientos de clientes en el sistema. Modelo de Cliente Rico/Gordo/Pesado
  • 29. ∗ Sistema Cliente – Servidor de Cajeros Automáticos (ATM): Modelo de Cliente Rico/Gordo/Pesado
  • 30. ∗ El problema con una aproximación cliente-servidor de dos capas es que las tres capas lógicas —-presentación procesamiento de la aplicación y gestión de los datos — deben asociarse con dos computadoras: el cliente y el servidor. ∗ Aquí puede haber problemas con la escalabilidad y rendimiento si se elige el modelo de cliente ligero, o problemas con la gestión del sistema si se usa el modelo de cliente rico. Modelo Cliente –Servidor de 2 Capas
  • 31. ∗ Para evitar estos problemas, una aproximación alternativa es usar una arquitectura cliente-servidor de tres capas. ∗ Aquí, la presentación, el procesamiento de la aplicación y la gestión de los datos son procesos lógicamente separados que se ejecutan sobre procesadores diferentes. Modelo Cliente –Servidor de 3 Capas
  • 32. ∗ Un sistema bancario por Internet es un ejemplo de una arquitectura cliente-servidor de tres capas. ∗ La base de datos de clientes del banco (usualmente ubicada sobre una computadora mainframe) proporciona servicios de gestión de datos; un servidor web proporciona los servicios de aplicación tales como facilidades para transferir efectivo, generar estados de cuenta, pagar facturas, y así sucesivamente. ∗ La propia computadora del usuario con un navegador de Internet es el cliente. Modelo Cliente –Servidor de 3 Capas
  • 33. ∗ El sistema es escalable, porque es relativamente fácil añadir nuevos servidores web, a medida que el número de clientes crece. ∗ El uso de una arquitectura de tres capas permite optimizar la transferencia de información entre el servidor web y el servidor de la base de datos. ∗ Las comunicaciones entre estos sistemas pueden usar protocolos de comunicación de bajo nivel muy rápidos. ∗ Para recuperar información de la base de datos se utiliza un middleware eficiente que soporte consultas a la base de datos en SQL (Structured Query Language). Modelo Cliente –Servidor de 3 Capas
  • 34. ∗ Figura de Modelo de Arquitectura Cliente – Servidor de 3 Capas (Sistema Bancario en Internet) Modelo Cliente –Servidor de 3 Capas
  • 35. ∗ Cuadro – resumen del uso de diferentes arquitecturas Cliente – Servidor: Modelo Cliente –Servidor
  • 36. ∗ A veces sirve extender el modelo cliente-servidor de tres capas a una variante multicapa en la que se añaden al sistema servidores adicionales. ∗ Los sistemas multicapa pueden usarse cuando las aplicaciones necesitan acceder y usar datos de diferentes bases de datos. ∗ Entonces, un servidor de integración se ubica entre el servidor de aplicaciones y los servidores de la base de datos. ∗ El servidor de integración recoge los datos distribuidos y los presenta a la aplicación como si se obtuviesen desde una única base de datos. Modelo Cliente –Servidor
  • 37. ∗ Las arquitecturas cliente-servidor de tres capas y las variantes multicapa, que distribuyen el procesamiento de la aplicación entre varios servidores, son más escalables que las arquitecturas de dos capas. ∗ El tráfico de la red se reduce, al contrario que con las arquitecturas de dos capas de cliente ligero. ∗ El procesamiento de la aplicación es la parte más volátil del sistema, y puede ser fácilmente actualizada, porque está localizada centralmente. ∗ El procesamiento, en algunos casos, puede distribuirse entre: la lógica de la aplicación y los servidores de gestión de datos, lo que permite una respuesta más rápida a las peticiones de los clientes. Modelo Cliente –Servidor
  • 38. ∗ En el modelo cliente-servidor de un sistema distribuido, los clientes y los servidores son diferentes. ∗ Los clientes reciben servicios de los servidores y no de otros clientes; los servidores pueden actuar como clientes recibiendo servicios de otros servidores, pero sin solicitar servicios de clientes. ∗ Los clientes deben conocer los servicios que ofrece cada uno de los servidores y deben conocer cómo contactar con cada uno de ellos. Arquitecturas de Objetos Distribuidos
  • 39. ∗ El modelo Cliente – Servidor funciona bien para muchos tipos de aplicaciones. ∗ Sin embargo, limita la flexibilidad del diseñador, que debe decidir dónde se proporciona cada servicio. ∗ También debe planificar la escalabilidad y proporcionar algún medio para distribuir la carga sobre los servidores, cuando más clientes se añadan al sistema. Arquitecturas de Objetos Distribuidos
  • 40. ∗ Una opción superadora es eliminar la distinción entre cliente y servidor y diseñar una arquitectura de objetos distribuidos. ∗ Aquí, los componentes del sistema son objetos que proporcionan y requieren un conjunto de servicios. ∗ Otros objetos realizan llamadas a estos servicios sin hacer ninguna distinción lógica entre un cliente (el receptor de un servicio) y un servidor (el proveedor de un servicio). Arquitecturas de Objetos Distribuidos
  • 41. ∗ Los objetos pueden distribuirse a través de varias computadoras en una red y comunicarse a través de middleware. ∗ A este middleware se lo denomina intermediario de peticiones de objetos. ∗ Su misión es proporcionar una interfaz transparente entre los objetos. ∗ Proporciona un conjunto de servicios que permiten la comunicación entre los objetos y que éstos sean añadidos y eliminados del sistema. Arquitecturas de Objetos Distribuidos
  • 42. ∗ Ventajas del modelo de objetos distribuido: 1) Permite al diseñador retrasar decisiones sobre dónde y cómo deberían proporcionarse los servicios. ∗ Los objetos que proporcionan servicios pueden ejecutarse sobre cualquier nodo de la red. ∗ Por lo tanto, la distinción entre los modelos de cliente rico y ligero es irrelevante, ya que no hay necesidad de decidir con antelación dónde ubicamos la lógica de aplicación de los objetos. Arquitecturas de Objetos Distribuidos
  • 43. 2) Es una arquitectura abierta: permite añadir nuevos recursos si es necesario. ∗Se han desarrollado estándares de comunicación de objetos, que permiten escribir objetos, en diferentes lenguajes de programación para comunicarse y proporcionarse servicios entre ellos. 3) El sistema es flexible y escalable. ∗Pueden añadirse nuevos objetos, a medida que la carga del sistema se incrementa, sin afectar al resto de los objetos del sistema. Arquitecturas de Objetos Distribuidos
  • 44. 4) Si es necesario, se puede reconfigurar el sistema, de forma dinámica, mediante la migración de objetos a través de la red. ∗Esto importa cuando haya fluctuación en los patrones de demanda de servicios. ∗Un objeto que proporciona servicios puede migrar al mismo procesador que los objetos que demandan los servicios, lo que mejora el rendimiento del sistema. Arquitecturas de Objetos Distribuidos
  • 45. ∗ Arquitectura de Objetos Distribuidos: Arquitecturas de Objetos Distribuidos
  • 46. ∗ Una arquitectura de objetos distribuidos puede ser usada como un modelo lógico que permita estructurar el sistema. ∗ Entonces, debemos pensar cómo proporcionar las funcionalidades de la aplicación únicamente en términos de servicios y combinaciones de servicios. ∗ Después, debemos identificar cómo proporcionar estos servicios utilizando varios objetos distribuidos. Arquitecturas de Objetos Distribuidos
  • 47. ∗ La principal desventaja de las arquitecturas de objetos distribuidos es que son mucho más complejas de diseñar que los sistemas cliente-servidor. ∗ Los sistemas cliente-servidor parecen ser la forma más natural de concebir a los sistemas. ∗ Estos reflejan muchas transacciones humanas, en las que la gente solicita y recibe servicios de otra gente especializada en proporcionárselos. ∗ Es más difícil pensar en una provisión de servicios generales. Arquitecturas de Objetos Distribuidos
  • 48. ∗ 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 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. Arquitecturas Peer-to-Peer
  • 49. ∗ Los estándares y protocolos que posibilitan las comunicaciones, a través de los nodos, están embebidos en la propia aplicación. ∗ Cada nodo debe ejecutar una copia de dicha aplicación. ∗ Las tecnologías peer-to-peer han sido mayormente usadas para sistemas personales. ∗ Sin embargo, se está utilizando de forma creciente en empresas con potentes redes de PCs. Arquitecturas Peer-to-Peer
  • 50. ∗ Intel y Boeing han implementado sistemas p2p para aplicaciones que requieren computaciones intensivas. ∗ Para aplicaciones cooperativas que soportan trabajo distribuido, es la tecnología más efectiva. ∗ Hay dos tipos principales de arquitecturas lógicas de red que se pueden usar: arquitecturas descentralizadas y arquitecturas semicentralizadas. Arquitecturas Peer-to-Peer
  • 51. ∗ En teoría, en los sistemas peer-to-peer, cada nodo podría conocer cualquier otro nodo, conectarse con él, e intercambiar datos. ∗ En la práctica, 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. ∗ En una arquitectura descentralizada, los nodos en la red no son simplemente elementos funcionales, sino que también son interruptores de comunicaciones que pueden encaminar los datos y señales de control de un nodo a otro. ∗ En la figura siguiente, si n1 debe buscar un archivo que está almacenado en n10, esta búsqueda se encamina a través de los nodos n3, n6 y n9 hasta llegar a n10. Arquitecturas Peer-to-Peer
  • 52. ∗ Arquitectura p2p descentralizada: Arquitecturas Peer-to-Peer
  • 53. ∗ Esta arquitectura descentralizada tiene ventajas: es altamente redundante, y tolerante a defectos y a nodos desconectados de la red. ∗ Sin embargo, existen sobrecargas obvias en el sistema ya que la misma búsqueda puede ser procesada por muchos nodos diferentes y hay una sobrecarga significativa en comunicaciones. ∗ Un modelo de arquitectura p2p alternativo que parte de una arquitectura p2p pura es una arquitectura semicentralizada en la que, dentro de la red, uno o más nodos actúan como servidores para facilitar las comunicaciones entre los nodos. Arquitecturas Peer-to-Peer
  • 54. ∗ Arquitectura p2p SemiCentralizada Arquitecturas Peer-to-Peer
  • 55. ∗ En una arquitectura semicentralizada, el papel del servidor es ayudar a establecer contacto entre iguales en la red o para coordinar los resultados de un cálculo. ∗ Por ejemplo, si la Figura anterior representa un sistema de mensajería instantánea, entonces los nodos de la red se comunican con el servidor (indicado por líneas punteadas), para encontrar qué otros nodos están disponibles. ∗ Una vez que éstos son encontrados, se pueden establecer comunicaciones directas y la conexión con el servidor es innecesaria. ∗ Por lo tanto, los nodos n2, n3, n5 y n6 están en comunicación directa. Arquitecturas Peer-to-Peer
  • 56. ∗ En un sistema p2p, donde un cálculo (que requiere un uso intensivo del procesador) se distribuye a través de un gran número de nodos, es normal que se distingan algunos nodos cuyo papel es distribuir el trabajo a otros nodos y reunir y comprobar los resultados del cálculo. ∗ Si bien hay sobrecargas obvias en los sistemas peer- to-peer, éstos son una aproximación mucho más eficiente para la computación interorganizacional que la aproximación basada en servicios que veremos seguidamente. Arquitecturas Peer-to-Peer
  • 57. ∗ Todavía hay problemas en el uso de las arquitecturas p2p, ya que cuestiones tales como la protección y la autenticidad no están del todo resueltas. ∗ Esto significa que los sistemas p2p se usan más en sistemas de información no críticos. Arquitecturas Peer-to-Peer
  • 58. ∗ Noción de Servicio Web: Por ellos, las organizaciones que quieren hacer accesible su información a otros programas, definen y publican una interfaz de servicio web. ∗ Esta interfaz define los datos disponibles y cómo se puede acceder a ellos. ∗ Un Servicio Web es una representación estándar para cualquier recurso computacional o de información que pueda ser usado por otros programas. ∗ La esencia de un servicio, por lo tanto, es que la provisión de servicio es independiente de la aplicación que utiliza el servicio. Arquitectura de Sistemas orientados a Servicios
  • 59. ∗ Los proveedores de servicios pueden desarrollar servicios especializados y ofertarlos a un cierto número de usuarios de servicios de diferentes organizaciones. ∗ Existen varios modelos de servicios, aunque todos ellos operan de acuerdo al modelo de la Figura siguiente. ∗ Un proveedor de servicio oferta un servicio definiendo su interfaz y definiendo la funcionalidad del servicio. Arquitectura de Sistemas orientados a Servicios
  • 60. ∗ Un solicitante del servicio enlaza este servicio en su aplicación. ∗ Es decir, la aplicación del solicitante incluye un código para llamar al servicio y procesa el resultado de esa llamada al servicio. ∗ Para asegurar que el servicio puede ser accedido por usuarios externos, el proveedor de servicios registra una entrada en el servicio de registro, que incluye información sobre el servicio y lo que hace. Arquitectura de Sistemas orientados a Servicios
  • 61. ∗ Arquitectura Conceptual de un Sistema orientado a Servicios: Arquitectura de Sistemas orientados a Servicios
  • 62. ∗ Diferencias entre el Modelo de Servicios y la aproximación de Objetos Distribuidos: ∗ Los servicios pueden ofertarse por cualquier proveedor de servicio dentro o fuera de una organización. ∗ Las organizaciones pueden crear aplicaciones integrando servicios desde varios proveedores. ∗ Por ejemplo, un compañía industrial puede enlazar directamente a los servicios de sus proveedores. Arquitectura de Sistemas orientados a Servicios
  • 63. ∗ El proveedor de servicios hace pública la información sobre el servicio para que cualquier usuario autorizado pueda usarlo. ∗ El proveedor de servicios y el usuario de los servicios no necesitan negociar sobre lo que el servicio hace. ∗ Las aplicaciones pueden retrasar el enlace de los servicios hasta que éstas sean desplegadas o hasta que estén en ejecución. ∗ Es posible la construcción de nuevos servicios. ∗ Un proveedor de servicios puede reconocer nuevos servicios que se creen. Arquitectura de Sistemas orientados a Servicios
  • 64. ∗ De este modo, los usuarios de los servicios pueden pagar por los servicios con arreglo a su uso en vez de a su provisión. ∗ Por lo tanto, en lugar de comprar un componente de precio elevado que se usa muy raramente, el desarrollador puede usar un servicio externo por el que pagará solamente cuando sea requerido. ∗ Las aplicaciones pueden ser reactivas y adaptar su operación de acuerdo con su entorno, enlazando con diferentes servicios según sea cada caso. Arquitectura de Sistemas orientados a Servicios