Sofia4boot: Soporte para trabajar con Sofia2 en aplicaciones Spring Boot

 

Sofia2 se aplica usualmente a escenarios IoT y BigData, pero también puede usarse como Plataforma/Arquitectura de desarrollo para el desarrollo a medida de proyectos.

 

En este sentido Sofia2 aporta:

 

  • Facilidad de uso: Sofia2 es compatible con las metodologías de desarrollo actuales, permite a los desarrolladores realizar iteraciones de forma rápida y continua sobre el modelo de datos y todo desde un interfaz Web. En contraposición un desarrollo tradicional modelo relacional impone un estricto conjunto de limitaciones al desarrollo, tanto a nivel de modelo de datos, de creación de reglas, cambios,…

 

  • Modelo de datos. Con Sofia2, el desarrollador solo tiene que crear el modelo de datos en un lugar: la Consola Web del propio producto. En un desarrollo los desarrolladores necesitan crear y mantener el modelo de datos en tres lugares mediante el uso de diferentes interfaces: la aplicación, la propia base de datos y la capa ORM.

 

  • Soporte JSON. El almacenamiento en JSON, pilar básico de numerosas aplicaciones actuales, se realiza sin dificultades y no requiere conversión. Con una SGBDR, los desarrolladores necesitan “aplanar” y transformar JSON para almacenarlo en tablas relacionales, y más tarde tienen que recuperar las capas al realizar la extracción de la base de datos.

 

  • APIs multilenguaje: Aparte del conector REST que puede usarse de forma sencilla desde cualquier lenguaje, se ofrecen APIS multilenguaje cuando se necesitan protocolos más avanzados y eficientes. Las APIs permiten comunicar de forma más sencilla con la plataforma, se ofrecen APIS Java, Javascript, C/C++, Python, Android, iOS, Node.js, Arduino,… todas estas APIs bajo licencia Apache y sin coste.

 

En este post presentamos Sofia4Bot, una librería Java que permite desarrollar aplicaciones Spring y Spring Boot que usan Sofia2 como Backend, de forma muy sencilla: basta una anotación y una clase DTO que representa nuestra ontología.

 

Preparar un proyecto Spring Boot para hacer uso de Sofia4Boot es muy sencillo y solo son necesarios tres pasos

 

  1. Añadir la dependencia de Sofia4Boot al nuestro proyecto

 

 

Os recordamos el repositorio maven de Sofia2

 

 

  1. Configurar el fichero application.properties de nuestra aplicación, para añadirle las siguientes propiedades de conexión con la plataforma, son los datos de URL, PUERTO y ENDPOINT de conexión con la plataforma y el TOKEN, KP e INSTANCIA para la gestión de la seguridad que hace la plataforma Sofia2.

 

 

  1. Inicializar Sofia2Boot, para ello en el arranque de SpringBoot le indicamos que queremos usar el Sofia2Initializer:

 

 

Ya tenemos todo listo para empezar a usar Sofia2 como repositorio de datos. Al estilo de SpringData Sofia4Boot solo requiere que definamos la Interface de nuestro Repository. El framework se encargará por debajo de realizar toda la lógica de negocio.

 

Si por ejemplo queremos trabajar con la ontología Alarma, podemos crear una interface RepositoryAlarma:

 

 

Esta interface la anotaremos con @Sofia2Repository(“Alarma”). Con esto le indicamos al framework que es una interfaz de repositorio Sofia2 que trabaja con la ontología Alarma. Tras esto, lo único que debemos hacer es definir los métodos de acceso a datos. Sofia4Boot soporta las operaciones de Query, Insert, Update y Delete. Para cada una de estas operaciones existe una anotación:

 

@Sofia2Query

@Sofia2Update

@Sofia2Delete

 

Nos permiten en la propia anotación definir la sentencia SQL de la operación

 

@Sofia2Query(“select * from Alarma where Alarma.causa=$causa”)

@Sofia2Update(“update Alarma set Alarma.causa=$valor where Alarma.causa=$param”)

@Sofia2Delete(“delete from Alarma where Alarma.causa=$parametro”)

 

Como podemos deducir de la propia sentencia se soporta el uso de parámetros para hacer sentencias dinámicas. Estos parámetros los definiremos como parámetros del método que estamos definiendo List update(@Param(“$valor”)String valor,@Param(“$param”) String param);

 

Es suficiente con indicar a través de la anotación @Param con que parámetro de la consulta se asocia el parámetro del método.

 

