IoT Data Models: Iniciativas y Sofia2 Data Model

¿Qué es un Data Model?

Un Data Model representa la estructura de tus datos y relaciones, por tanto organiza los elementos y estandariza como se relacionan unos con otros.

¿Por qué utilizar un Data Model en el ámbito IoT?

Los Data Models son fundamentales en el ámbito IoT donde tratamos con assets físicos, medidas, dispositivos, procesos, personas,… y el nuestro IoT Data Model debe ser capaz de modelar todos estos conceptos.

Un Data Model nos da una representación uniforme de todos los elementos de nuestro sistema, esto tienen numerosos beneficios:

  • Reuso: la capacidad de modelar componentes que luego podré reusar es una práctica estándar que permite ahorrar en costes
  • Flexibilidad: una vez creado el modelo, este permite que sea fácil actualizar, modificar o eliminar elementos del modelo sin necesidad de rehacer el sistema
  • Escalabilidad: simplifica el clonado y modificación de dispositivos que son similares o se comportan de la misma forma que otros ya testados.
  • Interoperabilidad: usar un Data Model que se base en estándares (JSON, XML,…) simplifica que este Data Model pueda usarse en aplicaciones futuras de forma sencilla
  • Colaboración: Un Data Model nos permite predefinir links, relaciones, acciones entre componentes, permitiendo que esto se defina cuando se está creando el modelo de modo que diferentes equipos puedan trabajar en partes
  • Independencia de la Plataforma: un Data Model permite una integración transparente con otros sistemas. Un modelo correctamente formado hará más sencillo crear aplicaciones como analítica sobre los datos

Iniciativas de estandarización de un Data Model en IoT

NOTA: No hemos considerado los protocolos de comunicación como MQTT-SN, LWM2M o CoAP, aunque en algunos casos hay ciertos solapes puestos estos protocolos pueden llevar embebido un Data Model.

 

En el mundo IoT existen varias propuestas para intentar estandarizar un Data Model único, aunque la realidad es que ninguna de ellas tiene una penetración en el mercado suficiente como para decantarse de forma unívoca por ella.

A continuación se incluye una tabla con información relevante sobre algunas de estas iniciativas:

  Descripción Organiz Formato Versión
SensorML http://www.opengeospatial.org/standards/sensorml

Sensor Model Language pretende definir semánticamente prceoss y componentes relacionados con las medidas, con el objetivo de conseguir interoperabilidad

OGC XML +XSD 2.0

2014

AMON https://amee.github.io/AMON/

Formato para definir datos de dispositivos

AMEE JSON 3.1

2012

SensorThings http://www.opengeospatial.org/standards/sensorthings

Forma abierta y unificada de conectar dispositivos, datos y aplicaciones.

OGC JSON +

OData

1.0

2016

GSMA IoT Big Data Armonized Data Model https://www.gsma.com/iot/wp-content/uploads/2016/11/CLP.26-v1.0.pdf

Definición de entidades de uso común en IoT y Big Data creando modelos harmonizados en ámbitos Agricultura, Automoción, Environment, Industria, Smart City y Smart Home

GSMA JSON +schema.org 1.0

2016

FIWARE Data Model https://www.fiware.org/data-models/

Adaptación de GSMA Data Model sustituyendo schema.org para definición de Data Modelo por JSON-Schema para simplificar su uso

FIWARE JSON +

JSON-Schema

1.0

2017

¿Qué tienen en común estas iniciativas?

El grueso de estas iniciativas (sobre todo las más actuales) usan JSON como formato de intercambio.

Respecto a JSON podemos decir:

  • Es un formato de intercambio ligero, en la actualidad se ha convertido en el estándar de intercambio sustituyendo a XML en la mayoría de los escenarios

a2.jpg

  • Es el formato usado “para todo” por los grandes en el mundo Web: Google, Amazon,…
  • Es el formato por defecto de la “API Economy” con la que por ejemplo los bancos y organizaciones ofrecen sus datos
  • Es un formato que se usa en las modernas aplicaciones Web y móviles por ser mucho más ligero que XML
  • Es un formato ligero, adecuado para dispositivos IoT

