Provisión de Servicios de Red mediante Dispositivos Empotrados. Aplicación al inicio remoto de equipos a través de Internet

Transcripción

1 Provisión de Servicios de Red mediante Dispositivos Empotrados. Aplicación al inicio remoto de equipos a través de Internet Juan Antonio Gil Martínez-Abarca 1, Francisco Maciá Pérez 2, Diego Marcos Jorquera 2 y Virgilio Gilart Iglesias 2 1 Escuela Politécnica Superior, Universidad de Alicante Ctra. de San Vicente del Raspeig, s/n, San Vicente del Raspeig Ap. 99 E-03080, Alicante, España, gil@eps.ua.es 2 Departamento de Tecnología Informática y Computación, Universidad de Alicante Ctra. de San Vicente del Raspeig, s/n, San Vicente del Raspeig Apdo. correos 99, Alicante, España {pmacia, dmarcos, vgilart}@dtic.ua.es Abstract. En este trabajo se presenta un dispositivo empotrado que es capaz de gestionar el encendido remoto de nodos de red mediante Wake on LAN (WoL) a través de Internet y redes de área amplia, presentándolo como un servicio de red. El servicio se denomina WoLI y está formado por un dispositivo de red, un conjunto de aplicaciones software empotradas en dicho dispositivo y un protocolo de aplicación denominado WoLIP. Este dispositivo es de reducidas dimensiones, requiere un mantenimiento mínimo y es capaz de comunicarse a través de redes de área amplia mediante las aplicaciones empotradas empleando el protocolo de aplicación WoLIP definido sobre protocolos de red normalizados. El mecanismo utilizado para el encendido de los equipos es compatible con la tecnología WoL. El servicio se integra perfectamente con sistemas de gestión remota basados en SOA. La gestión y el control del dispositivo y del servicio pueden realizarse a través de Internet mediante un navegador Web convencional. Esta propuesta es un ejemplo de aplicación de una propuesta más general para la gestión de servicios de red basada en la utilización de pequeños dispositivos de red embebidos que proporcionen funcionalidades concretas y de uso común, lo más autónomos y desatendidos posible. 1 Introducción La trascendencia de las tecnologías de la información y las comunicaciones (TIC) en todos los ámbitos de la actividad humana es un hecho indiscutible en la actualidad. Cuanto más sencillas se muestran estas tecnologías a los usuarios finales, tanto más complejas se vuelven los sistemas de backend que les proporcionan soporte. Estas tecnologías constituyen el suelo tecnológico en el que se sustenta gran parte de los

