Sistemas Distribuidos PDF

14, 15, 16 y 17 Arquitecturas de sistemas
distribuidos y Tarea 04
1
Prof. Edgardo Adrin Franco Martnez
http://computacion.cs.cinvestav.mx/~efranco
efranco.docencia@gmail.com
Estructuras de datos (Prof. Edgardo A. Franco)
Introduccin
Ventajas del uso de una aproximacin distribuida
Desventajas del uso de una aproximacin distribuida
Reto al disear un sistema distribuido
Arquitecturas multiprocesador
Arquitecturas cliente-servidor
Arquitecturas de objetos distribuidos
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Contenido
Contenido
CORBA
Computacin distribuida interorganizacional

Arquitecturas peer-to-peer
Arquitecturas de sistemas orientados a servicios
Tarea 04
Prcticamente todos los grandes sistemas

informticos son en la actualidad sistemas
distribuidos.
Introduccin
Introduccin
Comparticin de recursos
Apertura
Concurrencia
Escalabilidad
Tolerancia a defectos
Ventajas del uso de una

aproximacin distribuida
Comparticin de recursos
Un sistema distribuido permite compartir recursos
hardware y software como discos, impresoras,
archivos, compiladores, etc. que se asocian con
computadoras de una red.

Apertura
Los sistemas distribuidos son normalmente
sistemas abiertos, lo que significa que se disean
sobre protocolos estndar 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
comunicarse con otros durante su funcionamiento
normal.

Escalabilidad
Los sistemas distribuidos debern de ser
escalables en tanto que la capacidad del sistema
puede incrementarse aadiendo nuevos recursos
para cubrir nuevas demandas sobre el sistema.
*Mantener un costo constante y manejable por cada
recurso que se agregue.

Tolerancia a defectos
La disponibilidad de varias computadoras y el
potencial para reproducir informacin significa que los
sistemas distribuidos pueden ser tolerantes a algunos
fallos de funcionamiento del hardware y del software.
La mayora de los sistemas distribuidos pueden
proporcionar servicios an y cuando ocurren fallas de
funcionamiento (puede degradarse el servicio); una
completa perdida de servicio solo ocurre cuando
existe un fallo de funcionamiento en la red.

Para sistemas organizacionales a gran escala,

estas ventajas han remplazado a ampliamente a
las alcanzadas por los sistemas heredados
centralizados de los aos 80's y 90's.
Sin embargo, comparados con los sistemas que se
ejecutan en un solo procesador o cluster de
procesadores, los sistemas distribuidos tienen
desventajas muy marcadas.

10
Complejidad
Seguridad
Manejabilidad
Impredecibilidad
Desventajas del uso de una

11
Complejidad
Los sistemas distribuidos son mucho ms
complejos que los sistemas centralizados. Esto
hace ms difcil de comprender sus propiedades
emergentes y la prueba de estos sistemas.

El rendimiento lo puede dar el nodo o la velocidad

de la red, la ubicacin de los recursos, la distribucin
de los nodos, etc.
12
Seguridad
Puede accederse al sistema desde varias
computadoras diferentes, y el trafico en la red
puede estar sujeto a situaciones indeseadas. Esto
hace ms difcil 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 denegacin de servicio.

13
Manejabilidad
Las computadoras en un sistema pueden ser de
diferentes tipos y pueden ejecutar versiones
diferentes de sistemas operativos. Los defectos en
una maquina pueden propagarse a otras mquinas
con consecuencias inesperadas. Esto significa que
se requiere ms esfuerzo para gestionar y
mantener el funcionamiento del sistema.

14
Impredecibilidad
Los sistemas distribuidos tienen una respuesta
impredecible (E.g. la WWW). La respuesta
depende de la carga total en el sistema, de su
organizacin y de la carga de la red. Como todos
ellos pueden cambiar con mucha rapidez, el
tiempo requerido para responder a una peticin
de usuario puede variar drsticamente de una
peticin a otra.

15
El reto para el diseo de un sistema distribuido es

proporcionar caractersticas deseables a los
sistemas distribuidos y, al mismo tiempo,
minimizar los problemas inherentes a estos
sistemas.
Reto al disear un sistema

distribuido
Para ello es necesario conocer las ventajas y

desventajas de las diferentes arquitecturas de
sistemas distribuidos.
16
El modelo ms simple de un sistema

