Publicada Release 2.7.0 de SOFIA2

Ya está disponible la release 2.7.0 de SOFIA2, esta release también se ha disponibilizado en la Plataforma de Experimentación SOFIA2 InCloud.

Esta versión añade a la Plataforma las siguientes funcionalidades

· Ontologías Padre: este concepto Padre permite crear herencias entre ontologías, de modo que la ontología padre define la estructura y las ontologías hijo permiten establecer la seguridad con mayor granularidad (por ejemplo que ontología padre Jardín define la estructura y la ontología Jardín Retiro es sólo accesible a usuarios operadores de ese jardín)

· Wizard creación KPs Visualizadores en Tiempo real: que permite desde la consola y de forma visual crear KPs capaces de representar la información entrante en diferentes formatos (mapa Google, gráfico de líneas,…). Además permite descargarse un ZIP con el HTML+JS preparado para integrar en nuestra aplicación

· Creación ontologías desde Excel/CSV: permite crear automáticamente una ontología a partir de un fichero Excel

 

volcando además la información de este en la BDTR y lista para ser consumida:

· Publicación de APIS multilenguaje: estas APIS se disponibilizan para los usuarios que no usan el SOFIA2 SDK, estas descargas ofrecen en diferentes lenguajes todo lo necesario para poder desarrollar aplicaciones sobre SOFIA2, incluido un ejemplo de uso

· Buscador de Información pública: apermite a usuarios anónimos (no registrados en la plataforma) buscar y consultar la estructura de toda la información pública:

InformacionPublica

· Ampliación de Monitorización JMX: que ahora permite también monitorizar la topología de clusterización (instancias del SIB-Runtime, BDTR, BDH, SIB-Tools,…), los KPs conectados y suscritos a la plataforma, últimos mensajes recibidos, errores,…

· Certificación del KP Modelo sobre Gateway CSC de la Coruña El KPModelo es un contenedor que permite correr distintas implementaciones de KP sobre la misma máquina virtual. Utiliza un modelo de workers para ofrecer un marco de funcionalidades básicas comunes a los KPs de SOFIA (herramientas de conexión, envío y recepción de mensajes, suscripciones, monitorización, persistencia local de mensajes, reintento de envío de mensajes fallidos, gestión de versiones configuradas por consola). Las pruebas sobre el dispositivo han revelado un uso eficiente de los recursos.

· Nueva API Javascript con mejoras, callbacks con clousures y namespace propio.

· Resolución de diversos bugs e incorporación de mejoras de rendimiento y estabilidad

 

Ver:

Publicada Release 2.7.0 de SOFIA2

Smart Coruña comienza a instalar sus primeros gateways

 

Ya se ha comenzado la instalación de los primeros dispositivos ‘gateways’ en A Coruña -a modo de test- en varios parques y edificios públicos, lo que permitirá conectar los sensores y otros elementos de captación de información en la ciudad.

Esto constituye el primer gran hito tangible del proyecto de ciudad inteligente Coruña Smart City, impulsado por el Ayuntamiento gallego en colaboración con la UTE integrada por Indra, Altia, R e Ilux Technologies.

Leer más

Enlace

Conociendo las APIs de SOFIA 2 – API RESTFul

SOFIA2 proporciona un conjunto de APIS que permitirán a las aplicaciones cliente o Knowledge Processor (KPs), enviar y consumir información en la plataforma.

En este post vamos a introducir el API RESTFul de SOFIA2, cuya documentación on-line la podemos consultar en la dirección: http://sofia2.com/sib/

El protocolo del API RESTFul de SOFIA2 difiere del resto de APIS debido a las características intrínsecas de la especificación RESTFul y la necesidad de manejar recursos a través de los verbos HTTP. En este sentido, este API no utiliza el protocolo estándar SSAP que introdujimos en el post https://about.sofia2.com/2014/04/14/conociendo-el-protocolo-de-interoperabilidad-de-sofia2-ssap/, sino que maneja un objeto o recurso denominado SSAPResource a través de las operaciones HTTP: POST, PUT, GET y DELETE.

