pós-graduação em ciência da computação · 2019-10-26 · winder faik de sousa . xpresumo ±...

Pós-Graduação em Ciência da Computação

WINDER FAIK DE SOUSA

XPRESUMO – UM MIDDLEWARE ORIENTADO À

MENSAGENS PARA INTERNET DAS COISAS

Universidade Federal de Pernambuco [email protected]

www.cin.ufpe.br/~posgraduacao

RECIFE

2017

Winder Faik de Sousa

xPresumo – Um Middleware Orientado à Mensagens para Internet das Coisas

ORIENTADOR(A): Prof. Nelson Souto Rosa

RECIFE

2017

Este trabalho foi apresentado à Pós-Graduação em

Ciência da Computação do Centro de Informática da

Universidade Federal de Pernambuco como requisito

parcial para obtenção do grau de Mestre Profissional

em Ciência da Computação.

Catalogação na fonte Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217

S725x Sousa, Winder Faik de xPresumo: um middleware orientado à mensagens para internet das coisas

/ Winder Faik de Sousa. – 2017. 68 f.:il., fig., tab.

Orientador: Nelson Souto Rosa. Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn,

Ciência da Computação, Recife, 2017. Inclui referências.

1. Redes de computadores. 2. Internet das coisas. I. Rosa, Nelson Souto(orientador). II. Título.

004.6 CDD (23. ed.) UFPE- MEI 2017-172

Winder Faik de Sousa

xPresumo – Um Middleware Orientado à Mensagens para Internet

das Coisas

Dissertação apresentada ao Programa de Pós-

Graduação em Ciência da Computação da

Universidade Federal de Pernambuco, como

requisito parcial para a obtenção do título de

Mestre Profissional em 30 de junho de 2017.

Aprovado em: 30/06/2017.

BANCA EXAMINADORA

__________________________________________

Prof. Paulo Romero Martins Maciel

Centro de Informática / UFPE

__________________________________________

Prof. Fernando Antônio Aires Lins

Universidade Federal Rural de Pernambuco

__________________________________________

Prof. Nelson Souto Rosa

Centro de Informática / UFPE

(Orientador)

Dedico este trabalho aos meus pais, Odahil e Zilda, que

nunca mediram esforços para que eu pudesse concretizar

meus objetivos. Cada conquista é o espelho de todo amor,

apoio e dedicação que vocês tiveram comigo. Dedico

também a minha irmã Fairuze que, mesmo longe sempre

preocupou-se comigo, sempre demonstrando carinho. Todos

vocês contribuíram para que eu pudesse chegar onde estou.

Vocês foram o meu incentivo para concluir mais esse

desafio na minha vida.

Agradecimentos

Primeiramente agradeço a Deus por possibilitar meu ingresso neste mestrado e pelacapacidade de concluir mais essa etapa na minha vida seja concluída.

A toda minha família que foram os incentivadores nessa conquista, meu pai Odahil,minha mãe Zilda e minha irmã Fairuze. Agradeço a vocês pela paciência e compreensão quetiveram comigo nos momentos ausentes.

A todo corpo docente do Centro de Informática (CIn) da Universidade Federal do Per-nambuco, por compartilharem seus conhecimentos e experiências durante as aulas contribuindode forma positiva para o enriquecimento de minha formação profissional.

Ao professor Doutor Nelson Souto Rosa, pela disponibilidade e oportunidade a mimdada. Pela sabedoria, seriedade, paciência e compreensão que sempre teve comigo no papel deorientador.

A todos os amigos da turma do Mestrado Profissional em Redes 2014, em especial aosparceiros de Goiás, Alfredo Pupak, Daniel Bernardes e Ricardo, que sempre estiveram juntosnas dificuldades enfrentas.

Ao Instituto Federal de Goiás pela oportunidade em participar do Mestrado Profissionalofertado pela Universidade Federal do Pernambuco - UFPE.

Por fim, agradeço a todos àqueles que contribuíram de alguma forma, seja ela direta ouindiretamente para a realização de mais essa etapa na minha vida.

Resumo

Ambientes que antes eram desprovidos de tecnologia, hoje incorporam inúmeros objetosinteligentes (smartphones, smartwatch, smartglass, smart tv, entre outros) interagindo entre si.A comunicação entre esses objetos, na maioria das vezes distintos, trocando informações sobredeterminado contexto, resume-se no conceito de Machine-to-Machine (M2M). A expansão dessesobjetos interconectados transformando ambientes comuns em ambientes inteligentes deu origemao paradigma de Internet das Coisas - Internet of Things (IoT). Em virtude da relação entre mundofísico e mundo virtual proporcionada pela IoT, diversas aplicações tecnológicas nos mais diversosseguimentos poderão ser concretizadas. Entretanto, muitos desafios devem ser consideradosna efetiva implantação desses recursos tecnológicos. Fatores voltados à complexidade nainfraestrutura de comunicação e gerenciamento de diversos dispositivos no contexto de IoT

(diversidade de dispositivos, tecnologias de redes distintas, entre outros), deixam evidente anecessidade de solucionar desafios como a heterogeneidade. Uma solução proposta para esse eoutros problemas no cenário de Internet das Coisas é a adoção de uma arquitetura de middleware,no caso um Middleware Orientado à Mensagens (MOM). Neste estudo, foi realizado inicialmenteum levantamento sistemático das principais soluções de middleware desenvolvidas no contextode IoT . Posteriormente, foram identificados requisitos funcionais e não funcionais, modelos dedistribuição e em quais domínios de aplicação essas soluções de middleware têm sido aplicadas.Finalmente, foi projetado um Middleware Orientado à Mensagens com características desejáveisao ambiente de IoT , tal como, serviço de localização, adaptação dinâmica, segurança e assim pordiante. A solução proposta, chamada xPresumo, reúne os principais recursos necessários à umaarquitetura de Middleware para IoT , levando em consideração desempenho e armazenamentolimitado dos dispositivos. No quesito desempenho, o xPresumo se mostrou bastante estável nosexperimentos realizados na troca de mensagens entre dispositivos.

Palavras-chave: Middleware. Internet das Coisas. Adaptação. Serviços de Middleware.

Abstract

Environments where no technology was available before incorporate nowadays severalsmart objects (smartphones, smartwatches, smartglass, smart TVs, to name but a few). Com-munication among these objects, most of the time diverse ones, that exchange information in aparticular context, may be summarized in the definition of Machine-to-Machine (M2M). Fromthe expansion of these interconnected things, where common environments are changed intosmart ones, the paradigm of Internet of Things (IoT) was born. Due to the relation between thereal and virtual worlds provided by the IoT, several technological uses, in diverse fields, may beimplemented. However, lots of challenges must be taken into consideration when effectivelyimplementing the aforementioned technological resources. Issues concerning the complexityin the communication infrastructure and management of some devices in the context of IoT(diversity of devices, different network technologies, to name but a few) put in evidence theneed for solving problems such as heterogeneity. A solution proposed for this specific issueand others as well in the scenario of IoT would be the adoption of middleware architecture, incase a Message Oriented Middleware (MOM). In this research, primarily, a systematic searchof the main solutions of middleware developed in the context of the IoT was done. Then, therequisites, both functional and non-functional, ones were identified, as well as the distributionmodels and in which domains of application these middleware solutions have been applied. Theproposed solution, named as xPresumo, comprises the main necessary resources of Middlewarearchitecture for IoT, and takes into account performance and limited storage of the devices.

Keywords: Middleware. Adaptation. Internet of Things. Middleware Services.

Lista de Figuras

2.1 Principais Domínios de Aplicações e Cenários Relevantes ATZORI; IERA;MORABITO (2010) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2 Proposições de Arquitetura para IoT (AL-FUQAHA et al. (2015)) . . . . . . . 202.3 Arquitetura de Middleware (KRAKOWIAK (2007)) . . . . . . . . . . . . . . . 202.4 Arquitetura Cliente/Servidor (PUDER; RÖMER; PILHOFER (2006)) . . . . . 212.5 Chamadas Remotas de Procedimentos . . . . . . . . . . . . . . . . . . . . . . 212.6 Arquitetura do Middleware Transacional (BERNSTEIN (1996)) . . . . . . . . 222.7 Fluxo de Transações no Middleware Transacional . . . . . . . . . . . . . . . . 232.8 Esquema de Invocação Simplificado em Middleware Orientado à Objetos (MOO) 232.9 Arquitetura de Middleware Orientado a Mensagens . . . . . . . . . . . . . . . 252.10 Modelo de Mensagem Point-to-Point . . . . . . . . . . . . . . . . . . . . . . . 252.11 Modelo de Mensagem Publish/Subscriber . . . . . . . . . . . . . . . . . . . . 252.12 Arquitetura de Middleware para Internet das Coisas . . . . . . . . . . . . . . . 262.13 Arquitetura do Middleware Presumo . . . . . . . . . . . . . . . . . . . . . . . 28

3.1 Requisitos em um Middleware para IoT (BANDYOPADHYAY et al. (2011)) . . 33

4.1 Topologia com Vários xPresumo Conectados . . . . . . . . . . . . . . . . . . 414.2 Arquitetura do Middleware xPresumo . . . . . . . . . . . . . . . . . . . . . . 414.3 Diagrama de Classe do Serviço de Localização . . . . . . . . . . . . . . . . . 434.4 Diagrama de Sequência do Serviço de Localização . . . . . . . . . . . . . . . 444.5 Diagrama de Sequência do Serviço de Descoberta . . . . . . . . . . . . . . . . 444.6 Diagrama de Classe do Serviço de Ciência de Contexto . . . . . . . . . . . . . 454.7 Diagrama de Sequência do Serviço de Ciência de Contexto . . . . . . . . . . . 454.8 Diagrama de Classe do Serviço de Segurança - Autenticação . . . . . . . . . . 464.9 Diagrama de Sequência do Serviço de Segurança - Autenticação . . . . . . . . 474.10 Diagrama de Classe do Serviço de Segurança - Criptografia . . . . . . . . . . . 474.11 Diagrama de Sequência do Serviço de Segurança - Criptografia . . . . . . . . . 484.12 Diagrama de Classe do Serviço de Gerenciamento de Eventos . . . . . . . . . . 494.13 Diagrama de Sequência do Serviço de Gerenciamento de Eventos . . . . . . . . 49

5.1 Definição do Middleware xPresumo . . . . . . . . . . . . . . . . . . . . . . . 515.2 M1 - Tempo de resposta para adaptação . . . . . . . . . . . . . . . . . . . . . 565.3 M2 - Tempo de resposta para desativar mecanismo de criptografia . . . . . . . 575.4 M3 - Tempo de resposta no recebimento de mensagens (Localização) . . . . . 575.5 M3 - Tempo de resposta no recebimento de mensagens (Descoberta) . . . . . . 59

5.6 M3 - Tempo de resposta no recebimento de mensagens (Temperatura) . . . . . 605.7 M3 - Tempo de resposta no recebimento de mensagens (Status) . . . . . . . . 60

Lista de Tabelas

