Arquitetura

Este documento descreve a arquitetura atual que guia a implementação da plataforma, detalhando os componentes que compõe a solução, assim como as suas funcionalidades e como cada um deles contribui para a plataforma como um todo.

Enquanto uma breve explicação de cada componente é provida, esta descrição em alto nível não tem como objetivo explicar os detalhes de cada um dos componentes da implementação. Para isso, procure a documentação própria de cada um dos componentes.

Componentes

dojot was designed to make fast solution prototyping possible, providing a platform that’s easy to use, scalable and robust. Its internal architecture makes use of many well-known open-source components with others designed and implemented by dojot team. This architecture is described on Fig. 1.

Revised *dojot* Architecture

Fig. 1 Current Architecture

Using dojot is as follows: a user configures IoT devices through the GUI or directly using the REST APIs provided by the API Gateway. Data processing flows might be also configured - these entities can perform a variety of actions, such as generate notifications when a particular device attribute reaches a certain threshold or save all data generated by a device onto an external database. As devices start sending their readings to dojot, the user might want to receive these readings via notifications generated by subscriptions, consolidate all data into virtual devices, gather all data from historical database, and so on. These features can be used through REST APIs - these are the basic building blocks that any application based on dojot should use. dojot GUI provides an easy way to perform management operations for all entities related to the platform (users, devices, templates and flows) and can also be used to check if everything is working fine.

The user contexts are isolated and there is no data sharing, the access credentials are validated by the authorization service for each and every operation (API Request). Once devices are configured, the IoT Agent is capable of mapping the data received from devices, encapsulated on MQTT for example, and send them to the context broker for internal distribution, reaching, for instance, the history service so it can persist the data on a database. If certain conditions are matched when rules are being processed, a new event is generated and sent to the broker service to be redistributed to the interested services.

For more information about what’s going on with dojot, you should take a look at dojot GitHub repository. There you’ll find all components used in dojot.

Cada um dos componentes que compõe a arquitetura são brevemente descritos nas sessões subsequentes.

Kafka + data-broker + NGSI

Apache Kafka is a distributed messaging platform that can be used by applications which need to stream data or consume/produce data pipelines. In comparison with other open-source messaging solutions, Kafka seems to be more appropriate to fulfil dojot’s architectural requirements (responsibility isolation, simplicity, and so on).

No Kafka, utiliza-se uma estrutura de tópicos especializada para garantir isolamento de dados de usuários e aplicações, viabilizando uma arquitetura multi-tenant.

The flow-broker service makes use of an in-memory database for efficiency. It adds context to Apache Kafka, making it possible that internal or even external services are able to subscribe or query data based on context. Flow-broker is also a distributed service to avoid it being a single point of failure or even a bottleneck for the architecture.

To keep a certain level of compatibility with NGSI-compatible components, it is possible to build an element that offers a NGSI interface for such components.

DeviceManager

DeviceManager is a core entity which is responsible for keeping device and templates data models. It is also responsible for publishing any updates to all interested components (namely IoT agents, history and subscription manager) through Kafka.

O serviço não mantém estados e tem seus dados persistidos em banco de dados, onde suporta isolamento de dados por usuários e aplicações, viabilizando uma arquitetura de middleware com multi-tenancy.

IoT Agent

An IoT agent is an adaptation service between physical devices and dojot’s core components. It could be understood as a device driver for a set of devices. The dojot platform can have multiple iot-agents, each one of them being specialized in a specific protocol like, for instance, MQTT/JSON, CoAP/LWM2M and HTTP/JSON.

It is also responsible to ensure that it communicates with devices using secure channels.

Serviço de Autorização de Usuários

Serviço que implementa o gerenciamento de perfil de usuários e controle de acesso. Basicamente qualquer chamada de aplicação através do API Gateway é validada por este serviço.

Para ser capaz de atender a um grande volume de chamadas de autorização, faz uso de cache, não mantém estados e pode ser escalado horizontalmente. Seus dados são mantidos em banco de dados clusterizável.

flowbroker

