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 Adrin Franco Martnez http://computacion.cs.cinvestav.mx/~efranco efranco.docencia@gmail.com Estructuras de datos (Prof. Edgardo A. Franco)
Introduccin Ventajas del uso de una aproximacin distribuida Desventajas del uso de una aproximacin distribuida Reto al disear un sistema distribuido Arquitecturas multiprocesador Arquitecturas cliente-servidor Arquitecturas de objetos distribuidos
CORBA
Computacin distribuida interorganizacional

Arquitecturas peer-to-peer Arquitecturas de sistemas orientados a servicios
Tarea 04
Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Contenido
Contenido
Prcticamente todos los grandes sistemas informticos son en la actualidad sistemas distribuidos.
Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Introduccin
Introduccin
Comparticin 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 aproximacin distribuida
Ventajas del uso de una aproximacin distribuida
Comparticin de recursos Un sistema distribuido permite compartir recursos hardware y software como discos, impresoras, archivos, compiladores, etc. que se asocian con computadoras de una red.
Apertura Los sistemas distribuidos son normalmente sistemas abiertos, lo que significa que se disean sobre protocolos estndar que permiten combinar equipamiento y software de diferentes vendedores.
Concurrencia En un sistema distribuido, varios procesos pueden operar al mismo tiempo sobre diferentes computadoras de la red. Estos procesos pueden comunicarse con otros durante su funcionamiento normal.
Escalabilidad Los sistemas distribuidos debern de ser escalables en tanto que la capacidad del sistema puede incrementarse aadiendo nuevos recursos para cubrir nuevas demandas sobre el sistema.
*Mantener un costo constante y manejable por cada recurso que se agregue.
Tolerancia a defectos La disponibilidad de varias computadoras y el potencial para reproducir informacin significa que los sistemas distribuidos pueden ser tolerantes a algunos fallos de funcionamiento del hardware y del software. La mayora de los sistemas distribuidos pueden proporcionar servicios an y cuando ocurren fallas de funcionamiento (puede degradarse el servicio); una completa perdida de servicio solo ocurre cuando existe un fallo de funcionamiento en la red.
Para sistemas organizacionales a gran escala, estas ventajas han remplazado a ampliamente a las alcanzadas por los sistemas heredados centralizados de los aos 80's y 90's. Sin embargo, comparados con los sistemas que se ejecutan en un solo procesador o cluster de procesadores, los sistemas distribuidos tienen desventajas muy marcadas.
10
Desventajas del uso de una aproximacin distribuida

Complejidad Seguridad Manejabilidad Impredecibilidad
11
Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Desventajas del uso de una aproximacin distribuida
Complejidad Los sistemas distribuidos son mucho ms complejos que los sistemas centralizados. Esto hace ms difcil de comprender sus propiedades emergentes y la prueba de estos sistemas.
El rendimiento lo puede dar el nodo o la velocidad de la red, la ubicacin de los recursos, la distribucin de los nodos, etc.
12
Seguridad Puede accederse al sistema desde varias computadoras diferentes, y el trafico en la red puede estar sujeto a situaciones indeseadas. Esto hace ms difcil el asegurar que la integridad de los datos en el sistema se mantenga y que los servicios del sistema no se degraden por ataques de denegacin de servicio.
13
Manejabilidad Las computadoras en un sistema pueden ser de diferentes tipos y pueden ejecutar versiones diferentes de sistemas operativos. Los defectos en una maquina pueden propagarse a otras mquinas con consecuencias inesperadas. Esto significa que se requiere ms esfuerzo para gestionar y mantener el funcionamiento del sistema.
14
Impredecibilidad Los sistemas distribuidos tienen una respuesta impredecible (E.g. la WWW). La respuesta depende de la carga total en el sistema, de su organizacin y de la carga de la red. Como todos ellos pueden cambiar con mucha rapidez, el tiempo requerido para responder a una peticin de usuario puede variar drsticamente de una peticin a otra.
15
El reto para el diseo de un sistema distribuido es proporcionar caractersticas deseables a los sistemas distribuidos y, al mismo tiempo, minimizar los problemas inherentes a estos sistemas. Para ello es necesario conocer las ventajas y desventajas de las diferentes arquitecturas de sistemas distribuidos.
Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Reto al disear un sistema distribuido
Reto al disear un sistema distribuido
16
El modelo ms simple de un sistema multiprocesador en el que el sistema software esta formado por varios proceso que pueden (aunque no necesariamente) ejecutarse sobre procesadores diferentes. Este modelo es comn en sistemas de tiempo real o sistemas distribuidos masivos.
Los procesos relacionados con la recopilacin de informacin, toma de decisiones y control de actuadores podran ejecutarse en un solo procesador bajo el control de un planificador (scheduler).
Arquitecturas multiprocesador
17
El uso de mltiples procesadores mejora el rendimiento y adaptabilidad del sistema. La distribucin de procesos entre los procesadores puede ser predeterminada por un despachador (dispatcher) que decide que procesos se asignan a cada procesador.
Sistema multiprocesador de control de trafico
Procesador de sensores Proceso de control de sensores