3.1 Desafios no Middleware para IoT CHAQFEH; MOHAMED et al. (2012) . . . 313.2 Desafios versus Modelos de Distribuição de um Middleware para IoT (FERSI

(2015)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.3 Recursos de Middleware para IoT (BANDYOPADHYAY et al. (2011)) . . . . . 333.4 Interfaces de Middleware para IoT (BANDYOPADHYAY et al. (2011)) . . . . 333.5 Comparação entre Soluções de Middleware para IoT . . . . . . . . . . . . . . 38

5.1 Lista de Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.2 Parâmetros do Sistema e de Carga de Trabalho . . . . . . . . . . . . . . . . . . 535.3 Fatores de Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.4 M1 - Tempo de resposta para adaptação . . . . . . . . . . . . . . . . . . . . . 555.5 M2 - Tempo de resposta para desativar mecanismo de criptografia . . . . . . . 565.6 Tempo de Envio de Mensagens Criptografas e Não Criptografas (Localização) . 575.7 Taxa de Valores no Intervalo do Desvio Padrão (Localização) . . . . . . . . . . 585.8 Tempo de Envio de Mensagens Criptografas e Não Criptografas (Descoberta) . 585.9 Taxa de Valores no Intervalo do Desvio Padrão (Descoberta) . . . . . . . . . . 585.10 Tempo de Envio de Mensagens Criptografas e Não Criptografas (Temperatura) 595.11 Taxa de Valores no Intervalo do Desvio Padrão (Temperatura) . . . . . . . . . . 595.12 Tempo de Envio de Mensagens Criptografas e Não Criptografas (Status) . . . . 605.13 Taxa de Valores no Intervalo do Desvio Padrão (Status) . . . . . . . . . . . . . 61

Lista de Acrônimos

AES Advanced Encryption Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

AP Access Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

API Application Programming Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

CT Carga de Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

FIFO First-In, First-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

GPS Sistema de Posicionamento Global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

IDE Integrated Development Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

IoT Internet of Things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

JMS Java Message Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

JVM Java Virtual Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

MT Middleware Transacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

M2M Machine-to-Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

MOM Middleware Orientado à Mensagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

MOO Middleware Orientado à Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

NFC Near Field Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

NoSQL Not Only SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40

PS Parâmetros do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

QoS Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

RFID Radio-Frequency IDentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

RSSF Redes de Sensores Sem Fio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

RSSI Received Signal Strength Indicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

RPC Remote Procedure Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

SGBD Sistema de Gerenciamento de Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

SHA-2 Secure Hash Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

S.O. Sistema Operacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

SOA Service-Oriented Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

TCP Transmission Control Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

UML Unified Modelling Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Sumário

1 Introdução 141.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.2 Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.3 Limitações do Estado da Arte . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.4 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.5 Organização da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2 Conceitos Básicos 182.1 Internet das Coisas - IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2 Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2.1 Middleware Procedural - RPC . . . . . . . . . . . . . . . . . . . . . . . . . . 212.2.2 Middleware Transacional - MT . . . . . . . . . . . . . . . . . . . . . . . . . . 222.2.3 Middleware Orientado a Objeto - MOO . . . . . . . . . . . . . . . . . . . . . 232.2.4 Middleware Orientado a Mensagens - MOM . . . . . . . . . . . . . . . . . . . 242.3 Middleware para IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.4 Middleware Presumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.5 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3 Trabalhos Relacionados 303.1 Soluções de Middleware para Internet das Coisas . . . . . . . . . . . . . . . . 303.1.1 Middleware Baseado em Eventos . . . . . . . . . . . . . . . . . . . . . . . . . 343.1.2 Middleware Baseado em Agentes . . . . . . . . . . . . . . . . . . . . . . . . . 353.1.3 Middleware Orientado à Serviços . . . . . . . . . . . . . . . . . . . . . . . . . 363.1.4 Middleware Orientado a Banco de Dados . . . . . . . . . . . . . . . . . . . . 373.2 Sumário de Comparações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.3 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4 Middleware xPresumo 394.1 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.2 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.3 Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.3.1 Localização e Descoberta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.3.2 Ciência de Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.3.3 Segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.3.4 Gerenciamento de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.4 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.5 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5 Avaliação Experimental 515.1 Definição do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.2 Lista de Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.3 Métricas de Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.4 Lista de Parâmetros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.5 Fatores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.6 Seleção da Carga de Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.7 Planejamento dos Experimentos . . . . . . . . . . . . . . . . . . . . . . . . . 545.8 Interpretação dos Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.9 Apresentação dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.10 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6 Conclusão 626.1 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626.2 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Referências 65

141414

1Introdução

O conceito de Internet das Coisas, ou Internet of Things (IoT), não é algo novo KRAMP;KRANENBURG; LANGE (2013). O paradigma de Internet das Coisas assume que objetoscomuns, dispondo de um mínimo de “inteligência” computacional, tenham a capacidade deinteragir entre si ou mesmo com usuários finais por meio de uma rede provendo algum tipo deserviço.

Com foco na interação entre dispositivos distintos, um dos desafios em IoT é a inte-roperabilidade entre aplicações implantadas em ambientes extremamente heterogêneos MIO-RANDI et al. (2012). Uma possível solução para este cenário, consiste na implantação deuma plataforma de middleware, proporcionando assim abstração às aplicações dos dispositivosBANDYOPADHYAY et al. (2011).

Ressaltam-se que os desafios em IoT vão além da heterogeneidade, segundo CHAQFEH;MOHAMED et al. (2012) estes são: interoperabilidade, escalabilidade, provisionamento deabstração, interação espontânea, descoberta e gerenciamento de dispositivos, ciência de contexto,adaptação, segurança e privacidade. Diante de tais desafios, esforços tem sido realizados nodesenvolvimento de sistemas de middleware mais robustos capazes de minimizarem ou mesmosolucionarem tais problemas voltados ao contexto de IoT .

1.1 Motivação

Atualmente, percebe-se uma grande presença de coisas inteligentes conectadas nos maisdiversos ambientes. Além da quantidade de dispositivos conectados, a diversidade destes dispo-sitivos resulta em um nível de complexidade muito alto no que diz respeito ao desenvolvimentode aplicações distribuídas.

Com foco na interação entre objetos distintos e para possibilitar a interoperabilidadeentre inúmeros dispositivos envolvidos em ambientes extremamente heterogêneo MIORANDIet al. (2012), uma possível solução para demanda de IoT é o desenvolvimento de uma plataformade middleware, proporcionando assim abstração a nível de aplicação e de hardware, além dofornecimento de múltiplos serviços BANDYOPADHYAY et al. (2011).

1.2. PROBLEMA 15

Na literatura, encontram-se diversas soluções de middleware já propostas. Devido acomplexidade no desenvolvimento para IoT muitas delas resumem-se em proposições teóricassobre "o que um middleware para IoT deve possuir, suas características e recursos"FERSI(2015), ATZORI; IERA; MORABITO (2010). Em outras situações, uma solução de middleware

foi efetivamente desenvolvida EISENHAUER; ROSENGREN; ANTOLIN (2010), SOUSA;GARLAN (2002) voltada à um domínio de aplicação específico de IoT (Transporte e Logítica,Casas Inteligentes, Cidades Inteligentes, entre outros) (KRAMP; KRANENBURG; LANGE(2013)).

A interação entre coisas distintas em IoT é algo comum. Essa relação favorece osurgimento de ambientes onde dispositivos pertencentes a domínios de aplicação distintos (multi-domínios) coexistam. Dessa forma, a diversidade de domínios tem impacto significativo nacomplexidade envolvida no desenvolvimento de soluções de middleware e de aplicações capazesde gerenciar as solicitações dentro deste contexto.

As soluções de middleware voltadas para ambientes multi-domínios buscam solucionarboa parte dos problemas relacionados à heterogeneidade. Ao mesmo tempo, elas acabam porexigir muito dos recursos dos dispositivos (tais como, memória, processamento, bateria, assimpor diante), inviabilizando o uso de dispositivos com recursos computacionais limitados.

Em um cenário onde tudo está conectado, independente do poder computacional dodispositivo, nota-se a necessidade no desenvolvimento de uma arquitetura de middleware paraIoT multi-domínio, robusta e otimizada, capaz de absorver o máximo da complexidade possíveldas aplicações distribuídas envolvidas.

1.2 Problema

O termo middleware refere-se à uma infraestrutura de software que possibilita a imple-mentação de sistemas colaborativos FUKS et al. (2012), fornecendo um conjunto de abstraçõesde programação, a fim de facilitar a integração e a comunicação de componentes heterogêneosFERSI (2015).

Além de resolver os problemas de heterogeneidade (tais como, software, hardware,tecnologias de redes e linguagens de programação), uma solução de middleware fornece umapadronização no desenvolvimento de aplicações e de sistemas distribuídos COULOURIS et al.(2011).

Em suma, uma solução de middleware absorve as complexidades existentes em ambientesdistribuídos, facilitando o desenvolvimento de aplicações nesse contexto. Entretanto, pode-seobservar que há uma contínua busca por um padrão de middleware que seja capaz de extinguirtodas as complexidades envolvidas no paradigma de IoT .

Normalmente os cenários de IoT são formados por diversas tecnologias interagindo entresi. Essa heterogeneidade somada à capacidade limitada de hardware dos dispositivos, dificultamuito o desenvolvimento de sistemas de middleware para Internet das Coisas.

1.3. LIMITAÇÕES DO ESTADO DA ARTE 16

Desse modo, constata-se a necessidade no desenvolvimento de uma arquitetura deMiddleware para IoT que seja capaz de tratar todos os desafios no paradigma de Internet dasCoisas independente do domínio de aplicação.

1.3 Limitações do Estado da Arte

Como mencionado por FERSI (2015), as propostas de Middleware para Internet dasCoisas devem tratar os desafios provenientes do contexto de IoT . A busca pelo desenvolvimentode soluções capazes de absorverem as particularidades em ambientes ubíquos originou-se com oadvento das Redes de Sensores e são muito similares na Internet das Coisas.

Baseando-se nas afirmações apontadas por BANDYOPADHYAY et al. (2011) e CHAQ-FEH; MOHAMED et al. (2012), as muitas arquiteturas de middleware desenvolvidas não sãocapazes de cumprir o conjunto de exigências impostas no cenário de IoT .

Considerada em muitos estudos como uma arquitetura de middleware promissora nocontexto de IoT , a Hydra EISENHAUER; ROSENGREN; ANTOLIN (2010) atende em parte osdesafios apresentados na Seção 1. Entretanto, devido ao uso de virtualização na implementaçãoda solução de segurança e privacidade, ataques do tipo side-channel attack podem ser umapreocupação RAZZAQUE et al. (2016). Esse tipo de ataque procura explorar vulnerabilidadesno algoritmo criptográfico por meio de informações físicas mensuráveis como tempo, energiaconsumida e radiação eletromagnética dos dispositivos.

O Middleware TinyDB foi uma das primeiras soluções desenvolvidas com a capacidade deabstração de dispositivos, ou seja, a possibilidade de cooperação entre dispositivos distintos. Umdos pontos negativos da solução está na falta de abstração de sistemas, ou seja, seu funcionamentodepende exclusivamente da utilização do Sistema Operacional (S.O.) TinyOS (MADDEN et al.(2005)).

A solução apresentada em NAGY et al. (2009) é o resultado da proposição de um modelosemântico inteligente para Internet das Coisas. Mesmo com os diversos recursos disponíveis naarquitetura, os desafios voltados à interoperabilidade e segurança não são solucionados comopode ser visto em BANDYOPADHYAY et al. (2011).

São muitas as arquiteturas desenvolvidas para o contexto de IoT , mas como observado,nenhuma delas têm capacidade de absorver a complexidade envolvida nestes cenários. Cadadomínio de aplicação possui suas particularidades e o desenvolvimento de uma arquitetura únicacapaz de abranger todos esses atributos ainda não foi concretizada.

Além das dificuldades mencionadas anteriormente, muitos problemas em IoT perma-necem em aberto de acordo com CHAQFEH; MOHAMED et al. (2012). Questões comoa padronização de arquitetura, provisionamento de interface para o usuário, capacidade dearmazenamento, segurança e privacidade, ainda são desafios que merecem atenção.

1.4. OBJETIVO 17

1.4 Objetivo

Conforme já mencionado, há inúmeros projetos de Middleware para IoT, porém nãoexiste uma padronização única a ser seguida dentro de um domínio específico no desenvolvimentodessas arquiteturas. As características de cada solução normalmente seguem um padrão própriode desenvolvimento, com os requisitos funcionais e não funcionais que acreditam ser necessáriasao contexto de IoT.

O principal objetivo dessa dissertação é o desenvolvimento de uma arquitetura de Mid-

dleware Orientado à Mensagens para Internet das Coisas com capacidade de adaptação. Paraconcretizar esse objetivo foi realizado um estudo sistemático do atual contexto de soluções deMiddleware para Internet das Coisas serão identificadas as características essenciais ao desenvol-vimento de um Middleware para IoT (tal como, padronização, arquitetura, requisitos funcionaise não funcionais).

Identificadas as características desejáveis de um Middleware para o cenário de Internetdas Coisas, será então desenvolvida uma solução de middleware capaz de atender as característi-cas próprias de IoT .

O Middleware para IoT a ser desenvolvido será intitulado de xPresumo. O xPresumo

será uma extensão do Presumo (PRESUMO (2016)), um Middleware Orientado à Mensagens(MOM) leve, desenvolvido utilizando a Application Programming Interface (API) Java Message

Service (JMS).

1.5 Organização da Dissertação

O presente trabalho está organizado da seguinte forma:

Capítulo 2 apresenta os conceitos necessários ao entendimento desse estudo. Serãoabordados conceitos relativos à Internet das Coisas, Middleware, Arquiteturas de SoftwareDistribuídos, entre outros assuntos pertinentes ao tema em questão.

Capítulo 3 descreve a plataforma xPresumo. Para isto, o capítulo apresentará os requisitos,a arquitetura, o projeto e a implementação.

Capítulo 4 apresenta a metodologia de experimentação e os resultados obtidos na avalia-ção de desempenho realizada no Middleware xPresumo.

Capítulo 5 descreve soluções de middleware para Internet das Coisas encontradas atu-almente na literatura. São identificados os principais requisitos dessas plataformas para umaposterior comparação com a solução desenvolvida xPresumo.

Capítulo 6 apresenta os desafios enfrentados no desenvolvimento do middleware proposto,as contribuições da dissertação e os trabalhos futuros.

181818

2Conceitos Básicos

Neste capítulo, introduziremos os principais conceitos necessárias ao entendimento doMiddleware xPresumo. Será apresentado um resumo sobre diversos assuntos de relação diretacom o desenvolvimento e aplicabilidade do xPresumo, tais como Middleware, Internet das Coisas,Sistemas Distribuídos, e as características gerais do Presumo.

2.1 Internet das Coisas - IoT

O conceito de Internet das Coisas, resume-se em diversas "coisas"ou objetos (tags Radio-

Frequency IDentification (RFID), NFC, sensores, atuadores, entre outros) dotados de um mínimode recursos computacionais, interagindo entre si Machine-to-Machine (M2M) ou com usuáriosdo sistema, de modo a executar um objetivo definido TAN; KOO (2014).

O RFID é uma tecnologia de comunicação de curto alcance em que etiquetas/tags secomunicam com um leitor de RFID através de campos eletromagnéticos de radiofrequência.Essas etiquetas garantem que objetos rastreados com tags RFID tenham identidades individuaisno IoT . Outra tecnologia muito comum no cenário de IoT , é o Near Field Communication (NFC).O NFC é um padrão de comunicação de curto alcance em que os dispositivos podem se comunicarpor sinais de rádio, quando tocados ou mesmo quando são aproximados um do outro.

Os sensores são dispositivos que monitoram as características do ambiente ou de outrosobjetos, como temperatura, umidade, movimento e quantidade. Quando vários sensores sãousados juntos e interagem, eles formam uma Redes de Sensores Sem Fio (RSSF). Ressalta-seque a interação entre diferentes tecnologias originou-se por meio das RSSF, que posteriormentevenho a contribuir para o surgimento do paradigma de IoT MAINETTI; PATRONO; VILEI(2011). Enquanto os sensores têm ciência do estado de um determinado ambiente ou objeto, osatuadores executam ações para afetar de algum modo o meio ambiente ou objeto. Os atuadorestem interação direta com o mundo físico (WHITMORE; AGARWAL; DA XU (2014)).

A infra-estrutura da Internet não tende a desaparecer devido o contexto de IoT . Pelocontrário, sua importância será ainda mais evidente, exercendo a função de espinha dorsal paracompartilhamento e difusão de informações de modo global, interligando objetos físicos com

2.1. INTERNET DAS COISAS - IOT 19

recursos de computacionais em uma ampla gama de serviços e tecnologias ATZORI; IERA;MORABITO (2010).

Segundo ATZORI; IERA; MORABITO (2010), a Internet das Coisas vem ganhandoespaço em diversas áreas, estando presente nos mais diversos domínios (transporte e logística,saúde, ambiente inteligente, entre outros) (Figura 2.1). Devido à essa expansão, a IoT acaba porreunir um conjunto de desafios que tende a variar conforme a complexidade de cada seguimento.Dentre estes desafios em um contexto geral, podemos citar: abstração de tecnologias, segurança,escalabilidade, heterogeneidade e Quality of Service (QoS). Desafios estes que ainda preocupame são focos de diversos estudos PANDYA; CHAMPANERIA (2015).

Figura 2.1 Principais Domínios de Aplicações e Cenários Relevantes ATZORI; IERA; MORABITO(2010)

No intuito de enfrentar os desafios existentes em Internet das Coisas, diversos estudospropõem que a adoção de uma arquitetura dividida em camadas (Figura 2.2) seria a melhoralternativa. No entanto, nenhuma das propostas apresentadas até então evoluiu para um modelode referência KRcO; POKRIc; CARREZ (2014). Os principais modelos de arquitetura presentesatualmente na literatura são: a) Baseado em três camadas (Camadas de Aplicação, Rede eConhecimento); b) Baseado em Middleware; c) Baseado em Service-Oriented Architecture(SOA) e; d) Baseado em cinco camadas (Camada de Negócios, Aplicação, Gerenciamento deServiços, Abstração de Objetos e Objetos) AL-FUQAHA et al. (2015).

Ainda que não exista um modelo de referência para uma arquitetura de IoT , as soluçõescompostas por uma camada de middleware demonstram ser uma estrutura promissora na tratativados desafios em Internet das Coisas. Neste sentido, muitas arquiteturas de middleware paraIoT têm sido desenvolvidas, buscando integrar ao máximo os diversos domínios de aplicaçãoexistentes em Internet das Coisas.

2.2. MIDDLEWARE 20

Figura 2.2 Proposições de Arquitetura para IoT (AL-FUQAHA et al. (2015))

2.2 Middleware

O middleware (Figura 2.3) é uma camada de software posicionada entre o sistemaoperacional (S.O.) e as aplicações distribuídas. As aplicações distribuídas são componenteslógicos localizados em dispositivos interligados que se comunicam e coordenam suas açõesapenas por mensagens (COULOURIS et al. (2011)).

Em termos de funcionalidade, uma arquitetura de middleware pode ser definida comosendo um software capaz de abstrair ao máximo a complexidade existente no desenvolvimento eexecução de sistemas em ambientes distribuídos (FUKS et al. (2012)). Conforme COULOURISet al. (2011), a tarefa do middleware é fornecer uma abstração de programação para o desenvol-vimento de sistemas distribuídos e, por meio de camadas lógicas, abstrair a heterogeneidade dainfraestrutura subjacente para promover a interoperabilidade e a portabilidade.

Figura 2.3 Arquitetura de Middleware (KRAKOWIAK (2007))

O middleware também tem fundamental importância no controle de processos em com-putadores diferentes, oferecendo suporte à localização e nomeação de recursos distribuídoscontrolando a consistência dos dados distribuídos FUKS et al. (2012). Existem diversas pla-taformas de middleware e estes podem ser classificados segundo suas primitivas de interação.Ressalta-se a existência de plataformas híbridas que, são soluções com suporte a recursos nãoexclusivos de uma única arquitetura (COULOURIS et al. (2011)).

Segundo FUKS et al. (2012), as principais categorias de middleware conforme suas primi-tivas de comunicação são: Middleware Procedural, Middleware Transacional (MT), Middleware

2.2. MIDDLEWARE 21

Orientado à Objetos (MOO), e MOM.

2.2.1 Middleware Procedural - RPC

O Middleware Procedural baseia-se no modelo cliente/servidor (Figura 2.4) e tem comoprimitiva as chamadas de procedimento remoto Remote Procedure Call (RPC) (FUKS et al.(2012)). O modelo RPC é um conceito fundamental de computação distribuída e teve como baseas chamadas a procedimentos existentes em linguagens de programação procedurais.

Figura 2.4 Arquitetura Cliente/Servidor (PUDER; RÖMER; PILHOFER (2006))

