Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
14, 15, 16 y 17 Arquitecturas de sistemas distribuidos y Tarea 04
Estructuras de datos (Prof. Edgardo A. Franco)
1
Prof. Edgardo Adrián Franco Martínez http://computacion.cs.cinvestav.mx/~efranco [email protected]
Contenido
• 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
• Tarea 04
2
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s C
on
ten
ido
Introducción
• Prácticamente todos los grandes sistemas informáticos son en la actualidad sistemas distribuidos.
3
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s In
tro
du
cció
n
Ventajas del uso de una aproximación distribuida • Compartición de recursos
• Apertura
• Concurrencia
• Escalabilidad
• Tolerancia a defectos
4
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s V
enta
jas
del
uso
de
un
a ap
roxi
mac
ión
dis
trib
uid
a
Ventajas del uso de una aproximación distribuida • 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s V
enta
jas
del
uso
de
un
a ap
roxi
mac
ión
dis
trib
uid
a
Ventajas del uso de una aproximación distribuida • 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s V
enta
jas
del
uso
de
un
a ap
roxi
mac
ión
dis
trib
uid
a
Ventajas del uso de una aproximación distribuida • 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s V
enta
jas
del
uso
de
un
a ap
roxi
mac
ión
dis
trib
uid
a
Ventajas del uso de una aproximación distribuida • 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s V
enta
jas
del
uso
de
un
a ap
roxi
mac
ión
dis
trib
uid
a
Ventajas del uso de una aproximación distribuida • 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s V
enta
jas
del
uso
de
un
a ap
roxi
mac
ión
dis
trib
uid
a
Ventajas del uso de una aproximación distribuida • 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s V
enta
jas
del
uso
de
un
a ap
roxi
mac
ión
dis
trib
uid
a
Desventajas del uso de una aproximación distribuida • Complejidad
• Seguridad
• Manejabilidad
• Impredecibilidad
11
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s D
esve
nta
jas
del
uso
de
un
a ap
roxi
mac
ión
dis
trib
uid
a
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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s D
esve
nta
jas
del
uso
de
un
a ap
roxi
mac
ión
dis
trib
uid
a
Desventajas del uso de una aproximación distribuida • 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s D
esve
nta
jas
del
uso
de
un
a ap
roxi
mac
ión
dis
trib
uid
a
Desventajas del uso de una aproximación distribuida • 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s D
esve
nta
jas
del
uso
de
un
a ap
roxi
mac
ión
dis
trib
uid
a
Desventajas del uso de una aproximación distribuida • 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s D
esve
nta
jas
del
uso
de
un
a ap
roxi
mac
ión
dis
trib
uid
a
Reto al diseñar un sistema 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s R
eto
al d
iseñ
ar u
n s
iste
ma
dis
trib
uid
o
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 (scheduler).
17
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s R
eto
al d
iseñ
ar u
n s
iste
ma
dis
trib
uid
o
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.
18
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s R
eto
al d
iseñ
ar u
n s
iste
ma
dis
trib
uid
o
Proceso de control de sensores
Procesador de sensores
Proceso de vizualizado
Procesador de flujo de trafico
Proceso de control de
luces
Procesador de control de semáforos
Cámaras y sensores de flujo de tráfico
Consolas de los operadores Semáforos
Sistema multiprocesador de control de trafico
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 1:1 entre procesos y procesadores. en el sistema.
19
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s cl
ien
te-s
ervi
do
r
Arquitecturas cliente-servidor
20
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s cl
ien
te-s
ervi
do
r
c1
s1
Un sistema cliente –servidor
c1
c1
c1
s4
c12
c11
c6
s2 c7
c8
s3
c10
c9
Proceso servidor
Proceso cliente
Arquitecturas cliente-servidor
• 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.
21
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s cl
ien
te-s
ervi
do
r
Capa de gestión de datos
Capa de procesamiento de la aplicación
Capa de presentación
Arquitecturas cliente-servidor
• 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
22
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s cl
ien
te-s
ervi
do
r
Arquitecturas cliente-servidor
• 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s cl
ien
te-s
ervi
do
r
Arquitecturas cliente-servidor
• 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s cl
ien
te-s
ervi
do
r
Arquitecturas cliente-servidor
25
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s cl
ien
te-s
ervi
do
r
Gestión de datos Procesamiento de
la aplicación
Servidor
Gestión de datos
Servidor
Cliente
Cliente
Modelo de cliente ligero
Modelo de cliente pesado
Presentación
Presentación Procesamiento de la
aplicación
Arquitecturas cliente-servidor
• 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s cl
ien
te-s
ervi
do
r
Arquitecturas cliente-servidor
• 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s cl
ien
te-s
ervi
do
r
Arquitecturas cliente-servidor
• Un sistema ATM cliente-servidor
28
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s cl
ien
te-s
ervi
do
r
ATM
ATM
ATM
ATM
Base de datos de
cuentas de clientes
Servidor de cuentas
Monitor de teleprocesa
miento
Arquitecturas cliente-servidor
• 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s cl
ien
te-s
ervi
do
r
Arquitecturas cliente-servidor
• 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s cl
ien
te-s
ervi
do
r
Arquitecturas cliente-servidor
• 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s cl
ien
te-s
ervi
do
r
Arquitecturas cliente-servidor
32
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s cl
ien
te-s
ervi
do
r
Cliente
Servidor
Procesamiento de la aplicación
Servidor
Gestión de los datos
Presentación
Arquitectura cliente-servidor de tres capas
Arquitecturas cliente-servidor
• 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s cl
ien
te-s
ervi
do
r
Arquitecturas cliente-servidor
34
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s cl
ien
te-s
ervi
do
r
Cliente
Servidor Web
Provisión del servicio de
cuentas
Servidor de bases de datos
SQL
Interacción HTTP
Cliente
Cliente
SQL query Base de datos de cuentas de
clientes
La arquitectura de distribución de un sistema bancario en Internet
Arquitecturas cliente-servidor
35
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s cl
ien
te-s
ervi
do
r
Arquitectura
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
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.
Arquitecturas cliente-servidor
36
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s cl
ien
te-s
ervi
do
r
Arquitectura Aplicaciones
Arquitectura C/S de tres capas o multicapa
Aplicaciones a gran escala con cientos o miles de clientes Aplicaciones en donde tanto los datos como la aplicación son volátiles Aplicaciones en donde se integran datos de múltiples fuentes.
Arquitecturas cliente-servidor
• En el modelo cliente-servidor de un sistema distribuido, los clientes y los servidores son diferentes. Los clientes reciben servicios de los servidores y no de otros clientes; los servidores pueden actuar como clientes recibiendo servicios de otros servidores, pero sin solicitar servicios de clientes; los clientes deben conocer los servicios que ofrece cada uno de los servidores y deben conocer cómo contactar 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.
37
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s cl
ien
te-s
ervi
do
r
Arquitecturas de objetos 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s d
e o
bje
tos
dis
trib
uid
os
Arquitecturas de objetos distribuidos
39
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s d
e o
bje
tos
dis
trib
uid
os
Bus software
o1
S(o1)
o2
S(o2)
o3
S(o3)
o4
S(o4)
o5
S(o5)
o6
S(o6)
Arquitecturas de objetos 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s d
e o
bje
tos
dis
trib
uid
os
Arquitecturas de objetos 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 mediante la migración de objetos a través de la red.
41
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s d
e o
bje
tos
dis
trib
uid
os
Arquitecturas de objetos 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 lenguajes y ejecutadas en diferentes plataformas.
42
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s d
e o
bje
tos
dis
trib
uid
os
Arquitecturas de objetos 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, C++, Smalltalk, Java, Python, Perl y Tcl.
43
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s d
e o
bje
tos
dis
trib
uid
os
Arquitecturas de objetos 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 transacciones (middleware).
44
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s d
e o
bje
tos
dis
trib
uid
os
Arquitecturas de objetos 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s d
e o
bje
tos
dis
trib
uid
os
Arquitecturas de objetos 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 general usados por muchas aplicaciones.
46
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s d
e o
bje
tos
dis
trib
uid
os
Arquitecturas de objetos distribuidos
47
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s d
e o
bje
tos
dis
trib
uid
os
Intermediario de peticiones de objetos
o1
S(o1)
o2
S(o2)
Stub IDL
Skeleton IDL
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.
Arquitecturas de objetos 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s d
e o
bje
tos
dis
trib
uid
os
Arquitecturas de objetos distribuidos
49
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s d
e o
bje
tos
dis
trib
uid
os
Intermediario de peticiones de objetos
o1
S(o1)
o2
S(o2)
Stub IDL
Skeleton IDL
Intermediario de peticiones de objetos
o3
S(o3)
o4
S(o4)
Stub IDL
Skeleton IDL
Red
Arquitecturas de objetos 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s d
e o
bje
tos
dis
trib
uid
os
Arquitecturas de objetos 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s A
rqu
itec
tura
s d
e o
bje
tos
dis
trib
uid
os
Computación distribuida 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
• SOA
52
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s C
om
pu
taci
ón
dis
trib
uid
a in
tero
rgan
izac
ion
al
Computación distribuida 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 de dicha aplicación.
53
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s C
om
pu
taci
ón
dis
trib
uid
a in
tero
rgan
izac
ion
al
Computación distribuida interorganizacional • Arquitectura P2P
54
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s C
om
pu
taci
ón
dis
trib
uid
a in
tero
rgan
izac
ion
al
n4
n2
n8
n1 n5
n3
n9
n10
n6
n11
n12
n7
Computación distribuida 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s C
om
pu
taci
ón
dis
trib
uid
a in
tero
rgan
izac
ion
al
Computación distribuida 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 miembros del grupo consiguiendo así acceso redundante al servicio.
56
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s C
om
pu
taci
ón
dis
trib
uid
a in
tero
rgan
izac
ion
al
Computación distribuida interorganizacional
57
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s C
om
pu
taci
ón
dis
trib
uid
a in
tero
rgan
izac
ion
al
Par B (bb.mp3)
Par C (cc.mp3)
Par D (dd.mp3)
Servidor Bbb.mp3 Ccc.mp3 Ddd.mp3
Par A (¿cc.mp3?)
1- ¿cc.mp3?
2- Par C
3- cc.mp3 Conexión directa
Flujo de Datos
P2P (Centralizado)
Rendimiento Elevado
Coste Alto
Computación distribuida interorganizacional
58
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s C
om
pu
taci
ón
dis
trib
uid
a in
tero
rgan
izac
ion
al
Par F Par E
Par C – ccc.mp3 Par B
Par D
Par A ¿ccc.mp3?
Conexión directa Flujo de Datos
¿ccc.mp3? ¿ccc.mp3?
¿ccc.mp3?
¿ccc.mp3?
ccc.mp3
ccc.mp3 ccc.mp3
P2P (Puro o totalmente descentralizado) "E.g. Gnutella"
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
Computación distribuida interorganizacional
59
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s C
om
pu
taci
ón
dis
trib
uid
a in
tero
rgan
izac
ion
al
Conexión directa Flujo de Datos
Par A (¿cc.mp3?) Par Z (cc.mp3) Superpar
Z cc.mp3 (¿cc.mp3?) (¿cc.mp3?)
cc.mp3->Z
cc.mp3->Z
Red Escalable
Reducción del número de nodos involucrados en el encaminamiento
Buen tiempo de respuesta
P2P (Mixto o semicentralizado)
Computación distribuida 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s C
om
pu
taci
ón
dis
trib
uid
a in
tero
rgan
izac
ion
al
Computación distribuida interorganizacional • Características de las arquitecturas P2P
• Descentralización
• Escalabilidad
• Anonimato
• Propiedad compartida
• Rendimiento
• Seguridad
• Tolerancia a Fallos
• Interoperabilidad
61
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s C
om
pu
taci
ón
dis
trib
uid
a in
tero
rgan
izac
ion
al
Computación distribuida 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 JXTA-C++ respectivamente.
62
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s C
om
pu
taci
ón
dis
trib
uid
a in
tero
rgan
izac
ion
al
Computación distribuida 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s C
om
pu
taci
ón
dis
trib
uid
a in
tero
rgan
izac
ion
al
Computación distribuida 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s C
om
pu
taci
ón
dis
trib
uid
a in
tero
rgan
izac
ion
al
Computación distribuida 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s C
om
pu
taci
ón
dis
trib
uid
a in
tero
rgan
izac
ion
al
Computación distribuida interorganizacional
66
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s C
om
pu
taci
ón
dis
trib
uid
a in
tero
rgan
izac
ion
al
Registro de servicios
Solicitante de servicios
Suministrador de servicios
Servicio
Publicar
Enlazar
Buscar
• Arquitectura conceptual de un sistema orientado a servicios
Computación distribuida interorganizacional
67
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s C
om
pu
taci
ón
dis
trib
uid
a in
tero
rgan
izac
ion
al
• 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.
Computación distribuida 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.
• Sistemas de banca electrónica
68
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s C
om
pu
taci
ón
dis
trib
uid
a in
tero
rgan
izac
ion
al
Computación distribuida 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s C
om
pu
taci
ón
dis
trib
uid
a in
tero
rgan
izac
ion
al
Computación distribuida 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s C
om
pu
taci
ón
dis
trib
uid
a in
tero
rgan
izac
ion
al
Computación distribuida 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s C
om
pu
taci
ón
dis
trib
uid
a in
tero
rgan
izac
ion
al
Computación distribuida 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.
• *Todos los estándares se basan en XML generalmente.
72
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s C
om
pu
taci
ón
dis
trib
uid
a in
tero
rgan
izac
ion
al
Computación distribuida 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s C
om
pu
taci
ón
dis
trib
uid
a in
tero
rgan
izac
ion
al
Computación distribuida 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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s C
om
pu
taci
ón
dis
trib
uid
a in
tero
rgan
izac
ion
al
Computación distribuida 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 lenguajes de programación
75
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s C
om
pu
taci
ón
dis
trib
uid
a in
tero
rgan
izac
ion
al
Computación distribuida interorganizacional • Arquitectura Orientada a Servicios (SOA)
76
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s C
om
pu
taci
ón
dis
trib
uid
a in
tero
rgan
izac
ion
al
Evolución de la arquitectura:
Abstracción
Computación distribuida interorganizacional
77
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s C
om
pu
taci
ón
dis
trib
uid
a in
tero
rgan
izac
ion
al
Computación distribuida interorganizacional
78
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s C
om
pu
taci
ón
dis
trib
uid
a in
tero
rgan
izac
ion
al
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
Ámbito de
Comunicación
Intra-Aplicación
Intra-
Aplicación
Inter-
Aplicaciones
Inter-Empresas
Computación distribuida interorganizacional
79
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s C
om
pu
taci
ón
dis
trib
uid
a in
tero
rgan
izac
ion
al
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
Sist
emas
op
erat
ivo
s II
1
4 ,
15
, 16
y 1
7 A
rqu
itec
tura
s d
e si
stem
as d
istr
ibu
ido
s Ta
rea
04