multiprocesador en el que el sistema software
esta formado por varios proceso que pueden
(aunque no necesariamente) ejecutarse sobre
procesadores diferentes. Este modelo es comn
en sistemas de tiempo real o sistemas distribuidos
masivos.
Los procesos relacionados con la recopilacin de
informacin, toma de decisiones y control de
actuadores podran ejecutarse en un solo
procesador bajo el control de un planificador
(scheduler).
17
El uso de mltiples procesadores mejora el

rendimiento y adaptabilidad del sistema. La
distribucin de procesos entre los procesadores
puede ser predeterminada por un despachador
(dispatcher) que decide que procesos se asignan a
cada procesador.
Sistema multiprocesador de control de trafico
Cmaras y sensores
de flujo de trfico
Procesador
de sensores
Procesador
de flujo de trafico
Procesador de
control de
semforos
Proceso de
control de
sensores
Proceso de
vizualizado
Proceso de
control de
luces
Consolas de
los operadores
18
Semforos
En una arquitectura cliente-servidor, una aplicacin 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 estn
disponibles, pero normalmente no conocen la
existencia de otros clientes. Clientes y servidores son
procesos diferentes.
Varios procesos servidores pueden ejecutarse en un
procesador, por lo que no existe una correspondencia
1:1 entre procesos y procesadores. en el sistema.
19
Un sistema cliente servidor
c1
c1
c1
c1
Proceso
servidor
c12
s1
c11
Proceso
cliente
s4
c6
c10
c7
c9
s2
s3
20
c8
El diseo de sistemas cliente-servidor debera

reflejar la estructura lgica de la aplicacin que se
esta desarrollando.
Por ello generalmente se debe de organizar en
tres capas.
Capa de presentacin
Capa de procesamiento
de la aplicacin
21
Capa de gestin de datos
La capa de presentacin est relacionada con la

presentacin de la informacin al usuario y con
toda la interaccin con l.
La capa de procesamiento de la aplicacin est
relacionada con la implementacin de la lgica de
la aplicacin.
La capa de gestin de datos est relacionada con
todas las operaciones sobre la base de datos.
En los sistemas centralizados, estas capas no es
necesario que estn claramente separadas
22
Sin embargo a la hora del diseo debe hacerse

una distincin entre ellas, de forma que sea
posible distribuir cada capa sobre una
computadora diferente.
La arquitectura cliente servidor ms simple se
denomina arquitectura cliente-servidor de dos
capas, en la que una aplicacin se organiza como
un servidor (o mltiples servidores) y un conjunto
de clientes.
23
Arquitecturas cliente-servidor de dos capas:

1. Modelo de cliente ligero (thin-client): En un modelo
de cliente ligero, todo el procesamiento de las
aplicaciones y la gestin de los datos se lleva a cabo
en el servidor. El cliente simplemente es
responsable de la capa de presentacin del
software.
2. Modelo de cliente rico o pesado (fat-client): En este
modelo, el servidor solamente es responsable de la
gestin de los datos. El software del cliente
implementa la lgica de la aplicacin y las
interacciones con el usuario del sistema.
24
Presentacin
Modelo de
cliente ligero
Modelo de
cliente pesado
Cliente
Cliente
Presentacin
Procesamiento de la
aplicacin
Servidor
Gestin de datos
Procesamiento de
la aplicacin
Servidor
Gestin de datos
25
Una arquitectura de dos capas con clientes

ligeros, es la aproximacin ms simple en los
sistemas centralizados.
Una 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 clculos, adems de que
se debera de aprovechar que los dispositivos de
computacin modernos disponen de una gran
cantidad de potencia de procesamiento.
26
El modelo cliente-servidor de dos capas de cliente

pesado, hace uso de esa potencia de
procesamiento disponible y distribuye tanto el
procesamiento de la lgica de la aplicacin como
la presentacin al cliente.
El servidor es esencialmente un servidor de
transacciones que gestiona todas las transacciones
con la base de datos.
Un ejemplo de este tipo de arquitectura es la de
los sistemas bancarios ATM.
27
Un sistema ATM cliente-servidor

ATM
Servidor de cuentas
Monitor de
teleprocesa
miento
ATM
Base de
datos de
cuentas de
clientes
ATM
28
ATM
Aunque el modelo de pesado distribuye el procesamiento

de forma ms efectiva que un modelo de cliente ligero, la
gestin del sistema es ms compleja.
Cuando la aplicacin software tiene que ser modificada, se
debe de realizar la reinstalacin en cada computadora
cliente. (Alto costo si hay cientos de clientes en el sistema)
La aparicin de cdigo mvil (applets de Java y los
controles Active X), ha permitido el desarrollo de sistemas
cliente-servidor que son algo intermedio entre los modelos
de cliente ligero y pesado. Parte del procesamiento se
realiza del lado servidor y parte del lado cliente. La interfaz
de usuario se crea usando un navegador web que permite
ejecutar el cdigo descargado.
29
Aunque el modelo de pesado distribuye el