Cmaras y sensores de flujo de trfico Consolas de los operadores
Procesador de flujo de trafico Proceso de vizualizado
Procesador de control de semforos Proceso de control de luces
Semforos
Arquitecturas multiprocesador
18
En una arquitectura cliente-servidor, una aplicacin se modela como un conjunto de servicios proporcionados por los servidores y un conjunto de clientes que usan estos servicios. Los clientes necesitan conocer qu servidores estn disponibles, pero normalmente no conocen la existencia de otros clientes. Clientes y servidores son procesos diferentes. Varios procesos servidores pueden ejecutarse en un procesador, por lo que no existe una correspondencia 1:1 entre procesos y procesadores. en el sistema.
Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Arquitecturas cliente-servidor
Arquitecturas cliente-servidor
19
c1
c1 c1
Un sistema cliente servidor
c12
Proceso servidor
c11
c1
s1 s4
Proceso cliente
c6
c10
c7
c9 s2
s3
c8
20
El diseo de sistemas cliente-servidor debera reflejar la estructura lgica de la aplicacin que se esta desarrollando. Por ello generalmente se debe de organizar en tres capas.
Capa de presentacin
Capa de procesamiento de la aplicacin 21 Capa de gestin de datos
La capa de presentacin est relacionada con la presentacin de la informacin al usuario y con toda la interaccin con l. La capa de procesamiento de la aplicacin est relacionada con la implementacin de la lgica de la aplicacin. La capa de gestin de datos est relacionada con todas las operaciones sobre la base de datos. En los sistemas centralizados, estas capas no es necesario que estn claramente separadas
22
Sin embargo a la hora del diseo debe hacerse una distincin entre ellas, de forma que sea posible distribuir cada capa sobre una computadora diferente. La arquitectura cliente servidor ms simple se denomina arquitectura cliente-servidor de dos capas, en la que una aplicacin se organiza como un servidor (o mltiples servidores) y un conjunto de clientes.
23
Arquitecturas cliente-servidor de dos capas: 1. Modelo de cliente ligero (thin-client): En un modelo de cliente ligero, todo el procesamiento de las aplicaciones y la gestin de los datos se lleva a cabo en el servidor. El cliente simplemente es responsable de la capa de presentacin del software. 2. Modelo de cliente rico o pesado (fat-client): En este modelo, el servidor solamente es responsable de la gestin de los datos. El software del cliente implementa la lgica de la aplicacin y las interacciones con el usuario del sistema.
24
Presentacin
Modelo de cliente ligero
Cliente
Servidor Gestin de datos Procesamiento de la aplicacin
Modelo de cliente pesado
Cliente
Presentacin Procesamiento de la aplicacin
Servidor Gestin de datos
25
Una arquitectura de dos capas con clientes ligeros, es la aproximacin ms simple en los sistemas centralizados. Una desventaja del modelo de cliente ligero es que ubica una elevada carga de procesamiento tanto en el servidor como en la red. El servidor es responsable de todos los clculos, adems de que se debera de aprovechar que los dispositivos de computacin modernos disponen de una gran cantidad de potencia de procesamiento.
26
El modelo cliente-servidor de dos capas de cliente pesado, hace uso de esa potencia de procesamiento disponible y distribuye tanto el procesamiento de la lgica de la aplicacin como la presentacin al cliente. El servidor es esencialmente un servidor de transacciones que gestiona todas las transacciones con la base de datos. Un ejemplo de este tipo de arquitectura es la de los sistemas bancarios ATM.
27
Un sistema ATM cliente-servidor

