Conociendo el protocolo de Interoperabilidad de SOFIA2 – SSAP

En este post (https://sofia2about.wordpress.com/2014/03/04/conceptos-clave-de-sofia2-i/) se introdujo el concepto clave del protocolo de mensajería SSAP.

El protocolo SSAP (Smart Space Access Protocol) es el protocolo de mensajería estándar utilizado en Sofia2 para permitir que una aplicación cliente o KP, se pueda comunicar con el IoT Broker (SIB) de la plataforma para enviar o consumir información.

Utilizando el protocolo SSAP, un KP, puede colaborar con cualquier otro conectado a la plataforma mediante el intercambio de información.

El protocolo SSAP es independiente del lenguaje de programación y del protocolo de comunicación, permite que los KPs se comuniquen entre sí, independientemente del lenguaje en que estén programados (Java, C, Android…) y que Gateway utilicen para conectarse al SIB (REST, Ajax-Push, MQTT…)

El protocolo SSAP está basado en JSON, lo que lo convierte en un protocolo ligero y apropiado para dispositivos de bajos recursos, navegadores, móviles…

Se trata de un protocolo síncrono (cada solicitud tiene una respuesta) y donde todos los mensajes parten desde el cliente o KP al SIB, excepto para las notificaciones de suscripción que parten desde el SIB y no tienen respuesta.

Todos los mensajes SSAP tiene una estructura común, como se describe a continuación:

SSAP MESSAGE
{

“body”: “<cuerpo del mensaje>”,

“direction”:”{REQUEST|RESPONSE}“,

“messageId”:null,

“messageType”:”{JOIN|LEAVE|INSERT|

UPDATE|DELETE|QUERY|

SUBSCRIBE|UNSUBSCRIBE|CONFIG}”,

“ontology”:”<Ontologia>”,

“sessionKey”:null

}

body: Cuerpo del mensaje. Dependerá del tipo de mensaje de que se trate.

-direction: indica si se trata de un mensaje de solicitud (REQUEST) o de respuesta (RESPONSE).

-messageId: En comunicaciones asíncronas (En la versión actual solo se contempla en el mensaje de notificación de suscripción INDICATION, donde recoge el identificador de la suscripción asociada), indica el identificador de mensaje previo al que se asocia este mensaje.

-ontology: Ontologia a la que se dirige el mensaje.

-sessionKey: Identificador de la sesión SSAP a la que pertenece el mensaje.

SSAP contempla las siguientes operaciones para permitir interoperabilidad entre aplicaciones: JOIN, LEAVE, INSERT, UPDATE, DELETE, QUERY Y SUBSCRIBE.

JOIN

Este mensaje se usa para establecer una sesión lógica. Permite a un KP enviar sus credenciales de autenticación al SIB, para recibir o renovar una clave de sesión con la que enviar y recibir información de la plataforma.

Campo body en el mensaje SSAP JOIN:

El atributo “body” para el mensaje JOIN de tipo REQUEST es dependiente del plugin de seguridad utilizado en el SIB, ya que las credenciales cambian dependiendo del plugin que utilice el SIB. En la versión actual en la nube sofia2.com se está utilizado el plugin de referencia basado en tokens de autenticación. De ahí que las credenciales indicadas sean los atributos:

  • instance: El par nombreKP e instanciaKP separados por el carácter “:”
  • token: El token de autenticación generado en la plataforma para el KP.

El atributo “body” para el mensaje JOIN de tipo RESPONSE devolverá 3 campos:

  • data: Con la sessionKey asignada si todo ha ido correctamente.
  • ok: Indicando con un valor booleano si la operación ha sido correcta o no.
  • error: Indicando un mensaje descriptivo en caso de operación incorrecta.

Este mensaje tiene dos usos:

  • Solicitar un inicio de sesión: Se trata del primer mensaje de una sesión SSAP. Mediante el mensaje JOIN, un KP se autentica ante el SIB recibiendo una nueva sessionKey generada en el SIB que le servirá de identificador para el resto de mensajes.

 

JOIN REQUEST JOIN RESPONSE
{

“body”: “{

“instance”:”kpName:kpInstance”

“token”:”abcd0123def04569adecb”,

}”,

“direction”:”REQUEST“,

“messageId”:null,

“messageType”:”JOIN“,

“ontology”:null,

“sessionKey”:null

}

{

“body”:”{

“data”:”5b9349ab-d9a8-4fd0-b155-a11c5d8df6fa”,

“error”:null,

“ok”:true

}”,

“direction”:”RESPONSE“,

“messageId”:null,

“messageType”:”JOIN“,

“ontology”:null,

“sessionKey”:”5b9349ab-d9a8-4fd0-b155-a11c5d8df6fa”

}

  • Renovar una sesión existente: La sessionKey recibida al establecer una sesión lógica con la plataforma tiene un periodo de caducidad de 24 horas. Este periodo se renueva cada vez que el KP actúa con el SIB (Pej: enviando un mensaje de tipo QUERY o INSERT). Pero si no hay comunicación con el SIB durante ese tiempo, el SIB procederá a invalidar la sesión, dándola por caducada.

Para evitar esto, se puede enviar un mensaje JOIN para renovar la sessionKey otras 24 horas. Se trata del mismo mensaje JOIN utilizado para el establecimiento de sesión, incluyendo en este caso la sessionKey a renovar.

 

JOIN REQUEST JOIN RESPONSE
{

“body”: “{

“instance”:”kpName:kpInstance”

“token”:”abcd0123def04569adecb”,

}”,

“direction”:”REQUEST“,

“messageId”:null,

“messageType”:”JOIN“,

“ontology”:null,

“sessionKey”:”5b9349ab-d9a8-4fd0-b155-a11c5d8df6fa”

}

{

“body”:”{

“data”:”5b9349ab-d9a8-4fd0-b155-a11c5d8df6fa”,

“error”:null,

“ok”:true

}”,

“direction”:”RESPONSE“,

“messageId”:null,

“messageType”:”JOIN“,

“ontology”:null,

“sessionKey”:”5b9349ab-d9a8-4fd0-b155-a11c5d8df6fa”

}

LEAVE

El mensaje LEAVE se usa para hacer el cierre de la sesión lógica. Invalida la clave de sesión indicada en el mensaje, de manera que a partir de ese momento, no se podrá utilizar para ninguna otra operación.

Campo body en el mensaje SSAP LEAVE:

El mensaje LEAVE de tipo REQUEST no tiene atributo “body”, ya que toma la sessionkey a invalidar del propio mensaje SSAP.

El atributo “body” para un mensaje LEAVE de tipo RESPONSE devolverá 3 campos:

  • data: Con la sessionKey invalidada
  • ok: Indicando con un valor booleano si la operación ha sido correcta o no.
  • error: Indicando un mensaje descriptivo en caso de operación incorrecta.

 

LEAVE REQUEST LEAVE RESPONSE
{

“body”:null,

“direction”:”REQUEST“,

“messageId”:null,

“messageType”:”LEAVE“,

“ontology”:null,

“sessionKey”:”5b9349ab-d9a8-4fd0-b155-a11c5d8df6fa”

}

{

“body”:”{

“data”:”5b9349ab-d9a8-4fd0-b155-a11c5d8df6fa “,

“error”:null,

“ok”:true

}”,

“direction”:”RESPONSE“,

“messageId”:null,

“messageType”:”LEAVE“,

“ontology”:null,

“sessionKey”:”5b9349ab-d9a8-4fd0-b155-a11c5d8df6fa”

}

INSERT

El mensaje INSERT se usa para hacer un envío de información a la plataforma. Se trata de información semántica clasificada por su correspondiente ontología. En concreto la información es una instancia de ontología, o una sentencia de inserción.

La respuesta será el identificador de objeto asignado en la BDTR a la instancia de ontología, que será de utilidad para actualizaciones posteriores.

Campo body en el mensaje SSAP INSERT:

El atributo “body” para un mensaje INSERT de tipo REQUEST, tendrá 3 campos:

  • data: Con la instancia de la ontología a insertar. Puede tomar valor nulo en función del valor del atributo queryType.
  • query: Con la sentencia de tipo INSERT a insertar. Puede o tomar valor nulo o ser una sentencia en lenguaje nativo de la BDTR o en lenguaje SQL-LIKE, en función del valor del atributo queryType.
  • queryType: Indicando el tipo de sentencia INSERT de que se trata. Puede tomar los siguientes valores:

1. null: No existe sentencia de inserción. En el atributo data se envía un objeto JSON con la instancia de la ontología correspondiente. El campo query será nulo o se ignorará. Esta instancia de ontología se insertará en la BDTR.

2. NATIVE: Se inserta una ontología en la BDTR utilizando una sentencia de tipo INSERT en lenguaje nativo. La sentencia se indicará en el campo query. El campo data será nulo o se ignorará.

3. SQLLIKE: Se inserta una ontología en la BDTR utilizando una sentencia de tipo INSERT en lenguaje SQL. La sentencia se indicará en el campo query. El campo data será nulo o se ignorará.

El atributo “body” para un mensaje INSERT de tipo RESPONSE devolverá 4 campos:

  • data: Con el identificador de objeto asignado en la BDTR a la instancia de ontología
  • ok: Indicando con un valor booleano si la operación ha sido correcta o no.
  • error: Indicando un mensaje descriptivo en caso de operación incorrecta.
  • errorCode:En caso de operación incorrecta, indicara un código de error(AUTENTICATION, AUTHORIZATION, PROCESSOR, PERSISTENCE, PARSE_SQL, ONTOLOGY_NOT_FOUND, SIB_DEFINED_QUERY_NOT_FOUND, OTHER).

 

INSERT REQUEST INSERT RESPONSE
{

“body”:”{

“data”:”{<instanciaOntologia>}”,

“query”:null,

“queryType”:null

}”,

“direction”:”REQUEST“,

“messageId”:null,

“messageType”:”INSERT“,

“ontology”:”SensorTemperatura”,

“sessionKey”:”5b9349ab-d9a8-4fd0-b155-a11c5d8df6fa”

}

{

“body”:”{

“data”:”{\”_id\”:ObjectId(\”5349c024ae7b7d751eb79562\”)}”,

“error”:null,

“errorCode”:null,

“ok”:true

}”,

“direction”:”RESPONSE“,

“messageId”:null,

“messageType”:”INSERT“,

“ontology”:”SensorTemperatura”,

“sessionKey”:”5b9349ab-d9a8-4fd0-b155-a11c5d8df6fa”}

UPDATE

Realiza una actualización de información existente en la plataforma. Permite actualizar una o varias instancias de ontología en la plataforma. Incluye el valor del atributo o atributos a actualizar y la condición a cumplir por las instancias de ontología, o una sentencia de actualización.

Campo body en el mensaje SSAP UPDATE:

El atributo “body” para un mensaje UPDATE de tipo REQUEST, tendrá 3 campos:

  • data: Contiene la clausula SET en lenguaje nativo de la BDTR. Puede tomar valor nulo en función del valor del atributo queryType.
  • query: En función del valor del atributo queryType, puede contener o bien la clausula WHERE en lenguaje nativo de la BDTR con los campos a cumplir por las instancias a actualizar, o bien, la sentencia de tipo UPDATE a ejecutar.
  • queryType: Indicando el tipo de sentencia UPDATE de que se trata. Puede tomar los siguientes valores:

1. null: No existe sentencia de actualización, Se envía en el atributo data una clausula nativa de la BDTR de tipo $set con el nuevo valor de los campos, y en el atributo query, un objeto con las condiciones a cumplir por las instancias de ontología a actualizar.

2. NATIVE: Se actualizan una o varias ontologías en la BDTR utilizando una sentencia de tipo UPDATE en lenguaje nativo de la BDTR. La sentencia se indicará en el campo query. El campo data será nulo o se ignorará.

3. SQLLIKE: Se actualizan una o varias ontología en la BDTR utilizando una sentencia de tipo UPDATE en lenguaje SQL. La sentencia se indicará en el campo query. El campo data será nulo o se ignorará.

El atributo “body” para un mensaje UPDATE de tipo RESPONSE devolverá 4 campos:

  • ata: Con la lista de los identificadores de objetos de las instancias de ontología actualizados en la BDTR.
  • k: Indicando con un valor booleano si la operación ha sido correcta o no.
  • error: Indicando un mensaje descriptivo en caso de operación incorrecta.
  • errorCode:En caso de operación incorrecta, indicara un código de error(AUTENTICATION, AUTHORIZATION, PROCESSOR, PERSISTENCE, PARSE_SQL, ONTOLOGY_NOT_FOUND, SIB_DEFINED_QUERY_NOT_FOUND, OTHER).

 

UPDATE REQUEST INSERT RESPONSE
{

“body”:”{

“data”:”{$set:{<lista atributos a actualizar>}}”,

“query”:”{\”_id\”:{\”$oid\”:\”530f90d3fa3f6f704b7affe2\”}}”,

“queryType”:”NATIVE”

}”,

“direction”:”REQUEST“,

“messageId”:null,

“messageType”:”UPDATE“,

“ontology”:”SensorTemperatura”,

“sessionKey”:”5b9349ab-d9a8-4fd0-b155-a11c5d8df6fa”

}

{

“body”:”{

“data”:”{\”_ids\”:[{\”_id\”:ObjectId(\”530f90d3fa3f6f704b7affe2\”)}]}”,

“error”:null,

“errorCode”:null,

“ok”:true

}”,

“direction”:”RESPONSE“,

“messageId”:null,

“messageType”:”UPDATE“,

“ontology”:”SensorTemperatura”,

“sessionKey”:”5b9349ab-d9a8-4fd0-b155-a11c5d8df6fa”

}

DELETE

Realiza un borrado de información existente en la plataforma. Permite borrar una o varias instancias de ontología en la plataforma.

Campo body en el mensaje SSAP DELETE:

El atributo “body” para un mensaje DELETE de tipo REQUEST, tendrá 3 campos:

  • data: será siempre nulo
  • query: En función del valor del atributo queryType, puede contener o bien la clausula WHERE en lenguaje nativo de la BDTR con los campos a cumplir por las instancias a eliminar, o bien, la sentencia de tipo DELETE a ejecutar.
  • queryType: Indicando el tipo de sentencia DELETE de que se trata. Puede tomar los siguientes valores:

1. null: No existe sentencia de actualización, Se envía en el atributo query, un ojeto con las condiciones a cumplir por las instancias de ontología a eliminar de la BDTR.

2. NATIVE: Se eliminan una o varias ontología de la BDTR, utilizando una sentencia de tipo DELETE en lenguaje nativo de la BDTR. La sentencia se indicará en el campo query.

3. SQLLIKE: Se eliminan una o varias ontologías de la BDTR, utilizando una sentencia de tipo DELETE en lenguaje SQL. La sentencia se indicará en el campo query.

El atributo “body” para un mensaje DELTE de tipo RESPONSE devolverá 4 campos:

  • data: Con la lista de los identificadores de objetos de las instancias de ontología eliminados en la BDTR.
  • ok: Indicando con un valor booleano si la operación ha sido correcta o no.
  • error: Indicando un mensaje descriptivo en caso de operación incorrecta.
  • errorCode:En caso de operación incorrecta, indicara un código de error(AUTENTICATION, AUTHORIZATION, PROCESSOR, PERSISTENCE, PARSE_SQL, ONTOLOGY_NOT_FOUND, SIB_DEFINED_QUERY_NOT_FOUND, OTHER).

 

DELETE REQUEST DELETE RESPONSE
{

“body”:”{

“data”:null,

“query”:”{db.SensorTemperatura.remove({\”_id\”:{\”$oid\”:\”52fa15e1174388ee268f254f\”}})}”,

“queryType”:”NATIVE”

}”,

“direction”:”REQUEST“,

“messageId”:null,

“messageType”:”DELETE“,

“ontology”:” SensorTemperatura “,

“sessionKey”:”5b9349ab-d9a8-4fd0-b155-a11c5d8df6fa”

}

{

“body”:”{

“data”:”{\”_ids\”:[{\”_id\”:ObjectId(\”52fa15e1174388ee268f254f\”)}]}”,

“error”:null,

“errorCode”:null,

“ok”:true

}”,

“direction”:”RESPONSE“,

“messageId”:null,

“messageType”:”DELETE“,

“ontology”:”SensorTemperatura”,

“sessionKey”:”5b9349ab-d9a8-4fd0-b155-a11c5d8df6fa”

}

QUERY

El mensaje QUERY sirve para consultar información existente en la plataforma. Permite enviar a la plataforma una sentencia a ejecutar en la BDTR o BDH para recibir información insertada por cualquier KP. (Siempre y cuando se dispongan de los permisos adecuados).

El mensaje de tipo QUERY permite realizar las siguientes operaciones:

  • Utilizando lenguaje nativo de la BDTR:
  • Consultas sobre la BDTR.
  • Utilizando lenguaje SQLLIKE:
  • Consultas sobre la BDTR y BDH (SELECT)
  • Actualizaciones sobre la BDTR (UPDATE)
  • Inserciones sobre la BDTR y BDH (INSERT)
  • Borrado sobre la BDTR (DELETE)
  • Ejecución de consultas predefinidas en el SIB

Campo body en el mensaje SSAP QUERY:

El atributo “body” para un mensaje QUERY de tipo REQUEST, tendrá 3 campos:

  • query: En función del valor del atributo queryType, puede contener o bien la clausula WHERE en lenguaje nativo de la BDTR con los criterios de selección, o bien, la sentencia a ejecutar sobre la BDTR o BDH.
  • queryType: Indicando el tipo de sentencia QUERY de que se trata. Puede tomar los siguientes valores:

1. null: No existe sentencia de selección. Se trata de una operación sobre la BDTR. En el atributo query se envía un objeto con los criterios de selección a cumplir por las instancias de ontología a seleccionar.

2. NATIVE: Se trata de una operación de selección sobre la BDTR, utilizando una sentencia de tipo find en lenguaje nativo de la BDTR. La sentencia se indicará en el campo query.

3. SQLLIKE: Se trata de una operación sobre la BDTR. La operación a realizar será la indicada utilizando el lenguaje SQLLike en la sentencia del campo query. La sentencia podrá ser de tipo SELECT, INSERT, UPDATE y DELETE.

4. BDH: Se trata de una operación sobre la BDH. La operación a realizar será la indicada utilizando el lenguaje SQL nativo de la BDH en la sentencia del campo query. La sentencia podrá ser de tipo SELECT, INSERT.

5. SIB_DEFINED: Se trata de una operación sobre la BDTR. La operación a realizar será la sentencia definida en el SIB e identificada por el identificador del campo query. Si la sentencia tiene parámetros, estos serán informados en el atributo queryParams.

  • queryParams: Campo opcional, solo tendrá sentido con queryType a SIB_DEFINED. Informará los parámetros a pasar a una sentencia de tipo SIB_DEFINED que admita parámetros.El formato será un mapa en JSON informando para cada parámetro de la sentencia el valor correspondiente: {“PARAM1“:”ST-TA3231-1″,”PARAM2“:25}

El atributo “body” para un mensaje QUERY de tipo RESPONSE devolverá 4 campos:

  • data: Con el resultado de la sentencia (incluyendo el identificador de objeto de la instancia) si se trata de una operación SELECT, o el numero de registros afectados en la base de datos correspondiente si se trata de cualquier otro tipo de operación.
  • ok: Indicando con un valor booleano si la operación ha sido correcta o no.
  • error: Indicando un mensaje descriptivo en caso de operación incorrecta.
  • errorCode: En caso de operación incorrecta, indicara un código de error(AUTENTICATION, AUTHORIZATION, PROCESSOR, PERSISTENCE, PARSE_SQL, ONTOLOGY_NOT_FOUND, SIB_DEFINED_QUERY_NOT_FOUND, OTHER).

QUERY REQUEST QUERY RESPONSE
{

“body”:”{

“query”:”select * from SensorTemperatura where identificador = ‘**-TA3231-1’},”

“queryType”:”SQLLIKE”

}”,

“direction”:”REQUEST“,

“ontology”:”SensorTemperatura”,

“messageType”:”QUERY“,

“messageId”:null,

“sessionKey”:”5b9349ab5b9349ab-d9a8-4fd0-b155-a11c5d8df6fa”

}