2 40 J.A. Gil et al. procesos de negocio. Es indispensable aportar los mecanismos necesarios para asegurar que dicha infraestructura tenga un funcionamiento continuado Las actuales tendencias en la gestión de las TIC pasan por la externalización como estrategia para amortizar las inversiones, asegurar la disponibilidad continuada de infraestructuras y servicios y lograr la agilidad necesaria que permita a las organizaciones adaptarse a tiempo al cambiante entorno. Sin embargo, la externalización no elimina los problemas de gestión de las TIC, tan sólo los desplaza al ámbito de responsabilidad del proveedor de servicios y de comunicaciones. Aunque los servicios proporcionados por las TIC pueden llegar a ser verdaderamente complejos, se suelen apoyar en infinidad de pequeños servicios, más o menos estandarizados, que se encargan de realizar tareas repetitivas, muy bien definidas y que suelen servir de apoyo a las aplicaciones de nivel superior por ejemplo, los servicios de nombres, de configuración de red, de sincronización de relojes, de monitorización de la actividad, del cálculo de las rutas o los servicios de descubrimiento. Puesto que cada servicio encapsula su propia complejidad, la escalabilidad se convierte en una característica intrínseca, al tiempo que se facilita notablemente la gestión y el mantenimiento del servicio [1]. En muchas ocasiones, incluso aunque se haya recurrido a la externalización, es preferible que algunos de estos servicios se ubiquen en el lado del cliente por motivos de eficiencia, disponibilidad o seguridad. Se encuentren donde se encuentren, estos pequeños servicios, que por separado no parecen despertar siquiera la curiosidad de los administradores, en su conjunto involucran tal número de sencillas pero repetitivas tareas de gestión (configuración, monitorización, actualización), y un número tan elevado de infraestructuras para su despliegue que, en la práctica, suponen un verdadero quebradero de cabeza para los administradores. Un enfoque que está tomando fuerza para reducir el número de tareas de este tipo en cualquier infraestructura TIC medianamente sofisticada es la incorporación de dispositivos físicos diseñados para proporcionar algunos de los servicios descritos. En la última década se ha logrado un gran avance en las tecnologías para el desarrollo de pequeños dispositivos de red con una más que aceptable capacidad de cómputo, autonomía de funcionamiento [2] y posibilidad para embeber inteligencia en los mismos. Aunque hasta hace poco el coste de estos dispositivos no justificaba su incorporación masiva para la gestión de determinadas tareas y servicios, la actual tendencia hacia dispositivos cada vez más pequeños, con capacidades de computación y comunicación mayores y precios muy ajustados, propicia un escenario idóneo para plantear nuestra propuesta: proporcionar servicios de red concretos (DHCP, BOOTP, WoL, NTP, DNS, etc.), con necesidades de gestión y atención mínimas por parte de los administradores, basados en modelos de autoconfiguración y de gestión compatibles con las arquitecturas orientadas a servicios (SOA) y protocolos normalizados (UDDI, SOAP, upnp), todo ello empotrado en un dispositivo de red de dimensiones muy reducidas (incluso del tamaño de un mechero) y unos costes realmente residuales. Incorporar un servicio de estas características en nuestra organización, o incluso en el hogar, es tan sencillo como conectar a nuestra red el dispositivo de administración adecuado y, como mucho, proporcionar la configuración inicial necesaria para desarrollar su labor.

3 WoLI: Inicio remoto de equipos a través de Internet 41 En este artículo se desarrolla este enfoque guiado por el diseño de un dispositivo concreto. Este dispositivo se denomina WoLI bajo solicitud de patente (P , 2005) y proporciona Wake on LAN (WoL) sobre Internet, es decir; la capacidad de gestionar el encendido remoto de equipos ubicados en una LAN, desde cualquier lugar y con tan sólo un navegador Web convencional. En los próximos apartados revisamos el estado actual de las tecnologías implicadas, describimos el servicio WoLI, la estructura del dispositivo hardware y software en el que se embebe, el protocolo de aplicación que emplea y su evolución hacia servicio Web. Finalmente, se exponen las conclusiones que se desprenden de la investigación, así como las líneas de trabajo que estamos siguiendo en la actualidad. 2 Background Los primeros estándares abiertos que trataron de abordar los problemas de la gestión de las TIC de una manera global fueron SNMP y CMIP [3], propuestos por el IETF; ambos protocolos orientados principalmente a la supervisión y control de la red. Estos modelos de administración presentaban como principal inconveniente su dependencia de la plataforma. Basándose en ellos y buscando una integración entre sistemas heterogéneos, surgen dos líneas básicas de trabajo: procurar la integración entre sistemas que utilicen el mismo protocolo de gestión de red, como es el caso de [4] y [5] con el uso de CORBA; o, de carácter más ambicioso, proponer un protocolo de gestión de red independiente de las infraestructuras. Alguna de las propuestas más extendidas son: CORBA/JIDM, especificación del grupo de trabajo JIDM [6] del OMG [7]; CIM/WBEM, propuesta del DMTF [8] usando técnicas orientadas a objetos CIM e interoperación usando HTTP y XML con WBEM; JMX especificación definida por el JCP [9] que define una serie de API s orientadas a Java para la gestión de red; y WS- Management especificación realizada por varias compañías del sector (SUN, INTEL, MS, AMD) para la integración de sistemas de gestión de servicios y recursos basándose en Servicios Web. El elevado número de tareas asociadas con la gestión de redes así como su elevada diversidad y complejidad hace que las labores de mantenimiento de estos sistemas supongan un alto coste para las organizaciones tanto en recursos como en tiempo y personal. La utilización de sistemas multi-agente para la gestión redes de computadores aporta una serie de características que favorecen la automatización y desatención en los procesos de mantenimiento [10] [11]. La creación de proyectos como AgentLink III, la primera Acción Coordinada sobre Computación Basada en Agentes financiada por el 6º Programa Marco de la Comisión Europea [12], es un claro indicador del alto grado de interés que despierta la investigación sobre agentes software. Más recientemente, con la evolución de las tecnologías Web, se ha avanzado un paso más en la dirección de la autogestión proponiéndose modelos de autoorganización basados en Ontologías como modelos de información y en SOA como modelo operacional, consiguiendo, además, proporcionar a los administradores una interfaz ubicua y no dependiente de ninguna plataforma [13].