El recurso SSAPResource tiene las siguientes propiedades:

Lo que permite cubrir el juego de operaciones SSAP de la siguiente forma:

Operación SSAP Operación RESTFul
JOIN HTTP POST enviando un SSAPResource informando:

· join: true

· instanceKP: Identificador de KP e indentificador de instancia de KP

· token: Token de autenticación

LEAVE HTTP POST enviando un SSAPResource informando:

· leave: true

· sessionkey: Clave de sesión a caducar

INSERT HTTP POST enviando un SSAPResource infomando:

· ontology: Ontologia sobre la que envia una nueva instancia.

· data: Intancia de ontologia enviada.

· dessionkey: clave de sesión SSAP en la que pertenece el mensaje

HTTP GET enviando un SSAPResource informando a traves de los queryParams de la URL:

· $ontology: Ontologia sobre la que envia una nueva instancia.

· $query: Sentencia SQLLIKE de tipo INSERT.

· $sessionKey: clave de sesión SSAP en la que pertenece el mensaje

· $queryType: SQLLIKE

UPDATE HTTP PUT enviando un SSAPResource infomando:

· ontology: Ontologia sobre la que se realiza la actualización.

· Data: Intancia de ontologia con datos actualizados.

· Sessionkey: clave de sesión SSAP en la que pertenece el mensaje

HTTP GET informando a traves de los queryParams de la URL:

· $ontology: Ontologia sobre la que se realiza la actualización.

· $query: Sentencia SQLLIKE de tipo UPDATE.

· $sessionKey: clave de sesión SSAP en la que pertenece el mensaje

· $queryType: SQLLIKE

DELETE HTTP DELETE enviando un SSAPResource infomando:

· ontology: Ontologia sobre la que se realiza el borrado.

· Data: Intancia de ontologia a borrar.

· Sessionkey: clave de sesión SSAP en la que pertenece el mensaje

HTTP DELETE informando a traves de pathParam: el objectId en BDTR de la instancia de ontologia a borrar. Y a traves de queryParams de la URL:

· $ontology: Ontologia sobre la que se realiza el borrado.

· $sessionKey: clave de sesión SSAP en la que pertenece el mensaje

HTTP GET informando a traves de los queryParams de la URL:

· $ontology: Ontologia sobre la que se realiza el borrado.

· $query: Sentencia SQLLIKE de tipo DELETE.

· $sessionKey: clave de sesión SSAP en la que pertenece el mensaje

· $queryType: SQLLIKE

QUERY HTTP GET informando a traves de los queryParams de la URL:

· $ontology: Ontologia sobre la que se realiza la consulta.

· $query: Sentencia de consulta

· $sessionKey: clave de sesión SSAP en la que pertenece el mensaje

· $queryType: Tipo de lenguaje de consulta

· $queryParams: Parámetros a informar en caso de consulta predefinida en el SIB con argumentos.

HTTP GET informando a traves de pathParam: el objectId en BDTR de la instancia de ontologia a consultar. Y a traves de queryParams de la URL:

· $ontology: Ontologia sobre la que se realiza la consulta.

· $sessionKey: clave de sesión SSAP en la que pertenece el mensaje

GET_CONFIG HTTP GET informando a traves de los queryParams de la URL:

· $kp: Identificador de KP del que se quiere recuperar su configuración

· $instanciaKp: Identificador de la instancia de KP de la que se quiere recuperar su configuración

· $token:Token de autenticación

Las operaciones SSAP relativas a la suscripción (SUBSCRIBE, UNSUBSCRIBE e INDICATION) no están soportadas en este API, ya que REST no permite mantener una conexión bidireccional con el cliente.

En http://sofia2.com el API RESTFul se expone en el path http://sofia2.com/sib/services/api_ssap/v01/SSAPResource

Los métodos HTTP expuestos por el API son:

· POST: Método que permite enviar un recurso SSAPResource en formato JSON, cubriendo las operaciones JOIN, LEAVE e INSERT. El resultado será otro recurso SSAPResource indicando:

o En operaciones JOIN: SessionKey asignada por el SIB:

o En operaciones INSERT: ObjectId asignado en BDTR a la instancia de ontologia insertada:

o En operaciones LEAVE: Respuesta vacía, indicándose si todo ha ido bien a traves del código de error HTTP 200 OK:

La documentación on-line completa del método POST describe los posibles códigos de error, así como incluye ejemplos de invocación:

· PUT: Método que permite enviar un recurso

SSAPResource informando una instancia de ontología existente en la BDTR para su actualización con nuevos valores. El recurso enviado, está en formato JSON y la instancia de ontología se identifica a través del ObjectId en BDTR:

{

"sessionKey":"<session_key>",

"ontology":"SensorTemperatura",

"data":"{"_id":{"$oid": "527a6352c0af4380e54822e1”, <instancia_ont>}"

}

El resultado será una respuesta vacía indicándose si todo ha ido bien a través del código de error HTTP 200 OK:

La documentación on-line completa del método PUT describe los posibles códigos de error, así como incluye ejemplos de invocación:

· GET: Método que permite realizar las operaciones QUERY sobre BDTR y BDH. Y de operaciones GET_CONFIG. PermiteAdemás, mediante lenguaje SQLLIKE y sentencias de tipo INSERT,UPDATE y DELETE realizar operaciones de estos tipos sobre la BDTR.

El resultado será un objeto SSAPResource con los datos correspondientes a la consulta.

o QUERY sobre BDTR y BDH: Tiene dos variantes:

§ Mediante el ObjectID como pathParam permite recuperar de la BDTR la instancia de ontologia con dicho ObjectID. Este método necesita además recibir como queryParams:

· $sessionKey de la sessión SSAP

· $ontologia sobre la que se realiza la operación.

La documentación on-line completa del método GET recibiendo el ObjectId por PathParam describe los posibles códigos de error, así como incluye ejemplos de invocación:

§ Mediante sentencia a ejecutar sobre la base de datos correspondiente. Este método recibe los siguientes parámetros como queryParams:

· $ontology: Ontologia sobre la que se realiza la consulta.

· $query: Sentencia de consulta

· $sessionKey: clave de sesión SSAP en la que pertenece el mensaje

· $queryType: Tipo de lenguaje de consulta. Puede tomar valores

o NATIVE: Sentencia a ejecutar sobre la BDTR utilizando lenguaje nativo en la sentencia indicada en el argumento $query

o SQLIKE: Sentencia a ejecutar sobre la BDTR utilizando lenguaje SQLLIKE en la sentencia indicada en el argumento $query

o SIB_DEFINED: Sentencia a ejecutar sobre la BDTR utilizando una sentencia predefinida en el SIB. En este caso el argumento $query será el identificador de la sentencia.

o BDH: Sentencia a ejecutar sobre la BDH utilizando una sentencia en lenguaje SQL de la BDH en el argumento $query.

· $queryParams: Parámetros a informar en caso de consulta predefinida en el SIB con argumentos.

La documentación on-line completa del método GET describe los posibles códigos de error, así como incluye ejemplos de invocación:

o GET_CONFIG: El path de esta operación es http://sofia2.com/sib/services/api_ssap/v01/SSAPResource/configPermite recuperar la configuración de un KP, informando a través de los queryParams de la URL:

§ $kp: Identificador de KP del que se quiere recuperar su configuración

§ $instanciaKp: Identificador de la instancia de KP de la que se quiere recuperar su configuración

§ $token: Token de autenticación

La documentación on-line completa del método GET para configuración describe los posibles códigos de error, así como incluye ejemplos de invocación:

· DELETE: Método que permite realizar las operaciones de borrado sobre la BDTR.

La respuesta será vacia, indicándose si la operación ha sido correcta a traves del código de error HTTP 200 OK.

Tiene dos variantes:

o Mediante el ObjectID como pathParam: Permite borrar en la BDTR la instancia de ontología con dicho ObjectID. Este método necesita además recibir como queryParams:

§ $sessionKey de la sesion SSAP

§ $ontologia sobre la que se realiza la operación.

La documentación on-line completa del método DELETE recibiendo el ObjectId por Pathparam describe los posibles códigos de error, así como incluye ejemplos de invocación:

o Enviando un recurso SSAPResource informando la instancia de ontología existente en la BDTR para su borrado. El recurso enviado, está en formato JSON y la instancia de ontología se identifica a través del ObjectId en BDTR:

{

"sessionKey":"<session_key>",

"ontology":"SensorTemperatura",

"data":"{"_id":{"$oid": "527a6352c0af4380e54822e1”}"

}

La documentación on-line completa del método DELETE describe los posibles códigos de error, así como incluye ejemplos de invocación:

Conociendo las APIs de SOFIA 2 – API RESTFul

VI Encuentro de Ciudades Abiertas en Rivas

El próximo 9 de mayo Rivas celebrará el VI Encuentro de Ciudades Abiertas, este evento se celebrará en Rivas por sexta vez y es uno de los principales puntos de encuentro de las ciudades inteligentes.

Durante el encuentro, se realizarán ponencias y se expondrán casos prácticos de proyectos en curso.

Participarán representantes de diversas ciudades españolas y se analizarán los casos de Ámsterdam y Évora, dos de las ciudades que son referencia internacional en el terreno de las Smart Cities.

Estad atentos! en breve podremos informar de interesantes novedades… 🙂

VI Encuentro de Ciudades Abiertas en Rivas

startup4cities 2014

startup4cities es una iniciativa de la Fundetec y la Red Española de Ciudades Inteligentes (RECI) para impulsar el desarrollo de proyectos orientados a mejorar la eficiencia y la calidad de vida de las ciudades.

Hasta el 12 de mayo se pueden presentar los proyectos, esta convocatoria está pensada para emprendedores y startups que tengan una idea o proyecto inicial enfocado a las ciudades del futuro.

De entre estos proyectos se elegirán 12 que luego se presentarán y defenderán ante representantes de las ciudades que forman la REC el próximo 10 de junio en Madrid en el Palacio Cibeles.

En esta iniciativa colaboran:

Desde aquí os animamos a participar en esta pionera iniciativa y ponemos a vuestra disposición SOFIA2 InCloud como plataforma base para implementar vuestro proyecto!

startup4cities 2014

Consultas SQL, nativas y geoespaciales en SOFIA2

SOFIA2 soporta mensajes de Query bien en el lenguaje nativo de la BDTR o bien en lenguaje SQL para la BDTR o la BDH, para eso SOFIA2 incorpora parsers SQL para MongoDB (BDTR) y Hadoop (BDH).

(Más detalle sobre el protocolo de mensajería SSAP aquí)

Request SSAP QUERY Response SSAP QUERY
{“body”: {“query”: “select * from feedAutobus where Feed.assetId=’316′

limit 1,

“queryType”: “SQLLIKE”

},

“direction”: “REQUEST”,

“ontology”: “feedAutobus”,

“messageType”: “QUERY”,

“messageId”: null,

“sessionKey”: “xxx”

}

{“body”: {“data”: [

{“_id”:{“$oid”:“533bff5f50ae67a5ab0c433c”},

,

“Feed”:
{

“assetId”:“316”,

“assetName”:” Autobús nº 316 “,

“assetSource”:“guiaLocal”,

“assetType”:“Autobus”,

“attribs”:

[

{

“name”:“linea”,

“value”:“1”

},

{

“name”:“nombreLinea”,

“value”:“Abente y Lago – Os Castros”

},

{

“name”:“estado”,

“value”:“Tipo de Autobús: Normal piso bajo .

Última parada por la que ha pasado Plaza de Mina, 26 Hora de paso 14:15

Proxima parada: Plaza de Orense\n”

}

],

“feedId”: “1:316:2014-04-02T12:15:28.706266”,

“feedSource”: “guiaLocal”,

“geometry”: {

“coordinates”: [

-8.403705353600992,

43.36721562022267

],

“type”: “Point”

},

“measures”: [ ],

“measuresTimestamp”: {

“$date”: “2014-04-02T12:15:28.706Z”

},

“measuresType”: “INSTANT”,

“timestamp”: {

“$date”: “2014-04-02T12:15:28.706Z”

},

“type”: “MOBILE”

}

}

],

“error”: null,

“errorCode”: null,

“ok”: true

},

“direction”: “RESPONSE”,

“messageId”: null,

“messageType”: “QUERY”,

“ontology”: “feedAutobus”,

“sessionKey”: “xxx”

}