ATM
Servidor de cuentas
ATM Monitor de teleprocesa miento Base de datos de cuentas de clientes
ATM 28 ATM
Aunque el modelo de pesado distribuye el procesamiento de forma ms efectiva que un modelo de cliente ligero, la gestin del sistema es ms compleja. Cuando la aplicacin software tiene que ser modificada, se debe de realizar la reinstalacin en cada computadora cliente. (Alto costo si hay cientos de clientes en el sistema) La aparicin de cdigo mvil (applets de Java y los controles Active X), ha permitido el desarrollo de sistemas cliente-servidor que son algo intermedio entre los modelos de cliente ligero y pesado. Parte del procesamiento se realiza del lado servidor y parte del lado cliente. La interfaz de usuario se crea usando un navegador web que permite ejecutar el cdigo descargado.
29
Aunque el modelo de pesado distribuye el procesamiento de forma ms efectiva que un modelo de cliente ligero, la gestin del sistema es ms compleja. Cuando la aplicacin software tiene que ser modificada, se debe de realizar la reinstalacin en cada computadora cliente. (Alto costo si hay cientos de clientes en el sistema) La aparicin de cdigo mvil (applets de Java y los controles Active X), ha permitido el desarrollo de sistemas cliente-servidor que son algo intermedio entre los modelos de cliente ligero y pesado.
30
El problema con una aproximacin cliente-servidor de dos capas es que las tres capas lgicas (presentacin, procesamiento de la aplicacin y gestin de los datos) debe de asociarse con el cliente y el servidor, por lo que esto puede acarrear problemas de escalabilidad y rendimiento (cliente ligero) o problemas de gestin (cliente pesado). Para evitar estos problemas, una aproximacin alternativa es usar una arquitectura cliente-servidor de tres capas. En esta arquitectura, la presentacin, el procesamiento de la aplicacin y la gestin de los datos son procesos lgicamente separados que se ejecutan sobre procesos diferentes.
31
Arquitectura cliente-servidor de tres capas

Presentacin
Cliente
Servidor Procesamiento de la aplicacin
Servidor Gestin de los datos
32
Un ejemplo de una arquitectura de tres capas es un sistema bancario por internet. La base de datos de clientes (usualmente ubicada sobre un mainframe) proporciona servicios de gestin de datos; un servidor web proporciona los servicios de aplicacin tales como facilidades para transferir efectivo, generar estados de cuenta, pagar facturas, etc.; la propia computadora del usuario con un navegador de internet es el cliente. El sistema es escalable debido a que es mas sencillo agregar servidores web a la medida que crece el sistema.
33
La arquitectura de distribucin de un sistema bancario en Internet