Para definir la estructura de un JSON (por ejemplo que atributos son obligatorios o el tipo de datos) existe JSON-Schema (el equivalente a XML-Schema), aunque en la actualidad no es de uso obligatorio ni está ampliamente estandarizado y existen otras iniciativas.

Sobre JSON y JSON-Schema y por debajo de estándares como los que mencionábamos tenemos otros formatos y definiciones como OData o schema.org, pero tampoco tienen una penetración masiva.

Sofia2 Data Model

Ontologías Sofia2

En Sofia2 a la Entidad del Data Model usado (Sofia2 Data Model) la denominamos Ontologías.

Las Ontologías Sofia2 permiten modelar desde conceptos sencillos como una medida a conceptos complejos como una organización.

Las Ontologías en Sofia2 se definen en JSON+JSON Schema.

Origen de las Ontologías Sofia2

El concepto de Ontología viene del proyecto europeo I+D SOFIA del que se origina Sofia2, que usaba como Data Model Ontologías RDF/OWL conforme los principios de la Web semántica.

Cuando en 2013 Indra considera evolucionar SOFIA para crear una plataforma empresarial (Sofia2) que pueda usarse en proyectos productivos y complejos se realiza un análisis y pruebas empíricas y se concluye que la tecnología subyacente a las ontologías tradicionales modeladas en OWL no escala conforme a las necesidades de los proyectos IoT y Big Data.

Tras considerar diversas opciones se considera que JSON+JSON Schema es la mejor propuesta de presente y futuro.

Conceptos del Sofia2 Data Model

El concepto clave del Sofia2 Data Model es la Ontología, como ya hemos dicho, pero existen otros conceptos importantes, como el Template y la Instancia de la Ontología.

  Template Ontología Instancia Ontología
Representa Plantilla, bien creada por un administrador, bien creada conforme a un estándar concreto (AMON, FIWARE Data Model) que permite que las Ontologías se creen de Entidad que representa un concepto sobre el que trabaja la Plataforma. Es un registro concreto de la Entidad que define la Ontología
Ejemplos Plantilla definiendo los atributos de Calidad medioambiental conforme el FIWARE Data Model

-Pla

Calidad Medioambiental (obtenida de un dispositivo)

-Previsión metereológica (obtenida por un algoritmo)

-Calidad medioambiental obtenida en una hora concreta en un punto concreto

-Previsión para una región y mes concreto

Formato JSON-Schema JSON-Schema

(soporta GeoJSON, OData)

JSON

(GeoJSON)

Dónde están -No se almacenan, son una definición Independiente del motor de persistencia elegido: en un modelo relacional representan una tabla, en una BD NoSQL tipo documental una colección de documentos,,… Independiente del motor de persistencia elegido: en un modelo relacional representan un registro, en una BD NoSQL tipo documental un documento concreto,….
Más info Soportado por completo estándares AMON y FIWARE Data Model Soportan versionado

Soportan consultas geográficas

 

 Sofia2 Data Model en el Control Panel de Sofia2

Template

El concepto de Template representa una Plantilla sobre la que luego podrán crearse las Entidades.

Por tanto sólo se permite a los usuarios con rol ADMINISTRADOR crear estas Plantillas:

a1

En la Plataforma sólo tienen permiso para crear Templates o Plantillas, como puede verse en la imagen:

Las Plantillas tienen asociadas una o varias categorías que me permiten categorizarlas y buscar por estas.

Una Plantilla se representa por un JSON-Schema:

a3.jpg

Ontología

