TECNOLOGÍAS PARA LA GESTIÓN DEL CONTEXTO
Nota 3.1 Comprenhensive Structured Context Profiles.
3.2.3 Modelos de gestión del contexto (o fundamentos de la arquitectura).
Se comentan a continuación los modelos de gestión de contexto más habituales, que también pueden entenderse como determinantes de la arquitectura del sistema que los implementa.
• Acceso directo al sensor
Muchos de los prototipos y primeras aplicaciones basadas en contexto han sido desarrolladas siguiendo una estrategia de acceso directo al sensor: es decir, cada aplicación gestiona la captura de datos de modo ad hoc para sus objetivos, lo que incluye el acceso a las interfaces físicas y los posteriores algoritmos de procesado e inferencia. Esta aproximación, del todo ineficiente si se valora en términos de reusabilidad y escalabilidad, tiene la ventaja de proporcionar una mayor eficiencia y adaptación a los requisitos específicos de la aplicación. No obstante, la tendencia es a
• • • TECNOLOGÍAS PARA LA GESTIÓN DEL CONTEXTO
migrar hacia arquitecturas que hagan posible manejar el contexto de un modo adaptativo, que permitan la incorporación sencilla de nuevos componentes y aplicaciones, como las que se mencionan seguidamente.
• Widgets
Winograd (2001) explica el concepto de widget, original del Context Toolkit de Anind Dey et al. (2001), como “una extensión de los drivers de un dispositivo desde una interfaz software”. Es decir, se trata de un dispositivo abstracto que envuelve el físico, y que facilita el acceso a la información proporcionada por el mismo, procesándola y adecuándola a las necesidades impuestas por capas superiores (aplicaciones o middleware). La interacción se implementa en términos de mensajes que son enviados al widget y de callbacks o retrollamadas, que son iniciadas cuando se cumple una condición determinada en el widget para avisar a las aplicaciones o middleware consumidor de información. En una arquitectura tradicional basada en widgets, habitualmente existe un programa controlador (que puede ser la misma aplicación), que mantiene control sobre los servicios y las conexiones con los widgets.
• Servicios en red (o estructura cliente-servidor)
Esta aproximación considera que la adquisición del contexto depende de servicios implementados autónomamente, capaces de gestionar ellos mismos los procesos de descubrimiento, conexión y mantenimiento (control de errores, etc.) directamente con el consumidor, sin el uso de un sistema centralizado (como en el caso anterior). En este caso, las aplicaciones tienen que descubrir los servicios (en el proceso de descubrimiento esta conexión puede estar predefinida o implicar la configuración de servicios para tal objetivo) y establecer conexiones de mayor o menor duración (en el primer caso, a través de sockets, por ejemplo, y en el segundo con consultas HTTP). Mientras que la aproximación basada en widgets añade complejidad al middleware o aplicación, ésta hace lo propio con el servicio de adquisición. Uno de los aspectos más importantes es la gestión de descubrimiento de servicios.
• Pizarra
Los dos modelos anteriores están basados en proceso. Las arquitecturas basadas en pizarra están, por el contrario, basadas en datos. Los procesos envían mensajes a una pizarra virtual y pueden suscribirse para recibir notificaciones que concuerden con ciertos criterios (cuyo cumplimiento se garantiza a través de procesos de comparación más o menos sofisticados) que hayan establecido previamente, de tal forma que conceptualmente, sea siempre un servidor centralizado el que controle las comunicaciones.
• Servidor de contexto centralizado
En el caso de la arquitectura basada en pizarra, el servidor gestiona las comunicaciones pero no el procesado de los datos. Un servidor de contexto centralizado sirve de intermediario entre las aplicaciones y los sensores, de tal manera que aísla a las primeras de cualquier tipo de conocimiento sobre los procesos de adquisición. Este tipo de arquitectura necesita tener mecanismos de descubrimiento de sensores y de gestión
CAPÍTULO 3 • • •
80
de las aplicaciones/clientes que tiene conectados. Su principal ventaja es que libera a los dispositivos móviles de la sobrecarga computacional, al realizarlo de forma centralizada. Su principal inconveniente es un resultado de su principal ventaja: la falta de distribución.
3.3
Plataformas
de
provisión
de
servicios
contextuales.
En esta sección, se revisan once de las muchas plataformas de provisión de servicios contextuales que se han propuesto en los últimos años, con el propósito de trasmitir la diversidad de aproximaciones al problema. El lector interesado puede encontrar en (Baldauf y Dustdar, 2004), (Hoh, 2006), (Henricksen et al., 2005), (Singh et al., 2006) y (Ellebaek, 2007) un compendio del descripciones de plataformas, evaluadas con criterios de comparación que permiten extraer conclusiones desde un punto de vista práctico.
• Context Toolkit (CTK).
Presenta una arquitectura sencilla y funcional (Dey et al., 2001), consistente en widgets o encapsuladores de sensores, y en una infraestructura distribuida para alojarlos (Figura 3.5). Como se ha comentado anteriormente, los widgets son componentes software que proporcionan a las aplicaciones acceso a la información de contexto, ocultando los detalles del proceso de captura de datos. Adicionalmente, dispone de agregadores de contexto, que tienen capacidades de agrupamiento de información de contexto procedente de widgets. Por ejemplo: identidad, localización y nivel de sonido puede usarse para deducir que una reunión está teniendo lugar.
Figura 3.5 Arquitectura del CTK.
En lo que se refiere al razonamiento, no realiza una implementación elaborada de la inteligencia; cada usuario define conceptos de alto nivel que están basados en los datos de los sensores y en la información del entorno.
En su implementación última, dispone de una configuración que maneja un descubridor (discoverer) que permite mantener registro de todos los widgets en el sistema. Gracias a este registro, las aplicaciones pueden suscribirse al sistema sin conocer estrictamente los widgets que hay en capas inferiores.
• • • TECNOLOGÍAS PARA LA GESTIÓN DEL CONTEXTO
Esta plataforma se ha adaptado para implementar uno de los prototipos propuestos en esta Tesis, por lo que se describe con más detalle en el apartado 7.3.4.
• Cooltown
Cooltown (Kindberg y Barton, 2001) está dirigido a soportar interacción con dispositivos móviles inalámbricos para interaccionar con un entorno basado en web. El principio básico del sistema es que los dispositivos, las personas y las cosas estén presentes en la red a través de una URL, que es la interfaz de interacción con la entidad. La definición del contexto incluye parámetros que definen dónde, cuándo, quién, qué y cómo. El contexto está integrado con un modelo de mundo físico, en el que se encuentran lugares, personas y cosas, y en el que se describen las relaciones entre ellos (Contains, isContainedIn, isNextTo, isCarriedBy…). Los principales módulos de la arquitectura son: Web Presence Manager, Description, Directory, Discovery modules, Autobiographer, Observer y Control.
• Gaia
Gaia (Román et al., 2002) quiere ser un meta-sistema operativo. Se construye sobre el concepto de active space, que coordina y combina dispositivos heterogéneos en un especio físico (como una habitación). Al ser un SO, ofrece: ejecución de programas, operaciones I/O, acceso al sistema de ficheros, comunicaciones, detección de errores y asignación de recursos.
Gaia (Figura 3.6) utiliza el Context File System, una jerarquía virtual basada en etiquetas de información de contexto en archivos, que presenta una estructura de directorios basada en predicados de contexto. Diferencia entre información de posición, contexto y eventos, que son manejados por diferentes componentes. El contexto es recopilado por los context providers y el contexto de más alto nivel puede ser inferido a partir del de bajo nivel. Un servicio adicional de presencia gestiona aquellas entidades (aplicación, servicio, dispositivo y persona) presentes en el active space. Existe un sistema de aviso basado en eventos que mantiene alerta a las aplicaciones acerca de los cambios de contexto.
Figura 3.6 Arquitectura de Gaia.
• Solar
Solar (Chen y Kotz, 2002) implementa la abstracción de un grafo que recoge, agrega y disemina la información de contexto. Es una arquitectura basada en eventos, a los que las aplicaciones pueden suscribirse para responder a cambios asíncronos de contexto. En Solar se considera que:
CAPÍTULO 3 • • •
82
- Los sensores son fuentes de información (física o computacional), que publican eventos indicando su estado actual o cambios en el mismo.
- La secuencia de eventos producidos son un event stream (que son la entrada de los operadores).
- Los operadores son objetos que se suscriben a uno o más input event streams, los procesan y publican otro event stream.
- Un sensor con una única interfaz de interrogación puede envolverse en un proxy publisher.
- Las aplicaciones basadas en contexto se suscriben a los event streams que les interesan y reaccionan a los eventos de cambio.
Solar descompone el proceso de agregación de contexto de cada aplicación en una serie de operadores modulares y reutilizables, cada uno de los cuáles es un objeto que se suscribe y procesa uno o más input streams y publica otro event stream. Existen cuatro tipos de operadores:
- Filtro: proporciona un subconjunto de sus eventos de entrada. Por ejemplo, se emplea si un sensor publica su medida de temperatura cada 10 segundos y la aplicación sólo la necesita cuando supera los 90º.
- Transformador: operador que toma de entrada eventos del tipo T1 y da a la salida eventos T2 (por ejemplo, T1: localización coordenadas físicas, T2: localización simbólica).
- Merger: su salida es idéntica a su entrada. Por ejemplo, una aplicación que muestra la posición de los empleados fusiona información de todos los sensores de localización. Aunque los mergers no son estrictamente necesarios (cada aplicación podría suscribirse para recibir la información de los sensores), éstos facilitan la reutilización de los streams de eventos.
- Agregador: ofrece como salida un tipo de stream de eventos arbitrario basado en los eventos de uno o más input event streams. Por ejemplo, un termómetro min- max da como salida un evento cuando detecta un nuevo máximo o un nuevo mínimo en su input stream de lectores de temperatura.
Figura 3.7 Arquitectura de Solar.
Cada aplicación es capaz de construir un árbol de operadores para recoger y agregar el contexto que necesita. No obstante, se busca la reutilización de las suscripciones a los árboles (o subárboles de operadores).
La arquitectura de Solar está formada por estrellas y planetas. Una estrella (star) procesa de forma centralizada las peticiones de suscripción. Cuando la estrella recibe una descripción de un nuevo árbol de suscripción, “parsea” la descripción y la compara contra su estructura interna de datos en forma de árbol de operadores (para ver si hay operadores que puedan ser reutilizados). El planeta (planet) es la plataforma de
• • • TECNOLOGÍAS PARA LA GESTIÓN DEL CONTEXTO
ejecución de las fuentes y operadores de Solar y es responsable de inventariar las suscripciones y de distribuir eventos en el grafo de operadores.
• Hydrogen
Hydrogen (Hofer et al., 2003) es una arquitectura software que surge de la necesidad de considerar las limitaciones de conexión de red, computación y demás características de los dispositivos móviles. Propone una arquitectura tricapa (de adaptación, de gestión y de aplicación), en la que las tareas de gestión recaen sobre un servidor de contexto. En este servidor se almacena el contexto para los dispositivos y de ahí se proporciona a las aplicaciones.
El servidor de contexto permite peticiones asíncronas y también gestiona un mecanismo de suscripciones que proporciona acceso síncrono tipo push, para que las aplicaciones puedan ser notificadas ante cambios.
Contempla la posibilidad de que los dispositivos se comuniquen entre sí, y de tal forma distingue entre el contexto local y el remoto. Un dispositivo capaz de almacenar los datos de los dispositivos que tiene a su alrededor puede inferir su propio contexto de forma autónoma.
La arquitectura requiere que el cliente disponga de un ContextClient. Las comunicaciones intercapa se realizan a través de XML, y las aplicaciones tienen que utilizar también este lenguaje para hacerlo. No se incluye ningún tipo de razonamiento sobre el contexto, y se asume que este proceso lo hacen las aplicaciones.
En el momento de su publicación, Hydrogen planteaba la posibilidad de a) incluir un modelo de contexto basado en CC/PP, b) modelar los objetos de contexto en XML y c) establecer mecanismos de compartición de contexto entre varios servidores.
Figura 3.8 Arquitectura de Hydrogen.
• CoBrA
CoBra (Chen et al., 2003a) es una arquitectura basada en agentes inteligentes. El agente context broker mantienen un modelo de contexto compartido para la comunidad de agentes, servicios y dispositivos en el espacio y provee protección de la privacidad para los usuarios. El componente inteligente utiliza inferencias lógicas basadas en reglas para el razonamiento de contexto y el mantenimiento del conocimiento.
CAPÍTULO 3 • • •
84
i) proveer un modelo centralizado de contexto que puede ser compartido por todos los dispositivos, servicios y agentes en el espacio.
ii) adquirir información contextual de fuentes que no son alcanzables por dispositivos con recursos limitados.
iii) razonar acerca de la información contextual que no puede ser directamente adquirida por los sensores (intenciones, roles, relaciones espacio-temporales…).
iv) detectar y resolver inconsistencias que se puedan presentar en el modelo compartido de contexto.
v) proteger la privacidad del usuario.
El sistema utiliza tecnologías de web semántica como OWL.
Figura 3.9 Arquitectura del CoBrA.
• CMF
El Context Manager Framework (Korpipää et al., 2003) considera cuatro componentes en su arquitectura: un gestor de contexto (context manager), un servidor de recursos (resource server), un servicio de reconocimiento de contexto (context recognition service) y las aplicaciones. Cuando las entidades se comunican, el gestor de contexto funciona como un servidor central sobre el que otras entidades funcionan como clientes y utilizan los servicios que provee el servidor. El gestor de contexto, cualquier servidor de recursos y aplicaciones corren en el terminal móvil. Los servicios son distribuidos o locales. En el corazón del sistema de contexto del terminal móvil está el gestor de contexto (basado en un sistema de blackboard o pizarra).
CMF utiliza lógica borrosa para construir conceptos de alto nivel a partir de datos de sensores borrosos. La mayor parte de los marcos conceptuales para sistemas contextuales asumen que el contexto está inteligentemente especificado en términos de conceptos de alto nivel. Los autores de CMF proponen utilizar lógica borrosa para razonar sobre conceptos de alto nivel como la posición.
• MobiPADS
MobiPADS (Chan y Chuang, 2003) es un sistema middleware para entornos móviles. La entidad principal son los Mobilets, que proveen un servicio que puede ser migrado entre diferentes entornos MobiPADS. Cada Mobilet consiste en un esclavo y un maestro. El esclavo reside en el servidor, el maestro en el dispositivo móvil. Cada par coopera para proveer un servicio específico, Los servicios se componen encadenando
• • • TECNOLOGÍAS PARA LA GESTIÓN DEL CONTEXTO
los mobilets en un orden específico (tanto en cliente como en servidor). Esto hace posible una fácil reconfiguración.
Los tipos de contexto incluyen: potencia de procesado, memoria, almacenamiento, dispositivos de red, baterías, etc. Cada uno tiene varios subtipos (p.e. size o free_space para memoria y almacenamiento). A los mobilets se les hacen llegar los cambios a través de eventos a los que se suscriben. Existe un Environment Monitor que se suscribe a las fuentes de eventos.
• SOCAM (Service-Oriented Context-Aware Middleware)
SOCAM es un middleware distribuido que utiliza ontologías para modelar el contexto, convirtiendo espacios físicos en espacios semánticos donde los contextos pueden compartirse y accederse por servicios (Gu et al., 2004). La arquitectura SOCAM consiste en:
- Context Providers: abstraen contextos de diferentes fuentes, externas o internas, y los convierten a representaciones OWL de tal forma que los contextos pueden ser compartidos y reutilizados por otros componentes del servicio.
- Context Interpreters: proveen servicios de razonamiento lógico para procesar la información de contexto.
- Una base de datos de contexto (Context Database): almacena ontologías de contexto y contextos pasados para un subdominio. Hay una base de datos de contexto en cada dominio (por ejemplo, un dominio será “casa”).
- Un Service-Locating Service: provee un mecanismo donde los proveedores de contexto y el intérprete pueden anunciar su presencia.
- Diversos servicios móviles basados en contexto.
Figura 3.10 Arquitectura de SOCAM.
Los proveedores de contexto proporcionan contextos internos o externos, que pueden ser utilizados directamente por los servicios móviles o por otro Context Provider para ofrecer información de contexto elaborada. Externamente, el Context Interpreter actúa como proveedor de contexto.
El Context Interpreter consiste en un Context Reasoner y una Context Database, que contiene instancias de la ontología, tanto de usuarios como de proveedores de contexto. El contexto se actualiza por un mecanismo de disparo en diferentes intervalos. Los proveedores de contexto se registran con en el Service Location Service, permitiendo que los servicios móviles los localicen. Los servicios pueden obtener información de contexto preguntando a los proveedores de contexto o registrándose para eventos específicos. SOCAM soporta reglas para especificar qué métodos deben invocarse
CAPÍTULO 3 • • •
86
cuando sucede un evento. Estas reglas están predefinidas y pueden cargarse en el Context Reasoner.
• CORTEX (CO-operating Real-time senTient objects:architecture and Experimental evaluation)
El middleware (Sørensen et al., 2004) se basa en el uso de objetos “que sienten” (sentient objects), arquitectura dirigida a permitir que los desarrolladores diseñen aplicaciones distribuidas en esos términos. Los sentient objects son componentes software inteligentes que son capaces de adquirir datos del entorno a través de “eventos” que generan los sensores u otros objetos. Después, tienen la capacidad de fusionarlos para inferir un contexto de más alto nivel, y también pueden razonar con algún tipo de lógica de control y actuar desde el punto de vista físico, publicando eventos para los actuadores. Los sentient objects actúan según el comportamiento de objetos próximos que descubren dinámicamente y con los que comparten información de contexto.
CORTEX diseña su middleware basándose en marcos de componentes, cada uno ofrece un servicio a los objetos: en componente Publish-Subscribe se utiliza para descubrir, comunicar y compartir datos enter las entidades móviles en proximidad; el componente Group Communication se utiliza para proporcionar un protocolo de comunicaciones en grupo que proporciona mecanismos de enrutamiento en red ad hoc; el componente Context proporciona los mecanismos de fusión y el motor de inferencias; el componente QoS management gestiona la asignación de recusos y facilita la monitorización y la adaptación de la calidad de servicio. Utiliza el motor de inferencias basado en reglas CLIPS que, además de incluir las reglas de razonamiento del servicio, incluye la gestión de la calidad.
El sistema se configura en el momento del despliegue y puede reconfigurarse en tiempo de operación con una API.
CORTEX se ha prototipado para ofrecer servicios de control en vehículos inteligentes (por ejemplo, para hacer que el coche se pare si hay un peatón a una distancia demasiado corta).
Figura 3.11 Arquitectura de CORTEX.
• MiddleWhere
MiddleWhere (Ranganathan et al., 2004) proporciona información de posición a las aplicaciones e incorpora una amplia colección de técnicas para posicionamiento en un modelo integrado. La información de localización se origina en los Location Providers y se almacena en una base de datos espacial. El motor de razonamiento utiliza la
• • • TECNOLOGÍAS PARA LA GESTIÓN DEL CONTEXTO
información de posición de diferentes proveedores para determinar la posición, y un servicio de posicionamiento utiliza la base de datos espacial y el motor de razonamiento para proveer información de posición con una cierta probabilidad.
El modelo de localización es jerárquico y trabaja con tres tipos de posición: puntos, líneas y polígonos. La posición se representa como GLOBs (Gaia LOcation Byte- String). Por ejemplo, una mesa se representa como Building1/3/338/Desk 1 o como Building1/3/338/(2,4,0), lo que quiere decir que la mesa 1 está en la habitación 338, planta 3 del edificio 1, en las coordenadas (2,4,0) respecto al sistema de referencia de la habitación.
El sistema tiene en cuenta la calidad de la información de posición, medida en función de su resolución, confianza y actualidad (freshness).
• Citron
La peculiaridad de esta plataforma es que está pensada para residir en un terminal móvil equipado con un conjunto de sensores (Yamabe et al., 2005). La arquitectura adoptada está basada en un modelo de pizarra, sobre el que se ejecutan diversos módulos de análisis dirigidos a extraer información de los datos crudos que depositan los sensores. Para implementar la pizarra, utiliza un espacio de tuplas (un repositorio de tuplas que pueden accederse de forma concurrente). La arquitectura se basa en dos componentes principales: a) Citron Worker, que es el módulo de análisis de los datos procedentes por los sensores, en el que cada worker captura la información del sensor que le