Que también podría hacerse en lenguaje nativo:

{

“body”: {

“query”: “db.feedAutobus.find({‘Feed.assetId’:’316′}).limit(1),

“queryType”: “NATIVE”

},

“direction”: “REQUEST”,

“ontology”: “feedAutobus”,

“messageType”: “QUERY”,

“messageId”: null,

“sessionKey”: “b2c28802-dcd1-448c-8e63-e1039deb82c3”

}

SOFIA2 también soporta consultas geoespaciales, que pueden hacerse con el lenguaje de consultas geospaciales de MongoDB, por ejemplo para la consulta:

db.feedAutobus.find({‘Feed.geometry’ : {$near : {$geometry : {type : ‘Point’, coordinates : [-8.4, 43.37]}}, $maxDistance: 200}} ).limit(1);

Request SSAP QUERY Response SSAP QUERY
{
 "body": {
 "query": "db.feedAutobus.find(
{'Feed.geometry' : {
$near : {$geometry : {
type : 'Point', coordinates : 
[-8.4, 43.37]}}, 
$maxDistance: 200}} ).
limit(1);",
"queryType": "NATIVE"
},
"direction": "REQUEST",
"ontology": "feedAutobus",
"messageType": "QUERY",
"messageId": null,
"sessionKey": 
"xxx"
}
{“body”: {“data”: [

{

“_id”:{“$oid”:“534d7b85d9475fabab962a62”},

,

“Feed”:
{

“assetId”:“374”,

“assetName”:” Autobús nº 374 “,

“assetSource”:“guiaLocal”,

“assetType”:“Autobus”,

“attribs”:
[

{

“name”:“linea”,

“value”:“2A”

},

{

“name”:“nombreLinea”,

“value”:“Puerta Real – Os Castros – Oza”

},

{

“name”:“estado”,

“value”:“Tipo de Autobús: Normal piso bajo minusválido .

Última parada por la que ha pasado Autoridad Portuaria Hora de paso 20:33

Proxima parada: Puerta Real\n”

}

],

“feedId”: “2A:374:2014-04-15T18:33:54.711930”,

“feedSource”: “guiaLocal”,

“geometry”: {

“coordinates”: [

-8.400029224292654,

43.370000426416276

],

“type”: “Point”

},

“measures”: [ ],

“measuresTimestamp”: {“$date”: “2014-04-15T18:33:54.711Z”},

“measuresType”: “INSTANT”,

“timestamp”: {“$date”: “2014-04-15T18:33:54.711Z”

},

“type”: “MOBILE”

}

}

],

“error”: null,

“errorCode”: null,

“ok”: true

},

“direction”: “RESPONSE”,

“messageId”: null,

“messageType”: “QUERY”,

“ontology”: “feedAutobus”,

“sessionKey”: “xxx”

}

Consultas SQL, nativas y geoespaciales en SOFIA2

Cursos online gratuitos de MongoDB

A través de Elisabeth (gracias!!!) he descubierto estos cursos online en idigital.cat sobre diferentes aspectos de MongoDB impartidos por la

Que incluyen incluso exámenes certificados.

14/04/2014 – 03/06/2014

M101P: MongoDB for Developers

29/04/2014 – 18/06/2014

M202: MongoDB Advanced Deployment and Operations

05/05/2014 – 24/06/2014

M102: MongoDB for DBAs

06/05/2014 – 13/05/2014

C100DEV: MongoDB Certified Developer Associate Exam

06/05/2014 – 13/05/2014

C100DBA: MongoDB Certified DBA Associate Exam

26/05/2014 – 15/07/2014

M101J: MongoDB for Java Developers

02/06/2014 – 22/06/2014

M101JS: MongoDB for Node.js Developers

Cursos online gratuitos de MongoDB