La Ontología es el concepto clave del Sofia2 Data Model y también del funcionamiento completo de la plataforma, ya que sobre estas se desencadenan el resto de procesos:

  • Reglas: se aplican ante la llegada de una instancia de ontología (o bien planificadas) y permite acceder a los atributos de las ontologías para accionar en base a esta
  • Dashboards: se construyen bien representando en tiempo real las instancias que van llegando a la plataforma bien a través de una consulta a estas
  • Analítica: los modelos ML típicamente se realizan sobre las ontologías almacenadas en la infraestructura Big Data de la plataforma (BDH)

Los usuarios Sofia2 con rol COLABORADOR pueden crear Ontologías, existen diversos mecanismos de crear Ontologías, los principales son:

  • Creación Paso a Paso: me permite crear Ontologías indicándole los atributos que componen la ontología, el tipo de datos de cada uno y si son obligatorios. Es la opción ideal para ontologías sencillas (equivalentes a una Tabla)
  • Creación mediante JSON-Schema: en este caso crearemos la Ontología bien definiendo el JSON-Schema que representa mi entidad, bien partiendo de un template ya creado.

Si seleccionamos la creación vía Ontología entonces me pedirá que seleccione una de las categorías:

a4.jpg

Y una vez seleccionada una de ellas (por ejemplo GSMA) me dará la opción de seleccionar una de las Plantillas:

a5

Soporta además:

La creación de la Ontología a partir de un Schema XML (XSD).

La creación de la Ontología a través de un diagrama UML que se crea en el propio Panel de Control

  • Creación desde CSV o Excel: esta opción es muy útil cuando tenemos un fichero con datos con los que quiero hacer una carga inicial en la plataforma. La Plataforma me irá guiando y solicitando la información que necesita hasta generar de forma automática el JSON-Schema que representa los datos pasados:

q1

  • Creación desde JSON/XML: equivalente a la creación desde Excel en este caso podré subir una JSON o XML para que la Plataforma cree la Ontología correspondiente.
  • Creación Ontología Tipo KPI: en este caso lo que estamos haciendo es crear una Ontología que se calcula en base a cálculos sobre otras ontologías
  • Creación Ontología Tipo TimeSeries: el concepto de Time Series se refiere a datos de tipo Serie Temporal, la plataforma soporta la creación de estos modelos de forma sencilla: 

    Instancia de Ontología

    Representa una instanciación de una ontología, típicamente en un momento concreto y posición concreta.

    La Plataforma ofrece diversas herramientas para acceder a las instancias, la más usadas por el desarrollador será la Consola BDTR y BDH que permite a través de un wizard generar consultas sobre las ontologías:

q3.jpg

 

 

 

Desde la herramienta puedo visualizar los datos de la Ontología (instancias) en formato nativo de la Plataforma, esto es en JSON:

q3.jpg

Pero también puedo representar los datos en formato TABLA e incluso exportarlos a formato CSV, Excel o XML.

 

 

IoT Data Models: Iniciativas y Sofia2 Data Model

Nueva Pantalla de Inicio del Control Panel

A partir de esta Release, cuando un usuario con rol colaborador accede a la plataforma, puede ver un grafo que representa su “Universo Sofia”. Es decir, puede ver las Ontologías, ThinKPs, Dashboards y Gadgets, Reglas, Proyectos etc.. que ha creado en la plataforma. En el caso de no tener aún ningun componente creado en la platafoma, se mostrará un grafo como el siguiente:

grafosincomp.png

Seguir leyendo “Nueva Pantalla de Inicio del Control Panel”

Nueva Pantalla de Inicio del Control Panel

Motor de KPIs

En esta release se ha incorporado la definición y creación de KPIs (Key Performance Indicator) en Sofia2. Un KPI consiste básicamente en una métrica que nos ayuda a medir y a cuantificar un progreso en función de unas metas y objetivos planteados, es decir, un KPI se diseña para mostrar cómo es el progreso en un proceso o producto en concreto.

En Sofia2 se ha implementado el concepto de KPI vía el concepto de ontología, en esta se almacenará aquella información procedente de otras ontologías que se considere relevante para el estudio de la evolución de una serie de parámetros.