{

“body”:”{

“data”:””[

{ “_id” : {“$oid” : “510f86598dfe0dd9595f2e15”} , “SensorTemperatura” : {

“coordenadaGps” : {

“altitud” : 0.0 ,

“latitud” : 40.51083 ,

“longitud” : -3.669006} ,

“identificador” : “ TA3231-1′“,

“medida” : 23 ,

“timestamp” : 1359971931226 ,

“unidad” : “C”}}

]”,

“error”:null,

“ok”:true

}”,

“direction”:”RESPONSE“,

“messageId”:null,

“messageType”:”QUERY“,

“ontology”:”SensorTemperatura”,

“sessionKey”:”5b9349ab-d9a8-4fd0-b155-a11c5d8df6fa”

}

SUBSCRIBE

Se usa para hacer una suscripción a información en la plataforma o a una regla CEP. Permite a un KP enviar una query de suscripción, de manera que cuando algún otro KP envíe información que cumpla las condiciones de la query de suscripción, o desencadene la ejecución de una regla CEP, el SIB notificará al KP suscrito las nuevas instancias de ontología que cumplen las condiciones de la query o los resultados de la regla CEP

Campo body en el mensaje SSAP SUBSCRIBE:

El atributo “body” para un mensaje SUBSCRIBE de tipo REQUEST, tendrá 3 campos:

  • query: En función del valor del atributo queryType, puede contener o bien la clausula WHERE en lenguaje nativo de la BDTR con los criterios de selección, o bien, la sentencia select sobre la BDTR que representa la suscripción, o bien no indicar ningún valor (cadena vacia) en cuyo caso representa una suscripción al último valor de la ontología.
  • msRefresh: Periodo de refresco en milisegundos. Indica al SIB cada cuanto tiempo notificar al KP los resultados de la suscripciones en caso de que se cumplan. Evita que el SIB sature al KP en caso de que los criterios de suscripción se cumplan con mucha frecuencia. Por ejemplo, si un KP se suscribe con un valor 10000, aunque se produzcan resultados cada segundo, será notificado a los 10 segundos.
  • queryType: Indicando el tipo de sentencia QUERY de que se trata. Puede tomar los siguientes valores:

1. null: No existe sentencia de selección. En el atributo query se envia un objeto con las condiciones a cumplir por las instancias de ontología a seleccionar.

2. NATIVE: Se trata de una operación utilizando una sentencia de tipo find en lenguaje nativo de la BDTR. La sentencia se indicará en el campo query.

3. SQLLIKE: Se trata de una operación sobre la BDTR. La operación a realizar será la indicada utilizando el lenguaje SQLLike en la sentencia del campo query. La sentencia deberá ser de tipo SELECT.

4. SIB_DEFINED: La operación a realizar será la sentencia definida en el SIB e identificada por el identificador del campo query. Si la sentencia tiene parámetros, estos serán informados en el atributo queryParams.

5. CEP: Se realiza una suscripción a una regla CEP en la plataforma. En este caso, el campo query indicará el identificador de la regla CEP a la que se suscribe

  • queryParams: Campo opcional, solo tendrá sentido con queryType a SIB_DEFINED. Informará los parámetros a pasar a una sentencia de tipo SIB_DEFINED que admita parámetros.El formato será un mapa en JSON informando para cada parámetro de la sentencia el valor correspondiente: {“PARAM1“:”ST-TA3231-1″,”PARAM2“:25}

El atributo “body” para un mensaje QUERY de tipo RESPONSE devolverá 4 campos:

  • data: Indicando el identificador dado a la suscripción. Deberá ser almacenado por el KP ya que tiene dos usos:
    • Conocer a que suscripción pertenece una notificación futura (mensaje de tipo INDICATION), ya que la notificación llevará asociado este identificador de suscripción.
    • Realizar la desuscripción para dejar de recibir notificaciones.
  • ok: Indicando con un valor booleano si la operación ha sido correcta o no.
  • error: Indicando un mensaje descriptivo en caso de operación incorrecta.
  • errorCode:En caso de operación incorrecta, indicara un código de error(AUTENTICATION, AUTHORIZATION, PROCESSOR, PERSISTENCE, PARSE_SQL, ONTOLOGY_NOT_FOUND, SIB_DEFINED_QUERY_NOT_FOUND, OTHER).

 