procesamiento de forma ms efectiva que un modelo
de cliente ligero, la gestin del sistema es ms
compleja.
Cuando la aplicacin software tiene que ser
modificada, se debe de realizar la reinstalacin en
cada computadora cliente. (Alto costo si hay cientos
de clientes en el sistema)
La aparicin de cdigo mvil (applets de Java y los
controles Active X), ha permitido el desarrollo de
sistemas cliente-servidor que son algo intermedio
entre los modelos de cliente ligero y pesado.
30
El problema con una aproximacin cliente-servidor de

dos capas es que las tres capas lgicas (presentacin,
procesamiento de la aplicacin y gestin de los datos)
debe de asociarse con el cliente y el servidor, por lo
que esto puede acarrear problemas de escalabilidad y
rendimiento (cliente ligero) o problemas de gestin
(cliente pesado).
Para evitar estos problemas, una aproximacin
alternativa es usar una arquitectura cliente-servidor de
tres capas. En esta arquitectura, la presentacin, el
procesamiento de la aplicacin y la gestin de los
datos son procesos lgicamente separados que se
ejecutan sobre procesos diferentes.
31
Arquitectura cliente-servidor de tres capas

Presentacin
Cliente
Servidor
Servidor
Procesamiento
de la aplicacin
Gestin de los
datos
32
Un ejemplo de una arquitectura de tres capas es un

sistema bancario por internet.
La base de datos de clientes (usualmente ubicada
sobre un mainframe) proporciona servicios de gestin
de datos; un servidor web proporciona los servicios de
aplicacin tales como facilidades para transferir
efectivo, generar estados de cuenta, pagar facturas,
etc.; la propia computadora del usuario con un
navegador de internet es el cliente.
El sistema es escalable debido a que es mas sencillo
agregar servidores web a la medida que crece el
sistema.
33
La arquitectura de distribucin de
un sistema bancario en Internet
Interaccin HTTP
Cliente
Cliente
Cliente
Servidor Web
Provisin del
servicio de
cuentas
SQL query
Servidor de bases
de datos
SQL
Base de datos
de cuentas de
clientes
34
Arquitectur
a
Aplicaciones
Arquitectura
C/S de dos
capas con
clientes
ligeros
Aplicaciones de sistemas heredados en donde no es prctico separar el

procesamiento de la aplicacin y la gestin de los datos.
Aplicaciones que requieren clculos intensivos tales como
compiladores con poca o ninguna gestin de datos.
Aplicaciones que requieran manejar una gran cantidad de datos

(navegar y consultar) con poco o ningn procesamiento de la
aplicacin.
Arquitectura
C/S de dos
capas con
clientes
pesados
Aplicaciones en donde el procesamiento de la aplicacin se

proporciona por software comercial (E.g. Ofimatica) sobre el cliente.
Aplicaciones que requieren un procesamiento de datos
computacionalmente intensivo (E.g. Visualizacin de datos).
Aplicaciones con una funcionalidad para el usuario final relativamente
estable usada en un entorno de gestin del sistema bien establecido.
35
Arquitectura
Aplicaciones
Arquitectura C/S Aplicaciones a gran escala con cientos o miles de clientes

de tres capas o Aplicaciones en donde tanto los datos como la aplicacin son
multicapa
voltiles
Aplicaciones en donde se integran datos de mltiples fuentes.
36
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 cmo
contactar cada uno de estos servidores.
Este modelo funciona bien para muchos tipos de
aplicaciones. Sin embargo, limita la flexibilidad de los
diseadores del sistema ya que ellos deben decidir dnde
se proporciona cada servicio. Tambin deben planificar la
escalabilidad y proporcionar algn medio para distribuir la
carga sobre los servidores cuando ms clientes se aadan
al sistema.
37
Una aproximacin ms general al diseo de sistemas

distribuidos es eliminar la distincin entre cliente y
servidor y disear la arquitectura del sistema como
una arquitectura de objetos distribuidos.
En una arquitectura de objetos distribuidos, los
componentes fundamentales del sistema son objetos
que proporcionan un interfaz a un conjunto de
servicios que ellos suministran. Otros objetos realizan
llamadas a estos servicios sin hacer una distincin
lgica entre un cliente (receptor del servicio) y un
servidor (proveedor del servicio).
Arquitecturas de objetos
distribuidos
38
o1
o2
o3
o4
S(o1)
S(o2)
S(o3)
S(o4)
Bus software
o5
o6
S(o5)
S(o6)
distribuidos
39
En una arquitectura de objetos distribuidos, los