O objetivo no RPC é permitir a comunicação entre dois processos, sejam estes locaisou remotos (CURRY (2004)). Essa comunicação normalmente é realizada de forma síncrona,onde o cliente permanece bloqueado à espera da resposta do servidor, comumente chamado deprotocolo requisição/resposta (request/reply ou request/wait for replay) (COULOURIS et al.(2011)). A Figura 2.5 ilustra o fluxo de uma chamada remota de procedimento.

Figura 2.5 Chamadas Remotas de Procedimentos

Uma vantagem observada no Middleware Procedural é a capacidade de lidar com aheterogeneidade existente entre clientes. A cada chamada de procedimento, o middleware tem aresponsabilidade de converter os dados de modo a torná-los inteligíveis entre plataformas. Esseprocesso ocorre em duas etapas: 1) serialização (marshalling), quando os dados são convertidospara que possam ser enviados e; 2) desserialização (unmarhalling), onde os dados recebidos sãoconvertidos na estrutura de dados originais (FUKS et al. (2012)). Esse processo, possibilita deforma transparente, a interação remota entre aplicativos distintos.

2.2. MIDDLEWARE 22

Como pode ser observado, o Middleware Procedural oculta aspectos importantes dadistribuição, incluindo a codificação e a decodificação de parâmetros e resultados, a passagem demensagens e a preservação da semântica exigida para a chamada de procedimento (COULOURISet al. (2011)). Porém, esse tipo de arquitetura não suporta escalabilidade, confiabilidade einvocações assíncronas (JINGYONG et al. (2009)).

2.2.2 Middleware Transacional - MT

O Middleware Transacional ou monitores de transação pode simplificar a construçãode sistemas distribuídos. A arquitetura do MT (Figura 2.6) é projetada para suportar transa-ções distribuídas de modo síncrono ou assíncrono, além de fornecer suporte à coordenação esincronização nas solicitações entre clientes e servidores PINUS (2004).

Figura 2.6 Arquitetura do Middleware Transacional (BERNSTEIN (1996))

A primitiva de interação do Middleware Transacional, envolve a combinação de RPCassociada a um controle de transação que implementa o protocolo two phase commit (2PC), ouseja, as transações são realizadas em duas fases. Na primeira fase assegura-se a disponibilidade derecursos necessários para a concretizar a transação. Na segunda fase, são executados comandosnecessários para efetivação da transação. Caso alguma das bases distribuídas não consiga realizaruma das fases, a transação não é efetivada (FUKS et al. (2012)).

O MT tem suporte à heterogeneidade em diferentes níveis (software/hardware). Isso podeser observado na capacidade de gerenciamento de transações entre Sistema de Gerenciamento deBanco de Dados (SGBD) distintos. Entretanto, o MT não suporta muito bem a heterogeneidadede dados, porque não pode expressar estruturas de dados complexas e, portanto, não podeorganizar essas estruturas PINUS (2004). A Figura 2.7 ilustra o processo de comunicaçãorealizado através do Middleware Transacional.

Uma vantagem da arquitetura transacional é no fato de ser implementar o conjuntode propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade). Porém noquesito desempenho, o uso inadequado de transações com a semântica ACID gera uma sobre-carga excessiva. Outra desvantagem da solução está no processo de marshalling emarshalling,

2.2. MIDDLEWARE 23

Figura 2.7 Fluxo de Transações no Middleware Transacional

pois na maioria das soluções essa conversão deve ser realizada manualmente, isentando essaresponsabilidade ao middleware (PINUS (2004)).

As principais soluções baseadas em MT são: CICS da IBM, Tuxedo da BEA e Encina daTransarc (EMMERICH (2000)).

2.2.3 Middleware Orientado a Objeto - MOO

Pode-se dizer que o Middleware Orientado a Objeto é uma melhoria da arquiteturaprocedural (RPC), onde a comunicação entre objetos distribuídos ocorre por meio de um serviçopara obter as referências das operações, bem como funcionalidades de serialização (marshalling)e desserialização (unmarshalling) (FUKS et al. (2012)). Algumas soluções de MOO incluem:OMG CORBA, Microsoft COM, Java RMI e Enterprise Java Beans.

Devido à capacidade de interação entre objetos distribuídos, o MOO suporta permite queum cliente solicite uma operação a um objeto do servidor em outro host. Porém, é necessárioo prévio conhecimento por parte do cliente à referência ao objeto do servidor. O processo deserialização dos parâmetros para a solicitação de rede é feito automaticamente nos stubs docliente e do servidor (PINUS (2004)). A comunicação realizada no MOO pode ocorrer tanto demodo síncrona ou assíncrona (EMMERICH (2000)).

Figura 2.8 Esquema de Invocação Simplificado em MOO

A Figura 2.8 descreve o processo de comunicação na arquitetura de objetos distribuídos.A invocação ocorre como no paradigma orientado a objetos (linha tracejada). Porém, o queocorre de fato é que o cliente invoca um método em uma referência do objeto remoto: o proxy.

2.2. MIDDLEWARE 24

Usando o núcleo de comunicação, a invocação é codificada (marshalled) para o protocolo binárioespecífico e transmitida para um servidor usando a rede subjacente. Do lado do servidor, ainvocação é reconstruída e finalmente chega ao objeto. A resposta retorna ao cliente de modoinverso (VILLA et al. (2011)).

Uma vantagem do MOO está no amplo apoio à heterogeneidade. Por exemplo, o OMG

CORBA e Microsoft COM suporta múltiplas linguagem de programação, permitindo que osobjetos do cliente e do servidor não precisem ser escritos na mesma linguagem de programação.Ambos têm uma representação padronizada de dados que eles usam para resolver heterogeneidadede dados entre plataformas (EMMERICH (2000)).

Em relação à confiabilidade, o MOO lida com as falhas durante as solicitações decomponentes por meio de exceções. Caso a operação não seja executada, o cliente será informadoda falha. Entretanto, a tolerância a falhas não é um fator de grande confiabilidade neste tipo dearquitetura (PINUS (2004)).

A maioria das soluções MOO tem suporte à mensagens e transações. Neste sentido,ele poderia substituir outros três tipos de middleware (MT, MOM e RPC) em vários aspectosdiferentes. Fazendo o MOO um tipo de middleware poderoso e flexível. Entretanto, devido aseu limitado suporte à escalabilidade, o Middleware Orientado a Objetos acaba sendo usado emcenários onde a escalabilidade não seja um requisito de prioridade (EMMERICH (2000)).

2.2.4 Middleware Orientado a Mensagens - MOM

O Middleware Orientado à Mensagem provê comunicação entre aplicações por meio datroca de mensagem. Nessa estrutura (veja a Figura 2.9), as mensagens enviadas pelo clientessão organizadas em filas onde aguardam até serem encaminhadas para seus respectivos destinos.Normalmente, essas mensagens contidas nas filas são classificadas em uma ordem específica.Neste caso, elas seguem o padrão First-In, First-Out (FIFO), onde a primeira mensagem da fila étambém a primeira mensagem a ser encaminhada ao destino final (CURRY (2004)).

Em um ambiente distribuído, a comunicação realizada pelo MOM, pode ocorrer demodo síncrono ou assíncrono (SILVEIRA et al. (2011)). No método síncrono, os elementos,permanecem bloqueados até finalizarem o processo de comunicação. Na comunicação assíncrona,o elemento requisitante fica disponível logo após realizar uma solicitação, não sendo necessárioaguardar um retorno dessa requisição (FUKS et al. (2012)).

O Middleware Orientado a Mensagens dispõe de dois modelos de mensagens: 1) modelopoint-to-point; 2) modelo publish/subscriber (COULOURIS et al. (2011)). No point-to-point

(Figura 2.10), as mensagens são enviadas através de uma fila para um componente específicodo sistema, ou seja, a comunicação ocorre exclusivamente entre entre remetente e destinatário.O modelo publish/subscriber (Figura 2.11) aplica o conceito de produtores e consumidores demensagens, onde um único produtor pode enviar uma mensagem para um ou vários consumidores.Os produtores publicam mensagens em um tópico ou canal (ambos filas) e os consumidores se

2.3. MIDDLEWARE PARA IOT 25

Figura 2.9 Arquitetura de Middleware Orientado a Mensagens

subscrevem em determinado tópico ou canal conforme interesse (CURRY (2004)).

Figura 2.10 Modelo de Mensagem Point-to-Point

Figura 2.11 Modelo de Mensagem Publish/Subscriber

As plataformas de MOM, de modo geral, possuem um série de serviços integrados, taiscomo: mensagens transacionais, entrega confiável de mensagens, persistência de mensagens,balanceamento de carga e clustering de aplicativos (CURRY (2004)). Exemplo de arquiteturasde Middleware Orientado a Mensagens incluem: MQSeries, MSQM, Presumo, TIBCO, SonicMQ,OpenJMS, entre outras.

2.3 Middleware para IoT

A arquitetura de Middleware para o IoT (Figura 2.12) fornece uma camada abstrata inter-posta entre a infraestrutura de TI e as aplicações. Ela visa esconder os detalhes tecnológicos parapermitir que os desenvolvedores de aplicativos se concentrem no desenvolvimento das aplicaçõespara IoT (CHAQFEH; MOHAMED et al. (2012)). Existem diversas soluções independentes deMiddleware para IoT , no entanto, a tendência é que essas soluções evoluam para uma plataforma


unificada para IoT , onde bilhões de objetos podem se conectar à Internet e interagir uns comos outros em todos os domínios de aplicações (LI et al. (2015)). Portanto, é viável conceberum sistema de middleware que possa simplificar o desenvolvimento de aplicativos e serviçosnecessários para o contexto de IoT .

Figura 2.12 Arquitetura de Middleware para Internet das Coisas

A IoT compreende dois componentes centrais, Internet e Coisas. A Internet é umainfra-estrutura de rede global com capacidades de autoconfiguração, escalabilidade e expan-são dinâmica baseadas em protocolos de comunicação padrão e interoperáveis, enquanto queas Coisas são objetos físicos/dispositivos ou objetos virtuais/dispositivos que possuem iden-tidades, atributos físicos e personalidades virtuais que dispõe de interfaces inteligentes. Ascoisas são de natureza heterogênea e integradas de forma transparente na rede de informação(BANDYOPADHYAY et al. (2011)).

Devido à abrangência do paradigma de IoT , o middleware para esse contexto herdainúmeros desafios provenientes das particularidades de cada tecnologia envolvida em Internetdas Coisas. Além desses, outros desafios são adicionados, já que os eventos e aplicativos em IoT

são mais numerosos e heterogêneos (FERSI (2015)). Nesse sentido, uma solução de Middleware

para Internet das Coisas deve possuir requisitos suficientes para tratar os desafios existentesBANDYOPADHYAY et al. (2011); MIORANDI et al. (2012). Resumidamente, os principaisrequisitos identificados para um Middleware para IoT são: 1 - Interoperabilidade; 2 - Mobilidade;3 - Escalabilidade; 4 - Descoberta de Dispositivos; 5 - Ciência de Contexto e; 6 - Segurança ePrivacidade.

� Interoperabilidade: A característica de interoperabilidade remete à capacidade desistemas computacionais, de modo geral, a se comunicarem de forma transparente.No Middleware para IoT , é de fundamental importância prover esse recurso, já queo contexto de Internet das Coisas é formado por diferentes tipos de dispositivosresultando em um alto nível de heterogeneidade. Esse desafio se torna ainda mais


complexo quando o middleware a ser desenvolvido deve ter a capacidade de gerir umagrande quantidade de dispositivos conhecidos e suportar novos a serem descobertos(CHAQFEH; MOHAMED et al. (2012)). Desse modo, é necessário que o middleware

para IoT tenha um alto nível de abstração, no intuito de ocultar a heterogeneidadeem diversos níveis e a complexidade de comunicação de baixo nível (FERSI (2015)).

� Mobilidade: A mobilidade é a qualidade ou propriedade do que é móvel, ou mesmoa facilidade de modificar-se. É de amplo conhecimento que objetos inteligentes nocenário de IoT não são estáticos e constantemente a localização física destes podemsofrer alterações. Isso requer mudanças rápidas na topologia de rede que, por suavez, afetam a eficiência de roteamento, pois há muitos caminhos que podem ficarindisponíveis (FERSI (2015)). Assim, na presença de mobilidade, uma plataformaIoT unificada requer que o sistema gerencie a troca dados com atrasos aceitáveis eentregas confiáveis. LI et al. (2015)

� Escalabilidade: A escalabilidade no contexto de software está associada à capacidadede um sistema atuar conforme o nível de demanda sem perda de desempenho. Emsistemas escaláveis, novos recursos podem ser adicionados para atender a necessidadede crescimento. O Middleware para IoT deve ser capaz de gerir problemas de escala-bilidade para que as funções básicas funcionem de forma eficiente em ambientes depequena e grande escala (CHAQFEH; MOHAMED et al. (2012)). Essa eficiênciadeve estender-se ao crescente número de objetos conectados de modo a garantir suasfuncionalidades mesmo que esse número aumente e varie de um lugar para outro(FERSI (2015)).

� Descoberta de Dispositivos: Este recurso possibilita que novos dispositivos sejamdescobertos de forma autônoma. A Descoberta de Dispositivos permite que qualquerdispositivo da rede de IoT detecte todos os seus dispositivos vizinhos e apresentesua presença para cada vizinho da rede. Técnicas de ontologia são utilizadas paraarmazenar informações sobre os dispositivos heterogêneos. Do ponto de vista da IoT ,esses módulos precisam ser confiáveis, tolerantes a falhas, adaptáveis e otimizadospara consumo de recursos (BANDYOPADHYAY et al. (2011)).

� Ciência de Contexto: Em IoT , o Contexto está relacionado à capacidade de carac-terizar determinada situação de uma entidade (pessoa, lugar, objeto, entre outros)relevante para interação entre um usuário e um aplicativo. O Middleware para Internetdas Coisas deve ter consciência do contexto para executar suas funções em ambientesinteligentes (BANDYOPADHYAY et al. (2011)). A Ciência de Contexto é assegu-rada pela detecção e processamento de contexto. A detecção de contexto consiste nacoleta de dados e na identificação dos principais fatores que afetam as respostas. O

2.4. MIDDLEWARE PRESUMO 28

processamento de contexto faz a extração dos dados úteis, processando-os para queuma decisão seja tomada com base nessa análise (FERSI (2015)).

� Segurança e Privacidade: Esse requisito é de extrema importância em uma arquite-tura de Middleware para IoT . A comunicação entre objetos da vida real representamum grande desafio em termos de confiança, segurança e privacidade (LI et al. (2015)).O Middleware para IoT deve ter a capacidade de gerenciar segurança em Internetdas Coisas de duas maneiras: segurança operacional e segurança de dados. A segu-rança operacional significa que mesmo com a infraestrutura comprometida, os dadosnão serão perdidos. Já a segurança dos dados (privacidade) está na capacidade domiddleware garantir os princípios básicos de segurança da informação (integridade,não repúdio, confidencialidade e autenticação). É extremamente complexo a imple-mentação de medidas de segurança em cenários distribuídos do modo se encaixar noparadigma descentralizado IoT (FERSI (2015)).

Como observado, são diversos os requisitos necessários para uma solução de Middleware

para Internet das Coisas. Mesmo com os consideráveis esforços de pesquisa na área de am-bientes inteligentes e IoT , nenhuma arquitetura unificada de middleware para computação foipadronizada (YICK; MUKHERJEE; GHOSAL (2008)). Possivelmente, uma solução única eadaptável a todos os domínios de aplicação em IoT não existirá (CHAQFEH; MOHAMED et al.(2012)).

2.4 Middleware Presumo

O Middleware Presumo (PRESUMO (2016)) é uma arquitetura desenvolvida utilizando aAPI JMS, ou seja, trata-se de um MOM. O projeto foi desenvolvido de modo genérico, podendoassim ser aplicado em diversos domínios. O Presumo fornece suporte a modelo de mensagensPublish/Subscriber de modo a maximizar seu desempenho. A comunicação é realizada demodo assíncrono, permitindo uma maior autonomia dos elementos. A arquitetura conceitual doPresumo pode ser observada na Figura 2.13.