SUBSCRIBE REQUEST SUBSCRIBE RESPONSE
{

“body”:”{

“query”:”{SensorHumedad.medida:{$gt:3}}”,

“msRefresh”:”3000″,

“queryType”:null

}”,

“direction”:”REQUEST“,

“messageId”:null,

“messageType”:”SUBSCRIBE“,

“ontology”:”SensorHumedad”,

“sessionKey”:”5b9349ab5b9349ab-d9a8-4fd0-b155-a11c5d8df6fa”

}

{

“body”:”{

“data”:”0348aa53-47f2-469e-8bb1-9be0607d099e”,

“error”:null,

“errorCode”:null,

“ok”:true

}”,

“direction”:”RESPONSE“,

“messageId”:null,

“messageType”:”SUBSCRIBE“,

“ontology”:”SensorHumedad”,

“sessionKey”:”5b9349ab5b9349ab-d9a8-4fd0-b155-a11c5d8df6fa”

}

UNSUBSCRIBE

Permite a un KP desuscribirse de una suscripción previa. A partir de ese momento el SIB no notificará nuevas instancias de ontologia que cumplan las condiciones de la query.

Campo body en el mensaje SSAP UNSUBSCRIBE:

El atributo “body” para un mensaje UNSUBSCRIBE de tipo REQUEST, tendrá 1 campo:

  • idSuscripcion: Identificador de la suscripción a eliminar. Este identificador fue informado al KP en el mensaje SSAP de respuesta para la suscripción.

