CAPÍTULO 6 TRABALHOS RELACIONADOS
6.1. Adaptive Middleware for Context-aware Applications in Smarthomes
adaptativo para aplicações cientes de contexto que, entre outras funções, monitora metadados de QoC e responde às requisições síncronas e assíncronas. Portanto, a análise comparativa desse Middleware com o QoMonitor será restrita à parte de monitoramento e aferição de metadados de QoC, uma vez que o mesmo não monitora nem afere metadados de QoS. Em síntese, as outras funções que o Middleware implementa, que são próprias de um Middleware e não de um monitor de metadados apenas, são:
(i) Escolha de um provedor de contexto, entre todos os disponíveis, que forneça a melhor qualidade de contexto, maximizando a satisfação das aplicações. Para tanto, são utilizadas funções de utilidade específicas das aplicações. O QoMonitor é uma ferramenta de monitoramento de QoS e QoC e, portanto, deixa essas funções sob a responsabilidade do Middleware que o utiliza.
(ii) Implementação de funções autonômicas como auto-configuração e resiliência a falhas. Da mesma forma, estas não são funções próprias de um monitor de metadados, portanto, não são implementadas pelo QoMonitor.
Em relação à qualidade de contexto, o Middleware não propõe uma ontologia específica, utilizando alguns atributos de QoC especificados em [Buchholz et al., 2003]: precisão, probabilidade de corretude, resolução, atualidade (freshness) e taxa de refrescamento. Esses atributos são fornecidos pelos provedores ao fornecerem a informação de contexto e, como variam ao longo do tempo, devem ser regularmente atualizados. Em contraposição, o QoMonitor propõe uma ontologia específica, podendo os atributos serem fornecidos pelos provedores ou serem aferidos pelo mesmo, residindo, nestas características, duas diferenças básicas em favor do QoMonitor.
A figura 37 ilustra as camadas de provisão de contexto do middleware. O Middleware proposto utiliza uma arquitetura em camadas, tendo na camada mais baixa os sensores que entregam os dados brutos para provedores de contexto (context providers) na camada imediatamente acima, que agregam e interpretam os dados dos sensores para produzirem
informações de contexto de mais alto nível, como localização, identidade, condições de saúde, etc. Mais de um provedor de contexto pode acessar o mesmo grupo de sensores, como
Figura 37. Camadas de Provisão de Contexto do Middleware. Fonte: [Huebscher et al., 2005]
também é possível um provedor de contexto utilizar um grupo de sensores, aumentando assim, a confiabilidade devido à redundância empregada. Na camada imediatamente acima se situam os serviços de contexto (context services) que se conectam abaixo a diferentes provedores de contexto (context providers) que fornecem o mesmo tipo de contexto, porém utilizam sensores diferentes. Na camada superior se situam as aplicações que se conectam abaixo aos serviços de contexto, que permitem às aplicações abstrair o provedor de contexto utilizado.
Os CSs (context services) executam a adaptação no sistema, que consiste em substituir o CPs (context provider) quando a QoC do CP atualmente utilizado deteriora-se ou existe algum outro CP cuja QoC seja melhor.
O Middleware adaptativo propõe-se a desempenhar as seguintes funções:
(i) Descobrir o serviço através de um serviço de diretório (Directory Service). Quando um CP entra na rede ele informa sua presença ao DS fornecendo uma descrição dos atributos que ele fornece, isto é, o tipo da informação de contexto e os atributos de QoC. Essa informação deve ser regularmente atualizada, permitindo ao DS monitorar a QoC dos CPs e rapidamente detectar falhas nas CPs. O QoMonitor não se encarrega de descobrir o serviço, podendo o próprio serviço registrar-se no
Repositório de Serviços, ou ainda, um serviço pode ser adicionado nesse
repositório através de uma requisição do cliente para recuperar metadados de QoS/QoC relativos a um serviço que ainda não está no repositório.
(ii) Inicializar o context service-CS através do Directory Service-DS. Quando o primeiro CP, para um tipo particular de contexto se anuncia para o DS, um CS
correspondente é criado. Inversamente, quando não há mais CP para este contexto o CS finaliza, depois de notificar à aplicação que este contexto não está disponível. O QoMonitor não recorre a um serviço de diretório para monitorar um serviço de determinado provedor, procedendo como explicado no ítem anterior. (iii) Ativar o mecanismo de adaptação (adaptation engine). O CS executa adaptação
substituindo os provedores de contexto, porém eles não decidem quando e que CP deve ser substituído e por qual CP. Estas decisões são tomadas por um mecanismo de adaptação externo. O DS monitora os CPs e envia informações ao mecanismo de adaptação. Essas informações que permitem adaptação incluem notificação de falha de CP, degradação de provedor ou melhoria por um CP disponível, porém não utilizado. O mecanismo de adaptação, baseado nestas informações, decide que CP deve ser substituída por qual CP. No QoMonitor a reconfiguração após falhas é deixada a cargo do middleware.
(iv) Criar uma base de dados com o histórico de QoC e as informações de contexto fornecidas. O QoMonitor também disponibiliza esta base de dados.
(v) Escolher o melhor CP. Quando uma aplicação deseja adquirir informações de contexto do Middleware ela procura no DS a localização na rede do serviço de contexto (context service) para o tipo de contexto no qual está interessada e contata o CS e informa a QoC que deseja receber. Esta informação é transmitida para o mecanismo de adaptação que a utiliza para determinar que CP é a melhor escolha. Para tanto é utilizada uma função de utilidade que é enviada pela aplicação para o CS. O CS aplica a função de utilidade para cada CP, podendo, assim, escolher o melhor CP. No caso do QoMonitor, a escolha do melhor provedor de serviço de contexto é deixado a cargo do middleware, com base nas informações de contexto fornecidas, como também é função do Middleware a composição dos serviços.
Considerando os requisitos apresentados para o QoMonitor podemos concluir que o
Middleware adaptativo proposto:
(i) Fornece uma interface (API) para comunicação com clientes e provedores de serviços.
(ii) Não utiliza uma ontologia específica adotando alguns atributos de QoC especificados em [Buchholz et al., 2003].
(iii) Aceita requisições síncronas e assíncronas dos clientes apenas para QoC, mas não para QoS, definindo, para as síncronas, os parâmetros e os intervalos de tempo para monitoramento dos mesmos e, para as assíncronas, a condição de retorno. (iv) Monitora, avalia e registra os metadados de QoC, mas não os de QoS.
(v) Responde às requisições síncronas e assíncronas com os valores dos parâmetros de QoC solicitados, mas não os de QoS.