Diseño e implementación de un sistema intermediario para internet de las cosas

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA GRADO EN INGENIERÍA INFORMÁTICA DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA INTERMEDIARIO PARA INTERNET DE LAS COSAS MIDDLEWARE DESIGN AND IMPLEMENTATION FOR THE INTERNET OF THINGS Realizado por Antonio García Jiménez Tutorizado por Mercedes Amor Pinilla Departamento Lenguajes y Ciencias de la Computación UNIVERSIDAD DE MÁLAGA MÁLAGA, JUNIO 2016 Fecha defensa: El Secretario del Tribunal ! Resumen: En esta memoria se recoge el proceso y los conocimientos necesarios para el diseño y la implementación de un sistema capaz de estar a la altura de un nuevo concepto llamado ‘Internet de las Cosas’ que pretende, mediante la conexión de objetos de nuestro día a día a internet, conseguir mejorar la calidad de vida de las personas y solucionar problemas que hasta ahora no habían sido abordados. Este sistema, implementado en Node.js, permitirá recoger información obtenida mediante los sensores de diversos dispositivos para ser almacenados en una base de datos no relacional como lo es MongoDB. Se proporcionará para ello una API basada en el protocolo HTTP que permita a los usuarios y dispositivos un acceso sencillo y rápido. Con este trabajo se pretende que se conecten multitud de dispositivos y que con toda la información recopilada puedan diseñarse aplicaciones de más alto nivel que utilicen estos datos para realizar tareas complejas como análisis de Big Data o respuestas automatizadas ante ciertos eventos. La plataforma diseñada será escalable, para contar con un mayor tráfico, y extensible, para poder adaptarla en un futuro a las nuevas necesidades o tecnologías que pudieran surgir. Palabras claves: Node.js, Internet de las Cosas, HTTP, MongoDB Abstract: On this project, the process and knowledge needed for the design and implementation of a middleware able to live up to a new concept called ‘Internet of Things’ is addressed. This new concept, by connecting everyday objects to the Internet, aims at improving people’s life and solving some problems that have not been solved to this day. This system, implemented in Node.js allows us to collect information obtained by various devices’ sensors and store them on a non relational database like MongoDB. It will provide an API for this purpose based on the HTTP protocol that will allow users and devices easy and quick access. This project intent is to connect a variety of devices and use all that collected information to design higher-level applications which could use this data to perform complex tasks such as Big-Data analysis or automated responses to certain events. This platform aims to be scalable in order to support higher traffic and extensible in order to adapt in the future to new needs or technologies that might emerge. Keywords: Node.js, Internet of Things, HTTP, MongoDB ´ Indice general ´ Indice de figuras 2 ´ Indice de tablas 3 1. Introducci´on 7 1.1. Motivaci´on.................................... 7 1.2. Objetivos .................................... 7 1.3. Metodolog´ıa................................... 8 1.4. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Estado del Arte 11 2.1. El Internet de las Cosas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2. Telecomunicaciones: LTE, LTE-A y WiMax . . . . . . . . . . . . . . . . . 13 2.3. Dispositivos: Android, Arduino y otros . . . . . . . . . . . . . . . . . . . . 14 2.4. Aplicaciones existentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.5. Conclusi´on del cap´ıtulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3. Especificaci´on y dise˜no 19 3.1. Objetivos .................................... 19 3.2. Requisitos.................................... 20 3.3. CasosdeUso .................................. 20 3.3.1. Acceso a la jerarqu´ıa . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.3.2. Acceso a los datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.4. Diagramasdeclases............................... 21 3.5. Diagramasdeactividad............................. 22 3.6. Arquitectura................................... 23 3.7. Conclusi´on del cap´ıtulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4. An´alisis de las tecnolog´ıas 27 4.1. HTTP ...................................... 27 4.1.1. Introducci´on a HTTP . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.1.2. HTTP/2................................. 29 4.2. Node.js...................................... 29 1 ´ INDICE GENERAL 4.2.1. Introducci´on a Node.js . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.2.2. Desarrollo en Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.2.3. Express ................................. 30 4.2.4. NPM, Javascript y JSON . . . . . . . . . . . . . . . . . . . . . . . 32 4.3. MongoDB.................................... 33 4.3.1. Introducci´on a Mongo DB . . . . . . . . . . . . . . . . . . . . . . . 33 4.3.2. Estructura no relacional . . . . . . . . . . . . . . . . . . . . . . . . 33 5. Implementaci´on de la plataforma 35 5.1. Entornodedesarrollo.............................. 35 5.1.1. WebStorm................................ 35 5.1.2. Git.................................... 36 5.1.3. Servidor de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.2. Implementaci´on de funcionalidades . . . . . . . . . . . . . . . . . . . . . . 37 5.2.1. Inicializaci´on .............................. 38 5.2.2. RutasHTTP .............................. 39 5.2.3. Basededatos.............................. 43 5.2.4. Servidor en funcionamiento . . . . . . . . . . . . . . . . . . . . . . 44 5.2.5. P´agina web y rutina . . . . . . . . . . . . . . . . . . . . . . . . . . 46 6. Conclusi´on y l´ıneas futuras 51 6.1. Conclusi´on.................................... 51 6.2. L´ıneasfuturas.................................. 52 7. Ap´endice A 55 7.1. Gu´ıa de instalaci´on del servidor . . . . . . . . . . . . . . . . . . . . . . . . 55 7.1.1. Sistema operativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 7.1.2. Requisitos previos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 7.1.3. Clonaryarrancar............................ 56 2 ´ Indice de figuras 2.1. La predicci´on que realiza Ericsson es que antes de 2025 contaremos con 50 mil millones de dispositivos conectados. . . . . . . . . . . . . . . . . . . . 12 2.2. La placa Galileo desarrollada por Intel. . . . . . . . . . . . . . . . . . . . . 12 2.3. Diversas tecnolog´ıas inal´ambricas comparadas en t´erminos de velocidad y movilidad..................................... 13 2.4. Ejemplo de uso de un sistema de SmartSantander. . . . . . . . . . . . . . . 16 2.5. Esquema de la arquitectura utilizada por el sistema SIEGA para vi˜nedos. . 16 3.1. Diagrama de caso de uso para el acceso a la jerarqu´ıa. . . . . . . . . . . . . 21 3.2. Diagrama de caso de uso para el acceso a los datos. . . . . . . . . . . . . . 21 3.3. Diagrama de clases de nuestra aplicaci´on. . . . . . . . . . . . . . . . . . . . 22 3.4. Diagrama de actividad de un registro de un nuevo dispositivo. . . . . . . . 23 3.5. Diagrama de actividad de una petici´on de datos con filtro. . . . . . . . . . 23 3.6. Diagrama del dise˜no de la arquitectura. . . . . . . . . . . . . . . . . . . . . 24 4.1. Petici´on HTTP/1.1detipoGET........................ 28 4.2. Respuesta conc´odigo200. ........................... 28 4.3. Aplicaci´on de Node.js generada autom´aticamente por Express. . . . . . . . 32 4.4. Estructura de una base de datos en Mongo DB. . . . . . . . . . . . . . . . 33 5.1. Captura de pantalla del IDE WebStorm. . . . . . . . . . . . . . . . . . . . 36 5.2. Estructura de Git frente a SVN, otro gestor de versiones. . . . . . . . . . . 37 5.3. Flujo de trabajo de Gitflow. . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3 ´ INDICE DE FIGURAS 4 Cap´ıtulo 2 Estado del Arte Para el segundo cap´ıtulo, es conveniente realizar un estudio del Estado del Arte que nos permitir´a poner en contexto a este trabajo. Comenzaremos con una mirada en general al Internet de las Cosas para luego enfocar en los dispositivos que se encuentran en el mercado y las aplicaciones que utilizan este concepto. 2.1. El Internet de las Cosas Como ya hemos mencionado con anterioridad, no se trata de un concepto nuevo, pero que realmente no ha sido ampliamente desarrollado hasta los ´ultimos a˜nos. Las tecnolog´ıas que est´an potenciando y sustentando este avance se pueden dividir en dos grupos. Por un lado, el fuerte avance en campo de las telecomunicaciones y por otro, el abaratamiento y la llamada democratizaci´on de los dispositivos que conforman las cosas de este Internet de las Cosas. Existen diversas empresas de gran calado que han apostado por la investigaci´on y el desarrollo en este campo, entre las que se encuentran: Ericsson. Una de las empresas pioneras en el ´ambito de las telecomunicaciones y con una presencia a nivel mundial en el mercado tecnol´ogico, tiene una fuerte apuesta por el Internet de las Cosas, financiando proyectos de investigaci´on y con alianzas con otras empresas, como Volvo o Cisco, para realizar aplicaciones m´as cerca de las necesidades de la sociedad.[2] 11 2.1. EL INTERNET DE LAS COSAS Figura 2.1: La predicci´on que realiza Ericsson es que antes de 2025 contaremos con 50 mil millones de dispositivos conectados. Intel. Otro gran jugador en el campo del Internet de las Cosas es el gigante Intel. Podemos encontrar un avance en el desarrollo de tecnolog´ıas que faciliten el despliegue en sectores como la industria de la energ´ıa o de la automoci´on. Intel cuenta adem´as con su propio dispositivo preparado para el Internet de las Cosas, se trata del Intel Gallileo o el Intel Edison que analizaremos m´as adelante.[3] Figura 2.2: La placa Galileo desarrollada por Intel. Google. Debemos destacar tambien el trabajo de Google que ha potenciado a diversas empresas de este campo, adem´as cuenta con una fuerte apuesta para el Internet de las Cosas dentro de su Plataforma como Servicio llamada Google Cloud Platform. [4] 12 CAP´ ITULO 2. ESTADO DEL ARTE 2.2. Telecomunicaciones: LTE, LTE-A y WiMax Se trata de un sector no tan visible pero crucial para el desarrollo del Internet de las Cosas. Sin un sistema de telecomunicaciones que nos permita desplegar nuestros sistemas de forma barata y con un bajo coste energ´etico, no ser´ıa posible desarrollar el Internet de las cosas por lo que se puede considerar como un pilar fundamental. Ciertos estudios [5] nos muestran que el crecimiento en el n´umero de dispositivos conectados a la red est´a creciendo a raz´on de un 30 % m´as cada a˜no. Podemos observar que los est´andares que se est´an implementando y los planes de futuro para ´estos cuentan con una orientaci´on hacia la masificaci´on de los dispositivos, potenciado principalmente por el abaratamiento de los dispositivos m´oviles pero tambi´en por el avance en el Internet de las Cosas. En general las diferentes tecnolog´ıas que se est´an desarrollando en este campo, vienen a cubrir un espacio que hasta entonces no hab´ıa estado poblado entre las tecnolog´ıas Wi-Fi y las m´oviles como GSM como podemos ver en el gr´afico 2.3. Figura 2.3: Diversas tecnolog´ıas inal´ambricas comparadas en t´erminos de velocidad y movilidad. Dentro de estos est´andares podemos destacar: Long Term Evolution (LTE). Dise˜nado por un consorcio de las organizaciones que controlan el sector de las telecomunicaciones a nivel supranacional, el 3GPP (siglas por su nombre en ingl´es, “3rd Generation Partnership Project”) que se encarga, entre otros asuntos, del desarrollo y mantenimiento de los est´andares de tecnolog´ıas de telecomunicaciones que son adoptadas por el mercado. La tecnolog´ıa LTE cuenta con un dise˜no basado en anteriores tecnolog´ıas como GSM o UMTS y ofrece una capacidad y velocidad mejorada. Su implantaci´on comenz´o en 2010 y a d´ıa de hoy su cobertura se extiende por la inmensa mayor´ıa de los pa´ıses con una buena penetraci´on como podemos observar en esta tabla 2.1 extra´ıda de un estudio realizado en 2015. [6] 13 2.3. DISPOSITIVOS: ANDROID, ARDUINO Y OTROS Posici´on Pa´ıs Penetraci´on 1 Korea del Sur 97 % 2 Jap´on 90 % 3 Italia 90 % 4 Kuwait 86 % Cuadro 2.1: Los pa´ıses con mayor penetraci´on de LTE. Long Term Evolution Advanced (LTE-A). Se trata de la evoluci´on de la tecnolog´ıa LTE y es la primera en cumplir realmente con el est´andar de 4G propuesto por el 3GPP aunque tecnolog´ıas anteriores ya hab´ıan sido etiquetadas como 4G. Cuenta con un ancho de banda a´un mayor que su predecesor y una de sus mayores novedades es el uso de una arquitectura basada completamente en paquetes IP. [7] Worldwide Interoperability for Microwave Access (WiMax). Creado inicialmente como una alternativa a las l´ıneas cableadas de internet utilizando tecnolog´ıa inalambrica para ello. Actualmente cuenta con uso medianamente extendido y su ´ultima versi´on, WirelessMAN-Advanced, cumple el est´andar de 3GPP para 4G por lo que se establece como un competidor directo de LTE-A.[8] 2.3. Dispositivos: Android, Arduino y otros La otra cara de la moneda la conforman los dispositivos que estructuran el Internet de las Cosas. Con ellos realizaremos las tareas de recopilaci´on de datos o de informaci´on sobre el entorno y los usuarios, pero tambi´en ser´an usados para llevar a cabo acciones automatizadas en respuesta a esta informaci´on. Se trata de un punto cr´ıtico debido a las caracter´ısticas de cada una de las plataformas existentes ya que debemos tener en cuenta asuntos como el consumo de energ´ıa y la potencia de procesamiento, as´ı como la conectividad con los diversos sensores, para encontrar el mejor equilibrio que se ajuste a la situaci´on. En la actualidad, el mercado de dispositivos se encuentra en pleno crecimiento gracias a la apuesta de gigantes de la industria de la tecnolog´ıa y la incursi´on de nuevos jugadores provenientes de pa´ıses como China o India. Esta situaci´on ofrece un abaratamiento importante de los precios as´ı como una competencia que impulsa la tecnolog´ıa. Podemos destacar como l´ıderes en el mercado las siguientes plataformas: Android. Inicialmente dise˜nado por una peque˜na empresa que ser´ıa comprada en 2005 por Google. Actualmente se trata del sistema operativo m´ovil con mayor penetraci´on en el mundo debido a que es distribuido por la compa˜n´ıa como software libre. Es fabricado por muchos fabricantes en todo el mundo por lo que cuenta con una amplia gama de dise˜nos y aplicaciones. No solo un sistema operativo para dispositivos de telefon´ıa m´ovil sino que est´a presente en muchos otros dispositivos como televisiones o tabletas. Su impresionante extensi´on y bajo coste, as´ı como una 14 CAP´ ITULO 2. ESTADO DEL ARTE gran facilidad para realizar aplicaciones, hacen de esta plataforma una elecci´on muy interesante. [9] Arduino. Dise˜nado desde el principio como dispositivo con software y hardware libres, ofrece una plataforma muy interesante que cuenta con una comunidad muy extendida y adem´as es un buen sistema para iniciarse en el mundo de los sistemas empotrados. Su estrategia de dise˜no libre le permite adem´as que distintos fabricantes puedan vender los dispositivos a precios muy asequibles. Se programan a bajo nivel y cuentan con una amplia gama de sensores y ampliaciones que van desde sensores de movimiento o contaminaci´on hasta extensiones que permiten acceso a internet o a la red m´ovil. A˜nadir imagen de un arduino.[10] Intel, Libellium y BQ. Otros grandes fabricantes tienen sus propias apuestas preparadas para el Internet de las Cosas. Es el caso de Intel con su dispositivo Edison, Libellium con su gama de productos preparada para crear un ecosistema para desarrolladores y BQ, fabricante espa˜nol, que tambi´en se ha unido a la tendencia con su propio dispositivo llamado BQ Zum. 2.4. Aplicaciones existentes En esta secci´on analizaremos algunas aplicaciones que a d´ıa de hoy se aprovechan del Internet de las Cosas. De esta manera, se analizar´a el estado del despliegue y la amplitud que han alcanzado las aplicaciones m´as conocidas para poder tener una visi´on m´as global de todo el ecosistema, sobretodo desde un punto de vista m´as econ´omico y pr´actico. Aparcamiento. El aparcamiento se ha convertido en un problema cr´onico en las grandes ciudades, llegando a un punto en el que la tecnolog´ıa puede ser extremadamente beneficiosa para mejorar la vida de los usuarios. Es el caso de la empresa SmartSantander que ha conseguido desarrollar e implantar en la ciudad de Santander un sistema de aparcamiento inteligente mediante sensores colocados en las plazas de aparcamiento para conseguir que los usuarios encuentren una plaza de manera f´acil y r´apida. En la imagen 2.4 podemos ver como se despliega este sistema.[11] 15 2.4. APLICACIONES EXISTENTES Figura 2.4: Ejemplo de uso de un sistema de SmartSantander. Agricultura. La agricultura tambi´en es un ´area en el que el desarrollo del Internet de las cosas ha llevado grandes avances, consiguiendo sistemas que permitan un ahorro de recursos y una mejora en la eficiencia de los cultivos. Como ejemplo cercano de esta nueva agricultura tenemos el sistema “SIEGA” que se encuentra actualmente desplegado en vi˜nedos de Galicia ofreciendo par´ametros ambientales como humedad o temperatura. Estos datos son recogidos como se puede ver en la imagen 2.5 para luego ser procesados para realizar predicciones y/o tomar acciones acordes a la situaci´on en tiempo real del vi˜nedo.[13] Figura 2.5: Esquema de la arquitectura utilizada por el sistema SIEGA para vi˜nedos. 16 CAP´ ITULO 2. ESTADO DEL ARTE Contaminaci´on. Con el crecimiento de las grandes ciudades, la contaminaci´on medioambiental se ha convertido en un problema cr´onico. Algunas ciudades han optado por cerrar el acceso a la mayor parte del tr´afico o por reducirlo, pero para cualquier soluci´on que busque ser eficiente, un despliegue de una red de sensores ayudar´a a obtener informaci´on en tiempo real y con mucha m´as precisi´on, con el objetivo de adelantarse a los picos de contaminaci´on mediante software predictivo o la r´apida respuesta ante problemas no previstos. En la ciudad de Londres, una peque˜na empresa ha desarrollado un sistema que utiliza palomas equipadas con un peque˜no dispositivo para realizar su propio despliegue de sensores de contaminaci´on.[14] 2.5. Conclusi´on del cap´ıtulo Se puede observar que en los ´ultimos a˜nos, las grandes empresas han dejado el terreno preparado para que los peque˜nos empresarios puedan desarrollar sus propias aplicaciones del Internet de las Cosas. Pero, aunque el desarrollo tecnol´ogico podr´ıamos observar que ya ha llegado, las aplicaciones que se han implementado no se encuentran al alcance de todos. En la mayor´ıa de los casos se trata de aplicaciones “verticales” que se desarrollan para una situaci´on en concreto y no con miras a un despliegue m´as global. Podemos concluir que el verdadero desarrollo del Internet de las Cosas llegar´a cuando las aplicaciones “horizontales” comiencen a implementarse y a llegar a todos los usuarios. 17 2.5. CONCLUSI´ ON DEL CAP´ ITULO 18 Cap´ıtulo 3 Especificaci´on y dise˜no Gracias a la visi´on que hemos obtenido en el estudio del Estado del Arte, podemos comenzar con el dise˜no y an´alisis de los requisitos para nuestra plataforma. Revisaremos los objetivos, para pasar por un proceso de dise˜no de la arquitectura que se adapte de la mejor forma posible. En este cap´ıtulo se intentar´a no profundizar en la tecnolog´ıa a utilizar ya que as´ı conseguiremos un dise˜no que sea independiente de la implementaci´on. [15] 3.1. Objetivos Es muy importante tener en cuenta los objetivos que nos hemos propuesto inicialmente para poder definir el alcance del sistema. Los revisaremos y profundizaremos en cada uno de ellos para luego pasar a definir algunos casos de uso. Dise˜no e implementaci´on de un middleware con los servicios necesarios para la recolecci´on, almacenamiento y provisi´on de datos de dispositivos del Internet de las Cosas. Se trata de nuestro principal objetivo y como tal merece la mayor atenci´on. Debemos tener en cuenta que los datos contar´an con un una jerarqu´ıa a la que pertenecen y que para ello se deber´a poder almacenar informaci´on sobre, al menos, los usuarios y los dispositivos a los que pertenecen los datos recibidos. Para ello, lo mejor es dise˜nar el sistema de modo que los usuarios tengan acceso a dicha jerarqu´ıa y puedan modificarla a su conveniencia. Implementaci´on de una p´agina web que permita mostrar y comprobar el correcto funcionamiento del middleware. Para comprobar el correcto funcionamiento del sistema, vamos a desarrollar una r´apida p´agina web que utilice nuestro servicio de middleware para mostrar informaci´on. Se complementar´a con una peque˜na rutina que simular´a el comportamiento de un despliegue de dispositivos, mostrando la informaci´on recopilada de manera ordenada. Como se trata de un objetivo secundario, 19 3.2. REQUISITOS Req. Descripci´on Prioridad RF1 Acceso CRUD a la informaci´on de los usuarios:El usuario debe tener acceso a esta informaci´on ya que es b´asica para la configuraci´on por parte del usuario de su propio despliegue. Alta RF2 Acceso CRUD a la informaci´on de los dispositivos:Igualmente, el usuario debe poder tener un acceso completo a sus dispositivos, para poder realizar las tareas necesarias de administraci´on. Alta RF3 Env´ıo de datos desde un dispositivo: La recopilaci´on de datos es b´asica en nuestro sistema y por ello el usuario debe contar con un m´etodo sencillo de env´ıo de datos. Alta RF4 Lectura del ´ultimo dato de un dispositivo: Debido a que en muchos casos los datos se recibir´an de manera peri´odica, el cliente que desee estar al tanto de los datos puede pedir el ´ultimo como una primera forma de acceso a los datos. Alta RF5 Petici´on de datos de un dispositivo con filtro: Para que el usuario pueda recabar la informaci´on que necesite, se debe ofrecer un m´etodo de peticiones de datos mediante el uso de filtros. Media Cuadro 3.1: Requisitos funcionales de nuestro sistema. no contar´a con un an´alisis tan a fondo de sus requisitos y se explicar´a su desarrollo en el cap´ıtulo de implementaci´on. 3.2. Requisitos Analizando estos objetivos, podemos proceder a listar los requisitos funcionales m´as importantes de nuestra aplicaci´on, que ser´an una gu´ıa excelente para el posterior desarrollo. En la tabla 3.1 se muestran los requisitos, teniendo en cuenta su prioridad. 3.3. Casos de Uso Para visualizar las diferentes situaciones con las que vamos a encontrarnos vamos a dise˜nar algunos casos de uso que nos ser´an ´utiles para la identificaci´on de los requisitos funcionales y para el desarrollo de la plataforma. Vamos a dividir los casos de uso en dos apartados: acceso a los datos y acceso a la jerarqu´ıa. No habr´a una diferencia tan grande en el acceso a las distintas partes desde el punto de vista del desarrollo pero nos facilitar´a el dise˜no de los casos de uso. 3.3.1. Acceso a la jerarqu´ıa Se trata de un caso de uso b´asico en el que el usuario accede para leer, crear o modificar los datos sobre los usuarios del sistema o los dispositivos. Aunque no est´a incluido en este 20 Cap´ıtulo 4 An´alisis de las tecnolog´ıas En este tercer cap´ıtulo vamos a analizar brevemente las tecnolog´ıas elegidas para el desarrollo del Trabajo. Se pondr´a el foco en dichas tecnolog´ıas pero tambi´en habr´a espacio para estudiar algunas alternativas. Hay que tener en cuenta que estamos ante una oferta muy amplia de opciones y que la elecci´on es clave para la implementaci´on que vamos a realizar de nuestro dise˜no. Las tecnolog´ıas han sido elegidas por su facilidad de uso, su excelente soporte y su amplia difusi´on. 4.1. HTTP Es la base de todo nuestro desarrollo y como tal deberemos analizarlo para tener una visi´on muy clara de su funcionamiento. La versi´on m´as extendida de HTTP es la 1.1 publicada en 1997 pero que ha ido recibiendo actualicaciones hasta 2014. Es por ello que en primer lugar vamos a centrarnos en esta versi´on m´as extendida para luego hacer un peque˜no an´alisis de la nueva versi´on que ya est´a comenzando a ser implantada.[16] 4.1.1. Introducci´on a HTTP HTTP es un protocolo de comunicaci´on que se encuentra en la base de la web que conocemos hoy en d´ıa. Fue creado en 1991 por Tim Berners-Lee en el CERN donde tambi´en desarroll´o HTML y la tecnolog´ıa necesaria para los servidores web. Cuenta con un dise˜no cliente-servidor que permite realizar aplicaciones de manera muy sencilla, de modo que solo es necesario que el cliente emita una petici´on en la que se env´ıa o se pide informaci´on y el servidor responder´a con una respuesta que podr´a ser una p´agina HTML, un archivo o un simple c´odigo de control. Existen varios tipos de petici´on cada uno con un rol asignado tal y como se detalla en la tabla 4.1. A continuaci´on, en la imagen 4.1, podemos ver como ser´ıa una petici´on GET t´ıpica de HTTP/1.1: 27 4.1. HTTP M´etodo Descripci´on GET Recupera la informaci´on especificada. POST Sirve para el env´ıo del informaci´on al servidor. PUT Modifica informaci´on espec´ıfica en el servidor. DELETE Elimina la informaci´on especificada. TRACE Sirve para ver la petici´on que se realiza al servidor. HEAD Con este m´etodo el servidor devuelve tan solo la cabecera. CONNECT No se encuentra en uso actualmente. OPTIONS Recupera informaci´on sobre las opciones del servidor. Cuadro 4.1: Tipos de petici´on en HTTP/1.1. C´odigo Descripci´on 1xx Informaci´on variada enviada por el servidor. 2xx Son los c´odigos de ´exito en la petici´on. 3xx Redirecci´on. 4xx Nos informa sobre un error en el cliente. 5xx Informaci´on sobre un error en el servidor. Cuadro 4.2: C´odigos de respuesta HTTP/1.1. Figura 4.1: Petici´on HTTP/1.1 de tipo GET. Tras la recepci´on por parte del servidor de esta petici´on, se dispondr´a a responder con una respuesta en la que viene incluido un c´odigo de control. Los c´odigos m´as comunes est´an detallados en la tabla 4.2. En este caso el servidor responder´a con un archivo JSON que es el tipo que espera el cliente como se puede ver en la imagen 4.2. Figura 4.2: Respuesta con c´odigo 200. De esta sencilla manera, conseguimos un protocolo muy vers´atil y que permite utili28 CAP´ ITULO 4. AN´ ALISIS DE LAS TECNOLOG´ IAS zarse con mucha libertad. Est´a en manos del desarrollador utilizar su potencial y nosotros lo usaremos como la base para recibir y enviar informaci´on utilizando el formato JSON que ser´a explicado m´as adelante. 4.1.2. HTTP/2 Es la nueva versi´on de HTTP, definida en 2015 y que a d´ıa de hoy ya se encuentra en algunos servidores web y en todos los navegadores modernos. Su objetivo no es modificar el funcionamiento del protocolo a nivel de desarrollo sino a nivel de transporte. Con esto se busca mejorar la optimizaci´on de las comunicaciones reduciendo el tiempo de espera para el usuario y disminuyendo la carga en los servidores. Una importante innovaci´on con respecto a HTTP/1.1 es la introducci´on del uso de una sola conexi´on para la descarga de una p´agina web completa, que conlleva una importante mejora de rendimiento. Otro importante avance que introduce HTTP/2 es el de “server push” que se basa en la idea de que es el servidor el que origina la comunicaci´on con el cliente. Esto es interesante en el sector del Internet de las Cosas ya que nos ofrece la posibilidad de reducir el tr´afico en los casos en los que es el cliente el que tiene que esperar alguna informaci´on espec´ıfica del servidor, ya que en lugar de realizar actualizaciones peri´odicas, el cliente puede esperar a que el servidor tenga lista la informaci´on deseada. Este m´etodo se encuentra en contraposici´on al usual “server pull” en el que es el cliente el que pide la informaci´on y la espera de forma s´ıncrona. 4.2. Node.js Node.js es un entorno de desarrollo enfocado en la creaci´on de aplicaciones web para el servidor y fue creado en 2009 por Ryan Dahl. Se trata de una plataforma innovadora ya que combina las novedades del motor de Google “Javascript V8” con una arquitectura basada en eventos que permite una gesti´on as´ıncrona de la aplicaci´on. En los siguientes apartados profundizamos m´as en estos conceptos.[17] 4.2.1. Introducci´on a Node.js Node.js supuso un cambio en el paradigma del desarrollo de servidores que hasta entonces hab´ıan liderado JavaEE o PHP en el que se realizaba un procesamiento s´ıncrono de las peticiones recibidas. Es en este punto en el que Node.js ha destacado m´as, llevando el desarrollo as´ıncrono basado en eventos al desarrollo web. A continuaci´on vamos a definir brevemente algunos de estos conceptos para poder continuar profundizando en el desarrollo en Node.js: S´ıncrono y As´ıncrono. Node.js est´a dise˜nado para ejecutarse como un ´unico proceso, obligando al desarrollador a utilizar programaci´on as´ıncrona. La diferencia entre los dos tipos de programaci´on est´a en que el desarrollo s´ıncrono suele contar con bloqueos en los que el programa espera a que termine una funci´on para continuar 29 4.2. NODE.JS la ejecuci´on. En cambio, con el modelo as´ıncrono se utilizan funciones de callback que permiten que el c´odigo se ejecute sin detenerse, efectuando varias operaciones en paralelo. Callback (Retrollamada). No se trata de un concepto ´unico de Node.js pero se encuentra en pr´acticamente cada pieza de c´odigo del entorno. Una callback es una funci´on que se entrega a otra como un argumento y a la que se llama cuando la primera finaliza su ejecuci´on. En el pr´oximo apartado se analizar´a un ejemplo de una funci´on a la que se llama pasando por argumento una funci´on de callback. 4.2.2. Desarrollo en Node.js A continuaci´on podemos ver un extracto de c´odigo t´ıpico de Node.js en el que se realiza una funci´on de callback: 1function haveBreakfast (food , drink , callback ) { 2console . log (’Having breakfast of ’ + food + ’, ’ + drink + ’.’); 3if ( callback && typeof( callback ) == " function ") { 4callback (); 5} 6} 7 8haveBreakfast (’toast ’,’coffee ’,function() { 9console . log (’ Finished breakfast . Time to go to work !’); 10 }); 11 console . log (’ Reading newspaper . ’) Listing 4.1: Ejemplo funci´on callback. Procediendo a analizar con detalle este dise˜no, podemos observar que al realizar la llamada a la funci´on “haveBreakfast” el c´odigo no se bloquear´a esperando a que finalice, sino que cuando acabe llamar´a a la funci´on an´onima de callback que hemos pasado como tercer par´ametro. Mientras tanto, si la funci´on tuviera que acceder a una base de datos por ejemplo, la ejecuci´on continuar´ıa con el mensaje “Reading newspaper.”. Esto nos permite realizar una ejecuci´on en el servidor del c´odigo de manera paralela, descolg´andonos de la espera en las llamadas a bases de datos o a otros servicios. En cuanto a la estructura de una aplicaci´on Node.js, se nos ofrece libertad para el desarrollo, pero para facilitarlo existen diversas librer´ıas (llamadas m´odulos en Node.js) que nos ofrecen una estructura sobre la que trabajar y as´ı ahorrarnos un trabajo que ser´ıa muy repetitivo. Para ello vamos a utilizar el m´odulo Express que cuenta con un soporte directo por parte de Node.js y es el m´as extendido. 4.2.3. Express Express es un framework web para Node.js que aprovecha los patrones que se suelen cumplir en las aplicaciones de servidor para facilitar el desarrollo y crear aplicaciones m´as estables. Aunque se trata de un m´odulo bastante ligero, cuenta con una funcionalidad para 30 CAP´ ITULO 4. AN´ ALISIS DE LAS TECNOLOG´ IAS desarrollar una API basada en JSON que nos podr´a ahorrar mucho trabajo en nuestro desarrollo. Adem´as, Express se encarga de realizar otras tareas por nosotros como la puesta a punto del enrutamiento de las peticiones HTTP o la gesti´on de vistas y modelos. En concreto, Express crear´a una aplicaci´on esqueleto para nosotros sobre la que podremos desarrollar directamente, ahorr´andonos la repetitiva tarea de crear proyectos desde cero en cada nuevo desarrollo. Aunque Express permite realizar otro tipo de organizaci´on, la estructura que crea, como podemos ver en la imagen ??, es la siguiente: node modules. Carpeta destinada a contener las librer´ıas utilizadas, que en Node.js son llamadas m´odulos. No debemos modificarla directamente ya que Node.js cuenta con un gestor de dependencias llamado NPM que se encarga de esto y que se explicar´a m´as adelante. bin. En esta carpeta se encuentra el punto de entrada de la aplicaci´on y por lo general no debe ser modificada. public. Aqu´ı se almacenan los los recursos que ser´an accedidos por los usuarios. Generalmente se almacenan aqu´ı los archivos est´aticos como im´agenes y hojas de estilo. routes. Ser´a el punto central de nuestro desarrollo y cuenta con los archivos que gestionan las rutas de las peticiones HTTP. Puede estar organizado en diferentes archivos para facilitar su lectura. Esto nos facilitar´a mucho el trabajo ya que permite crear una API de tipo REST de una manera sencilla y directa. views. Las vistas ser´an los trozos de c´odigo que generen las p´aginas web que se presenten a los usuarios. Nosotros no usaremos esta caracter´ıstica pero cabe mencionar que Express utiliza el sistema de plantillas Jade para este cometido. app.js. Es el archivo central de nuestra aplicaci´on y desde aqu´ı iniciaremos las diferentes rutas necesarias para nuestro sistema as´ı como la inicializaci´on de las bases de datos y otros asuntos generales que no sean espec´ıficos de cada petici´on. package.json. Se trata de un archivo generado por el gestor de dependencias NPM, se ir´a formando autom´aticamente conforme vayamos desarrollando la aplicaci´on y definir´a diversos aspectos como el arranque del servidor, la gesti´on de los m´odulos o la ejecuci´on de los tests unitarios. 31 4.2. NODE.JS Figura 4.3: Aplicaci´on de Node.js generada autom´aticamente por Express. 4.2.4. NPM, Javascript y JSON Para finalizar con el an´alisis de Node.js, es necesario hacer una corta menci´on a estos conceptos que han surgido durante esta secci´on. Adem´as ser´an de gran utilidad en las proximas secciones y cap´ıtulos. Los conceptos m´as destacables son: Node Package Manager(NPM). El entorno de Node.js cuenta desde 2011 con este gestor de dependencias que por una parte nos permite abstraernos de la tarea de gestionar las librer´ıas y de su actualizaci´on, pero que tambi´en se ofrece como una herramienta de gesti´on de la aplicaci´on con funciones de instalaci´on en el caso de mover el c´odigo, de inicializaci´on del servidor o de inicializaci´on de la ejecuci´on de tests unitarios. Adem´as ofrece la posibilidad de crear diferentes modos de inicio, creando por ejemplo, rutinas de inicio distintas para las tareas de depuraci´on y para la puesta en producci´on. Javascript. Es el lenguaje en el que se escriben el c´odigo de Node.js y por tanto es clave conocer su funcionamiento antes de comenzar a desarrollar en el entorno. Su vida se encuentra muy ligada a la de internet ya que originalmente fue concebido para crear rutinas en las p´aginas web que se ejecutaran en el lado del cliente. Desde entonces ha tenido un enorme crecimiento y a d´ıa de hoy se utiliza, por su excelente versatilidad, en diversos proyectos como Angular.js ´o JQuery que ofrecen excelentes herramientas para el desarrollo de aplicaciones en web. Se trata siempre de un lenguaje interpretado por los motores V8 de Google o SpiderMonkey de Mozilla, entre otros.[19] Javascript Object Notation (JSON). Este est´andar para la transmisi´on de objetos, que surgi´o en el seno de Javascript, consigue que la informaci´on sea legible para las personas gracias a una estructura de pares clave-valor. En la actualidad muchos otros lenguajes cuentan con soporte para JSON y est´a ampliamente extendido. Ser´a nuestra base para el manejo de la informaci´on ya que como veremos m´as adelante, la base de datos que vamos a utilizar, est´a basada en esta notaci´on. 32 CAP´ ITULO 4. AN´ ALISIS DE LAS TECNOLOG´ IAS 4.3. Mongo DB Mongo DB es un sistema gestor de bases de datos no relacional que ha tenido un importante crecimiento en los ´ultimos a˜nos, encontr´andose muy ligado a internet y a Node.js. La programaci´on de Mongo DB se realiza en Javascript por lo que utilizaremos el mismo lenguaje en nuestro desarrollo del servidor y en la base de datos.[18] 4.3.1. Introducci´on a Mongo DB Mongo DB cuenta con una distribuci´on gratuita y con licencia libre por lo que podemos tener acceso a todo su c´odigo y utiliza una estructura no relacional para almacenar la informaci´on. Ha sido desarrollada por la empresa 10gen, ahora llamada MongoDB Inc., desde 2007 y cuenta con una comunidad y una documentaci´on excelentes. Su desarrollo siempre ha contado con un foco muy importante en el alto rendimiento, debido a que es utilizado principalmente por servidores web, pero tambi´en ha tenido en cuenta mantener su estructura din´amica para poder adaptarse a las necesidades cambiantes de cualquier aplicaci´on web. Cuenta igualmente con caracter´ısticas comunes en el mercado de las bases de datos como la agregaci´on, utilizando MapReduce, o el balanceo de carga para permitir la escalabilidad de la base de datos. 4.3.2. Estructura no relacional Es una de las caracter´ısticas clave de Mongo DB, que permite desprenderse de la estructura r´ıgida de las tablas en las bases de datos relacionales para utilizar un sistema de esquemas din´amicos que Mongo DB denomina “BSON (Binary JSON)” en clara referencia a la estructura JSON. En la imagen 4.4 podemos ver como est´a dise˜nada la estructura de esta base de datos. Cada base de datos est´a formada por colecciones y son el equivalente a las tablas en una base de datos relacional, pudiendo contener tantas colecciones como sea necesario. Por otro lado contamos con los documentos, que ser´ıan equivalentes a las filas, y conforman la informaci´on que es almacenada en nuestra base de datos. Los documentos son objetos BSON y deben ser almacenados siempre dentro de una colecci´on. Figura 4.4: Estructura de una base de datos en Mongo DB. Por ´ultimo, a continuaci´on se muestra un ejemplo de escritura y lectura en Mongo DB. 33 4.3. MONGO DB Donde podemos observar que se utilizan llamadas a funciones javascript para realizar estas tareas, adem´as de utilizar el sistema de callback que definimos con anterioridad. 1var collection = db . collection (’test ’); 2var doc = { myket :1 , 3text:" Hola Mundo ." }; 4 5collection . insert ( doc ); 6collection . findOne ({ mykey :1} , function(err , item ) {}); Listing 4.2: Ejemplo de escritura y lectura en Mongo DB. 34 Cap´ıtulo 5 Implementaci´on de la plataforma En est´e pen´ultimo cap´ıtulo vamos a desglosar el desarrollo de la plataforma de una manera resumida pero que tanto la funcionalidad del entorno como de la aplicaci´on en s´ı queden bien claras. Comenzaremos con el entorno de desarrollo y las herramientas utilizadas para esta tarea y continuaremos con la explicaci´on de algunas de las partes m´as importantes del servidor, as´ı como un an´alisis de la estructura utilizada en Mongo DB. 5.1. Entorno de desarrollo La elecci´on y la puesta en marcha de un correcto entorno de desarrollo es una parte importante del proceso de implementaci´on y por tanto vamos a analizar los distintos componentes que han sido claves en este proceso. Cabe destacar que se ha intentado utilizar software libre en la medida de lo posible, acudiendo en su ausencia a software propietario pero con licencias de educaci´on o licencias gratuitas. 5.1.1. WebStorm Es un IDE desarrollado espec´ıficamente para el desarrollo web, creado por la compa˜n´ıa JetBrains, y que nos ofrece un entorno integrado con soporte espec´ıfico para Node.js, lo cual nos facilita mucho la tarea del desarrollo. Cuenta con funci´on de autocompletar y con integraci´on con gestores de versiones. Es esta integraci´on con diferentes elementos del desarrollo lo que hace de este entorno una de las mejores apuestas para trabajar en Node.js frente a otros entornos o editores como Aptana o SublimeText. 35 5.1. ENTORNO DE DESARROLLO Figura 5.1: Captura de pantalla del IDE WebStorm. 5.1.2. Git Git es un sistema de control de versiones que sigue un dise˜no distribuido en el que cada cliente cuenta con un repositorio completo. Fue creado por Linus Torvalds en 2005 para contribuir al desarrollo de Linux. Cuenta con una licencia de uso de software libre y su uso est´a tan extendido que la mayor´ıa de los entornos de desarrollo ya traen integrado este sistema, adem´as de muchos sistemas operativos. En los ´ultimos a˜nos, plataformas colaborativas como Github o Bitbucket, que usan Git como la base de su dise˜no, han permitido una penetraci´on a´un mayor, llegando a utilizarse para otras tareas fuera de la programaci´on.[20] En cuanto a su funcionamiento, en la imagen 5.2 podemos ver como se estructura Git y a continuaci´on en la imagen 5.3 se observa el llamado “gitflow workflow”, flujo de trabajo de Git, que es una de las muchas formas de organizar el desarrollo sobre Git pero la m´as recomendada para el desarrollo de software en equipos de trabajo. 36 CAP´ ITULO 5. IMPLEMENTACI´ ON DE LA PLATAFORMA 147 next (); 148 }) 149 . get ( function (req , res , next ) { 150 var user_id = req . params . user_id ; 151 var device_id = req .params . device_id ; 152 var collection = user_id + ’_’+ device_id ; 153 154 var options = {"sort ":[[’_id ’,’desc ’]], " limit " :1}; 155 db . collection ( collection ). find ({} , options ). toArray ( function (err , result){ 156 assert . equal ( err , null); 157 res . send ( result ); 158 }); 159 160 }); 161 162 function isEmpty ( obj ) { 163 return Object . keys ( obj ). length === 0; 164 } 165 166 module . exports = router ; Listing 5.2: Partes del archivo iot.js 5.2.3. Base de datos Como ya hemos mencionado anteriormente, Mongo DB est´a especialmente dise˜nada para ser muy compatible con Node.js, entre otros, por lo que su puesta a punto es bastante sencilla y se realiza dentro de un archivo que ser´a importando donde sea necesario. Podemos observar que el c´odigo resulta muy sencillo ´este es suficiente para establecer una correcta conexi´on con la base de datos. La variable db es exportada y utilizada en donde sea necesario el acceso a la base de datos. 1var MongoClient = require ( ’mongodb’).MongoClient; 2var assert = require ( ’assert’); 3var ObjectId = require ( ’mongodb’). ObjectID ; 4var url = ’mongodb :// localhost :27017/ iot ’; 5var db; 6 7MongoClient . connect (url , function( err , database ) { 8if (! err ){ 9console . log (" We are connected "); 10 db = database ; 11 }else{ 12 console . log (" DB ERROR "); 13 } 14 }); 15 16 exports . db = function () { 17 return db; 43 5.2. IMPLEMENTACI´ ON DE FUNCIONALIDADES 18 }; Listing 5.3: Contenido del archivo mongo.js 5.2.4. Servidor en funcionamiento Para finalizar el desarrollo del servidor, vamos a analizar brevemente el correcto funcionamiento del servidor, por medio de la salida por pantalla y de la aplicaci´on de consola Httpie. 1$ http POST 127.0.0.1:8000/ angajime \? name \= antonio 2HTTP /1.1 200 OK 3Connection : keep - alive 4Content - Length : 108 5Content - Type : text / html ; charset =utf -8 6Date : Fri , 24 Jun 2016 01:17:43 GMT 7ETag : W/"6cQWsEzN0VSMoJozS0SxtEQg " 8XPowered -By: Express 9 10 Inserted {" name ":"antonio","user_id":" angajime " ,"_id":"576 c8a37e0ab121ff8902f61"} into the users collection . 11 12 $ http GET 127.0.0.1:8000/ angajime 13 HTTP /1.1 200 OK 14 Connection : keep - alive 15 Content - Length : 72 16 Content - Type : application / json ; charset =utf -8 17 Date : Fri , 24 Jun 2016 01:17:46 GMT 18 ETag : W/"48zsynLHtVRdxJONTfpZZb6w " 19 XPowered -By: Express 20 21 { 22 "_id ":"576c895e79233f79efbe3608", 23 "name ":"antonio", 24 "user_id":" angajime " 25 } Listing 5.4: Creaci´on y lectura de un usuario 1$ http POST 127.0.0.1:8000/ angajime / arduino \? loc \= garden 2HTTP /1.1 200 OK 3Connection : keep - alive 4Content - Length : 130 5Content - Type : text / html ; charset =utf -8 6Date : Fri , 24 Jun 2016 01:25:35 GMT 7ETag : W/"82-4ZZXh2bGg7M6naGEaqIi0w" 8XPowered -By: Express 9 10 Inserted {" loc":"garden","user_id":" angajime "," device_id ":"arduino"," _id":"576c8c0fe0ab121ff8902f62"} into the devices collection . 11 44 CAP´ ITULO 5. IMPLEMENTACI´ ON DE LA PLATAFORMA 12 $ http POST 127.0.0.1:8000/ angajime / arduino3 \? loc \= garden 13 HTTP /1.1 200 OK 14 Connection : keep - alive 15 Content - Length : 131 16 Content - Type : text / html ; charset =utf -8 17 Date : Fri , 24 Jun 2016 01:25:49 GMT 18 ETag : W/"83ORny9suj1Wl3WsIssUfV0Q " 19 XPowered -By: Express 20 21 Inserted {" loc":"garden","user_id":" angajime "," device_id ":" arduino3 " ," _id":"576c8c1de0ab121ff8902f63"} into the devices collection . Listing 5.5: Creaci´on y lectura de un dispositivo 1$ http POST 127.0.0.1:8000/ angajime / arduino / bits \? temperatura \=32\& day \=17 2HTTP /1.1 200 OK 3Connection : keep - alive 4Content - Length : 154 5Content - Type : text / html ; charset =utf -8 6Date : Fri , 24 Jun 2016 01:30:14 GMT 7ETag : W/"9aUdHSPb3GXqx0NXZisNiSyg " 8XPowered -By: Express 9 10 Inserted {"temperatura":" 32","day":"17","user_id":" angajime " ," device_id ":"arduino"," _id ":"576c8d26e0ab121ff8902f68"} into the angajime_arduino collection . 11 12 $ http GET 127.0.0.1:8000/ angajime / arduino / bits \? day \=17 13 HTTP /1.1 200 OK 14 Connection : keep - alive 15 Content - Length : 217 16 Content - Type : application / json ; charset =utf -8 17 Date : Fri , 24 Jun 2016 01:30:25 GMT 18 ETag : W/"d9 - eNLI4lOwUKnsvjt1NXqKQQ " 19 XPowered -By: Express 20 21 [ 22 { 23 "_id ":"576c8d1ce0ab121ff8902f67", 24 "day ":"17", 25 " device_id ":"arduino", 26 "temperatura":"35", 27 "user_id":" angajime " 28 }, 29 { 30 "_id ":"576c8d26e0ab121ff8902f68", 31 "day ":"17", 32 " device_id ":"arduino", 33 "temperatura":"32", 34 "user_id":" angajime " 45 5.2. IMPLEMENTACI´ ON DE FUNCIONALIDADES 35 } 36 ] Listing 5.6: Env´ıo de datos y lectura con filtro. Podemos observar que en los tres casos contamos con una API muy sencilla que hace muy legible la comunicaci´on con el servidor. Este era uno de los objetivos originarios del Trabajo ya que una interfaz accesible para los usuarios siempre va a mejorar su interacci´on y ayuda a realizar una depuraci´on m´as sencilla. En el caso de la lectura de datos con filtro, hemos usado uno muy sencillo, pero MongoDB nos permite utilizar filtros mucho mas complejos. Desde el punto de vista del servidor, se nos informa de las diferentes peticiones recibidas y se muestra adem´as el c´odigo con el que se ha respondido a estas junto con la latencia. De este modo, contamos con una visi´on de cliente y servidor que nos permite depurar f´acilmente cualquier problema que surja durante el desarrollo. 1$ npm start 2 3> iot - server@0 .0.0 start / www/iot - server 4> node ./ bin/ www 5 6We are connected 7POST / angajime ? name = antonio 200 10.236 ms - 108 8GET / angajime 200 8.401 ms - 72 9POST / angajime ? name = antonio 200 1.559 ms - 108 10 GET / angajime 200 3.021 ms - 72 11 POST / angajime / arduino ? loc =garden 200 2.826 ms - 130 12 POST / angajime / arduino3 ? loc = garden 200 1.077 ms - 131 13 GET / angajime / arduino 200 1.293 ms - 92 14 POST / angajime / arduino / bits ? temperatura =35 200 3.556 ms - 143 15 POST / angajime / arduino / bits ? temperatura =34 200 0.909 ms - 143 16 POST / angajime / arduino / bits ? temperatura =36 200 0.795 ms - 143 17 GET / angajime / arduino / bits ? temperatura %3E34 200 2.124 ms - 2 18 GET / angajime / arduino / bits ? temperatura %3E35 200 1.494 ms - 2 19 GET / angajime / arduino / bits 200 1.408 ms - 292 20 GET / angajime / arduino / bits ? temperatura =35 200 1.584 ms - 98 21 GET / angajime / arduino / bits ? temperatura =35& day =17 200 0.938 ms - 2 22 GET / angajime / arduino / bits ? temperatura =36& day =17 200 0.918 ms - 2 23 GET / angajime / arduino / bits 200 1.284 ms - 292 24 POST / angajime / arduino / bits ? temperatura =35& day =17 200 0.762 ms - 154 25 POST / angajime / arduino / bits ? temperatura =32& day =17 200 0.845 ms - 154 26 GET / angajime / arduino / bits ? day =17 200 0.945 ms - 217 Listing 5.7: Salida del servidor. 5.2.5. P´agina web y rutina Uno de los objetivos definidos en esta memoria era el de la creaci´on de una simple p´agina web, que acompa˜nado de una rutina de l´ınea de comandos, pudiera simular el 46 CAP´ ITULO 5. IMPLEMENTACI´ ON DE LA PLATAFORMA funcionamiento de un despliegue real de dispositivos para as´ı observar, y depurar, el funcionamiento de nuestra plataforma. Para ello, en el mismo servidor se ha colgado una p´agina web en la ruta ra´ız de modo que fuera f´acilmente accesible. La p´agina web utiliza las librer´ıas Bootstrap y jQuery para facilitar el dise˜no y mejorar su funcionalidad. Se ha elegido un despliegue de sensores de contaminaci´on medioambiental que, desplegados por la ciudad de M´alaga, permiten mostrar informaci´on en tiempo real sobre un mapa de la ciudad. A continuaci´on se adjunta parte del c´odigo de la web y la rutina que genera los datos. 1<! DOCTYPE html > 2<html> 3<head> 4<meta name=" viewport " content=" initial - scale =1.0 , user - scalable = no "> 5<meta charset ="utf -8"> 6<title > Simple web app </ title > 7<script src=" https :// code . jquery . com / jquery -2.2.4. min .js " integrity = "sha256-BbhdlvQf/xTY9gja0Dq3HiwQF8LaCRTXxZKRutelT44=" crossorigin =" anonymous " > 8</ script> 9<link rel =" stylesheet " href=" https :// maxcdn . bootstrapcdn . com / bootstrap /3.3.6/ css / bootstrap . min .css " integrity ="sha384 -1 q8mTJOASx8j1Au+a5WDVnPi2lkFfwwEAa8hDDdjZlpLegxhjVME1fgjWPGmkzs7" crossorigin=" anonymous " > 10 <link rel =" stylesheet " href=" https :// maxcdn . bootstrapcdn . com / bootstrap /3.3.6/ css / bootstrap - theme . min . css " integrity ="sha384 - fLW2N01lMqjakBkx3l / M9EahuwpSfeNvV63J5ezn3uZzapT0u7EYsXMjQV +0 En5r " crossorigin=" anonymous " > 11 <script src=" https :// maxcdn . bootstrapcdn . com / bootstrap /3.3.6/ js / bootstrap . min .js" integrity =" sha384 -0 mSbJDEHialfmuBBQP6A4Qrprq5OVfW37PRR3j5ELqxss1yVqOtnepnHVP9aJ7xS" crossorigin=" anonymous " ></ script> 12 <style > 13 html , body { 14 height : 100 %; 15 margin: 0; 16 padding : 0; 17 } 18 #map { 19 height : 100 %; 20 } 21 </ style > 22 </ head> 23 <body> 24 <div id="map "></div > 25 <script> 26 var devices = [ 27 { name :’d0 ’, lat : 36.7265818 , lng : -4.4236739 , marker : null }, 28 { name :’d1 ’, lat : 36.7261693 , lng : -4.4176548 , marker : null }, 29 { name :’d2 ’, lat : 36.7225686 , lng : -4.4217912 , marker : null }, 30 { name :’d3 ’, lat : 36.7200547 , lng : -4.4287248 , marker : null }, 47 5.2. IMPLEMENTACI´ ON DE FUNCIONALIDADES 31 { name :’d4 ’, lat : 36.7265818 , lng : -4.4343191 , marker : null }, 32 { name :’d5 ’, lat : 36.7241312 , lng : -4.4301827 , marker : null }, 33 { name :’d6 ’, lat : 36.7307617 , lng : -4.4172988 , marker : null }, 34 { name :’d7 ’, lat : 36.7234518 , lng : -4.4256733 , marker : null }, 35 { name :’d8 ’, lat : 36.7281123 , lng : -4.4294029 , marker : null }, 36 { name :’d9 ’, lat : 36.7225142 , lng : -4.417943 , marker : null } 37 ]; 38 39 function createMarker (map , latlng , color , marker ){ 40 41 if ( marker == null ) 42 marker = new google . maps . Marker ({ 43 position : latlng , 44 map: map , 45 title : ’ Device updated .’, 46 icon : color , 47 visible : true 48 }); 49 else 50 marker . setIcon ( color ); 51 marker.setMap(map); 52 } 53 54 function initMap () { 55 var myLatLng = {lat : 36.7265818 , lng: -4.4236739}; 56 57 var map = new google . maps . Map ( document . getElementById (’map ’) , { 58 zoom : 16, 59 center : myLatLng 60 }); 61 62 var time = 500; 63 setInterval ( function (){ 64 for( var i =0;i<=9; i++){ 65 var url = ’/ angajime / ’+ devices [i]. name+ ’/ bits /last ’; 66 $. get (url , function (data, status){ 67 var color ; 68 console . log (data); 69 console . log ( status ); 70 if(data[0]. polution == 1){ 71 color = ’http :// maps . google . com / mapfiles / ms/ icons / green - dot .png ’; 72 }else if( data[0]. polution == 2){ 73 color = ’http :// maps . google . com / mapfiles / ms/ icons / yellow - dot .png ’ 74 }else if( data[0]. polution == 3){ 75 color = ’http :// maps . google . com / mapfiles / ms/ icons / purple - dot .png ’ 76 }else if( data[0]. polution == 4){ 77 color = ’http :// maps . google . com / mapfiles / ms/ icons /red - dot.png ’ 48 CAP´ ITULO 5. IMPLEMENTACI´ ON DE LA PLATAFORMA 78 } 79 console . log ( color ); 80 var num = parseInt ( data[0]. device_id . substr ( data[0]. device_id . length - 1) ); 81 var latlng = { lat : devices [ num ]. lat , lng : devices [ num ]. lng }; 82 var marker = devices [ num ]. marker ; 83 createMarker(map, latlng , color, marker); 84 }); 85 } 86 }, time ); 87 88 } 89 90 91 92 93 94 95 </ script> 96 <script async defer 97 src=" https :// maps . googleapis . com /maps /api /js ?key = AIzaSyBM5mQ8hKgHdqMX9im8d35yftasrFjFawY & signed_in = true & callback = initMap"></ script> 98 </ body> 99 </ html> 1#!/ bin/ bash 2 3declare -a devices =( "d0" "d1" "d2" "d3" "d4" "d5 " "d6" "d7" "d8" "d9" ) 4echo "init " 5while : 6do 7# http POST 127.0.0.1:8000/ angajime / arduino / bits \? temperatura \=35\& day \=17 8 9for device in "${ devices [@ ]} " 10 do 11 pol=$(( ( RANDOM % 4 ) + 1 )) 12 echo ${ pol} 13 curl 127.0.0.1:8000/ angajime /${ device }/ bits ? polution =${ pol } -X POST 14 done 15 sleep 1 16 17 done 49 5.2. IMPLEMENTACI´ ON DE FUNCIONALIDADES 50 Cap´ıtulo 6 Conclusi´on y l´ıneas futuras Para el ´utlimo cap´ıtulo, vamos a hacer una peque˜na retrospectiva una vez hemos finalizado el Trabajo. Para ello intentaremos sacar algunas conclusiones y establecer algunas l´ıneas que pueden surgir a partir de este proyecto. 6.1. Conclusi´on El t´ıtulo de este Trabajo Fin de Grado es “DISE˜ NO E IMPLEMENTACI´ ON DE UN SISTEMA INTERMEDIARIO PARA INTERNET DE LAS COSAS” y, como conclusi´on a este trabajo podemos decir que aunque el dise˜no y la implementaci´on ha resultado no ser demasiado compleja, teniendo en cuenta el limitado alcance del proyecto, es la amplia cantidad de tecnolog´ıas y agentes en juego lo que fundamenta la verdadera complejidad del campo del Internet de las Cosas. Esto nos ofrece por un lado una oportunidad excelente para descubrir nuevas tecnolog´ıas, como ha sido en mi caso con Node.js y Mongo DB, pero por otro, hace que cualquier proyecto comercial alcance una gran complejidad en poco tiempo. Los mayores problemas a los que me he enfrentado durante la realizaci´on han sido relacionados con la elecci´on de la tecnolog´ıa y con el dise˜no de una arquitectura que pudiera acoger el mayor n´umero de casos posibles. Esto se trata de un problema de doble filo porque si apuntamos hacia una arquitectura m´as general, ser´a a costa de ofrecer menos funcionalidades personalizadas que a ciertos usuarios les puede facilitar mucho el desarrollo. Se debe mencionar que durante la preparaci´on del Trabajo Fin de Grado se defini´o una prueba a realizar en un entorno real pero que, por motivos de tiempo, no ha podido realizarse. La idea inicial era instalar sobre un servidor Meshlium de la empresa Libelium que nos permitiera desplegar el sistema en una situaci´on que simulara mejor la de un entorno de producci´on. Uno de nuestros objetivos era la utilizaci´on de la tecnolog´ıa existente, con el fin de aprovechar la investigaci´on y el desarrollo que ya se ha realizado sobre ´esta y no repetir 51 6.2. L´ INEAS FUTURAS trabajo. Nuestro an´alisis inicial creo que ha dado buenos frutos ya que HTTP y Node.JS cuentan con una excelente base de informaci´on y creo que eso ha sido una de las piezas que m´as me ha facilitado el trabajo. Adem´as, como hemos podido ver en el dise˜no, la plataforma est´a pensada para que pueda ser extensible, dando cabida de manera sencilla a nuevas estructuras de jerarqu´ıas, pudiendo adaptarse a otras situaciones. Existe una gran competencia a d´ıa de hoy para tomar las riendas del Internet de las Cosas, pero la falta de un est´andar claro y la pluralidad de este ecosistema suponen un reto que espero este Trabajo ayude a superar. En definitiva, el Internet de las Cosas es un concepto que es dif´ıcil de llevar adelante, tal y como se ve en el gran desarrollo que se est´a dando en este campo pero en la poca penetraci´on con la que cuenta en nuestras vidas diarias, aunque si la tendencia sigue as´ı, en un futuro no muy lejano puede que veamos una verdadera revoluci´on en este campo. 6.2. L´ıneas futuras De este trabajo se pueden desprender algunas l´ıneas que ser´ıan muy interesante de desarrollar parte debido a la falta de tiempo para realizar un trabajo m´as extenso y tambi´en por que se trata de otros campos que se encuentran relacionados con el Internet de las Cosas. Estas son las l´ıneas m´as destacables y son asuntos con los que me he encontrado durante la realizaci´on del Trabajo. Los tres son caminos interesantes para avanzar y formar´ıa un buen complemento para este proyecto. Big Data. Con el impresionante desarrollo que est´a teniendo la tecnolog´ıa relacionada con el concepto de Big Data, que trata sobre el procesado de inmensas cantidades de datos para obtener informaci´on muy ´util, el Internet de las Cosas puede servir de base para alimentar estos sistemas debido a gran generaci´on de datos que puede crear un despliegue en una ciudad o cualquier otro sistema. Esto es una pieza esencial para el futuro del Internet de las Cosas ya que generar informaci´on ´util a partir de estos datos tambi´en podr´a ser de provecho para mejorar la calidad de los despliegues de sensores o crear redes de actuadores que se adelanten a los acontecimientos aprovechando la componente de predicci´on con la que cuenta el Big Data. Seguridad. La seguridad es un punto clave en el Internet de las Cosas aunque para evitar la sobreextensi´on se decidi´o eliminarla del alcance del proyecto. Desarrollar un buen sistema de seguridad que proteja la informaci´on de cada usuario es un punto muy importante y estos sistemas tan horizontales hacen que la seguridad sea un reto interesante. Hoy en d´ıa muchos usuarios dan una gran importancia a la seguridad de su informaci´on y cualquier cliente desear´a que sus datos est´en bien protegidos ya que en algunos casos podr´ıa contener informaci´on sensible. Escalabilidad. Node.js y Mongo DB son entornos que ofrecen unas posibilidades excelentes de escalabilidad para nuestras aplicaciones y, debido a la gran cantidad de 52