El atributo “body” para un mensaje QUERY de tipo RESPONSE devolverá 4 campos:

  • data: Con valor nulo.
  • ok: Indicando con un valor booleano si la operación ha sido correcta o no.
  • error: Indicando un mensaje descriptivo en caso de operación incorrecta.
  • errorCode:En caso de operación incorrecta, indicara un código de error(AUTENTICATION, AUTHORIZATION, PROCESSOR, PERSISTENCE, PARSE_SQL, ONTOLOGY_NOT_FOUND, SIB_DEFINED_QUERY_NOT_FOUND, OTHER).

 

UNSUBSCRIBE REQUEST UNSUBSCRIBE RESPONSE
{

“body”:”{

“idSuscripcion”:”0348aa53-47f2-469e-8bb1-9be0607d099e”

}”,

“direction”:”REQUEST“,

“messageId”:null,

“messageType”:”UNSUBSCRIBE“,

“ontology”:”SensorTemperatura”,

“sessionKey”:”5b9349ab5b9349ab-d9a8-4fd0-b155-a11c5d8df6fa”

}

{

“body”:”{

“data”:””,

“error”:null,

“errorCode”:null,

“ok”:true

}”,

“direction”:”RESPONSE“,

“messageId”:null,

“messageType”:”UNSUBSCRIBE“,

“ontology”:”SensorTemperatura”,

“sessionKey”:”5b9349ab5b9349ab-d9a8-4fd0-b155-a11c5d8df6fa”

}