4 42 J.A. Gil et al. La diversidad de modelos de gestión de red existentes deja patente la necesidad de definir mecanismos que proporcionen interoperatividad entre todos los dominios de gestión implicados [14]. Esta relación puede alcanzar nivel semántico utilizando ontologías de tal forma que se trabaje con una vista abstracta de la información de gestión de red, independiente del modelo especifico utilizado y permitiendo a los administradores (personas o agentes software) la automatización de las tareas de gestión [15]. La Gestión Semántica permite la integración de políticas comunes de gestión de los recursos y servicios de red al independizar los modelos mediante una ontología común y consensuada [16] que implica la comprensión de los elementos de red y permite la normalización de las tareas a realizar. En [17] se propone el conjunto de operaciones básicas de un Servicio Web para su estandarización dentro de la administración de redes como contrapartida a la estandarización del modelo de información de SNMP bajo XML desarrollo en otros trabajos [18]. En otros ámbitos de manejo automatizado de información y en los que pueden intervenir múltiples dispositivos, como son el ámbito de los procesos industriales y el domótico, la evolución de la gestión autónoma se ha encaminado hacia arquitecturas orientadas a servicios para sistemas empotrados [19][20], reflejándose en el primero de ellos la importancia de trasladar estas ideas al ámbito de la gestión autónoma de la redes y sistemas. Justamente es dentro de esta línea en la que podemos encuadrar nuestra propuesta: el desarrollo de un servicios de red embebidos en hardware, más concretamente de un servicio de encendido remoto de equipos que permite su integración con los modelos de gestión de red existentes. 3 Descripción del servicio WoLI El servicio WoLI es un servicio de red que permite el control del encendido de nodos de red con soporte WoL, empleando para ello protocolos estándar de Internet y arquitecturas orientadas a servicios (SOA), lo que independiza el servicio de la ubicación en la que se encuentre el administrador y de la plataforma que éste utilice para ello. Además, este servicio estará empotrado en un dispositivo de red específico, de reducidas dimensiones, transparente a las infraestructuras TIC existentes y con la una necesidad mínima de mantenimiento por parte de los administradores del sistema. La principal utilidad del servicio WoLI es facilitar la gestión remota de equipos de red a través de redes de área amplia, en general, e Internet en particular, en las que la simple imposibilidad de iniciar, desconectar o reiniciar estos equipos limita notablemente la capacidad de actuación a distancia de los administradores del sistema. En la figura 1 se muestra un diagrama con los principales elementos y actores que intervienen en el servicio junto con la relación que existe entre los mismos y que podemos sintetizar en: clientes WoLI, planificadores WoLI, dispositivo WoLI y los nodos de red destinatarios del servicio. A continuación analizaremos cada uno de estos elementos.

