Considerações Finais

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.