La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 1 Sistemas Ubicuos (Parte I) 2. Arquitecturas.

Presentaciones similares


Presentación del tema: "UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 1 Sistemas Ubicuos (Parte I) 2. Arquitecturas."— Transcripción de la presentación:

1 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 1 Sistemas Ubicuos (Parte I) 2. Arquitecturas para sistemas ubicuos Departamento de Arquitectura y Tecnología de Computadores Universidad del País Vasco / Euskal Herriko Unibertsitatea Programa de Tercer Ciclo

2 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 2 Arquitecturas para sistemas ubicuos Interfaces Tecnologías de red y dispositivos Infraestructuras Entornos inteligentes Arquitecturas Aplicaciones Seguridad e integridad Aspectos éticos y sociales Herramientas y plataformas Metodologías

3 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 3 Arquitecturas para sistemas ubicuos 1.Infraestructura soporte 2.Modelo de entorno ubicuo 3.Arquitectura de un sistema ubicuo 4.Integración de servicios heterogéneos

4 UPV - EHU Infraestructura soporte

5 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 5 Arquitecturas Middleware Hardware Sistema operativo Middleware Aplicación ¿cómo se reparten las funciones? ¿compatibilidad?

6 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 6 Reparto de funciones: SO vs Mw Modificar el SO es laborioso y cuesta alcanzar versiones estables. Trasladar la funcionalidad al Mw es más sencillo pero ofrece peor rendimiento. –Ejemplo: Gaia, Aura, Sistemas basados en Jini- Java. Micronúcleos: sólo el soporte básico (cambio de contexto, interrupciones...) en el espacio del núcleo; el resto de funciones, como cliente-servidor en espacio de usuario. –Ejemplos: Plan 9 / Plan B.

7 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 7 Compatibilidad Sistemas heterogéneos: –¿cómo conseguir que las aplicaciones puedan migrar entre plataformas (Hw o SO) diferentes? Soluciones: –Disponer de versiones de las aplicaciones para cada plataforma. –Utilizar una plataforma Mw común (ej: Java). –Utilizar emuladores para homogeneizar plataformas.

8 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 8 Compatibilidad: emulación Emulación software –Se interceptan los traps de las llamadas al sistema del SO emulado y se interpretan en el SO anfitrión. –Ejemplo: Wine. Emulación hardware –Se emula el entorno Hw completo. –Ejemplo: BOCHS Virtualización –Emulación Hw de lo estrictamente necesario: Llamadas al sistema Acceso a los dispositivos –El resto de las IM se ejecutan nativamente –Requiere análisis del código –Ejemplos: VMware, VirtualPC, Win4Lin

9 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 9 Sistema operativo (espacio del kernel) Aplicaciones (espacio de usuario) Espacio del kernel Espacio de usuario SO clásicoMicronúcleo Emulador POSIX Emulador System V Otro Emulador Hw Compatibilidad: micronúcleos

10 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 10 Compatibilidad: emulación (cont) Emulación Software Hw SO anfitrión Emulador API Aplicación emulada Aplicación nativa Emulación Hardware Hw SO anfitrión Hw emulado SO huesped Aplicación nativa Aplicación emulada Virtualización SO huesped Aplicación emulada Hw SO anfitrión Hw emulado Aplicación nativa

11 UPV - EHU Modelo de entorno

12 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 12 Modelo de entorno para sistemas ubicuos Recursos o servicios Dispositivos de acceso Electrodomésticos, iluminación, proyector... Mando, PDA, teléfono... Medio de acceso WiFi, Bluetooth, Infrarrojos, GPRS... Servidores PC, dispositivos específicos... Infraestructura de comunicación Power line, ethernet... ¿Explícito o implícito?

13 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 13 Modelo de entorno para sistemas ubicuos: ejemplo

14 UPV - EHU Arquitectura de un sistema ubicuo

15 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 15 Arquitecturas Middleware para sistemas ubicuos Hardware Sistema operativo Middleware Aplicación

16 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 16 Arquitecturas Middleware para sistemas ubicuos. Ejemplos. Gaia Active Spaces (Roman, 2002)

17 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 17 Arquitecturas Middleware para sistemas ubicuos. Ejemplos. Aura (Garlan, 2002)

18 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 18 Arquitecturas Middleware para sistemas ubicuos. Ejemplos. Arquitectura Jini SPARC Solaris Java PowerPC SolarisMac Java x86 Windows Java RMI Discovery/Join Lookup Applications JavaSpaces Other services Jini Network services

19 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 19 Arquitectura de un sistema ubicuo Los recursos son de naturaleza dinámica –Pueden estar disponibles o no. –Pueden estar en el radio de acción del usuario o no. –El usuario cambia de entorno y las aplicaciones descubren nuevos dispositivos. –La aplicación debe adaptarse en tiempo de ejecución (no se instalan drivers explícitamente). Se requieren mecanismos de –Publicación o registro de recursos y servicios. –Descubrimiento de esos servicios por las aplicaciones. –Control de acceso, seguridad, privacidad... Se requieren estándares (Jini, UPnP, Salutation) Los recursos pueden ser heterogéneos Integración

20 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 20 Arquitectura de un sistema ubicuo Aspectos básicos a considerar en un entorno con recursos no heterogéneos: –Cómo se gestiona el estado de los recursos Grado de persistencia –Características de los dispositivos de acceso (determinan su funcionalidad) Tamaño Capacidad de cómputo y almacenamiento Capacidad de comunicación Consumo de energía –Características de los usuarios Categorías, con diferentes derechos de acceso Autenticación