This service provides mechanisms to build data processing flows to perform a set of actions. These flows can be extended using external processing blocks (which can be added using REST APIs).

History

The History component works as a pipeline for data and events that must be persisted on a database. The data is converted into an storage structure and is sent to the corresponding database.

Para armazenamento interno, utiliza-se uma base de dados não-relacional MongoDB que pode ser configurada em modo Sharded Cluster dependendo do caso de uso.

Os dados também podem ser armazenados em base de dados externa a plataforma dojot. Para isto, basta configurar o Logstash para enviar os dados para a base correspondente conforme a estrutura de dados desejada.

Serviço de Registro e Auditoria

All the services that are part of the dojot platform can generate usage metrics of its resources that can be used by a logging and auditing service, which process this registers and summarize then based on users and applications.

Os dados consolidados são disponibilizados para outros serviços do próprio dojot, permitindo-lhes, por exemplo, expor esses dados através de uma interface gráfica para os usuários, ára limitar o uso do sistema baseado no consumo de recursos e cotas associadas a usuários ou ainda pode ser usado por serviços externos de faturamento em função da utilização da plataforma por usuários.

Such components are currently in development.

Kong API Gateway

O Kong API Gateway é utilizado como um ponto de fronteira entre as aplicações e serviços externos e os serviços internos do dojot, isto resulta em inúmeras vantagens como, por exemplo, ponto único de acesso e facilidade na aplicação de regras sobre as chamadas de APIs como limitação de tráfego e controle de acesso.

GUI

The Graphical User Interface in dojot is responsible for providing responsive interfaces to manage the platform, including functionalities like:

  • Gerenciamento de perfil de usuários: definir perfis e quais APIs podem ou não serem acessadas pelo respectivo perfil.
  • Gerenciamento de usuários: operações de criação, visualização, edição e remoção.
  • Gerenciamento de aplicações: operações de criação, visualização, edição e remoção.
  • Gerenciamento de modelos de dispositivos: operações de criação, visualização, edição e remoção.
  • Gerenciamento de dispositivos: operações de criação, visualização (dispositivo e dados em tempo real), edição e remoção.
  • Gerenciamento de fluxo de processamentos: operações de criação, visualização, edição e remoção de fluxos de processamento de dados.

Controlador de Serviços Elástico

Serviço especializado para ambientes de nuvem que monitora a utilização da plataforma, diminuindo ou aumentando a sua capacidade de processamento e armazenamento de maneira automática e dinâmica de forma a se adaptar a variação da demanda.

Este controlador depende que os serviços que compõem o dojot possam ser escalados horizontalmente, assim como, que os bancos de dados utilizados sejam clusterizáveis, que é o caso da arquitetura adotada.

This component is currently scheduled for development.

Alarm Management

This component is responsible for handling alarms generated by dojot’s internal components, such as IoT agents, Device Manager, and so on.

Image manager

This component is responsible for device image storage and retrieval.

Infraestrutura

A few extra components are used in dojot that were not shown in Fig. 1. They are:

  • postgres: this database is used to persist data from many components, such as Device Manager.
  • redis: in-memory database used as cache in many components, such as service orchestrator, subscription manager, IoT agents, and so on. It is very light and easy to use.
  • rabbitMQ: message broker used in service orchestrator in order to implement action flows related that should be applied to messages received from components.
  • mongo database: widly used database solution that is easy to use and doesn’t add a considerable access overhead (where it was employed in dojot).
  • zookeeper: keeps replicated services within a cluster under control.

Comunicação

All components communicate with each other in two ways:

  • Using HTTP requests: if one component needs to retrieve data from other one, say an IoT agent needs the list of currently configured devices from Device Manager, it can send a HTTP request to the appropriate component.
  • Using Kafka messages: if one component needs to send new information about a resource controlled by it (such as new devices created in Device Manager), the component may publish this data through Kafka. Using this mechanism, any other component that is interested in such information needs only to listen to a particular topic to receive it. Note that this mechanism doesn’t make any hard associations between components. For instance, Device Manager doesn’t know which components need its information, and an IoT agent doesn’t need to know which component is sending data through a particular topic.