5 WoLI: Inicio remoto de equipos a través de Internet 43 El cliente WoLI facilita al usuario, a través del agente de gestión del servicio, el acceso al servicio, tanto para planificar, como para generar instrucciones WoL a través de Internet. Las órdenes se transmiten al planificador WoLI o al dispositivo WoLI mediante el protocolo de aplicación WoLIP (Wake on LAN over Internet Protocol) definido para tal fin. Este agente, en general, será externo al dispositivo. Fig. 1. Organización de los elementos funcionales del servicio WoLI. El planificador WoLI suele actuar como panel de control de todos los posibles dispositivos WoLI distribuidos por Internet. Este control lo realiza a través del agente de planificación que se encarga de realizar, ejecutar y verificar todas las tareas previamente establecidas sobre los dispositivos WoLI (encender un nodo individual o un conjunto de ellos, verificar su estado, actualizar el firmware de los dispositivos WoLI e, incluso, planificar el trabajo del dispositivo WoLI). Este agente podrá residir en un nodo externo a la LAN, generalmente en el sitio del proveedor de servicios o comunicaciones, o bien puede estar integrado dentro de un dispositivo WoLI. El Dispositivo WoLI es la pieza angular del servicio. Se trata de un dispositivo de red embebido, de reducidas dimensiones, encargado de actuar como pasarela WoLIP- WoL entre la red de área amplia, basada en el protocolo de aplicación WoLIP y a su vez definido sobre protocolos normalizados como TCP/IP, HTTP, SOAP o UDDI y la red de área local en la que opera mediante la tecnología pseudoestándar Wake on Lan. La mayor parte de este trabajo recae sobre el agente WoLI. En este caso, el agente WoLI siempre actuará desde dentro de la LAN. El agente WoLI se comportará de forma diferente según actúe en modo activo o pasivo. En el modo pasivo, el agente está a la espera de recibir solicitudes WoLIP provenientes de un agente de gestión, generalmente externo, para ejecutarlas bajo demanda (ver figura 2). Sin embargo, en el modo activo, es el agente el que toma la iniciativa y solicita un plan de trabajo a un agente de planificación. El funcionamiento en modo activo del agente WoLI permite trabajar con independencia de las posibles políticas de seguridad implantadas para la protección de la intranet, puesto que emplearía para ello solicitudes HTTP estándar como base del protocolo WoLIP. Los nodos de red son el objeto de la administración y están constituidos por todos

6 44 J.A. Gil et al. aquéllos dispositivos conectados a la red con soporte WoL en sus tarjetas adaptadoras. Estamos hablando de PCs, servidores de red, dispositivos de networking o de cualquier otro dispositivo que cumpla los requerimientos establecidos. 4 Protocolo de Servicio WoLIP El protocolo de servicio WoLIP define una serie de instrucciones utilizadas por los usuarios y por los diferentes componentes del sistema para comunicarse entre sí. Este protocolo está basado en mensajes y se puede sustentar sobre protocolos de aplicación estándares de tipo petición-respuesta como HTTP o SMTP, actuando éstos como mecanismo de transporte. Los mensajes del protocolo WoLIP se expresan en formato XML y están formados por una cabecera y un cuerpo. La cabecera incluye información referente a la codificación e interpretación del mensaje. El cuerpo contendrá información específica sobre la acción a realizar o los datos devueltos por la misma. La estructura de un mensaje mediante el protocolo WoLIP se define a continuación: Envoltura de transporte (HTTP, SMTP, ) Envoltura del mensaje WoLIP (MIME1) Cabecera mensaje WoLIP Cuerpo mensaje WoLIP La definición del tipo de documento (DTD Document Type Definition) para un mensaje de petición del protocolo WoLIP sigue la siguiente sintaxis: <! ELEMENT Body (Command)> <! ELEMENT Command (Action?, Arguments?)> <! ATTLIST Command name (Comand) #REQUIRED> <! ELEMENT Action (Arguments?)> <! ATTLIST Action name (Action level 1) #REQUIRED \ type (Action level 2) #IMPLIED> <! ELEMENT Arguments (Argument*)> <! ELEMENT Argument (#PCDATA)> <! ATTLIST Argument name (Argument)> donde se distinguen los siguientes elementos: Comand define las acciones del servicio en términos de solicitud. Action level 1 y Action level 2 son parámetros especiales que perfilan la funcionalidad de la solicitud. Argument representa la información necesaria para ejecutar la solicitud.