objetos se distribuyen a travs de varias
computadoras en una red y comunicarse a travs
de middleware. Este middleware proporciona un
conjunto de servicios que permiten la
comunicacin entre objetos y el que estos puedan
ser aadidos o eliminados del sistema.
distribuidos
40
Ventajas del modelo de objetos distribuidos

Los objetos que proporcionan servicios pueden
ejecutarse sobre cualquier nodo de la red. No ser
necesario decidir con antelacin donde ser situ la
lgica de la aplicacin.
Es una arquitectura muy abierta que permite aadir
nuevos recursos fcilmente. (Implementacin de
estndares de comunicacin entre objetos que permite
escribir objetos en lenguajes de programacin distintos).
Mayor flexibilidad y escalabilidad debido a que se
pueden crear diferentes instancias del sistema
proporcionando los mismo servicios por objetos
diferentes. (segn la carga del sistema)
Es posible reconfigurar el sistema de forma dinmica
mediante la migracin de objetos a travs de la red.
distribuidos
41
En computacin, CORBA (Common Object Request

Broker Architecture), arquitectura comn de
intermediarios en peticiones a objetos, es un estndar
que establece una plataforma de desarrollo de
sistemas distribuidos facilitando la invocacin de
mtodos remotos bajo un paradigma orientado a
objetos.
CORBA fue definido y est controlado por el Object
Management Group (OMG) que define las APIs, el
protocolo de comunicaciones y los mecanismos
necesarios para permitir la interoperabilidad entre
diferentes aplicaciones escritas en diferentes
lenguajes y ejecutadas en diferentes plataformas.
distribuidos
42
En un sentido general, CORBA "envuelve" el cdigo escrito

en otro lenguaje, en un paquete que contiene informacin
adicional sobre las capacidades del cdigo que contiene y
sobre cmo llamar a sus mtodos. Los objetos que
resultan, pueden entonces ser invocados desde otro
programa (u objeto CORBA) desde la red.
CORBA utiliza un lenguaje de definicin de interfaces (IDL)
para especificar las interfaces con los servicios que los
objetos ofrecern. CORBA puede especificar a partir de
este IDL, la interfaz a un lenguaje determinado,
describiendo cmo los tipos de dato CORBA deben ser
utilizados en las implementaciones del cliente y del
servidor. Implementaciones estndar existen para Ada, C,
C++, Smalltalk, Java, Python, Perl y Tcl.
distribuidos
43
Al compilar una interfaz en IDL se genera cdigo para

el cliente y el servidor (el implementador del objeto).
El cdigo del cliente sirve para poder realizar las
llamadas a mtodos remoto. Es el conocido como
stub, el cual incluye un representante del objeto
remoto en el lado del cliente. El cdigo generado para
el servidor consiste en unos skeletons que el
desarrollador tiene que rellenar para implementar los
mtodos del objeto.
CORBA
es
ms
que
una
especificacin
multiplataforma,
ya
que
define
servicios
habitualmente necesarios como seguridad y
transacciones (middleware).
distribuidos
44
Los estndares CORBA incluyen:

1. Un modelo de objetos para objetos de aplicacin en
donde un objeto CORBA es una encapsulacin de un
estado con una interfaz con un lenguaje neutral y
bien definido descrito en IDL (Interfaz Definition
Language)
2. Un intermediario de peticiones de objetos (ORB)
que gestiona peticiones para servicios de objetos.
Este ORB localiza al objeto que proporciona el
servicio, lo prepara para la peticin, enva la
peticin de servicio y devuelve el resultado
solicitante del servicio.
distribuidos
45
3. Un conjunto de servicios de objetos que son

servicios generales que probablemente sern
requeridos
por
muchas
aplicaciones
distribuidas. Ejemplo de servicios son servicios
de directorio, servicios de transacciones y
servicios de persistencia.
4. Un conjunto de componentes construidos sobre
estos servidores bsicos que pueden ser
requeridos por las aplicaciones. Pueden ser
componentes verticales especficos del dominio
o componentes horizontales de propsito
general usados por muchas aplicaciones.
distribuidos
46
o1
o2
S(o1)
S(o2)
Stub
IDL
Skeleton
IDL
Intermediario de peticiones de
objetos
Dos objetos o1 y o2 se comunican a travs

