Mejoras API Manager

En la versión 2.15 de la plataforma de incluyen las siguientes mejoras en el módulo API-Manager:

Modos de Despliegue API-Manager

A partir de esta versión de la plataforma el módulo API Manager permite su despliegue bien en modo StandAlone, bien acoplado a un SIB existente.

Para esto último se incorpora un KP genérico que realiza la invocación. La configuración por defecto de dicho KP es externa al código.

Sistema de Caché API-Manager

Se incorpora además un sistema de caches propio del módulo. Consta de 2 caches separadas (para facilitar su configuración). Una definida para las APIs externas registradas y otra para las APIs disponibilizadas a partir de las Ontologías existentes de la plataforma.

La configuración del periodo de cache se realiza en la pantalla de creación/modificación de API, se incluye una nueva sección:

Si se selecciona la opción “Cachear Resultados”, se podrá introducir un valor en minutos de tiempo de Cacheo de los resultados de peticiones al API. Dicho tiempo de cache debe estar entre los límites permitidos (configurable desde ficheros de propiedades externos al código).

Soporte APIs externas con respuestas no JSON

Hasta ahora el formato en el que se devolvían las respuestas recibidas desde APIs externas era JSON. A partir de la versión 2.15 de Sofia2 se añade soporte para devolver cualquier tipo de formato de respuesta de APIs externas.

Por ejemplo, para una invocación a una API que devuelva una respuesta XML, el resultado de la invocación sería:

Y el contenido:

Mejoras API Manager

Sofia2: Características diferenciales

Sofia2 es una Plataforma IoT, su oferta puede conceptualizarse en este datasheet:

Sofia2 ofrece un conjunto de características diferenciales frente a otras soluciones, fundamentalmente:

  • Entorno de Experimentación gratuito: CloudLab
  • Operación y gestión de la Plataforma 100% web
  • Enfoque Semántico (ligero)
  • Independencia del protocolo de comunicación
  • Modular, Extensible y personalizable
  • Seguridad integrada
  • Modular
  • APIs multilenguaje
  • API Manager integrado
  • Motor de Reglas y Motor CEP integrado
  • Capacidades Social Media integradas
  • Implementación de referencia sobre software Open-Source
  • Despliegue On-Premise y On-Cloud
  • Integrada capacidades Big Data out-of-the-box
  • Gestión de SW y configuración dispositivos centralizada

Que en detalle:

Entorno de Experimentación gratuito: CloudLab

  • Dentro del Offering de la Plataforma se ofrece un Entorno de Experimentación en el que los desarrolladores de la Plataforma pueden probar todas las capacidades de la Plataforma sin coste. Esto permite poner en valor la Plataforma
  • Adicionalmente a través de CloudLab+ se ofrece la instalación de un entorno a medida y de horas de soporte a un precio asequible para el desarrollo de pilotos para mostrar la viabilidad de un proyecto.

Operación y gestión de la Plataforma 100% web

  • Toda la Plataforma se gestiona, mantiene y opera desde una Consola Web, tanto la definición de entidades (ontologías), seguridad, creación de clientes, reglas,…
  • Además se ofrece APIs REST para toda esta gestión, lo que permite integrar esta gestión en otras consolas de administración

Enfoque Semántico (ligero)

  • La Plataforma ofrece un enfoque semántico, lo que permite aprovechar esta semántica a la hora de hacer consultas, procesos analíticos,…
  • Se propone un enfoque semántico ligero basado en JSON, apropiado para todo tipo de dispositivos, incluso los menos potentes.
  • Se ofrecen modelos creados para diversos dominios, como dominio en el ámbito Smart City, Smart Energy. Estos modelos pueden ampliarse.
  • Desde la consola Web se pueden crear las entidades conforme a los dominios creados.

Independencia del protocolo de comunicación

  • Los mensajes intercambiados entre los clientes y la Plataforma son independientes de la Plataforma, se ofrecen out-of-the-box conectores para MQTT, REST, WebSockets, WebServices y JMS.
  • Los desarrolladores pueden crear nuevos conectores plugeables.

Modular, Extensible y personalizable

  • La Plataforma está creada con un enfoque modular lo que permite sustituir la implementación de un módulo por otra contemplando los interfaces (por ejemplo uso de SAP HANA en lugar de base de datos MongoDB de Implementación de referencia).
  • La Plataforma está pensada para extenderse en el proyecto a través del concepto de plugin. Los plugins se despliegan como JARs y permiten crear nuevos conectores, definir el modelo de seguridad adecuado,…
  • La instalación puede personalizarse según las necesidades, instalando sólo los módulos adecuados, definiendo parametrización,…