7 WoLI: Inicio remoto de equipos a través de Internet 45 En el cuerpo de un mensaje de petición del protocolo WoLIP estará formado por una sola instrucción, con todos los argumentos necesarios para su ejecución, la cuál llevará implícita su correspondiente mensaje de tipo respuesta. Fig. 2. Diagrama de secuencia para el arranque de un nodo de red con el agente WoLI trabajando en modo pasivo. En un mensaje respuesta del protocolo WoLIP, el cuerpo está formado por el resultado dependiente de solicitud realizada o por un mensaje de error, en caso de que se haya producido algún acontecimiento inesperado. Las solicitudes definidas en el protocolo (ver tabla 1) se pueden agrupar en tres grandes tipos: órdenes de configuración, órdenes básicas y órdenes de control. Tabla 1. Principales órdenes soportadas por el protocolo WoLIP. CMD ARG ACCTION SET MODE Informa del modo establecido. MODE PASIVE [puerto] Establece el modo pasivo. Puede indicarse el puerto de escucha. MODE ACTIVE <ip>[:puerto] Establece el modo activo indicando la dirección y puerto del servidor. RUN Informa del estado del servicio WoL. RUN <START STOP> Inicia o para el servicio de WoL del dispositivo. UPDT FIRM <archive> Actualiza el firmware del dispositivo desde un archivo. GET SCHDL Devuelve la lista de tareas planificadas en el dispositivo. PUT SCHDL Añade una tarea o una lista de tareas a la planificación. VALIDATE <user> <pass> Identificación y autenticación de usuarios. WAKE <equipo> Inicia un nodo de la red mediante WoL. PING <equipo> Comprueba si un equipo está en ejecución. La configuración de las variables internas del dispositivo determina su modo de funcionamiento. Estas variables se gestionan mediante la orden SET. El servicio fundamental prestado por el dispositivo WoLI se invoca mediante la orden WAKE. En la figura 2 se presenta un sencillo diagrama de secuencia para esta orden, responsable de encender un equipo mediante el protocolo WoL. Las órdenes PUT y

8 46 J.A. Gil et al. GET, combinadas con el argumento SCHDL para programar y obtener la programación de un dispositivo, permiten planificar el proceso de encendido de uno o varios equipos de forma desatendida. El servicio permite establecer un control de acceso mediante una lista del tipo usuario-contraseña. Esta funcionalidad se gestiona mediante la orden VALIDATE. Todas las órdenes del protocolo WoLIP proporcionan una respuesta: OK, si la orden se ejecuta correctamente o error en caso contrario, excepto GET SCHDL que devuelve la lista de tareas programadas para el dispositivo y el comando PING que, asíncronamente, devolverá el estado del nodo de red que se ha pretendido encender. 5 Dispositivo WoLI En los siguientes apartados nos centraremos en el diseño y la realización, tanto software como hardware, de un prototipo totalmente funcional de este dispositivos de red empotrado. 5.1 Diseño Hardware La plataforma hardware que sirve de soporte al dispositivo WoLI (fig. 3) consiste, básicamente, en un microcontrolador, una memoria volátil (SRAM), otra memoria permanente (ROM) y una memoria reescribible (Flash), además de un interfaz de red. Fig. 3. Esquema hardware del dispositivo WoLI. La plataforma hardware elegida para el desarrollo del prototipo es un dispositivo Xport de Lantronix que dispone de un procesador DSTni-EX de 16bits y 48/88MHz de frecuencia con los que se alcanzan 12/22MIPS respectivamente. Los diferentes módulos de memoria que proporciona este dispositivo se encargan, en función de sus características intrínsecas, de tareas específicas: los programas en ejecución y los datos que maneja el dispositivo residen en la memoria SRAM (256KB); la memoria ROM (16KB) contiene el programa de arranque del sistema y, por último, memoria EEPROM de 512KB almacena información no volátil pero susceptible de cambio,

