14 15 16 17 Arquitecturas de Sistemas Distribuidos y Tarea 04

14, 15, 16 y 17 Arquitecturas de sistemas
distribuidos y Tarea 04
1
Prof. Edgardo Adrián Franco Martínez
http://computacion.cs.cinvestav.mx/~efranco
efranco.docencia@gmail.com Estructuras de datos (Prof. Edgardo A. Franco)
Contenido
Sistemas operativos II
Contenido
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
• Introducción
• Ventajas del uso de una aproximación distribuida
• Desventajas del uso de una aproximación distribuida
• Reto al diseñar un sistema distribuido
• Arquitecturas multiprocesador
• Arquitecturas cliente-servidor
• Arquitecturas de objetos distribuidos
• CORBA
• Computación distribuida interorganizacional
• Arquitecturas peer-to-peer
• Arquitecturas de sistemas orientados a servicios 2
• Tarea 04
Introducción
Introducción
• Prácticamente todos los grandes sistemas
informáticos son en la actualidad sistemas
distribuidos.
3
Ventajas del uso de una
Ventajas del uso de una aproximación distribuida

aproximación distribuida
• Compartición de recursos
• Apertura
• Concurrencia
• Escalabilidad
• Tolerancia a defectos
4

• Compartición 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.
5

• Apertura
• Los sistemas distribuidos son normalmente
sistemas abiertos, lo que significa que se diseñan
sobre protocolos estándar que permiten combinar
equipamiento y software de diferentes
vendedores.
6

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

• Escalabilidad
• Los sistemas distribuidos deberán de ser
escalables en tanto que la capacidad del sistema
puede incrementarse añadiendo nuevos recursos
para cubrir nuevas demandas sobre el sistema.
• *Mantener un costo constante y manejable por cada
recurso que se agregue.
8

• Tolerancia a defectos
• La disponibilidad de varias computadoras y el
potencial para reproducir información significa que los
sistemas distribuidos pueden ser tolerantes a algunos
fallos de funcionamiento del hardware y del software.
• La mayoría de los sistemas distribuidos pueden
proporcionar servicios aún 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.
9

• Para sistemas organizacionales a gran escala,
estas ventajas han remplazado a ampliamente a
las alcanzadas por los sistemas heredados
centralizados de los años 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
• Seguridad
• Complejidad
• Manejabilidad
• Impredecibilidad
Desventajas del uso de una
11

Desventajas del uso de una aproximación distribuida

• Complejidad
• Los sistemas distribuidos son mucho más
complejos que los sistemas centralizados. Esto
hace más difícil 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 ubicación de los recursos, la distribución
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 más difícil el asegurar que la integridad de
los datos en el sistema se mantenga y que los
servicios del sistema no se degraden por ataques
de denegación de servicio.
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 máquinas
con consecuencias inesperadas. Esto significa que
se requiere más 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
organización y de la carga de la red. Como todos
ellos pueden cambiar con mucha rapidez, el
tiempo requerido para responder a una petición
de usuario puede variar drásticamente de una
petición a otra.
15
Reto al diseñar un sistema
Reto al diseñar un sistema distribuido

distribuido
• El reto para el diseño de un sistema distribuido es
proporcionar características deseables a los
sistemas distribuidos y, al mismo tiempo,
minimizar los problemas inherentes a estos
sistemas.
• Para ello es necesario conocer las ventajas y

desventajas de las diferentes arquitecturas de
sistemas distribuidos.
16
Arquitecturas multiprocesador

• El modelo más 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 común
en sistemas de tiempo real o sistemas distribuidos
masivos.
• Los procesos relacionados con la recopilación de
información, toma de decisiones y control de
actuadores podrían ejecutarse en un solo
procesador bajo el control de un planificador 17
(scheduler).
Arquitecturas multiprocesador

• El uso de múltiples procesadores mejora el
rendimiento y adaptabilidad del sistema. La
distribución 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
Procesador de
Procesador Procesador control de
de sensores de flujo de trafico semáforos
Proceso de Proceso de
Proceso de
control de control de
vizualizado
sensores luces 18
Cámaras y sensores Consolas de

