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 posgraduacao@cin.ufpe.br 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.
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 pela capacidade 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 que tiveram 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 contribuindo de forma positiva para o enriquecimento de minha formação profissional.
Ao professor Doutor Nelson Souto Rosa, pela disponibilidade e oportunidade a mim dada. Pela sabedoria, seriedade, paciência e compreensão que sempre teve comigo no papel de orientador.
A todos os amigos da turma do Mestrado Profissional em Redes 2014, em especial aos parceiros de Goiás, Alfredo Pupak, Daniel Bernardes e Ricardo, que sempre estiveram juntos nas dificuldades enfrentas.
Ao Instituto Federal de Goiás pela oportunidade em participar do Mestrado Profissional ofertado pela Universidade Federal do Pernambuco - UFPE.
Por fim, agradeço a todos àqueles que contribuíram de alguma forma, seja ela direta ou indiretamente para a realização de mais essa etapa na minha vida.
Resumo
Ambientes que antes eram desprovidos de tecnologia, hoje incorporam inúmeros objetos inteligentes (smartphones, smartwatch, smartglass, smart tv, entre outros) interagindo entre si. A comunicação entre esses objetos, na maioria das vezes distintos, trocando informações sobre determinado contexto, resume-se no conceito de Machine-to-Machine (M2M). A expansão desses objetos interconectados transformando ambientes comuns em ambientes inteligentes deu origem ao paradigma de Internet das Coisas - Internet of Things (IoT). Em virtude da relação entre mundo físico e mundo virtual proporcionada pela IoT, diversas aplicações tecnológicas nos mais diversos seguimentos poderão ser concretizadas. Entretanto, muitos desafios devem ser considerados na efetiva implantação desses recursos tecnológicos. Fatores voltados à complexidade na infraestrutura de comunicação e gerenciamento de diversos dispositivos no contexto de IoT (diversidade de dispositivos, tecnologias de redes distintas, entre outros), deixam evidente a necessidade de solucionar desafios como a heterogeneidade. Uma solução proposta para esse e outros 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 inicialmente um levantamento sistemático das principais soluções de middleware desenvolvidas no contexto de IoT. Posteriormente, foram identificados requisitos funcionais e não funcionais, modelos de distribuiçã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áveis ao ambiente de IoT, tal como, serviço de localização, adaptação dinâmica, segurança e assim por diante. A solução proposta, chamada xPresumo, reúne os principais recursos necessários à uma arquitetura de Middleware para IoT, levando em consideração desempenho e armazenamento limitado dos dispositivos. No quesito desempenho, o xPresumo se mostrou bastante estável nos experimentos realizados na troca de mensagens entre dispositivos.
Abstract
Environments where no technology was available before incorporate nowadays several smart 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 a particular context, may be summarized in the definition of Machine-to-Machine (M2M). From the expansion of these interconnected things, where common environments are changed into smart ones, the paradigm of Internet of Things (IoT) was born. Due to the relation between the real and virtual worlds provided by the IoT, several technological uses, in diverse fields, may be implemented. However, lots of challenges must be taken into consideration when effectively implementing the aforementioned technological resources. Issues concerning the complexity in 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 the need for solving problems such as heterogeneity. A solution proposed for this specific issue and others as well in the scenario of IoT would be the adoption of middleware architecture, in case a Message Oriented Middleware (MOM). In this research, primarily, a systematic search of the main solutions of middleware developed in the context of the IoT was done. Then, the requisites, both functional and non-functional, ones were identified, as well as the distribution models and in which domains of application these middleware solutions have been applied. The proposed solution, named as xPresumo, comprises the main necessary resources of Middleware architecture for IoT, and takes into account performance and limited storage of the devices.
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)) . . . 20
2.3 Arquitetura de Middleware (KRAKOWIAK(2007)) . . . 20
2.4 Arquitetura Cliente/Servidor (PUDER; RÖMER; PILHOFER(2006)) . . . 21
2.5 Chamadas Remotas de Procedimentos . . . 21
2.6 Arquitetura do Middleware Transacional (BERNSTEIN(1996)) . . . 22
2.7 Fluxo de Transações no Middleware Transacional . . . 23
2.8 Esquema de Invocação Simplificado em Middleware Orientado à Objetos (MOO) 23 2.9 Arquitetura de Middleware Orientado a Mensagens . . . 25
2.10 Modelo de Mensagem Point-to-Point . . . 25
2.11 Modelo de Mensagem Publish/Subscriber . . . 25
2.12 Arquitetura de Middleware para Internet das Coisas . . . 26
2.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 . . . 41
4.2 Arquitetura do Middleware xPresumo . . . 41
4.3 Diagrama de Classe do Serviço de Localização . . . 43
4.4 Diagrama de Sequência do Serviço de Localização . . . 44
4.5 Diagrama de Sequência do Serviço de Descoberta . . . 44
4.6 Diagrama de Classe do Serviço de Ciência de Contexto . . . 45
4.7 Diagrama de Sequência do Serviço de Ciência de Contexto . . . 45
4.8 Diagrama de Classe do Serviço de Segurança - Autenticação . . . 46
4.9 Diagrama de Sequência do Serviço de Segurança - Autenticação . . . 47
4.10 Diagrama de Classe do Serviço de Segurança - Criptografia . . . 47
4.11 Diagrama de Sequência do Serviço de Segurança - Criptografia . . . 48
4.12 Diagrama de Classe do Serviço de Gerenciamento de Eventos . . . 49
4.13 Diagrama de Sequência do Serviço de Gerenciamento de Eventos . . . 49
5.1 Definição do Middleware xPresumo . . . 51
5.2 M1 - Tempo de resposta para adaptação . . . 56
5.3 M2 - Tempo de resposta para desativar mecanismo de criptografia . . . 57
5.4 M3 - Tempo de resposta no recebimento de mensagens (Localização) . . . 57
5.6 M3 - Tempo de resposta no recebimento de mensagens (Temperatura) . . . 60 5.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) . . . 31
3.2 Desafios versus Modelos de Distribuição de um Middleware para IoT (FERSI (2015)) . . . 32
3.3 Recursos de Middleware para IoT (BANDYOPADHYAY et al.(2011)) . . . 33
3.4 Interfaces de Middleware para IoT (BANDYOPADHYAY et al.(2011)) . . . . 33
3.5 Comparação entre Soluções de Middleware para IoT . . . 38
5.1 Lista de Serviços . . . 52
5.2 Parâmetros do Sistema e de Carga de Trabalho . . . 53
5.3 Fatores de Desempenho . . . 53
5.4 M1 - Tempo de resposta para adaptação . . . 55
5.5 M2 - Tempo de resposta para desativar mecanismo de criptografia . . . 56
5.6 Tempo de Envio de Mensagens Criptografas e Não Criptografas (Localização) . 57 5.7 Taxa de Valores no Intervalo do Desvio Padrão (Localização) . . . 58
5.8 Tempo de Envio de Mensagens Criptografas e Não Criptografas (Descoberta) . 58 5.9 Taxa de Valores no Intervalo do Desvio Padrão (Descoberta) . . . 58
5.10 Tempo de Envio de Mensagens Criptografas e Não Criptografas (Temperatura) 59 5.11 Taxa de Valores no Intervalo do Desvio Padrão (Temperatura) . . . 59
5.12 Tempo de Envio de Mensagens Criptografas e Não Criptografas (Status) . . . . 60
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 MiddlewareTransacional . . . 20
M2M Machine-to-Machine. . . 18
MOM MiddlewareOrientado à Mensagens . . . 17
MOO MiddlewareOrientado à 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
Sumário
1 Introdução 14
1.1 Motivação . . . 14
1.2 Problema . . . 15
1.3 Limitações do Estado da Arte . . . 16
1.4 Objetivo . . . 17
1.5 Organização da Dissertação . . . 17
2 Conceitos Básicos 18 2.1 Internet das Coisas - IoT . . . 18
2.2 Middleware . . . 20
2.2.1 Middleware Procedural - RPC . . . 21
2.2.2 Middleware Transacional - MT . . . 22
2.2.3 Middleware Orientado a Objeto - MOO . . . 23
2.2.4 Middleware Orientado a Mensagens - MOM . . . 24
2.3 Middleware para IoT . . . 25
2.4 Middleware Presumo . . . 28
2.5 Considerações Finais . . . 29
3 Trabalhos Relacionados 30 3.1 Soluções de Middleware para Internet das Coisas . . . 30
3.1.1 Middleware Baseado em Eventos . . . 34
3.1.2 Middleware Baseado em Agentes . . . 35
3.1.3 Middleware Orientado à Serviços . . . 36
3.1.4 Middleware Orientado a Banco de Dados . . . 37
3.2 Sumário de Comparações . . . 38 3.3 Considerações Finais . . . 38 4 Middleware xPresumo 39 4.1 Requisitos . . . 39 4.2 Arquitetura . . . 40 4.3 Projeto . . . 43 4.3.1 Localização e Descoberta . . . 43 4.3.2 Ciência de Contexto . . . 44 4.3.3 Segurança . . . 46 4.3.4 Gerenciamento de Eventos . . . 48 4.4 Implementação . . . 50
4.5 Considerações Finais . . . 50 5 Avaliação Experimental 51 5.1 Definição do Sistema . . . 51 5.2 Lista de Serviços . . . 52 5.3 Métricas de Desempenho . . . 52 5.4 Lista de Parâmetros . . . 53 5.5 Fatores . . . 53
5.6 Seleção da Carga de Trabalho . . . 54
5.7 Planejamento dos Experimentos . . . 54
5.8 Interpretação dos Dados . . . 54
5.9 Apresentação dos Resultados . . . 55
5.10 Considerações Finais . . . 61 6 Conclusão 62 6.1 Contribuições . . . 62 6.2 Limitações . . . 63 6.3 Trabalhos Futuros . . . 63 Referências 65
14 14 14
1
Introdução
O conceito de Internet das Coisas, ou Internet of Things (IoT), não é algo novoKRAMP;
KRANENBURG; LANGE(2013). O paradigma de Internet das Coisas assume que objetos
comuns, dispondo de um mínimo de “inteligência” computacional, tenham a capacidade de interagir entre si ou mesmo com usuários finais por meio de uma rede provendo algum tipo de serviç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 de uma plataforma de middleware, proporcionando assim abstração às aplicações dos dispositivos
BANDYOPADHYAY et al.(2011).
Ressaltam-se que os desafios em IoT vão além da heterogeneidade, segundoCHAQFEH; MOHAMED et al.(2012) estes são: interoperabilidade, escalabilidade, provisionamento de abstraçã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 no desenvolvimento de sistemas de middleware mais robustos capazes de minimizarem ou mesmo solucionarem tais problemas voltados ao contexto de IoT.
1.1
Motivação
Atualmente, percebe-se uma grande presença de coisas inteligentes conectadas nos mais diversos 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 desenvolvimento de aplicações distribuídas.
Com foco na interação entre objetos distintos e para possibilitar a interoperabilidade entre inúmeros dispositivos envolvidos em ambientes extremamente heterogêneoMIORANDI et al.(2012), uma possível solução para demanda de IoT é o desenvolvimento de uma plataforma de middleware, proporcionando assim abstração a nível de aplicação e de hardware, além do fornecimento de múltiplos serviçosBANDYOPADHYAY et al.(2011).
1.2. PROBLEMA 15 Na literatura, encontram-se diversas soluções de middleware já propostas. Devido a complexidade no desenvolvimento para IoT muitas delas resumem-se em proposições teóricas sobre "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 desenvolvidaEISENHAUER; 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 o surgimento 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 na complexidade envolvida no desenvolvimento de soluções de middleware e de aplicações capazes de gerenciar as solicitações dentro deste contexto.
As soluções de middleware voltadas para ambientes multi-domínios buscam solucionar boa parte dos problemas relacionados à heterogeneidade. Ao mesmo tempo, elas acabam por exigir muito dos recursos dos dispositivos (tais como, memória, processamento, bateria, assim por diante), inviabilizando o uso de dispositivos com recursos computacionais limitados.
Em um cenário onde tudo está conectado, independente do poder computacional do dispositivo, nota-se a necessidade no desenvolvimento de uma arquitetura de middleware para IoT multi-domínio, robusta e otimizada, capaz de absorver o máximo da complexidade possível das 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 colaborativosFUKS et al.(2012), fornecendo um conjunto de abstrações de programação, a fim de facilitar a integração e a comunicação de componentes heterogêneos
FERSI(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 uma padronização no desenvolvimento de aplicações e de sistemas distribuídosCOULOURIS et al.
(2011).
Em suma, uma solução de middleware absorve as complexidades existentes em ambientes distribuídos, facilitando o desenvolvimento de aplicações nesse contexto. Entretanto, pode-se observar que há uma contínua busca por um padrão de middleware que seja capaz de extinguir todas as complexidades envolvidas no paradigma de IoT.
Normalmente os cenários de IoT são formados por diversas tecnologias interagindo entre si. Essa heterogeneidade somada à capacidade limitada de hardware dos dispositivos, dificulta muito 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 de Middlewarepara IoT que seja capaz de tratar todos os desafios no paradigma de Internet das Coisas 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 das Coisas devem tratar os desafios provenientes do contexto de IoT. A busca pelo desenvolvimento de soluções capazes de absorverem as particularidades em ambientes ubíquos originou-se com o advento das Redes de Sensores e são muito similares na Internet das Coisas.
Baseando-se nas afirmações apontadas porBANDYOPADHYAY et al.(2011) e CHAQ-FEH; MOHAMED et al.(2012), as muitas arquiteturas de middleware desenvolvidas não são capazes de cumprir o conjunto de exigências impostas no cenário de IoT.
Considerada em muitos estudos como uma arquitetura de middleware promissora no contexto de IoT, a HydraEISENHAUER; ROSENGREN; ANTOLIN(2010) atende em parte os desafios apresentados na Seção 1. Entretanto, devido ao uso de virtualização na implementação da solução de segurança e privacidade, ataques do tipo side-channel attack podem ser uma preocupaçãoRAZZAQUE et al.(2016). Esse tipo de ataque procura explorar vulnerabilidades no algoritmo criptográfico por meio de informações físicas mensuráveis como tempo, energia consumida e radiação eletromagnética dos dispositivos.
O Middleware TinyDB foi uma das primeiras soluções desenvolvidas com a capacidade de abstração de dispositivos, ou seja, a possibilidade de cooperação entre dispositivos distintos. Um dos pontos negativos da solução está na falta de abstração de sistemas, ou seja, seu funcionamento depende exclusivamente da utilização do Sistema Operacional (S.O.) TinyOS (MADDEN et al.
(2005)).
A solução apresentada emNAGY et al.(2009) é o resultado da proposição de um modelo semântico inteligente para Internet das Coisas. Mesmo com os diversos recursos disponíveis na arquitetura, os desafios voltados à interoperabilidade e segurança não são solucionados como pode ser visto emBANDYOPADHYAY 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. Cada domínio de aplicação possui suas particularidades e o desenvolvimento de uma arquitetura única capaz 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 como a padronização de arquitetura, provisionamento de interface para o usuário, capacidade de armazenamento, 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ão existe uma padronização única a ser seguida dentro de um domínio específico no desenvolvimento dessas arquiteturas. As características de cada solução normalmente seguem um padrão próprio de desenvolvimento, com os requisitos funcionais e não funcionais que acreditam ser necessárias ao contexto de IoT.
O principal objetivo dessa dissertação é o desenvolvimento de uma arquitetura de Mid-dlewareOrientado à Mensagens para Internet das Coisas com capacidade de adaptação. Para concretizar esse objetivo foi realizado um estudo sistemático do atual contexto de soluções de Middlewarepara Internet das Coisas serão identificadas as características essenciais ao desenvol-vimento de um Middleware para IoT (tal como, padronização, arquitetura, requisitos funcionais e não funcionais).
Identificadas as características desejáveis de um Middleware para o cenário de Internet das 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ão abordados conceitos relativos à Internet das Coisas, Middleware, Arquiteturas de Software Distribuí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 uma posterior 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.
18 18 18
2
Conceitos Básicos
Neste capítulo, introduziremos os principais conceitos necessárias ao entendimento do Middleware xPresumo. Será apresentado um resumo sobre diversos assuntos de relação direta com 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ínimo
de recursos computacionais, interagindo entre si Machine-to-Machine (M2M) ou com usuários do sistema, de modo a executar um objetivo definidoTAN; KOO(2014).
O RFID é uma tecnologia de comunicação de curto alcance em que etiquetas/tags se comunicam 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 individuais no 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 comunicar por 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 outros objetos, como temperatura, umidade, movimento e quantidade. Quando vários sensores são usados juntos e interagem, eles formam uma Redes de Sensores Sem Fio (RSSF). Ressalta-se que a interação entre diferentes tecnologias originou-se por meio das RSSF, que posteriormente venho 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, os atuadores executam ações para afetar de algum modo o meio ambiente ou objeto. Os atuadores tem 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. Pelo contrário, sua importância será ainda mais evidente, exercendo a função de espinha dorsal para compartilhamento 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 tecnologiasATZORI; IERA;
MORABITO(2010).
SegundoATZORI; IERA; MORABITO(2010), a Internet das Coisas vem ganhando espaç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 por reunir 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 preocupam e são focos de diversos estudosPANDYA; CHAMPANERIA(2015).
Figura 2.1 Principais Domínios de Aplicações e Cenários RelevantesATZORI; IERA; MORABITO
(2010)
No intuito de enfrentar os desafios existentes em Internet das Coisas, diversos estudos propõem que a adoção de uma arquitetura dividida em camadas (Figura 2.2) seria a melhor alternativa. No entanto, nenhuma das propostas apresentadas até então evoluiu para um modelo de referênciaKRˇcO; POKRI´c; CARREZ(2014). Os principais modelos de arquitetura presentes atualmente na literatura são: a) Baseado em três camadas (Camadas de Aplicação, Rede e Conhecimento); b) Baseado em Middleware; c) Baseado em Service-Oriented Architecture (SOA) e; d) Baseado em cinco camadas (Camada de Negócios, Aplicação, Gerenciamento de Serviç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ções compostas por uma camada de middleware demonstram ser uma estrutura promissora na tratativa dos desafios em Internet das Coisas. Neste sentido, muitas arquiteturas de middleware para IoT têm sido desenvolvidas, buscando integrar ao máximo os diversos domínios de aplicação existentes 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 sistema operacional (S.O.) e as aplicações distribuídas. As aplicações distribuídas são componentes lógicos localizados em dispositivos interligados que se comunicam e coordenam suas ações apenas por mensagens (COULOURIS et al.(2011)).
Em termos de funcionalidade, uma arquitetura de middleware pode ser definida como sendo um software capaz de abstrair ao máximo a complexidade existente no desenvolvimento e execução de sistemas em ambientes distribuídos (FUKS et al.(2012)). ConformeCOULOURIS et 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 da infraestrutura 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ídos controlando a consistência dos dados distribuídosFUKS 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ão exclusivos de uma única arquitetura (COULOURIS et al.(2011)).
SegundoFUKS 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 como primitiva 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 base as 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 locais ou remotos (CURRY(2004)). Essa comunicação normalmente é realizada de forma síncrona, onde o cliente permanece bloqueado à espera da resposta do servidor, comumente chamado de protocolo 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 a heterogeneidade existente entre clientes. A cada chamada de procedimento, o middleware tem a responsabilidade de converter os dados de modo a torná-los inteligíveis entre plataformas. Esse processo ocorre em duas etapas: 1) serialização (marshalling), quando os dados são convertidos para que possam ser enviados e; 2) desserialização (unmarhalling), onde os dados recebidos são convertidos na estrutura de dados originais (FUKS et al.(2012)). Esse processo, possibilita de forma transparente, a interação remota entre aplicativos distintos.
2.2. MIDDLEWARE 22 Como pode ser observado, o Middleware Procedural oculta aspectos importantes da distribuição, incluindo a codificação e a decodificação de parâmetros e resultados, a passagem de mensagens e a preservação da semântica exigida para a chamada de procedimento (COULOURIS et al. (2011)). Porém, esse tipo de arquitetura não suporta escalabilidade, confiabilidade e invocaçõ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ção de 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 e sincronização nas solicitações entre clientes e servidoresPINUS(2004).
Figura 2.6 Arquitetura do Middleware Transacional (BERNSTEIN(1996))
A primitiva de interação do Middleware Transacional, envolve a combinação de RPC associada a um controle de transação que implementa o protocolo two phase commit (2PC), ou seja, as transações são realizadas em duas fases. Na primeira fase assegura-se a disponibilidade de recursos necessários para a concretizar a transação. Na segunda fase, são executados comandos necessários para efetivação da transação. Caso alguma das bases distribuídas não consiga realizar uma das fases, a transação não é efetivada (FUKS et al.(2012)).
O MT tem suporte à heterogeneidade em diferentes níveis (software/hardware). Isso pode ser observado na capacidade de gerenciamento de transações entre Sistema de Gerenciamento de Banco de Dados (SGBD) distintos. Entretanto, o MT não suporta muito bem a heterogeneidade de dados, porque não pode expressar estruturas de dados complexas e, portanto, não pode organizar essas estruturas PINUS (2004). A Figura 2.7 ilustra o processo de comunicação realizado através do Middleware Transacional.
Uma vantagem da arquitetura transacional é no fato de ser implementar o conjunto de propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade). Porém no quesito 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 essa responsabilidade ao middleware (PINUS(2004)).
As principais soluções baseadas em MT são: CICS da IBM, Tuxedo da BEA e Encina da Transarc(EMMERICH(2000)).
2.2.3
Middleware Orientado a Objeto - MOO
Pode-se dizer que o Middleware Orientado a Objeto é uma melhoria da arquitetura procedural (RPC), onde a comunicação entre objetos distribuídos ocorre por meio de um serviço para 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 que um cliente solicite uma operação a um objeto do servidor em outro host. Porém, é necessário o prévio conhecimento por parte do cliente à referência ao objeto do servidor. O processo de serialização dos parâmetros para a solicitação de rede é feito automaticamente nos stubs do cliente e do servidor (PINUS(2004)). A comunicação realizada no MOO pode ocorrer tanto de modo 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 que ocorre 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ário específico e transmitida para um servidor usando a rede subjacente. Do lado do servidor, a invocação é reconstruída e finalmente chega ao objeto. A resposta retorna ao cliente de modo inverso (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 os objetos 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 heterogeneidade de dados entre plataformas (EMMERICH(2000)).
Em relação à confiabilidade, o MOO lida com as falhas durante as solicitações de componentes por meio de exceções. Caso a operação não seja executada, o cliente será informado da falha. Entretanto, a tolerância a falhas não é um fator de grande confiabilidade neste tipo de arquitetura (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 aspectos diferentes. Fazendo o MOO um tipo de middleware poderoso e flexível. Entretanto, devido a seu limitado suporte à escalabilidade, o Middleware Orientado a Objetos acaba sendo usado em cená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 da troca de mensagem. Nessa estrutura (veja a Figura 2.9), as mensagens enviadas pelo clientes sã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 de modo 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ário aguardar um retorno dessa requisição (FUKS et al.(2012)).
O Middleware Orientado a Mensagens dispõe de dois modelos de mensagens: 1) modelo point-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ífico do 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 de mensagens, 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, tais como: mensagens transacionais, entrega confiável de mensagens, persistência de mensagens, balanceamento de carga e clustering de aplicativos (CURRY(2004)). Exemplo de arquiteturas de 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 para permitir que os desenvolvedores de aplicativos se concentrem no desenvolvimento das aplicações para IoT (CHAQFEH; MOHAMED et al.(2012)). Existem diversas soluções independentes de Middlewarepara IoT, no entanto, a tendência é que essas soluções evoluam para uma plataforma
2.3. MIDDLEWARE PARA IOT 26 unificada para IoT, onde bilhões de objetos podem se conectar à Internet e interagir uns com os outros em todos os domínios de aplicações (LI et al.(2015)). Portanto, é viável conceber um sistema de middleware que possa simplificar o desenvolvimento de aplicativos e serviços necessá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 é uma infra-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 que as 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. As coisas 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 herda inúmeros desafios provenientes das particularidades de cada tecnologia envolvida em Internet das 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 existentes
BANDYOPADHYAY et al.(2011);MIORANDI et al.(2012). Resumidamente, os principais requisitos 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 e Privacidade.
Interoperabilidade: A característica de interoperabilidade remete à capacidade de
sistemas computacionais, de modo geral, a se comunicarem de forma transparente. No Middleware para IoT, é de fundamental importância prover esse recurso, já que o contexto de Internet das Coisas é formado por diferentes tipos de dispositivos resultando em um alto nível de heterogeneidade. Esse desafio se torna ainda mais
2.3. MIDDLEWARE PARA IOT 27 complexo quando o middleware a ser desenvolvido deve ter a capacidade de gerir uma grande 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 heterogeneidade em 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 mesmo
a facilidade de modificar-se. É de amplo conhecimento que objetos inteligentes no cenário de IoT não são estáticos e constantemente a localização física destes podem sofrer alterações. Isso requer mudanças rápidas na topologia de rede que, por sua vez, afetam a eficiência de roteamento, pois há muitos caminhos que podem ficar indisponíveis (FERSI(2015)). Assim, na presença de mobilidade, uma plataforma IoT unificada requer que o sistema gerencie a troca dados com atrasos aceitáveis e entregas confiáveis. LI et al.(2015)
Escalabilidade: A escalabilidade no contexto de software está associada à capacidade
de um sistema atuar conforme o nível de demanda sem perda de desempenho. Em sistemas escaláveis, novos recursos podem ser adicionados para atender a necessidade de 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 de pequena e grande escala (CHAQFEH; MOHAMED et al.(2012)). Essa eficiência deve estender-se ao crescente número de objetos conectados de modo a garantir suas funcionalidades mesmo que esse número aumente e varie de um lugar para outro (FERSI(2015)).
Descoberta de Dispositivos: Este recurso possibilita que novos dispositivos sejam
descobertos de forma autônoma. A Descoberta de Dispositivos permite que qualquer dispositivo da rede de IoT detecte todos os seus dispositivos vizinhos e apresente sua presença para cada vizinho da rede. Técnicas de ontologia são utilizadas para armazenar 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 otimizados para 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 Internet das Coisas deve ter consciência do contexto para executar suas funções em ambientes inteligentes (BANDYOPADHYAY et al.(2011)). A Ciência de Contexto é assegu-rada pela detecção e processamento de contexto. A detecção de contexto consiste na coleta 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 que uma 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 representam um 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 Internet das 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 dados não serão perdidos. Já a segurança dos dados (privacidade) está na capacidade do middlewaregarantir 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 no paradigma 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 foi padronizada (YICK; MUKHERJEE; GHOSAL(2008)). Possivelmente, uma solução única e adaptá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 a API JMS, ou seja, trata-se de um MOM. O projeto foi desenvolvido de modo genérico, podendo assim ser aplicado em diversos domínios. O Presumo fornece suporte a modelo de mensagens Publish/Subscriber de modo a maximizar seu desempenho. A comunicação é realizada de modo assíncrono, permitindo uma maior autonomia dos elementos. A arquitetura conceitual do Presumopode ser observada na Figura 2.13.
2.5. CONSIDERAÇÕES FINAIS 29 O projeto distribuído do Presumo não depende de nenhum controlador centralizado. Isso resulta em uma maior flexibilidade na utilização do Presumo, diferente do que ocorre na utilização da API JNDI (Java Naming and Directory Interface), já que a maioria dessas implementações são centralizadas. 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 e armazená-los em uma implementação JNDI.
Uma grande vantagem do Presumo em relação a outras soluções, está na implementação leve 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 bom desempenho (PRESUMO(2016)). Nas situação onde as mensagens são intra-JVM, estas são encaminhadas sem passar pela pilha de IP. Isso permite uma operabilidade eficiente, que pode ser 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 muita complexidade.
2.5
Considerações Finais
Neste capítulo foram apresentados os principais conceitos relacionados ao paradigma de Internet das Coisas. Desde os possíveis cenários de aplicação até a definição dos elementos que fazem 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 cada categoria 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.
30 30 30
3
Trabalhos Relacionados
Neste capítulo, serão apresentados os estudos existentes sobre o tema em questão. Foi realizada um análise sistemática do atual cenário de soluções de Middleware para Internet das Coisas. Foram apreciados assuntos de relevância e relação direta ao tema proposto, e.g., Internet das Coisas, Middleware e Redes de Sensores Sem fio. As pesquisas mais recentes com foco no desenvolvimento 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 e tendências como a Internet das Coisas. Atualmente, podemos observar a interação entre diversos objetos inteligentes, denominados de “coisas”, gerando consideráveis volumes de dados. Estes objetos não se limitam apenas a computadores convencionais, mas também a smartphones, smartwatchs, eyeglasses, pulseiras inteligentes, entre outros dispositivos com um mínimo de processamento computacional.
Devido as diversas particularidades e em especial a heterogeneidade de dispositivos, o desenvolvimento 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 arquitetura distribuída para Internet das Coisas, tais como: um ambiente em constante mudança, modelo de programação inadequado, questões sobre arquitetura de software e a necessidade de reconfigura-ção dinâmicaBERNARD(2006).
Em seu estudo, ChaqfehCHAQFEH; 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écnicos de 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 abordagem de middleware para Internet das Coisas.
Tabela 3.1 Desafios no Middleware para IoTCHAQFEH; MOHAMED et al.(2012)
Ressalta-se que as abordagens apresentadas na Tabela 3.1, tiveram foco nos desafios que Chaqfeh (CHAQFEH; MOHAMED et al.(2012)) pondera serem imprescindíveis à uma plataforma de middleware para IoT. Desta forma, o autor acredita que a solução que melhor se adapta ao desenvolvimento de uma plataforma de middleware para Internet das Coisas são baseadas 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 e generalizado para o desenvolvimento de um middleware para Internet das Coisas devido à grande quantidade de aplicações e domínios distintos envolvidos. Todavia, acredita-se na possibilidade de 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 de Data-Point, Conflitos de Ativação, Bootstrapping, Extensibilidade, Confiança, Modularidade, e Integração com mundo real.
3.1. SOLUÇÕES DE MIDDLEWARE PARA INTERNET DAS COISAS 32 A avaliação positiva de um middleware para Internet das Coisas está condicionada ao conjunto de desafios que a arquitetura desenvolvida é capaz de suportar. Em observância as funcionalidades de um middleware para IoT, Fersi (FERSI(2015)) analisa algumas abordagens possíveis, como mostrado na Tabela 3.2: Publish/Subscribe (Pub/Sub), Arquitetura Orientada a Serviç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 consideravelmente o 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 de um 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ão capazes 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árias técnicas afim de abordar ao máximo os demais desafios não alcançados no uso de uma única abordagem, buscando o ponto de equilíbrio entre o consumo de energia para a computação e consumo de energia para a comunicação (BERNARD(2006)).
Os componentes funcionais e as arquiteturas de middleware para IoT são apresentados emBANDYOPADHYAY et al.(2011), que busca classificar as diferentes plataformas segundo os recursos disponíveis. A Figura 3.1 ilustra os componentes funcionais de uma solução de middlewarepara 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 no cenário de IoT tendem a solucionar os contratempos de ambientes distribuídos além de fornecer
3.1. SOLUÇÕES DE MIDDLEWARE PARA INTERNET DAS COISAS 33
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, gerenciamento de 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, a escalabilidade merece certa atenção. Devido à sua capacidade de operar conforme expansão do modelo de negócio, o resultado será uma grande quantidade de dados gerados pela interação de milhares de dispositivos.
3.1. SOLUÇÕES DE MIDDLEWARE PARA INTERNET DAS COISAS 34 Esperando-se que a vasta quantidade de dados gerados seja tratada, o requisito de gerenciamento de grandes volumes de dados se faz necessário, pois este será responsável pela verificaçã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 problemas
DELICATO; 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 em eventos com foco em aplicações distribuídas em larga escala. A comunicação no Hermes ocorre tanto em modo síncrono ou assíncrono. Um algoritmo de roteamento escalável e mecanismos de tolerância a falhas foram utilizados na solução de modo evitar diferentes tipos de falhas no middleware.
A arquitetura do Hermes está segmentada em seis camadas: camada de serviços, a camada de middleware baseada em eventos, camada publish/subscriber baseada em tipos e em atributos, 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 que implementam funcionalidades como tolerância a falhas, entrega confiável de eventos, descoberta de evento, segurança e transações. Uma característica negativa do Hermes, está na falta de uma topologia de rede dinâmica. Hermes não suporta eventos compostos ou armazenamento persistente para eventos. Além disso, o suporte para a adaptação à nível de rede, é bastante limitado.
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 oferece suporte à interoperabilidade das tecnologias de rede heterogêneas. A solução possui um conjunto de 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
3.1. SOLUÇÕES DE MIDDLEWARE PARA INTERNET DAS COISAS 35 de dados, verificação de requisitos de QoS e reconfiguração. A reconfiguração é suportada em vários casos (por exemplo, falha no dispositivo). A camada de serviço fornece um componente de descoberta 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, essa abordagem 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 fator favorável. Um dos objetivos futuros, é redesenhar a arquitetura do PRISMA para permitir o suporte à 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ípio de 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 a diferentes funções que o agente desempenha) e a camada referente ao núcleo do agente, que conté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, novas políticas de segurança e reconfigurando as já existentes em resposta a ambientes extremamente dinâmicos. A interoperabilidade é alcançada por meio de adaptação semântica e atribuindo um agente pró-ativo a cada um dos recursos. Isso é suportado usando metadados e ontologias. No entanto, o suporte à interoperabilidade é limitado. Por exemplo, não abrange a interoperabilidade entre diferentes protocolos de descoberta de recursos.
Impala(LIU; MARTONOSI(2003)) - é uma solução de middleware voltada para RSSF que permite a modularidade de aplicativos, adaptatividade e reparação. O Impala permite que as 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 de melhorar 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ção em um único protocolo. Os requisitos de gerenciamento de recursos, mobilidade, abertura e escalabilidade são suportados ao alternar entre diferentes protocolos e modos de operação dependendo das aplicações e das condições da rede.
O Impala usa uma camada de sistema otimizada para executar a adaptação de aplicativos dinâmicos com base em parâmetros e falhas de dispositivos e atualizações automáticas de
aplica-3.1. SOLUÇÕES DE MIDDLEWARE PARA INTERNET DAS COISAS 36 tivos com base em um mecanismo de gerenciamento e transmissão de software especializado. No entanto, o Impala não suporta o pré-processamento de dados, que é um componente importante do gerenciamento de dados. Em geral, o Impala é um sistema de baixo impacto no desempenho em tempo de execução e que pode melhorar significativamente a confiabilidade, o desempenho e a 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 para cenários de IoT. A solução é baseada em SOA (Arquitetura Orientada a Serviços) e oferece interfaces de serviços Web para controle de qualquer tipo de dispositivo físico e permite que desenvolvedores incorporem dispositivos físicos heterogêneos em suas aplicações.
Sua arquitetura consiste em uma série de componentes de gerenciamento, incluindo gerenciador 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 uma série de requisitos funcionais (por exemplo, gerenciamento de dados, gerenciamento de eventos e 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 de contexto e serviços) e a camada de segurança (abrange as demais camadas fornecendo uma comunicaçã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ções de segurança (por exemplo ataques do tipo side-channel attack). Além disso, a segurança semântica baseada em ontologia e as soluções de interoperabilidade provavelmente não serão adequadas ao contexto de IoT devido a falta de padronização de ontologias para este paradigma em 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á em desenvolver uma plataforma de projeto, execução e gerenciamento para sistemas de automação industrial de próxima geração, explorando o modelo de arquitetura orientada à serviços, tanto em dispositivo como em nível de aplicação.
Sua arquitetura consiste em duas camadas: a camada para serviços de aplicação (por exemplo, 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 de vida de serviços).
3.1. SOLUÇÕES DE MIDDLEWARE PARA INTERNET DAS COISAS 37 por dispositivos inteligentes que interagem com o ambiente físico e organizacional, buscando metas 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ída pela 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 a complexidade associada.
3.1.4
Middleware Orientado a Banco de Dados
TinyDB(MADDEN; HELLERSTEIN; HONG(2003)) é um middleware voltado para rede 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 de processamento 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 de aplicativos 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 de roteamento), 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, minimizando a 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 pelos sensores dentro da rede.
GNS(ABERER; HAUSWIRTH; SALEHI(2006)) é uma plataforma de middleware de
fácil integração envolvendo vários tipos de sensores, ou seja, sua implementação é altamente modular de modo possibilitar a implantação em diversas plataformas de hardware, desde estações de trabalho até pequenos dispositivos programáveis. Novos sensores podem ser facilmente adicionados 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 pode hospedar e gerenciar simultaneamente um ou mais sensores virtuais. O recipiente gerencia todos os aspectos dos sensores virtuais em tempo de execução, incluindo acesso remoto, interação com a rede de sensores, segurança, persistência, filtragem de dados, concorrência, controle de acesso a compartilhamento de recursos.
As informações sobre os sensores virtuais são identificadas por pares de valores-chave definidos pelo usuário e a comunicação é realizada via peer-to-peer. Esse recurso possibilita que os sensores virtuais possam ser descobertos e acessados com base em qualquer combinação de suas propriedades, por exemplo, localização geográfica e tipo de sensor. Esse recurso possibilita que 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 tem como 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, TinyDBe GNS. Como parâmetros de classificação foram utilizados os principais componentes funcionais e não funcionais necessários a uma solução de middleware para IoT apresentados em Bandyopadhya (BANDYOPADHYAY et al.(2011)) e Mohammad (RAZZAQUE et al.(2016)).
Tabela 3.5 Comparação entre Soluções de Middleware para IoT
3.3
Considerações Finais
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 de middleware(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, foram apresentadas as principais soluções de Middleware atualmente existentes para IoT e classificadas em grupos conforme suas características de funcionamento.
39 39 39
4
Middleware 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 de desenvolvimento 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 de Middlewarepara Internet das Coisas, procurando associar os recursos necessários e o melhor desempenho. Os requisitos dos xPresumo foram definidos com base nos estudos apresentados por 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 e
necessário ao contexto de IoT. Devido à diversidade de dispositivos conectados em ambientes inteligentes, o xPresumo atua para que a comunicação ocorra de maneira simplificada, ou seja, de maneira padronizada.
Segurança: Em ambientes onde inúmeros dispositivos compartilham todo tipo de
informações, é de fundamental importância a adoção de mecanismos de segurança que visem dificultar a manipulação de informações sem a devida autorização. O xPre-sumoprovê confidencialidade e integridade das informações por meio de criptografia simétrica. O módulo de segurança do xPresumo conta com dois mecanismos: de autenticação de dispositivos e de criptografia das mensagens trocadas entre dispositi-vos.
Descoberta e Localização de Dispositivos: Outro requisito essencial no cenário de
IoT é na capacidade de localização e descoberta de dispositivos. O xPresumo conta com o recurso de localização e descoberta baseados em Received Signal Strength