@Sofia2Insert

 

Es todavía más sencillo de usar, el método solo necesita un parámetro que será el DTO de la ontología que vamos a insertar.

 

SofiaId insert(Alarma alarmaOntologia);

 

Estos métodos nos devuelven el identificador a través del SofiaId o de una Lista de SofiaId de los elementos que han sido credos, modificados o borrados y en el caso de las consultas una Lista del objeto de la ontología.

 

Veamos cómo queda la interfaz completa:

 

 

Y su invocación desde un controlador, donde directamente invocamos las operaciones que hemos definido pero no hemos tenido que implementar. Para Spring Boot existirá un bean que implementa nuestra interfaz ya que sofia4Boot se encarga de crearlo por nosotros y de toda la lógica de conectividad con Sofia2, preparación de los mensajes y transformación de datos en JSON a nuestros objeto Java.

 

 

Podéis descargaros el proyecto de ejemplo desde nuestro repositorio github en https://github.com/Sofia2/sofia4bootexample.git

 

Para ejecutarlo basta con hacer

 

mvn spring-boot:run

 

 

Para probar el ejemplo una vez creado el Controlador podemos hacer a través de una invocación HTTP. Vamos a lanzar la consulta de todos los registros y una inserción desde el cliente POSTMAN. En el caso de la consulta, definimos una operación GET a la URL del controlador, en la URL localhost:8080

 

 

Y nos devuelve un listado con la consulta

 

 

Para la Inserción, definimos la invocación a través de una operación POST y definimos los valores del Objeto Alarma. Al estar en un cliente HTTP, definimos el objeto como JSON

 

 

El retorno de la invocación será el Id de la instancia insertada.

 

 

A medida que ejecutamos inserciones, si volvemos a lanzar la consulta veremos que cada vez aparecen nuevas instancias.

 

 

También podemos crearlo como proyecto Eclipse ejecutando >mvn eclipse:eclipse

 

Sofia4boot: Soporte para trabajar con Sofia2 en aplicaciones Spring Boot

Social Login

La plataforma Sofia2, permite registrar usuarios asociándolos a las redes sociales más populares, de esta forma podemos utilizar las características de Single Sing On de otras plataformas como Facebook, Twitter o Linkedin para logarnos con el usuario de estas redes sociales. También debemos crear un usuario local en la plataforma, esto nos permitirá poder acceder siempre a Sofia2 independientemente de que por ejemplo los servicios de autenticación de las otras plataformas estén fuera de servicio.

 

Imagen 1.png

 

Cuando intentamos acceder a Sofia2 a través de una red social, lo primero que veremos será la página de Login de la Red Social, donde aceptaremos que la plataforma Sofia2 pueda leer nuestra información pública.

 

Imagen 1.png

 

Una vez que hemos accedido a través de la página de Login del proveedor accederemos a la página de registro del usuario local de Sofia2, donde tendremos rellenos los datos que nos proporcione la Red Social (Debemos tener en cuenta que no todas las redes sociales nos proporcionan la misma información)

 

Imagen 1.png

 

Una vez registrados podremos acceder a la plataforma a través del usuario local que hemos creado o a través de la red social, a todos los efectos para Sofia2 son el mismo usuario, pero la autenticación es realizada por una u otra plataforma.

 

Los datos recopilados de la Red Social son almacenados en una Ontología Privada llamada SocialMediaProfile y por tanto almacenados en formato JSON y consultables a través de la plataforma.

 

Imagen 1.png

Social Login

Nuevo Intérprete MongoDB en Notebook

Sofia2 a través de sus Notebook permite el acceso directo al modelo de datos BDTR, MongoDB, para ello cuenta con un intérprete que permite acceder a estos datos y compartirlos con el resto de intérpretes para el desarrollo en Analytics.

 

Este modo de acceso es complementario al acceso que ya se proveía a través de los conectores con Sofia2 y su protocolo de mensajes SSAP y está orientado a los perfiles puramente analíticos.

 

El Interprete por defecto está configurado para hacer uso de la instancia de datos de tiempo real de Sofia2, obviamente se porta la creación de nuevos intérpretes, configurados para usar otras instancias de forma que podamos trabajar con diferentes orígenes de datos MongoDB.

 

imagen-1

El intérprete configurado por defecto %mongodb nos permite ejecutar sentencias en lenguaje nativo MongoDB para recuperar la información con la queremos trabajar.

imagen-1