Figura 2.13 Arquitetura do Middleware Presumo

2.5. CONSIDERAÇÕES FINAIS 29

O projeto distribuído do Presumo não depende de nenhum controlador centralizado. Issoresulta em uma maior flexibilidade na utilização do Presumo, diferente do que ocorre na utilizaçãoda API JNDI (Java Naming and Directory Interface), já que a maioria dessas implementações sãocentralizadas. No Presumo, as aplicações tem suas conexões, filas e tópicos criadas manualmente.Entretanto, nada impede aos desenvolvedores de criarem objetos administrados manualmente earmazená-los em uma implementação JNDI.

Uma grande vantagem do Presumo em relação a outras soluções, está na implementaçãoleve de sua arquitetura. Toda aplicação pode ser executada em uma única Java Virtual Machine

(JVM). Nos testes realizados no Presumo é possível observar que este proporciona um bomdesempenho (PRESUMO (2016)). Nas situação onde as mensagens são intra-JVM, estas sãoencaminhadas sem passar pela pilha de IP. Isso permite uma operabilidade eficiente, que podeser escalada como solução distribuída com o mínimo de desenvolvimento adicional.

A arquitetura do Presumo é consideravelmente flexível e isso a torna bastante escalável.Devido a facilidade na criação de aplicações com o Presumo, os desenvolvedores podem ex-plorar os diversos recursos da arquitetura, desenvolvendo e implantando aplicativos sem muitacomplexidade.

2.5 Considerações Finais

Neste capítulo foram apresentados os principais conceitos relacionados ao paradigma deInternet das Coisas. Desde os possíveis cenários de aplicação até a definição dos elementos quefazem parte da rede de IoT . Foram descritos os principais modelos de arquiteturas propostas noâmbito de Internet das Coisas, segundo a literatura.

Foi abordado o conceito de middleware no contexto geral; suas funcionalidades e a im-portância em ambientes distribuídos. Foram apresentados as principais categorias de middleware

segundo suas primitivas de comunicação. Foram descrito as características relevantes de cadacategoria de middleware apresentada, os pontos fortes e fracos de cada arquitetura.

Posteriormente, foi apresentada uma análise dos principais conceitos em Middleware

para IoT . Conforme a literatura, foram abordados os aspectos de uma arquitetura de Middleware

para Internet das Coisas, destacando os principais recursos que esse tipo de solução deve prover.Por fim, foi realizado um resumo sobre a arquitetura de Middleware Presumo. Suas ca-

racterísticas relevantes, funcionalidades e vantagens em relação a outras soluções de Middleware

Orientado à Mensagens - MOM.

303030

3Trabalhos Relacionados

Neste capítulo, serão apresentados os estudos existentes sobre o tema em questão. Foirealizada um análise sistemática do atual cenário de soluções de Middleware para Internet dasCoisas. Foram apreciados assuntos de relevância e relação direta ao tema proposto, e.g., Internetdas Coisas, Middleware e Redes de Sensores Sem fio. As pesquisas mais recentes com foco nodesenvolvimento de soluções de middleware para iot serão apresentadas.

3.1 Soluções de Middleware para Internet das Coisas

A rápida evolução tecnológica tem impulsionado o surgimento de novas tecnologias etendências como a Internet das Coisas. Atualmente, podemos observar a interação entre diversosobjetos inteligentes, denominados de “coisas”, gerando consideráveis volumes de dados. Estesobjetos não se limitam apenas a computadores convencionais, mas também a smartphones,smartwatchs, eyeglasses, pulseiras inteligentes, entre outros dispositivos com um mínimo deprocessamento computacional.

Devido as diversas particularidades e em especial a heterogeneidade de dispositivos, odesenvolvimento de aplicações IoT é complexo e a adoção de uma plataforma de middleware

pode ajudar nesta tarefa. Tal complexidade refere-se aos desafios envolvidos numa arquiteturadistribuída para Internet das Coisas, tais como: um ambiente em constante mudança, modelo deprogramação inadequado, questões sobre arquitetura de software e a necessidade de reconfigura-ção dinâmica BERNARD (2006).

Em seu estudo, Chaqfeh CHAQFEH; MOHAMED et al. (2012) faz uma breve introduçãoà dificuldade em se desenvolver aplicações para IoT e descreve quais são os desafios técnicosde uma plataforma de middleware para Internet das Coisas: Interoperabilidade, Escalabilidade,Provisionamento de abstração, Multiplicidade, Interação espontânea, Infraestrutura variável,Segurança e Privacidade.

Baseando-se nessas características, o autor remete à possíveis soluções de Middleware

para IoT levando em consideração as soluções de middleware existentes em outros domínios,tais como: no contexto de Web Semântica e Web Services, RFID e RSSF, e Sistemas Robóticos.

3.1. SOLUÇÕES DE MIDDLEWARE PARA INTERNET DAS COISAS 31

Com base nos domínios supracitados, a Tabela 3.1 ilustra os desafios enfrentados na abordagemde middleware para Internet das Coisas.

Tabela 3.1 Desafios no Middleware para IoT CHAQFEH; MOHAMED et al. (2012)

Ressalta-se que as abordagens apresentadas na Tabela 3.1, tiveram foco nos desafiosque Chaqfeh (CHAQFEH; MOHAMED et al. (2012)) pondera serem imprescindíveis à umaplataforma de middleware para IoT . Desta forma, o autor acredita que a solução que melhorse adapta ao desenvolvimento de uma plataforma de middleware para Internet das Coisas sãobaseadas no domínio de Web Semântica, mais especificamente para soluções SOA (FERSI(2015)). Entretanto, o autor acentua a limitada possibilidade da existência de um padrão único egeneralizado para o desenvolvimento de um middleware para Internet das Coisas devido à grandequantidade de aplicações e domínios distintos envolvidos. Todavia, acredita-se na possibilidadede uma padronização para domínios específicos.

Da mesma forma, Fersi (FERSI (2015)) reforça os desafios técnicos já apresentados,acrescentando fatores que acredita serem também importantes: Disponibilidade desconhecida deData-Point, Conflitos de Ativação, Bootstrapping, Extensibilidade, Confiança, Modularidade, eIntegração com mundo real.


A avaliação positiva de um middleware para Internet das Coisas está condicionada aoconjunto de desafios que a arquitetura desenvolvida é capaz de suportar. Em observância asfuncionalidades de um middleware para IoT , Fersi (FERSI (2015)) analisa algumas abordagenspossíveis, como mostrado na Tabela 3.2: Publish/Subscribe (Pub/Sub), Arquitetura Orientada aServiços (SOA), Web Semântica, e Ciência de contexto.

Tabela 3.2 Desafios versus Modelos de Distribuição de um Middleware para IoT (FERSI (2015))

Um fator que necessita de atenção no âmbito de IoT e que dificulta consideravelmenteo desenvolvimento de um middleware é a capacidade limitada de recursos (processamento,memória, energia) que os objetos envolvidos dispõe. Devido à essas limitações, as funções deum middleware para Internet das Coisas podem ser comprometidas (FERSI (2015)).

De acordo com Fersi (FERSI (2015)), as soluções de middleware para IoT existentes sãocapazes de tratar uma considerável quantidade desses desafios, mas o resultado não é suficienteàs necessidades de Internet das Coisas. Uma solução proposta baseia-se na combinação de váriastécnicas afim de abordar ao máximo os demais desafios não alcançados no uso de uma únicaabordagem, buscando o ponto de equilíbrio entre o consumo de energia para a computação econsumo de energia para a comunicação (BERNARD (2006)).

Os componentes funcionais e as arquiteturas de middleware para IoT são apresentadosem BANDYOPADHYAY et al. (2011), que busca classificar as diferentes plataformas segundoos recursos disponíveis. A Figura 3.1 ilustra os componentes funcionais de uma solução demiddleware para Internet das Coisas.

Como mencionado, as plataformas de middleware, de modo geral, procuram sanar as difi-culdades encontradas em ambientes distribuídos. Ao mesmo tempo, as plataformas existentes nocenário de IoT tendem a solucionar os contratempos de ambientes distribuídos além de fornecer


Figura 3.1 Requisitos em um Middleware para IoT (BANDYOPADHYAY et al. (2011))

diversos recursos que auxiliam na resolução de muitos desafios (interoperação, gerenciamentode dispositivos, ciência de contexto, segurança e privacidade, e assim por diante) encontrados noâmbito de Internet das Coisas. As Tabelas 3.3 e 3.4 exemplificam essas comparações.

Tabela 3.3 Recursos de Middleware para IoT (BANDYOPADHYAY et al. (2011))

Tabela 3.4 Interfaces de Middleware para IoT (BANDYOPADHYAY et al. (2011))

Diante dos desafios enfrentados no desenvolvimento de um Middleware para IoT, aescalabilidade merece certa atenção. Devido à sua capacidade de operar conforme expansão domodelo de negócio, o resultado será uma grande quantidade de dados gerados pela interação demilhares de dispositivos.


Esperando-se que a vasta quantidade de dados gerados seja tratada, o requisito degerenciamento de grandes volumes de dados se faz necessário, pois este será responsável pelaverificação e análise dos dados coletados, atuando de maneira eficiente na tomada de decisões.Entretanto, no banco de dados, a manipulação desse grande volume de dados se torna um desafio.Neste cenário, soluções de Big Data tem sido apontadas como repostas para estes problemasDELICATO; PIRES; BATISTA (2013).

Observou-se que o desenvolvimento de soluções de middleware no contexto de IoT

podem ser agrupadas conforme as abordagens de comunicação:

� Baseado em Eventos;

� Baseado em Agentes;

� Orientada a Serviços;

� Orientada a Banco de Dados;

3.1.1 Middleware Baseado em Eventos

Hermes (PIETZUCH (2004)) - trata-se de uma solução de middleware baseada emeventos com foco em aplicações distribuídas em larga escala. A comunicação no Hermes ocorretanto em modo síncrono ou assíncrono. Um algoritmo de roteamento escalável e mecanismosde tolerância a falhas foram utilizados na solução de modo evitar diferentes tipos de falhas nomiddleware.

A arquitetura do Hermes está segmentada em seis camadas: camada de serviços, acamada de middleware baseada em eventos, camada publish/subscriber baseada em tipos e ematributos, a camada de rede de roteamento de sobreposição e a camada de rede.

A camada de middleware baseada em eventos fornece uma API para que os programado-res possam implementar aplicativos. A camada de middleware consiste em vários módulos queimplementam funcionalidades como tolerância a falhas, entrega confiável de eventos, descobertade evento, segurança e transações. Uma característica negativa do Hermes, está na falta deuma topologia de rede dinâmica. Hermes não suporta eventos compostos ou armazenamentopersistente para eventos. Além disso, o suporte para a adaptação à nível de rede, é bastantelimitado.

Prisma (SILVA et al. (2014)) - é um middleware baseado em eventos voltado para RSSF.Ao fornecer uma interface de alto nível e padronizada para acesso a dados, o PRISMA oferecesuporte à interoperabilidade das tecnologias de rede heterogêneas. A solução possui um conjuntode bibliotecas que representam os seguintes recursos do middleware: controle de topologia,descoberta de serviços e uma biblioteca para gerenciamento de mensagens.

O projeto PRISMA implementa uma arquitetura em três camadas: camada de acesso,camada de serviço e camada de aplicação. A camada de acesso gerencia a comunicação, aquisição


de dados, verificação de requisitos de QoS e reconfiguração. A reconfiguração é suportada emvários casos (por exemplo, falha no dispositivo). A camada de serviço fornece um componente dedescoberta de recursos. A camada de aplicação oferece suporte para abstração de programação eé responsável por receber e gerenciar mensagens de aplicativos.

O Prisma assume o paradigma de uma Rede de Sensores Sem Fio heterogênea e hie-rárquica, subdividida em três níveis: Gateway, Cluster Head e Nó Sensor. No entanto, essaabordagem centralizada gera consideráveis gargalos nos nós coletores. Diante cenários espe-cíficos de IoT , a abordagem centralizada de descoberta de serviços acaba não sendo um fatorfavorável. Um dos objetivos futuros, é redesenhar a arquitetura do PRISMA para permitir osuporte à reconfiguração dinâmica em tempo de execução.

3.1.2 Middleware Baseado em Agentes

Ubiware (NAGY et al. (2009)) é uma solução de middleware que incorpora o princípiode sistemas multi-agentes com suporte ao desenvolvimento de sistemas industriais autônomos,complexos, flexíveis e extensíveis. Sua plataforma baseia-se em três requisitos: automação,integração e interoperabilidade.

Um agente do Ubiware é dividido em três camadas: camada de mecanismos de com-portamento, camada intermediária declarativa (modelos de comportamento correspondentes adiferentes funções que o agente desempenha) e a camada referente ao núcleo do agente, quecontém recursos compartilhados e reutilizáveis interpretados como componentes Java (sensores,atuadores, máquinas inteligentes e dispositivos, entre outros).

No que diz respeito à segurança, o Ubiware é capaz de incluir, sem problemas, novaspolíticas de segurança e reconfigurando as já existentes em resposta a ambientes extremamentedinâmicos. A interoperabilidade é alcançada por meio de adaptação semântica e atribuindo umagente pró-ativo a cada um dos recursos. Isso é suportado usando metadados e ontologias. Noentanto, o suporte à interoperabilidade é limitado. Por exemplo, não abrange a interoperabilidadeentre diferentes protocolos de descoberta de recursos.

Impala (LIU; MARTONOSI (2003)) - é uma solução de middleware voltada para RSSFque permite a modularidade de aplicativos, adaptatividade e reparação. O Impala permite queas atualizações de software sejam recebidas e aplicadas ao sistema em tempo de execução.A solução também fornece uma interface para a adaptação de aplicativos on-the-fly, a fim demelhorar o desempenho, eficiência energética e confiabilidade do sistema de software.

Para realizar a adaptação dinâmica, o Impala combina vários protocolos de aplicaçãoem um único protocolo. Os requisitos de gerenciamento de recursos, mobilidade, aberturae escalabilidade são suportados ao alternar entre diferentes protocolos e modos de operaçãodependendo das aplicações e das condições da rede.

O Impala usa uma camada de sistema otimizada para executar a adaptação de aplicativosdinâmicos com base em parâmetros e falhas de dispositivos e atualizações automáticas de aplica-


tivos com base em um mecanismo de gerenciamento e transmissão de software especializado. Noentanto, o Impala não suporta o pré-processamento de dados, que é um componente importantedo gerenciamento de dados. Em geral, o Impala é um sistema de baixo impacto no desempenhoem tempo de execução e que pode melhorar significativamente a confiabilidade, o desempenho ea eficiência energética do sistema.

3.1.3 Middleware Orientado à Serviços

Hydra (EISENHAUER; ROSENGREN; ANTOLIN (2010)) é conhecido como LinkS-

mart, é um middleware para serviços e sistemas de inteligência ambiental (AmI) voltado paracenários de IoT . A solução é baseada em SOA (Arquitetura Orientada a Serviços) e ofereceinterfaces de serviços Web para controle de qualquer tipo de dispositivo físico e permite quedesenvolvedores incorporem dispositivos físicos heterogêneos em suas aplicações.

Sua arquitetura consiste em uma série de componentes de gerenciamento, incluindogerenciador de serviços, eventos, dispositivos, armazenamento, contexto e segurança. O Hydra

fornece interoperabilidade de nível sintático e semântico usando Web Semântica. Além de umasérie de requisitos funcionais (por exemplo, gerenciamento de dados, gerenciamento de eventose gerenciamento de recursos), ele suporta reconfiguração dinâmica e autoconfiguração.

O projeto Hydra tem sua estrutura distribuída em quatro camadas: camada de rede (co-municação com os dispositivos), camada de serviço (responsável pelo gerenciamento de eventos,dispositivos, escalonamento de recursos, entre outros), camada semântica (gerenciamento decontexto e serviços) e a camada de segurança (abrange as demais camadas fornecendo umacomunicação segura e confiável).

