Cami Can Calders, 8 2º-2ª | 08173 Sant Cugat del Valles info@bmotes.com 932504996

WhatsBee blog

Data brokerage: un paso más hacia el interfaz del cliente

Vamos avanzando en el recorrido desde el sensado del entorno hacia la interacción con el usuario final. Hace unos pocos días probaba la forma de comunicar una aplicación de VB.Net con el Gateway. Este tipo de comunicación directa solo tiene sentido si vamos a consumir los datos desde la misma red que tenemos el gateway, también podríamos tenerlo en remoto y hacer una VPN para acceder, pero es una solución muy poco escalable.

Podemos añadir una capa intermedia ubicada en un equipo público de Internet que pueda ir recogiendo los datos de los sensores, de varias ubicaciones diferentes y con varias tecnologías diferentes. La función de esta capa de software es recoger los datos, almacenarlos y servirlos cuando alguien los demande. La función de esta capa es hacer de broker con los datos.

Hay algunas aplicaciones que cumplen con esta función, en este blog hemos hablado por lo menos de dos de ellas, pachube e iDigi. La primera está orientada a recoger datos de cualquier plataforma, la segunda exclusivamente de la plataforma de Digi, aún así quiero hacer un experimiento de como hacer nuestro propio broker de datos por varios motivos: no depender de un tercero, poder escalarlo en base a nuestras necesidades, etc.

Broker de datos

La forma de comunicar con nuestro broker de datos será basada en servicios web, la tecnología a utilizar un servidor IIS con ASP.NET. La estructura de la base de datos a utilizar estará basada en tres tablas principales, utilizando la misma terminología que Pachube:

-Environement –> Contiene los datos del lugar en el que está ubicado el sensor, nombre, dirección, latitud, longitud, altura, etc.

-DataStreams –> Son colecciones de datos, se corresponden con un canal del sensor, en el caso de un sensor con tres variables se tendrían que crear tres datastreams del mismo Environement.

-DataPoint –> Contiene las lecturas de un DataStream.

Además de estas tres tablas, claramente relacionadas entre ellas, tendremos que crear algunas tablas accesorias, de usuarios, de unidades, etc.

Tenemos que crear un número de servicios web que permita leer, escribir borrar o actualizar cada tabla.

La idea de esta capa del SW es disponer de un modelo estandar para el almacenamiento y la recuperación de los datos, permitiendo el desarrollo rápido de aplicaciones sobre ellos. las API son públicas, lo que permitirá a cualquier persona desarrollar soluciones.

Todo eso en una entrega posterior…

Dejar un comentario