Hacia una Arquitectura Orientada a Servicios para Redes Inal´ambricas de Sensores Edgardo Avil´es L´opez y Jos´e Antonio Garc´ıa Mac´ıas Centro de Investigaci´on Cient´ıfica y de Educ. Superior de Ensenada Departamento de Ciencias de la Computaci´on Km. 107 Carr. Tijuana-Ensenada, 22860, Eda. B.C., M´exico {avilesl, jagm}@cicese.mx
Resumen Las redes inal´ambricas de sensores est´an empezando a hacer realidad la visi´on del c´omputo ubicuo. Compuestas de una gran cantidad de distintos dispositivos de sensado que capturan constantemente par´ametros como temperatura, aceleraci´on, humedad, etc. Sin embargo, existen barreras para su aplicaci´on ya que la brecha entre los requerimientos del usuario y la programaci´on de la red es muy amplia. Este problema est´a siendo abordado por distintas investigaciones, sin embargo muchas de las soluciones no son flexibles, heterog´eneas, escalables o sencillas de utilizar. En este trabajo se explora la utilizaci´on de una arquitectura orientada a servicios en el dise˜no de un sistema middleware para redes inal´ambricas de sensores.
1. Introducci´on Las redes inal´ambricas de sensores (WSN por sus siglas en ingl´es) est´an conformadas por peque˜nos nodos de sensado de bajo costo que realizan lecturas de par´ametros tales como temperatura, humedad, luminosidad, aceleraci´on, etc. Estos nodos multifuncionales y multiprop´osito tienen caracter´ısticas m´ınimas muy limitadas, tanto en comunicaci´on como en procesamiento y memoria. Estas caracter´ısticas obligan a que los nodos de sensado cooperen para lograr comunicarse a mayor distancia o para procesar mayores vol´umenes de informaci´on. Una WSN es capaz de autoorganizarse, funcionar de manera desatendida, y puede estar conformada por cientos o incluso miles de nodos. Las WSN surgen como un nuevo campo de investigaci´on en el cual se est´a realizando una activa investigaci´on en temas tales como el dise˜no de hardware, redes, algoritmos distribu´ıdos, seguridad, dise˜no de sistemas, entre otros. En la Figura 1 se puede apreciar el escenario com´un de una WSN. Su funcionamiento inicia al desplegar los nodos
Figura 1. Escenario comun ´ de una WSN
en el a´ rea a estudiar. Una vez que se han distribuido una cantidad suficiente de sensores, la red puede iniciar la tarea para la que fue programada. Las redes de sensores est´an dise˜nadas para funcionar de manera desatendida a no ser que necesiten de mantenimiento como puede ser reemplazar alg´un sensor da˜nado o alg´un nodo sin energ´ıa. Los resultados de la tarea son enviados a una entidad externa conectada a la red (por ejemplo una aplicaci´on a trav´es de Internet) a trav´es de uno de los nodos de la red que funge como puente, a este nodo se le conoce como nodo gateway o m´as comunmente nodo sink. Esta comunicaci´on es bidireccional, por lo que la entidad externa puede inyectar tareas a la red de sensores. Idealmente, estas tareas le ser´ıan indicadas a un alto nivel, es decir, mediante el uso de expresiones como: “reportar temperatura promedio en el a´ rea”. Adicionalmente los nodos pueden trabajar de manera cooperativa para, procesando una peque˜na parte de la tarea, fusionar las lecturas y obtener el resultado final. Las WSN ofrecen nuevas oportunidades de investigaci´on y aplicaci´on, consider´andose su situaci´on actual similar a la de Internet hace treinta a˜nos. El campo es altamente espec´ıfico a la aplicaci´on, los l´ımites y requerimientos de las aplicaciones no est´an totalmente comprendidos y como consecuencia, muchas de las aplicaciones actuales a´un no est´an listas para el mundo real [4].
Arturo Hernández, José L. Zechinelli (Eds.) Avances en la Ciencia de la Computación 2006, pp. 208-212
El resto de este art´ıculo est´a organizado de la manera siguiente: en la Secci´on 2 se presentan algunos sistemas middleware para WSN as´ı como su clasificaci´on, adem´as se presentan los retos que estos sistemas deben resolver as´ı como tambi´en los requerimientos de los programadores. En la Secci´on 3 se hace una introducci´on a las arquitecturas orientadas a servicios para continuar con la descripci´on de la arquitectura propuesta en la Secci´on 4, de la cual se implement´o un prototipo como prueba de concepto (Secci´on 5). Para finalizar, se menciona el trabajo relacionado as´ı como el trabajo a futuro y algunas conclusiones.
Eficiencia. Ser conciente de la energ´ıa y “amigable con los recursos”. Programabilidad. Deben proveer soporte para la configuraci´on y la reconfiguraci´on de la red. Adaptabilidad. Deben soportar algoritmos con caracter´ısticas de desempe˜no adaptable. Adem´as deben proveer soporte para la escalabilidad, control sobre la topolog´ıa, seguridad y propiedades no funcionales (calidad de servicio, disponibilidad, etc.)
2. Middleware para WSN
De igual manera es posible identificar las necesidades de los programadores de estos sistemas [2]:
Programar sensores involucra el uso de lenguajes de bajo nivel para comunicar las instrucciones al hardware. Por lo que existe una gran necesidad de abstracciones de programaci´on que simplifiquen el asignar tareas a los sensores y de middleware que soporte tales abstracciones [13]. Actualmente existen algunas soluciones middleware disponibles y en desarrollo que permiten utilizar una WSN en la soluci´on de alg´un problema. Para el estudio de estos diferentes sistemas se clasifican por tipo de la siguiente manera:
Necesidad de un API familiar. Para el f´acil desarrollo de nuevas aplicaciones. Extensibilidad del software del nodo de sensado. Para agregar nuevos tipos de sensores o nuevas operaciones de transformaci´on de datos. Modularidad en los servicios de red. Para facilitar la experimentaci´on con diferentes soluciones para enrutamiento, sampling, calendarizaci´on, etc.
Cl´asico. Esconde la complejidad de la comunicaci´on y transferencia de datos.
3. Arquitecturas Orientadas a Servicios
Data-centric. Provee la abstracci´on de la red como una base de datos o´ hace principal referencia a la informaci´on ofrecida por la red.
Al igual que con las WSN, en el desarrollo tradicional de software ha existido el problema de proveer mejores abstracciones para la implementaci´on. Si se observa la evoluci´on de la programaci´on tradicional podremos ver c´omo esta ha avanzado desde la programaci´on secuencial, pasando por la programaci´on modular, la orientaci´on a objetos y la programaci´on basada en componentes hasta llegar a la orientaci´on a servicios [6]. Diversos autores han considerado a las arquitecturas orientadas a servicios como la siguiente ola de desarrollo de aplicaciones [11]. Una arquitectura orientada a servicios (SOA por sus siglas en ingl´es) es un estilo arquitect´onico cuya meta es lograr un bajo acoplamiento entre agentes de software que interact´uan entre s´ı. Un servicio es una unidad de trabajo realizada por un proveedor de servicio para lograr resultados deseados por un consumidor de servicios. La raz´on principal para consumir un servicio es que generalmente es m´as barato y efectivo que hacer el trabajo por s´ı mismo. Ambos roles, el proveedor y el consumidor, son realizados por agentes de software en representaci´on de sus respectivos due˜nos [7]. La comunicaci´on entre estos componentes se realiza por medio de mensajes extendibles independientes de plataforma o lenguaje. SOA est´a compuesta de tres piezas principales: proveedores de servicios, consumidores de servicios y el servicio
M´aquinas virtuales. La red es una colecci´on de interpretadores de c´odigo que se hacen cargo de programas/scripts ejecutables. Adaptable. Cuyo enfoque principal es la adaptabilidad del nodo de sensado ante diferentes situaciones. Nuestro trabajo es data-centric, ya que se enfoca en proveer una abstracci´on de la red con el objetivo de la creaci´on de sistemas de visualizaci´on/monitoreo, en el que la informaci´on ofrecida por los nodos es la principal preocupaci´on. Existe una gran diversidad de posibles aplicaciones para una WSN, cada una de ellas con una gran diferencia con las dem´as. Como se puede observar en los proyectos Sustainable Bridges [1] y Cartalk 2000 [12], el primero es totalmente pasivo, mientras que el segundo es a´ ltamente m´ovil. Independientemente de las diferencias a´un es posible encontrar ciertas similitudes entre estas aplicaciones, lo que nos permite conocer los requerimientos que sistemas middleware deben resolver [10]. Los retos de estos sistemas son: Soporte de abstracci´on. Deben esconder la complejidad de cada nodo individual y proveer una vista hol´ıstica de la red. Soportar un amplio rango de aplicaciones y plataformas de hardware.
209
de directorio, adem´as de tres operaciones principales: publish, find y bind [5]. El descubrimiento de servicios de manera din´amica es una parte importante de SOA, esto se logra gracias al servicio de directorio. Durante su iniciaci´on un servicio se registra en el directorio mediante una operaci´on publish, posteriormente un consumidor de servicios utiliza el directorio para encontrar un proveedor de un servicio que desee (mediante la operaci´on find), una vez encontrado, el consumidor procede con la operaci´on bind para enlazar y empezar a utilizar el servicio. ´ Figura 2. Escenario de ejecucion
3.1. Servicios Web SOA no es un concepto nuevo, es gracias a los servicios web que nuevamente entran en atenci´on. Los servicios web est´an constru´ıdos encima de protocolos y lenguajes como HTTP, XML, UDDI, WSDL y SOAP. UDDI y WSDL intervienen en el descubrimiento din´amico de servicios. Las interfaces est´an descritas en XML y la comunicaci´on de los mensajes se realiza a trav´es de HTTP.
Concentraci´on. En esta a´ rea se realiza la mayor parte del procesamiento. Las lecturas e informaci´on enviada por los sensores es recabada y clasificada para su posterior uso. En esta a´ rea tambi´en se proporciona acceso a los datos y al control de la red por medio de un servidor de servicios web. Esta actividad puede ser realizada ya sea por una computadora conectada a la red por medio de un nodo sink o´ por un nodo especializado con capacidades de soporte para servidores.
4. Arquitectura Propuesta
Aplicaci´on. En esta a´ rea se encuentran las aplicaciones de monitoreo/visualizaci´on creadas con el uso de los servicios prove´ıdos en el a´ rea de concentraci´on.
El zo´ologo alem´an Ernst Haeckel estableci´o que “la ontogenia recapitula la filogenia”. Con esto quiso decir que el desarrollo de un embri´on (ontogenia) repite (es decir, recapitula) la evoluci´on de la especie (filogenia). Algo an´alogo ha sucedido en la industria de la computaci´on. Tanenbaum [15] menciona que cada vez que aparece un nuevo tipo de computadora, esta pasa por el mismo desarrollo de sus antepasados, estos dispositivos se empiezan programando utilizando lenguaje esamblador hasta llegar a lenguajes de alto nivel. Este patr´on puede ser observado tambi´en con el desarrollo de la programaci´on de las WSN. Hasta ahora la mayor actividad de investigaci´on se ha conducido en las capas de bajo nivel de las WSN, sin embargo a´un falta mucho trabajo en la capa de aplicaci´on. Todo esto nos lleva a nuestra propuesta: TinySOA, la cual es una arquitectura resultado de la exploraci´on de la utilizaci´on de un enfoque orientado a servicios para la creaci´on de un middleware de redes inal´ambricas de sensores, tomando en cuenta las capacidades limitadas actuales de los sensores. En la Figura 2 se puede observar el escenario de ejecuci´on de la arquitectura. Todas las operaciones tienen lugar en tres secciones o a´ reas:
La arquitectura provee dos tipos de servicios, internos y externos. En estos servicios intervienen sus cuatro componentes: TinySOA Nodo, Gateway, Registro y Servidor.
4.1. Servicios Internos Los componentes responsables por los servicios internos son TinySOA Nodo, Gateway y Registro. El detalle de los componentes puede ser observado en la Figura 3. Los servicios internos operan de la manera siguiente: Inicializaci´on. TinySOA Nodo, utilizando el m´odulo Descubridor, identifica los servicios que puede proveer, estos son, par´ametros que puede sensar o actuadores que tiene a su disposici´on. Publicaci´on. Una vez identificados sus servicios, este procede a publicarlos por medio del m´odulo Comunicaci´on que a su vez, utilizando mecanismos prove´ıdos por el sistema operativo embebido, le son enviados a traves del nodo sink a TinySOA Gateway.
Captura. En esta a´ rea se encuentra la red de sensores en operaci´on, la cual mediante un modelo publish/subscribe comunica lecturas de sensado e informaci´on de mantenimiento al exterior a trav´es de un nodo sink que act´ua como puente de comunicaci´on. De igual manera, a trav´es de este nodo se permite la “inyecci´on” de solicitudes a la red.
Suscripci´on. TinySOA Gateway, est´a cont´ınuamente esperando mensajes de registro. Al arrivo de uno, utilizando el Procesador de Mensajes, este identifica qu´e servicios son ofrecidos por la red de sensores.
210
Figura 4. Monitor de TinySOA Gateway
Figura 3. TinySOA: Arquitectura propuesta
un componente TinySOA Gateway correspondiente) pueden ser parte de los servicios externos. El componente principal de los servicios externos es TinySOA Servidor, consiste en el m´odulo Proveedor de Servicios Externos el cual proporciona servicios web. El m´odulo proveer´a por cada red registrada en el Registro de Redes, un servicio web con una interf´az para:
Posteriormente env´ıa, utilizando el Cliente de Servicios Internos, un mensaje de suscripci´on para los servicios indicados, independientemente de su proveedor. Adem´as, registra los servicios ofrecidos por la red de sensores en el m´odulo Registro de Redes del componente TinySOA Registro. Env´ıo de lecturas. TinySOA Nodo procede a enviar las lecturas de sensado por las cuales ha recibido suscripci´on. Para hacer esto utiliza el m´odulo Lecturas de Sensado. TinySOA Gateway al recibir estas lecturas procede a enviarlas al m´odulo Registro Hist´orico del componente TinySOA Registro, adicionalmente comprueba si alg´un evento del Registro de Eventos cumple con las condiciones de las lecturas, si es as´ı, altera el estado del evento como detectado.
Consultar los servicios ofrecidos por la red. Acceder a lecturas en el Registro Hist´orico Consultar y registrar eventos. Realizar tareas de mantenimiento en la red. Adicionalmente un servicio de informaci´on es prove´ıdo, con el cual es posible consultar cu´antas redes de sensores hay disponibles y cu´ales son sus propiedades y descripci´on. Opcionalmente existe un m´odulo de comunicaci´on en los componentes TinySOA Gateway y Servidor el cual permite realizar una tarea de mantenimiento en tiempo real sin necesidad de esperar en el registro.
Actuadores y tareas de mantenimiento. TinySOA Gateway utilizando el m´odulo Registro de Tareas de Mantenimiento del componente TinySOA Registro puede ser instruido a enviar un mensaje solicitando el funcionamiento de alg´un actuador en TinySOA Nodo. Tambi´en a enviar alguna tarea de mantenimiento como por ejemplo cambiar la tasa de muestreo, poner al sensor en modo de espera, etc.
5. Prototipo Para comprobar la viabilidad en la aplicaci´on de la arquitectura, se realiz´o la implementaci´on de un prototipo middleware. El desarrollo del prototipo nos permite conocer eventualidades en la concepci´on de la arquitectura y obtener informaci´on que permita mejorar el dise˜no. Para la implementaci´on se utilizaron las plataformas de sensores MicaZ1 y Tmote Sky2 . TinySOA Nodo fue implementado sobre TinyOS [8]. TinyOS se ha convertido en el
4.2. Servicios Externos En los servicios externos los componentes responsables son TinySOA Gateway, Registro y Servidor. En la Figura 3 se puede observar un ejemplo de c´omo estos componentes est´an distribuidos en una computadora con acceso a la red de sensores a trav´es de un nodo sink, sin embargo estos componentes pueden estar distribuidos en distintas localidades. En el ejemplo se muestra la conexi´on con una sola red de sensores, sin embargo m´ultiples redes (cada una con
1 Crossbow 2 Moteiv
211
Technology Inc. http://www.xbow.com/ Corporation. http://www.moteiv.com/
est´andar de facto gracias a su estabilidad, grado de desarrollo y aceptaci´on por varios investigadores y en desarrollos comerciales. Adem´as provee soporte para una gran variedad de plataformas de sensores. TinySOA Gateway, Registro y Servidor fueron implementados utilizando el lenguaje Java3 y una base de datos MySQL4 . En la Figura 4 se puede observar un monitor del componente TinySOA Gateway implementado en funcionamiento.
control de mantenimiento tales como el cambio de tasas de datos, y control de nodos espec´ıficos. Nuestra investigaci´on es un paso m´as en la integraci´on de las redes de sensores con Internet y otras aplicaciones.
Referencias [1] Sitio web de Sustainable Bridges. http://www.sustainablebridges.net. [2] P. Buonadonna, D. Gay, J. Hellerstein, W. Hong, y S. Madden. Task: Sensor network in a box. 2005. [3] F. C. Delicato, P. F. Pires, L. Rust, L. Pirmez, y J. F. de Rezende. Reflective middleware for wireless sensor networks. 20th Annual ACM Symposium on Applied Computing (ACM SAC’2005). Santa Fe, Nuevo M´exico, EE.UU., Marzo, 2005. [4] D. Estrin, D. Culler, K. Pister, y G. Sukhatme. Connecting the physical world with pervasive networks. Pervasive Computing, IEEE. Enero-Marzo, 2002, 1(1):59–69, 2002. [5] S. Graham, D. Davis, S. Simeonov, G. Daniels, P. Brittenham, Y. Nakamura, P. Fremantle, D. Koening, y C. Zentner. Building Web Services with Java: Making Sense of XML, SOAP, WSDL and UDDI. Sams Publishing, 2004. [6] S. Hashimi. Service-oriented architecture explained, 2004. Consultado en Diciembre 2005: http://dev2dev.bea.com/pub/a/2004/05/soa hashimi.html. [7] H. He. What is service-oriented architecture?, 2003. Consultado en Diciembre 2005: http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html. [8] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, y K. Pister. System architecture directions for networked sensors. 9th International Conference on Architectural Support for Programming Languages and Operating Systems. Cambridge, MA. EE.UU., Noviembre, 2000. [9] S. Madden, M. J. Franklin, J. M. Hellerstein, y W. Hong. Tag: A tiny agregation service for ad-hoc sensor networks. Proceedings of the 5th Symposium on Operating Systems Design and Implementation. Diciembre 9-11, 2002, Boston, Massachusetts, EE.UU., 2002. [10] P. J. Marr´on, D. Minder, A. Lachenmann, y K. Rothermel. Tinycubus: An adaptive cross-layer framework for sensor networks. IT - Information Technology, 47(2):87–97, 2005. [11] M. S. Pallos. Service-oriented architecture: A primer, 2001. URL: http://www.eaijournal.com/PDF/SOAPallos.pdf. [12] D. Reichardt, M. Miglietta, L. Moretti, P. Morsink, y W. Schulz. Cartalk 2000: Safe and comfortable driving based upon inter-vehicle-communication. Proceedings of the Intelligent Vehicle Symposium, 2:545–550, 2002. [13] K. R¨omer. Programming paradigms and middleware for sensor networks. GI/ITG Workshop on Sensor Networks. Alemania, Febrero 2004, pp. 49–54, 2004. [14] J. Shi y W. Liu. A service-oriented model for wireless sensor networks with internet. The Fifth International Conference on Computer and Information Technology (CIT’05), pp. 1045–1049, 2005. [15] A. S. Tanenbaum. Modern Operating Systems. Prentice Hall, 2da. edici´on, 2001.
6. Trabajo Relacionado Trabajos anteriores han realizado la abstracci´on de la red de sensores como una base de datos [9]. Poco a poco se est´a prestando atenci´on al esquema orientado a servicios, algunos autores han empezando a integrar los servicios web con las redes de sensores, tal es el caso de Delicato [3], la cual propone un sistema middleware adaptable orientado a servicios, el cual se centra en la adaptabilidad y en el ahorro de energ´ıa. Shi y Liu [14] proponen un modelo orientado a servicios en el cual agentes se encargan de proveer acceso a la informaci´on generada por la red. Ambos trabajos carecen de una implementaci´on en alguna plataforma de sensores. Presentan sus resultados por medio de simulaciones. Al no ofrecer una implementaci´on ciertos problemas podr´ıan no ser detectados y por lo tanto influir en la adopci´on y aplicaci´on de su arquitectura.
7. Trabajo a Futuro Este es un trabajo a´un en desarrollo, existen muchas mejoras posibles. Se planea incluir algunos m´etodos de ahorro de energ´ıa tales como la determinaci´on autom´atica de la velocidad de muestreo bas´andose en la varianza de un n´umero de lecturas anteriores. Tambi´en se planea realizar la instalaci´on de una red de sensores utilizando el prototipo para el desarrollo de una aplicaci´on de monitoreo de un invernadero. Para con ello obtener datos de desempe˜no con el objetivo de mejorar y depurar el dise˜no de la arquitectura.
8. Conclusiones La arquitectura propuesta da soporte a los requerimientos de los programadores de aplicaciones. La necesidad de un API familiar la brinda mediante los servicios web, al poder consumir estos servicios en el ambiente de programaci´on de preferencia del programador. La organizaci´on de la arquitectura en m´odulos y componentes posibilitan la experimentaci´on con diferentes tipos de sensores, protocolos de comunicaci´on y nuevas operaciones de datos. Adem´as, en los servicios ofrecidos se da acceso a mecanismos de 3 Sun
Microsystems. http://java.sun.com/ AB. http://www.mysql.com/
4 MySQL
212