Sua solução de segurança e privacidade usa a virtualização e a implementação de meca-nismos baseados em Web Semântica. No entanto, sua virtualização pode introduzir preocupaçõesde segurança (por exemplo ataques do tipo side-channel attack). Além disso, a segurançasemântica baseada em ontologia e as soluções de interoperabilidade provavelmente não serãoadequadas ao contexto de IoT devido a falta de padronização de ontologias para este paradigmaem grande escala.

SOCRADES (CANNATA; GEROSA; TAISCH (2008)) - é um projeto de pesquisa eu-ropeu que aborda o paradigma industrial baseado em SOA. Seu principal objetivo está emdesenvolver uma plataforma de projeto, execução e gerenciamento para sistemas de automaçãoindustrial de próxima geração, explorando o modelo de arquitetura orientada à serviços, tantoem dispositivo como em nível de aplicação.

Sua arquitetura consiste em duas camadas: a camada para serviços de aplicação (porexemplo, armazenamento de eventos) e a camada para serviços de dispositivo (por exemplo,gerenciador de dispositivos e monitoramento, descoberta de serviços, gerenciamento de ciclo devida de serviços).

A idéia de SOCRADES é criar um ecossistema onde os sistemas de rede são compostos


por dispositivos inteligentes que interagem com o ambiente físico e organizacional, buscandometas de sistema bem definidas. Esta abordagem favorece a adaptabilidade e a rápida recon-figurabilidade, uma vez que a reprogramação de grandes sistemas monolíticos é substituídapela reconfiguração de unidades embutidas livre de acoplamento. Do ponto de vista funcional,o foco é gerenciar o número amplamente aumentado de dispositivos inteligentes e dominar acomplexidade associada.

3.1.4 Middleware Orientado a Banco de Dados

TinyDB (MADDEN; HELLERSTEIN; HONG (2003)) é um middleware voltado pararede de sensores com foco em processamento de consultas distribuídas baseado no S.O. TinyOS.Devido às limitações dos nó sensores, o TinyDB fornece eficiência energética em sistemas deprocessamento de consultas em rede por meio de algoritmos específicos.

O TinyDB fornece suporte à abstração em nível de programação e um modelo de agrega-ção de dados, neste contexto ele fornece uma API Java para possibilitar o desenvolvimento deaplicativos de consulta e extração dados na rede. O TinyDB conta com algumas características:gerenciamento de metadados, consultas de alto nível, gerenciamento de rede dinâmica (tabelas deroteamento), múltiplas consultas e desenvolvimento gradual via compartilhamento de consultas(compartilhamento e execução de consultas por motes).

Em suma, o projeto TinyBD possui um gerenciamento de dados eficiente, minimizandoa comunicação dispendiosa, aplicando operações de agregação e filtragem dentro da RSSF.Entretanto, as vantagens apresentadas estão vinculadas ao uso exclusivo do S.O. TinyOS pelossensores dentro da rede.

GNS (ABERER; HAUSWIRTH; SALEHI (2006)) é uma plataforma de middleware defácil integração envolvendo vários tipos de sensores, ou seja, sua implementação é altamentemodular de modo possibilitar a implantação em diversas plataformas de hardware, desde estaçõesde trabalho até pequenos dispositivos programáveis. Novos sensores podem ser facilmenteadicionados através da utilização da API GSN disponibilizada pelo middleware.

O GSN dispõe de uma arquitetura baseada em contêiners, onde cada recipiente podehospedar e gerenciar simultaneamente um ou mais sensores virtuais. O recipiente gerencia todosos aspectos dos sensores virtuais em tempo de execução, incluindo acesso remoto, interação coma rede de sensores, segurança, persistência, filtragem de dados, concorrência, controle de acessoa compartilhamento de recursos.

As informações sobre os sensores virtuais são identificadas por pares de valores-chavedefinidos pelo usuário e a comunicação é realizada via peer-to-peer. Esse recurso possibilita queos sensores virtuais possam ser descobertos e acessados com base em qualquer combinação desuas propriedades, por exemplo, localização geográfica e tipo de sensor. Esse recurso possibilitaque o sistema seja escalável e adaptável, entretanto não oferece suporte para interoperabilidade,segurança e/ou privacidade.

3.2. SUMÁRIO DE COMPARAÇÕES 38

3.2 Sumário de Comparações

Tendo como base as diversas soluções apresentadas na Seção 3.1, a presente seção temcomo foco a realização de um comparativo entre essas soluções. O comparativo será realizado en-tre as seguintes soluções de middleware: Hermes, Prisma, Ubiware, Impala, Hydra, SOCRADES,

TinyDB e GNS. Como parâmetros de classificação foram utilizados os principais componentesfuncionais e não funcionais necessários a uma solução de middleware para IoT apresentados emBandyopadhya (BANDYOPADHYAY et al. (2011)) e Mohammad (RAZZAQUE et al. (2016)).

Tabela 3.5 Comparação entre Soluções de Middleware para IoT


Este capítulo apresentou os principais trabalhos relacionados ao contexto de Middleware

para IoT . Foram apresentadas as principais características que uma solução de middleware

para Internet das Coisas deve possuir. Também foram abordados as possíveis arquiteturas demiddleware (primitivas de comunicações) compatíveis com o paradigma de IoT .

Foi realizado um paralelo entre as soluções de middleware para Internet das Coisas,considerando os desafios a serem solucionados no contexto de IoT . Posteriormente, foramapresentadas as principais soluções de Middleware atualmente existentes para IoT e classificadasem grupos conforme suas características de funcionamento.

393939

4Middleware xPresumo

Neste capítulo será apresentado o Middleware xPresumo, que é um MOM desenvol-vido para o contexto de IoT . Serão apresentados os requisitos, a arquitetura, o projeto dedesenvolvimento e suas características, além da implementação da solução.

4.1 Requisitos

Com um tamanho inferior a 500 KB (quilobyte), o middleware xPresumo é uma solu-ção que foi desenvolvida tendo como base as características essenciais à uma arquitetura deMiddleware para Internet das Coisas, procurando associar os recursos necessários e o melhordesempenho. Os requisitos dos xPresumo foram definidos com base nos estudos apresentadospor Bandyopadhya (BANDYOPADHYAY et al. (2011)), Whitmore (WHITMORE; AGARWAL;DA XU (2014)), Mohammad (RAZZAQUE et al. (2016)) e Miorandi (MIORANDI et al. (2012)).

Assim, os principais requisitos para a solução em questão são:

� Heterogeneidade: Uma das principais características em sistemas distribuídos enecessário ao contexto de IoT . Devido à diversidade de dispositivos conectados emambientes inteligentes, o xPresumo atua para que a comunicação ocorra de maneirasimplificada, ou seja, de maneira padronizada.

� Segurança: Em ambientes onde inúmeros dispositivos compartilham todo tipo deinformações, é de fundamental importância a adoção de mecanismos de segurançaque visem dificultar a manipulação de informações sem a devida autorização. O xPre-

sumo provê confidencialidade e integridade das informações por meio de criptografiasimétrica. O módulo de segurança do xPresumo conta com dois mecanismos: deautenticação de dispositivos e de criptografia das mensagens trocadas entre dispositi-vos.

� Descoberta e Localização de Dispositivos: Outro requisito essencial no cenário deIoT é na capacidade de localização e descoberta de dispositivos. O xPresumo contacom o recurso de localização e descoberta baseados em Received Signal Strength

4.2. ARQUITETURA 40

Indicator (RSSI), ou seja, estimativa de posicionamento baseada na intensidade dosinal sem fio transmitido por estações base.

� Ciência de Contexto e Adaptabilidade: Sabendo da dinamicidade encontrada emambientes de IoT , muitos dispositivos podem sofrer alterações necessárias paraseu funcionamento adequado. Pensando nisso, o xPresumo possui a capacidade deadaptar o uso de criptografia conforme o nível de bateria dos dispositivos conectados.Conforme a bateria de determinado dispositivo atingi um nível crítico de energia, énecessário que a comunicação entre dispositivos seja modificada; mensagens queantes eram enviadas criptografadas, agora devem trafegar em seu formato original.

� Gerenciamento de Eventos: São muitos os eventos gerados em Internet das Coisas. Énecessário que o grande volume de dados produzido pelos dispositivos conectadossejam registrados para possíveis análises futuras. Sendo assim, o xPresumo possuium módulo responsável pelo armazenamento desses eventos em uma base de dadosorientada a documentos (estrutura Not Only SQL (NoSQL) de coleções de atributos evalores).

Nas próximas seções serão apresentadas as demais etapas de desenvolvimento do xPre-

sumo, além de maiores detalhes funcionais sobre os requisitos em relação à arquitetura.

4.2 Arquitetura

O xPresumo foi desenvolvido com base na arquitetura do Middleware Presumo (Seção2.4), um servidor de mensagens baseado na API JMS. Optou-se pelo desenvolvimento de umasolução de middleware utilizando a API JMS considerando o mecanismo de troca de mensagensassíncronas, o mais indicado no contexto de IoT para notificações de eventos ou mesmo a trocade informações entre dispositivos. O xPresumo é uma extensão da arquitetura do Presumo, ouseja, as camadas de Distribuição e Infraestrutura foram utilizadas para estender a camada deServiços do xPresumo. Foram necessárias algumas adaptações nas camadas de Distribuição eInfraestrutura para o correto funcionamento do xPresumo.

O Middleware xPresumo pode ser configurado de modo simples seguindo o modelocliente-servidor, onde vários clientes se conectam a um servidor, ou mesmo adotar uma topologiamais complexa, ou seja, múltiplos servidores xPresumo conectados entre si (Figura 4.1). Nessaúltima topologia, os servidores ficam encarregados de encaminhar as mensagens destinadasàqueles clientes interessados em determinados tópicos.

O desenvolvimento da solução se deu utilizando o padrão de projeto Observer, tambémconhecido como Publish-Subscribe GAMMA et al. (1994). Em diversas situações, um ou maisdispositivos terão interesse em determinado assunto, sendo esta, a razão por adotar o modeloPublish-Subscribe ao invés do modelo Point-to-point.

4.2. ARQUITETURA 41

Figura 4.1 Topologia com Vários xPresumo Conectados

O funcionamento do padrão Observer consiste basicamente em estabelecer o relaciona-mento entre objetos-chave denominados observer (observador) e subject (assunto). Os subjects

produzem conteúdo e os publicam, os observers, que implementam a interface Listener, seriamos assinantes desses conteúdos, recebendo notificações a cada nova publicação.

Uma visão conceitual da arquitetura do xPresumo pode ser observada na Figura 4.2. Aarquitetura do xPresumo é dividida em três camadas: infraestrutura, distribuição e serviços.

Figura 4.2 Arquitetura do Middleware xPresumo

A camada de infraestrutura é responsável pelo encapsulamento das primitivas de comuni-cação a nível de S.O. entre o transmissor e o receptor. Já a camada de distribuição tem a funçãode gerenciar as filas de mensagens do middleware, assegurando a troca de mensagens entre ascamadas de infraestrutura e de serviços.

A camada de serviços do middleware xPresumo encapsula os serviços voltados ao

4.2. ARQUITETURA 42

contexto de IoT . A referida camada conta com os seguintes serviços: Localização e Descoberta,Ciência de Contexto, Gerenciamento de Eventos e Segurança.

Os serviços de Localização e Descoberta de dispositivos são características fundamentaisem uma solução de Middleware para Internet das Coisas devido a mobilidade das coisas. Alocalização geográfica de determinado dispositivo é realizada baseando-se na intensidade do sinal(RSSI) em relação aos Access Point (AP) fixos. Optou-se pelo recurso de localização baseadoem RSSI devido o sinal do Sistema de Posicionamento Global (GPS) ser de baixa qualidade namaioria dos ambientes indoor.

O serviço de Localização de dispositivos retorna a localização geográfica do própriodispositivo solicitante. O serviço de Descoberta é responsável por informar à um determinadodispositivo a localização geográfica de um outro dispositivo dentro da mesma estrutura física.

A Ciência de Contexto é outro recurso fundamental ao paradigma de Internet das Coisas.No xPresumo, o serviço relativo à Ciência de Contexto tem como finalidade analisar o nível deenergia dos dispositivos portadores de bateria e reagir conforme as necessidades de mudanças.Neste caso específico, quando a bateria do dispositivo atinge um nível crítico, as mensagens queantes eram enviadas criptografadas, passam a trafegar decriptografadas.

A Segurança implementada no xPresumo, envolve dois módulos, de Autenticação dedispositivos e Criptografia das mensagens. Na Autenticação, foi implementado o algoritmo hash

Secure Hash Algorithm (SHA-2) com uma função de 256 bits. A Criptografia das mensagensé realizada por meio de Criptografia Simétrica utilizando o algoritmo Advanced Encryption

Standard (AES) com uma chave de 128 bits.Nos estudos realizados por Prasithsangaree (PRASITHSANGAREE; KRISHNAMURTHY

(2003)) e Singhal (SINGHAL; RAINA (2011)) é possível observar que existem algoritmos simé-tricos que oferecem melhor desempenho e menor consumo energético em relação ao AES, porémnota-se que tais algoritmos são suscetíveis a maioria dos ataques de força bruta (COUTURE;KENT (2004)), ou seja, oferecem menos segurança que o AES. No cenário de Internet das Coi-sas, dependendo do domínio de aplicação, é necessário priorizar a segurança devido a relevânciadas informação trocadas entre dispositivos; o algoritmo AES proporciona um equilíbrio entresegurança e desempenho.

O serviço de Gerenciamento de Eventos tem como propósito a captura dos eventosocorridos durante o funcionamento de xPresumo. A troca de mensagens entre os dispositivossão armazenadas em um servidor de banco de dados. Devido à grande quantidade de eventosgerados no cenário de IoT , optou-se pelo uso do MongoDB (KANADE; GOPAL; KANADE(2014)), um banco de dados orientados a documentos (NoSQL). Os bancos de dados NoSQLtem desempenho escalável, alta disponibilidade e resiliência.

No processo de desenvolvimento do xPresumo, houve a preocupação em solucionaros principais problemas em IoT apontados pela literatura, procurando manter um desempenhosatisfatório na sua utilização.

4.3. PROJETO 43

4.3 Projeto

Esta seção tem como foco detalhar os serviços desenvolvidos no xPresumo (ver Seção4.2). Para melhor entendimento, a representação desses serviços será realizada por diagramas deClasses e Atividades Unified Modelling Language (UML) BOOCH; RUMBAUGH; JACOBSON(2006).

4.3.1 Localização e Descoberta

Os serviços de Localização e Descoberta de dispositivos tem a responsabilidade deretornar a localização geográfica. As funcionalidade desses serviços são implementadas pelaclasse Location, que, possui os métodos necessários para simular os APs fixos e calcular o RSSI.

A Figura 4.3 apresenta a modelagem dos serviços de Localização e Descoberta. Nafigura é possível observar a relação entre as classes DispositivoA e a Location. A classe Location

implementa a interface MessageListener, que é definida na especificação JMS e possui trêsatributos (idcoisa, rssi e resultabse) e cinco métodos (serviceDicovery(), serviceLocation(),

LocationA(), LocationB() e LocationB()).O atributo "rssi"tem como finalidade armazenar temporariamente a intensidade do sinal

de rádio (RSSI) recebido por determinado dispositivo em relação aos APs disponíveis. Após aobtenção desses valores, o posicionamento geográfico é calculado tendo por base as distânciasentre o dispositivo em questão e os APs. Para melhor acurácia do posicionamento, é precisousar no mínimo três APs. O atributo resultbase é utilizado para armazenar o posicionamentogeográfico calculado anteriormente.

Ambos os métodos e atributos são comuns aos serviços de Localização e Descoberta dedispositivos. Entretanto, o método serviceLocation() é usado especificamente pelo serviço deLocalização, já o método serviceDiscovery() é de exclusividade do serviço de Descoberta.

