Post on 16-Apr-2015
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 1
UPV - EHU
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
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 2
UPV - EHU
Arquitecturas para sistemas ubicuos
Interfaces
Tecnologías de red y dispositivos
Infraestructuras
Entornos inteligentes
Arquitecturas
Aplicaciones
Seg
urid
ad e
inte
grid
ad
Asp
ecto
s ét
icos
y s
ocia
les
Her
ram
ient
as y
pla
tafo
rmas
Met
odol
ogía
s
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 3
UPV - EHU
Arquitecturas para sistemas ubicuos
1. Infraestructura soporte2. Modelo de entorno ubicuo3. Arquitectura de un sistema ubicuo4. Integración de servicios heterogéneos
UPV - EHU Infraestructura soporte
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 5
UPV - EHU
Arquitecturas Middleware
Hardware
Sistema operativo
Middleware
Aplicación Aplicación
¿cómo se reparten las
funciones?
¿compatibilidad?
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 6
UPV - EHU
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.
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 7
UPV - EHU
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.
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 8
UPV - EHU
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
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 9
UPV - EHU
Sistemaoperativo (espacio
del kernel)
Aplicaciones(espacio
de usuario)
Espaciodel kernel
Espaciode usuario
SO clásico Micronúcleo
Micronúcleo
EmuladorPOSIX
EmuladorSystem V
OtroEmulador
Hw
Compatibilidad: micronúcleos
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 10
UPV - EHU
Compatibilidad: emulación (cont)
Emulación Software
Hw
SO anfitrión
EmuladorAPI
Aplicaciónemulada
Aplicaciónnativa
Emulación Hardware
Hw
SO anfitrión
Hwemulado
SOhuesped
Aplicaciónnativa
Aplicaciónemulada
Virtualización
SOhuesped
Aplicaciónemulada
Hw
SO anfitrión
Hwemulado
Aplicaciónnativa
UPV - EHU Modelo de entorno
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 12
UPV - EHU
Modelo de entorno para sistemas ubicuos
Recursoso 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?
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 13
UPV - EHU
Modelo de entorno para sistemas ubicuos: ejemplo
UPV - EHU Arquitectura de un sistema ubicuo
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 15
UPV - EHU
Arquitecturas Middleware para sistemas ubicuos
Hardware
Sistema operativo
Middleware
Aplicación Aplicación
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 16
UPV - EHU
Arquitecturas Middleware para sistemas ubicuos. Ejemplos.
Gaia Active Spaces
(Roman, 2002)
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 17
UPV - EHU
Arquitecturas Middleware para sistemas ubicuos. Ejemplos.
Aura
(Garlan, 2002)
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 18
UPV - EHU
Arquitecturas Middleware para sistemas ubicuos. Ejemplos.
Arquitectura Jini
SPARC
SolarisSolaris
Java
PowerPC
SolarisMac
Java
x86
Windows
Java
RMI
Discovery/Join
Lookup
Applications JavaSpaces Other services
Jini
Network services
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 19
UPV - EHU
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
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 20
UPV - EHU
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
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 21
UPV - EHU
Arquitectura de un sistema ubicuo Dos enfoques
1. Estructura del mecanismo de descubrimiento
2. Reparto de funciones entre los elementos del entorno
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 22
UPV - EHU
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
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 23
UPV - EHU
Arquitecturas para el descubrimiento de servicios:Arquitectura en dos partes
• Un SM se da a conocer mediante multicast.
SUSUSUSUSMSMSMSM
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 24
UPV - EHU
Arquitecturas para el descubrimiento de servicios:Arquitectura en dos partes
• Un SU descubre servicios mediante multicast.
SUSUSUSUSMSMSMSM
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 25
UPV - EHU
Arquitecturas para el descubrimiento de servicios:Arquitectura en dos partes
• El SU obtiene el SD.
SUSUSUSUSMSMSMSM
• El SU accede al servicio.
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 26
UPV - EHU
Arquitecturas para el descubrimiento de servicios:Arquitectura en tres partes
• SCM: Service Cache Manager. Proporciona persistencia
SUSUSUSUSMSMSMSM
SCMSCMSCMSCM
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 27
UPV - EHU
Arquitecturas para el descubrimiento de servicios:Arquitectura en tres partes
• Los servicios se registran en los SCMs.
SUSUSU SMSMSMSM
SCMSCMSCM
SU
SCM
• Los SU descubren los servicios registrados.
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 28
UPV - EHU
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
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 29
UPV - EHU
• 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
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 30
UPV - EHU
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.
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 31
UPV - EHU
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)
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 32
UPV - EHU
Arquitecturas para sistemas ubicuos
(3 partes)
• Dependiendo de dónde se ubique el SCM, varias combinaciones (Salvador et al, 2005):
UPV - EHU Integración de servicios heterogéneos
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 34
UPV - EHU
Integración de servicios
• Dispositivos heterogéneos• Muchos protocolos • ¿Cómo integrarlos?• ¿Cómo ofrecer una interfaz común a las
aplicaciones?
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 35
UPV - EHU
Integración de serviciosEnfoques
• 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
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 36
UPV - EHU
X10resource
X10resource
Power line
•Jini Service 1•Jini Service 2•UPnP Gateway 1•UPNP Gateway 2•X10 Gateway•EIB Gateway
EIBresource
EIBresource
EIB bus
UPnPresource 1
UPnPresource 2
UPnPGateway
2
EIBGateway
JiniService 2
JiniService 1
LUS
JiniClient
UPnPGateway factory
OtherGateway factories
X10Gateway factory
EIBGateway factory
UPnPControl point
Gateway creation
UPnP commands
Service invocationDiscovery / Registry
Discovery / Registry
UPnPGateway
1
X10Gateway
JiniClient
JiniClient
Integración de serviciosJini como plataforma base
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 37
UPV - EHU
Integración de serviciosOSGi
• 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.
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 38
UPV - EHU
Integración de serviciosOSGi: registro y descubrimiento
Registro y descubrimiento de servicios en OSGi. Tomado de (Lee, 2003)
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 39
UPV - EHU
Integración de serviciosOSGi: un ejemplo
Ejemplo “Hello World”, tomado de (Lee, 2003).(a) Definición de la interfaz, (b) implementación del servicio
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 40
UPV - EHU
Integración de serviciosOSGi: un ejemplo (cont)
Ejemplo “Hello World”, tomado de (Lee, 2003).(c) Registro del servicio.
Konputagailuen Arkitektura eta Teknologia SailaDepartamento de Arquitectura y Tecnología de Computadores 41
UPV - EHU
Integración de serviciosOSGi: un ejemplo (cont)
Ejemplo “Hello World”, tomado de (Lee, 2003).(d) Descubrimiento e invocación.