INDICATION

Es el mensaje de notificación con los resultados de una query de suscripción. Es el único mensaje asíncrono dado que se inicia desde el SIB y no tiene mensaje de respuesta. Con este mensaje, el SIB notifica a un KP que ha hecho una suscripción previa, los datos insertados o actualizado por otro KP y que cumplen los criterios de tal suscripción.

Campo body en el mensaje SSAP INDICATION:

El atributo “body” para un mensaje INDICATION devolverá 4 campos:

  • data: Devuelve una lista de con los resultado de la query de suscripción (incluyendo el identificador de objeto de la instancia) desde la última notificación.
  • ok: Indicando con un valor booleano si la operación ha sido correcta o no.
  • error: Indicando un mensaje descriptivo en caso de operación incorrecta.
  • errorCode: En caso de operación incorrecta, indicara un código de error(AUTENTICATION, AUTHORIZATION, PROCESSOR, PERSISTENCE, PARSE_SQL, ONTOLOGY_NOT_FOUND, SIB_DEFINED_QUERY_NOT_FOUND, OTHER).

 

INDICATION
{

“body”:”{

“data”:”[<datos de la query>]”,

“error”:null,

“errorCode”:null,

“ok”:true

}”,

“direction”:”RESPONSE“,

“messageId”:”3c3acfc4-bfed-4cbd-bbb6-9a09096e9263″,

“messageType”:”INDICATION“,

“ontology”:null,

“sessionKey”:”5b9349ab5b9349ab-d9a8-4fd0-b155-a11c5d8df6fa”

}