Si queremos mostrar directamente el resultado de una consulta sobre una colección bebemos prestar especial atención a la función table(), esta será la encargada de convertir los documentos MongoDB (JSON) en tablas interpretables por el Notebook.

imagen-1

Una vez que los datos son utilizables por el Notebook (table()) podremos realizar la presentación gráfica de los valores como en todos los interpretes de datos como una tabla.

Imagen 1.png
O como una representación gráfica.
imagen-1

Nuevo Intérprete MongoDB en Notebook

Particionado de Ontologías

Sofia2 unifica el mundo IoT con el mundo BigData, con su modelo de trabajo basado en el uso de un repositorio de tiempo Real (MongoDB) que vuelca la información a un repositorio Histórico (HDFS) cuando el primero no puede manejar el volumen de información.


Cuando los datos son volcados en el repositorio histórico, se disponibilizan como una tabla en Hive, con el tiempo el volumen generado en el repositorio de Tiempo Real, puede ser extremadamente elevado e  incluso complicado de manejar para la infraestructura BigData.


La operación de E/S es el principal cuello de botella de rendimiento para ejecutar consultas de Hive. El rendimiento se puede mejorar si se puede reducir la cantidad de datos que deben leerse. De forma predeterminada, las consultas de Hive examinan tablas completas de Hive. Esto es excelente para las consultas como recorridos de tabla; sin embargo, para las consultas que sólo necesitan analizar una pequeña cantidad de datos (por ejemplo, consultas con filtrado), esto crea una sobrecarga innecesaria.


Un modo de organizar la información mejorando las operaciones de E/S y optimizando los tiempos de acceso es mediante el uso de particiones.


La creación de particiones de Hive se implementa mediante la reorganización de los datos en nuevos directorios teniendo cada partición su propio directorio.


Ilustremos con un ejemplo, supongamos que las consultas que realizamos sobre un volumen muy grande de información siempre son discriminado el sexo y luego el país de residencia, en este supuesto podríamos crear dos particiones uno por sexo donde en disco se crearán dos directorio uno para Hombres y otro para Mujeres y  dentro de cada uno de estos directorios otros subdirectorios con el nombre de cada país de residencia.


Esto crea una estructura en forma de Árbol, y nos permite utilizar las capacidades de búsqueda de estas estructuras de datos. Debemos ser conscientes que si bien el rendimiento es muy superior cuando buscamos datos a través de los filtros basados en las particiones el sistema es altamente ineficiente si realizamos búsquedas que no hagan uso de estos filtros, por ejemplo si buscamos por nombre sin buscar por sexo y país de residencia.

presentacion1


También debemos prestar una especial atención a la organización de la información sería mucho más óptimo crear la primera partición por Pais y luego por Sexo, al tener el árbol más equilibrado.

Algunas consideraciones de particiones:

 

  • No cree particiones insuficientes: la creación de particiones en columnas con solo unos pocos valores puede generar muy pocas particiones. Por ejemplo, la creación de particiones por sexo solo creará dos particiones (hombres y mujeres); por tanto, solo se reduce la latencia a un máximo de la mitad.

 

  • No cree particiones excesivas: en el otro extremo, la creación de una partición en una columna con un valor único (por ejemplo, userid) hará que varias particiones provoquen un gran esfuerzo en el namenode del clúster ya que tendrá que controlar la gran cantidad de directorios.

 

  • Evite el sesgo de datos: elija su clave de creación de particiones con cuidado de manera que todas las particiones tengan el mismo tamaño. Un ejemplo es que la creación de particiones enEstado puede hacer que el número de registros en California 30 veces superior al de Vermont debido a la diferencia en la población.

Sofia2 permite la configuración del particionado de las ontologías. A través del menú mis ontologías.

imagen-1El usuario podrá decidir si la ontología debe almacenarse particionada en la BDH de Sofia2 y en tal caso con que campos.

 

El asistente nos permite seleccionar aquellos campos por los que queremos particionar, uno o varios.

 

El proceso de particionado puede ser costoso en función de los datos registrados en la BDH para esa ontología, durante ese tiempo desaparecerá el icono de configuración del participando

Particionado de Ontologías

BDTR y BDH en los NoteBook

Sofia2 disponibiliza un API compatible con Spark, de esta forma permitimos que los NoteBook puedan trabajar con la información contenida en cualquier instancia de Sofia2.

Este API es idéntico al API Java y a continuación vamos a ver cómo podemos hacer uso de este API para en nuestro Notebook de Analytic podamos trabajar con información por ejemplo Real Time.