9 WoLI: Inicio remoto de equipos a través de Internet 47 como la configuración del dispositivo WoLI o los programas del sistema que pueden ser actualizados. Estas capacidades son suficientes para los requerimientos de memoria del software desarrollado, proporcionando alrededor de 192K de memoria RAM libres para la implementación del protocolo. Como elementos de comunicación entre subsistemas se dispone de un bus de datos y direcciones que interconecta la CPU con las memorias RAM, ROM y EEPROM; además, para la comunicación de la CPU con el exterior, se dispone de diversos dispositivos de E/S, entre los cuáles destaca una interfaz de red FastEthernet que permite unos más que aceptables ratios de comunicación con el exterior. Además, para el correcto funcionamiento del sistema se dispone de una serie de elementos auxiliares como: un watchdog que monitoriza la CPU e impide que se bloquee; un gestor de la EEPROM (PLC) para el control de las actualizaciones de la misma; un divisor de frecuencias PLL necesario para configurar la frecuencia de reloj del sistema y que facilita el ahorro de energía; una unidad de control encargada de supervisar las señales necesarias para la correcta operación de todos los elementos y un controlador de interrupciones que facilita la gestión de los dispositivos de entrada/salida. Por último, indicar que el sistema cuenta con cuatro líneas de entrada: una señal de reloj (CLK) ajustable para optimizar el consumo o el rendimiento según necesidades; una señal de reinicio (RST) y las tensiones de alimentación (VDD) y masa de alimentación (VSS). 5.2 Diseño Software La arquitectura software de este dispositivo (fig. 4) consta de diversos elementos funcionales organizados bajo un modelo jerárquico. En las capas superiores se ubican los agentes del sistema, encargados de proporcionar los servicios del dispositivo, junto con utilidades y aplicaciones auxiliares que facilitan su mantenimiento. Básicamente, podemos distinguir dos agentes: 1) Agente WoLI, encargado de la activación de nodos de red mediante la generación de paquetes del protocolo estándar de encendido remoto (WoL). 2) Agente de planificación, que permite planificar las tareas del dispositivo, especificando horarios y condiciones para su ejecución. Esta capa se apoya fundamentalmente sobre la implementación del protocolo de servicio WoLIP tratado anteriormente (ver tabla 1). Este protocolo de servicio está basado en mensajes en formto XML y utiliza como capa de transporte el protocolo de aplicación HTTP. Para desarrollar su cometido, el agente WoLI, una vez interpretado el mensaje de solicitud de servicio, hará uso de la implementación del protocolo estándar para encendido remoto de nodos de red (WoL) para ejecutar dicha solicitud. De esta forma, el agente WoLI actúa como pasarela entre los protocolos estándar de Internet y el método WoL. Adicionalmente, se ha dotado al dispositivo de diversos servicios basados en protocolos ampliamente utilizados sobre los que se apoyan las utilidades y

10 48 J.A. Gil et al. herramientas de gestión. Su objetivo es que el dispositivo soporte los mecanismos convencionales de gestión, de forma que puedan integrarse fácilmente en las políticas de gestión empleadas en la actualidad. Según esto, para almacenar o recuperar la configuración del dispositivo o para la actualización de su firmware se ha recurrido al protocolo ligero de transferencia de archivos (TFTP); y para la gestión del dispositivo se proporciona el protocolo ligero para gestión de red (SNMP), el cuál facilita las tareas de gestión y administración del dispositivo en la red. Aplicaciones WoLIP (agente WoLI y agente de planificación) WoLIP Utilidades y Servicios WoLIP (consola de texto, autoconfiguración, autenticación, ) WoL HTTPx TFTP SMTP TCP/IP STACK EMBEDDED OPERATING SYSTEM BIOS DEVICE HW Fig. 4. Componentes software del dispositivo WoLI junto con su ubicación en las diferentes capas arquitecturales. En las capas inferiores se definen protocolos de carácter más general, como la pila TCP/IP, el sistema operativo embebido del dispositivo que en el caso que nos ocupa es CoBOS, propiedad de Lantronix, y que ya incluye una implementación de la pila de TCP/IP, con DHCP, AutoIP y BOOTP como protocolos para la configuración automática de red. Finalmente encontramos el hardware del dispositivo analizado en el apartado anterior junto con las primitivas que facilitan el acceso a sus recursos. 6 Hacia los Servicios Web Aunque este prototipo de prueba está basado en SOA y se comunica mediante mensajes en formato XML, se ha implementado mediante protocolos específicos para el servicio. Esto es debido, principalmente, a la necesidad inicial de empotrar todo el software generado dentro de un dispositivo de muy reducidas prestaciones. Sin embargo, con el actual nivel de miniaturización se puede disponer de memoria suficiente como para albergar plataformas cada vez más sofisticadas. A partir de estos nuevos dispositivos y buscando estándares ampliamente difundidos con los que mejorar la integración e interoperatividad del sistema WoLI con otros servicios, hemos redefinido algunas capas del dispositivo con una realización basada en Servicios Web.