de un ORB. El objeto que hace la llamada
(o1) tiene un stub IDL asociado que define la
interfaz del objeto que proporciona el
servicio solicitado. El implementador de o1
incluye la llamada a este stub en su
implementacin del objeto cuando se
solicita un servicio.
El objeto que proporciona el servicio tiene
un skeleton IDL asociado que enlaza la
interfaz con la implementacin de los
servicios. En trminos simples cuando un
servicio se llama a travs de la interfaz, el
skeleton IDL traduce los resultados a IDL
para que puedan ser accedidos por el objeto
que realizo la llamada.
distribuidos
47
Los intermediarios de peticiones de objetos no se

implementan normalmente como procesos
separados, pero son un conjunto de libreras que
pueden enlazarse con las implementaciones de los
objetos. Por lo tanto, en un sistema distribuido,
cada computadora que est ejecutando objetos
distribuidos tendr su propio intermediario de
peticiones de objetos. ste manejar todas las
invocaciones locales de objetos.
distribuidos
48
o1
o2
o3
o4
S(o1)
S(o2)
S(o3)
S(o4)
Stub
IDL
Skeleton
IDL
Stub
IDL
Skeleton
IDL
objetos
distribuidos
objetos
49
Red
Los servicios de CORBA proveen facilidades

requeridas por sistemas distribuidos. El estandar
incluye diversos servicios (aprox. 15 comunes) y
infinidad de servicios especficos. Algunos
ejemplos de estos servicios son:
distribuidos
Servicio de nombres y categoras (trading): Permite

a los objetos hacer referencia y encontrar a los otros
objetos de la red. "Directorios de objetos".
50
Servicios de notificacin: Permiten a los objetos

notificar a otros objetos que ha ocurrido algn
evento. "Los objetos registran el inters en un
evento especifico del servicio".
Servicio de transacciones: Soporta transacciones
atmicas y operaciones rollback cuando ocurre un
fallo.
distribuidos
51
La computacin distribuida ha sido principalmente

implementada
a
nivel
organizacional.
Una
organizacin tiene varios servidores y distribuye la
carga entre ellos.
Actualmente estn disponibles modelos ms recientes
de
computacin
distribuida
que
permiten
computacin distribuida interorganizacional en lugar
de intraorganizacional.
Computacin distribuida
interorganizacional
Arquitecturas peer-to-peer
Arquitecturas de sistemas orientados a servicios
Servicios Web
SOA
52
Peer-to-Peer
Los sistemas peer-to-peer (P2P) son sistemas
descentralizados en los que los clculos 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 disea para aprovechar la ventaja de la potencia
computacional y disponibilidad de almacenamiento a
travs de una red de computadoras enormes.
Los estndares y protocolos que posibilitan las
comunicaciones a travs de los nodos estn embebidos en
la propia aplicacin, y cada nodo debe ejecutar una copia
de dicha aplicacin.
interorganizacional
53
Arquitectura P2P
n4
n2
n1
n7
n5
n9
n8
n6
n3
n12
interorganizacional
n10
n11
54
P2P (Entre iguales)

No tiene clientes y servidores fijos, sino una serie de nodos
que se comportan a la vez como clientes y como servidores
de los dems nodos de la red.
Todos los nodos se comportan igual y pueden realizar el
mismo tipo de operaciones.
A pesar de que el P2P ha sido popularizado por el
intercambio de msica por Internet, este no es el nico uso
que se puede dar a esta tecnologa.
interorganizacional
Skype
SETI (Search for Extraterrestrial Intelligence Institute).
RTVE emisin en directo a travs de P2P
55
Elementos de una red P2P

Par: entidad capaz de desarrollar algn trabajo til y de comunicar los
resultados de ese trabajo a otra entidad de la red, ya sea directa o
indirectamente .
Par simple: Sirven a un nico usuario final, permitindolo proporcionar
servicios desde su dispositivo y empleando los servicios ofrecidos por otros
pares de la red
Sper-par: Ayudan a los pares simples a que encuentre otros pares o a
otros recursos de los pares
Grupo de Pares: Un grupo de pares es un conjunto de pares formado para
servir a un inters comn u objetivo dictado por el resto de pares
implicados.
Servicios: proporcionan una funcionalidad til que se consigue mediante la
comunicacin de los distintos pares
Servicios de pares: Funcionalidades ofrecidas por un par concreto de la red
a otros pares
Servicios de Grupo de pares: funcionalidades proporcionadas por varios
miembros del grupo consiguiendo as acceso redundante al servicio.
interorganizacional
56
Rendimiento Elevado
Coste Alto
P2P (Centralizado)
1- cc.mp3?
Par B (bb.mp3)
2- Par C
Par C (cc.mp3)
Servidor
Bbb.mp3
Ccc.mp3
Ddd.mp3
3- cc.mp3
Par A (cc.mp3?)
interorganizacional
Conexin directa
Flujo de Datos
Par D (dd.mp3)
57
P2P (Puro o totalmente descentralizado) "E.g. Gnutella"

