Monografia- ThingProvider

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE CAMPINAS
CENTRO DE CIÊNCIAS EXATAS, AMBIENTAIS E DE
TECNOLOGIA
KEVIN MATHEUS MARTINS
PROVEDOR DE SERVIÇOS PARA INTERNET DAS
COISAS
CAMPINAS
2018

KEVIN MATHEUS MARTINS
PROVEDOR DE SERVIÇOS PARA INTERNET DAS
COISAS
Este trabalho apresenta um modelo para
aplicação de serviços na arquitetura da IoT
visando ambientes locais onde o
compartilhamento de informações entre
diversos sistemas se mostre necessário.
Orientador: Prof. Dr. Amilton da Costa
Lamas
CAMPINAS
2018

Pontifícia Universidade Católica de Campinas
Centro de Ciências Exatas, Ambientais e de Tecnologia
Faculdade de Engenharia Elétrica
Curso de Engenharia de Telecomunicações
Autor: MARTINS, Kevin Matheus
Título: Provedor de serviços para internet das coisas
Trabalho de Conclusão de Curso
BANCA EXAMINADORA
Presidente e Orientador Prof. Dr. _____________________________________
1º Examinador (Prof. Dr. _____________________________________________
2° Examinador (Prof. Dr. _____________________________________________
Campinas, ___ de ____________ de 2018

À minha querida família e amigos que me apoiaram em
minhas decisões.

AGRADECIMENTOS
Ao Prof. Fabio Pereira Benjovengo que me apoiou no desenvolvimento deste projeto, se
mostrando aberto a novos temas de conclusão de curso pertinentes a área de engenharia de
telecomunicações onde deu total suporte para sucesso do projeto.
Ao Prof. Amilton da Costa Lamas que entendeu o momento da minha carreira e em como
eu poderia tornar meu trabalho mais completo para o curso de engenharia de telecomunicações.
Ao meu fiel amigo Gustavo Henrique Cirulo que me ajudou durante todo período da
graduação onde me auxiliou a compreender os conceitos voltados à elétrica e sua aplicação
prática, me apoiou nas dificuldades e tornou o processo da graduação muito mais cativante e
tranquila.
Aos meus companheiros de trabalho que me fazem crescer tecnicamente onde este
projeto só foi possível de ser realizado devido ao convívio com estes.
A empresa Dextra Digital que me proporciona um ambiente do mais alto nível técnico e
um aprendizado contínuo.
A todos meus companheiros de turma que tornaram a experiência da universidade uma
jornada de união e coleguismo.

“Experiência é o nome que todos dão aos seus próprios
erros”.
Oscar Wilde
(1854-1900)

RESUMO
MARTINS, Kevin Matheus. Provedor de serviços para internet das coisas. 2018. Trabalho
de Conclusão de Curso (Graduação) – Curso de Engenharia de Telecomunicações,
Pontifícia Universidade Católica de Campinas, Campinas, 2018.
Este trabalho apresenta um modelo para aplicação de serviços na arquitetura da IoT
visando ambientes locais onde o compartilhamento de informações entre diversos
sistemas se mostre necessário. Para propor uma arquitetura diferente da comum
monolítica aplicada comumente em projetos de menores escalas serão utilizados web
services RESTful proporcionando a possibilidade do consumo das informações para os
mais diversos sistemas em que esta se mostre necessária, algo que em sistemas
centralizados se torna difícil, além de se aplicar uma arquitetura distribuída para o ganho
de benefícios. Para propor um modelo de serviço descentralizado foi criado um servidor
de roteamento onde é possível o cadastro de rotas de serviços compostas por vários
outros serviços baseados em verbos do protocolo HTTP, permitindo a criação de caches
e apresentação de maior desempenho na busca de informações. Um sistema isolado foi
criado para o teste de conceito possibilitando a comunicação distribuída de serviços
aplicados à internet das coisas. Esse sistema foi estressado a casos de erros e múltiplas
requisições onde foi possível comprovar as vantagens sistêmicas da aplicação deste
modelo.
Palavras Chave: HTTP, IoT, JAVA , NODE , PYTHON ,REST, Serviços ,Software.

ABSTRACT
MARTINS, Kevin Matheus. Internet Service Provider of Things. 2018. Trabalho de
Conclusão de Curso (Graduação) – Telecommunications Engineering Course, Pontifícia
Universidade Católica de Campinas, Campinas, 2018.
This work presents a model for application of services in the IoT architecture, aiming at
local environments where information sharing among several systems is necessary. In
order to propose a different architecture from the common monolithic commonly applied in
projects of smaller scales will be used RESTful web services providing the possibility of
the consumption of the information for the most diverse systems in which it is shown
necessary something that in centralized systems becomes difficult, besides apply a
distributed architecture for the gain of benefits. In order to propose a decentralized service
model, a routing server was created where it is possible to register service routes
composed of several other services based on HTTP protocol verbs, allowing the creation
of caches and presentation of higher performance in the search of information. An isolated
system was created for the concept test allowing the distributed communication of
services applied to the internet of the things where it was stressed to cases of errors and
multiple requisitions where it was possible to prove the systemic advantages of the
application of this model.
Descriptors: HTTP, IoT, JAVA , NODE , PYTHON ,REST, Serviços ,Software.

LISTA DE FIGURAS
Figura 1- Módulo provedor de serviços ........................................................................... 23
Figura 2- Serviço de roteamento ..................................................................................... 24
Figura 3- Disposição dos módulos do sistema ................................................................ 27
Figura 4- Arduino uno...................................................................................................... 30
Figura 5- Sensor de chuva .............................................................................................. 30
Figura 6- Ethernet shield para Arduino............................................................................ 30
Figura 7- Disposição das tarefas..................................................................................... 32
Figura 8- Descrição da tarefa.......................................................................................... 32
Figura 9- Disposição das tarefas no modelo Kanban ...................................................... 33
Figura 10- Módulo de serviço com um sensor de chuva.................................................. 35
Figura 11- Sensor de chuva ............................................................................................ 35
Figura 12- Requisição para o serviço do sensor digital de chuva .................................... 36
Figura 13- Requisição para o serviço do sensor analógico de chuva .............................. 36
Figura 14- Serviço atuador ligado.................................................................................... 38
Figura 15- Serviço atuador desligado.............................................................................. 38
Figura 16- Requisição ligando o serviço atuador............................................................. 39
Figura 17- Requisição desligando o serviço atuador ....................................................... 39
Figura 18- Configuração da expiração dos valores em memória..................................... 42
Figura 19- Requisição ao serviço de roteamento ............................................................ 42
Figura 20- Segunda requisição ao serviço de roteamento............................................... 43
Figura 21- Resultados do teste de carga com o módulo de roteamento.......................... 45
Figura 22- Resultados do teste de carga sem o módulo de roteamento.......................... 46
Figura 23- Serviços criados para o teste integrado.......................................................... 48
Figura 24- Logs do módulo de chamadas periódicas ...................................................... 50
Figura 25- Cenário ativo.................................................................................................. 50
Figura 26- Número de dispositivos conectados a internet ............................................... 53

LISTA DE GRÁFICOS
Gráfico 1- Comparativo do teste de carga entre o módulo de roteamento ativo e um
cenário convencional............................................................................................... 47
Gráfico 2- Alterações nas chamadas............................................................................... 51

LISTA DE QUADROS
Quadro 1- Disposição dos serviços................................................................................. 24
Quadro 2- Retorno do serviço do sensor digital de chuva ............................................... 37
Quadro 3- Retorno do serviço do sensor analógico de chuva ......................................... 37
Quadro 4- Retorno da ativação do serviço atuador ......................................................... 40
Quadro 5- Retorno da desativação do serviço atuador.................................................... 40
Quadro 6- Retorno da busca pelo módulo de roteamento ............................................... 41
Quadro 7- Rotas para o teste integrado .......................................................................... 49

LISTA DE ABREVIATURAS E SIGLAS
PUC = Pontifícia Universidade Católica de Campinas
IoT = Internet of Things - Internet das coisas
REST = Representational State Transfer-Transferência de estado representacional
JSON = JavaScript Object Notation -Objeto de JavaScript
RESTful = Aplicação de REST para serviços web
API = Application program interface-Interface de programação de aplicativos
URI = Uniform resource identifier-Identificação de recursos universal
HTTP = Hypertext Transfer Protocol- Protocolo de transferência de hipertexto
WS = Web service-Serviço web
GIT = Sistema de controle de versão
Kanban = Metodologia para tornar o desenvolvimento de tarefas mais eficiente
Firmware = Fornece controle de baixo nível para um hardware específico
MongoDB = Banco de dados não relacional
Javascript= Linguagem de programação
Node JS = Ambiente de execução JavaScript para servidor

13
SUMÁRIO
1 Introdução 15
1.1 Descrição do projeto 15
1.2 Justificativa 16
1.3 Objetivos 16
2 Fundamentação 17
2.1 O que é IoT ? 17
2.2 Sistemas distribuídos 17
2.3 Web services 18
2.4 JSON 18
2.5 Endpoint 19
2.6 API 19
3 Descrição 20
3.1 Módulo de roteamento de serviços 20
3.1.1 Módulo de exposição de serviços 20
3.1.2 Módulo de provedores de serviços 20
3.2 Consumo e exposição de API 21
3.3 Proposta 22
3.4 Arquitetura 22
3.4.1 Módulo de provedores de serviços 22
3.4.2 Módulo de roteamento de serviços 23
3.4.3 Módulo de exposição de serviços 26
3.4.4 Produto 26
3.5 Integração contínua 28
3.6 Virtualização 28
3.7 Materiais 29
3.7.1 Módulo de provedores de serviço 29
3.7.2 Teste de conceito 29
3.7.3 Módulo de roteamento 31
3.7.4 Módulo de apresentação 31

14
4 Método 32
5 Resultados 34
5.1 Testes unitários do módulo provedor de serviços 34
5.1.1 Nós associados a um sensor de chuva e um LED 34
5.1.2 Ambiente 34
5.1.3 Nó sensor de chuva 34
5.1.4 Nó atuador com LED 37
5.2 Testes unitários do módulo de roteamento 40
5.2.1 Exemplo de requisição ao servidor 40
5.2.2 Testes de carga 44
5.3 Testes Integrados 47
6 Discussão 52
6.1 A grande necessidade da incorporação de APIs a IoT 52
6.2 O problema com a complexidade em sistemas distribuídos 53
7 Conclusão 55
8 Referências 56

15
1 INTRODUÇÃO
Com a crescente necessidade de integrar diferentes sistemas, o conceito
de API se tornou bastante popular e se mostrou como uma das melhores
soluções para a exposição de serviços permitindo a gerência de serviços
escalava, flexíveis e seguros.
Atualmente as APIs são construídas em sua maior parte utilizando os
conceitos do modelo arquitetural REST, onde recursos são gerenciados e
identificados com o conceito de URI sobre o protocolo HTTP representando seus
recursos com múltiplos formatos, sendo o mais comum deles o JSON.
Em grandes e pequenas implantações de IoT são comumente utilizadas
os conceitos de monólitos fazendo com que a arquitetura da solução seja eficaz,
porém qualquer alteração fará com que todo o sistema seja recarregado. Uma
alternativa recente aos monólitos é a arquitetura voltada à micro serviços onde o
sistema como um todo é dividido em pequenos serviços independentes, flexíveis
e escaláveis.
A aplicação de micro serviços junto às APIs pode tornar as implantações
de IoT mais baratas, escaláveis, resistente a erros, além de prover um design
eficiente para a heurística da IoT.
1.1 Descrição do projeto
Os dispositivos de IoT precisam manter o tráfego de rede pequeno, além
de necessitar que este seja rápido, dado que possuem uma memória pequena e
limitada, um baixo poder de processamento de grandes informações e consumo
limitado de energia devido as suas baterias. Esse cenário caracteriza a exposição
de serviços onde este irá processar apenas as requisições de seus serviços
expostos, ficando a responsabilidade de quem fez a requisição processá-la e
tomar decisões sobre esta.
Esse projeto tem como base a criação de uma plataforma para
roteamento de serviços integrados a dispositivos de IoT, provendo um sistema
integrador que irá gerenciar as requisições e permitir o cadastro de serviços
dispostos por dispositivos de IoT em geral, junto a uma estratégia de contorno de

16
erros caso o serviço apresente falhas e um cache para minimização de acessos
indevido aos dispositivos de IoT.
Foi dado o nome de ThingProvider para uma representação comercial do
projeto.
1.2 Justificativa
A aplicação do conceito de micro serviços e APIs voltadas a IoT proveem
melhorias de desempenho, além de permitir integração entre diversos sistemas e
remover a necessidade de reinicialização completa do sistema em casos de erro.
Em ambientes locais é difícil o compartilhamento de dados entre usuários
devido à inexistência de plataformas simples com este fim. É necessária uma
plataforma que demonstre quais os serviços locais estão disponíveis e quais são
os recursos para utilizá-las.
Também é necessário que essa plataforma tenha um algoritmo que busque
pelos serviços e realize sua integração realizando as ações necessárias de modo
a ser simples ao usuário sua utilização, compondo serviços complexos e
utilizáveis por várias aplicações. As utilizações de arquiteturas monolíticas
impedem a resolução desse problema, assim sendo necessária a utilização de
uma arquitetura distribuída.
1.3 Objetivos
Aplicar os conceitos arquiteturais de micro serviços e exposição de
serviços REST em aplicações de IoT, prover uma plataforma para exposição de
serviços e demonstrar que o desempenho e o compartilhamento de serviços
podem ser aplicadas aos dispositivos de IoT.
Também se tem como objetivo a criação de uma ferramenta que
possibilite o roteamento necessário para os serviços e a realização das ações
necessárias onde um teste de conceito composto por um sistema distribuído será
criado demonstrando a aplicação prática da aplicação de APIs para os
dispositivos de internet das coisas.

17
2 FUNDAMENTAÇÃO
Serão apresentados brevemente os conceitos essenciais para o
entendimento do projeto e análise dos resultados obtidos.
2.1 O que é IoT ?
Com os avanços da tecnologia, a coleta e a troca de informações se
tornaram um grande facilitador na questão de oferecer serviços personalizados e
integrados para as pessoas e para a indústria. De forma resumida, IoT é a
comunicação máquina a máquina por meio da Internet , onde através de sensores
e dispositivos acoplados ao mais diferentes objetos a comunicação entre as
“coisas” se torna possível.
A discriminação de processadores baratos, internet e acesso a serviços
criam um ambiente onde a evolução da internet das coisas acontece tanto por
meio de grandes laboratórios de pesquisa quanto por indivíduos com interesse
pelo assunto, onde sua utilização já é algo bastante comum e por muitas vezes
passa até despercebido pela população.
2.2 Sistemas distribuídos
Existem várias definições para o conceito de sistemas distribuídos, mas
em termos gerais são sistemas composto por vários computadores e softwares
independentes entre si, interconectados por uma rede que juntos compõem um
sistema único e coerente.
Seu funcionamento é dividido em domínios de tarefas onde estas são
processadas por um módulo com esta única funcionalidade e no momento que
outro módulo necessita do serviço é realizada uma integração entre módulos de
forma que ao usuário o sistema parece ser algo único, porém todas suas
transações são distribuídas. Ao distribuir um sistema é possível obter algumas
vantagens referentes à escalabilidade, desempenho, falhas parciais e estratégias
em cenários de erros já que os módulos são independentes.
No cenário da internet é bastante comum a criação de APIs para a
comunicação de diferentes serviços, onde são criados alguns pontos de entrada

18
na aplicação que irão receber requisições sobre o protocolo HTTP para executar
ações e um conjunto de pontos de entrada caracterizam uma API.
2.3 Web services
Os web services são conjuntos de funções que podem ser invocadas por
outros programas que utilizam as tecnologias web com o objetivo de trafegar
dados através de protocolos de comunicação entre diferentes plataformas e
soluções podendo integrar aplicações escritas em diferentes linguagens e
executadas em hardwares diferentes.
Com os web services é possível a separação entre clientes e servidores
além da integração entre funcionalidades diferentes sendo possível arquitetar
uma solução que irá consumir vários serviços com a finalidade de apresentar ao
usuário algo único.
Sua comunicação ocorre através de requisições que são processadas
pelo servidor do web servisse, convertida na linguem necessária e gerada uma
resposta ao cliente que realizou a requisição.
2.4 JSON
JSON é uma forma de representação de objetos em texto definidos por
chaves e valores. Quando uma comunicação entre um navegador e um servidor
está sendo realizada é possível apenas trafegar texto, o que torna o JSON uma
tecnologia extremamente poderosa, pois sua conversão pode ser facilmente
realizada em qualquer linguagem de programação além de permitir uma leitura
simplificada para humanos.
O significado de JSON é JavaScript Object Notation tendo esse nome
devido a linguagem de programação JavaScript onde objetos são representados
por chaves e valores.

19
2.5 Endpoint
Um endpoint é uma função publicada por um web service, onde este irá
receber uma requisição, processar e gerar uma resposta. É normalmente
representado por uma URL que pode ser acessada por um cliente.
2.6 API
Uma API é um conjunto de ferramentas, protocolos e rotinas que
constituem uma aplicação. O objetivo das APIs é a realização da integração entre
sistemas de forma distribuída sendo possível a criação da comunicação entre
diferentes aplicações.
São normalmente criadas com um conjunto de endpoints que possibilitam
a realização de tarefas em um servidor, podendo ser consumida por vários
clientes. O escopo de uma API é voltada a uma entidade e as operações que está
pode executar.

20
3 DESCRIÇÃO
O sistema será dividido em três módulos com responsabilidades únicas,
compondo uma solução abrangente à proposta da criação de um sistema
distribuído onde cada módulo possui uma reponsabilidade única e isolada para a
criação da solução.
3.1 Módulo de roteamento de serviços
Responsável pelo roteamento de serviços sendo composto por rotas que
direcionam aos nós provedores, realizando requisições aos provedores de
serviços junto aos dados fornecidos pelo sistema. Possui duas principais
funcionalidades, sendo a primeira o gerenciamento do cadastro de serviços onde
estes são basicamente coleções de endereços das APIs publicadas pelos nós e o
segundo serviço que realiza a integração com os nós, tornando possível a sua
utilização por clientes que desejam conseguir os serviços. Também será
responsável pela execução de uma tarefa agendada que irá consumir os serviços
para a verificação do teste de conceito.
3.1.1 Módulo de exposição de serviços
Responsável pela interação com o usuário, onde os serviços cadastrados
no sistema serão demonstrados junto a informações do projeto. Tem como maior
funcionalidade a disposição visual dos serviços de forma a auxiliar o usuário a
utilizar corretamente os serviços disponíveis.
3.1.2 Módulo de provedores de serviços
São os nós de sensores com API publicadas para consumo do módulo de
roteamento de serviços, onde estes realizam o intermédio entre o dispositivo de
internet das coisas com a API de modo a abstrair suas funcionalidades em forma
de serviços.

21
3.2 Consumo e exposição de API
Para a criação de uma API RESTful é necessário utilizar os conceitos do
estilo de arquitetura REST que define um conjunto de propriedades baseados no
protocolo HTTP, para isso são definidos recursos que são entidades que podem
ser manipuladas, endereçadas ou nomeadas na internet por meio de URLs. Para
a realização das operações relacionadas aos recursos são utilizados os verbos do
protocolo HTTP onde os mais comuns são:
● GET - Obtém a representação de um recurso
● POST - Cria um novo recurso
● PUT - Atualiza um recurso existente
● DELETE - Apaga um recurso existente
No momento em que um sistema cliente chama o serviço web
disponibilizado é gerada uma requisição ao servidor que publica a API. A
requisição possui um cabeçalho com informações complementares como chave
de autenticação, um corpo com a informação para processamento da requisição e
parâmetros na URL que serão utilizados para identificar o recurso. Por exemplo,
caso o sistema cliente queira obter recurso com identificador único de número 1
no servidor “exemplo.api” a requisição será :
 GET - http://exemplo.api/1
Também é necessário que os recursos sejam representados por um
formato de informação onde o mais comum atualmente é o JSON.
O JSON é um padrão aberto para a troca de dados de forma simples e
rápida entre sistemas, onde o recurso é apresentado em um formato de texto
legível para os humanos e representado por um conjunto de chave e valor.
A resposta do servidor após processamento da requisição contém um
código de status que informa se o processamento aconteceu com sucesso ou se
algum erro ou redirecionamento aconteceu, os principais códigos de status são:
 200 - Sucesso
 201 - Criado
 301 - Movido permanentemente

22
 302 - Encontrado
 400 - Solicitação inválida
 404 - Não encontrado
 500 - Erro interno do servidor
No geral a implementação de todos os conceitos de REST demandam
bastante esforço e grande complexidade fazendo com que muitas vezes a
implementação não aborde todos os conceitos trazidos por esse estilo de
arquitetura.
3.3 Proposta
Aplicar os conceitos arquiteturais de micro serviços e exposição de
serviços REST em aplicações de IoT, prover uma plataforma para exposição e
roteamento de serviços e demonstrar a aplicação da arquitetura distribuída em
IoT.
3.4 Arquitetura
Cada um dos três módulos do sistema será composto por uma arquitetura
diferente compondo ao final a solução completa do provedor de serviços para
internet das coisas.
3.4.1 Módulo de provedores de serviços
Será considerado um nó todo componente que estiver expondo uma API
de modo que se o mesmo componente expuser mais de uma API este será
compreendido como mais de um nó no sistema.
Para correto funcionamento da integração com os demais módulos do
projeto é necessário que os nós proporcionem uma API que implementam
corretamente o verbo GET ou PUT do protocolo HTTP.
Para o método GET este deverá representar exclusivamente um único
recurso provendo uma resposta referente a medições, e para o verbo PUT este
deve esperar um corpo na requisição ou um parâmetro representando a mudança

23
de estado. A Figura 1 demonstra o modelo utilizado para este módulo com os
verbos do protocolo HTTP e um nó do sistema.
Figura 1- Módulo provedor de serviços
Para o teste de conceito será utilizado um dos modelos do produto
Arduino, sendo este uma plataforma de prototipagem eletrônica junto a sensores
que irão captar as informações para exposição dos serviços. Para criação dos
serviços será utilizada a biblioteca open-source aREST que possibilita a criação
de web services RESTful com facilidade em um ambiente com baixo poder de
processamento.
3.4.2 Módulo de roteamento de serviços
O módulo para roteamento de serviços foi criado utilizando a plataforma
Node JS com a finalidade de construir aplicações web escaláveis e com alto
desempenho. A linguagem básica é o JavaScript, que é uma linguagem de
programação interpretada, originalmente criada para que os navegadores
pudessem executar tarefas do lado do cliente sem a necessidade de passar pelo
servidor.
Devido a seu assincronismo, alto desempenho escrita/leitura sem
bloqueios o Node JS foi escolhido como base da aplicação. Para a parte de
persistência de dados foi utilizado o MongoDB, que é um banco de dados não
relacional baseado na persistência de objetos no formato de documentos. Essa
abordagem permite a escalabilidade e flexibilidade para a aplicação, além de
realizar a criação de índices em qualquer das buscas necessárias à aplicação.

24
A Figura 2 demonstra o modelo da arquitetura utilizada, descrevendo os
módulos e como é realizada a integração.
Figura 2- Serviço de roteamento
O módulo de roteamento irá expor uma API com as seguintes
funcionalidades:
● Criar um novo serviço - Necessário informar o nome do serviço, o
método que este será chamado (GET ou PUT) e as URIs dos serviços
que esse serviço representa, como por exemplo se este serviço
realizar a leitura de um sensor de corrente este deverá expor uma API
que será cadastrada no serviço “LeitorCorrente”. Porém é possível
informar mais uma API para esse serviço garantindo a confiabilidade
da informação caso o primeiro venha a apresentar algum problema,
servindo como um backup para o serviço.
Quadro 1- Disposição dos serviços
Verbo Nome APIs
GET LeitorCorrente 1- http://api.teste/
2- http://leitor.teste/

25
● Realizar o roteamento para o serviço - Com o nome do serviço será
chamado o serviço de roteamento onde este irá buscar as APIs
cadastradas no serviço e de forma ordenada por cadastro irá
requisitar as informações até que uma delas responda. Caso a
primeira API venha a falhar a segunda API irá ser requisitada,
seguindo esse processo até que todas tenham sido verificadas ou um
resultado válido encontrado. No caso de um resultado válido ser
encontrado este será armazenado no documento do serviço
poupando uma nova busca nas APIs em um momento não
necessário. O período em que será retornado o valor em memória
será parametrizado por uma configuração no código possibilitando
sua alteração no momento de inicialização do sistema.
● Buscar serviços cadastrados - Será retornada a lista com todos os
serviços cadastrados no módulo de roteamento. No caso do serviço
cadastrado estar relacionado com o verbo GET, será retornado o
primeiro valor válido encontrado nas APIs relacionadas ao serviço.
Como forma de verificação destas será esperada pelo código 200 na
resposta do nó. Caso a resposta seja diferente, a próxima API será
chamada até que um resultado válido seja encontrado ou que todas
APIs sejam consultadas com erro, em caso positivo será retornada á
resposta do serviço com o status 200 e em caso de erro será
retornado o status 500. Se o serviço estiver relacionado com o verbo
PUT o conteúdo enviado na requisição será aplicado para todas as
APIs cadastradas no serviço onde caso todas processem com
sucesso o código 200 será retornado e em caso de erro em qualquer
um dos serviços será retornado o código 500.
● Realizar a chamada periódica de serviços onde esse módulo fica
externo ao servidor do módulo de roteamento e tem como objetivo
proporcionar testes integrados de solução.

26
3.4.3 Módulo de exposição de serviços
Este componente será a parte de integrações gráficas com o usuário
provendo maneiras de este interagir com o módulo de roteamento de serviços.
Para construção das telas serão utilizados os dados providos pela API do módulo
de roteamento e estas serão construídas utilizando o framework React construído
com JavaScript, visando a composição de componententes isolados e
reutilizáveis.
Este módulo visa apenas a apresentação dos dados onde a API do
módulo de roteamento pode ser consumida por qualquer cliente HTTP. Foram
criadas quatro páginas para esse módulo sendo:
● Apresentação - Breve descrição do projeto
● Serviço - Lista de todos os serviços disponíveis
● Colaboradores - Colaboradores do projeto
● Repositórios - Lista dos repositórios dos módulos
3.4.4 Produto
A composição completa dos sistemas e seu funcionamento são
demonstrados na Figura 3 junto com uma descrição isolada de cada módulo:

27
Figura 3- Disposição dos módulos do sistema
O módulo de exposição de serviços tem a função de permitir a busca de
serviços cadastrados para efetuar as requisições. Será composta por uma
interface gráfica amigável onde será possível visualizar os direcionamentos e
respostas dos nós comprovando a tese de serviços escaláveis para IoT. Seu
servidor será simples e monolítico onde irá consumir WS REST provido pelo
servidor do módulo de roteamento.
O módulo de roteamento, construído em Node JS com foco em
escalabilidade irá funcionar como um servidor de rotas onde irá expor um WS
genérico que ao receber uma requisição irá chamar o nó necessário após
consultar a instancia do MongoDB e verificar se a rota que está sendo chamada
não possui um valor em cache.
O cliente irá efetuar requisições as rotas cadastradas após verificar
no módulo de exposição os serviços ativos.
O módulo provedor de serviço é composto por várias APIs publicadas
pelos dispositivos de IoT que formam as rotas cadastradas no módulo de
roteamento, sendo chamadas se não existirem valores em cache válido para a
rota.

28
3.5 Integração contínua
Nos projetos atuais é de deveras importância garantir que seu código
esteja sempre funcionando corretamente e que seus testes estejam sendo
executados com sucesso, além de diversos processos de automatização e
compatibilidade visando à qualidade do produto que está sendo entregue.
Devido a problemas comuns, surgiram no mercado soluções de
integração contínuas que permitem às equipes realizar as mais diversas pipelines
nos mais diversificados projetos. Como critério de qualidade foi realizada a
configuração para todos os repositórios onde após qualquer alteração no
repositório uma bateria de testes seja executada e em caso de problemas os
desenvolvedores dos projetos serão notificados.
Foi realizada a integração com o Travis CI, uma poderosa ferramenta de
integração contínua com uma enorme facilidade de criação e integração com o
Github, sendo disponibilizada de forma online como serviço e gratuita para
projetos abertos a comunidade.
3.6 Virtualização
Para prover um desenvolvimento seguro e facilidade de implantação os
módulos de roteamento e exposição de serviços estão utilizando a tecnologia de
virtualização por container por parte do Docker, que é uma ferramenta de código
aberto para a criação e administração de ambientes isolados chamados
containers, sendo esses criados com base de uma imagem referente a um serviço
com suas dependências ou um sistema operacional.
Todos os componentes do projeto possuem um arquivo chamado “docker-
compose.yml” descrevendo as necessidades de ambiente em forma de um roteiro
simples onde são especificadas a imagem básica para execução do container,
seus comandos para iniciar do projeto e suas demais dependências ,assim para
realizar a execução desses projetos basta possuir o Docker e o Docker Compose
instalados na máquina que realizará a execução e aplicar os comandos “docker-
compose build” e “docker-compose up”. A grande importância de se utilizar a
virtualização é a facilidade em reprodução dos ambientes de forma seguras em

29
diferentes servidores, além de serviços publicados pelas grandes empresas
mantenedoras de serviços em nuvem que baseadas em um container conseguem
prover escalabilidade e fácil gerenciamento.
3.7 Materiais
Serão listados os materiais utilizados para a geração de resultados e
criação dos sistemas que irão compor a solução.
3.7.1 Módulo de provedores de serviço
Para o módulo do provedor de serviços todo dispositivo capaz de publicar
uma interface HTTP junto à camada REST é um serviço elegível a ser utilizado
pelo módulo de roteamento. O modelo do dispositivo que irá gerar a interface não
afeta o sistema onde os únicos requisitos são que os nós proporcionem uma API
que implementa corretamente o verbo GET ou PUT do protocolo HTTP.
Para o método GET este deverá representar exclusivamente um único
recurso provendo resposta referente a medições, e para o verbo PUT este deve
esperar um corpo na requisição ou um parâmetro representando a mudança de
estado.
3.7.2 Teste de conceito
Para o teste de conceito foram utilizados os seguintes dispositivos e
componentes:
● Micro controlador: Foi utilizado um Arduino Uno (Figura 4), que é
composto por um ATMega 328, com o objetivo de publicar serviços por
meio de APIs.

30
Figura 4- Arduino uno
● Sensor de chuva: Tem como objetivo funcionar como o provedor de
informações a serem interpretados pela API e consumidos por
requisições externas.
Figura 5- Sensor de chuva
● Ethernet shield- Necessária ao sistema para prover a troca de
informações utilizando o protocolo HTTP.
Figura 6- Ethernet shield para Arduino
● Servidor para comunicação serial com o Arduino.
● Biblioteca aREST para exposição da camada da API sendo integrada
ao firmware do microcontrolador do Arduino.
● Cliente HTTP: Para realização das requisições foi utilizado à
ferramenta Postman que possui uma versão grátis e proporciona um
ambiente completo para verificação de desempenho e tráfego da
rede.

31
● LRD: Para montar uma banca de sensores foram utilizados resistores
dependentes de luz devido ao seu baixo preço e facilidade em variar
sua leitura.
● LED: Para representar a mudança de estado foram utilizados alguns
LEDs devido à rápida transição entre seus estados de ligado e
desligado.
3.7.3 Módulo de roteamento
Para o módulo de roteamento é necessário apenas um servidor que pode
ser local ou remoto com o Docker instalado e conexão ativa com a internet. Todo
o restante das configurações e instalação de componentes necessários está
abstraído pelo Docker tornando a execução simples.
Para a execução do módulo de chamadas periódicas é necessário a
instalação do Python 3 no servidor.
3.7.4 Módulo de apresentação
É necessária a instalação do Docker para a execução do módulo de
apresentação e a prévia inicialização do módulo de roteamento, pois para a
correta renderização das telas o módulo de apresentação irá consumir serviços
publicados pelo módulo de roteamento.

32
4 MÉTODO
Todo desenvolvimento do projeto será mantido na plataforma GitHub no
repositório ThingProvider (https://github.com/kevinmmartins/ThingProvider)
utilizando o modelo Kanban para controle de tarefas junto às tarefas que devem
ser desenvolvidas e marcos de versão referentes ao andamento do projeto.
As figuras 7 e 8 representam as tarefas demonstrando sua lista e a
descrição unitária do que deve ser desenvolvido respectivamente.
Figura 7- Disposição das tarefas
Figura 8- Descrição da tarefa

33
A Figura 9 representa o modelo do Kanban aplicado às tarefas,
dividindo estas em colunas referentes ao estágio da tarefa.
Figura 9- Disposição das tarefas no modelo Kanban
Problemas encontrados durante o projeto devem ser abertos como tarefas
de erros e serão tratados ao final do desenvolvimento dos módulos do projeto
para que seu impacto no cronograma seja pequeno.
Para análise dos resultados será verificada a quantidade de requisições
que um nó irá suportar demonstrando a correta abordagem no compartilhamento
de serviços. Também serão gerados casos onde uma API esteja indisponível e
que o restante do sistema não seja afetado para demonstrar uma das vantagens
da aplicação dos conceitos nos micro serviços em IoT. Para demonstrar o sistema
por completo de maneira integrada, o módulo de chamadas periódicas irá realizar
requisições ao módulo de roteamento com o objetivo de buscar por informações e
atuar sobre elas.
Para verificação do módulo de interface com o usuário junto à aplicação
será demonstrado que este consegue descobrir novos serviços e demonstra-las
em tela.
Para a etapa de verificação, os resultados serão divididos em duas partes
sendo os primeiros testes unitários, validando os módulos da aplicação e os
segundos testes integrados.

34
5 RESULTADOS
5.1 Testes unitários do módulo provedor de serviços
Para os testes do módulo provedor de serviços foram publicados serviços
simples e unitários.
5.1.1 Nós associados a um sensor de chuva e um LED
Foram criados dois nós sensores utilizando a biblioteca aREST para a
publicação de serviços específicos visando demonstrar a legitimidade da solução
onde ambos respondem a verbos do HTTP e retornam JSON para utilização do
executor da requisição.
O primeiro sensor trabalha com o verbo GET do HTTP retornando à
requisição um JSON com os valores atuais que estão sendo lidos pelo sensor. Já
o segundo funciona como um nó atuador onde responde ao verbo PUT do HTTP
e altera o estado do LED.
5.1.2 Ambiente
Para criação do ambiente e realização dos testes foram utilizados:
● Arduino;
● Arduino Ethernet shield;
● Arduino IDE;
● SPI.h,Ethernet.h,aREST,h e avr/wdt.h biblIoTecas;
● Postman.
5.1.3 Nó sensor de chuva
Foi criado um nó sensor responsável por ler valores publicados por um
sensor de chuva e disponibilizá-los por uma API através do verbo GET do HTTP.
As Figuras 10 e 11 demonstram a disposição física do módulo.

35
Figura 10- Módulo de serviço com um sensor de chuva
Figura 11- Sensor de chuva
Foram disponibilizados dois recursos para requisição dos valores sendo:
● rainDigitalValue – Retorna o valor digital lido pelo sensor de chuva e
no ambiente local está disponível em:
http://192.168.0.10:98/rainDigitalValue. A Figura 12 demonstra a
requisição com a chamada e o retorno do servidor.

36
Figura 12- Requisição para o serviço do sensor digital de chuva
● rainAnalogicValue- Retorna o valor analógico lido pelo sensor de
chuva e no ambiente local está disponível em
http://192.168.0.10:98/rainAnalogicValue. A Figura 13 demonstra a
requisição com a chamada e o retorno do servidor.
Figura 13- Requisição para o serviço do sensor analógico de chuva
Para o recurso de valor digital é retornado o JSON ao realizar uma
requisição com GET. O quadro 2 e 3 representam o recurso retornado no formato
de JSON.

37
Quadro 2- Retorno do serviço do sensor digital de chuva
{
"rainDigitalValue": 0,
"id": "1",
"name": "rainAPI",
"hardware": "arduino",
"connected": true
}
Para o recurso de valor analógico é retornado o JSON ao realizar uma
requisição com GET.
Quadro 3- Retorno do serviço do sensor analógico de chuva
{
"rainAnalogicValue": 131,
"id": "1",
"name": "rainAPI",
"hardware": "arduino",
"connected": true
}
5.1.4 Nó atuador com LED
Para representar o verbo PUT do HTTP foi criado um nó sensor que
realiza a alteração de estado de um LED através do recurso “led” que será
utilizado na requisição. As Figuras 14 e 15 demonstram a montagem física do
módulo.

38
Figura 14- Serviço atuador ligado
Figura 15- Serviço atuador desligado
Na requisição é utilizado um parâmetro de query com os valores 1 e 0
representando os estados ligado e desligado respectivamente. Em rede local o
recuso está disponível em http://192.168.0.10:98/led. As Figuras 16 e 17
demonstram as requisições e o tempo de resposta referente à ativação e a
desativação do serviço atuador.

39
Figura 16- Requisição ligando o serviço atuador
Figura 17- Requisição desligando o serviço atuador
Para a requisição com o parâmetro 1 será retornada um JSON com a
informação do estado atual na chave “return_value” conforme disposto no quadro
4.

40
Quadro 4- Retorno da ativação do serviço atuador
{
"return_value":1,
"id":2,
"name":"ledApi",
"hardware":"arduino",
"connected":true
}
O mesmo acontece para a requisição com o parâmetro 0 conforme
disposto no quadro 5.
Quadro 5- Retorno da desativação do serviço atuador
{
"return_value":0,
"id":2,
"name":"ledApi",
"hardware":"arduino",
"connected":true
}
5.2 Testes unitários do módulo de roteamento
Para criação de testes para o módulo de roteamento foi utilizado o Mocky
que é um site que permite realizar a configuração de respostas padrão para
determinados recursos.
Para clientes HTTP foram utilizados as ferramentas Postman e SoapUI,
ambas com licença gratuita ,onde a primeira foi utilizada para as requisições e a
segunda para testes de carga.
5.2.1 Exemplo de requisição ao servidor
O nó "TestNodeInvalidSuccess" possui dois endpoints cadastrados sendo:
 "http://www.mocky.io/v2/5bddddd22" - endpoint inválido

41
 "http://www.mocky.io/v2/5bddddd22" - endpoint inválido
 "http://www.mocky.io/v2/5bb03edc3100007f00fb60ea" - endpoint
válido
O serviço cadastrado é representado pelo documento abaixo representado
pelo quadro 6.
Quadro 6- Retorno da busca pelo módulo de roteamento
{
"endpoints":[
"http://www.mocky.io/v2/5bddddd22",
"http://www.mocky.io/v2/5bb03edc3100007f00fb60ea"
],
"method":"GET",
"_id":"5bb03ef926b8ed03e0ac2618",
"name":"TestNodeInvalidAndSuccess",
"lastUpdate":"2018-09-30T17:50:44.850Z",
"value":{
"temperature":22.6,
"aquariumCicle":"ON"
}
}
Ao realizar uma requisição sobre os dados desse serviço é esperado:
● Como o primeiro endpoint está indisponível o dado deve ser buscado
no segundo endpoint;
● Com o sucesso da requisição a chave "value" precisa ser atualizada
com o valor retornado pelo serviço;
● A data da última atualização também precisa ser atualizada;
● A próxima requisição deve pegar a resposta do cache (para o cenário
de testes foi definido o tempo de uma nova busca em 10 segundos).

42
A configuração para manter os valores em memória foi configurada em 10
segundos como demonstrado na Figura 18.
Figura 18- Configuração da expiração dos valores em memória
Com a configuração correta foi realizada a primeira requisição ao servidor
como demonstrado na Figura 19, onde é possível visualizar a URL e o valor de
resposta.
Figura 19- Requisição ao serviço de roteamento
Após processamento da requisição o serviço cadastrado foi atualizado com as
novas informações utilizadas na requisição sendo agora representado com um
novo valor para a tag “lastUpdate” conforme disposto na tabela 1.

43
Tabela 1- Resposta atualizada do serviço de roteamento
{
"endpoints":[
"http://www.mocky.io/v2/5bddddd22",
"http://www.mocky.io/v2/5bb03edc3100007f00fb60ea"
],
"method":"GET",
"_id":"5bb03ef926b8ed03e0ac2618",
"name":"TestNodeInvalidAndSuccess",
"lastUpdate":"2018-09-30T18:24:27.151Z",
"value":{
"temperature":22.6,
"aquariumCicle":"ON"
}
}
Em um período menor que 10 segundos foi realizada a segunda requisição
conforme demonstrado na Figura 20.
Figura 20- Segunda requisição ao serviço de roteamento

44
Na primeira requisição onde os valores de resposta não estavam
cacheados foram necessários 1658 milissegundos para o cliente receber uma
resposta. Já na segunda com os valores válidos e cacheados foram necessários
371 milissegundos o que corresponde a uma redução de 77,63%. Com os valores
cacheados é possível escalar o módulo de serviços para que a maioria das
requisições tenham um bom desempenho e apenas a requisição com cache
inválido irá até o endpoint do serviço e buscar a informação.
5.2.2 Testes de carga
Os testes de carga foram realizados utilizando as seguintes premissas:
● Serão disparados cinco threads realizando requisições ao servidor do
módulo de roteamento;
● O teste tentará executar o máximo de requisições possível no período
de 60 segundos;
● O objetivo será verificar o tempo mínimo, máximo e médio de
resposta às requisições;
● O número total de requisições também será observado;
● Serão realizados dois cenários de testes o primeiro com o módulo de
roteamento realizando o controle das requisições simulando o

45
ambiente de produção e o segundo simulando requisições sem o
controle do módulo de roteamento;
● A configuração para manter os valores em memória foi configurada
em 10 segundos.
Com o setup completo foi realizado o primeiro cenário com o módulo de
roteamento ativo.
A Figura 21 demonstra as configurações utilizadas para o teste de carga e
os resultados obtidos após sua execução.
Figura 21- Resultados do teste de carga com o módulo de roteamento
● Tempo mínimo (milissegundos): 151
● Tempo máximo (milissegundos): 3000
● Tempo médio (milissegundos): 319,44
● Número total de requisições: 279
Após concluir o primeiro cenário o tempo para manter os valores em
memória foi alterado para 0 fazendo com que os nós sejam sempre chamados. A
Figura 22 demonstra as configurações utilizadas para o teste de carga e os
resultados obtidos após termino das requisições.

46
Figura 22- Resultados do teste de carga sem o módulo de roteamento
● Tempo mínimo (milissegundos): 1244
● Tempo máximo (milissegundos): 2644
● Tempo médio (milissegundos): 1371,15
● Número total de requisições: 139
A discrepância entre os cenários é enorme onde, o cenário 1 se mostra
mais eficiente. O tempo médio entre as requisições do cenário um foram 76,71 %
menores comparadas com o cenário 2, onde o número de requisições foi 50,18 %
maiores. Com esses resultados é possível demonstrar que o módulo de
roteamento consegue prover uma forma mais eficiente de se realizar a coleta de
informação dos nós em um ambiente controlado, porém com a presença de
serviços mais complexos onde a busca das informações ou a alteração de
estados necessitarem de maiores tempos de processamentos esses resultados
podem não apresentar uma discrepância tão grande. O Gráfico 1 demonstra os
resultados obtidos em forma de comparativo.

47
Gráfico 1- Comparativo do teste de carga entre o módulo de roteamento ativo e
um cenário convencional
Como o módulo de roteamento realiza a chamada às APIs cadastradas nos
serviços, caso a API esteja construída de uma maneira em que apresente baixo
desempenho é recomendável que o tempo em que as respostas serão mantidas
em memória seja maior, garantindo assim um melhor desempenho nas próximas
requisições. Também recomenda-se sempre manter no cadastro a API com
melhor desempenho como primeira opção. Assim as demais serão consumidas
apenas em um cenário de erro. Para os cenários de alta latência de rede e
requisições concorrentes é recomendado um maior tempo para os valores em
memória, de modo a não causar problemas de desempenho relacionado ao
banco de dados.
5.3 Testes Integrados
Para a execução de testes integrados foi criado um cenário com a
disposição de dois principais serviços conforme demonstrado na Figura 23 sendo:
 Serviço para coleta de informações utilizando o verbo GET do
protocolo HTTP, composto por três APIs provindas de sensores de
luminosidade.
 Serviço de alteração de estado utilizando o verbo PUT do protocolo
HTTP composto por duas APIs provindas por diodos emissores de
luz.
0
500
1000
1500
2000
2500
3000
3500
Roteamento ativo Roteamento Invativo
Tempodasrequisiçõesemms
Estado do módulo
Tempo de resposta
Tempo mínimo (ms)
Tempo máximo (ms)
Tempo médio (ms)
Total de requisições

48
Figura 23- Serviços criados para o teste integrado
Esses serviços foram cadastrados no módulo de roteamento em três rotas
conforme demonstrado no quadro 7 sendo:
 LdrEndpoint- Composta por duas APIs referente aos sensores de
luminosidade. Essa rota foi criada com o objetivo básico de sempre
recuperar os dados da primeira API que está disposta com sucesso,
mas que em caso de erro irá buscar pela segunda API cadastrada.
Para chamada dessa rota é utilizado o verbo GET do protocolo HTTP
utilizando como parâmetro o nome da rota cadastrada.
 LdrEndpointComErro- Essa rota possui duas APIs cadastradas onde
a primeira é inválida e sempre irá retornar o status 500 do protocolo
HTTP forçando sempre a chamada da segunda API que é referente a
terceira e ultima API publicada pelos sensores de luminosidade.
Também utiliza o verbo GET do protocolo HTTP.
 AtuadorEndpoint – Composto pelas duas APIs referentes aos
serviços dos diodos emissores de luz com o objetivo de manter os
estados de ligado e desligado de ambos síncronos.

49
Para a chamada é necessário à utilização do verbo PUT do protocolo
HTTP.
Quadro 7- Rotas para o teste integrado
Nome Verbo Endpoint
LdrEndpoint GET localhost:3002/route/LDREndpoint
LdrEndpointComErro GET localhost:3002/route/LDREndpointComErro
AtuadorEndpoint PUT localhost:3002/route/
AtuadorEndpoint?params=1
Com as rotas cadastradas no módulo de roteamento foi realizada a
configuração do módulo de chamadas periódicas para a execução de dois
processos assíncronos agendados em um intervalo de tempo de 2 segundos que
realizam a chamada das duas rotas baseadas no verbo GET e com base na
resposta realizam a chamada da rota baseada no verbo PUT para alterar o estado
dos diodos emissores de luz.
A configuração para que os processos sejam concorrentes visam
demonstrar um cenário real onde requisições podem se sobrescrever. Já a
disposição das rotas nesse cenário tem como objetivo demonstrar a possibilidade
de aplicação do módulo de roteamento em um cenário de maior escala, estando
esse utilizando as duas possibilidades para o roteamento. A regra para a
alteração de estado da rota dos LEDs é uma leitura com o valor 0 a partir da
resposta de qualquer uma das duas rotas baseadas em GET.
O tempo para manter os valores de resposta em memória no módulo de
roteamento foi configurado para 5 segundos de modo a gerar situações em que
uma leitura com o valor 0 force a ativação por duas requisições em sequencia,
gerando mais alterações de estado devido ao cenário controlado em que é
possível forçar uma rota a essa situação.
No console de logs é possível verificar as chamadas das rotas, seu
retorno e o comando executado com base na regra conforme demonstrado na
Figura 24.

50
Figura 24- Logs do módulo de chamadas periódicas
Foi possível verificar o cenário completo funcionando de maneira
distribuída a partir desse teste integrado. O fato dos LEDs estarem próximos aos
sensores de luminosidade proporcionaram várias alterações de leituras e com
isso uma gama maiores de resultados pôde ser coletada. A Figura 25 representa
esse cenário ativo onde partindo da leitura de uma das rotas cadastradas foi
realizada a alteração do estado da rota do atuador.
Figura 25- Cenário ativo

51
Com base nos logs das chamadas foi gerado o Gráfico 2 que demonstra a
relação de mudanças de estados partindo da chamada das rotas, essas
alterações de estado fazem referência ao estado da rota atuador.
Gráfico 2- Alterações nas chamadas
A proximidade do número de chamadas e das alterações de estado
demonstra que em um cenário controlado o sistema cumpre com seus objetivos
de forma que mesmo em processos assíncronos as leituras e tomadas de ações
se mostra coerente junto ao tempo de valores mantidos em memória.
Demonstrar um sistema funcionando de forma distribuída em um cenário
real confirma sua possibilidade de aplicação e vantagens onde são aplicadas,
porém certamente possuem grandes débitos e dificuldades em sua
implementação, sendo o maior deles o enorme aumento de complexidade onde
suas vantagens são mais visíveis em cenários de grande escala.
0
10
20
30
40
50
60
Nº chamadas Alterações de estado
Númeroderequisições
Chamadas e alterações de estado
LdrEndpoint
LrdEndpointComErro

52
6 DISCUSSÃO
6.1 A grande necessidade da incorporação de APIs a IoT
Segundo a companhia Statista em 2025 cerca de 75 bilhões de
dispositivos irão estar conectados à Internet demonstrando o quão grande é a
projeção para o futuro da internet das coisas.
Realizar a integração entre sistemas é uma necessidade em um cenário
em que carros, cidades inteligentes, redes inteligentes e mais uma gama de
“coisas” precisam interagir e tomar decisões. APIs proveem uma especificação de
como software deve interagir de uma forma flexível, escalável e segura, podendo
interagir com o mundo físico através do protocolo HTTP e proporcionar a troca de
informações entre sistemas. Ao isolar um dispositivo de IoT da Internet, este
impede que suas leituras ou ações sejam compartilhadas com demais dispositivos
além de gerar por muitas vezes problemas na arquitetura desse projeto onde
estados são armazenamentos em memória para utilização e monólitos são
criados onde todo o sistema é dependente e cabível a uma falha única sem meios
simples de substituição e contornos de erros. A Figura 26 demonstra a
perspectiva de crescimento do numero de dispositivos conectados a Internet.

53
Figura 26- Número de dispositivos conectados a internet
A possibilidade de uma API se tornar rentável onde um valor é cobrado
para o consumo da informação também se mostra uma oportunidade para o
mundo de IoT, onde diversos dados são capturados e armazenados para
consumo de um próximo serviço. Um bom exemplo é da Candy House onde um
serviço para a geração de chaves para a abertura de portas via Wi-Fi é
disponibilizada para consumo de outros serviços, proporcionando uma maneira
simples de integração e da venda de seu produto junto ao consumo da API.
6.2 O problema com a complexidade em sistemas distribuídos
Ao arquitetar sistemas distribuídos, alguns pontos negativos precisam ser
ponderados onde a descoberta de serviços, compartilhamento de dados,
complexidade de codificação e complexidade de implantação se tornam grandes
desafios quando comparados aos sistemas monolíticos.
As vantagens referentes à escalabilidade, desempenho, falhas parciais e
estratégias em cenários de erros começam a se mostrar mais efetivas em
cenários onde à solução de mostra grande e em que o acesso aos módulos não
sejam triviais. Atualmente diversas soluções de computação em nuvem oferecem

54
serviços que facilitam a implantação de sistemas distribuídos e na utilização de
suas vantagens associadas, porém ainda nesse cenário será necessário
arquitetura a solução já pensando em como esta será implantada o que limita
algumas decisões e atrela a solução com uma infraestrutura de terceiros.
Criar sistemas distribuídos exige um maior nível de conhecimento da
equipe que está desenvolvendo, gera maiores desafios técnicos além de se mal
implementado pode gerar maiores problemas relacionados ao desempenho. É
preciso entender se a solução para determinado problema precisa dessa
abordagem, porém optar pela arquitetura monolítica apenas por facilidade é um
enorme erro que precisa ser contornado, onde distribuir um monólito é uma tarefa
bastante complexa.
No cenário apresentado nesse projeto é possível compreender as
vantagens e desafios em se aplicar uma arquitetura distribuída para IoT , onde foi
possível verificar em um teste de conceito sua vantagem. Em contraparte os
testes foram gerados sobre cenários pequenos que seriam facilmente
implementados em um monólito de maneira mais rápida e com resultados
parecidos, a complexidade que foi trazida aos cenários de testes se mostram um
grande desafio para criação do experimento.

55
7 CONCLUSÃO
Foi possível a criação de um sistema distribuído baseado em micro
serviços com o consumo de todos os módulos propostos na arquitetura do
projeto. Junto aos testes foi possível demonstrar cenários de erros e como o
módulo de roteamento propõe uma solução para não afetar todos os clientes
nesse caso, também foi possível demonstrar um melhor desempenho da solução
utilizando mecanismos de cache como demonstrado no teste de carga. Nos testes
integrados foi possível criar um cenário controlado onde foi colocado em prática a
integração com os dispositivos de IoT.
Para maior validação do sistema é necessário um teste integrado de
grande escala, utilizando dispositivos com maiores tempos de leitura, maior
tráfego em rede e APIs mais complexas. A decisão de utilizar a biblioteca aREST
para criação das APIs junto aos dispositivos de IoT não foi uma boa decisão visto
que a biblioteca não permite a criação de APIs mais complexas, não sendo
possível retornar códigos de status do protocolo HTTP diferente de 200, o que
para o cenário de testes é um problema pois as validações ocorrem em nível de
códigos de status. Em um cenário controlado para testes integrados observar as
vantagens do sistema distribuído também se tornaram complexas devido ao seu
pequeno tamanho e facilidade de implementação monolítica.
Ao final é possível concluir que os objetivos foram alcançados e a criação
de um sistema distribuído voltado a IoT é possível e garante todas as vantagens
da arquitetura distribuída em seu desenvolvimento , bem como gera necessidade
de análise em sua implementação devido as desvantagens dessa arquitetura.
Para futuro desenvolvimento será realizado a expansão do módulo de
exposição de serviços a fim de permitir ao usuário a gerência simplificada das
rotas. Também será realizada uma implantação em grande escala voltada para as
cidades inteligentes para melhor verificação dos benefícios apresentados pelos
sistemas distribuídos. Para o módulo de roteamento será criado uma camada de
autenticação e uma camada de autorização para tornar possível a venda e
controle de acessos das APIs com o objetivo de torna-las viáveis comercialmente
como venda de software como serviço.

56
8 REFERÊNCIAS
Medium- IoT is eating the world: APIs and REST. Disponível em <
https://medium.com/@AlexandraBowen/IoT-is-eating-the-world-apis-and-rest-
9e0321bc6cbf >. Acesso em 03 jun. 2018.
D Zone- REST Without JSON: The Future of IoT Protocols. Disponível em <
https://dzone.com/articles/json-http-and-the-future-of-IoT-protocols>. Acesso em
03 jun. 2018.
InforQ- Rest e internet das coisas. Disponível em <
https://www.infoq.com/br/news/2013/12/rest-IoT#>. Acesso em 03 jun. 2018.
Multi- IoT e micro serviços. Disponível em < http://www.grupomult.com.br/IoT-
comunicacao-de-dados-e-microserviços-uma-visao-integrada-para-suportar-
industria-4-0/>. Acesso em 03 jun. 2018.
aREST- Rest library to Arduino environment . Disponível em <
https://arest.io/get-started>. Acesso em 03 jun. 2018.
Spring- Spring Framework to Java applications. Disponível em <
https://spring.io/>. Acesso em 03 jun. 2018.
Java- Java language . Disponível em < https://java.com/en/download/>. Acesso
em 03 jun. 2018.
React- JavaScript library to front end development. Disponível em <
https://reactjs.org/>. Acesso em 03 jun. 2018.
Github- Online Git repository. Disponível em < https://github.com/>. Acesso em
03 jun. 2018.
Medium- O que é o Node JS. Disponível em
<https://medium.com/thdesenvolvedores/node-js-o-que-%C3%A9-por-que-usar-e-
primeiros-passos-1118f771b889>. Acesso em 10 out. 2018.
Travis CI- Integração continua para repositórios online. Disponível em
<https://travis-ci.org/>. Acesso em 10 out. 2018.
MongoDB- Banco não relacional baseado em documentos. Disponível em
<https://www.mongodb.com/>. Acesso em 10 out. 2018.
Docker Compose- Ferramenta para a criação de containers. Disponível em
<https://docs.docker.com/compose/>. Acesso em 10 out. 2018.
Node JS- JavaScript to server applications. Disponível em
<https://nodejs.org/en/>. Acesso em 10 out. 2018.
Mocky- Mocks para web. Disponível em <https://www.mocky.io/>. Acesso em 10
out. 2018.

57
SoapUI- HTTP/SOAP cliente. Disponível em <https://www.soapui.org/>. Acesso
em 10 out. 2018.
Postman – HTTP cliente. Disponível em <https://www.getpostman.com/>. Acesso
em 10 out. 2018.
Henrik Kniberg e Mattias Skarin. Kanban e Scrum Obtendo o melhor de
ambos. Disponível em < https://www.slideshare.net/fernando.palma/livro-gratuito-
scrum-x-kanban>. Acesso em 21 out. 2018.
Statista. Número de dispositivos conectados ao redor do mundo.
<https://www.statista.com/statistics/471264/IoT-number-of-connected-devices-
worldwide/>. Acesso em 22 out. 2018.
Candy House. Geração de chaves digitais. <https://docs.candyhouse.co> .
Acesso em 22 out. 2018.
Figura 4. Arduino Uno. Disponível em: <Arduino.cc/>. Acesso 21 set. 2018.
Figura 5. Sensor de chuva. Disponível em: <mercadolivre.com.br/>. Acesso 21
set. 2018.
Figura 6. Ethernet shield. Disponível em: <mercadolivre.com.br/>. Acesso 21 set.
2018.
Figura 7. Github. Disponível em:
<github.com/kevinmmartins/ThingProvider/projects/>. Acesso 21 set. 2018.
<github.com/kevinmmartins/ThingProvider/issues/>. Acesso 21 set. 2018.
<github.com/kevinmmartins/ThingProvider/projects/2 />. Acesso 21 set. 2018.
Figura 26. Candy House. Disponível em: <candyhouse.co/>. Acesso 21 set.
2018.

Monografia- ThingProvider

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Monografia- ThingProvider

Semelhante a Monografia- ThingProvider (20)

Monografia- ThingProvider