21 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 21 Arquitectura de un sistema ubicuo Dos enfoques 1.Estructura del mecanismo de descubrimiento 2.Reparto de funciones entre los elementos del entorno

22 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 22 Arquitecturas para el descubrimiento de servicios (Dabrowski & Mills, 2002) Componentes básicos: –Cliente: Service User (SU) –Servidor: Service Manager (SM) Esquemas de comunicación: –Multicast –Unicast Descripciones del servicio (SD): –Identificación –Tipo –Atributos –Interfaz del servicio –Interfaz de usuario

23 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 23 Arquitecturas para el descubrimiento de servicios: Arquitectura en dos partes Un SM se da a conocer mediante multicast. SU SM

24 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 24 Arquitecturas para el descubrimiento de servicios: Arquitectura en dos partes Un SU descubre servicios mediante multicast. SU SM

25 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 25 Arquitecturas para el descubrimiento de servicios: Arquitectura en dos partes El SU obtiene el SD. SU SM El SU accede al servicio.

26 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 26 Arquitecturas para el descubrimiento de servicios: Arquitectura en tres partes SCM: Service Cache Manager. Proporciona persistencia SU SM SCM

27 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 27 Arquitecturas para el descubrimiento de servicios: Arquitectura en tres partes Los servicios se registran en los SCMs. SU SM SCM SU SCM Los SU descubren los servicios registrados.

28 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 28 Reparto de funciones Dónde ubicar... –El SU –El SCM –La gestión de usuarios Alternativas: –Utilizar servidores específicos o no –Centralizado vs distribuido –Replicación de servicios

29 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 29 Un usuario utiliza su dispositivo de acceso que le autoidentifica para acceder a los servicios de un entorno ubicuo. –El dispositivo es de uso personal (tipo tab: quien posee el dispositivo está autorizado para usarlo). –El dispositivo descubre los servicios que ofrece el entorno. –El usuario puede operar con los dispositivos descubiertos de acuerdo a sus derechos de acceso sobre ellos, codificados en su dispositivo de acceso. Arquitecturas para sistemas ubicuos Ejemplo 1

30 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 30 Arquitecturas para sistemas ubicuos Ejemplo 2 Un usuario utiliza un dispositivo de acceso para acceder a los servicios de un entorno ubicuo. –El dispositivo es de uso común (tipo pad). –Un servidor dedicado descubre los servicios que ofrece el entorno. –El servidor autentica al usuario. –El usuario puede operar con los dispositivos descubiertos de acuerdo a sus derechos de acceso sobre ellos, almacenados en el servidor.

31 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 31 Arquitecturas para sistemas ubicuos (2 partes) Dependiendo de dónde se ubique el SU y las funciones de gestión de usuario: –en el dispositivo de acceso: personal-server architecture (ejemplo 1) –en un servidor dedicado: dedicated-server architecture (ejemplo 2)

32 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 32 Arquitecturas para sistemas ubicuos (3 partes) Dependiendo de dónde se ubique el SCM, varias combinaciones (Salvador et al, 2005) :

33 UPV - EHU Integración de servicios heterogéneos

34 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 34 Integración de servicios Dispositivos heterogéneos Muchos protocolos ¿Cómo integrarlos? ¿Cómo ofrecer una interfaz común a las aplicaciones?

35 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 35 Integración de servicios Enfoques Soluciones ad-hoc –Pasarelas específicas entre protocolos. –Hay que integrar específicamente cada dispositivo. Plataforma común –Todos los servicios se representan bajo una interfaz específica lo suficientemente general (p. ej., JINI). Un marco estándar de especificación lo más universal posible –OSGi

36 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 36 X10 resource X10 resource Power line Jini Service 1 Jini Service 2 UPnP Gateway 1 UPNP Gateway 2 X10 Gateway EIB Gateway EIB resource EIB resource EIB bus UPnP resource 1 UPnP resource 2 UPnP Gateway 2 EIB Gateway Jini Service 2 Jini Service 1 LUS Jini Client UPnP Gateway factory Other Gateway factories X10 Gateway factory EIB Gateway factory UPnP Control point Gateway creation UPnP commands Service invocationDiscovery / Registry UPnP Gateway 1 X10 Gateway Jini Client Jini Client Integración de servicios Jini como plataforma base

37 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 37 Integración de servicios OSGi Open Services Gateway Initiative (1999). Orientado a entornos domésticos. Arquitectura centralizada. Proporciona soporte para instalar dinámicamente servicios Java (bundles) –La implementación de los bundles compete a los desarrolladores del sistema –Los desarrolladores de aplicaciones se limitan a especificar interfaces.

38 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 38 Integración de servicios OSGi: registro y descubrimiento Registro y descubrimiento de servicios en OSGi. Tomado de (Lee, 2003)

39 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 39 Integración de servicios OSGi: un ejemplo Ejemplo Hello World, tomado de (Lee, 2003). (a)Definición de la interfaz, (b) implementación del servicio

40 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 40 Integración de servicios OSGi: un ejemplo (cont) Ejemplo Hello World, tomado de (Lee, 2003). (c) Registro del servicio.

41 UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 41 Integración de servicios OSGi: un ejemplo (cont) Ejemplo Hello World, tomado de (Lee, 2003). (d) Descubrimiento e invocación.


Descargar ppt "UPV - EHU Konputagailuen Arkitektura eta Teknologia Saila Departamento de Arquitectura y Tecnología de Computadores 1 Sistemas Ubicuos (Parte I) 2. Arquitecturas."

Presentaciones similares


Anuncios Google