Seguridad integrada

  • Dentro de la Plataforma la seguridad es un concepto fundamental.
  • Se ofrece seguridad a nivel de comunicación (HTTPS, MQTTS,…) y también a nivel de permisos sobre las entidades, pudiendo ser entidades privadas, públicas o bien con acceso personalizado

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 se ofrecen bajo licencia Apache y sin coste.

API Manager integrado

  • Las APIS como mecanismo de integración es ya una realidad como prueban grandes como Facebook, Twitter, Google, Bancos a nivel internacional,…
  • Permite por un lado disponibilizar como APIs REST las entidades que maneja, permitiendo llevar al concepto Open Data el dinamismo de las APIs REST, también permite disponibilizar APIs Externas bajo un enfoque RESTful ofreciendo un acceso unificado.

Motor de Reglas y Motor CEP integrado

  • La Plataforma incluye un motor de Reglas que permite definir en un lenguaje sencilla y a través de la consola Web las reglas a aplicar antes la llegada de un evento o dato o bien temporizada. Permite a los usuarios con permisos crear en un lenguaje de scripting nuevas lógicas reutilizables e invocables desde el motor (por ejemplo enviar SMS o mail,…)
  • Además se incluye un motor CEP que permite definir reglas en las que interviene el tiempo (por ejemplo que no ha llegado una cierta medida en 1 día). A los eventos generados por el motor CEP pueden suscribirse los clientes o servir como entrada al motor de Reglas.

Capacidades Social Media integradas

  • Desde la propia consola pueden realizarse diversas búsquedas (perfiles, timeline, grupos, hashtags, tendencias) para las principales redes sociales.
  • Estas búsquedas se persisten sobre la plataforma para realizar procesos analíticos.

Implementación de referencia (RI) sobre software Open-Source

  • La RI de la Plataforma se basa por completo en software open-source sin restricciones, esto permite que la plataforma no acarree costosas licencias en su implantación.
  • Además existen otras implementaciones creadas a medida en la que unas piezas son reemplazadas por otras (pj HANA en lugar de Mongo y Hadoop, Motor CEP Oracle en lugar del Motor CEP WSO2, …)

Despliegue On-Premise y On-Cloud

  • La Plataforma puede instalarse tanto On-Premise como On-Cloud, bien públicas o privadas.
  • Se soportan diversos modelos de operación y diversos tipos de soporte en función de las necesidades de la organización.
  • En cloud puede optarse por un modelo PaaS en el que se cobra por la infraestructura montada o bien SaaS en el que se cobra por el número de mensajes procesaso o por TB usados.

Integrada capacidades Big Data out-of-the-box

  • La Plataforma integra de forma nativa un enfoque Big Data, de modo que para cada entidad (ontología) se puede definir cuándo los datos pasan de la RTDB (base de datos Tiempo Real) a la HDB (base de datos histórica) (RI sobre Hadoop).
  • La Plataforma integra capacidades para realizar consultas online tanto sobre la RTDB como sobre la HDB
  • La Plataforma permite lanzar procesos analíticos sobre la BDH de forma sencilla e integrada.

Gestión de SW y configuración dispositivos centralizada

  • Además de las APIs multilenguaje se ofrece una Infraestructura Java que permite construir aplicaciones para dispositivos embebidos autogestionada.
  • Desde la consola central se puede cargar el SW y la configuración que va a cada dispositivo o grupo de dispositivos de modo que a través de esta infraestructura se disponibilice.
Sofia2: Características diferenciales

Uso e invocación del API REST de Gestión

La consola Web de configuración de Sofía2 dispone de un API Rest de configuración que implementa las acciones que se permiten realizar desde la consola web utilizando un interfaz RES.

Para ello se puede utilizar el interfaz que proporciona la consola. Tras logarse en la misma e y pulsar sobre la opción documentación REST de la cabecera, se accederá a una pantalla que presenta el siguiente aspecto:

En el lateral izquierdo se dispondrá de un listado de todos los servicios REST asociados a entidades de la plataforma que se encuentran disponibilizados. Si se desciende en la pantalla, también se podrá acceder a los distintos objetos que los representan:

Si se pulsa sobre alguno de los objetos disponibles, aparecerá la descripción detallada del mismo en el panel principal de la pantalla, por ejemplo para Assets:

Para invocar a uno de los servicios, se pulsará sobre el servicio correspondiente. Aparecerán a la derecha el listado de operaciones disponibles:

Si se pulsa sobre una de ellas, se desplegará la documentación disponible, incluyendo parámetros,…

En la parte derecha de la pantalla, aparecerá un nuevo panel, que permitirá introducir los parámetros necesarios para la invocación del servicio. Para este caso:

