Instituto Tecnológico y de Estudios Superiores de Monterrey Campus Monterrey
Monterrey, Nuevo León a
Lic. Arturo Azuara Flores:
Director de Asesoría Legal del Sistema
Por medio de la presente hago constar que soy autor y titular de la obra
titulada"
", en los sucesivo LA OBRA, en virtud de lo cual autorizo a el Instituto Tecnológico y de Estudios Superiores de Monterrey (EL INSTITUTO) para que
efectúe la divulgación, publicación, comunicación pública, distribución y reproducción, así como la digitalización de la misma, con fines académicos o propios al objeto de EL INSTITUTO.
El Instituto se compromete a respetar en todo momento mi autoría y a
otorgarme el crédito correspondiente en todas las actividades mencionadas anteriormente de la obra.
De la misma manera, desligo de toda responsabilidad a EL INSTITUTO por cualquier violación a los derechos de autor y propiedad intelectual que cometa el suscrito frente a terceros.
Nombre y Firma AUTOR (A)
Modelo Inter-Tecnologías en Entornos Inteligentes-Edición
Única
Title Modelo Inter-Tecnologías en Entornos Inteligentes-Edición Única
Authors María Teresa González Díaz
Affiliation ITESM-Campus Monterrey
Issue Date 2006-06-01
Item type Tesis
Rights Open Access
Downloaded 19-Jan-2017 10:57:34
Instituto Tecnol´
ogico y de Estudios
Superiores de Monterrey
CAMPUS MONTERREY
PROGRAMA DE GRADUADOS EN ELECTR ´ONICA,
COMPUTACI ´ON, INFORMACI ´ON Y COMUNICACIONES
TESIS
MODELO INTER-TECNOLOG´IAS EN ENTORNOS INTELIGENTES
PRESENTADA COMO REQUISITO PARCIAL PARA OBTENER EL GRADO ACAD´EMICO DE:
MAESTR´IA EN CIENCIAS EN TECNOLOG´IAS DE LA INFORMACI ´ON POR
MARIA TERESA GONZALEZ DIAZ
Instituto Tecnol´
ogico y de Estudios
Superiores de Monterrey
Campus Monterrey
Programa de Graduados en Electr´
onica,
Computaci´
on, Informaci´
on y Comunicaciones
Los miembros del comit´e de tesis recomendamos que la presente propuesta de sea aceptada para desarrollar el proyecto de tesis que es requisito parcial para obtener el grado de Maestro en Ciencias de Tecnolog´ıa Inform´atica.
Comit´
e de Tesis
Dr. Jos´e Ra´ul P´erez C´azares
Asesor Principal
Dr. Ra´ul V. Ram´ırez Velarde Ing. Pablo Daniel D´ıaz L´opez
Sinodal Sinodal
Dr. David A. Garza Salazar
Director del Programa de Posgrado en Electr´onica, Computaci´on, Informaci´on y Comunicaciones
MODELO INTER-TECNOLOG´IAS EN ENTORNOS INTELIGENTES
por
MARIA TERESA GONZALEZ DIAZ
TESIS
Presentada al Programa de Graduados en Electr´onica, Computaci´on, Informaci´on y Comunicaciones
Este trabajo es requisito parcial para obtener el grado de Maestro en Ciencias en Tecnolog´ıa Inform´atica
INSTITUTO TECNOL ´OGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY
Dedicatoria
A mis padres y hermanos,
Gracias por ense˜
narme la persistencia
y la pasi´on por buscar la excelencia.
A Salom´
on,
Por mantener de pie este sue˜
no.
Gracias
Resumen
Los dispositivos m´oviles son una alternativa de comunicaci´on que en los ´ultimos a˜nos han tomado amplia popularidad. Los ambientes m´oviles representan aspectos de practicidad, comodidad y simplicidad en las soluciones inal´ambricas. De la misma manera, las redes dom´oticas son espacios donde la tecnolog´ıa puede incursionar para ofrecer soluciones integrales de control, seguridad y comodidad a trav´es de ambientes de comunicaci´on versatiles y potenciales. Asi, ambas tendencias cooperan para formar ambientes inteligentes en los hogares modernos.
En esta tesis, se presenta un modelo de integraci´on de usuarios m´oviles con las aplicaciones en los hogares instaladas en una paserala residencial, denominado Modelo Intertecnolog´ıas. Se propone una soluci´on integral bajo uno de los est´andares m´as importantes y representativos, como lo es OSGi. Este est´andar especifica un framework para instalar e interoperar aplicaciones desarrolladas en java. Sin embargo, no especifica un mecanismo de comunicar y administrar los dispositivos m´oviles, raz´on por la cual es necesario proponer un modelo de integraci´on.
El modelo propuesto es basado en componentes y orientado a servicios. El objetivo es satisfacer la integraci´on de aplicaciones instaladas en el framework de OSGi y soluciones instaladas en usuarios m´oviles. El modelo representa una abstraci´on de las caracter´ısticas de los ambientes m´oviles como lo son la adaptaci´on al contexto y provisi´on de servicios de manera transparente entre los clientes y el servidor. Adem´as, se define un esquema de interoperabilidad orientado a proveer interfaces gen´ericas encapsuladas en un WPA (Wireless Personal Access) Middleware de comunicaci´on.
´Indice general
1. Introducci´on 1
1.1. Planteamiento del Problema . . . 2
1.1.1. Las Arquitecturas y Middleware en Redes Dom´oticas . 3 1.1.2. Integrando Ambientes Heterog´eneos basados OSGi . . 5
1.2. Justificaci´on . . . 6
1.3. Objetivos . . . 6
1.3.1. Objetivo General . . . 6
1.3.2. Objetivos Espec´ıficos . . . 7
1.4. Alcances . . . 7
1.5. Hip´otesis . . . 8
1.6. Metodolog´ıa . . . 8
2. OSGi en las Redes Dom´oticas 10 2.1. Caracter´ısticas Generales de OSGi . . . 11
2.2. La Especificaci´on OSGi . . . 11
2.3. Los Modelos Arquitecturales para Soluciones basadas en OSGi 12 2.4. El Framework de OSGi . . . 14
2.4.1. La Arquitectura del Framework . . . 14
2.4.2. Bundles . . . 17
´
INDICE GENERAL ´INDICE GENERAL
2.4.4. Eventos . . . 20
2.4.5. Listeners . . . 20
2.4.6. Especificaci´on de Acceso a los Dispositivos . . . 20
2.4.7. Especificaci´on de Servicios Jini . . . 22
2.4.8. Especificaci´on UPnp con OSGi . . . 24
2.5. Implementaciones del Framework de OSGi . . . 26
2.5.1. Knopflerfish . . . 27
2.5.2. Componentes del Framework Knopflerfish . . . 27
3. Ambientes Dom´oticos basados en Tecnolog´ıas Inal´ambricas 29 3.1. Clasificaci´on de las Redes Inal´ambricas . . . 30
3.1.1. IrDA . . . 31
3.1.2. Bluetooth . . . 32
3.1.3. 802.15 . . . 32
3.1.4. Zigbee . . . 33
3.2. Principios de Dise˜no en Ambientes M´oviles . . . 34
3.2.1. Complejidad de los Ambientes M´oviles . . . 34
3.2.2. Requerimientos de los Ambientes M´oviles . . . 36
3.3. Arquitecturas orientadas a Ambientes M´oviles . . . 37
3.3.1. Modelos basados en Cliente/Servidor . . . 38
3.3.2. Modelos basados en Arquitecturas Orientadas a Servicios. . . 39
3.3.3. Arquitecturas M´oviles basadas en OSGi . . . 42
4. Modelo Inter-tecnolog´ıas Propuesto 44 4.1. Definici´on de Requerimientos . . . 45
4.2. Arquitectura del Modelo . . . 45
4.2.1. Esquema de Operaci´on . . . 46
´
INDICE GENERAL ´INDICE GENERAL
4.3. Modelo Propuesto Detallado . . . 50
4.3.1. WPA Middleware en OSGi y en el cliente M´ovil. . . 50
4.3.2. Service Manager . . . 54
4.3.3. Context Manager Manager . . . 57
4.3.4. Mobile OSGi Manager . . . 58
4.3.5. OSGi Application y la Mobile Application . . . 59
5. Conclusiones 61 5.1. Caracter´ısticas Generales del Modelo . . . 61
5.2. Desarrollo de la Prueba de Concepto . . . 63
5.2.1. Implementaci´on de la Prueba de Concepto . . . 63
5.3. Resultados del Experimento . . . 65
5.3.1. An´alisis del N´umero de Interfaces . . . 67
5.3.2. An´alisis Comparativo de los Resultados . . . 67
5.4. Trabajo Futuro . . . 68
5.4.1. Extensi´on del Modelo para Arquitecturas Smart Client 69 5.4.2. Reconfiguraci´on Din´amica de Servicios. . . 69
5.4.3. Integraci´on Adaptaci´on al Contexto dentro del Usuario M´ovil . . . 70
5.4.4. Aspectos de Seguridad De las Soluciones . . . 70
6. Ap´endices. 71 6.1. Instalaci´on de Knopflerfish . . . 71
6.2. Pasos para Construir una Aplicaci´on en Knopflerfish . . . 72
´Indice de figuras
2.1. Entorno Adaptable de Redes Dom´oticas en Pasarelas
Residenciales. . . 11
2.2. Elementos de Modelos de Negocio basados en OSGi. . . 13
2.3. Arquitectura de Capas de OSGi. . . 15
2.4. Diagrama de Clases del Framework de OSGi. . . 16
2.5. Servicios del Framework de OSGi. . . 17
2.6. Diagrama de Clases para la especificaci´on Jini. . . 23
2.7. Diagrama de Clases para la Especificaci´on UPnp. . . 25
3.1. Pila de Protocolos de Bluetooth. . . 33
3.2. Pila de Protocolos de Zigbee y 802.15.4. . . 34
3.3. Ejemplo de Modelo Cliente-Servidor para Ambientes M´oviles. 38 3.4. Ejemplo de Arquitectura Smart Client. . . 39
3.5. Ejemplo de Arquitectura Thin Client. . . 39
4.1. Infraestructura General de una Red Dom´otica basada en OSGi. 46 4.2. Interacci´on de Aplicaciones M´oviles con OSGi. (Diagrama de Instalaci´on.) . . . 46
4.3. Arquitectura del Modelo de Integraci´on de Ambientes M´oviles a OSGi. (Diagrama de Componentes.) . . . 47
´
INDICE DE FIGURAS ´INDICE DE FIGURAS
4.5. Diagrama de Clases para el Componente WPA Middleware en
el Dispositivo M´ovil. . . 52
4.6. Diagrama de Secuencia para el Protocolo de Comunicai´on basado en WPA Middleware. . . 53
4.7. Diagrama de Clases del Componente Service Manager. . . 55
4.8. Diagrama de Secuencia del Comportamiento del Service Manager. . . 57
4.9. Diagrama de Clases del Context Aware Manager . . . 58
4.10. Diagrama de Secuencia del Context Aware Manager. . . 59
4.11. Interfaces propuestas para el Mobile OSGi Manager. . . 59
4.12. Interfaces para la capa de aplicaci´on. . . 59
4.13. Diagrama de Secuencia para la Capa de Aplicaci´on de OSGi y en el Dispositivo M´ovil. . . 60
´Indice de cuadros
4.1. Descripci´on de los Mensajes del Protocolo. . . 54 4.2. Descripci´on de los Mensajes del Protocolo para la
Adminis-traci´on de los Servicios. . . 56 5.1. Descripci´on del Caso de Uso. Control de Temperatura en OSGi
para Clientes M´oviles . . . 64 5.2. An´alisis Comparativo del Modelo Propuesto con las
Cap´ıtulo 1
Introducci´
on
Hoy en d´ıa, una de las principales tendencias de la tecnolog´ıa es crear entornos inteligentes que proporcionen al hombre seguridad, comodidad y comunicaci´on al instante desde cualquier parte. La explosi´on de tecnolog´ıas diferentes ha propiciado ambientes inter-operables independientemente de la ubicaci´on y las plataformas. La definici´on de modelos y est´andares para la integraci´on de componentes y redes de comunicaci´on han marcado el punto de partida para el crecimiento de estos entornos.
M´as all´a de interconexi´on tradicional de computadoras, las redes dom´oticas surgen como una alternativa para la inte rconexi´on de los dispositivos cotidianos. Est´an orientadas a proveer servicios a trav´es de pasarelas interconectadas a redes tradicionales [39]. Pensar en ambientes inteligentes donde se pueda usar el tel´efono o la televisi´on para verificar que las puertas han sido cerradas o la cafetera est´a apagada, son simples ejemplos de los alcances logrados hasta el momento.
Los hogares modernos se componen de un conjunto de dispositivos electr´onicos de diferentes proveedores. Cuando son enlazados y ofrecen servicios integrados, proporcionan mayor versatilidad sobre sus aplicaciones dentro de la casa. Sin embargo, lograr un ambiente heterog´eneo de sistemas, dispositivos y servicios interoperando dentro de las redes dom´oticas, es uno de los principales problemas que las investigaciones actuales est´an tratando de resolver [13].
CAP´ITULO 1. INTRODUCCI ´ON
ofrecer a los usuarios. Proporcionar transparencia y simplicidad de conexi´on, acceso y control, no es una tarea f´acil [30]. Moon [24], especifica que si se tienen n diferentes tipos de dispositivos con m diferentes interfaces comunic´andose contra otros k diferentes dispositivos, entonces la complejidad de comunicacion es de O(nmk). Obs´ervese la alta proporci´on de interfaces resultantes con el crecimiento de dispositivos diferentes interconectados. Esto se traduce en una motivaci´on para buscar nuevas y mejores soluciones que optimicen el n´umero de interfaces entre los dispositivos integrados. Es decir, es necesario proponer arquitecturas que reduzcan integraciones y proporcionen la mayor transparencia posible. El mercado a´un espera por soluciones que contribuyan a las tendencias de uno los entornos inteligentes con mayor potencial de crecimiento, tal como lo representan los ambientes dom´oticos [31].
Un ejemplo de las soluciones que se han ofrecido es OSGi(Open Source Gateway Iniciative). OSGi es un modelo de especificaci´on est´andar para proveer servicios orientados a redes dom´oticas [32]. El objetivo es promover los sistemas de interconexi´on abiertos. Se considera uno de los est´andares con mayor futuro para satisfacer estas necesidades. Sin embargo, actualmente no ofrece interoperabilidad con redes inal´ambricas, como Wifi o Bluetooth. La mayor´ıa de los autores coinciden en que la integraci´on de redes inal´ambricas a OSGi significar´ıa una contribuci´on importante para ofrecer ventajas de flexibilidad y minimizaci´on de costos.
Es por ello, que la presente propuesta de tesis tiene el objetivo de realizar una investigaci´on detallada sobre las capacidades ofrecidas de OSGi y las caracter´ısticas de los ambientes m´oviles. Para obtener como resultado el desarollo de un modelo de integraci´on de tecnolog´ıas m´oviles, basado en el framework OSGi dentro de una red dom´otica.
1.1.
Planteamiento del Problema
CAP´ITULO 1. INTRODUCCI ´ON
para ofrecer seguridad, comodidad, manejo y comunicaci´on [10]. En [18] Jimeno, define que las redes dom´oticas son sistemas ubicuos integrados por dispositivos y recursos dom´oticos de acceso m´ovil y multimedia, servidores y medios de comunicaci´on. Como parte de la lengua inglesa, tambi´en son conocidas como ”Home Networks” oResidential Network”.
Los ambientes dom´oticos representan una ´area de automatizaci´on con alta aceptaci´on y futuro, debido a la cantidad de productos dom´esticos que pueden ser integrados y manipulados por un sistema de tecnolog´ıa de informaci´on
(TI). No obstante, debido al crecimiento de los clientes y proveedores de servicios, se hace necesario la definici´on de los est´andares para operar en ambientes heterog´eneos. Dentro de los est´andares conocidos sobre ambientes de red, se pueden citar HAVi, Jini, Satulation, UPnP, X10, HomePlug, HomePNA, IEEE 1394, OSGi, entre otos m´as [30]. Mientras que en los estand´ares para ambientes inal´ambricos se encuentran: HomeRF2, 802.11b, 802.11a, 802.11g, 802.15.3 HiperLAn2, 5-Up, Irda, Bluetooth2 y Zigbee [40] . Obs´ervese como la lista de est´andares es amplia, por lo que la complejidad de integraci´on aumenta en base al n´umero de interfaces necesarias entre ellos para comunicarse y ofrecer servicios.
1.1.1.
Las Arquitecturas y Middleware en Redes
Dom´
oticas
En los ´ultimos dos a˜nos, los investigadores han enfocado esfuerzos para proponer arquitecturas interoperables. Los enfoques y trabajos son variados. Existen arquitecturas propuestas como MiDA’s(Mobile Internet Device with Network Appliance) [17], UMB [21], CINEMA(Columbia InterNet Extensible Multimedia Architecture) [34], mPRM(Remote Manangement Concept) [37]. Sin embargo, los trabajos han sido muy enfocados a resolver una aplicaci´on en particular. Proponen arquitecturas dependientes de los servicios que se desean integrar y esto las hace poco escalables. En t´erminos de ambientes m´oviles, puede comentarse que los trabajos coinciden en los siguientes puntos: 1. Es necesario un protocolo que permita descubrir el dispostivo y que
determine su posici´on.
CAP´ITULO 1. INTRODUCCI ´ON
caracter´ısticas de movilidad, es decir que elimine la necesidad de autentificarse si el dispositivo cambia de celda.
3. Es necesario establecer un middleware que responda a los caracter´ısticas del medio para proveer o denegar servicios.
4. Es necesario definir estrategias para determinar que servicios ser´an ofrecidos dependiendo de la ubicaci´on del dispositivo. Por ejemplo si se ubica en la cocina, el dispositivo puede acceder a los servicios de la cafetera, mientras que al moverse a la rec´amara, deber´a solo de tener acceso a la televisi´on o a la l´ampara.
Por otro lado, en t´erminos de arquitecturas los trabajos identifican los siguientes puntos importantes:
1. Identifican un servicio administrador y controlador de servicios. Este puede ser distribuido como lo describe autor en la arquitectura MiDas, o bien centralizado como en mPRM.
2. Identifican un middleware encargado de manejar la comunicaci´on con los diferentes est´andares de los dispositivos.
3. Identifican un middlewarebroker que mantenga la comunicaci´on entre las interfaces de los dispositivos y los servicios.
4. Determinan el costo de integraci´on seg´un el n´umero de interfaces necesarias para proporcionar flexiblidad y transparencia de conexi´on y del servicio.
5. Las arquitecturas son orientadas a servicios que responden a eventos. En realidad, existe un amplio n´umero de arquitecturas que proponen soluciones e integraci´on entre diversas arquitecturas y est´andares. Sin embargo, la escalabilidad y la portabilidad son un punto d´ebil. Una de las arquitecturas m´as sofisticadas es propuesta por Cho [4], propone 3 componentes principales: Middleware Manager, Middleware Broker y el Web Server. El manager controla los dispositivos que pertenecen al tipo de red. El
CAP´ITULO 1. INTRODUCCI ´ON
m´as actuales es la propuesta por Moon [24], quien propone una estructura principal basada en un mmiddleware de tablas de ruteo. Incluye un adaptador que permita la comunicaci´on f´ısica de los dispositivos; adem´as unmiddleware
de red y uno de mensajes.
1.1.2.
Integrando Ambientes Heterog´
eneos basados
OSGi
El ambiente OSGi fue pensado para manejar de manera externa las interfaces, donde los proveedores realizar´an un tipo de manejador que permitiera la comunicaci´on con el gateway OSGi. Es decir, una vez que se define la interfaz, OSGi tiene disponible de manera implicita la integraci´on con las interfaces que han sido instaladas en la pasarela de servicios, como es el caso de Jini, HTTP, UPnP. Esto elimina la necesidad de que cada interfaz tuviera que integrarse de manera especifica a los otros est´andares, ya que se logra con el simple hecho de interconectarlo a OSGi.
El mercado apunta hacia OSGi debido a que internamente ya controla y administra los servicios que se integran mediante una interfaz a la pasarela de servicios. Sin embargo, Bellavista [2] resalta la necesidad de que OSGi integre un middleware que soporte las caracter´ısticas de los ambientes m´oviles.
Algunos autores como Lee [21], Hall [32] o Latvakoski [17], est´an estableciendo algunas propuestas que han sido publicadas en 2004. Sin embargo, dentro de sus trabajos han propuesto soluciones sin un impacto formal 1
, pero coinciden en describir las siguientes caracter´ısticas para la interfaz con OSGi:
Se debe incluir el descubrimiento del dispositivo m´ovil con la definici´on de su instalaci´on, activaci´on y desinstalaci´on.
Se debe definir la denegaci´on/otorgaci´on del servicio bajo un esquema ´optimo de autentificaci´on.
Se debe especificar el proceso de adaptaci´on durante su tiempo activo, asi como el esquema de servicio disponible para el dispositivo y los servicios que ´este prove´e a la red de manera transparente [31].
1
CAP´ITULO 1. INTRODUCCI ´ON
1.2.
Justificaci´
on
Las limitaciones de movilidad de las redes cableadas y el alto costo de la infraestructura para nuevas instalaciones han llevado a buscar nuevas alternativas [39]. La integraci´on de redes inal´ambricas a las redes dom´oticas proponen una alternativa de acceso m´ovil y flexible, orientada a ofrecer ventajas competitivas en costos. Bajo este esquema, Bluetooth es una de las alternativas que tienen mayor impacto y futuro en estos momentos.
Actualmente, existen varios investigadores que est´an trabajando en proporcionar modelos que solucionen las caracter´ısticas distintivas de la comunicaci´on inal´ambrica. Sin embargo, el objetivo es desarrollar un modelo basado en OSGi, debido a la importancia que tiene ´este est´andar como plataforma para proveer servicios con pasarelas residenciales. Adem´as, OSGi es una especificaci´on abierta que ha sido retomada por una gran variedad de proveedores como IBM, Motorola, Oracle o Intel [1]. La integraci´on del modelo basado en las carater´ısticas de instalaci´on, registro, activaci´on y provisi´on del servicio proporcionadas por OSGi para tecnolog´ıas Jini, http y plug and play son la base para plantear la funcionalidad del modelo.
Considerando que hasta el momento OSGi, no ha definido una interface aceptada por el est´andar, abre una ventana de posibilidades de proveer una soluci´on. La soluci´on debe aprovechar las ventajas y expectativas de flexibilidad que las comunicaciones inal´ambricas ofrecen.
Asi mismo, en la validaci´on del modelo se realizar´a un prototipo con Bluetooth que demuestre que los problemas planteados en esta propuesta son resueltos. Bluetooth es una tecnolog´ıa que se considera con mayor auge en estos momentos y se visualiza mayor aceptaci´on en el futuro.
1.3.
Objetivos
1.3.1.
Objetivo General
CAP´ITULO 1. INTRODUCCI ´ON
1.3.2.
Objetivos Espec´ıficos
1. Definir el modelo de interacci´on entre el dispositivo m´ovil y el gateway de OSGi para integrarlo a la red dom´otica. El dispositivo debe de ser registrado, configurado, activado, actualizado y/o desinstalado de manera transparente dentro de la red; tal como es especificado en OSGi [7].
2. Definir el modelo de interacci´on entre el OSGi y el dispositivo m´ovil. El dispositivo debe accesar a los servicios que son proporcionados dentro de la red dom´otica por medio de la pasarela de servicios de OSGi. 3. Definir el modelo para satisfacer las caracter´ısticas inherentes de la
movilidad y el enlace espont´aneo de los dispositivos inal´ambricos. Estas caracter´ısticas son: el descubrimiento, la autentificaci´on, la b´usquedad y provisi´on de los servicios locales dependientes de la posici´on y la identificaci´on del dispositivos [6].
1.4.
Alcances
Sobre el Modelo:
1. Proponer un modelo gen´erico para resolver la interoperabilidad de OSGi con las diferentes tecnolog´ıas inal´ambricas.
2. El modelo deber´a abstraer las caracter´ısticas de los ambientes m´oviles y proponer un middleware que integre los dispositivos. 3. El dispositivo deber´a de quedar disponible para la acceso y control
a trav´es de mecanismos eficientes que minimicen el n´umero de interfaces.
Sobre la validaci´on del modelo:
1. El modelo ser´a validado por medio de la realizaci´on de un prototipo utilizando la tecnolog´ıa Bluetooth y el framework Knopflerfish de OSGi.
CAP´ITULO 1. INTRODUCCI ´ON
Sobre el prototipo:
1. El prototipo deber´a permitir determinar la efectividad del modelo propuesto.
2. El prototipo ser´a implementado en java para compatibilidad con OSGi.
3. Se usar´a un PDA como dispotivo m´ovil y una laptop como pasarela servicios que ejecute Knopflerfish y con el respectivo adaptador bluetooth.
Limitaciones: El middleware prototipo se enfocar´a sobre Bluetooth y explor´a sus caracter´ısticas. El descubrimiento del dispositivo se realizar´a en base a las especificaciones.
Futuros trabajos: Construcci´on del middleware completo para integrar a OSGi.
1.5.
Hip´
otesis
Proponer un modelo gen´erico e integrador de redes inal´ambricas para las redes dom´oticas orientado a servicios OSGi, puede:
Ofrecer mayor portabilidad.
Minimizar el n´umero de interfaces para garantizar la interoperabilidad Proporcionar mayor nivel flexibilidad y transparencia de acceso a los servicios m´oviles.
1.6.
Metodolog´ıa
CAP´ITULO 1. INTRODUCCI ´ON
Cap´ıtulo 2
OSGi en las Redes Dom´
oticas
OSGi (Open Services Gateway Iniciative) es una alianza formada en 1999 con el objetivo de crear una especificaci´on de referencia completa, no restrictiva, abierta y no normativa para redes y dispositivos de ´area local. Para ello, la alianza cuenta con la participaci´on y el respaldo de las compa˜n´ıas m´as importantes de software y hardware como IBM, SUN, Wirlhpool, Intel, etc [1].
Inicialmente la misi´on fue especificar top boxes y pasarelas de servicios para hogares, pero actualmente la especificaci´on esta siendo usada en automatizaci´on industrial, automovil´ıstica y telem´atica. As´ı, la especificaci´on intenta cubrir sus requerimientos, proporcionando comunicaci´on entre varios dispositivos de una red local como una casa, oficina o autom´ovil. Adem´as, OSGi promueve el descubrimiento y la colaboraci´on din´amica de dispositivos y servicios de los diferentes proveedores.
Otro de los objetivos de OSGi, es presentar un modelo arquitectural que describe los escenarios posibles de los casos de negocio. El modelo abierto propone esquemas de implementaci´on de las redes de manera adaptable a las caracter´ısticas del ambiente y en diferentes esquemas de negocio, como se muestra en la figura 2.1. Asimismo, proporciona referencias distribuidas y centralizadas para la provisi´on de los servicios. En ellas, la infraestructura de comunicaci´on, los proveedores, el cliente y los servicios, interoperan a trav´es de la pasarela1
basada en OSGi.
1
CAP´ITULO 2. OSGI EN LAS REDES DOM ´OTICAS
Figura 2.1: Entorno Adaptable de Redes Dom´oticas en Pasarelas Residenciales.
2.1.
Caracter´ısticas Generales de OSGi
Seg´un [1], OSGi incluye las siguientes caracter´ıstcas:
Propone una especificaci´on abierta y un framework basado en componentes para aplicaciones orientadas a servicios.
Ofrece la instalaci´on de nuevos componentes y aplicaciones, inter-operando por medio de programaci´on de APIs que pueden ser importandas o exportadas entre aplicaciones, denominadas bundles. El ambiente de ejecuci´on del framework es un modelo cooperativo que permite de manera flexible el descubrimiento, el registro y la actualizaci´on de las aplicaciones instaladas en ´el.
Incluye un manejador de aplicaciones que permite instalar aplicaciones de manera transparente para los desarrolladores.
Incluye un conjunto de servicios de sistema y est´andares para el soporte de las aplicaciones como logTracker, http, xml, IO, bootloader, entre otros.
2.2.
La Especificaci´
on OSGi
La especificaci´on abierta de OSGi consta de tres secciones importantes2
, donde se describen los aspectos b´asicos y estrat´egicos que deben cumplir las
2
CAP´ITULO 2. OSGI EN LAS REDES DOM ´OTICAS
implementaciones del framework[16]. Estas son:
1. Secci´on de referencia. Es comprendida por documentos de referencia sobre arquitecturas, modelos, terminolog´ıa e informaci´on relacionados para la implantaci´on de soluciones basadas en OSGi.
2. Secci´on Normativa. Incluye la descripci´on detallada del framework. Se compone por el conjunto de clases con sus m´etodos y propiedades que debe cumplir las implementaciones, como son: elbundle,bundlecontext, servicios, registros, eventos, notificaciones, permisos, conectores de entrada y salida, registros, ambientes de ejecuci´on, posicionamiento y medidas.
3. Secci´on Recomendada. Incluye un conjunto de especificaciones para
bundles de aplicaci´on que han sido aceptados por OSGi, como lo son
Jini, Http UPnp. El objetivo es continuar con la compatibilidad para protocolos de comunicaci´on de servicios Jini, UPnP y Http en las diferentes versiones.
2.3.
Los Modelos Arquitecturales para
Solu-ciones basadas en OSGi
CAP´ITULO 2. OSGI EN LAS REDES DOM ´OTICAS
[image:26.612.229.382.140.236.2]identificador de la plataforma de servicios, el cual ser´a asignado por operador.
Figura 2.2: Elementos de Modelos de Negocio basados en OSGi. De esta manera, el est´andar describe los siguientes cuatro modelos
propuestos:
1. Modelo de Pasarela de Servicios. Representa una referencia para la especificaci´on de sistemas basados en pasarelas residenciales a gran escala. Divide el escenario en dos ambientes definidos como la residencia y la localizaci´on del operador. El operador define los roles del proveedor de servicios, quien desarrolla, instala y mantiene los servicios a trav´es de la pasarela del operador. ´Esta a su vez, se conecta a la residencia por medio de la infraestructura de red, donde se ubica la pasarela y la plataforma de servicios. La pasarela ofrece los servicios del operador dentro de la red local y los dispositivos locales. La red local de dispositivos var´ıa seg´un el tipo de servicio y de mercardo. Las tecnolog´ıas t´ıpicamente usadas en la red local son: EIB, Ethernet, WiFi, IEEE 1394, entre otros. Mientras, para el proveedor de la WAN, puede ser DSL, Ethernet o redes de celulares(GSM, AMPS).
2. Modelo Industrial. Es recomendado cuando se desea un acceso remoto a trav´es de computadora, pero no hay un modelo de acceso al proveedor de servicios. Un ejemplo es el acceso mediante una conexi´on de celular. Este modelo implica problemas de interoperabilidad. Sin embargo la propuesta es: un operador del celular encargado de la provision de servicios, conectado por una estaci´on de la c´elula, la cual es el punto de acceso a la plataforma de servicios remota.
CAP´ITULO 2. OSGI EN LAS REDES DOM ´OTICAS
computadora y dispositivos conectados por medio un enruteador con ethernet o WiFI, pero incluye un enlace de intercambio privado. 4. Modelo de Pasarela Virtual. Considera que la pasarela no esta
localizada en la residencia, por lo que los servicios son controlados por medio de la red. La ventaja es que el sistema puede ser contralado por el operador en su mayor parte, pero la conexi´on de los dispositivos es m´as complicada de manera local.
2.4.
El Framework de OSGi
El framework de OSGi es un modelo conciso y consistente para desarrollo de aplicaciones basado en bundles. B´asicamente, simplifica la implementaci´on de aplicaciones utilizando los servicios a trav´es de interfaces y componentes. Adem´as, proporciona mecanismos para la instalaci´on de bundles, resoluci´on autom´atica de dependencias e interacci´on de modelos de ejecuci´on orientados a eventos y servicios.
2.4.1.
La Arquitectura del Framework
La arquitectura de framework se basa en un conjunto de bundles
que pueden correr sobre dispositivos compatibles con java. Los bundles
son aplicaciones que pueden ser instaladas, actualizadas y desinstaladas din´amicamente. Los bundles contienen mecanismos y algoritmos para controlar dispositivos individuales. Algunos de ellos son b´asicos para la operaci´on del framework, mientras que otros interactuan con ´el para formar una plataforma de servicios [14].
De manera general, la arquitectura se compone de las siguientes capas que se muestran en la figura 2.3:
CAP´ITULO 2. OSGI EN LAS REDES DOM ´OTICAS
Figura 2.3: Arquitectura de Capas de OSGi.
3. M´odulos. Esta capa resuelve la cooperaci´on y dependencias entre bundles. Define la forma transparente de importar y exportar los bundles dentro de paquetes.
4. Administraci´on del Ciclo de Vida. Encapsula los mecanismos para que los bundles puedan ser instalados, iniciados y activados; o bien detenidos y desinstalados. Estos procesos son realizados mediante el
Manifesto incluido en los archivos JAR de los bundles. El manifiesto contiene informaci´on sobre dependencias, versiones y servicios del bundle que son requeridos para su instalaci´on en el framework.
B´asicamente, el diagrama de clases del framework mostrado en la figura 2.4, incluye las siguientes caracter´ısticas agrupadas en 4 puntos principales:
1. Controlador de Bundles. Implementa las interfaces de BundleAc-tivator y bundle. Se encarga del ciclo de vida de bundles(instalar, resolver, iniciar, detener y desinstalar). Adem´as, controla elclassloader, a trav´es del encabezado del manifiesto. Se comunica con el manejador de servicios y con el m´odulo de seguridad para definir la resoluci´on de los servicios.
CAP´ITULO 2. OSGI EN LAS REDES DOM ´OTICAS
Figura 2.4: Diagrama de Clases del Framework de OSGi.
3. El framework. Implementa la interfaz Bundle Context que permite controlar el acceso a los bundles en ambiente de ejecuci´on. Implementa los eventos y los listeners para registrar actividades de bundles y agregar o eliminar servicios. Maneja los eventos de framework sobre la inicializaci´on del sistema y su contexto, adem´as se comunica con el administrador de bundles. De la misma forma, realiza el manejo de excepciones y de constantes que sean utilizadas. Por ´ultimo, define aspectos del ciclo de vida de los bundles.
CAP´ITULO 2. OSGI EN LAS REDES DOM ´OTICAS
plataforma de seguridad definida por Java.
5. Servicio de Registro. Facilita la administraci´on de los bundles activos o eliminados, con el objetivo de realizar un control din´amico de bundles. 6. Servicios Est´andares : La version 3 del framework, mostrada en la
[image:30.612.231.380.204.290.2]figura 2.5, incluye:
Figura 2.5: Servicios del Framework de OSGi.
Servicios del Framework: Bundles enfocados a administraci´on, accesos y manejadores de URL.
Servicios del Sistema: Administraci´on de Accesos. Servicios de protocolo: Http, UPnp y Jini.
Servicios Miscel´aneos: Wire Admin, XML y Axis.
2.4.2.
Bundles
Un bundle es un archivo JAR que son entidades de instalaci´on para almacenar aplicaciones y sus recursos. Las relaciones y dependencias son implementadaas por el Bundle Activator, quien controla las actividades de iniciar, resolver, actualizar y eliminar los bundles. As´ı, el mismo framework representa un Bundle, el cual es denominado System Bundle y se le asigna el identificador cero.
De manera general, pueden definirse las siguientes caracter´ısticas de los bundles:
CAP´ITULO 2. OSGI EN LAS REDES DOM ´OTICAS
Est´an asociados a un espacio de nombres definido en la base de datos de los bundles instalados. La base de datos es consultada para resolver cualquier servicio de los bundles.
Tiene definido un ambiente de ejecuci´on en el framework y durante el tiempo de activaci´on, dependiendo de los permisos y el classpath
asignados en el encabezado.
Existen reglas definidas para la b´usqueda de clases y recursos proporcionadas por elclassLoader, el cual responde a las solicitudes de otros servicios para resolver dependencias y asociaciones de los bundles.
Bundle Object
Para todo bundle instalado existe su correspodiente Bundle Object y ´este objeto permite manejar el ciclo de vida de un bundle. Un objetoBundle tiene las siguientes caracter´ısticas:
1. Tiene asociado un identificador ´unico y una localizaci´on asignada durante la instalaci´on.
2. Los estados de un bundle son: instalado, resuelto, iniciado, detenido, activado y desinstalado.
3. Un bundle pude ser instalado solo s´ı las dependencias han sido resueltas. Si las dependencias no se resuelven, entonces el bundle pasa al estado de iniciado.
4. Cuando un bundle objeto es detenido, los objetos que importaron dicho objeto pueden continuar accesando c´odigo de ´este.
5. El framework debe de garantizar que a trav´es del proceso de
actualizaci´on, exista solamente una versi´on activada, importada y exportada en el framework.
CAP´ITULO 2. OSGI EN LAS REDES DOM ´OTICAS
Bundle Context
El bundle Context representa el objetoproxy entre los bundles instalados y los objetos en contexto de ejecuci´on para el framework. Es el reponsable de regresar la informaci´on del objeto en ejecuci´on como la versi´on, vendedor, procesador, etc. Cuando un bundle es iniciado, se crea un objeto de contexto para mantener la persistencia de almacenamiento al bundle instalado.
2.4.3.
Objetos para los Servicios.
La cooperaci´on entre los servicios es soportada por medio de objeto
service controller, el cual implementa las interfaces service registration,
service reference y service event. La interfaz de servicio de registro mantiene actualizada la base de datos de servicios instalados en el framework. La interfaz de servicios de referencia encapsula la informaci´on del servicio que representa. Mientras la interfaz de eventos se encarga de resolver/notificar los cambios de estado de los servicios instalados.
De esta froma, cuando un nuevo servicio es instalado en el framework, el controlador de servicios se encarga de registrar el nuevo objeto. Si un objeto es registrado exitosamente, entonces el servicio regresa un objeto de
ServiceRegistration y genera un ServiceListener basado en el concepto de
callbacks de java. Por otro lado, las propiedades del registro y los datos que se guardan durante el proceso de registro, forman un diccionario de llaves que permite realizar filtros para acceder a los objetos. Adem´as, con ello se lleva el registro del uso de los servicios al incrementarse dependiendo los accesos al objeto de Contexto.
El acceso a la informaci´on de los servicios se realiza por medio de dos m´etodos implementados por la interfaz: getRegisteredServices() y
getServicesinUse().
Los Filtros
CAP´ITULO 2. OSGI EN LAS REDES DOM ´OTICAS
Service Factories
El objetivo de esta interfaz es generar objetos que puedan ser configurables, dando la flexibilidad al framework para realizar las actividades de registro. Remplazan la opci´on de implementar listeners, en lugar de ello, este servicio notifica cuando un objeto ha cambiado. Entonces, los m´etodos se encargan de resolver las dependencias, de llevar el n´umero de usos del servicio a cero, entre otras cosas.
2.4.4.
Eventos
El framework soporta tres tipos de eventos:
1. Eventos de Servicio. Reporta las actividades de registro y eliminaci´on del registro de los objetos de servicios.
2. Eventos de Bundles. Reportan los cambios en el ciclo de vida de los bundles.
3. Eventos del Framework. Reporta cambios sobre cambios en el framework.
2.4.5.
Listeners
Proporcionan interfaces asociadas a los servicios, bundles y el framework para notificar que se ha agregado un servicio, un nuevo bundle o ha cambiado alg´un evento.
2.4.6.
Especificaci´
on de Acceso a los Dispositivos
CAP´ITULO 2. OSGI EN LAS REDES DOM ´OTICAS
No obstante, esta especificaci´on deliberadamente no prescribe alg´un dispositivo o tecnolog´ıa de red en particular. La especificaci´on se centra en el agregado de dispositivos alimentados por diferentes vendedores. Esto enfatiza el desarrollo de interfaces de dispositivos estandarizados para ser definidos en categor´ıas de dispositivos, aunque tales categor´ıas de dispositivos no son definidas en esta especificaci´on 3
.
Operaci´on
La especificaci´on define el comportamiento del manejador del dispositivo. Detecta el registro del servicio del dispositivo y es responsable por la asociaci´on de estos con el apropiado servicio del driver. Se hace con la ayuda de los servicios del localizador de controladores y del selector de controladores que permiten al manejador encontrar un Driver Bundle e instalarlo.
Servicios de Dispositivos
Los servicios de dispositivos pueden variar ampliamente: algunos representan dispositivos f´´ısicos individuales y otros representan redes completas. Muchos servicios de dispositivos pueden simult´aneamente representar al mismo dispositivo f´ısico a diferentes niveles de abstracci´on, por ejemplo:
1. Una red conectado mediante USB.
2. Un dispositivo adherido sobre una red USB.
3. El mismo dispositivo reconocido como USB o un puente Ethernet. 4. El mismo dispositivo reconocido en una Ethernet.
5. El mismo en una impresora.
Un dispositivo tambi´en puede ser representado en diferentes caminos, un rat´on USB puede ser considerado como un dispositivo USB el cual entrega
3
CAP´ITULO 2. OSGI EN LAS REDES DOM ´OTICAS
informaci´on sobre el bus USB o como un dispositivo Mouse el cual entrega coordenadas acerca de su estado.
Cada representaci´on tiene implicaciones espec´ıficas, as´ı los servicios de dispositivos pertenecen a una categor´ıa de dispositivos definida. Una categor´ıa de dispositivos especifica el m´etodo para la comunicaci´on con un servicio de dispositivos, y habilita interoperabilidad entre los bundles que son basados en la misma base tecnol´ogica.
2.4.7.
Especificaci´
on de Servicios Jini
Jini es un middleware de red para computaci´on ubicua basada en Java para crear una federaci´on o servicios que trabajan juntosde m´aquinas virtuales [22]. Es una capa de software que proporciona la informaci´on de dispositivos para ser agregados directamente a la red sin tratamiento de controladores y configuraci´on del sistema operativo. As´ı, Jini es considerado como una soluci´on de software para redes residenciales de SunMicrosystem.
Los objetivos de Jini son:
1. Compartir recursos y servicios sobre una red.
2. Proporcionar acceso a los recursos de la red en cualquier lugar.
3. Ofrecer un ambiente programaci´on basado en patrones para el desarrollo robusto de sistemas distribuidos.
4. Simplifica la tarea de construcc´on y mantenimiento de software para los usuarios.
5. Una de las fortazalezas es estar compuesto por protocolos llamados
discovery, join, y lookup.
La Especificaci´on Jini en OSGi
CAP´ITULO 2. OSGI EN LAS REDES DOM ´OTICAS
por los diferentes proveedores de aplicaciones OSGi. Entonces, se pretende cumplir con tres puntos esenciales: transparencia, capacidades de exportaci´on e importaci´on de los servicios.
[image:36.612.172.440.192.401.2]Para cumplir con estos puntos, el diagrama de clases del est´andar que se muestra en la figura 2.6, puede dividirse en los siguientes puntos importantes:
Figura 2.6: Diagrama de Clases para la especificaci´on Jini.
1. Servicio de Importaci´on. Es servicio permite que por cada servicio Jini, no se agregue un servicio en OSGi, sino que el driver es quien controla el acceso a los dispositivos. Entonces, el driver es quien mantiene la lista de los servicios que son registrados en la red Jini. Cuando un servicio es imporatdo, se agrega informaci´on sobre device category, service id y entries.
CAP´ITULO 2. OSGI EN LAS REDES DOM ´OTICAS
3. Proxy o Bundle Jini Driver. Transforma cualquier servicio Jini descubierto en la red y lo transforma en un servicio registrado para OSGi.
4. Jini Interfaz. Representa la interfaz del dispositvo Jini. Modo de Operaci´on.
Cuando un dispositivo Jini es agregado a la red, ´este usa un protocolo adicionado, denominado discovery and join, el cual registra el servicio con el ServiceRegistrar class de Jini. Cuando un dispositivo proporciona un servicio, se ejecuta el servicio de lookup y ´este descarga el objeto usando la serializaci´on. Entonces, el driver de OSGi debe registrar los servicos de OSGi para importar los servicios dentro del ambiente de OSGi. El driver
Jini debe estar escuchando si la red Jini descubre un nuevo dispositivo. Cuando ocurre este evento, el driver debe regresar el objeto proxy para que el servicio sea registrado en OSGi usando ServiceRegister. Cuando los servicios son registrados en el framework, el driver tambi´en debe manejar el ciclo de vida de los servicios tanto en OSGi como en Jini. El driver de Jini carga los c´odigos de otras m´aquinas virtuales y ejecuta este c´odigo en el ambiente de OSGi.
De esta forma, el framework de OSGi registra los objetos de servicios bajo el nombre de la interfaz, la cual debe ser importada por otro bundle. Cada interfaz de servicio registrado debe ser exportada por uno o m´as bundles. Esto implica que el driver de Jini debe asegurarse que los objetos de Jini soporten la interfaz m´as reciente de manera din´amica.
2.4.8.
Especificaci´
on UPnp con OSGi
UPnp (Universal Plug and Play) es un est´andar que se caracteriza por soportar cero configuraci´on de los dispositivos, una operaci´on de red transparente y descubrimiento autom´atico. As´ı, un dispositivo UPnp puede agregarse a la red, obtener una direcci´on IP y ofrecer servicios de manera autom´atica. Para ello, UPnp utiliza los protocolos TCP/IP para publicar sus servicios usando una interfaz XML. As´ı, el servicio del dispositivo UPnp puede ser llamado, accesado u operado a trav´es del uso de la interfaz.
CAP´ITULO 2. OSGI EN LAS REDES DOM ´OTICAS
manejados en un sistema remoto. Es decir como desarrollar bundles que puedan interoperar con dispositivos y puntos de control.
La Arquitectura OSGi-UPnp
[image:38.612.172.440.267.443.2]B´asicamente, la especificaci´on del dispositivo UPnp en OSGi, esta orientada a la integraci´on del servicio, para que ´este sea visto como un servicio de OSGi y pueda ser usado dentro del framework. Para ello, el diagrama de clases que se muestra en la figura 2.7, se integra de los siguientes elementos importantes:
Figura 2.7: Diagrama de Clases para la Especificaci´on UPnp.
1. Servicio. El servicio es formado por los objetos de servicio, acciones y variables.
2. Dispositivo. El dispositvo implementa los servicios del UPnp.
3. Driver. El driver permite administrar los servicios que son registrados en el framework, a la vez sirve como proxy con los dispositivos.
CAP´ITULO 2. OSGI EN LAS REDES DOM ´OTICAS
El driver UPnp debe manejar la funcionalidad del protocolo y la interacci´on con los bundles UPnp. As´ı, cuando un nuevo dispositivo es detectado en la red, el dispositivo es registrado en OSGi usando la interfaz
service.
2.5.
Implementaciones del Framework de
OSGi
Actualmente, el framework de OSGi ha sido implementado por varios investigadores y empresas que demuestran su operabilidad y viabilidad. Dentro de las implementaciones libres se encuentran:
1. OSCAR. Es una implementaci´on de la versi´on 2 y 3 del framework. Se enfoca a proporcionar un ambiente din´amico de componentes. Proporciona un framework ligero que se puede configurar dependiendo de las necesidades y capacidades de las pasarelas. Incluye un repositorio de bundles y un ambiente de desarrollo.
2. Knopflerfish. Es una versi´on abierta basada en la versi´on propietaria Ubiserv. Incluye un administrador y librer´ıas para bundles en entorno gr´afico. Adem´as, proporciona unplug-in de desarrollo bajo entorno de eclipse.
3. Java Embedded Server. Es la implementaci´on propuesta por Java Sun para version 1.0 del framework de OSGi.. Se caracteriza por ser muy ligero y proveer solamente los servicios elementales para la administraci´on de bundles [35].
Adem´as, existen versiones propietarias como:
CAP´ITULO 2. OSGI EN LAS REDES DOM ´OTICAS
dise˜nado para realizar pruebas de las aplicaciones en un ambiente gr´afico. Adem´as, ofrece caracter´ısticas basadas en el ambiente de desarrollo WSDD, como lo son el cargador de clases y la administraci´on de los recursos [15].
2. Prosyst. En mBedded Server 5.2 facilita un entorno especializado de desarrollo para aplicaciones basadas en OSGi versi´on 3 y 4. Incluye versiones para manejo de dispositivos m´oviles para arquitecturas OMA4
. Adem´as incluye librer´ıas para administraci´on y aplicaciones gr´aficas y un plug-in para JBuilder [29].
2.5.1.
Knopflerfish
Knopflerfish es un proyecto creado para el desarrollo y distribuci´on de c´odigo, herramientas y aplicaciones basadas en OSGi. Se considera una versi´on robusta, que est´a contin´uamente actualizada. Actualmente, la implementaci´on del framework corresponde a la versi´on 3, ya que la versi´on 4 fue liberada en el mes octubre de 2005.
2.5.2.
Componentes del Framework Knopflerfish
Como parte de la implementaci´on, se incluyen los siguiente servicios y componentes [20]:
Base framework. Soporta el ciclo de vida de los bundles. Contiene los siguientes componentes:
• Servicio de Administraci´on de Paquetes. • Servicio de Administraci´on de Permisos. • Servicio StartLevel.
• Servicio URL.
Utlier´ıa de Seguimiento de Servicios. Servicio de registros.
4
CAP´ITULO 2. OSGI EN LAS REDES DOM ´OTICAS
Servicio HTTP.
Manejador de Configuraci´on. Maneja el almacenamiento persistente de los datos de aplicaci´on.
Manejador de dispositivos. Maneja los componentes de software relacionados con los controladores de los dispositivos f´ısicos.
Servicio de Administraci´on de Usuarios. Funcionalidad de control de accesos de usuarios.
Servicios de Preferencias.
Posicionamiento. Manejador de posiciones. Manejador de unidades.
Metatype API. Permite que las aplicaciones puedan publicar informaci´on.
Utiler´ıa XML. Proporciona clases template para traductores XML. Instalaci´on Remota
Cap´ıtulo 3
Ambientes Dom´
oticos basados
en Tecnolog´ıas Inal´
ambricas
La comunicaci´on en los ambientes dom´oticos orientados principalmente al control y el monitoreo de dispositivos y aplicaciones, tiene retos importantes por resolver y fortalecer. Las soluciones est´an basadas en la simplicidad, la transparencia de conexi´on, disponibilidad y facilidad de uso para los usuarios. Dobrev [27], sugiere que a medida que estos cuatro puntos sean cubiertos, la tecnolog´ıa ser´a menos costosa y m´as f´acil de proporcionar a los hogares.
CAP´ITULO 3. AMBIENTES DOM ´OTICOS BASADOS EN TECNOLOG´IAS INAL ´AMBRICAS
mencionados en esta secci´on.
3.1.
Clasificaci´
on de las Redes Inal´
ambricas
Las tecnolog´ıas inal´ambricas abarcan un conjunto de redes, cuya transmisi´on de datos, audio y video se realiza mediante ondas de radio. Dependiendo del alcance de la comunicaci´on y las frecuencias utilizadas, existen las siguientes cuatro categor´ıas [23]:
1. Redes de Area PersonalWPAN (Wireless Personal Area Network). Son aquellas que permiten comunicaci´on entre los dispositivos electr´onicos de la persona, tales como PDA, computadoras, aud´ıfonos, tel´efonos, etc. Se caracterizan por proporcionar comunicaci´on de corto alcance, bajo consumo de energ´ıa, bajo costo y por formar redes de espacios peque˜nos. La interoperabilidad y la cobertura representan sus dos principales metas. Dentro de los est´andares l´ıderes se encuentran: IrDA, Bluetooth, 802.15 y ZigBee.
2. Redes Inal´ambricas de Area Local WLAN (Wireless Local Area Network). Representan soluciones para espacios definidos como oficinas, corporaciones, hoteles, aeropuertos, etc. Son usados para ahorrar costos, evitar tendidos de cable o proveer accesos r´apidos a Internet. Tienen cobertura aproximada de 50 hasta 150 metros con rendimiento de 1 a 54 Mbps. Los consumos de energ´ıa dependen de los productos, mientras que los costos var´ıan dependiento de las caracter´ısticas de instalaci´on y el est´andar propuesto. Las configuraciones pueden ser por puntos de accesos o peer-to-peer, siendo ´este ´ultimo el m´as com´un para integrar puntos de acceso extendidos. Los est´andares conocidos son especificados por tres vertientes: IEEE y ETSI(European Telecommunications Standards Institute) y la alianza HomeRF. El est´andar l´ıder es 802.11b o WiFi, pero tambi´en existen 802.11a, 802.11g y HIPERLAN/1 y 2.
CAP´ITULO 3. AMBIENTES DOM ´OTICOS BASADOS EN TECNOLOG´IAS INAL ´AMBRICAS
frecuencias con licencia. La calidad y la velocidad depende de la tecnolog´ıa utilizada, mientras que el costo y la cobertura depende de la red. Inicialmente eran redes anal´ogicas y han evolucionado a redes digitales, proporcionando mayores beneficios. Estas tecnolog´ıas han mejorado sus caracter´ısticas de desempe˜no y los servicios ofrecidos en tres generaciones. Actualmente, la tercera generaci´on est´a orientada a proporcionar servicios de alta calidad y de alta velocidad, cuyos est´andares est´an regulados por la asociaci´on GSM, el grupo CDMA, el foro UMTS, Mobitex y Motorola.
4. Redes Satelitales. Originalmente fueron propuestas para sistemas de comunicaci´on de voz y datos con cobertura en todo el planeta, sin necesidad de puentes entre dispositivos. Sin embargo, ´estas han resultado soluciones muy caras que pueden ser remplazadas por redes de ´area amplia. Actualmente, se utilizan para soluciones de localizaci´on. Su velocidad var´ıa de 2.4 kbps a 2 Mbps. Algunos de los proveedores de servicios de redes satelitales son: Iridium, GlobalStart, Teledesic, Asia Cellular Satellite, entre otros.
Dentro de los ambientes dom´oticos, las redes personales representan mayor potencial para comunicar dispositivos dentro de espacios definidos con personas autorizadas. Por ello, a continuaci´on se revisan a detalle las redes basadas en IrDA, Bluetooth, 802.15 y Zigbee.
3.1.1.
IrDA
CAP´ITULO 3. AMBIENTES DOM ´OTICOS BASADOS EN TECNOLOG´IAS INAL ´AMBRICAS
3.1.2.
Bluetooth
Es una tecnolog´ıa para aplicaciones m´oviles que no requiere la vista entre los dispositivos, como en el caso de IrDA. Permite la comunicaci´on a trav´es de barreras f´ısicas en un rango de 10 a 100 metros para voz y datos. Transmite a una frecuencia 2.4GHz con m´aximo de 720 Kbps. Proporciona el descubrimiento del dispositivo con conexi´on punto a punto o multipunto. Dos o m´as dispositivos conectados forman un piconet en una red ad hoc con un m´aximo de 8 dispositivos. En el caso de redes con m´as de 8 dispositivos, deben formar una configuraci´on de scatternet, en la que los dispositivos son disponibles a trav´es de los piconets. La especificaci´on de Bluetooth describe una arquitectura de capas basada en una pila de protocolos, como lo muestra la figura 3.1. La capa f´ısica incluye laHost Controller Interface para comunicarse con la capa de Link Manager. La siguiente capa es denominada Logical Link Control Adaptation Protocol (L2CAP), que es un protocolo multiplexado en varios protocolos, como Service Discovery Protocol (SDP),
Object Exchange Protoco (OBEX) y RFCOMM. Uno de los m´as usados es el RFCOMM, el cual emula la interfaz de puerto serial por medio de m´odulos de hardware que proporcionan la interfaz RS232 o RS485. A nivel de ´esta capa, es necesiario levantar un servicio SPP(Serial Port Profile) que le permite comunicaci´on basada en la interfaz serial.
3.1.3.
802.15
CAP´ITULO 3. AMBIENTES DOM ´OTICOS BASADOS EN TECNOLOG´IAS INAL ´AMBRICAS
Figura 3.1: Pila de Protocolos de Bluetooth. aumenta la confiabilidad.
3.1.4.
Zigbee
CAP´ITULO 3. AMBIENTES DOM ´OTICOS BASADOS EN TECNOLOG´IAS INAL ´AMBRICAS
Figura 3.2: Pila de Protocolos de Zigbee y 802.15.4.
3.2.
Principios de Dise˜
no en Ambientes
M´
oviles
Dise˜nar espacios inteligentes integrados por diferentes tipos de elec-trodom´esticos, computadoras, dispositivos personales y de oficina, es parte de los expectativas de las redes dom´oticas, la computaci´on m´ovil y ubicua [36]. El prop´osito es lograr que el usuario pueda percibir un entorno transparente y sencillo, como actualmente sucede al adquirir una televisi´on o un dvd. Al usuario no le importa el proveedor o la forma de comunicaci´on del dispositivo, ya que s´olo le preocupa usar el dispositivo de forma sencilla. Sin embargo, lograr estas caracter´ısticas deseables a´un resulta muy costoso debido a la falta de una infraestructura est´andar de hardware y software que oculte aspectos complejos de dise˜no. Esta infraestructura debe satisfacer medios interoperables de comunicaci´on, de control y organizaci´on entre los diferentes dispositivos. Por ello, es necesario un middleware que combine las caracter´ısticas del hardware y la tecnolog´ıa de software que soporte la cooperaci´on arm´onica de ellos. Este middleware debe ser utilizado por los desarrolladores de aplicaciones quienes solamente se enfocan en la aplicaci´on del usuario; sin necesidad de involucrarse en los aspectos del ambiente y as´ı disminuir los costos de desarrollo o construcci´on.
3.2.1.
Complejidad de los Ambientes M´
oviles
CAP´ITULO 3. AMBIENTES DOM ´OTICOS BASADOS EN TECNOLOG´IAS INAL ´AMBRICAS
1. Abtracci´on. Representa el nivel de abstracci´on deseado para el desarrollo de las aplicaciones y la dificultad de los algoritmos para el programador.
2. Ocultamiento de la complejidad. Representa las caracter´ısticas que se desean ocultar por el middleware, como son los aspectos de la distribuci´on, la reconfiguraci´on din´amica, autoconfiguraci´on, la interacci´on, el descrubrimiento y la personalizaci´on.
3. Reducci´on de costos. Representa los niveles de reutilizaci´on para las aplicaciones basadas en el middleware.
En el mismo sentido, en [24] [21] consideran que la complejidad depende tambi´en de la integraci´on de los diferentes protocolos de comunicaci´on entre los dispositivos. Si el middleware se dise˜na para utilizar interfaces de manera espec´ıfica, es decir, interfaces dependientes del protocolo, la complejidad del middleware interoperable aumenta. Es decir,
O(n) = (α(n) +β(n) +γ(n))θ(n) (3.1) donde O(n) es la complejidad del middleware, θ(n) es la complejidad de las interfaces, las funciones α, β y γ, corresponden a la compejidad de abstracci´on, ocultamiento y reducci´on de costos, respectivamente.
Y adem´as:
θ(n) =mk (3.2) donde m el n´umero de interfaces para los protocolos diferentes de los k
dispositivos.
CAP´ITULO 3. AMBIENTES DOM ´OTICOS BASADOS EN TECNOLOG´IAS INAL ´AMBRICAS
3.2.2.
Requerimientos de los Ambientes M´
oviles
En [33] y [6] se define que los ambientes m´oviles son tambi´en sistemas distribuidos, cuyo dise˜no debe satisfacer los siguientes requermientos no funcionales distintivos:
1. Los elementos m´oviles tienenrecursos limitados comparados con los elementos est´aticos, como la velocidad del procesador y la capacidad de disco y memoria.
2. La movilidad es un problema deseguridadinherente, ya que el acceso a los dispositivos m´oviles es m´as suceptible a ataques de seguridad. 3. La conectividad m´ovil es altamente variable en rendimiento
y confiabilidad, debido a la disponibilidad del ancho de banda dependiente de la ubicaci´on.
4. Los elementos m´oviles dependen de la capacidad deenerg´ıadisponible. Estas restricciones afectan los esquemas tradicionales de dise˜no para los modelos de datos y de comunicaci´on en sistemas distribuidos, como cliente/servidor. Los modelos propuestos deben cubrir estos aspectos, buscando equilibrio entre el dinamismo y la adaptaci´on de la movilidad de los clientes.
La transparencia de movilidad es considerada un requerimiento funcional complejo que est´a fuertemente acoplado a las necesidades de las aplicaciones m´oviles. La tendencia es que la tecnolog´ıa sea transparente para los usuarios, lo cual ha propiciado la integraci´on de este requerimiento como parte del middleware. Para ello, se deriva en los siguientes requerimientos no funcionales[28]:
1. Asincron´ıa. Desacoplar los componentes del cliente y del servidor; adem´as del envi´o de mensajes en multidifusi´on.
2. Lightweight. Debe usarse la cantidad m´ınima de funcionalidad por la
mayor´ıa de las aplicaciones.
CAP´ITULO 3. AMBIENTES DOM ´OTICOS BASADOS EN TECNOLOG´IAS INAL ´AMBRICAS
1. Reconfiguraci´on din´amica. Debe permitir la detecci´on de cambios sobre los recursos disponibles, as´ı como la relocalizaci´on de ellos y la notificaci´on de los cambios.
2. Adaptaci´on. El sistema debe tener la habilidad para reconocer necesidades desconocidas y en tiempo de ejecuci´on adoptarlas para resolver la funcionalidad.
3. Context Awareness. El contexto debe ser considerado como una
capa que vigile las caracter´ısticas del dispositivo, las actividades del usuario y el estado de los servicios.
La informaci´on del contexto es un elemento b´asico para satisfacer estos requerimientos funcionales, es por ello que el context aware computing se encarga de proporner modelos para descubrir y reaccionar a los eventos del entorno ante la dificultad de la adquisici´on de la informaci´on [38]. Las aplicaciones dependen del tipo de informaci´on recabada, la cual es procesada con el fin de definir las acciones pertinentes en el sistema. Por lo tanto, es deseable que el middleware proporcione mecanismos y componentes para monitorear el ambiente de diferentes recursos, procesar los datos de manera heterog´enea y almacenar el contexto. Adem´as, incluir los mecanismos de env´ıo de mensajes y la posibilidad de publicar las interfaces a medida de lo posible.
3.3.
Arquitecturas orientadas a Ambientes
M´
oviles
CAP´ITULO 3. AMBIENTES DOM ´OTICOS BASADOS EN TECNOLOG´IAS INAL ´AMBRICAS
3.3.1.
Modelos basados en Cliente/Servidor
[image:51.612.227.380.297.390.2]Desde la perspectiva del modelo cliente/servidor para ambientes m´oviles, Satyanarayanan [33] propone un modelo extendido basado en el requerimiento de movilidad. Este modelo identifica c´omo los clientes y los servidores son diferenciados por la manera en que satisfacen los requerimientos no funcionales mencionados en la secci´on 3.2. Dichos requerimientos necesitan de operaciones que clientes tradicionales deben eliminar. B´asicamente, los clientes deben integran mecanismos para los estados de desconexi´on, replicaci´on, conectividad d´ebil, aislamiento de transacciones, m´etodos de caching, sem´antica de callbacks y validaciones, algoritmos de revocaci´on y an´alisis de adaptaci´on.
Figura 3.3: Ejemplo de Modelo Cliente-Servidor para Ambientes M´oviles. Por otro lado, considerando que los dispositivos m´oviles son limitados, los mecanimos deben ser ocultados por el middleware bajo dos tipos de modelos:
CAP´ITULO 3. AMBIENTES DOM ´OTICOS BASADOS EN TECNOLOG´IAS INAL ´AMBRICAS
Figura 3.4: Ejemplo de ArquitecturaSmart Client.
Figura 3.5: Ejemplo de Arquitectura Thin Client.
3.3.2.
Modelos basados en Arquitecturas Orientadas a
Servicios.
Desde el punto de vista de arquitecturas basadas en servicios [9], el dinamismo y la adaptaci´on de los dispositivos m´oviles es soportada por los servicios definidos en el modelo. Pueden ser modelos de comunicacion peer to peer o centralizados. En el primero se tiene comunicaci´on directa entre los dispositos, mientras que en el segundo se considera la participaci´on de un broker de comunicaci´on que resuleva las solicitudes a los servicios en la red. Ambos modelos deben proveer servicios de descubrimiento, extracci´on, selecci´on, invocaci´on y presentaci´on, tal como lo muestran los siguientes ejemplos de arquitecturas.
Thanh [38], considera que un servicio m´ovil dentro de una arquitectura SOA 1
, es una aplicaci´on realizada por varios servicios y componentes que interact´uan para garantizar la movilidad del cliente. Propone un
1
[image:52.612.229.384.253.360.2]CAP´ITULO 3. AMBIENTES DOM ´OTICOS BASADOS EN TECNOLOG´IAS INAL ´AMBRICAS
modelo centralizado y un middleware gen´erico m´ovil basado en siguientes componentes:
1. MobileService. Es la representaci´on completa del servicio. 2. ServiceLogic. Es la pieza ejecutable del servicio.
3. ServiceState. Son las variables de estado y los datos usados por el componente ServiceLogic.
4. ServiceContent. Representa la informaci´on que puede ser usada por otros servicios y que no representa estados de servicio.
5. ServiceContentMetaData. Representa informaci´on que puede ser usada junto con el componente Service Content.
6. ServiceProfile. Contiene informaci´on personalizada del servicio y del dispositivo m´ovil.
Estos componentes soportan el nivel de personalizaci´on de los clientes, cambios din´amicos entre los servicios a trav´es del descubrimiento del servicio, selecci´on de la l´ogica adecuada y la comunicaci´on entre ´estos. Dentro del descubrimiento debe cubrirse la identificaci´on del servicio, mientras que en la selecci´on y la l´ogica debe cubrirse un protocolo de comunicaci´on est´andar. Finalmente el autor, propone el controlador de movilidad, el cual coordina y transfiere los servicios, basados en las ontolog´ıas definidas en el serviceLogic y el serviceState.
Por su parte en [8], se describe una arquitectura orientada a satisfacer los requerimientos de adaptaci´on del contexto de servicios m´oviles. Propone identificar las interfaces de los ambientes f´ısicos e integrar medios de acceso a la arquitectura. Se identifica que el contexto es la informaci´on usada para caracterizar o describir el estado del entorno. La informaci´on puede ser clasificada en tres tipos de datos: est´aticos, din´amicos y de sesi´on. Los datos est´aticos son aquellos que tienen poco cambio tales como las cuentas de usuario y de servicios, mientras que los din´amicos representan los datos que cambian rapidamente como la localizaci´on o la orientaci´on. Los datos de sesi´on corresponden a los que indican aspectos de conexi´on y usuarios en el sistema, tales como historial o datos estad´ısticos.
CAP´ITULO 3. AMBIENTES DOM ´OTICOS BASADOS EN TECNOLOG´IAS INAL ´AMBRICAS
1. Sensor. Incluye el conjunto de componentes que ayudan a detectar y reportar datos din´amicos del contexto, as´ı como identificar las actividades locales de los usuarios.
2. Administraci´on de la sesi´on. Proporciona la funcionalidad necesaria para administrar la informaci´on de la sesi´on de los usuarios.
3. Manejador de Interfaces. Administra la entrada y salida entre dispositivos. Se encarga de la adaptaci´on de contenidos y optimizaci´on de salidas en las terminales de los usuarios.
4. L´ogica de servicio. Implementa la l´ogica de la aplicaci´on con adapataci´on a un contexto espec´ıfico.
Finalmente en [28], se propone otro enfoque basado en el manejo de los siguientes componentes para satificacer los requerimientos del cliente m´ovil: 1. Modelador del Servicio. Modela los servicios que pueden ser invocados desde una tarea con un dominio de aplicaci´on, incluyendo la implementaci´on y la administraci´on de los servicios.
2. Modelador del Sensor. Recolecta la informaci´on del contexto que es ejecutada de acuerdo a los servicios a trav´es del manejador de conexto. 3. Modelador del Ambiente. Representa un modelo abstracto del
ambiente f´ısico, pueden ser sensores, dispositivos u otros servicios. 4. Modelador del Usuario. Modela al usuario como un conjunto de
informaci´on, con organizaci´on, personalizaci´on y preferencias.
5. Modelador de Tareas. Define las tareas y la manera en que puede ser ejecutadas.
6. Modelador de Reglas. Define el conjunto de reglas que las tareas pueden ejecutar.
CAP´ITULO 3. AMBIENTES DOM ´OTICOS BASADOS EN TECNOLOG´IAS INAL ´AMBRICAS
3.3.3.
Arquitecturas M´
oviles basadas en OSGi
Las propuestas de integraci´on de ambientes m´oviles a la plataforma OSGi, var´ıan en enfoques y cobertura. En general, proponen soportar los requerimientos de movilidad y aprovechar las ventajes de OSGi como est´andar y como plataforma estable de instalaci´on de servicios para los hogares.
Basado en la operabilidad de OSGi, donde los dispositivos son parte de una red local como una casa oficina, el proyecto Matilda’s Smart House [21] resalta la necesidad de que la plataforma integre servicios orientados a la localizaci´on. Ante esta problem´atica, integra un broker que funciona como mediador entre los proveedores y la comunicaci´on de los clientes.
Por otro lado, en [4] se analiza la dificultad de incluir un mecanismo de comunicaci´on por dispositivo asociado en una red residencial basada en OSGi. Para reducir el n´umero de middlewares necesarios en una red residencial, conceptualiza realizar un middleware independiente del protocolo de comuncicaci´on. Propone una arquitectura dividida en 3 componentes principales: Middleware Manager, Middleware Broquer y el Web Server. El
manager controla los dispositivos que pertenecen al tipo de red. El broker
permite la comunicaci´on entre los diferentes manejadores y finalmente elWeb Server permite la administraci´on v´ıa web de los dispositivos.
Mientras tanto, en [12] describen un middleware montado sobre OSGi para agregar la adaptabilidad del contexto del servicio ofrecido. Se basa en la descripci´on de ontolog´ıas 2
para los contextos usando OWL( Web Ontology Languague). OWL es un lenguaje de ontolog´ıas por comentarios que proporciona contextos compartidos y razonados. La arquitectura es dise˜nada mediante los siguientes 5 componentes:
1. Context Provider. Abstrae los recursos internos de la aplicaci´on externa y los convierte en una representaci´on OWL para que otros componentes de servicios puedan ser empleados.
2. Context Interpreter. Proporciona el razonamiento l´ogico para procesar el contexto.
2