Interaccin HTTP
Cliente
Cliente
Servidor Web Provisin del servicio de cuentas
SQL query
Servidor de bases de datos
SQL
Base de datos de cuentas de clientes
Cliente
34
Arquitectur a Arquitectura C/S de dos capas con clientes ligeros
Aplicaciones Aplicaciones de sistemas heredados en donde no es prctico separar el procesamiento de la aplicacin y la gestin de los datos. Aplicaciones que requieren clculos intensivos tales como compiladores con poca o ninguna gestin de datos.
Aplicaciones que requieran manejar una gran cantidad de datos (navegar y consultar) con poco o ningn procesamiento de la aplicacin.
Arquitectura C/S de dos capas con clientes pesados Aplicaciones en donde el procesamiento de la aplicacin se proporciona por software comercial (E.g. Ofimatica) sobre el cliente. Aplicaciones que requieren un procesamiento de datos computacionalmente intensivo (E.g. Visualizacin de datos). Aplicaciones con una funcionalidad para el usuario final relativamente estable usada en un entorno de gestin del sistema bien establecido.
35
Arquitectura
Aplicaciones
Arquitectura C/S Aplicaciones a gran escala con cientos o miles de clientes de tres capas o Aplicaciones en donde tanto los datos como la aplicacin son multicapa voltiles Aplicaciones en donde se integran datos de mltiples fuentes.
36
En el modelo cliente-servidor de un sistema distribuido, los clientes y los servidores son diferentes. Los clientes reciben servicios de los servidores y no de otros clientes; los servidores pueden actuar como clientes recibiendo servicios de otros servidores, pero sin solicitar servicios de clientes; los clientes deben conocer los servicios que ofrece cada uno de los servidores y deben conocer cmo contactar cada uno de estos servidores. Este modelo funciona bien para muchos tipos de aplicaciones. Sin embargo, limita la flexibilidad de los diseadores del sistema ya que ellos deben decidir dnde se proporciona cada servicio. Tambin deben planificar la escalabilidad y proporcionar algn medio para distribuir la carga sobre los servidores cuando ms clientes se aadan al sistema.
37
Una aproximacin ms general al diseo de sistemas distribuidos es eliminar la distincin entre cliente y servidor y disear la arquitectura del sistema como una arquitectura de objetos distribuidos. En una arquitectura de objetos distribuidos, los componentes fundamentales del sistema son objetos que proporcionan un interfaz a un conjunto de servicios que ellos suministran. Otros objetos realizan llamadas a estos servicios sin hacer una distincin lgica entre un cliente (receptor del servicio) y un servidor (proveedor del servicio).
Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Arquitecturas de objetos distribuidos
Arquitecturas de objetos distribuidos
38
o1
S(o1)
o2
S(o2)
o5 Bus software S(o3) o6 S(o4)
S(o5) S(o6) 39
o3 o4
En una arquitectura de objetos distribuidos, los objetos se distribuyen a travs de varias computadoras en una red y comunicarse a travs de middleware. Este middleware proporciona un conjunto de servicios que permiten la comunicacin entre objetos y el que estos puedan ser aadidos o eliminados del sistema.
40
Ventajas del modelo de objetos distribuidos