11 WoLI: Inicio remoto de equipos a través de Internet 49 Se ha optado por Servicios Web en detrimento de otras opciones como JINI y upnp debido a que, la primera es dependiente de la plataforma para la que está ideada: JAVA; y la segunda se compone de diversos protocolos que en realidad no son estándares, sino implementaciones propias [21]. WoLIP Applicantions (WoL Agent, Planning Agent, Register Agent) UDDI SOAP WoLIP WoLIP Utilities and Services DHCP WoL HTTP TFTP TCP/IP STACK EMBEDDED OPERATING SYSTEM DEVICE HW Fig. 5. Componentes software y ubicación en las diferentes capas arquitecturales del dispositivo WoLI como Servicio Web. A pesar de las capacidades ampliadas, estos dispositivos siguen presentando limitaciones en sus recursos. Por esta razón se ha optado por utilizar la funcionalidad estrictamente necesaria para cumplir con el estándar de Servicios Web. El desarrollo lo hemos basado en la librería csoap, adecuada para este tipo de dispositivos [22]. En la figura 5 se puede observar la arquitectura software del servicio WoLI. La mayor parte de los elementos son idénticos a los discutidos en el prototipo anterior. La principal diferencia radica en que ahora basamos el protocolo de servicio WoLIP sobre SOAP, en lugar de hacerlo directamente sobre HTTP. La imposibilidad de contar con una implementación de SOAP bajo el protocolo UDP impide el uso de los mecanismos de descubrimiento (ws-discovery), eventos (ws-eventing) y configuración (ws-addresing) específicos del estándar Web Service, por lo que se ha propuesto una solución mínima, aunque perfectamente compatible con el estándar Web Services, basada en DHCP y AutoIP como protocolos de configuración de red y UDDI para registrar y publicitar los servicios. Por el mismo motivo, no se ha implementado el dispositivo empotrado como un punto final de una comunicación WSDL, aligerando de esta forma la programación del sistema y obligando a una tercera parte a ejercer dicha función. De esta forma, la definición del servicio se ha realizado mediante WSDL y registrado con UDDI, pero el dispositivo empotrado no dispone del analizador WSDL ni realiza consultas al registro UDDI debido a que, en principio, no interaccionará con otros Servicios Web directamente. En la figura 6 se muestra cómo queda definida la página WSDL para la operación WAKE del protocolo WoLIP. <operation name="wake"> <SOAP:operation style="rpc" soapaction=""/> <input> <SOAP:body use="encoded" namespace="urn:woli" \ encodingstyle="

12 50 J.A. Gil et al. </input> <output> <SOAP:body use="encoded" namespace="urn:woli" \ encodingstyle=" </output> </operation> En cualquier caso, es importante para el futuro, a medida que los dispositivos empotrados vayan proporcionando suficientes recursos, la implementación del servicio WoLI con toda la funcionalidad del estándar Web Services. Es más, nuestro objetivo es emplear técnicas de Servicios Web Semánticos junto con una ontología que defina los procesos y la información de administración para proporcionar servicios completamente autónomos, capaces de registrarse, actuar bajo demanda como una utility computing, descubrir otros servicios e interactuar con ellos, y todo ello con tan sólo conectar el dispositivo empotrado a la red de comunicaciones y sin necesitar intervención humana en ningún momento. 7 Conclusiones En este trabajo hemos presentado un enfoque para la prestación de servicios de red sencillos (DHCP, NTP, Jini LUS, etc.) de forma embebida, en dispositivos de red de reducidas dimensiones y consumo, autónomos y especializados en cada servicio. El principal objetivo de este enfoque es que se pueden proporcionar estos servicios, comunes en cualquier entorno de red actual, sin que se tenga que recurrir a un especialista, ni para su puesta en marcha, ni para su posterior mantenimiento. Desde el punto de vista de un usuario, cada servicio representa un pequeño dispositivo que tan sólo debe conectar a la red de su organización de su hogar para disponer del servicio deseado. El dispositivo es capaz de autoconfigurarse y de realizar su trabajo de forma independiente o integrada con otros servicios de red existentes, tanto si éstos son proporcionados por otros dispositivos similares o como servicios de red convencionales. Para verificar la validez de este enfoque se ha discutido el diseño y la implementación de un servicio específico, concretamente orientado al inicio remoto de quipos de red a través de Internet (WoL over Internet). Este prototipo, denominado WoLI, se ha presentado en forma de SOA genérico y como Servicio Web, compatible con estándares abiertos como SOAP, UDDI y WSDL y con capacidad para autoregistrarse. En la actualidad estamos trabajando en otros servicios de red embebidos e integrándolos todos bajo un modelo basado en servicios Web Semánticos, de forma que en un futuro puedan, no sólo entenderse con los servicios existentes, sino también con servicios o configuraciones novedosas no contempladas inicialmente en su diseño.