ccc.mp3?
Par F
ccc.mp3?
ccc.mp3
Par C ccc.mp3
Par E
ccc.mp3
Par B
ccc.mp3?
Par A ccc.mp3?
interorganizacional
ccc.mp3?
ccc.mp3
Par D
Conexin directa
Flujo de Datos
El modelo P2P puro es ms robusto al no depender de un servidor central

Econmico
Elevado tiempo y sobrecarga de ancho de banda.
El recurso buscado y existente ni siquiera pueda ser encontrado
58
P2P (Mixto o semicentralizado)
Par A (cc.mp3?)
(cc.mp3?)
(cc.mp3?)
Superpar
Z cc.mp3
Par Z (cc.mp3)
cc.mp3->Z
cc.mp3->Z
interorganizacional
Conexin directa
Flujo de Datos
Red Escalable
Reduccin del nmero de nodos involucrados en el encaminamiento
Buen tiempo de respuesta
59
La bsqueda de informacin (pares, contenidos y

servicios), dada la ausencia de un conocimiento global de
los datos y recursos involucrados, es un aspecto
fundamental en entornos P2P
Bsqueda en cach: Cada par mantiene una cach de recursos
previamente descubiertos.
Bsqueda directa: Pregunta directamente a otros pares de la red
con los que tenga conexin directa (Arquitectura P2P pura)
Bsqueda indirecta: Los superpares actan como fuente de
informacin de localizacin de pares y otros recursos conocidos.
Adems esos hacen la bsqueda en nombre del par (Arquitectura
P2P mixta).
interorganizacional
60
Caractersticas de las arquitecturas P2P
Descentralizacin
Escalabilidad
Anonimato
Propiedad compartida
Rendimiento
Seguridad
Tolerancia a Fallos
Interoperabilidad
interorganizacional
61
JXTA (Juxtapose) es una plataforma peer-to-peer open source

creada por Sun Microsystems en el ao 2001. Esta plataforma
esta definida como un conjunto de protocolos basados en XML.
Dichos protocolos permiten que dispositivos conectados a una
red intercambien mensajes entre s. JXTA es el framework P2P
ms maduro que actualmente existe. Adems, fue diseado
para permitir que un amplio rango de dispositivos
(computadoras, telfonos mviles, PDAs) se comuniquen de
forma descentralizada.
Como JXTA est basado en una serie de protocolos abiertos, en
teora, puede ser portado a cualquier lenguaje moderno de
computacin. Actualmente, la implementacin de JXTA de Java
es la ms avanzada. Existen versiones para C y C++, JXTA-C y
JXTA-C++ respectivamente.
interorganizacional
62
JXTA crea una red virtual que permite a los peers interactuar entre s,
aun cuando algunos de ellos estn detrs de firewalls, NATs o usen
distintos transportes de red. Adems, cada peer es identificado por un
ID nico, un URN SHA-1 de 160 bits en la implementacin de Java,
permitiendo que los peers puedan cambiar su direccin pero
conservar su nmero de identificacin.
Los servicios JXTA pueden ser implementados para interoperar con
otros servicios. Por ejemplo, un servicio de comunicacin P2P de
mensajera instantnea puede ser fcilmente agregado a una
aplicacin P2P de comparticin de ficheros si es que ambos soportan
protocolos JXTA.
La forma de funcionamiento se basa en un conjunto de protocolos P2P
simples y abiertos que permiten que cualquier dispositivo de red se
comunique, colabore y comparta recursos.
interorganizacional
63
Arquitecturas de sistemas orientado a servicios

El desarrollo de la WWW trajo consigo que las
computadoras cliente tuviesen acceso a los
servidores remotos situados fuera de sus propias
organizaciones.
Es claro que si las organizaciones convierten su
informacin a HTML, entonces sta podr ser
accedida por estas computadoras. Sin embargo el
acceso solo a travs de un navegador web no es
prctico.
interorganizacional
64
Servicio web
Un servicio Web (Web service) es una coleccin de protocolos y
estndares que sirven para intercambiar datos entre
aplicaciones.
Mediante la nocin de un servicio web, las organizaciones que
requieren hacer accesible la informacin a otros programas,
pueden hacerlo definiendo y publicando un interfaz de servicio
web. Esta interfaz define los datos disponibles y como se puede
acceder a ellos i.e. un servicio web es una representacin
estndar para cualquier recurso computacional o de informacin
que pueda ser usado por otros programas.
La principal razn para usar servicios Web es que se basan en HTTP
sobre TCP en el puerto 80.
Buena interfaz para acceder a servicios y funcionalidades de otros
ordenadores en la red.
Gran independencia y flexibilidad entre aplicacin y servicio.
interorganizacional
65
Arquitectura conceptual de un sistema orientado