Los objetos que proporcionan servicios pueden ejecutarse sobre cualquier nodo de la red. No ser necesario decidir con antelacin donde ser situ la lgica de la aplicacin. Es una arquitectura muy abierta que permite aadir nuevos recursos fcilmente. (Implementacin de estndares de comunicacin entre objetos que permite escribir objetos en lenguajes de programacin distintos). Mayor flexibilidad y escalabilidad debido a que se pueden crear diferentes instancias del sistema proporcionando los mismo servicios por objetos diferentes. (segn la carga del sistema) Es posible reconfigurar el sistema de forma dinmica mediante la migracin de objetos a travs de la red.
41
En computacin, CORBA (Common Object Request Broker Architecture), arquitectura comn de intermediarios en peticiones a objetos, es un estndar que establece una plataforma de desarrollo de sistemas distribuidos facilitando la invocacin de mtodos remotos bajo un paradigma orientado a objetos. CORBA fue definido y est controlado por el Object Management Group (OMG) que define las APIs, el protocolo de comunicaciones y los mecanismos necesarios para permitir la interoperabilidad entre diferentes aplicaciones escritas en diferentes lenguajes y ejecutadas en diferentes plataformas.
42
En un sentido general, CORBA "envuelve" el cdigo escrito en otro lenguaje, en un paquete que contiene informacin adicional sobre las capacidades del cdigo que contiene y sobre cmo llamar a sus mtodos. Los objetos que resultan, pueden entonces ser invocados desde otro programa (u objeto CORBA) desde la red. CORBA utiliza un lenguaje de definicin de interfaces (IDL) para especificar las interfaces con los servicios que los objetos ofrecern. CORBA puede especificar a partir de este IDL, la interfaz a un lenguaje determinado, describiendo cmo los tipos de dato CORBA deben ser utilizados en las implementaciones del cliente y del servidor. Implementaciones estndar existen para Ada, C, C++, Smalltalk, Java, Python, Perl y Tcl.
43
Al compilar una interfaz en IDL se genera cdigo para el cliente y el servidor (el implementador del objeto). El cdigo del cliente sirve para poder realizar las llamadas a mtodos remoto. Es el conocido como stub, el cual incluye un representante del objeto remoto en el lado del cliente. El cdigo generado para el servidor consiste en unos skeletons que el desarrollador tiene que rellenar para implementar los mtodos del objeto. CORBA es ms que una especificacin multiplataforma, ya que define servicios habitualmente necesarios como seguridad y transacciones (middleware).
44
Los estndares CORBA incluyen: 1. Un modelo de objetos para objetos de aplicacin en donde un objeto CORBA es una encapsulacin de un estado con una interfaz con un lenguaje neutral y bien definido descrito en IDL (Interfaz Definition Language) 2. Un intermediario de peticiones de objetos (ORB) que gestiona peticiones para servicios de objetos. Este ORB localiza al objeto que proporciona el servicio, lo prepara para la peticin, enva la peticin de servicio y devuelve el resultado solicitante del servicio.
45
3. Un conjunto de servicios de objetos que son servicios generales que probablemente sern requeridos por muchas aplicaciones distribuidas. Ejemplo de servicios son servicios de directorio, servicios de transacciones y servicios de persistencia. 4. Un conjunto de componentes construidos sobre estos servidores bsicos que pueden ser requeridos por las aplicaciones. Pueden ser componentes verticales especficos del dominio o componentes horizontales de propsito general usados por muchas aplicaciones.
46
o1
o2
S(o1)
S(o2)
Stub IDL
Skeleton IDL
Intermediario de peticiones de objetos
Dos objetos o1 y o2 se comunican a travs de un ORB. El objeto que hace la llamada (o1) tiene un stub IDL asociado que define la interfaz del objeto que proporciona el servicio solicitado. El implementador de o1 incluye la llamada a este stub en su implementacin del objeto cuando se solicita un servicio. El objeto que proporciona el servicio tiene un skeleton IDL asociado que enlaza la interfaz con la implementacin de los servicios. En trminos simples cuando un servicio se llama a travs de la interfaz, el skeleton IDL traduce los resultados a IDL para que puedan ser accedidos por el objeto que realizo la llamada.
47
Los intermediarios de peticiones de objetos no se implementan normalmente como procesos separados, pero son un conjunto de libreras que pueden enlazarse con las implementaciones de los objetos. Por lo tanto, en un sistema distribuido, cada computadora que est ejecutando objetos distribuidos tendr su propio intermediario de peticiones de objetos. ste manejar todas las invocaciones locales de objetos.
48
o1
o2
o3 S(o3)
o4 S(o4)
S(o1)
S(o2)
Stub IDL
Skeleton IDL
Stub IDL
Skeleton IDL
Red
49
Los servicios de CORBA proveen facilidades requeridas por sistemas distribuidos. El estandar incluye diversos servicios (aprox. 15 comunes) y infinidad de servicios especficos. Algunos ejemplos de estos servicios son:
Servicio de nombres y categoras (trading): Permite a los objetos hacer referencia y encontrar a los otros objetos de la red. "Directorios de objetos".
50
Servicios de notificacin: Permiten a los objetos notificar a otros objetos que ha ocurrido algn evento. "Los objetos registran el inters en un evento especifico del servicio". Servicio de transacciones: Soporta transacciones atmicas y operaciones rollback cuando ocurre un fallo.
51
La computacin distribuida ha sido principalmente implementada a nivel organizacional. Una organizacin tiene varios servidores y distribuye la carga entre ellos. Actualmente estn disponibles modelos ms recientes de computacin distribuida que permiten computacin distribuida interorganizacional en lugar de intraorganizacional.
Arquitecturas peer-to-peer Arquitecturas de sistemas orientados a servicios
Servicios Web SOA
Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Computacin distribuida interorganizacional
52
Peer-to-Peer Los sistemas peer-to-peer (P2P) son sistemas descentralizados en los que los clculos pueden llevarse a cabo en cualquier nodo de la red y, al menos en principio no se hacen distinciones entre clientes y servidores. En las aplicaciones peer-to-peer, el sistema en su totalidad se disea para aprovechar la ventaja de la potencia computacional y disponibilidad de almacenamiento a travs de una red de computadoras enormes. Los estndares y protocolos que posibilitan las comunicaciones a travs de los nodos estn embebidos en la propia aplicacin, y cada nodo debe ejecutar una copia de dicha aplicacin.
53
n4
Arquitectura P2P
n1 n5 n8
n11 n12
n2 n3
n7 n6 n9
n10
54
P2P (Entre iguales) No tiene clientes y servidores fijos, sino una serie de nodos que se comportan a la vez como clientes y como servidores de los dems nodos de la red. Todos los nodos se comportan igual y pueden realizar el mismo tipo de operaciones. A pesar de que el P2P ha sido popularizado por el intercambio de msica por Internet, este no es el nico uso que se puede dar a esta tecnologa.
Skype SETI (Search for Extraterrestrial Intelligence Institute). RTVE emisin en directo a travs de P2P
55
Elementos de una red P2P Par: entidad capaz de desarrollar algn trabajo til y de comunicar los resultados de ese trabajo a otra entidad de la red, ya sea directa o indirectamente .
Par simple: Sirven a un nico usuario final, permitindolo proporcionar servicios desde su dispositivo y empleando los servicios ofrecidos por otros pares de la red Sper-par: Ayudan a los pares simples a que encuentre otros pares o a otros recursos de los pares Grupo de Pares: Un grupo de pares es un conjunto de pares formado para servir a un inters comn u objetivo dictado por el resto de pares implicados. Servicios: proporcionan una funcionalidad til que se consigue mediante la comunicacin de los distintos pares Servicios de pares: Funcionalidades ofrecidas por un par concreto de la red a otros pares Servicios de Grupo de pares: funcionalidades proporcionadas por varios miembros del grupo consiguiendo as acceso redundante al servicio.
56
P2P (Centralizado)
Rendimiento Elevado Coste Alto