de flujo de tráfico los operadores Semáforos
Arquitecturas cliente-servidor
• 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 en un
procesador, por lo que no existe una correspondencia
19
1:1 entre procesos y procesadores. en el sistema.
Un sistema cliente –servidor
c1 c1
Proceso
c1 c12 servidor
c1 s1 c11
s4 Proceso
cliente
c6
c10
c9
c7 s2
s3 20
c8
• El diseño de sistemas cliente-servidor debería
reflejar la estructura lógica de la aplicación que se
esta desarrollando.
• Por ello generalmente se debe de organizar en
tres capas.
Capa de presentación
Capa de procesamiento
de la aplicación
21
Capa de gestión de datos

• 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.
• 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, estas capas no es
22
necesario que estén claramente separadas
• Sin embargo a la hora del diseño debe hacerse
una distinción entre ellas, de forma que sea
posible distribuir cada capa sobre una
computadora diferente.
• La arquitectura cliente servidor más simple se
denomina arquitectura cliente-servidor de dos
capas, en la que una aplicación se organiza como
un servidor (o múltiples servidores) 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 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.
2. Modelo de cliente rico o pesado (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. 24
Presentación Servidor
Gestión de datos
Modelo de Cliente Procesamiento de
cliente ligero la aplicación
Presentación
Procesamiento de la Servidor
Modelo de aplicación
Cliente Gestión de datos
cliente pesado
25
• Una arquitectura de dos capas con clientes
ligeros, es la aproximación más 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 cálculos, además de que
se debería de aprovechar que los dispositivos de
computación 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 lógica de la aplicación como
la presentación 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
Base de
Monitor de
ATM datos de
teleprocesa
cuentas de
miento
clientes
ATM
28
ATM
• Aunque el modelo de pesado distribuye el procesamiento
de forma más efectiva que un modelo de cliente ligero, la
gestión del sistema es más compleja.
• Cuando la aplicación software tiene que ser modificada, se
debe de realizar la reinstalación en cada computadora
cliente. (Alto costo si hay cientos de clientes en el sistema)
• La aparición de código móvil (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 código descargado. 29
• Aunque el modelo de pesado distribuye el
procesamiento de forma más efectiva que un modelo
de cliente ligero, la gestión del sistema es más
compleja.
• Cuando la aplicación software tiene que ser
modificada, se debe de realizar la reinstalación en
cada computadora cliente. (Alto costo si hay cientos
de clientes en el sistema)
• La aparición de código móvil (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 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)
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 gestión
(cliente pesado).
• Para evitar estos problemas, una aproximación
alternativa es usar una arquitectura cliente-servidor de
tres capas. En esta arquitectura, 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 procesos diferentes. 31
Arquitectura cliente-servidor de tres capas
Presentación
Servidor Servidor
Procesamiento Gestión de los
Cliente
de la aplicación 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 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,
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 distribución de
un sistema bancario en Internet
Interacción HTTP
Cliente
Servidor de bases
Servidor Web de datos
Provisión del SQL query Base de datos
Cliente servicio de SQL de cuentas de
clientes
cuentas
Cliente 34
Arquitectur Aplicaciones
a
Arquitectura Aplicaciones de sistemas heredados en donde no es práctico separar el
C/S de dos procesamiento de la aplicación y la gestión de los datos.
capas con
clientes Aplicaciones que requieren cálculos intensivos tales como
ligeros compiladores con poca o ninguna gestión de datos.
Aplicaciones que requieran manejar una gran cantidad de datos

(navegar y consultar) con poco o ningún procesamiento de la
aplicación.
Arquitectura Aplicaciones en donde el procesamiento de la aplicación se
C/S de dos proporciona por software comercial (E.g. Ofimatica) sobre el cliente.
capas con
clientes Aplicaciones que requieren un procesamiento de datos
pesados computacionalmente intensivo (E.g. Visualización de datos). 35
Aplicaciones con una funcionalidad para el usuario final relativamente
estable usada en un entorno de gestión del sistema bien establecido.
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 aplicación son
multicapa volátiles
Aplicaciones en donde se integran datos de múltiples 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 cómo
contactar cada uno de estos servidores.
• Este modelo funciona bien para muchos tipos de
aplicaciones. Sin embargo, limita la flexibilidad de los
diseñadores del sistema ya que ellos deben decidir dónde
se proporciona cada servicio. También deben planificar la
escalabilidad y proporcionar algún medio para distribuir la
carga sobre los servidores cuando más clientes se añadan
37
al sistema.
Arquitecturas de objetos
Arquitecturas de objetos distribuidos

distribuidos
• Una aproximación más general al diseño de sistemas
distribuidos es eliminar la distinción entre cliente y
servidor y diseñar 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 distinción
lógica entre un cliente (receptor del servicio) y un
servidor (proveedor del servicio). 38
o1
S(o1)
o2
o5
S(o2)
S(o5)
distribuidos
Bus software
o3
S(o3)
o6
S(o6)
o4
S(o4)
39


distribuidos
• En una arquitectura de objetos distribuidos, los
objetos se distribuyen a través de varias
computadoras en una red y comunicarse a través
de middleware. Este middleware proporciona un
conjunto de servicios que permiten la
comunicación entre objetos y el que estos puedan
ser añadidos o eliminados del sistema.
40

distribuidos
• Ventajas del modelo de objetos distribuidos
• Los objetos que proporcionan servicios pueden
ejecutarse sobre cualquier nodo de la red. No será
necesario decidir con antelación donde ser situá la
lógica de la aplicación.
• Es una arquitectura muy abierta que permite añadir
nuevos recursos fácilmente. (Implementación de
estándares de comunicación entre objetos que permite
escribir objetos en lenguajes de programación distintos).
• Mayor flexibilidad y escalabilidad debido a que se
pueden crear diferentes instancias del sistema
proporcionando los mismo servicios por objetos
diferentes. (según la carga del sistema)
• Es posible reconfigurar el sistema de forma dinámica 41
mediante la migración de objetos a través de la red.

distribuidos
• En computación, CORBA (Common Object Request
Broker Architecture), arquitectura común de
intermediarios en peticiones a objetos, es un estándar
que establece una plataforma de desarrollo de
sistemas distribuidos facilitando la invocación de
métodos 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 42
lenguajes y ejecutadas en diferentes plataformas.

distribuidos
• En un sentido general, CORBA "envuelve" el código escrito
en otro lenguaje, en un paquete que contiene información
adicional sobre las capacidades del código que contiene y
sobre cómo llamar a sus métodos. Los objetos que
resultan, pueden entonces ser invocados desde otro
programa (u objeto CORBA) desde la red.
• CORBA utiliza un lenguaje de definición de interfaces (IDL)

para especificar las interfaces con los servicios que los
objetos ofrecerán. CORBA puede especificar a partir de
este IDL, la interfaz a un lenguaje determinado,
describiendo cómo los tipos de dato CORBA deben ser
utilizados en las implementaciones del cliente y del
servidor. Implementaciones estándar existen para Ada, C, 43
C++, Smalltalk, Java, Python, Perl y Tcl.

distribuidos
• Al compilar una interfaz en IDL se genera código para
el cliente y el servidor (el implementador del objeto).
El código del cliente sirve para poder realizar las
llamadas a métodos remoto. Es el conocido como
stub, el cual incluye un representante del objeto
remoto en el lado del cliente. El código generado para
el servidor consiste en unos skeletons que el
desarrollador tiene que rellenar para implementar los
métodos del objeto.
• CORBA es más que una especificación

multiplataforma, ya que define servicios
habitualmente necesarios como seguridad y 44
transacciones (middleware).

distribuidos
• Los estándares CORBA incluyen:
1. Un modelo de objetos para objetos de aplicación en
donde un objeto CORBA es una encapsulación 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 petición, envía la
petición de servicio y devuelve el resultado
solicitante del servicio. 45

distribuidos
3. Un conjunto de servicios de objetos que son
servicios generales que probablemente serán
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 básicos que pueden ser
requeridos por las aplicaciones. Pueden ser
componentes verticales específicos del dominio
o componentes horizontales de propósito 46
general usados por muchas aplicaciones.

distribuidos
Dos objetos o1 y o2 se comunican a través
o1 o2 de un ORB. El objeto que hace la llamada
(o1) tiene un stub IDL asociado que define la
S(o1) S(o2) interfaz del objeto que proporciona el
servicio solicitado. El implementador de o1
incluye la llamada a este stub en su
implementación del objeto cuando se
Stub Skeleton solicita un servicio.
IDL IDL El objeto que proporciona el servicio tiene
un skeleton IDL asociado que enlaza la
Intermediario de peticiones de interfaz con la implementación de los
objetos servicios. En términos simples cuando un
servicio se llama a través de la interfaz, el
skeleton IDL traduce los resultados a IDL
para que puedan ser accedidos por el objeto
que realizo la llamada. 47

distribuidos
• Los intermediarios de peticiones de objetos no se
implementan normalmente como procesos
separados, pero son un conjunto de librerías 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.
48

distribuidos
o1 o2 o3 o4
S(o1) S(o2) S(o3) S(o4)
Stub Skeleton Stub Skeleton

IDL IDL IDL IDL
Intermediario de peticiones de Intermediario de peticiones de

objetos objetos
49
Red

distribuidos
• Los servicios de CORBA proveen facilidades
requeridas por sistemas distribuidos. El estandar
incluye diversos servicios (aprox. 15 comunes) y
infinidad de servicios específicos. Algunos
ejemplos de estos servicios son:
• Servicio de nombres y categorías (trading): Permite

a los objetos hacer referencia y encontrar a los otros
objetos de la red. "Directorios de objetos".
50

distribuidos
• Servicios de notificación: Permiten a los objetos
notificar a otros objetos que ha ocurrido algún
evento. "Los objetos registran el interés en un
evento especifico del servicio".
• Servicio de transacciones: Soporta transacciones

atómicas y operaciones rollback cuando ocurre un
fallo.
51
Computación distribuida
Computación distribuida interorganizacional

interorganizacional
• La computación distribuida ha sido principalmente
implementada a nivel organizacional. Una
organización tiene varios servidores y distribuye la
carga entre ellos.
• Actualmente están disponibles modelos más recientes
de computación distribuida que permiten
computación distribuida interorganizacional en lugar
de intraorganizacional.
• Arquitecturas peer-to-peer
• Arquitecturas de sistemas orientados a servicios
• Servicios Web
52
• SOA

interorganizacional
• Peer-to-Peer
• 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 enormes.
• Los estándares y protocolos que posibilitan las
comunicaciones a través de los nodos están embebidos en
la propia aplicación, y cada nodo debe ejecutar una copia
53
de dicha aplicación.
n4
n1
n2
n5
n3
• Arquitectura P2P
n8
n11
interorganizacional
n7
n12
n6
n9
n10
54


interorganizacional
• 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 demás 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 música por Internet, este no es el único uso
que se puede dar a esta tecnología.
• Skype
• SETI (Search for Extraterrestrial Intelligence Institute).
• RTVE emisión en directo a través de P2P
55

interorganizacional
• Elementos de una red P2P
• Par: entidad capaz de desarrollar algún 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, permitiéndolo proporcionar
servicios desde su dispositivo y empleando los servicios ofrecidos por otros
pares de la red
• Súper-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 interés común u objetivo dictado por el resto de pares
implicados.
• Servicios: proporcionan una funcionalidad útil que se consigue mediante la
comunicación 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 56
miembros del grupo consiguiendo así acceso redundante al servicio.

interorganizacional
Rendimiento Elevado
P2P (Centralizado) Coste Alto
1- ¿cc.mp3?
Par B (bb.mp3)
2- Par C
Servidor
Bbb.mp3 Par A (¿cc.mp3?)
Ccc.mp3
Par C (cc.mp3) Ddd.mp3
3- cc.mp3 Conexión directa

Flujo de Datos
Par D (dd.mp3)
57

interorganizacional
P2P (Puro o totalmente descentralizado) "E.g. Gnutella"
¿ccc.mp3?
Par F Par E
¿ccc.mp3?
ccc.mp3 ccc.mp3
Par C – ccc.mp3 Par B Par A ¿ccc.mp3?

¿ccc.mp3? ¿ccc.mp3?
ccc.mp3
Par D
Conexión directa
Flujo de Datos
El modelo P2P puro es más robusto al no depender de un servidor central 58

Económico
Elevado tiempo y sobrecarga de ancho de banda.
El recurso buscado y existente ni siquiera pueda ser encontrado

interorganizacional
P2P (Mixto o semicentralizado)
Par A (¿cc.mp3?) Par Z (cc.mp3)

Superpar
(¿cc.mp3?) (¿cc.mp3?)
Z  cc.mp3
cc.mp3->Z
cc.mp3->Z
Conexión directa
Flujo de Datos
59
Red Escalable
Reducción del número de nodos involucrados en el encaminamiento
Buen tiempo de respuesta

interorganizacional
• La búsqueda de información (pares, contenidos y
servicios), dada la ausencia de un conocimiento global de
los datos y recursos involucrados, es un aspecto
fundamental en entornos P2P
• Búsqueda en caché: Cada par mantiene una caché de recursos

previamente descubiertos.
• Búsqueda directa: Pregunta directamente a otros pares de la red

con los que tenga conexión directa (Arquitectura P2P pura)
• Búsqueda indirecta: Los superpares actúan como fuente de

información de localización de pares y otros recursos conocidos.
Además esos hacen la búsqueda en nombre del par (Arquitectura
P2P mixta). 60

interorganizacional
• Características de las arquitecturas P2P
• Descentralización
• Escalabilidad
• Anonimato
• Propiedad compartida
• Rendimiento
• Seguridad
• Tolerancia a Fallos
• Interoperabilidad 61

interorganizacional
• JXTA (Juxtapose) es una plataforma peer-to-peer open source
creada por Sun Microsystems en el año 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
más maduro que actualmente existe. Además, fue diseñado
para permitir que un amplio rango de dispositivos
(computadoras, teléfonos móviles, PDAs) se comuniquen de
forma descentralizada.
• Como JXTA está basado en una serie de protocolos abiertos, en

teoría, puede ser portado a cualquier lenguaje moderno de
computación. Actualmente, la implementación de JXTA de Java
es la más avanzada. Existen versiones para C y C++, JXTA-C y 62
JXTA-C++ respectivamente.

interorganizacional
• JXTA crea una red virtual que permite a los peers interactuar entre sí,
aun cuando algunos de ellos estén detrás de firewalls, NATs o usen
distintos transportes de red. Además, cada peer es identificado por un
ID único, un URN SHA-1 de 160 bits en la implementación de Java,
permitiendo que los peers puedan cambiar su dirección pero
conservar su número de identificación.
• Los servicios JXTA pueden ser implementados para interoperar con

otros servicios. Por ejemplo, un servicio de comunicación P2P de
mensajería instantánea puede ser fácilmente agregado a una
aplicación P2P de compartición 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.
63

interorganizacional
• 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
información a HTML, entonces ésta podrá ser
accedida por estas computadoras. Sin embargo el
acceso solo a través de un navegador web no es
práctico. 64

interorganizacional
• Servicio web
• Un servicio Web (Web service) es una colección de protocolos y
estándares que sirven para intercambiar datos entre
aplicaciones.
• Mediante la noción de un servicio web, las organizaciones que
requieren hacer accesible la información 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 representación
estándar para cualquier recurso computacional o de información
que pueda ser usado por otros programas.
• La principal razón 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 aplicación y servicio. 65

interorganizacional
• Arquitectura conceptual de un sistema orientado
a servicios
Registro de
servicios
Buscar Publicar
Solicitante Suministrador
Servicio
de servicios de servicios
Enlazar
66

interorganizacional
• XML: Es el formato estándar 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 también pueden
enviarse de una aplicación a otra mediante protocolos
normales ya bien conocidos.
• WSDL: Es el lenguaje de la interfaz pública para los
servicios Web.
• UDDI: Protocolo para publicar la información de los
servicios Web. 67
• WS-Security: Protocolo de seguridad.

interorganizacional
• Diferencias entre la orientación a servicios y la
aproximación de objetos distribuidos
• Los servicios podrán ofertarse por cualquier
proveedor de servicio (con base en estándares)
dentro o fuera de una organización, las
organizaciones pueden crear aplicaciones
integrando servicios desde varios proveedores.
• E.g.
• Una compañía de fabricación puede enlazar directamente a
los servicios proporcionado por sus proveedores.
• Una compañía de logística puede enlazarse con servicios de
geolocalización y comunicaciónes. 68
• Sistemas de banca electrónica

interorganizacional
• El proveedor del servicio 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 antes de ser
incorporado en un programa de aplicación.
• Las aplicaciones pueden retrasar el enlace de los
servicios hasta que éstas sean desplegadas o hasta
que estén en ejecución.
• i.e. una aplicación podría cambiar dinámicamente los
proveedores de los servicios mientras el servicio se
este ejecutando. 69

interorganizacional
• El es posible la construcción 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
provisión. Por lo que en lugar de comprar un
componente de precio elevado que se usa
raramente, el desarrollador de la aplicación puede
usar un servicio externo por el que pagará
solamente cuando sea requerido. 70

interorganizacional
• Las aplicaciones pueden hacerse mas pequeñas
debido a que pueden implementar el manejo de
excepciones como servicios externos.
• Las aplicaciones pueden ser reactivas y adaptar su
operación de acuerdo con su entorno enlazando con
diferentes servicios a medida que cambia este.
71

interorganizacional
• Los tres estándares fundamentales que permiten la
comunicación entre servicios web son:
• SOAP (Simple Object Access Protocol). Este protocolo
define una organización para intercambio de datos
estructurados entre servicios web.
• WSDL (Web Services Description Languaje). Este
protocolo define cómo pueden representarse las
interfaces de los servicios web.
• UDDI (Universal Descripción, Discovery and Integratión).
Éste es un estándar de búsqueda que define como
puede organizarse la información de descripción de
servicios, usada por los solicitantes de los servicios para
encontrar servicios.
72
• *Todos los estándares se basan en XML generalmente.

interorganizacional
• Las arquitecturas de aplicaciones de servicios web
son arquitecturas débilmente acopladas en donde
el enlace a los servicios puede cambiar durante la
ejecución. Algunos sistemas se construirán
solamente usando servicios web y otras mezclaran
servicios web desarrollados localmente.
73

interorganizacional
• Ventajas de los servicios web
• Aportan interoperabilidad entre aplicaciones de
software
• Los servicios Web fomentan los estándares y protocolos
basados en texto (más 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 compañías y varios software's
• Permiten la interoperabilidad entre plataformas de
distintos fabricantes por medio de protocolos estándar. 74

interorganizacional
• Desventajas de los servicios web
• Para realizar transacciones no pueden compararse en su
grado de desarrollo con los estándares abiertos de
computación distribuida como CORBA.
• Su rendimiento es bajo si se compara con otros modelos
de computación distribuida, tales como RMI o CORBA
(XML no está diseñado para el rendimiento)
• Al apoyarse en HTTP, pueden esquivar medidas de
seguridad basadas en firewalls cuyas reglas tratan de
bloquear o auditar la comunicación entre programas a
ambos lados de la barrera.
• Existe poca información de servicios web para algunos 75
lenguajes de programación

interorganizacional
• Arquitectura Orientada a Servicios (SOA)
Evolución de la arquitectura:
Abstracción 76
interorganizacional
77


interorganizacional
Programación Objetos Componentes Servicios
Estructurada
Granularidad Muy fina Fina Intermedia Gruesa
Contrato Definido Privado/Publico Publico Publicado
Reusabilidad Baja Baja Intermedia Alta
Acoplamiento Fuerte Fuerte Débil Muy débil
Tiempo de Tiempo de Tiempo de

Dependencias Compilación Compilación Compilación Run-Time
78
Ámbito de Intra- Inter-
Comunicación Intra-Aplicación Aplicación Aplicaciones Inter-Empresas
interorganizacional
79

Tarea 04
Tarea 04
• Realizar un mapa conceptual que contenga los
conceptos de la clase 11 a 17
• A más tardar se debe entregar el día Domingo 17 de
Octubre de 2010 a las 23:59:59 hrs.
• Incluir portada.
• Recomendación: Usar Cmap Tools
80

14 15 16 17 Arquitecturas de Sistemas Distribuidos y Tarea 04

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

14 15 16 17 Arquitecturas de Sistemas Distribuidos y Tarea 04

Cargado por

Copyright:

Formatos disponibles

14, 15, 16 y 17 Arquitecturas de sistemas

Ventajas del uso de una aproximación distribuida

Ventajas del uso de una aproximación distribuida

Ventajas del uso de una aproximación distribuida

Ventajas del uso de una aproximación distribuida

Ventajas del uso de una aproximación distribuida

Ventajas del uso de una aproximación distribuida

Ventajas del uso de una aproximación distribuida

14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos

Desventajas del uso de una aproximación distribuida

• El rendimiento lo puede dar el nodo o la velocidad

Desventajas del uso de una aproximación distribuida

Desventajas del uso de una aproximación distribuida

Desventajas del uso de una aproximación distribuida

Reto al diseñar un sistema distribuido

• Para ello es necesario conocer las ventajas y

Reto al diseñar un sistema distribuido

Reto al diseñar un sistema distribuido

Cámaras y sensores Consolas de

Capa de gestión de datos

Aplicaciones que requieran manejar una gran cantidad de datos

Arquitecturas de objetos distribuidos

14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos

Arquitecturas de objetos distribuidos

Arquitecturas de objetos distribuidos

Arquitecturas de objetos distribuidos

• CORBA fue definido y está controlado por el Object

Arquitecturas de objetos distribuidos

• CORBA utiliza un lenguaje de definición de interfaces (IDL)

Arquitecturas de objetos distribuidos

• CORBA es más que una especificación

Arquitecturas de objetos distribuidos

Arquitecturas de objetos distribuidos

Arquitecturas de objetos distribuidos

Arquitecturas de objetos distribuidos

Arquitecturas de objetos distribuidos

S(o1) S(o2) S(o3) S(o4)

Stub Skeleton Stub Skeleton

Intermediario de peticiones de Intermediario de peticiones de

Arquitecturas de objetos distribuidos

• Servicio de nombres y categorías (trading): Permite

Arquitecturas de objetos distribuidos

• Servicio de transacciones: Soporta transacciones

Computación distribuida interorganizacional

Computación distribuida interorganizacional

14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos

Computación distribuida interorganizacional

Computación distribuida interorganizacional

Computación distribuida interorganizacional

3- cc.mp3 Conexión directa

Computación distribuida interorganizacional

Par C – ccc.mp3 Par B Par A ¿ccc.mp3?

El modelo P2P puro es más robusto al no depender de un servidor central 58

Computación distribuida interorganizacional

Par A (¿cc.mp3?) Par Z (cc.mp3)

Computación distribuida interorganizacional

• Búsqueda en caché: Cada par mantiene una caché de recursos

• Búsqueda directa: Pregunta directamente a otros pares de la red

• Búsqueda indirecta: Los superpares actúan como fuente de

Computación distribuida interorganizacional

Computación distribuida interorganizacional

• Como JXTA está basado en una serie de protocolos abiertos, en

Computación distribuida interorganizacional