13 WoLI: Inicio remoto de equipos a través de Internet 51 Referencias 1 F. Jammes and H. Smit, Service-Oriented Paradigms in Industrial Automation, IEEE Trans. On Industrial Informatics, vol. 1, Feb 2005, pp L.B. Ruiz, T.R.M. Braga, F.A. Sikva, H.P.Assuncao, J.M.S. Nogueira, and A.A.F. Loureiro, On the Design os a Self-Managed Wireless Sensor Network, IEEE Communications Magazine, July 2005, pp RFC Project: (URL) 4 Jeong, M.S., Kim, K.H., Kwon, J.H., Park, J.T. CORBS/CMIP: Gateway Service Scheme for CORBA/TMN Integration. Knom Review, Vol.2, No. 1, pp , Aschemann, G., Mohr, T., Ruppert, M. Integration of SNMP into a CORBA- and Web- Based Management Environment in Proc. Kommunikation in Verteilten Systemen, Heidelberg, 1999, pp Work Group JIDM: (URL) 7 OMG: (URL) 8 DMTF: (URL) 9 JCP: (URL). 10 T.C.Du, E.Y. Li, and A.P. Chang, Mobile Agents in Distributed Network Management, in Communications at the ACM, 46(7), 2003, pp J. Guo,Y. Liao, and B. Parviz. An Agent-Based Network management system, presented at the 2005 Internet and Multimedia Applications. 12 European co-ordination action for agent-based computing: (URL) 13 R. Boutaba, J. Xiao, Network Management: State of the Art presented at the 2002 World Computer Congress, pp J.E. López. V.A. Villagrá, and J.I. Asensio, Ontologies: Giving Semantics to Network Management Models, IEEE Network, 17(3): 15-21, May-June J. Peer, A POP-Based Replanning Agent for Automatic Web Service Composition, presented at the 2005 Second European Semantic Web Confenrece. 16 A. Guerrero, V.A. Villagrá, and J.E. López, Definición del comportamiento de gestión de red con reglas SWRL en un marco de gestión basado en ontologías en OWL, presented at the 2005 V Jornadas de Ingeniería Telemática, Vigo, pp J. Sloten, A. Pras, and M. Van Sinderen, On the standardisation of web service management operations, presented at the 2004 X EUNICE Summer School and IFIP WG 6.3 Workshop. 18 T. Klie, and F. Straub, Integrating SNMP agents with XML-based management systems, IEEE Communications Magazine vol. 42 Issue 7, July 2004, pp U. Toop, P. Muller, J. Konnertz, A. Pick, Web based Service for Embedded Devices, LNCS vol. 2593, 2002, pp: F. Jammes, H. Smit, Martínez-Lastra, J.L., I.M. Delamer, Orchestration of Service- Oriented Manufacturing Process. Proc. Of the10 th IEEE International Conference on Emerging Technologies and Factory Automation ETFA 2005, Catania, September 19-22, F. Jammes and H. Smit, Service-Oriented Architectures for Devices- the SIRENA View. Available: 22 V. Miori, L. Tarrini, and R. Bianchi, LIGHT: XML-Innovative Generation for home Networking Technologies, Ercim News, Number 62, July2005