Por tanto, para crear un KPI, debemos dirigirnos al menú Ontología->Crear Ontología y despues hacer click sobre Crear Ontología de tipo KPI:

kpipantallainiciales

Seguir leyendo “Motor de KPIs”

Motor de KPIs

Comó crear un Dashboard paso a paso.

En este post vamos a explicar el proceso de creación de un Dashboard.

En la Plataforma todos los módulos trabajan alrededor del concepto de Ontología, y esto también aplica a los Dashboards. Por tanto lo primero será seleccionar/crear/cargar las Ontologías que va a manejar.

En este ejemplo voy a crear un Dashboard que representa las Ventas de una empresa, así que crearemos:

  • una ontología ‘PuntoVenta‘ para representar los puntos de ventas global (continente)
  • y otra ‘PuntoVentaCliente‘ en la que representamos el punto de venta local (ciudad).

De las diversas formas que tenemos para crear una ontología seleccionamos ‘Creación Guiada Ontología’ dentro del menú Ontologías>Crear Ontología.

Veamos los atributos de cada una de ellas.

Seguir leyendo “Comó crear un Dashboard paso a paso.”

Comó crear un Dashboard paso a paso.

Analysis of the Total Cost of Ownership (TCO) of Sofia2 vs Custom development

In this post we have put together a simple analysis about the TCO of Sofia2 vs a Custom development on a relational database.

The Total Cost of Ownership (TCO) of MongoDB and Oracle includes upfront and ongoing costs including software, hardware and personnel.

UPFRONT COSTS:

The initial costs include:

  • Initial developer effort: Personnel costs + Developer coding required to get the application and data store working together
  • Initial administrative effort: Personnel costs + Admins to install and configure software, cluster machines, set up sharding, etc
  • Software licenses
  • Server hardware: Servers required to run database (excludes storage).  Driven primarily by the number and type of processors and RAM. Other costs include enclosures, network connectivity, cabling, and power supplies.
  • Storage hardware: Storage required to store the data, varies depending on whether internal or shared (SAN) storage is used, the amount of storage and whether hard disk drives (HDDs) or solid state drives (SSDs) are used.

ONGOING COSTS:

Consistes of:

  • Ongoing developer effort: Personnel + Coding needed to adapt data store to the customer, market and business needs.
  • Ongoing administrative effort: Personnel + Administrative effort required to keep the data store healthy and running.
  • Software maintenance and support: Maintenance: Upgrades and bug fixes for software + Support: On-call assistance for troubleshooting technical problems with software.
  • Hardware maintenance and support: Maintenance: Upgrades and bug fixes for firmware and any software that may come with the hardware + Support: On-call assistance for troubleshooting technical problems with hardware.
  • Miscellaneous Deployment Costs: Other costs associated with keeping database up and running. Includes cloud/hosting/colocation costs, bandwidth charges, electricity feed, etc.

Here is how Sofia2 reduces various costs that make up the TCO of a system:

INITIAL DEVELOPER EFFORT

The initial developer effort refers to the cost of time spent by the developer to ensure that the application and data warehouse work together.

In the case of a development on a relational database, the initial development effort includes tasks such as defining the data model, creating a layer of object-relational mapping (ORM), write the business logic for the application and make the presentation layer for this logic.

 

Sofia2 is designed to reduce development time, so that a developer can use the platform easily with any language.

With Sofia2 Console developers can:

  • Create their own entities (Ontologies in Sofia2, tables in an RDBMS, collections in MongoDB)
  • Define their business rules in a simple and guided way
  • Provide secure access to their entities
  • CRUD access (create, read, update, delete, …) to all these entities through any language (Java, Javascript, C, Android, …) allowing you to develop Web MVC applications (API Java, Python, Node js), HTML5 applications (API Javascript), mobile applications (API Android, iOS, Javascript …) or business modules (Java, Python, C, …)
  • Ability to subscribe to events, queries, rules, … easily and independently of the messaging protocol (JMS, MQTT, AMQP, …)
  • Assisted Publishing and APIs REST website based on entities
  • Integrated GIS Capabilities
  • Integrated Dashboards
  • Integrated reporting
  • Integrated Big Data Repository

 Therefore, we can say that it is much more profitable to develop with Sofia2 that to do a custom development on a relational database.