Al encontrarnos registrados en la consola web, no será necesario introducir los encabezados (el navegador lo hará de forma automática). Sólo será necesario introducir los distintos parámetros de invocación.

Si se realiza una operación que necesita el envío de información (un alta o modificación por ejemplo), la pantalla proporcionará los interfaces asociados:

Una vez introducidos los datos y seleccionadas las opciones deseadas, al enviar la petición se observará el resultado en la parte inferior derecha de la pantalla. Por ejemplo para la invocación de un método que recupera todas las ontologías:

Las APIS son accesibles también a través de cualquier cliente REST externo. Para ello, habrá que especificar los mismos encabezados y parámetros que en el interfaz que se ha visto. Utilizando el plugin de Chrome “Advanced Rest Client”, una invocación sería similar a:

Se indicaría:

· El host y el puerto

· La ruta del servicio

· Query Parameters a utilizar (parámetros de la invocación)

· Tipo de Operación HTTP

· Encabezados de la petición:

o Tipo de datos que acepta el servicio (en este caso application/json)

o Token de Autorización: Basic (usuario:contraseña en B64)

Tras la invocación al mismo, se obtendría el resultado de igual forma:

Uso e invocación del API REST de Gestión

MongoDB Connector for Hadoop: MongoDB y Hadoop uniendo fuerzas!

MongoDB Connector for Hadoop es un plugin de Hadoop que permite usar MongoDB como fuente de entrada o como destino de salida.

Como bien sabemos en Sofia2 donde la implementación de referencia de la BDTR (Base Datos Tiempo Real) es MongoDB y de la BDH (Base Datos Histórica) es Hadoop usar MongoDB+Hadoop es una combinación muy potente ya que nos permite usarlos juntos para hacer procesamiento de datos y analíticas sobre datos almacenados en MongoDB.

Este conector funciona con prácticamente todas las versiones de Hadoop (incluidas CDH4 y CDH5), para usarlo basta con compilar el conector que está en GitHub para la distribución correspondiente.

Los diversos ejemplos de uso, como este ejemplo MapReduce que descarga el cuerpo de los mails y los importa en MongoDB dan una idea de cómo se usan

A un conjunto de mails con este formato:

Le aplicamos el proceso map:

Que extrae el campo headers de cada documento, parsea el campo From y el campo To para construir un objeto MailPair emitiendo el valor 1 para cada clave.

Luego con el reduce:

Sumamos el número de ocurrencias para cada par From-To

Son muchos los casos de uso típicos en los que MongoDB y Hadoop pueden formar un stack Big data típico.

En estos MongoDB actúa como el datastore en tiempo-real/operacional t Hadoop como el datastore offline para procesamiento y análisis.

Agregación Batch

En muchos escenarios la funcionalidad de agregación incluida en MongoDB es suficiente para analizar los datos, cuando es necesario un análisis más complejo Hadoop nos provee un framework muy potente para análisis complejos:

En este escenario los datos se extraen de MongoDB y se procesan en Hadoop con uno o más jbos MapReduce.

La salida de estos Jobs puede ser de nuevo escrita en MongoDB para consultas posteriores.

Data Warehouse

En un escenario típico de producción los datos del sistema pueden estar en diferentes datastores cada uno con su lenguaje de queries,…

Hadoop en este escenario puede usarse como datawarehouse y repositorio centralizado de múltiples fuentes lo que simplifica la complejidad de tratamiento de estos datos.

Pueden usarse Jobs MapReduce periódicos que vuelcan datos de Mongo a Hadoop.

ETL Data:

MongoDB puede ser el datastore operacional de nuestra aplicación pero también puedex existir otros. En este escenario es útil mover datos de un datastore a otro.

Los Jobs MapReduce pueden usarse para extraerse, transformar y cargar datos de un datastore a otro, actuando Hadoop como una ETL.

MongoDB Connector for Hadoop: MongoDB y Hadoop uniendo fuerzas!

¿Qué es oneM2M?

oneM2M es un proyecto de Asociación entre 7 Organizaciones líderes de Desarrollo de Estándares ICT (CCSA China Communications Standards Association, TTA Telecommunications Technology Association, ARIB Association of Radio Industries and Business, TTC Telecommunication Technology Committee of Japan , ETSI European Telecommunications Standards Institute, ATIS Alliance for Telecommunications Industry Solutions, TIA Telecommunications Industry Association) que se han unido para lanzar una nueva organización para asegurar el despliegue de sistemas de comunicación M2M de una manera más eficiente.

Para ellos todas las organizaciones acordaron cooperar en la producción, definición y mantenimiento de las Especificaciones Técnicas así como los Reportes Técnicos relacionados con soluciones M2M enfocados hacia la Capa de Servicio.