1- cc.mp3?
Par B (bb.mp3)
2- Par C
Par C (cc.mp3)
Servidor Bbb.mp3 Ccc.mp3 Ddd.mp3
Par A (cc.mp3?)
3- cc.mp3
Conexin directa Flujo de Datos
Par D (dd.mp3)
57
P2P (Puro o totalmente descentralizado) "E.g. Gnutella"

ccc.mp3?
Par F
ccc.mp3
ccc.mp3?
Par E
ccc.mp3
Par C ccc.mp3
ccc.mp3?
Par B
ccc.mp3?
Par A ccc.mp3?
ccc.mp3
Par D
El modelo P2P puro es ms robusto al no depender de un servidor central Econmico Elevado tiempo y sobrecarga de ancho de banda. El recurso buscado y existente ni siquiera pueda ser encontrado
58
P2P (Mixto o semicentralizado)
Par A (cc.mp3?)
(cc.mp3?) cc.mp3->Z (cc.mp3?)
Superpar Z cc.mp3
Par Z (cc.mp3)
cc.mp3->Z
Red Escalable Reduccin del nmero de nodos involucrados en el encaminamiento Buen tiempo de respuesta
59
La bsqueda de informacin (pares, contenidos y servicios), dada la ausencia de un conocimiento global de los datos y recursos involucrados, es un aspecto fundamental en entornos P2P
Bsqueda en cach: Cada par mantiene una cach de recursos previamente descubiertos. Bsqueda directa: Pregunta directamente a otros pares de la red con los que tenga conexin directa (Arquitectura P2P pura) Bsqueda indirecta: Los superpares actan como fuente de informacin de localizacin de pares y otros recursos conocidos. Adems esos hacen la bsqueda en nombre del par (Arquitectura P2P mixta).
60
Caractersticas de las arquitecturas P2P