a servicios
Registro de
servicios
Buscar
Solicitante
de servicios
Publicar
Enlazar
Suministrador
de servicios
interorganizacional
Servicio
66
XML: Es el formato estndar para los datos que se

vayan a intercambiar.
SOAP o XML-RPC: Protocolos sobre los que se
establece el intercambio.
HTTP, FTP, o SMTP: los datos en XML tambin pueden
enviarse de una aplicacin a otra mediante protocolos
normales ya bien conocidos.
WSDL: Es el lenguaje de la interfaz pblica para los
servicios Web.
UDDI: Protocolo para publicar la informacin de los
servicios Web.
WS-Security: Protocolo de seguridad.
interorganizacional
67
Diferencias entre la orientacin a servicios y la

aproximacin de objetos distribuidos
Los servicios podrn ofertarse por cualquier
proveedor de servicio (con base en estndares)
dentro o fuera de una organizacin, las
organizaciones
pueden
crear
aplicaciones
integrando servicios desde varios proveedores.
interorganizacional
E.g.
Una compaa de fabricacin puede enlazar directamente a
los servicios proporcionado por sus proveedores.
Una compaa de logstica puede enlazarse con servicios de
geolocalizacin y comunicacines.
Sistemas de banca electrnica
68
El proveedor del servicio hace pblica la

informacin 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 antes de ser
incorporado en un programa de aplicacin.
Las aplicaciones pueden retrasar el enlace de los
servicios hasta que stas sean desplegadas o hasta
que estn en ejecucin.
i.e. una aplicacin podra cambiar dinmicamente los
proveedores de los servicios mientras el servicio se
este ejecutando.
interorganizacional
69
El es posible la construccin oportunista de nuevos

servicios. Un proveedor de servicios puede
reconocer nuevos servicios que se crean enlazando
servicios existentes de formas innovadoras.
Los usuarios de los servicios pueden pagar por los
servicios con arreglo a su uso en vez de a su
provisin. Por lo que en lugar de comprar un
componente de precio elevado que se usa
raramente, el desarrollador de la aplicacin puede
usar un servicio externo por el que pagar
solamente cuando sea requerido.
interorganizacional
70
Las aplicaciones pueden hacerse mas pequeas

debido a que pueden implementar el manejo de
excepciones como servicios externos.
Las aplicaciones pueden ser reactivas y adaptar su
operacin de acuerdo con su entorno enlazando con
diferentes servicios a medida que cambia este.
interorganizacional
71
Los tres estndares fundamentales que permiten la

comunicacin entre servicios web son:
SOAP (Simple Object Access Protocol). Este protocolo
define una organizacin para intercambio de datos
estructurados entre servicios web.
WSDL (Web Services Description Languaje). Este
protocolo define cmo pueden representarse las
interfaces de los servicios web.
UDDI (Universal Descripcin, Discovery and Integratin).
ste es un estndar de bsqueda que define como
puede organizarse la informacin de descripcin de
servicios, usada por los solicitantes de los servicios para
encontrar servicios.
interorganizacional
72
*Todos los estndares se basan en XML generalmente.
Las arquitecturas de aplicaciones de servicios web

son arquitecturas dbilmente acopladas en donde
el enlace a los servicios puede cambiar durante la
ejecucin. Algunos sistemas se construirn
solamente usando servicios web y otras mezclaran
servicios web desarrollados localmente.
interorganizacional
73
Ventajas de los servicios web

Aportan interoperabilidad entre aplicaciones de
software
Los servicios Web fomentan los estndares y protocolos
basados en texto (ms humanos y accesibles)
Al apoyarse en HTTP, permiten acceder a cualquier
sistema conectado a la red (http usa el puerto 80)
Permiten el uso de servicios integrados cambiando el de
varias compaas y varios software's
Permiten la interoperabilidad entre plataformas de
distintos fabricantes por medio de protocolos estndar.
interorganizacional
74
Desventajas de los servicios web