Lo primero que haremos será crear la conexión física contra la instancia que queramos usar

ConexionFisica

Seguir leyendo “BDTR y BDH en los NoteBook”

BDTR y BDH en los NoteBook

Mejoras en el soporte de almacenamiento de binarios

Con la última versión de la plataforma Sofia2, ha llegado la posibilidad de operar con archivos binarios fuera de una ontología, esto permite el envío de binarios con un tamaño mayor al soportado por el tipo de dato Binary.

2015-06-17_17-31-41Como se expone en el gráfico anterior esta nueva funcionalidad consta de los siguientes módulos.

  • APIClient cliente Java que facilita la operatividad de upload, update, delete y recuperación de los binarios depositados en la plataforma.
  • Service exposición de un Servicio REST para subir ficheros a la plataforma.
  • Imeplentaciones Plugables a traves de las extensiones en modo Plugin podemos añadir nuevas implementaciones para el almacenamiento de los binarios, Actualmente se dispone de dos. Almacenamiento en la base de datos de tiempo Real (BDTR) y en sistema de ficheros (File).

El Servicio REST que expone el SIB soporta la subida de binarios a través de multipart, lo que permite adjuntar binarios sin límite de tamaño, la plataforma permite a través de su parametrización configurar el tamaño máximo de los binarios añadidos.2015-06-17_17-38-15

Los métodos que expone el servicio son.

  • Post. Para añadir un nuevo binario en la plataforma, en la respuesta del servicio se nos indicará el ID del Binario que debemos usar en las siguientes operaciones.

2015-06-17_17-42-07

  • Put. Para modificar un binario ya gestionado por la plataforma.

2015-06-17_17-44-26

  • Delete. Nos permite dar de baja un recurso gestionado por la plataforma (Será una baja lógica)

2015-06-17_17-45-17

  • Get. Podremos recuperar el Binario gestionado por la plataforma.

2015-06-17_17-46-25

Podemos observar que en todas operaciones se nos solicita un SessionId que obtendremos a través de un Join previo en la plataforma, para obtener un SessionId válido deberemos solicitar al administrador de la plataforma que nos otorgue permisos a alguno de nuestro Kp para usar BinaryRepository y con el nivel de actuación que deseemos Consultas, Inserciones o Completo.

En función del tipo de permiso podremos realizar todas las operaciones expuestas por el Servicio o solo aquellas para las que estemos autorizados.

Mejoras en el soporte de almacenamiento de binarios

Migración a MongoDB 3

Se ha actualizado en el entorno de experimentación CloudLab la versión 3.0.0 de MongoDB.

mongo3

La migración a esta versión desde la 2.6 se realiza de manera automática, respetando las colecciones y configuración de estas (indices, campos georferenciados…). En caso de tener que migrar desde una versión previa, se debe, como paso intermedio la migración a la versión 2.6.

To upgrade an existing MongoDB deployment to 3.0, you must be running 2.6. If you’re running a version of MongoDB before 2.6, you must upgrade to 2.6 before upgrading to 3.0. See Upgrade MongoDB to 2.6 for the procedure to upgrade from 2.4 to 2.6. Once upgraded to MongoDB 2.6, you cannot downgrade to any version earlier than MongoDB 2.4.

El proceso de migración es tan sencillo como detener el servicio de MongoDB sustituir los binarios de la versión 2.6 por los de la 3.0 y volver a arrancar el servicio de MongoDB.

Las principales novedades de esta versión son:

  • Nueva API de motor de almacenamiento de MongoDB que permite optimizar la base de datos para diferentes arquitecturas de hardware y cargas de trabajo de aplicaciones.
  • MongoDB 3.0 multiplica el rendimiento entre siete y diez veces, ofrece escalabilidad vertical para las cargas de trabajo de escritura intensiva mediante  la recopilación y el bloqueo a nivel de documento. La compresión nativa reduce considerablemente los costes de almacenamiento hasta en un 80 %. Ahora, los conjuntos de réplicas pueden incluir hasta 50 miembros, lo que reduce la latencia al distribuir geográficamente los datos cerca de los usuarios.
  • Ampliación del marco de auditoría introducido en MongoDB 2.6 para incluir todas las operaciones de sistema y datos (DDL y DML) en la base de datos. Gracias a estas extensiones, ahora los administradores pueden crear y filtrar las trazas de auditoría de cualquier operación en MongoDB sin tener que recurrir a herramientas de terceros.
Migración a MongoDB 3