Another important productivity advantage of Sofia2 is its design of Entities (Ontologies) oriented to dynamic documents and schemas. The way in which the platform stores data from the application corresponds with the technology and current development practices that have evolved considerably since the beginning of the industry of the relational databases 30 years ago.

Some reasons that support the productivity benefits of Sofia2 are:

  • Usability: Sofia2 is compatible with existing development methodologies, allows developers to iterate quickly and continuously on the data model and all from a Web interface. In contrast to a traditional  relational model development that imposes a strict set of constraints to develop, both in terms of data model, rule creation, changes, …
  • Data Model. With Sofia2, the developer only has to create the data model in one place: the product´s own Web Console. In a traditional development developers need to create and maintain the data model in three places using different interfaces: the application, the database itself and the ORM layer.
  • Data flexibility. Unlike a RDBMS, Sofia2 allows developers to easily store polymorphic data and semi-structured and structured data in a individual data store.
  • JSON support. Storage in JSON, mainstay of many current applications, is done smoothly and does not require conversion. With a RDBMS, developers need to “flatten” and transform JSON to store it in relational tables, and then they have to recover the layers to make the extraction of the database.

INITIAL ADMINISTRATIVE EFFORT

The Installation and configuration of Sofia2 is cheap and easy. The Platform consists of:

  • CDB (Configuration DataBase): can be any relational database. By default it runs on a MySQL embedded DB.
  • RTDB (Real Time DataBase): where in the RI it is MongoDB making the initial administrative effort is low, an administrator must take into account a single variable: the number of nodes in the cluster. There is only a small set of configuration settings to put the system into operation. MongoDB administrators do not need to integrate layers of cache or create custom logic horizontal partitioning to direct queries to the correct server node. Instead, the memory storage, cache and the horizontal partitioning are core capabilities of MongoDB.
  • HDB (Historical DataBase): It can run on MongoDB or Hadoop depending on the needs or preferences.
  • SIB + Console + Tools + API Manager + Process: all business modules are built on Java, deployed as Web applications on any JEE application server. The bulk of the configuration goes in the CDB so it is not necessary to create complex configuration files.

SOFTWARE LICENSES

Sofia2 is a platform with a free version for the open source community (Apache license) and an issue for business subscribes that can be used in different modes: On Premise or Cloud.

This version includes support in various forms (from 8×5 without SLAS to 24×7 with strict SLAS), software updates and solution to errors and some additional functions.

The commercial edition of Sofia2 is billed continuously instead of timely (ie, an annual fee per server).

SERVER HARDWARE

In general, the cost of Sofia2 servers is considerably lower than in a traditional development on a relational DB for similar workloads and availability. This applies to all components.

Sofia2 is designed to use basic hardware in scalable architectures.

Sofia2 deployments typically use basic and economic Linux servers, which cost only $3.000, even a low-power and high performance can cost just $4.000 (excluding storage).

STORAGE HARDWARE

The scalable architecture of Sofia2 significantly reduces storage costs.

Sofia2 can use local economic storage and allows to efficiently use the solid state drives (SSD).

ONGOING DEVELOPER EFFORT

The dynamics of current development efforts are lower than the initial development effort.

With a traditional development, the cost of making changes in the application is greater, whether they are changes in the schema of a database that is already in production (greater costs than for a database that has not yet been delivered) as in the development of logic, rules, security settings.

For example with Sofia2 it is easy for developers to add fields to entities, create new APIs, which leads to significantly lower costs and allows developers to adapt applications as the demands evolve.

ONGOING ADMINISTRATIVE EFFORT

The ongoing administrative effort includes activities that keep the system in good working order (for example, updating software or hardware, performing backups and recovery times of unexpected interruptions).