Descentralizacin Escalabilidad Anonimato Propiedad compartida Rendimiento Seguridad Tolerancia a Fallos Interoperabilidad
61
JXTA (Juxtapose) es una plataforma peer-to-peer open source creada por Sun Microsystems en el ao 2001. Esta plataforma esta definida como un conjunto de protocolos basados en XML. Dichos protocolos permiten que dispositivos conectados a una red intercambien mensajes entre s. JXTA es el framework P2P ms maduro que actualmente existe. Adems, fue diseado para permitir que un amplio rango de dispositivos (computadoras, telfonos mviles, PDAs) se comuniquen de forma descentralizada. Como JXTA est basado en una serie de protocolos abiertos, en teora, puede ser portado a cualquier lenguaje moderno de computacin. Actualmente, la implementacin de JXTA de Java es la ms avanzada. Existen versiones para C y C++, JXTA-C y JXTA-C++ respectivamente.
62
JXTA crea una red virtual que permite a los peers interactuar entre s, aun cuando algunos de ellos estn detrs de firewalls, NATs o usen distintos transportes de red. Adems, cada peer es identificado por un ID nico, un URN SHA-1 de 160 bits en la implementacin de Java, permitiendo que los peers puedan cambiar su direccin pero conservar su nmero de identificacin. Los servicios JXTA pueden ser implementados para interoperar con otros servicios. Por ejemplo, un servicio de comunicacin P2P de mensajera instantnea puede ser fcilmente agregado a una aplicacin P2P de comparticin de ficheros si es que ambos soportan protocolos JXTA. La forma de funcionamiento se basa en un conjunto de protocolos P2P simples y abiertos que permiten que cualquier dispositivo de red se comunique, colabore y comparta recursos.
63
Arquitecturas de sistemas orientado a servicios El desarrollo de la WWW trajo consigo que las computadoras cliente tuviesen acceso a los servidores remotos situados fuera de sus propias organizaciones. Es claro que si las organizaciones convierten su informacin a HTML, entonces sta podr ser accedida por estas computadoras. Sin embargo el acceso solo a travs de un navegador web no es prctico.
64
Servicio web Un servicio Web (Web service) es una coleccin de protocolos y estndares que sirven para intercambiar datos entre aplicaciones. Mediante la nocin de un servicio web, las organizaciones que requieren hacer accesible la informacin a otros programas, pueden hacerlo definiendo y publicando un interfaz de servicio web. Esta interfaz define los datos disponibles y como se puede acceder a ellos i.e. un servicio web es una representacin estndar para cualquier recurso computacional o de informacin que pueda ser usado por otros programas.
La principal razn para usar servicios Web es que se basan en HTTP sobre TCP en el puerto 80. Buena interfaz para acceder a servicios y funcionalidades de otros ordenadores en la red. Gran independencia y flexibilidad entre aplicacin y servicio.
65
Arquitectura conceptual de un sistema orientado a servicios

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

Los servicios podrn ofertarse por cualquier proveedor de servicio (con base en estndares) dentro o fuera de una organizacin, las organizaciones pueden crear aplicaciones integrando servicios desde varios proveedores.
E.g.
Una compaa de fabricacin puede enlazar directamente a los servicios proporcionado por sus proveedores. Una compaa de logstica puede enlazarse con servicios de geolocalizacin y comunicacines. Sistemas de banca electrnica
68
El proveedor del servicio hace pblica la informacin sobre el servicio para que cualquier usuario autorizado pueda usarlo. El proveedor de servicios y el usuario de los servicios no necesitan negociar sobre lo que el servicio hace antes de ser incorporado en un programa de aplicacin. Las aplicaciones pueden retrasar el enlace de los servicios hasta que stas sean desplegadas o hasta que estn en ejecucin.
i.e. una aplicacin podra cambiar dinmicamente los proveedores de los servicios mientras el servicio se este ejecutando.
69
El es posible la construccin oportunista de nuevos servicios. Un proveedor de servicios puede reconocer nuevos servicios que se crean enlazando servicios existentes de formas innovadoras. Los usuarios de los servicios pueden pagar por los servicios con arreglo a su uso en vez de a su provisin. Por lo que en lugar de comprar un componente de precio elevado que se usa raramente, el desarrollador de la aplicacin puede usar un servicio externo por el que pagar solamente cuando sea requerido.
70
Las aplicaciones pueden hacerse mas pequeas debido a que pueden implementar el manejo de excepciones como servicios externos. Las aplicaciones pueden ser reactivas y adaptar su operacin de acuerdo con su entorno enlazando con diferentes servicios a medida que cambia este.
71
Los tres estndares fundamentales que permiten la comunicacin entre servicios web son:
SOAP (Simple Object Access Protocol). Este protocolo define una organizacin para intercambio de datos estructurados entre servicios web. WSDL (Web Services Description Languaje). Este protocolo define cmo pueden representarse las interfaces de los servicios web. UDDI (Universal Descripcin, Discovery and Integratin). ste es un estndar de bsqueda que define como puede organizarse la informacin de descripcin de servicios, usada por los solicitantes de los servicios para encontrar servicios.
*Todos los estndares se basan en XML generalmente.
72
Las arquitecturas de aplicaciones de servicios web son arquitecturas dbilmente acopladas en donde el enlace a los servicios puede cambiar durante la ejecucin. Algunos sistemas se construirn solamente usando servicios web y otras mezclaran servicios web desarrollados localmente.
73
Ventajas de los servicios web

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

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

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

