Transcript Arquitectura de un sistema ubicuo

Programa de Tercer Ciclo
Departamento de Arquitectura y Tecnología de
Computadores
Universidad del País Vasco / Euskal Herriko Unibertsitatea
UPV - EHU
Sistemas Ubicuos
(Parte I)
2. Arquitecturas para
sistemas ubicuos
Konputagailuen Arkitektura eta Teknologia Saila
Departamento de Arquitectura y Tecnología de Computadores
1
Konputagailuen Arkitektura eta Teknologia Saila
Departamento de Arquitectura y Tecnología de Computadores
Interfaces
Entornos
inteligentes
Arquitecturas
Infraestructuras
Tecnologías de red
y dispositivos
Aspectos éticos y sociales
Aplicaciones
Seguridad e integridad
Metodologías
UPV - EHU
Herramientas y plataformas
Arquitecturas para sistemas
ubicuos
2
Arquitecturas para sistemas
ubicuos
UPV - EHU
1.
2.
3.
4.
Infraestructura soporte
Modelo de entorno ubicuo
Arquitectura de un sistema ubicuo
Integración de servicios heterogéneos
Konputagailuen Arkitektura eta Teknologia Saila
Departamento de Arquitectura y Tecnología de Computadores
3
UPV - EHU
Infraestructura soporte
Arquitecturas Middleware
Aplicación
Aplicación
UPV - EHU
¿cómo se
reparten las
funciones?
Middleware
¿compatibilidad?
Sistema operativo
Hardware
Konputagailuen Arkitektura eta Teknologia Saila
Departamento de Arquitectura y Tecnología de Computadores
5
Reparto de funciones:
SO vs Mw
UPV - EHU
• 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 JiniJava.
• 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 Saila
Departamento de Arquitectura y Tecnología de Computadores
6
Compatibilidad
• Sistemas heterogéneos:
UPV - EHU
– ¿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 Saila
Departamento de Arquitectura y Tecnología de Computadores
7
Compatibilidad: emulación
• Emulación software
UPV - EHU
– 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 Saila
Departamento de Arquitectura y Tecnología de Computadores
8
Compatibilidad: micronúcleos
UPV - EHU
SO clásico
Micronúcleo
Aplicaciones
(espacio
de usuario)
Sistema
operativo
(espacio
del kernel)
Espacio
de usuario
Emulador
System V
Emulador
POSIX
Micronúcleo
Otro
Emulador
Espacio
del kernel
Hw
Konputagailuen Arkitektura eta Teknologia Saila
Departamento de Arquitectura y Tecnología de Computadores
9
Compatibilidad: emulación (cont)
Aplicación
emulada
Emulador Aplicación
API
nativa
Aplicación
emulada
SO
huesped
Hw
Aplicación
emulado
nativa
SO anfitrión
SO anfitrión
Hw
Hw
Emulación Software
Emulación Hardware
UPV - EHU
Konputagailuen Arkitektura eta Teknologia Saila
Departamento de Arquitectura y Tecnología de Computadores
Aplicación
emulada
SO
huesped
Hw
Aplicación
emulado
nativa
SO anfitrión
Hw
Virtualización
10
UPV - EHU
Modelo de entorno
Modelo de entorno para
sistemas ubicuos
UPV - EHU
Recursos
o servicios
Electrodomésticos,
iluminación,
proyector...
Medio de acceso
WiFi, Bluetooth,
Infrarrojos, GPRS...
Dispositivos de
acceso
Mando, PDA,
teléfono...
Servidores
PC, dispositivos
específicos...
Infraestructura
de comunicación
Power line,
ethernet...
Konputagailuen Arkitektura eta Teknologia Saila
Departamento de Arquitectura y Tecnología de Computadores
¿Explícito o
implícito?
12
Modelo de entorno para sistemas
ubicuos: ejemplo
UPV - EHU
Konputagailuen Arkitektura eta Teknologia Saila
Departamento de Arquitectura y Tecnología de Computadores
13
UPV - EHU
Arquitectura de un sistema
ubicuo
Arquitecturas Middleware para
sistemas ubicuos
Aplicación
Aplicación
UPV - EHU
Middleware
Sistema operativo
Hardware
Konputagailuen Arkitektura eta Teknologia Saila
Departamento de Arquitectura y Tecnología de Computadores
15
Arquitecturas Middleware para
sistemas ubicuos. Ejemplos.
UPV - EHU
Gaia Active Spaces
(Roman, 2002)
Konputagailuen Arkitektura eta Teknologia Saila
Departamento de Arquitectura y Tecnología de Computadores
16
Arquitecturas Middleware para
sistemas ubicuos. Ejemplos.
UPV - EHU
Aura
(Garlan, 2002)
Konputagailuen Arkitektura eta Teknologia Saila
Departamento de Arquitectura y Tecnología de Computadores
17
Arquitecturas Middleware para
sistemas ubicuos. Ejemplos.
Applications
JavaSpaces
Other services
Lookup
UPV - EHU
Network
services
Jini
Discovery/Join
RMI
Java
Java
Java
Solaris
Solaris
Mac
Windows
SPARC
PowerPC
x86
Arquitectura Jini
Konputagailuen Arkitektura eta Teknologia Saila
Departamento de Arquitectura y Tecnología de Computadores
18
Arquitectura de un sistema ubicuo
• Los recursos son de naturaleza dinámica
UPV - EHU
– 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 Saila
Departamento de Arquitectura y Tecnología de Computadores
19
Arquitectura de un sistema ubicuo
• Aspectos básicos a considerar en un
entorno con recursos no heterogéneos:
UPV - EHU
– 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 Saila
Departamento de Arquitectura y Tecnología de Computadores
20
Arquitectura de un sistema ubicuo
Dos enfoques
UPV - EHU
1. Estructura del mecanismo de
descubrimiento
2. Reparto de funciones entre los elementos
del entorno
Konputagailuen Arkitektura eta Teknologia Saila
Departamento de Arquitectura y Tecnología de Computadores
21
Arquitecturas para el
descubrimiento de servicios
(Dabrowski & Mills, 2002)
• Componentes básicos:
UPV - EHU
– 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 Saila
Departamento de Arquitectura y Tecnología de Computadores
22
Arquitecturas para el
descubrimiento de servicios:
Arquitectura en dos partes
UPV - EHU
SU
SU
SU
SU
SM
SM
SM
SM
• Un SM se da a conocer mediante multicast.
Konputagailuen Arkitektura eta Teknologia Saila
Departamento de Arquitectura y Tecnología de Computadores
23
Arquitecturas para el
descubrimiento de servicios:
Arquitectura en dos partes
UPV - EHU
SU
SU
SU
SU
SM
SM
SM
SM
• Un SU descubre servicios mediante
multicast.
Konputagailuen Arkitektura eta Teknologia Saila
Departamento de Arquitectura y Tecnología de Computadores
24
Arquitecturas para el
descubrimiento de servicios:
Arquitectura en dos partes
UPV - EHU
SU
SU
SU
SU
SM
SM
SM
SM
• El SU obtiene el SD.
• El SU accede al servicio.
Konputagailuen Arkitektura eta Teknologia Saila
Departamento de Arquitectura y Tecnología de Computadores
25
Arquitecturas para el
descubrimiento de servicios:
Arquitectura en tres partes
UPV - EHU
SU
SU
SU
SU
SM
SM
SM
SM
SCM
SCM
SCM
SCM
• SCM: Service Cache Manager. Proporciona
persistencia
Konputagailuen Arkitektura eta Teknologia Saila
Departamento de Arquitectura y Tecnología de Computadores
26
Arquitecturas para el
descubrimiento de servicios:
Arquitectura en tres partes
UPV - EHU
SU
SU
SU
SU
SM
SM
SM
SM
SCM
SCM
SCM
SCM
• Los servicios se registran en los SCMs.
• Los SU descubren los servicios registrados.
Konputagailuen Arkitektura eta Teknologia Saila
Departamento de Arquitectura y Tecnología de Computadores
27
Reparto de funciones
• Dónde ubicar...
UPV - EHU
– 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 Saila
Departamento de Arquitectura y Tecnología de Computadores
28
Arquitecturas para sistemas
ubicuos
Ejemplo 1
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.
Konputagailuen Arkitektura eta Teknologia Saila
Departamento de Arquitectura y Tecnología de Computadores
29
Arquitecturas para sistemas
ubicuos
Ejemplo 2
UPV - EHU
• 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 Saila
Departamento de Arquitectura y Tecnología de Computadores
30
Arquitecturas para sistemas
ubicuos
(2 partes)
UPV - EHU
• 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 Saila
Departamento de Arquitectura y Tecnología de Computadores
31
Arquitecturas para sistemas
ubicuos
(3 partes)
UPV - EHU
• Dependiendo de dónde se ubique el SCM,
varias combinaciones (Salvador et al, 2005):
Konputagailuen Arkitektura eta Teknologia Saila
Departamento de Arquitectura y Tecnología de Computadores
32
UPV - EHU
Integración de servicios
heterogéneos
Integración de servicios
UPV - EHU
•
•
•
•
Dispositivos heterogéneos
Muchos protocolos
¿Cómo integrarlos?
¿Cómo ofrecer una interfaz común a las
aplicaciones?
Konputagailuen Arkitektura eta Teknologia Saila
Departamento de Arquitectura y Tecnología de Computadores
34
Integración de servicios
Enfoques
• Soluciones ad-hoc
UPV - EHU
– 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 Saila
Departamento de Arquitectura y Tecnología de Computadores
35
Integración de servicios
Jini como plataforma base
LUS
UPV - EHU
•Jini Service 1
•Jini Service 2
•UPnP Gateway 1
•UPNP Gateway 2
•X10 Gateway
•EIB Gateway
Jini
Client
Jini
Client
Jini
Client
Discovery / Registry
Service invocation
UPnP
Gateway
1
UPnP
Gateway
2
X10
Gateway
EIB
Gateway
Jini
Service 1
Jini
Service 2
Gateway creation
UPnP
Gateway factory
UPnP
Control point
X10
Gateway factory
EIB
Gateway factory
Other
Gateway factories
UPnP
commands
Discovery / Registry
EIB bus
Power line
UPnP
resource 1
UPnP
resource 2
Konputagailuen Arkitektura eta Teknologia Saila
Departamento de Arquitectura y Tecnología de Computadores
X10
resource
X10
resource
EIB
resource
EIB
resource
36
Integración de servicios
OSGi
UPV - EHU
•
•
•
•
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 Saila
Departamento de Arquitectura y Tecnología de Computadores
37
Integración de servicios
OSGi: registro y descubrimiento
UPV - EHU
Registro y descubrimiento de servicios en OSGi. Tomado de (Lee, 2003)
Konputagailuen Arkitektura eta Teknologia Saila
Departamento de Arquitectura y Tecnología de Computadores
38
Integración de servicios
OSGi: un ejemplo
UPV - EHU
Ejemplo “Hello World”, tomado de (Lee, 2003).
(a) Definición de la interfaz, (b) implementación del servicio
Konputagailuen Arkitektura eta Teknologia Saila
Departamento de Arquitectura y Tecnología de Computadores
39
Integración de servicios
OSGi: un ejemplo (cont)
UPV - EHU
Ejemplo “Hello World”, tomado de (Lee, 2003).
(c) Registro del servicio.
Konputagailuen Arkitektura eta Teknologia Saila
Departamento de Arquitectura y Tecnología de Computadores
40
Integración de servicios
OSGi: un ejemplo (cont)
UPV - EHU
Ejemplo “Hello World”, tomado de (Lee, 2003).
(d) Descubrimiento e invocación.
Konputagailuen Arkitektura eta Teknologia Saila
Departamento de Arquitectura y Tecnología de Computadores
41