Para realizar transacciones no pueden compararse en su
grado de desarrollo con los estndares abiertos de
computacin distribuida como CORBA.
Su rendimiento es bajo si se compara con otros modelos
de computacin distribuida, tales como RMI o CORBA
(XML no est diseado para el rendimiento)
Al apoyarse en HTTP, pueden esquivar medidas de
seguridad basadas en firewalls cuyas reglas tratan de
bloquear o auditar la comunicacin entre programas a
ambos lados de la barrera.
Existe poca informacin de servicios web para algunos
lenguajes de programacin
interorganizacional
75
Arquitectura Orientada a Servicios (SOA)

Evolucin de la arquitectura:
Abstraccin
interorganizacional
76
interorganizacional
77
Programacin
Estructurada
Objetos
Componentes
Servicios
Granularidad
Muy fina
Fina
Intermedia
Gruesa
Contrato
Definido
Privado/Publico
Publico
Publicado
Reusabilidad
Baja
Baja
Intermedia
Alta
Acoplamiento
Fuerte
Fuerte
Dbil
Muy dbil
Dependencias
Tiempo de
Compilacin
Tiempo de
Compilacin
Tiempo de
Compilacin
Run-Time
interorganizacional
78
mbito de
Comunicacin
Intra-Aplicacin
IntraAplicacin
InterAplicaciones
Inter-Empresas
interorganizacional
79
Realizar un mapa conceptual que contenga los

conceptos de la clase 11 a 17
A ms tardar se debe entregar el da Domingo 17 de
Octubre de 2010 a las 23:59:59 hrs.
Incluir portada.
Recomendacin: Usar Cmap Tools
Tarea 04
Tarea 04
80

Sistemas Distribuidos PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Sistemas Distribuidos PDF

Cargado por

Copyright:

Formatos disponibles

14, 15, 16 y 17 Arquitecturas de sistemas

Computacin distribuida interorganizacional

Prcticamente todos los grandes sistemas

Ventajas del uso de una

Ventajas del uso de una

Ventajas del uso de una

Ventajas del uso de una

Ventajas del uso de una

Ventajas del uso de una

Para sistemas organizacionales a gran escala,

Ventajas del uso de una

Desventajas del uso de una

Desventajas del uso de una

El rendimiento lo puede dar el nodo o la velocidad

Desventajas del uso de una

Desventajas del uso de una

Desventajas del uso de una

El reto para el diseo de un sistema distribuido es

Reto al disear un sistema

Para ello es necesario conocer las ventajas y

El modelo ms simple de un sistema

El uso de mltiples procesadores mejora el

En una arquitectura cliente-servidor, una aplicacin se

Un sistema cliente servidor

El diseo de sistemas cliente-servidor debera

La capa de presentacin est relacionada con la

Sin embargo a la hora del diseo debe hacerse

Arquitecturas cliente-servidor de dos capas:

Una arquitectura de dos capas con clientes

El modelo cliente-servidor de dos capas de cliente

Un sistema ATM cliente-servidor

Aunque el modelo de pesado distribuye el procesamiento

Aunque el modelo de pesado distribuye el

El problema con una aproximacin cliente-servidor de

Arquitectura cliente-servidor de tres capas

Un ejemplo de una arquitectura de tres capas es un

Aplicaciones de sistemas heredados en donde no es prctico separar el

Aplicaciones que requieran manejar una gran cantidad de datos

Aplicaciones en donde el procesamiento de la aplicacin se

Arquitectura C/S Aplicaciones a gran escala con cientos o miles de clientes

En el modelo cliente-servidor de un sistema distribuido, los

Una aproximacin ms general al diseo de sistemas

En una arquitectura de objetos distribuidos, los

Ventajas del modelo de objetos distribuidos

En computacin, CORBA (Common Object Request

En un sentido general, CORBA "envuelve" el cdigo escrito

Al compilar una interfaz en IDL se genera cdigo para

Los estndares CORBA incluyen:

3. Un conjunto de servicios de objetos que son

Dos objetos o1 y o2 se comunican a travs

Los intermediarios de peticiones de objetos no se

Los servicios de CORBA proveen facilidades

Servicio de nombres y categoras (trading): Permite

Servicios de notificacin: Permiten a los objetos

La computacin distribuida ha sido principalmente

P2P (Entre iguales)

Elementos de una red P2P

P2P (Puro o totalmente descentralizado) "E.g. Gnutella"

El modelo P2P puro es ms robusto al no depender de un servidor central

P2P (Mixto o semicentralizado)

La bsqueda de informacin (pares, contenidos y

Caractersticas de las arquitecturas P2P

JXTA (Juxtapose) es una plataforma peer-to-peer open source