upv - ehu konputagailuen arkitektura eta teknologia saila departamento de arquitectura y tecnología...

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.