Figura 4.3 Diagrama de Classe do Serviço de Localização

O diagrama de sequência do serviço de Localização pode ser observado na Figura 4.4. Umdispositivo qualquer solicita sua localização fazendo uma chamada ao método serviceLocation()

4.3. PROJETO 44

da classe Location e no retorno é realizada uma chamada aos métodos subscriberLocation() eonMessage().

Figura 4.4 Diagrama de Sequência do Serviço de Localização

Juntamente com o método subscriberLocation(), um parâmetro do tipo "inteiro"é enca-minhado. Esse parâmetro corresponde ao "id"do próprio dispositivo, ou seja, sua identificação.Ao invocar o método publisherLocation(), o dispositivo em questão recebe a sua localizaçãogeográfica por meio de um objeto do tipo Message no método onMessage.

Figura 4.5 Diagrama de Sequência do Serviço de Descoberta

A Figura 4.5 apresenta o diagrama de sequência do serviço de Descoberta. O métodoresponsável por retornar a localização geográfica de outros dispositivos é o serviceDiscovery(),que também recebe um parâmetro do tipo "inteiro", correspondente à identificação (id) dodispositivo que se deseja obter a localização.

4.3.2 Ciência de Contexto

O serviço de Ciência de Contexto viabiliza a adaptação do funcionamento do xPresumo

em relação ao envio de mensagens. Por padrão, as mensagem trocadas entre os dispositivos sãotodas criptografadas e esse recurso de segurança tem impacto negativo no consumo de energiade dispositivos dependentes de bateria. Por essa razão, optou-se em incluir o módulo em questãode modo a obter um melhor gerenciamento dos recursos energéticos dos dispositivos.

4.3. PROJETO 45

O diagrama de classe do serviço de Ciência de Contexto pode ser visto na Figura 4.6.Assim como a classe Location, a classe MessageControl também implementa a interface Messa-

geListener. A MessageControl possibilita a alternância entre mensagens criptografadas e nãocriptografas através do envio de mensagens de controle (message), informando quando determi-nado dispositivo equipado com bateria atingir um nível crítico (nivelcritico) de energia. O valordo nível crítico é um parâmetro definido pelo usuário do sistema conforme as necessidades doambiente monitorado e do tipo de dispositivos que portam bateria.

Figura 4.6 Diagrama de Classe do Serviço de Ciência de Contexto

A adaptação ocorre mediante o recebimento de alguma mensagem de controle, ou seja,todos os dispositivos que se subscrevem a um determinado tópico (temperatura, localização,status, entre outras), estão condicionados às mensagens de controle. Antes que as mensagensenviadas aos tópicos cheguem ao destino final, é verificado se existem dispositivos portandobateria e se o nível energético destes dispositivos possibilita o recebimento de mensagens semcomprometer seu funcionamento. O diagrama de sequência da Figura 4.7 ilustra esse fluxo deeventos.

Figura 4.7 Diagrama de Sequência do Serviço de Ciência de Contexto

Os dispositivos que solicitam alguma informação pertinente ao cenário monitorado(temperatura, localização, status, entre outras), realizam inicialmente uma chamada ao métodosubscriberMSGControl(). O subscriberMSGControl() é responsável por receber as mensagensde controle relacionadas ao nível energético dos dispositivos dependentes de bateria.

4.3. PROJETO 46

O publisherMSGControl() é o método encarregado pelo envio das mensagens de controle.Os dispositivos portadores de bateria devem constantemente realizar chamadas a este método,informando se o nível crítico de energia foi atingido. O método onMessage presente em ambasas classes é invocado a cada nova mensagem. Nos dispositivos que detém bateria, o métodosetMensagem é executado dentro do onMessage e atualiza o status energético sempre que háalterações no nível de energia da bateria.

4.3.3 Segurança

O serviço de Segurança é outro módulo de extrema importância ao cenário de IoT . Asinformações que trafegam entre as coisas inteligentes devem ter um mínimo de segurança paraque problemas como intercepção de dados sejam evitados. A Segurança no xPresumo tem duasfinalidades: prover um mecanismos de autenticação das coisas inteligentes e a criptografia nasmensagens trocadas entre esses dispositivos.

O diagrama de classe da Figura 4.8 ilustra a classe Authentication, responsável por autori-zar que dispositivos conhecidos possam enviar e/ou receber informações. A classe Authentication

possui três métodos: includeDevice(), verificationDevice() e selecthashDevice(). O primeirométodo (includeDevice) foi implementado para possibilitar a prévia inclusão dos dispositivos par-ticipantes no cenário a ser monitorado. Dentre as informações que são utilizadas para o cadastrodo dispositivo, uma identificação única é solicitada, além de uma senha para autenticação.

Figura 4.8 Diagrama de Classe do Serviço de Segurança - Autenticação

Para aumentar a segurança no mecanismo de autenticação, a senha fornecida no cadastroé submetida à uma função criptográfica unidirecional SHA-2, gerando um hash (sequência debits) que será convertida em formato hexadecimal antes de ser armazenadoa no banco de dados.

O método verificationDevice() tem a finalidade de verificar se a identificação única dodispositivo (idcoisa) que está publicando alguma mensagem corresponde ao dispositivo emquestão. A validação das informações relacionadas à autenticação dos dispositivos é realizadapelo método selecthashDevice. As informações fornecidas para autenticação são verificadasem uma base dados e caso a autenticação seja bem sucedida, o dispositivo terá permissão para

4.3. PROJETO 47

interagir com os demais. O diagrama de sequência da Figura 4.9 demonstra o processo deautenticação realizado pelos dispositivos.

Figura 4.9 Diagrama de Sequência do Serviço de Segurança - Autenticação

Antes de qualquer publicação de mensagens relacionada ao cenário monitorado, os dis-positivos devem realizar a autenticação para que possam interagir com o xPresumo. Inicialmenteé realizada uma chamada ao método selecthashDevice passando como parâmetro a identificaçãoúnica do dispositivo (id), juntamente com o hash gerado para aquele dispositivo específico. Érealizada uma consulta à base de dados do xPresumo afim de verificar se os dados são válidos ecorrespondem a algum dispositivo previamente cadastrado. Em caso de sucesso na verificação,o dispositivo terá permissão para interagir com o sistema, publicando e recebendo mensagens.Essa verificação é realizada toda vez que um dispositivo deseja enviar e receber mensagens.

O mecanismo de autenticação resolve uma das preocupações presentes nos cenáriosde IoT; acesso não autorizado as mensagens trocadas entre dispositivos. Entretanto, só essamedida de segurança não é suficiente. Existe também a preocupação em relação à inteligibilidadedas mensagens em casos de intercepção não autorizada. Sendo assim, em complemento aomecanismo de autenticação, o xPresumo por meio de criptografia simétrica, permite a encriptaçãodas mensagens enviadas entre dispositivos.

Todas as mensagens publicadas via xPresumo são submetidas ao processo de cifragemutilizando um algoritmo criptográfico AES com uma chave de 128 bits. A classe Security

(Figura 4.10) fica responsável por realizar esse processo de encriptografar e decriptografar asmensagens trocadas entre os dispositivos.

Figura 4.10 Diagrama de Classe do Serviço de Segurança - Criptografia

A classe Security possui um atributo key do tipo array de bytes, além dos seguintesmétodos: keyGenerator, encrypt e decrypt(). O atributo key tem a responsabilidade de armazenar

4.3. PROJETO 48

o valor da chave criptográfica gerada por meio do método keyGenerator. O encrypt tem a finali-dade de encriptar as mensagens enviadas. Na outra extremidade de comunicação, o decrypt()

realiza a decriptação das mensagens recebidas. Uma melhor visualização do fluxo criptográficorealizado na troca de mensagens pode ser observada na Figura 4.11.

Figura 4.11 Diagrama de Sequência do Serviço de Segurança - Criptografia

Quando determinado dispositivo deseja publicar uma mensagem, este invoca o métodoencrypt da classe Security, passando como parâmetro a mensagem a ser criptografada (msg). Oresultado desse processo é um array (vetor) de bytes. A chave de 128 bits utilizada para realizara criptografia e decriptografia é gerada por meio de uma chamada ao método (keyGenerator).O decrypt() fica responsável pela conversão das mensagens criptografadas para o seu estadooriginal (texto puro). Por se tratar de uma algoritmo simétrico, a chave utilizada para criptografaras mensagens enviadas também é aplicada no processo de decriptografia da mensagens recebidas.

A implementação desses dois mecanismos de segurança (autenticação e criptografia) sãosuficientes para impedir que dispositivos não autorizados ou mesmo invasores tenham acesso asfuncionalidades do xPresumo.

4.3.4 Gerenciamento de Eventos

No cenário de Internet das Coisas, a grande quantidade de coisas inteligentes gerandoeventos em tempo contínuo acaba por resultar em um alto volume de informações. Devido àrelevância dessas informações, é essencial que estas sejam armazenadas para posterior análises.

Todos os eventos gerados durante o monitoramento de determinado ambiente são persis-tidos (armazenados) em um banco de dados Orientado a Documentos. Optou-se por um SGBDNoSQL devido as inúmeras vantagens (flexibilidade, escalabilidade, desempenho, entre outros)em relação aos SGBD convencionais, principalmente em arquiteturas distribuídas.

O banco de dados escolhido para interagir com a arquitetura do xPresumo foi o MongoDB.O MongoDB é um SGBD NoSQL Orientado a Documentos que se adapta muito bem à comarquiteturas distribuídas. No contexto de IoT onde o volume de informações produzidas éextremamente elevado, a adoção do MongoDB foi muito importante. A MongoConnection

4.3. PROJETO 49

(Figura 4.12) é a classe responsável por realizar a conexão com o MongoDB e fazer a persistênciados dados.

Figura 4.12 Diagrama de Classe do Serviço de Gerenciamento de Eventos

Além de realizar a conexão com o banco de dados MongoDB, a classe MongoConnection

também possui métodos que permitem a persistência dos eventos gerados pelos dispositivos. Osatributos server e port são utilizados no processo de comunicação com o servidor MongoDB

via conexão Transmission Control Protocol (TCP). Os demais atributo (mongo, db, dbname,collection), são usados na conexão com banco de dados e nos métodos de acesso. O fluxode operação dos métodos da MongoConnection pode ser observado no diagrama de sequência(Figura 4.13).

Figura 4.13 Diagrama de Sequência do Serviço de Gerenciamento de Eventos

Na situação onde os dispositivos já se encontram cadastrados na base de dados queserá utilizada pelo xPresumo, é realizada uma chamada ao método verifyHash para liberar oacesso (autenticação) do dispositivo ao middleware. Após a etapa de autenticação, o processo depersistência dos dados inicia-se com a verificação do status da conexão realizada com o Servidorde Banco de Dados. Essa verificação é realizada através do verifyConnection(), retornando umvalor true caso o Servidor esteja online e o valor false em caso contrário.

Posteriormente à verificação de comunicação com o Servidor, é criado um objeto do tipoMongoClient. A partir do objeto MongoClient, é realizada a conexão com o banco de dados por

4.4. IMPLEMENTAÇÃO 50

meio do método getDB(), passando como parâmetro o nome da base de dados (dbname) a serutilizada. O atributo db do tipo DB possui o método getCollection() para acessar as coleçõesdo banco de dados. Se estas etapas tiverem sucesso, o método insertDataDB é invocado pararealizar a persistência dos eventos gerados pelos dispositivos.

4.4 Implementação

O xPresumo foi integralmente implementado na linguagem de programação Java e édistribuído como biblioteca. Para o desenvolvimento da solução algumas ferramentas foramutilizadas, a saber: o uso da Integrated Development Environment (IDE) Netbeans (NETBEANS(2016)) para implementação do código-fonte, o banco de dados MongoDB (KANADE; GOPAL;KANADE (2014)) para registrar os eventos gerados e o Robomongo (ROBOMONGO (2016))para gerenciamento da base de dados.


Esse capítulo apresentou a solução desenvolvida, o Middleware xPresumo. Apresentou-se um visão geral da arquitetura do middleware, descrevendo seus requisitos e detalhes de suasfuncionalidades (serviços) implementadas visando o contexto de Internet das Coisas.

O desenvolvimento do xPresumo foi completamente realizado utilizando a linguagemJava. A documentação do projeto foi realizada usando-se diagramas de classe e de se quênciaem UML.

Tendo por base os requisitos necessários à uma solução de middleware para Internet dasCoisas apresentados na Seção 1, o xPresumo exerce sua função de Middleware para IoT de modosatisfatório. Em relação a outras soluções de middleware desenvolvidas para o contexto de IoT ,o xPresumo se destaca por sua arquitetura leve no quesito tamanho e otimizada em relação aotempo de entrega das mensagens trocadas.

515151

5Avaliação Experimental

Este capítulo tem como foco apresentar uma avaliação de desempenho realizada noMiddleware xPresumo. A metodologia utilizada na avaliação da xPresumo foi baseada emJAIN (1991). Para a afetiva avaliação de desempenho do sistema, foi necessário realizar olevantamento de algumas informações essenciais ao cumprimento das seguintes etapas: (1)Definição do Sistema, (2) Identificação da Lista de Serviços, (3) Definição das Métricas deDesempenho, (4) Identificação dos Parâmetros do Sistema (PS) e de Carga de Trabalho (CT), (5)definição dos Fatores, (6) Seleção da Carga de Trabalho, (7) Planejamento dos Experimentos, (8)Interpretação dos Dados, e (9) Apresentação dos Resultados.

5.1 Definição do Sistema

A primeira etapa foi definir o objetivo da avaliação de desempenho, ou seja, o que sepretende avaliar em relação ao software desenvolvido. O foco dessa análise é a avaliação dedesempenho em sistemas que utilizam-se da troca de mensagens para se comunicar. Nestecontexto, será analisado o tempo de resposta que o xPresumo necessário à entrega de mensagens,sejam elas criptografadas ou não, a seus respectivos destinatários.

Como dito na Seção 4.2, a solução implementada consiste basicamente na comunicaçãoentre dispositivos utilizando o modelo Publisher/Subscriber, onde a troca de mensagens ébaseada no conceito de tópicos (Figura 5.1).

Figura 5.1 Definição do Middleware xPresumo

5.2. LISTA DE SERVIÇOS 52

5.2 Lista de Serviços

A Lista de Serviços do sistema, resume-se aos serviços oferecidos pela solução desenvol-vida. Normalmente um sistema provê um conjunto de serviços e para cada um deles existe umconjunto de possíveis resultados. No caso do xPresumo esta lista de serviços pode ser observadada Tabela 5.1.

Tabela 5.1 Lista de Serviços

5.3 Métricas de Desempenho

As Métricas de Desempenho são critérios que possibilitam mensurar componentes dosoftware de modo a identificar e corrigir possíveis problemas em relação ao desempenho. Nãoexiste uma definição padrão das métricas estabelecidas no contexto de avaliação, elas estãointrinsecamente ligadas às particularidades de cada sistema. A avaliação de desempenho doxPresumo se dará por meio das seguintes métricas:

� M1 - Tempo de resposta para adaptação;

� M2 - Tempo de resposta para desativar mecanismo de criptografia;

� M3 - Tempo de resposta no recebimento de mensagens;

� M4 - Tamanho dos objetos trocados;

Nas métricas onde o tempo é o foco da análise, utilizou-se a seguinte fórmula para seobter o tempo total: Ttotal = T1 −T0, onde T0 representa o momento em que a requisição foiiniciada e o T1 é o instante em que a requisição é concluída. No caso do xPresumo, o tempo écontabilizado a partir do envio e recebimento das mensagens. A unidade de tempo utilizada noscálculos foi a de milissegundos.

Não foram consideradas erros ou falhas no sistema. No experimento foram consideradas2 situações: na primeira, o envio de mensagens criptografadas, na segunda, o envio de mensagensnão criptografados.

5.4. LISTA DE PARÂMETROS 53

5.4 Lista de Parâmetros