Managing Sofia2 requires much less time and effort compared with traditional development.

Administration of a Sofia2 deployment primarily involves administering Linux configurations and hardware itself; so you only need to know and manage a few parameters.

SOFTWARE MAINTENANCE AND SUPPORT

Sofia2 subscriptions are billed annually per core. This includes access to product support, software updates and bug fixes as well as certain functionalities that are only available in the paid edition.

OTHER ADVANTAGES OF SOFIA2

In addition to tangible cost savings, the model oriented to documents and Sofia2´s flexible schema, the platform also provides greater agility and flexibility to companies, which in turn provide advantages to generate income.

Once the Sofia2 Platform is implanted in a company, they can use the Platform (without the need to build a new infrastructure) for new deployments and to integrate data from other systems so they have them centralized in a common repository with Big Data capabilities. You can also develop Sofia2 applications with any technology and language.

Analysis of the Total Cost of Ownership (TCO) of Sofia2 vs Custom development

Análisis sobre el TCO (Coste Total de Propiedad) de Sofia2 vs Desarrollo a medida

En este post vamos a hacer un pequeño análisis sobre el TCO de Sofia2 vs un desarrollo a medida sobre una base de datos relacional.

El coste total de propiedad (TCO) de MongoDB y Oracle incluye los costes iniciales y corrientes que incluyen software, hardware y personal.

COSTES INICIALES:

Los costes iniciales se componen de:

  • Esfuerzo de desarrollo inicial: Coste de personal + Programación del desarrollador necesaria para la aplicación
  • Esfuerzo administrativo inicial: Coste de personal + Administradores para instalar y configurar software, máquinas del clúster, particionado, …
  • Licencias de software
  • Hardware de servidores
  • Hardware de almacenamiento Almacenamiento necesario para almacenar los datos, varía en función de si se utiliza almacenamiento interno o compartido (SAN), de la cantidad de almacenamiento y de si se utilizan unidades de disco duro (HDD) o unidades de estado sólido (SSD).

 

COSTES CORRIENTES:

Se compone de:

  • Esfuerzo de desarrollo corriente: Personal + Programación necesaria para adaptar el almacén de datos a las necesidades del cliente, del mercado y empresariales
  • Esfuerzo administrativo corriente: Personal + Esfuerzo administrativo necesario para mantener el funcionamiento y ejecución del almacén de datos
  • Mantenimiento y soporte técnico del software: Mantenimiento: actualizaciones y soluciones de errores del software + Soporte técnico: asistencia para localizar y solucionar problemas técnicos en el software
  • Mantenimiento y soporte técnico del hardware:
  • Costes de despliegue diversos: Otros costes necesarios para mantener la base de datos en funcionamiento. Incluye costes de nube/alojamiento/coubicación, costes de ancho de banda, tarifas eléctricas, etc.

A continuación veremos cómo Sofia2 reduce los diversos costes que componen el TCO de un sistema:

ESFUERZO DE DESARROLLO INICIAL

El esfuerzo de desarrollo inicial se refiere al coste del tiempo dedicado por el desarrollador para conseguir que la aplicación y el almacén de datos trabajen juntos.

En el caso de un desarrollo sobre base de datos relacional, el esfuerzo de desarrollo inicial incluye tareas como definir el modelo de datos, crear una capa de mapeo objeto-relacional (ORM), escribir la lógica empresarial para la aplicación y hacer la capa de presentación para esta lógica.

Sofia2 está diseñado para que reducir los tiempos de desarrollo, de modo que un desarrollador en cualquier lenguaje pueda utilizar la Plataforma con facilidad.