CONFIG

Mensaje enviado por un KP al SIB para obtener la configuración de software de sus aplicaciones. Permite a un KP conocer información almacenada y gestionada en el SIB sobre la configuración software de sus aplicaciones, lista de assets asociados, lista de esquemas de ontologías utilizadas.

Se trata de un mensaje que se envía fuera de una sesión SSAP, ya que es previo al establecimiento de la misma, para que el KP se autoconfigure antes de empezar a trabajar con el SIB. Por lo tanto, este mensaje no tiene asociada una sessionkey, y el KP debe autenticarse con sus credenciales en el propio mensaje. Del mismo modo, las credenciales son devueltas por el SIB al KP al no poder asociar la respuesta a una clave de sesión.

Campo body en el mensaje SSAP JOIN:

El atributo “body” para el mensaje JOIN de tipo REQUEST es dependiente del plugin de seguridad utilizado en el SIB, ya que las credenciales cambian dependiendo del plugin que utilice el SIB. En la versión actual en la nube sofia2.com se está utilizado el plugin de referencia basado en tokens de autenticación. De ahí que las credenciales indicadas sean los atributos:

  • kp: Idenficador de KP
  • instanciaKp: Identificador de instanciaKP
  • token: El token de autenticación generado en la plataforma para el KP.

El atributo “body” para el mensaje JOIN de tipo RESPONSE devolverá 3 campos:

  • kp: Idenficador de KP
  • instanciaKp: Identificador de instanciaKP
  • token: El token de autenticación generado en la plataforma para el KP.
  • lappsw: Lista de ficheros WAR con las aplicaciones a desplegar en el KP junto con su localización para descargarlos y su configuración.
  • lasset: Lista de assets asociados al KP junto con su configuración.
  • lmisc: Datos misceláneos de información propia al KP.
  • lontologia: Lista con los esquemas de las ontologías asociadas al KP y los permisos que dispone sobre ellas.

CONFIG REQUEST CONFIG RESPONSE
{

“body”:”{

“instanciaKp”:”KPvisualizacionHT01″,

“kp”:”KPvisualizacionHT”,

“token”:”cbb9364c434543a18dc6efa30dc780eb”

}”,

“direction”:”REQUEST“,

“messageId”:null,

“messageType”:”CONFIG“,

“ontology”:null,

“sessionKey”:null

}

{

“body”:”{

“instanciaKp”:”KPpubliAnuncios:KPpubliAnuncios01″,

“kp”:”KPpubliAnuncios”,

“token”:”d9e77d01d3c84f96994bfdcd428faa97″,

“lappsw”:[<lista de WARs de Aplicaciones>],

“lasset”:[<lista de assets asociados al KP>],

“lmisc”:[<datos misceláneos>],

“lontologia”:[<lista de ontologías y permisos>]

}”,

“direction”:”RESPONSE“,

“messageId”:null,

“messageType”:”CONFIG“,

“ontology”:null,

“sessionKey”:null

}

Conociendo el protocolo de Interoperabilidad de SOFIA2 – SSAP

5 comentarios en “Conociendo el protocolo de Interoperabilidad de SOFIA2 – SSAP

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s