Os parâmetros afetam diretamente o desempenho da solução implementada e estespodem ser divididos em Parâmetros do Sistema (PS) e de Carga de Trabalho (CT). Os PS sãocaracterísticas que geralmente não variam de uma instância do sistema para outra, nestes podemser incluídos parâmetros de hardware e software. Os parâmetros de CT são elementos bastantesvariáveis, têm relação direta com a carga de trabalho submetida ao sistema. Os parâmetrosidentificados no xPresumo podem ser visualizados na Tabela 5.2.

Tabela 5.2 Parâmetros do Sistema e de Carga de Trabalho

5.5 Fatores

Os fatores de desempenho são os parâmetros que podem sofrer variações, e estas podemimpactar diretamente no desempenho do sistema. Essas variações que podem ocorrer sãoclassificadas em níveis.

Uma boa prática na definição dos fatores a serem utilizados, é começar com o mínimode fatores e poucos níveis em cada, de modo a ir aumentando os níveis conforme necessidade.É interessante dar prioridade aos parâmetros que mais podem influenciar no desempenho. NoMiddleware xPresumo, o fatores e níveis podem ser observados na Tabela 5.3.

Tabela 5.3 Fatores de Desempenho

5.6. SELEÇÃO DA CARGA DE TRABALHO 54

5.6 Seleção da Carga de Trabalho

A seleção da carga de trabalho consiste em executar os componentes ou serviços dosistema que mais irão afetar seu desempenho. A carga representa a real utilização do sistemanaquele dado momento. Para monitoramento dos recursos utilizados, o uso de profilers se faznecessário. Os aplicativos do tipo profilers são capazes de medir desde o consumo de recursoscomputacionais até identificar gargalos de desempenho.

No contexto do xPresumo, será analisada o impacto causado na publicação de um númeroelevado de mensagens em um curto período de tempo. O xPresumo será submetido a uma cargade trabalho de 5.000 mensagens, ou seja, as mensagens serão enviadas e nesse processo seráanalisado o impacto causado ao xPresumo com base nos valores obtidos relacionados ao tempode resposta.

5.7 Planejamento dos Experimentos

Definidos os fatores e seus níveis, é necessário elaborar como os experimentos serãoconduzidos. A técnica de avaliação escolhida foi a medição, pois esta permite testar a soluçãodesenvolvida em uma situação muito próxima da real aplicação. Para efeito de testes, foramconsiderados quatro tipos de informações distintas a serem publicadas (Localização, Descoberta,Temperatura e Status).

As informações referentes à Localização, Descoberta e Status são características comunsa todos os dispositivos no cenário do xPresumo, exceto a Temperatura, particularidade somentede alguns dispositivos. Para cada uma das informações a serem publicadas, alguns elementosserão considerados para análise:

� Tempo total no processo de envio de mensagens;

� Tempo médio no processo de envio de mensagens;

� Definição de um Intervalo de Confiança;

Para a execução dos experimentos foram utilizadas 3 máquinas virtuais, com duasconfigurações de hardware distintas. Para a máquina virtual utilizada como servidor do xPresumo

foi atribuído 1GB de memória RAM e para as máquinas virtuais representando os dispositivos(coisas inteligentes), foi definida a quantidade de 512 MB de memória RAM. Ambas as máquinasvirtuais utilizaram um processador com duas unidades de processamento independentes (núcleo)e sistema operacional Microsoft Windows 7 (Arquitetura x64).

5.8 Interpretação dos Dados

Para efeito de avaliação de desempenho, inicialmente foi calculado o tempo necessáriopara criptografar e decriptografar as mensagens e o tempo gasto para identificar a necessidade de

5.9. APRESENTAÇÃO DOS RESULTADOS 55

desativar/ativar o módulo de criptografia nas mensagens. Posteriormente, foram calculados oTempo Total, Tempo Médio, Desvio Padrão e o Intervalo de Confiança.

No xPresumo, os experimentos foram realizados baseando-se no impacto de desempenhocausado pela publicação das mensagens entre dispositivos. Cada experimento consistiu no enviode um conjunto de 5.000 (cinco mil) mensagens com os seguintes intervalos de requisição: 100,200, 300, 400 e 500 ms (milissegundos).

No total foram realizados 40 experimentos, levando em consideração o tipo de informaçãoenviada (Localização, Descoberta, Temperatura e Status), os intervalos de requisição (100, 200,300, 400 e 500 ms) e o estado das mensagens trocadas (criptografadas e não criptografas). Paracada tipo de informação (Localização, Descoberta, Temperatura e Status), foram enviadas 5.000mensagens no total, iniciando com o envio de 500 mensagens criptografadas e a cada ciclo (1ciclo equivale a um total de 500 mensagens enviadas) de mensagens o módulo de criptografia sealternava entre ativado e desativado. O tempo de cada experimento varia entre 11 e 40 minutosdevido o intervalo de requisição. Por meio da interpretação desses dados foi possível fazer umaanálise do desempenho do xPresumo.

5.9 Apresentação dos Resultados

Antes da execução dos experimentos envolvendo o envio de mensagens, realizou-se umaverificação no impacto gerado no processo de criptografar e decriptografar as mensagens e napercepção da necessidade em ativar/desativar o módulo de criptografia dessas mensagens.

O tempo decorrido para realizar o processo de criptografar e decriptografar de umamensagem ou o inverso, pode ser observado na Tabela 5.4.

Tabela 5.4 M1 - Tempo de resposta para adaptação

Para obtenção dos resultados, foi enviado um total de 5.000 mensagens alternando entreos estados de criptografado e decriptografado. O processo consiste na alternância de estado(criptografado ou decriptografado) dentro de um ciclo de mensagens. No experimento realizado,foram realizadas 10 trocas, iniciando o primeiro ciclo com mensagens criptografadas e alternandode estado a cada 500 mensagens - um ciclo. A unidade de medida de tempo milissegundos foiutilizada para representação dos resultados. O gráfico da Figura 5.2 possibilita uma melhorcompreensão dessas informações.

Para averiguar o tempo decorrido para identificar a necessidade de ativar ou desativaro módulo de criptografia, utilizou-se a métrica M2, o experimento seguiu os mesmos critérios


Figura 5.2 M1 - Tempo de resposta para adaptação

utilizados na verificação de tempo para criptografar e decriptografar uma mensagem. Foramenviadas 5.000 mensagens e a cada ciclo de mensagens, foi verificado o tempo consumido peloxPresumo para identificar a necessidade de habilitar ou desabilitar o módulo de criptografia. ATabela 5.5 apresenta o tempo gasto conforme seus respectivos ciclos.

Tabela 5.5 M2 - Tempo de resposta para desativar mecanismo de criptografia

Devido ao curto período de tempo no processo de identificar a necessidade de ativar ounão o módulo de criptografia, o gráfico da Figura 5.3, permite um melhor entendimento.

Os experimentos realizados para se obter o desempenho do xPresumo em relação aoenvio de diferentes tipos de informações foram conduzidos do seguinte modo: inicialmentefoi realizada a medição para cada tipo de informação (Localização, Descoberta, Temperatura eStatus). No primeiro experimento, ocorre somente o envio de mensagens não criptografadas, jáno segundo, somente mensagens criptografadas. Nesses experimentos utilizou-se a métrica M3 eM4 para a análise de desempenho;

Tomando como exemplo as informações sobre a Localização; 5.000 mensagens cripto-grafadas são publicadas e registrado o tempo de resposta. Posteriormente um novo experimentoé realizado porém publicando 5.000 mensagens em formato original, sem criptografia. A Tabela5.6 mostra os valores dos experimentos realizados na publicação de informações referentes àLocalização de dispositivos.

Para cada intervalo de requisição, existem valores criptografados e não criptografados.As colunas da tabela na cor cinza representam os valores obtidos nos experimentos realizados


Figura 5.3 M2 - Tempo de resposta para desativar mecanismo de criptografia

Tabela 5.6 Tempo de Envio de Mensagens Criptografas e Não Criptografas (Localização)

com mensagens criptografas (objetos de 139 bytes), já as colunas na cor branca contém os valoresdos testes utilizando mensagens não criptografas (objetos de 111 bytes).

Devido a adição do módulo de segurança para criptografar as mensagens, identifica-secerto impacto no processo de publicação desses objetos. Conforme o intervalo de requisiçãoaumenta, esse impacto tende a ser minimizado. Na Figura 5.4, é possível visualizar os valores damédia e desvio padrão de cada grupo de experimentos.

Figura 5.4 M3 - Tempo de resposta no recebimento de mensagens (Localização)

Nos primeiros grupos de experimentos do gráfico, observa-se um considerável graude dispersão do desvio padrão em relação a média de tempo do envio das mensagens (barras


verticais de erros). Como pode ser observado na Tabela 5.7, mesmo com um intervalo derequisição de 100 ms, em média 75,7% das mensagens enviadas encontram-se dentro da faixa deum desvio padrão.

Tabela 5.7 Taxa de Valores no Intervalo do Desvio Padrão (Localização)

A Tabela 5.8 ilustra valores dos experimentos realizados na publicação de mensagensreferentes à Descoberta de dispositivos. As mensagens publicadas são objetos com tamanho de107 bytes (criptografados) e 79 bytes (sem criptografia).

Em análise preliminar, é possível concluir que os valores dos experimentos realizadosna publicação de informações referente a Descoberta de dispositivos, sofrem certa influênciadevido o intervalo de requisição. Entretanto, estas não têm impacto sobre o tempo necessário noprocesso de criptografia das mensagens. Observando o gráfico da Figura 5.5, visualizam-se osresultados da média populacional e desvio padrão dos experimentos realizados.

A partir das informações apresentadas no gráfico em questão, conclui-se que, por maisque os objetos enviados sejam de tamanho reduzidos, estes tiveram impacto no tempo decorridona publicação das mensagens. Porém, a média da diferença de tempo registrada entre asmensagens criptografadas publicadas e as mensagens não criptografadas é bastante reduzida,levando a crer que o tempo gasto em ambas as situações são similares (Tabela 5.9). Issodemonstra que o xPresumo possui um bom desempenho em relação ao tempo de resposta noenvio e recebimento de mensagens em ambas as situações, ou seja, com o mecanismos decriptografia ativado ou mesmo desativado.

Tabela 5.8 Tempo de Envio de Mensagens Criptografas e Não Criptografas (Descoberta)

Tabela 5.9 Taxa de Valores no Intervalo do Desvio Padrão (Descoberta)

Como pode ser observado na Tabela 5.9, a maior parte dos valores da distribuiçãonormal encontram-se dentro do intervalo de um desvio padrão. Isso demonstra que os resultados


Figura 5.5 M3 - Tempo de resposta no recebimento de mensagens (Descoberta)

obtidos no experimentos tiveram pouca variação de tempo no processo de encriptação e envio demensagens.

Os resultados dos experimentos realizados no envio de informações do tipo Tempe-ratura podem ser observados na Tabela 5.10. Nesse contexto, os objetos enviados de modocriptografados e sem criptografia assumem tamanhos de 43 bytes e 10 bytes, respectivamente.

Tabela 5.10 Tempo de Envio de Mensagens Criptografas e Não Criptografas (Temperatura)

O gráfico da Figura 5.6 apresenta a relação entre as médias dos resultados do experimen-tos e seus desvios padrões correspondentes, ou seja, o tempo de resposta obtido no envio demensagens até a sua entrega aos destinatários. Observando as informações do gráfico, nota-seuma mínima diferença de tempo entre os resultados dos experimentos realizados com o módulode criptografia ativado e desativado.

A Tabela 5.11 apresenta as informações sobre a taxa de valores obtidos nos experimentosque se encontram dentro do intervalo de um desvio padrão. Neste sentido, infere-se dos resultadosque em sua maior parte, estes se encontram acima de 90% dentro da faixa de um desvio padrão,tanto para mais quanto para menos em relação à média.

Tabela 5.11 Taxa de Valores no Intervalo do Desvio Padrão (Temperatura)

Os resultados dos experimentos realizados referentes ao Status dos dispositivos são


Figura 5.6 M3 - Tempo de resposta no recebimento de mensagens (Temperatura)

apresentados na Tabela 5.12. Nestes experimentos, o tamanho dos objetos assumem valoresde 10 bytes (sem criptografia) e 43 bytes (com criptografia). O gráfico da Figura 5.7 ilustraos resultados dos experimentos realizados com os objetos enviados. No gráfico é possívelobservar a média de tempo para cada conjunto de mensagens enviadas, conforme suas intervalode requisição.

Figura 5.7 M3 - Tempo de resposta no recebimento de mensagens (Status)

Nota-se que, assim como nos resultados dos experimentos anteriores, a diferença detempo entre o conjunto de mensagens criptografas e não criptografadas é mínimo. O desviopadrão (barras verticais de erros), se mantém em nível muito baixo, indicando um desempenhosatisfatório em relação a média do tempo decorrido no envio das mensagens.

Tabela 5.12 Tempo de Envio de Mensagens Criptografas e Não Criptografas (Status)

5.10. CONSIDERAÇÕES FINAIS 61

Em complemento as informações apresentadas no gráfico da Figura 5.7, constata-sepelos dados contidos na Tabela 5.13, que os resultados dos experimentos em todos os grupospermanecem acima de 98% dos teste dentro da margem de um desvio padrão em relação amédia de tempo. Isso comprova a uniformidade no tempo decorrido no envio das mensagens,independente do módulo de segurança estar ou não ativo; uma vantagem em ambientes IoT , ondenormalmente os dispositivos detém de limitados recursos computacionais e energéticos.

Tabela 5.13 Taxa de Valores no Intervalo do Desvio Padrão (Status)


Este capítulo teve foco nos experimentos realizados com o Middleware xPresumo. Oobjetivo foi avaliar o desempenho da solução em uma situação real. A metodologia de avaliaçãoseguiu uma sequência de etapas, todas elas descritas e explicadas no decorrer do capítulo.

Por meio dos resultados obtidos nos experimentos foi possível concluir que o xPresumo

mostrou-se eficiente em diversas situações onde se foi necessário o uso de sua capacidade deadaptação em relação ao modo de interação entre dispositivos (criptografada/decriptografada).

Em comparação, o tempo decorrido para publicar mensagens criptografadas e nãocriptografadas foi muito similar e consideravelmente baixo. Foi possível observar também aotimização no processo de encriptar e decriptografar mensagens conforme a necessidade domiddleware.

626262

6Conclusão

Este trabalho apresentou o xPresumo, uma arquitetura de Middleware Orientado àMensagens - MOM para o contexto de Internet das Coisas - IoT . Por se tratar de uma arquiteturamuito leve, o xPresumo tem um bom desempenho em dispositivos com limitados recursoscomputacionais. O projeto foi desenvolvido utilizando a API JMS, tendo como primitiva decomunicação o modelo Publish-Subscribe. O fato de optar pela primitiva Publish-Subscribe estárelacionado à realidade de IoT , onde os eventos são gerados em grande quantidade. Desse modo,a interação entre coisas inteligentes torna-se mais flexível e otimizada.

6.1 Contribuições

A principal contribuição deste trabalho foi o desenvolvimento de uma arquitetura deMOM com a capacidade de adaptação voltada ao paradigma de IoT . Atualmente o xPresumo

dispõe dos serviços de Localização e Descoberta de Dispositivos, Gerenciamento de Eventos,Ciência de Contexto e Segurança e Privacidade. Estes recursos foram adicionados ao mid-

dleware exclusivamente para atender as particularidades de IoT . Entretanto o xPresumo tem apossibilidade de expansão desses recursos e serviços do middleware conforme às necessidadesexigidas.

Os serviços implementados no xPresumo se mostraram bastante efetivos. O serviço deLocalização de Descoberta de Dispositivos, demostrou por meio de experimentos sua eficiênciaem termos de rapidez e consumo de recursos computacionais. Em um curto período de tempo,ambos os métodos possibilitam a localização geográfica dos dispositivos pertencentes a umadeterminada rede.