Para eso a través de la Consola Sofia2 (Sofia2-Console) el desarrollador puede:

  • crear sus entidades (Ontologías en Sofia2, tablas en un SGBDR, colecciones en MongoDB),
  • definir sus reglas de negocio de forma sencilla y asistida,
  • establecer seguridad en el acceso a sus entidades,
  • Acceso CRUD (consulta, inserción, borrado, actualización,…) a todas estas entidades a través de cualquier lenguaje (Java, Javascript, C, Android,…) lo que le permite desarrollar tanto aplicaciones Web MVC (API Java, Python, Node.js), aplicaciones HTML5 (API Javascript), aplicaciones móviles (API Android, iOS, Javascript…) o módulos de negocio (Java, Python, C,…)
  • Capacidad de suscripción a eventos, consultas, reglas, …de forma sencilla e independiente del protocolo de mensajería (JMS, MQTT, AMQP,…)
  • Publicación asistida y web de APIS REST a partir de las entidades
  • Capacidades GIS integradas
  • Dashboards integrados
  • Informes integrados
  • Repositorio Big Data integrado

Por lo tanto, podemos decir que resulta mucho más rentable desarrollar con Sofia2 que hacer un desarrollo a medida sobre bases de datos relacionales.

Otra  ventaja de productividad importante de Sofia2 es su diseño de Entidades (Ontologías) orientado a documentos y a los esquemas dinámicos. La forma en que almacena datos de la aplicación se corresponde con la tecnología y prácticas de desarrollo actuales, que han evolucionado considerablemente desde los comienzos de la industria de las bases de datos relacionales hace 30 años.

Algunos motivos que respaldan las ventajas de productividad de Sofia2 son:

  • 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.
  • Flexibilidad de datos.A diferencia de una SGBDR, Sofia2 permite a los desarrolladores almacenar con facilidad datos polimórficos, así como datos semiestructurados y estructurados, en un almacén de datos individual.
  • 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.

ESFUERZO ADMINISTRATIVO INICIAL

La instalación y configuración de Sofia2 es económica y sencilla.

La Plataforma se compone de :

  • BDC (Base Datos Configuración) : puede ser cualquier base de datos relacional. Por defecto funciona sobre una BD embebida MySQL.
  • BDTR (Base Datos Tiempo Real): en la RI es un MongoDB lo que hace que el esfuerzo administrativo inicial sea bajo, un administrador solo debe tener en cuenta una variable: el número de nodos en el clúster. Solo existe un reducido conjunto de ajustes de configuración para poner el sistema en funcionamiento. Los administradores de MongoDB no necesitan integrar capas de memoria caché ni crear lógica de particionado horizontal personalizada para dirigir las consultas al nodo servidor correcto.  En lugar de esto, el almacenamiento en memoria, caché y el particionado horizontal son capacidades centrales de MongoDB.
  • BDH (Base Datos Históricoa): puede funcionar sobre MongoDB o Hadoop en función de las necesidades o preferencias.
  • SIB + Consola + Tools + API Manager + Process: todos los módulos de negocio de la Plataforma están construidos en Java, se despliegan como aplicaciones Web en cualquier servidor de aplicaciones JEE. El grueso de la configuración va en la BDC por lo que no es necesario crear ficheros de configuración complejos.

LICENCIAS DE SOFTWARE

Sofia2 es una Plataforma con una versión gratuita para la comunidad de código abierto (licencia Apache) y una edición para suscriptores comerciales que puede usarse en modo On Premise o en Modo Cloud.

Esta versión incluye soporte técnico en diferentes modalidades (desde 8×5 sin SLAS a 24×7 con SLAS estrictas), actualizaciones de software y soluciones de errores y algunas funciones adicionales.

La edición comercial de Sofia2  se factura de forma continua en lugar de puntualmente (esto es, una cuota anual por servidor).

HARDWARE DE SERVIDORES

En general, los costes de servidores de Sofia2 son considerablemente inferiores a los de un desarrollo tradicional sobre BD relacional para cargas de trabajo y disponibilidad similar. Esto aplica a todos los componentes.

Sofia2 se diseña para utilizar hardware básico en arquitecturas escalables.

Los despliegues de Sofia2 normalmente utilizan servidores Linux básicos y económicos.

