para os componentes do middleware responsáveis pelo monitoramento e avaliação de QoC, ambos baseado na utilização de agentes de processamento de eventos complexos
4.2 Avaliação do Consumo de Memória dos Mecanismos 79 Foi utilizada a mesma aplicação teste empregada no experimento anterior, variando-se apenas a taxa de publicação, que neste experimento foi de 1 mensagem por segundo (uma frequência considerada moderada). A aplicação foi executada durante 30 minutos. A partir do uso da ferramenta Android Monitor (embutida na IDE Android Studio) foram coletados dados relativos ao consumo de memória em 5 instantes de execução da aplicação: 5, 10, 15, 20 e 25 minutos. A tabela 4.3 exibe a média resultados obtidos considerando 5 repetições.
5 min 10 min 15 min 20 min 25 min Média Desvio Padrão QoC Evaluator 263 262 268 269 270 266 2.77
Monitor 213 213 216 219 280 214 3.14
Tabela 4.3: Consumo de Memória em Kbytes
A partir desses resultados é possível observar que os componentes de monitoramento e avaliação de QoC necessitam de pouca quantidade de memória para processar fluxos de dados com frequência moderada.
4.2.1 Avaliação do Consumo de Bateria
O objetivo deste experimento foi avaliar o consumo de bateria por parte dos componentes do middleware. Para isso foi utilizada a mesma aplicação teste do experimento anterior e igual taxa de publicação de dados. A aplicação foi executada durante 12 horas, sendo que o nível da bateria foi medido antes e depois do tempo de execução da mesma. É importante destacar que durante a execução da aplicação a tela do dispositivo permaneceu desligada. Além disso, com a exceção dos processos do sistema operacional, não haviam outros processos executando no dispositivo. O consumo de bateria medido foi de 15.6 % após as 12 horas.
Mínimo Máximo Média Desvio Padrão Consumo de Bateria 15 % 16 % 15.6 % 0.55
Tabela 4.4: Consumo de Bateria
Considera-se que esse consumo é baixo, indicando que o middleware pode ser utilizado para publicar dados e monitorar QoC em dispositivos móveis de uso convencional.
5 Trabalhos Relacionados e Análise
Comparativa
Apesar do desenvolvimento de middleware de contexto ser uma área de grande interesse, e que várias propostas tenham surgido, poucas delas focaram nos mecanismos de avaliação de QoC, particularmente em prover um mecanismo abrangente que envolva tanto QoS quanto QoI. O cenário tampouco conta com muitos trabalhos que foquem o monitoramento de QoC. Perera et al. [69] e Bandyopadhyay et al. [4] analisarem vários tipos de middleware, mas sem levar em consideração a QoC como critério comparativo. No melhor do nosso conhecimento, as propostas de middlewarecom suporte a QoC que mais se destacam são: QoMonitor [5], AWARENESS [79], COSMOS [1, 20], COPAL [50], INCOME [3, 60, 61] e SALES [22, 24, 25, 32]. Essas propostas serão apresentadas a seguir.
5.1 QoMonitor
QoMonitor [5] é um sistema de monitoramento de metadados que recebe requisições síncronas e assíncronas de clientes (aplicações e/ou middleware ubíquos), recupera metadados de provedores de contexto e os envia aos clientes. Utilizando o middleware, aplicações ubíquas podem se concentrar nos problemas do negócio e abstrair as complexidades relacionadas com o monitoramento de metadados. Os metadados monitorados pelo QoMonitor ficam disponíveis para as aplicações. O QoMonitor pode ainda ser associado a um middleware responsável por gerenciar essas informações de modo a selecionar os serviços que serão usados pela aplicação, por exemplo.
O QoMonitor é constituído de três repositórios: a) um Metadata Repository, que armazena todos os metadados de QoS e QoI dos serviços monitorados e os metadados fornecidos pelas provedores dos serviços; b) um Service Repository, que armazena informações sobre os serviços monitorados e os parâmetros necessários para se comunicar com eles e c) um Client Repository, que armazena informações sobre os
5.1 QoMonitor 81 clientes de modo a permitir a comunicação com os clientes. Além disso, o QoMonitor contém: a) um Ontology Module, que é responsável por especificar metadados usando um modelo de ontologia que representa os conceitos de modo não ambíguo; b) um Request Handler, que recebe requisições dos clientes, coleta os metadados e os envia para estes clientes e c) um Assesment Module, que é responsável por efetivamente monitorar e avaliar metadados de QoS/QoI dos serviços armazenados no repositório de serviços.
Figura 5.1: Arquitetura Geral do QoMonitor
A Figura 5.1 ilustra a arquitetura do QoMonitor. O QoMonitor fornece duas interfaces de comunicação: IClient para comunicação com clientes e IServer para se comunicar com os provedores de serviços. A Server Façade é responsável por registrar novos serviços no repositório de serviços e se comunicar com os provedores. O Service Repository é responsável por armazenar informações sobre todos os serviços
monitorados e os parâmetros necessários para se comunicar com eles. A Client Façade é responsável por permitir a comunicação dos clientes com o monitor, que pode ser qualquer aplicação ou middleware ubíquo que precisa fazer uso de parâmetros de QoS/QoI. Os clientes podem se registrar no monitor e fazer solicitações síncronas e assíncronas. Ao executar solicitações assíncronas, o cliente deve implementar um método de callback para permitir a comunicação entre o monitor e o cliente, de modo que esse método seja responsável por receber a resposta do monitor em relação à solicitação assíncrona. O monitor verifica periodicamente a condição de retorno e, se for satisfeita, responde ao cliente fornecendo os parâmetros com seus respectivos valores representados na forma da ontologia. O Metadata Repository é responsável pela persistência de todos os metadados de QoS/QoI avaliados pelo monitor e também dos metadados de QoS/QoI fornecidos pelos provedores de serviços. Por sua vez, o Ontology Module é responsável por representar esses dados sob a forma de uma ontologia.
O componente principal do monitor é o Assesment Module que é responsável por avaliar os metadados de QoS/QoI dos serviços armazenados no Service Repository e monitorá-los e é composto por três tipos de elementos: assessores, Blackboard e Controller. Cada assessor é responsável por avaliar um parâmetro de qualidade (QoS/QoI) específico a partir de informações coletadas através de solicitações aos serviços monitorados pelo Assesment Module. Esta informação é: (i) o tempo gasto para completar o pedido (CompletedTime); (ii) se o serviço estava disponível ou não (isAvailable); (iii) o instante em que o pedido foi feito (TimeStamp), e; (iv) a data e a hora de criação/detecção das informações de contexto fornecidas pelo serviço que é utilizada para inferir a idade (Age) das informações de contexto fornecidas pelo serviço. O componente Blackboard incorpora a ideia de um repositório de dados compartilhado usado pelos avaliadores de diferentes parâmetros QoS/QoI para calcular o valor desses parâmetros. O componente Controller é responsável por controlar o acesso às informações armazenadas no quadro-negro e as informações obtidas a partir da avaliação dos parâmetros, para que os avaliadores não conheçam a fonte dos dados que eles usam para fazer a avaliação, modularizando assim a arquitetura. O monitoramento de serviços funciona de forma independente, usando threads e começa no momento em que o monitor está disponível, de modo que as operações de monitoramento e avaliação sejam executadas enquanto o monitor recebe
5.2 AWARENESS 83