A capacidade de gerir os eventos ocorridos no ambiente de IoT são tratados pelo serviçode Gerenciamento de Eventos. A decisão em utilizar um banco de dados orientados a documentos(NoSQL) mostrou que essa estratégia direcionada ao gerenciamento de dados em larga escala,possibilita maior escalabilidade em IoT , evitando assim problemas futuros relacionados aoaumento na demanda de dados proveniente de novos dispositivos.

À arquitetura do xPresumo foi adicionado a capacidade de consciência sobre a situação

6.2. LIMITAÇÕES 63

de determinado ambiente. O serviço de Ciência de Contexto foi um recurso introduzido pensandonas variações que podem ocorrer no âmbito de Internet das Coisas. Por meio deste recurso,o xPresumo pode tomar decisões que visam preservar a eficiência do funcionamento de todainfraestrutura. Por meio de mensagens de controle é possível por exemplo, alterar o comporta-mento de mecanismos de segurança diante uma anormalidade em um determinado dispositivo.Essa capacidade de se adaptar conforme as circunstâncias, inclusive em tempo de execução, nãogera impacto significativo no desempenho do xPresumo, isso devido a simplicidade na estruturadessas mensagens de controle.

Os recursos de Segurança e Privacidade, mostraram-se apropriados ao cenário de Internetdas Coisas. Dada a importância das informações que trafegam pela rede, a segurança é umdos fatores de maior relevância e complexidade no contexto de IoT . No caso do xPresumo,as funções utilizadas para realizar a criptografia de mensagens e o processo de autenticaçãode dispositivos, não resultaram impactos consideráveis ao funcionamento do sistema. O usode criptografia simétrica possibilitou melhor desempenho sem comprometer a segurança dasmensagens e permissões de acesso.

Uma outra importante contribuição é ter a arquitetura do xPresumo como modelo dedesenvolvimento para novas soluções de middleware voltadas ao contexto de IoT .

6.2 Limitações

Nesse estudo foi possível observar que o xPresumo atende os requisitos essenciais aocontexto de IoT . Entretanto, a solução possui algumas limitações. Dentre estas limitações,ressalta-se a falta de mecanismos que possibilitem a interação entre dispositivos através demensagens persistentes.

Embora o xPresumo detenha a capacidade de ciência de contexto, esta limita-se ao estadodos dispositivos portadores de bateria. Sua função básica é analisar o nível energético da bateriados dispositivos e em de caso de nível crítico, a criptografia das mensagens é desativada até quea situação seja normalizada.

Outra limitação identificada na arquitetura do xPresumo está relacionada à segurança. Aarquitetura é vulnerável a ataques de força bruta para quebra da chave criptográfica. O algoritmosutilizados na criptografia simétrica são mais simples e favorecem o desempenho, porém estãosujeito a este tipo de ataque.

6.3 Trabalhos Futuros

As propostas de trabalhos futuros estão relacionados com o aperfeiçoamento dos recursosjá existentes, eliminando as limitações existentes apresentadas na Seção 6.2.

Possibilitar o uso de criptografia assimétrica nos mecanismos de segurança do xPresumo,considerando o mínimo de impacto no desempenho. Um grande desafio em se trabalhar com

6.3. TRABALHOS FUTUROS 64

criptografia assimétrica está no fato do gerenciamento de chaves públicas. Esse gerenciamentode chaves públicas é um recurso complexo no contexto de IoT , pois a cada novo dispositivo narede, será necessário a troca de chaves públicas entre todos os dispositivos já existentes. Esseprocesso pode gerar um impacto considerável no desempenho do middleware.

A realização de experimentos relacionados ao desempenho em dispositivos com proces-samento computacional limitado. Os experimentos realizados foram baseados em aplicaçõesdesenvolvidas em Java de modo simular dispositivos virtuais, não se utilizando de dispositi-vos físicos com poder computacional limitado. Em posteriores trabalhos, estuda-se o uso dedispositivos físicos para uma melhor acurácia na análise de desempenho do xPresumo.

Adotar o uso de ontologias de modo obter informações sobre dispositivos e suas fun-cionalidades, assim como a descoberta, localização e atualizações de dispositivos. O uso deontologias pode trazer inúmeros benefícios a solução desenvolvida, tornando-a mais otimizadana realização de tarefas que exijam a tomada de decisões. Como já mencionado, os benefíciosvão desde a localização de dispositivos até os serviços e recursos por eles fornecidos.

O uso de políticas de controle de acesso para definir o nível de permissão que cadadispositivo tem em relação aos demais recursos disponíveis. Este recurso poderá ser estendidoa todos os usuários do sistema. Com a adoção de políticas de controle de acesso será possívelum gerenciamento mais eficiente dos dispositivos em uma rede. Será possível por exemplo, emcaso de algum dispositivo se comportar de modo "estranho"gerando risco ao funcionamento dosistema, suas permissões de acesso podem ser revogadas evitando assim possíveis problemas. Ouso das políticas e as regras de acesso podem ser aplicados aos usuários do sistema, dificultandoque usuários mal intencionados possam comprometer o funcionamento do xPresumo.

Por fim, desenvolver recursos que possibilitem o gerenciamento de eventos (falhas/sucesso)e tomada de decisão baseadas nas técnicas de análise de Big Data (análise preditiva, análiseprescritiva, análise descritiva e análise diagnóstica). Dessa forma, levando a um melhor apro-veitamento dos dados produzidos e coletados das coisas inteligentes. Tornando possível àidentificação de possíveis problemas no funcionamento do xPresumo e até mesmo possibilitaruma melhor tomada de decisão com base na análise desses dados.

656565

Referências

ABERER, K.; HAUSWIRTH, M.; SALEHI, A. A Middleware for Fast and Flexible SensorNetwork Deployment. In: ND INTERNATIONAL CONFERENCE ON VERY LARGE DATABASES, 32. Proceedings. . . VLDB Endowment, 2006. p.1199–1202. (VLDB ’06).

AL-FUQAHA, A. et al. Internet of Things: a survey on enabling technologies, protocols,and applications. IEEE Communications Surveys Tutorials, [S.l.], v.17, n.4, p.2347–2376,Fourthquarter 2015.

ATZORI, L.; IERA, A.; MORABITO, G. The Internet of Things: a survey. Comput. Netw.,New York, NY, USA, v.54, n.15, p.2787–2805, Oct. 2010.

BANDYOPADHYAY, S. et al. Role of middleware for internet of things: a study. InternationalJournal of Computer Science & Engineering Survey (IJCSES), [S.l.], v.2, n.3, p.94–105,2011.

BERNARD, G. Invited Paper: middleware for next generation distributed systems: main chal-lenges and perspectives. In: DATABASE AND EXPERT SYSTEMS APPLICATIONS, 2006.DEXA ’06. 17TH INTERNATIONAL WORKSHOP ON. Anais. . . [S.l.: s.n.], 2006. p.237–240.

BERNSTEIN, P. A. Middleware: a model for distributed system services. Commun. ACM,New York, NY, USA, v.39, n.2, p.86–98, Feb. 1996.

BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usuário. [S.l.]: CAMPUS - RJ,2006.

CANNATA, A.; GEROSA, M.; TAISCH, M. SOCRADES: a framework for developing intel-ligent systems in manufacturing. In: IEEE INTERNATIONAL CONFERENCE ON INDUS-TRIAL ENGINEERING AND ENGINEERING MANAGEMENT, 2008. Anais. . . [S.l.: s.n.],2008. p.1904–1908.

CHAQFEH, M.; MOHAMED, N. et al. Challenges in middleware solutions for the internet ofthings. In: COLLABORATION TECHNOLOGIES AND SYSTEMS (CTS), 2012 INTERNATI-ONAL CONFERENCE ON. Anais. . . [S.l.: s.n.], 2012. p.21–26.

COULOURIS, G. et al. Distributed Systems: concepts and design. [S.l.]: Pearson Education,2011.

COUTURE, N.; KENT, K. B. The effectiveness of brute force attacks on RC4. In: SECOND AN-NUAL CONFERENCE ON COMMUNICATION NETWORKS AND SERVICES RESEARCH,2004. Proceedings. . . [S.l.: s.n.], 2004. p.333–336.

REFERÊNCIAS 66

CURRY, E. Message-oriented middleware. Middleware for communications, [S.l.], p.1–28,2004.

DELICATO, F.; PIRES, P.; BATISTA, T. Middleware Solutions for the Internet of Things.[S.l.]: Springer London, 2013. (SpringerBriefs in Computer Science).

GIUSTO, D. et al. (Ed.). HYDRA: a development platform for integrating wireless devices andsensors into ambient intelligence systems. New York, NY: Springer New York, 2010. 367–373p.

EMMERICH, W. Software Engineering and Middleware: a roadmap. In: CONFERENCE ONTHE FUTURE OF SOFTWARE ENGINEERING, New York, NY, USA. Proceedings. . . ACM,2000. p.117–129. (ICSE ’00).

FERSI, G. Middleware for Internet of Things: a study. In: DISTRIBUTED COMPUTINGIN SENSOR SYSTEMS (DCOSS), 2015 INTERNATIONAL CONFERENCE ON. Anais. . .[S.l.: s.n.], 2015. p.230–235.

FUKS, H. et al. Arquiteturas distribuídas para sistemas colaborativos. In: Sistemas Colaborati-vos. [S.l.: s.n.], 2012. p.328–347.

GAMMA, E. et al. Design patterns: elements of reusable object-oriented software. [S.l.]:Pearson Education, 1994.

JAIN, R. The Art of Computer Systems Performance Analysis: techniques for experimentaldesign, measurement, simulation, and modeling. [S.l.]: Wiley, 1991.

JINGYONG, L. et al. Middleware-based Distributed Systems Software Process. In: INTERNA-TIONAL CONFERENCE ON HYBRID INFORMATION TECHNOLOGY, 2009., New York,NY, USA. Proceedings. . . ACM, 2009. p.345–348. (ICHIT ’09).

KANADE, A.; GOPAL, A.; KANADE, S. A study of normalization and embedding in Mon-goDB. In: IEEE INTERNATIONAL ADVANCE COMPUTING CONFERENCE (IACC), 2014.Anais. . . [S.l.: s.n.], 2014. p.416–421.

KRAKOWIAK, S. Middleware Architecture with Patterns and Frameworks. , [S.l.], 2007.

BASSI, A. et al. (Ed.). Introduction to the Internet of Things. Berlin, Heidelberg: SpringerBerlin Heidelberg, 2013. 1–10p.

KRcO, S.; POKRIc, B.; CARREZ, F. Designing IoT architecture(s): a european perspective. In:IEEE WORLD FORUM ON INTERNET OF THINGS (WF-IOT), 2014. Anais. . . [S.l.: s.n.],2014. p.79–84.

LI, S. et al. IoT Middleware Architecture over Information-Centric Network. In: GLOBECOMWORKSHOPS (GC WKSHPS), 2015 IEEE. Anais. . . [S.l.: s.n.], 2015. p.1–7.

REFERÊNCIAS 67

LIU, T.; MARTONOSI, M. Impala: a middleware system for managing autonomic, parallelsensor systems. In: NINTH ACM SIGPLAN SYMPOSIUM ON PRINCIPLES AND PRACTICEOF PARALLEL PROGRAMMING, New York, NY, USA. Proceedings. . . ACM, 2003. p.107–118. (PPoPP ’03).

MADDEN, S.; HELLERSTEIN, J.; HONG, W. TinyDB: in-network query processing in tinyos., [S.l.], 2003.

MADDEN, S. R. et al. TinyDB: an acquisitional query processing system for sensor networks.ACM Trans. Database Syst., New York, NY, USA, v.30, n.1, p.122–173, Mar. 2005.

MAINETTI, L.; PATRONO, L.; VILEI, A. Evolution of wireless sensor networks towards theinternet of things: a survey. In: SOFTWARE, TELECOMMUNICATIONS AND COMPUTERNETWORKS (SOFTCOM), 2011 19TH INTERNATIONAL CONFERENCE ON. Anais. . .[S.l.: s.n.], 2011. p.1–6.

MIORANDI, D. et al. Internet of things: vision, applications and research challenges. Ad HocNetworks, [S.l.], v.10, n.7, p.1497–1516, 2012.

NAGY, M. et al. Challenges of middleware for the internet of things. [S.l.]: INTECH OpenAccess Publisher, 2009.

NETBEANS, I. Disponível em:<https://netbeans.org>. Acesso em: 2016, [S.l.], v.8.2, 2016.

PANDYA, H. B.; CHAMPANERIA, T. A. Internet of things: survey and case studies. In:INTERNATIONAL CONFERENCE ON ELECTRICAL, ELECTRONICS, SIGNALS, COM-MUNICATION AND OPTIMIZATION (EESCO), 2015. Anais. . . [S.l.: s.n.], 2015. p.1–6.

PIETZUCH, P. R. Hermes: a scalable event-based middleware. [S.l.: s.n.], 2004.

PINUS, H. Middleware: past and present a comparison. In: AVAILABLE: HTTP://USERPAGES.UMBC. EDU/˜ DGORIN1/451/MIDDLEWARE/MIDDLEWARE. PDF. Anais. . . [S.l.: s.n.],2004.

PRASITHSANGAREE, P.; KRISHNAMURTHY, P. Analysis of energy consumption of RC4 andAES algorithms in wireless LANs. In: GLOBAL TELECOMMUNICATIONS CONFERENCE,2003. GLOBECOM ’03. IEEE. Anais. . . [S.l.: s.n.], 2003. v.3, p.1445–1449 vol.3.

PRESUMO. Disponível em:<http://presumo.sourceforge.net/hld.pdf>. Acesso em: 2016, [S.l.],v.0.2, 2016.

PUDER, A.; RÖMER, K.; PILHOFER, F. Distributed systems architecture: a middlewareapproach. [S.l.]: Elsevier, 2006.

REFERÊNCIAS 68

RAZZAQUE, M. A. et al. Middleware for Internet of Things: a survey. IEEE Internet ofThings Journal, [S.l.], v.3, n.1, p.70–95, Feb 2016.

ROBOMONGO. Disponível em:<https://robomongo.org>. Acesso em: 2016, [S.l.], v.0.9, 2016.

SILVA, J. R. et al. PRISMA: a publish-subscribe and resource-oriented middleware for wirelesssensor networks. 2014.

SILVEIRA, G. et al. Introdução à Arquitetura de Design de Software: uma introdução àplataforma java. [S.l.]: Elsevier Brasil, 2011.

SINGHAL, N.; RAINA, J. Comparative analysis of AES and RC4 algorithms for better utilization., [S.l.], 2011.

SOUSA, J. a. P.; GARLAN, D. Aura: an architectural framework for user mobility in ubiquitouscomputing environments. In: IFIP 17TH WORLD COMPUTER CONGRESS - TC2 STREAM/ 3RD IEEE/IFIP CONFERENCE ON SOFTWARE ARCHITECTURE: SYSTEM DESIGN,DEVELOPMENT AND MAINTENANCE, Deventer, The Netherlands, The Netherlands. Pro-ceedings. . . Kluwer: B.V., 2002. p.29–43. (WICSA 3).

TAN, J.; KOO, S. G. M. A Survey of Technologies in Internet of Things. In: IEEE INTERNA-TIONAL CONFERENCE ON DISTRIBUTED COMPUTING IN SENSOR SYSTEMS, 2014.Anais. . . [S.l.: s.n.], 2014. p.269–274.

VILLA, D. et al. A dynamically reconfigurable architecture for smart grids. IEEE Transactionson Consumer Electronics, [S.l.], v.57, n.2, p.411–419, May 2011.

WHITMORE, A.; AGARWAL, A.; DA XU, L. The Internet of Things - A survey of topics andtrends. Information Systems Frontiers, [S.l.], v.17, n.2, p.261–274, 2014.

YICK, J.; MUKHERJEE, B.; GHOSAL, D. Wireless sensor network survey. ComputerNetworks, [S.l.], v.52, n.12, p.2292 – 2330, 2008.

pós-graduação em ciência da computação · 2019-10-26 · winder faik de sousa . xpresumo ±...

Documents