HARDWARE DE ALMACENAMIENTO 

La arquitectura escalable de Sofia2 permite reducir considerablemente los costes de almacenamiento.

Sofia2 puede utilizar el almacenamiento local económico y permite realizar un uso eficiente de las unidades de estado sólido (SSD).

ESFUERZO DE DESARROLLO CORRIENTE

Las dinámicas del esfuerzo de desarrollo corriente son menores a las del esfuerzo de desarrollo inicial.

Con una desarrollo tradicional, el coste de realizar cambios en la aplicación es mayor, bien sean cambios en el esquema de una base de datos que ya se encuentre en producción (coste mayor que para una base de datos que aún no se ha entregado), como en el desarrollo de la lógica, reglas, seguridad, configuración).

Por ejemplo con Sofia2 resulta fácil para los desarrolladores agregar campos a las entidades, crear nuevas APIs, lo que se deriva en costes considerablemente inferiores y permite a los desarrolladores adaptar las aplicaciones a medida que evolucionen las demandas.

ESFUERZO ADMINISTRATIVO CORRIENTE

El esfuerzo administrativo corriente incluye actividades que mantienen el sistema en buen estado de funcionamiento (por ejemplo, actualización del software y hardware, realización de copias de seguridad y recuperación de tiempos de interrupción inesperados)

Se requiere mucho menos tiempo y esfuerzo para administrar Sofia2 en comparación con un desarrollo tradicional.

La administración de un despliegue de Sofia2 implica principalmente administrar configuraciones de Linux y el propio hardware; solo es necesario conocer y administrar unos pocos parámetros.

MANTENIMIENTO Y SOPORTE TÉCNICO

Las suscripciones de Sofia2 se facturan anualmente por core. Esto incluye el acceso al soporte técnico del producto, actualizaciones de software y soluciones de errores, así como ciertas funciones que solo se ofrecen en la edición de pago.

OTRAS VENTAJAS DE SOFIA2

Además de los ahorros de costes tangibles, el modelo orientado a documentos y el esquema flexible de Sofia2 también aportan mayor agilidad y flexibilidad a las empresas, que a su vez proporcionan ventajas para generar ingresos.

Una vez implantada la Plataforma Sofia2 en una empresa esta puede utilizar la Plataforma (sin necesidad de montar nueva infraestructura) para hacer nuevos desarrollos y para integrar datos de otros sistemas de forma que los tenga centralizados en un repositorio común y con capacidades Big Data. Además puede desarrollar aplicaciones Sofia2 en cualquier tecnología y lenguaje.

Análisis sobre el TCO (Coste Total de Propiedad) de Sofia2 vs Desarrollo a medida

Gobierno de Ontologías en Sofia2 (parte II)

Continuando con el primer post sobre gobierno sobre Ontologías en Sofia2 hoy veremos otros aspectos importantes a la hora de definir nuestras ontologías, como es la nomenclatura y tipado.

Nomenclatura:

  • Utilizar nombres en inglés y se seguirá el estándar Java (aka “camel”).
  • Para la definición de plantillas nombres cortos y autoexplicativos con primera letra en mayúsculas. Las primeras letras identifican el tipo de ontología:

Feed: Feed

Command: Cmd

Alert: Alrt

Schedule: Schdl

Audit: Adt

KPI: Kpi

  • Para la definición de ontologías primera letra en minúscula, empiezan siempre por el tipo de ontología. Ejemplo para una Espira: feedEspira, cmdEspira, adtEspira …
  • Para la definición de atributos de las ontologías primera letra en minúsculas, sin espacios, sin caracteres especiales.
  • Para la definición de constantes utilizadas como valores posibles para los atributos de las ontologías: todas las letras en mayúsculas. Por ejemplo: MOBILE, FIXED, VIRTUAL.

Seguir leyendo “Gobierno de Ontologías en Sofia2 (parte II)”

Gobierno de Ontologías en Sofia2 (parte II)