EWS

Embedded Web Services
Resumen: 

El objetivo principal de EWS (Embedded Web Services) es dar soporte de servicios web (WS) a dispositivos con recursos muy reducidos. Es posible definir interfaces con WSDL y generar máquinas de estados capaces de responder peticiones, usando XML-RPC, SOAP, etc.

Problemas iniciales

Las aproximaciones actuales y las librarías de soporte están optimizadas para máquinas relativamente potentes (PC's, PDA, Teléfonos, etc.), y en comparación, los recursos que consumen son reducidos. A pesar de ello, no es factible utilizar estas mismas implementaciones en objetos con recursos muy limitados (Motas, microcontroladores, etc.). O bien la capacidad de computo es reducida, con lo que el tiempo de respuesta se agrava, o bien no disponen de espacio físico suficiente para almacenar todo el código necesario.

Es por ello por lo que nace Embedded Web Services. Con EWS es posible dotar de servicios web a dispositivos relativamente simples. Así pues, por ejemplo, es posible usar Web Services en redes inalámbricas de sensores y actuadores.

Propuesta

Nuestra experiencia en el diseño de midlewares empotrados sirve como base a la hora de abordar este desarrollo. Utilizando software diseñado a tal efecto, es posible generar los cabos de código para los servidores de forma que consuman pocos recursos. Así, partiendo de la especificación de las interfaces y del código de usuario, podemos generar un servicio completo capaz de ejecutarse dentro de una mota, o en sensores aún más pequeños, basados en microcontrolador.

Esto es EWS. El servicio generado consta de una máquina de estados que analiza los mensajes XML según se leen desde la red. De este modo, no es necesario almacenarlos, consumiendo sólo dos bytes en el proceso. La máquina evoluciona según se parsean los mensajes. Si llega a un estado correcto, correspondiente a la interfaz implementada, ejecuta el código de usuario pertinente y responde. Si se da un caso de error, se retorna un mensaje de error y se cierra la conexión.

Los protocolos empleados para los prototipos iniciales son XML-RPC y SOAP. Ambos utilizan mensajes encapsulados en XML para la comunicación entre clientes y servidores. XML-RPC es un protocolo muy sencillo, con un tamaño de mensaje más corto, por lo que es adecuado en dispositivos que estén limitados por el ancho de banda. Este es el caso de las redes de sensores en las que prima la conservación de la batería, y donde transmitir mensajes largos es caro.

Por otro lado, SOAP permite una mayor flexibilidad en la generación de interfaces y objetos, pero a costa de mensajes de tamaño mayor. Por ello, se puede destinar a nodos con menos restricciones, por ejemplo, dispositivos con mayor autonomía, o con un coste por byte enviado menor.

En ambos casos, la generación de las máquinas de estados se automatiza, dejando al programador la implementación de las interfaces y de las rutinas de usuario. Así, el proceso de desarrollo no es muy diferente del acostumbrado en servicios web estándares.

Prototipos y resultados

Hemos desarrollado prototipos que utilizan esta aproximación. En la sección de descargas puedes obtener ejemplos de SOAP y XML-RPC, tanto basados en librerías estándar o de libre disposición, como prototipos que utilizan EWS. El código ha sido compilado para arquitecturas x86 (sistemas GNU/Linux) y para Atmel (sistemas TinyOS y sobre máquina desnuda). Escritos en C, se compilan estáticamente y se eliminan los símbolos que no se utilizan (strip). La siguiente tabla muestra los resultados obtenidos en cuanto a espacio utilizado se refiere:
Prototype Platform Middleware Server size Other RAM
Librerías estándar x86 SOAP 1.731.508 OS -
XML-RPC 768.536 OS -
Embedded WS x86 SOAP 507.676 OS -
XML-RPC 504.772 OS -
TinyOS SOAP 35.150 -
XML-RPC 11.216 -
AVR SOAP 1.068 4.261 (Zigbee) 1.823
XML-RPC 1.182 4.261 (Zigbee) 895
(Todos los tamaños son en bytes).

Descargas

Prototipos: Librerías:

Referencias