A ms tardar se debe entregar el da Domingo 17 de Octubre de 2010 a las 23:59:59 hrs. Incluir portada. Recomendacin: Usar Cmap Tools
Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Tarea 04
Tarea 04
80

14 15-16-17 Arquitecturas de Sistemas Distribuidos y Tarea 04

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

14 15-16-17 Arquitecturas de Sistemas Distribuidos y Tarea 04

Caricato da

Copyright:

Formati disponibili

14, 15, 16 y 17 Arquitecturas de sistemas distribuidos y Tarea 04

Computacin distribuida interorganizacional

Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Contenido

Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Introduccin

Comparticin de recursos Apertura Concurrencia Escalabilidad Tolerancia a defectos

Ventajas del uso de una aproximacin distribuida

Ventajas del uso de una aproximacin distribuida

Ventajas del uso de una aproximacin distribuida

Ventajas del uso de una aproximacin distribuida

Ventajas del uso de una aproximacin distribuida

Ventajas del uso de una aproximacin distribuida

Ventajas del uso de una aproximacin distribuida

Desventajas del uso de una aproximacin distribuida

Desventajas del uso de una aproximacin distribuida

Desventajas del uso de una aproximacin distribuida

Desventajas del uso de una aproximacin distribuida

Desventajas del uso de una aproximacin distribuida

Reto al disear un sistema distribuido

Procesador de sensores Proceso de control de sensores

Procesador de flujo de trafico Proceso de vizualizado

Procesador de control de semforos Proceso de control de luces

Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Arquitecturas cliente-servidor

Un sistema cliente servidor

Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Arquitecturas cliente-servidor

Capa de procesamiento de la aplicacin 21 Capa de gestin de datos

Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Arquitecturas cliente-servidor

Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Arquitecturas cliente-servidor

Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Arquitecturas cliente-servidor

Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Arquitecturas cliente-servidor

Modelo de cliente ligero

Servidor Gestin de datos Procesamiento de la aplicacin

Modelo de cliente pesado

Presentacin Procesamiento de la aplicacin

Servidor Gestin de datos

Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Arquitecturas cliente-servidor

Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Arquitecturas cliente-servidor

Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Arquitecturas cliente-servidor

Un sistema ATM cliente-servidor

Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Arquitecturas cliente-servidor

Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Arquitecturas cliente-servidor

Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Arquitecturas cliente-servidor

Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Arquitecturas cliente-servidor

Arquitectura cliente-servidor de tres capas

Servidor Procesamiento de la aplicacin

Servidor Gestin de los datos

Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Arquitecturas cliente-servidor

Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Arquitecturas cliente-servidor

La arquitectura de distribucin de un sistema bancario en Internet

Servidor Web Provisin del servicio de cuentas

Servidor de bases de datos

Base de datos de cuentas de clientes

Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Arquitecturas cliente-servidor

Arquitectur a Arquitectura C/S de dos capas con clientes ligeros

Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Arquitecturas cliente-servidor

Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Arquitecturas cliente-servidor

Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Arquitecturas cliente-servidor

Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Arquitecturas de objetos distribuidos

Arquitecturas de objetos distribuidos

o5 Bus software S(o3) o6 S(o4)

Arquitecturas de objetos distribuidos

Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Arquitecturas de objetos distribuidos

Sistemas operativos II 14 , 15, 16 y 17 Arquitecturas de sistemas distribuidos Arquitecturas de objetos distribuidos

Arquitecturas de objetos distribuidos

Ventajas del modelo de objetos distribuidos