Inicialmente las organizaciones de oneM2M deben preparar, aprobar y mantener los documentos técnicos necesarios para:

1. Casos de uso y requerimientos para un conjunto común de capacidades de la capa de Servicio

2. Aspectos de la capa de Servicio con una definición a alto nivel y de manera detallada de la arquitectura

3. Protocolos/APIs/objetos estándar basados en la arquitectura

4. Aspectos relacionados con la privacidad y la seguridad

5. Accesibilidad y descubrimiento de aplicaciones

6. Interoperabilidad

7. Almacenamiento de datos para registros con fines estadísticos y de facturación

8. Identificación y nombramiento de dispositivos y aplicaciones

9. Modelos de información y de gestión de datos (incluyendo funcionalidades de suscripción y notificación)

10. Aspectos de gestión (incluyendo la gestión remota de entidades)

11. Casos de uso comunes, aspectos de terminales y módulos, incluyendo la capa de Interfaces/ APIs entre:

  • Las capas de aplicación y servicio
  • La capa de servicio y las funciones de comunicación

En 2014 fue lanzada la primera Candidate Release del estándar oneM2M.

Vamos a resumir sus principales características.

Casos de uso

OneM2M estableció unos casos de uso iniciales aplicables a los diferentes segmentos la industria M2M.

Esto es solo un cuadro resumen, si deseáis conocer con más detalle las especificaciones de cada uno de los casos de uso podéis descargaros el documento oficial aquí.

Arquitectura y especificaciones

En un principio se realizó un análisis de las arquitecturas propuestas para el estándar oneM2M junto con un estudio sobre como unir las arquitecturas propuestas. Obteniendo como resultado el documento Arquitectura funcional del estándar de la Candidate Release.

El modelo arquitectónico de oneM2M consiste en un modelo por capas compuesto por la capa de Aplicación, la capa de Servicios Comunes y la capa de los Servicios de Red.

capas oneM2M

Arquitectura funcional

oneM2M

La imagen nos muestra la estructura básica de un modelo oneM2M.

Los diferentes componentes que podemos ver en la imagen superior son instancias de las capas que vimos en el apartado anterior.

1. AE o Entidad de Aplicación: Representa una instancia de la lógica de la aplicación para soluciones punto a punto M2M. Ejemplos de posibles AEs podrían ser una instancia de una aplicación de seguimiento de flota (flota de autobuses interurbanos por ejemplo), una instancia de una aplicación de monitorización del azúcar en sangre, etc.

2. CSE o Entidad de Servicios Comunes: Representa la instancia de un conjunto de Funciones de Servicios Comunes (CSF) en los entornos M2M. Algún ejemplo de las funciones ofrecidas por un CSE es la función de Gestión de Datos, la de gestión de Dispositivos, la de gestión de Suscripciones M2M o Servicios de Localización.

3. NSE o Entidad de Servicios de Red: Una entidad de Servicios de red proporciona servicios de la red subyacente a los CSEs.

Relaciones entre entidades oneM2M

Las diferentes entidades se agrupar en nodos que pueden existir en un espacio oneM2M y pueden relacionarse entre sí.

oneM2MCom

Como podemos ver en la imagen existen diferentes tipos de nodos, tenemos el Infrastructure Node (IN), el Middle Node (MN), el Application Service Node (ASN) y el Application Dedicated Node (ADN) los cuales pueden comunicarse entre sí a través de los diferentes puntos de referencia que podemos observar. Dependiendo del tipo de nodo las restricciones de comunicaciones entre los diferentes nodos son distintos, para más información acudir a la sección 6.1 del Documento de Arquitectura Funcional de M2M.

Los diferentes nodos pueden estar localizados en diferentes puntos de la red M2M. Por ejemplo tanto los ASN como los ADN, pueden estar alojados en un dispositivo M2M. Un MN puede estar alojado en un Gateway M2M. En el caso de los INs solo puede existir un nodo de este estilo en el dominio de la infraestructura (Infrastructure Domain en la imagen) por Proveedor de Servicio en un sistema oneM2M.

Aspectos de Seguridad

OneM2M más allá de proporcionar soluciones de seguridad que protegen la integridad de la capa de servicios M2M, la arquitectura oneM2M expone, a través de su API, más servicios de seguridad que se ponen a disposición aplicaciones M2M. Esto permite a las aplicaciones M2M beneficiarse de las soluciones de seguridad desplegadas en el Servicio de Arquitectura M2M, sin añadir soluciones de seguridad redundantes y / o propietarias.

¿Qué es oneM2M?