11 Tipos de sistemas distribuidos

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
[email protected]
Estructuras de datos (Prof. Edgardo A. Franco)
•
•
•
•
•
•
•
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
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Contenido
Contenido
• CORBA
• Computación distribuida interorganizacional
• Arquitecturas peer-to-peer
• Arquitecturas de sistemas orientados a servicios
• Tarea 04
2
• Prácticamente todos los grandes sistemas
informáticos son en la actualidad sistemas
distribuidos.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Introducción
Introducción
3
• Compartición de recursos
• Apertura
• Concurrencia
• Escalabilidad
• Tolerancia a defectos
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Ventajas del uso de una aproximación distribuida
Ventajas del uso de una
aproximación distribuida
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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Ventajas del uso de una aproximación distribuida
Ventajas del uso de una
aproximación distribuida
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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Ventajas del uso de una aproximación distribuida
Ventajas del uso de una
aproximación distribuida
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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Ventajas del uso de una aproximación distribuida
Ventajas del uso de una
aproximación distribuida
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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Ventajas del uso de una aproximación distribuida
Ventajas del uso de una
aproximación distribuida
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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Ventajas del uso de una aproximación distribuida
Ventajas del uso de una
aproximación distribuida
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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Ventajas del uso de una aproximación distribuida
Ventajas del uso de una
aproximación distribuida
10
• Complejidad
• Seguridad
• Manejabilidad
• Impredecibilidad
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Desventajas del uso de una aproximación distribuida
Desventajas del uso de una
aproximación distribuida
11
• 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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Desventajas del uso de una aproximación distribuida
Desventajas del uso de una
aproximación distribuida
• 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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Desventajas del uso de una aproximación distribuida
Desventajas del uso de una
aproximación distribuida
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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Desventajas del uso de una aproximación distribuida
Desventajas del uso de una
aproximación distribuida
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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Desventajas del uso de una aproximación distribuida
Desventajas del uso de una
aproximación distribuida
15
• 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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Reto al diseñar un sistema distribuido
Reto al diseñar un sistema
distribuido
• Para ello es necesario conocer las ventajas y
desventajas de las diferentes arquitecturas de
sistemas distribuidos.
16
• 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
(scheduler).
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Reto al diseñar un sistema distribuido
Arquitecturas multiprocesador
17
• 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
Cámaras y sensores
de flujo de tráfico
Procesador
de sensores
Procesador
de flujo de trafico
Procesador de
control de
semáforos
Proceso de
control de
sensores
Proceso de
vizualizado
Proceso de
control de
luces
Consolas de
los operadores
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Reto al diseñar un sistema distribuido
Arquitecturas multiprocesador
18
Semáforos
• 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
1:1 entre procesos y procesadores. en el sistema.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas cliente-servidor
Arquitecturas cliente-servidor
19
Un sistema cliente –servidor
c1
c1
c1
c1
Proceso
servidor
c12
s1
c11
Proceso
cliente
s4
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas cliente-servidor
Arquitecturas cliente-servidor
c6
c10
c7
c9
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
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas cliente-servidor
Arquitecturas cliente-servidor
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
necesario que estén claramente separadas
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas cliente-servidor
Arquitecturas cliente-servidor
22
• 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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas cliente-servidor
Arquitecturas cliente-servidor
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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas cliente-servidor
Arquitecturas cliente-servidor
24
Presentación
Modelo de
cliente ligero
Modelo de
cliente pesado
Cliente
Cliente
Presentación
Procesamiento de la
aplicación
Servidor
Gestión de datos
Procesamiento de
la aplicación
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas cliente-servidor
Arquitecturas cliente-servidor
Servidor
Gestión de datos
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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas cliente-servidor
Arquitecturas cliente-servidor
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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas cliente-servidor
Arquitecturas cliente-servidor
27
• Un sistema ATM cliente-servidor
ATM
Servidor de cuentas
Monitor de
teleprocesa
miento
ATM
Base de
datos de
cuentas de
clientes
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas cliente-servidor
Arquitecturas cliente-servidor
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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas cliente-servidor
Arquitecturas cliente-servidor
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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas cliente-servidor
Arquitecturas cliente-servidor
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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas cliente-servidor
Arquitecturas cliente-servidor
31
Arquitectura cliente-servidor de tres capas
Presentación
Cliente
Servidor
Servidor
Procesamiento
de la aplicación
Gestión de los
datos
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas cliente-servidor
Arquitecturas cliente-servidor
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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas cliente-servidor
Arquitecturas cliente-servidor
33
La arquitectura de distribución de
un sistema bancario en Internet
Interacción HTTP
Cliente
Cliente
Cliente
Servidor Web
Provisión del
servicio de
cuentas
SQL query
Servidor de bases
de datos
SQL
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas cliente-servidor
Arquitecturas cliente-servidor
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 práctico separar el
procesamiento de la aplicación y la gestión de los datos.
Aplicaciones que requieren cálculos intensivos tales como
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
C/S de dos
capas con
clientes
pesados
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas cliente-servidor
Arquitecturas cliente-servidor
Aplicaciones en donde el procesamiento de la aplicación se
proporciona por software comercial (E.g. Ofimatica) sobre el cliente.
Aplicaciones que requieren un procesamiento de datos
computacionalmente intensivo (E.g. Visualización de datos).
Aplicaciones con una funcionalidad para el usuario final relativamente
estable usada en un entorno de gestión 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 aplicación son
multicapa
volátiles
Aplicaciones en donde se integran datos de múltiples fuentes.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas cliente-servidor
Arquitecturas cliente-servidor
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
al sistema.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas cliente-servidor
Arquitecturas cliente-servidor
37
• 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).
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas de objetos distribuidos
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)
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas de objetos distribuidos
Arquitecturas de objetos
distribuidos
39
• 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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas de objetos distribuidos
Arquitecturas de objetos
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 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
mediante la migración de objetos a través de la red.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas de objetos distribuidos
Arquitecturas de objetos
distribuidos
41
• 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
lenguajes y ejecutadas en diferentes plataformas.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas de objetos distribuidos
Arquitecturas de objetos
distribuidos
42
• 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,
C++, Smalltalk, Java, Python, Perl y Tcl.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas de objetos distribuidos
Arquitecturas de objetos
distribuidos
43
• 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
transacciones (middleware).
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas de objetos distribuidos
Arquitecturas de objetos
distribuidos
44
• 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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas de objetos distribuidos
Arquitecturas de objetos
distribuidos
45
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
general usados por muchas aplicaciones.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas de objetos distribuidos
Arquitecturas de objetos
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 través
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
implementación del objeto cuando se
solicita un servicio.
El objeto que proporciona el servicio tiene
un skeleton IDL asociado que enlaza la
interfaz con la implementación de los
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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas de objetos distribuidos
Arquitecturas de objetos
distribuidos
47
• 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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas de objetos distribuidos
Arquitecturas de objetos
distribuidos
48
o1
o2
o3
o4
S(o1)
S(o2)
S(o3)
S(o4)
Stub
IDL
Skeleton
IDL
Stub
IDL
Skeleton
IDL
Intermediario de peticiones de
objetos
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas de objetos distribuidos
Arquitecturas de objetos
distribuidos
Intermediario de peticiones de
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 específicos. Algunos
ejemplos de estos servicios son:
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas de objetos distribuidos
Arquitecturas de objetos
distribuidos
• 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
• 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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Arquitecturas de objetos distribuidos
Arquitecturas de objetos
distribuidos
51
• 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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Computación distribuida interorganizacional
Computación 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 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
de dicha aplicación.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Computación distribuida interorganizacional
Computación distribuida
interorganizacional
53
• Arquitectura P2P
n4
n2
n1
n7
n5
n9
n8
n6
n3
n12
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Computación distribuida interorganizacional
Computación distribuida
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 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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Computación distribuida interorganizacional
Computación distribuida
interorganizacional
• Skype
• SETI (Search for Extraterrestrial Intelligence Institute).
• RTVE emisión en directo a través de P2P
55
• 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
miembros del grupo consiguiendo así acceso redundante al servicio.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Computación distribuida interorganizacional
Computación distribuida
interorganizacional
56
Rendimiento Elevado
Coste Alto
P2P (Centralizado)
1- ¿cc.mp3?
Par B (bb.mp3)
2- Par C
Par C (cc.mp3)
Servidor
Bbb.mp3
Ccc.mp3
Ddd.mp3
3- cc.mp3
Par A (¿cc.mp3?)
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Computación distribuida interorganizacional
Computación distribuida
interorganizacional
Conexión 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?
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Computación distribuida interorganizacional
Computación distribuida
interorganizacional
¿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
Económico
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
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Computación distribuida interorganizacional
Computación distribuida
interorganizacional
Conexión directa
Flujo de Datos
Red Escalable
Reducción del número de nodos involucrados en el encaminamiento
Buen tiempo de respuesta
59
• 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).
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Computación distribuida interorganizacional
Computación distribuida
interorganizacional
60
• Características de las arquitecturas P2P
•
•
•
•
•
•
•
•
Descentralización
Escalabilidad
Anonimato
Propiedad compartida
Rendimiento
Seguridad
Tolerancia a Fallos
Interoperabilidad
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Computación distribuida interorganizacional
Computación distribuida
interorganizacional
61
• 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
JXTA-C++ respectivamente.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Computación distribuida interorganizacional
Computación distribuida
interorganizacional
62
• 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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Computación distribuida interorganizacional
Computación distribuida
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
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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Computación distribuida interorganizacional
Computación distribuida
interorganizacional
64
• 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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Computación distribuida interorganizacional
Computación distribuida
interorganizacional
65
• Arquitectura conceptual de un sistema orientado
a servicios
Registro de
servicios
Buscar
Solicitante
de servicios
Publicar
Enlazar
Suministrador
de servicios
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Computación distribuida interorganizacional
Computación distribuida
interorganizacional
Servicio
66
• 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.
• WS-Security: Protocolo de seguridad.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Computación distribuida interorganizacional
Computación distribuida
interorganizacional
67
• 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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Computación distribuida interorganizacional
Computación distribuida
interorganizacional
• 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.
• Sistemas de banca electrónica
68
• 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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Computación distribuida interorganizacional
Computación distribuida
interorganizacional
69
• 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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Computación distribuida interorganizacional
Computación distribuida
interorganizacional
70
• 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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Computación distribuida interorganizacional
Computación distribuida
interorganizacional
71
• 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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Computación distribuida interorganizacional
Computación distribuida
interorganizacional
72
• *Todos los estándares se basan en XML generalmente.
• 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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Computación distribuida interorganizacional
Computación distribuida
interorganizacional
73
• 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.
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Computación distribuida interorganizacional
Computación distribuida
interorganizacional
74
• 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
lenguajes de programación
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Computación distribuida interorganizacional
Computación distribuida
interorganizacional
75
• Arquitectura Orientada a Servicios (SOA)
Evolución de la arquitectura:
Abstracción
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Computación distribuida interorganizacional
Computación distribuida
interorganizacional
76
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Computación distribuida interorganizacional
Computación distribuida
interorganizacional
77
Programación
Estructurada
Objetos
Componentes
Servicios
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
Dependencias
Tiempo de
Compilación
Tiempo de
Compilación
Tiempo de
Compilación
Run-Time
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Computación distribuida interorganizacional
Computación distribuida
interorganizacional
78
Ámbito de
Comunicación
Intra-Aplicación
IntraAplicación
InterAplicaciones
Inter-Empresas
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Computación distribuida interorganizacional
Computación distribuida
interorganizacional
79
• 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
Sistemas operativos II
14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos
Tarea 04
Tarea 04
80