CENTRO DE CIÊNCIAS
DEPARTAMENTO DE COMPUTAÇÃO
MESTRADO E DOUTORADO EM CIÊNCIA DA COMPUTAÇÃO
BENEDITO JOSÉ DE ALMEIDA NETO
SYSSU-DTS: UM SISTEMA DE SUPORTE À COMPUTAÇÃO UBÍQUA
BASEADO EM ESPAÇO DE TUPLAS DISTRIBUÍDO
SYSSU-DTS: UM SISTEMA DE SUPORTE À COMPUTAÇÃO UBÍQUA
BASEADO EM ESPAÇO DE TUPLAS DISTRIBUÍDO
Dissertação submetida à Coordenação do Pro-grama de Pós-Graduação em Ciência da Com-putação da Universidade Federal do Ceará, como requisito parcial para a obtenção do grau de Mestre em Ciência da Computação.
Área de concentração: Ciência da Computação.
Orientadora: Profa. Dra. Rossana Maria de Castro Andrade.
Coorientador: Prof. Me. Marcio Espíndola Freire Maia.
SYSSU-DTS: UM SISTEMA DE SUPORTE À COMPUTAÇÃO UBÍQUA
BASEADO EM ESPAÇO DE TUPLAS DISTRIBUÍDO
Dissertação submetida à Coordenação do Programa de Pós-Graduação em Ciência da Compu-tação da Universidade Federal do Ceará, como requisito parcial para a obtenção do grau de Mestre em Ciência da Computação. Área de concentração: Ciência da Computação.
Aprovada em: 29/08/2013.
BANCA EXAMINADORA
Profa. Dra. Rossana Maria de Castro Andrade Universidade Federal do Ceará - UFC
Orientadora
Prof. Dr. Miguel Franklin de Castro Universidade Federal do Ceará - UFC
Prof. Dr. Windson Viana de Carvalho Universidade Federal do Ceará - UFC
DSc. Hervé Martin
Dou graças ao mestre dos mestres, Jesus Cristo, por todos os momentos que pude sentir sua força, mantendo minha fé e esperança, sem Ele nada seria possível pois sou fraco e limitado. Essa força, que chegou a mim por meio de tantos amigos e familiares é a razão da minha alegria e o segredo desta conquista.
Agradeço aos professores do MDCC que confiaram no meu trabalho. Em especial agradeço aos meus orientadores, Rossana Andrade, que sempre foi uma inspiração e exemplo de profissionalismo, competência e de amor pela pesquisa, e Marcio Maia, que também se dispôs a me guiar pelos caminhos da pesquisa científica, compartilhando seu conhecimento e colabo-rando ativamente, com dedicação e paciência, para o sucesso deste trabalho. Agradeço também ao professor Vicente Sousa, por ter me recomendado e motivado a ingressar no mestrado.
Agradeço, a pedidos, ao professor Windson Viana, que esteve sempre próximo e interessado em minha pesquisa, e com o qual pude contar durante a árdua tarefa de produção científica, mesmo durante madrugadas de trabalho. E também ao Reinaldo e a Carina, que se dispuseram a contribuir, principalmente com a análise dos dados estatísticos.
Aos professores Hervé Martin, Miguel Franklin e Windson Viana, que compuseram a banca examinadora e contribuíram significativamente com o bom resultado desse trabalho.
Não poderia deixar de agradecer ao amigo e parceiro de produção científica An-dré Fonteles, com o qual dividi os momentos mais críticos de aprendizado e superação neste mestrado. Sua ajuda, incentivo e companheirismo fizeram a diferença.
Agradeço aos alunos de mestrado e doutorado que já estavam com seus trabalhos em andamento quando iniciei o meu mestrado, e mesmo muito atarefados me brindaram com seu exemplo e orientações, além de bom humor e incentivo. Obrigado Fabrício Lima, Carlos Al-berto e Lincoln Rocha, Atslands Rocha, Fabiana Marinho, Fátima Souza, Deborah Magalhães, Sandra Carvalho, Thiago Malveira, Paulo Alexandre, Alexandre Corrêa e Fernando Parente. E um agradecimento especial para o Fabrício Lima, Carlos Alberto e Lincoln Rocha por oferece-rem o suporte necessário para contribuir com o SysSU. Agradeço também o companheirismo e incentivo dos meus queridos contemporâneos, André, Rafael, Ismyle, Nayane, José Ricardo, Adson, Carla, Emanuel, Cleiton. E aos novatos Akono, Ítalo, Paulo Arthur, Rodrigo, Douglas, Cristiano, Thalisson, Larissa, Mairton e Rainara.
Aos meus irmãos Wallberth e Robertinho, por sempre acreditarem e incentivarem incondicionalmente os meus estudos. A meus pais, Sr. Roberto Veloso Veloso e D. Walderez Almeida, pois mesmo não tendo a oportunidade de cursar o nível superior, souberam me ensinar o valor dos estudos e me educaram para ser, acima de tudo, um homem de bem.
A evolução das tecnologias móveis favorece o surgimento de sistemas capazes de antever as necessidades do usuário e se adaptar às variações de seu contexto de forma impercep-tível. Tais sistemas, denominados sistemas ubíquos, enfrentam o desafio da adaptação dinâmica em um cenário altamente distribuído, heterogêneo e volátil, uma vez que pode se tornar difícil coletar e processar informações contextuais oriundas de fontes desconhecidas e distribuídas. O problema em questão é o gerenciamento de dados contextuais em cenários sujeitos a mobilidade e conexões intermitentes entre dispositivos móveis e servidores. A fim de facilitar o desenvol-vimento de sistemas ubíquos, este trabalho estende um sistema de suporte existente, chamado SysSU (LIMA et al., 2011), que foi baseado em espaços de tuplas centralizado. Com o ob-jetivo de gerenciar informações de contexto distribuídas, é adotada uma abordagem de espaço de tuplas descentralizada, oferecendo aos componentes dos sistemas ubíquos a capacidade de interação e cooperação em situações de total descentralização. Sendo assim, esta dissertação propõe o SysSU-DTS (System Support for Ubiquity - Distribute Tuple Space), um sistema de suporte que fornece a funcionalidade de coordenação de sistemas ubíquos em ambientes aber-tos, onde nenhuma suposição sobre os recursos disponíveis deve ser feita. O SysSU-DTS é focado em sistemas ubíquos baseado em dispositivos móveis, como smartphones, tablets e ul-trabooks, que podem se comunicar através de redes móveis Ad hoc (MANET -Mobile Ad hoc Network). O SysSU-DTS representa informações contextuais por meio de tuplas e permite o acesso transparente a informações de contexto disponíveis, estejam elas localizadas dentro do dispositivo móvel, em um servidor ou em outro dispositivo móvel próximo. A partir do acesso a informações de contexto oriundas de diferentes provedores, as aplicações ubíquas e sensíveis ao contexto que adotem o suporte do SysSU-DTS podem ter uma visão do contexto global das enti-dades envolvidas no sistema. Além disso, o SysSU-DTS implementa um mecanismo de escopo que permite a formação de subconjuntos de informações contextuais disponíveis, evitando ge-renciamento de informações desnecessárias. São apresentados resultados experimentais obtidos em uma avaliação de desempenho realizada em umtestbedcomposto por smartphones e tablets. Esta avaliação demonstra a viabilidade prática da abordagem proposta e como o SysSU-DTS promove a distribuição de informações de contexto adaptando-se dinamicamente a provedores de contexto locais, infra-estruturados e distribuídos em redes Ad hoc.
Palavras-chave: Computação Ubíqua; Computação Pervasiva; Coordenação; Espaço de Tuplas Distribuído; Sensibilidade ao Contexto; Adaptação Dinâmica.
The evolution of mobile technologies allows the emerging of ubiquitous systems, able to anticipate user’s needs and to seamlessly adapt to context changes. These systems pre-sent the problem of dynamic adaptation in a highly distributed, heterogeneous and volatile en-vironment, since it may be difficult to collect and process context information from distributed unknown sources. The problem faced is the management of contextual data in scenarios with mobility and intermittent connections between mobile devices and servers. In order to facilitate the development of such systems, this work extends an existing support system based on centra-lized tuple spaces, called SysSU (LIMA et al., 2011), aiming at the management of distributed information. Hence, a decentralized tuple space approach is adopted, offering to ubiquitous systems components the capability of interaction and cooperation in scenarios of total decen-tralization. Thus, this work introduces SysSU-DTS (System Support for Ubiquity - Distribute Tuple Space), a system support that provides functionality for coordinating ubiquitous systems in open environments, where no assumptions about available resources should be made. It focu-ses on ubiquitous systems based on mobile devices such as smartphones, tablets and ultrabooks, which can communicate through a Mobile Ad hoc Network (MANET). SysSU-DTS represents context information by tuples and allows a transparent access to spread context, as follows: (i) local access, which accesses an internal device tuple space; (ii) infrastructured access, tuple spaces located on a server accessed using an infrastructured network; or (iii) Ad hoc access, interacting directly with tuple spaces located in nearby devices via the formation of an Ad hoc network. From the access to different context providers, ubiquitous and context-aware applica-tions, using SysSU-DTSs support, can have an insight of global context related to the system entities. In addition, SysSU-DTS implements a scope mechanism that allows the formation of available contextual information subsets. This mechanism restricts access to contextual tuples only to members of the same scope, avoiding unnecessary information management. This dis-sertation reports some experimental results obtained in a performance evaluation using a testbed of smartphones and tablets. The evaluation shows the practical feasibility of our approach and point out how SysSU-DTS can grant context data distribution with dynamically adapting to local, infrastructured and distributed over Ad hoc networks context providers.
Keywords: Ubiquitous Computing; Pervasive Computing; Coordination; Distributed Tuple Space; Context-Aware; Dynamic Adaptation.
Figura 1.1 Elementos básicos de um sistema ubíquo: Dispositivo, Rede, Middleware e
Aplicação (adaptado de (SAHA; MUKHERJEE, 2003)). . . 14
Figura 2.1 Do mainframe à ubiquidade (adaptado de (BICK; KUMMER, 2008)). . . 22
Figura 2.2 Relação entre contexto, zona de observação e zona de interesse (adaptado de (VIANA, 2010)). . . 25
Figura 2.3 Laço de controle – MAPE-K (adaptado de (HUEBSCHER; MCCANN, 2008)). 29 Figura 2.4 Modelo de Arquitetura em Três Camadas para Auto Gerenciamento (adaptado de (KRAMER; MAGEE, 2007)). . . 30
Figura 3.1 Arquitetura original do SysSU (LIMA et al., 2011). . . 37
Figura 3.2 Espaços tupla transitoriamente compartilhados (adaptado de (MURPHY; PICCO, 2006)). . . 40
Figura 3.3 Abstração da composição do Espaços tupla do EXEHDA-TS (retirado de (SOUZA et al., 2012)). . . 43
Figura 3.4 Modelo de consulta de contexto do Contory. . . 44
Figura 4.1 Comunicação descentralizada através de espaço de tuplas distribuído. . . 50
Figura 4.2 Visão geral da arquitetura do SysSU-DTS. . . 51
Figura 4.3 Diagrama de atividades do algoritmo de busca transparente de provedor de contexto. . . 54
Figura 4.4 Tuplas restritas a diferentes escopos. . . 57
Figura 5.2 Tempo de resposta para a consulta de contexto local, infra-estruturado e Ad
hoc. . . 64
Figura 5.3 Consultasbroadcast em espaço de tuplas distribuídos em redes Ad hoc de di-ferentes tamanhos. . . 65
Figura 5.4 Dispositivos móveis utilizados nos experimentos III e IV. . . 67
Figura 5.5 Consultas com seleção direta e autônoma de provedor contextual. . . 69
Figura 5.6 Adaptação autonômica de provedor de contexto. . . 70
Figura 5.7 Acesso a tuplas restritas a escopos de diferentes tamanhos. . . 72
Tabela 3.1 Comparação entre os trabalhos relacionados. . . 46
Tabela 5.1 Descrição dotestbed. . . 62
Tabela 5.2 Descrição dotestbedutilizado nos experimento III e IV. . . 67
1 INTRODUÇÃO. . . 13
1.1 Contextualização . . . 13
1.2 Motivação . . . 16
1.3 Objetivo, Metas e Contribuições. . . 18
1.4 Organização da Dissertação . . . 19
2 FUNDAMENTAÇÃO TEÓRICA DA PESQUISA. . . 21
2.1 Computação Ubíqua e Conceitos Relacionados. . . 21
2.1.1 Introdução à Computação Ubíqua . . . 21
2.1.2 Sensibilidade ao Contexto . . . 24
2.1.3 Middleware Ubíquo . . . 26
2.1.4 Computação Autonômica . . . 28
2.2 Modelos de Coordenação . . . 31
2.3 Contexto Distribuído. . . 33
2.4 Conclusão . . . 35
3 TRABALHOS RELACIONADOS. . . 36
3.1 Sistema de Suporte SysSU . . . 36
3.2 LIME . . . 39
3.3 TOTA . . . 41
3.4 EXEHDA-TS . . . 42
3.5 Contory . . . 44
3.6 Análise Comparativa. . . 45
3.7 Conclusão . . . 46
4 SYSSU-DTS. . . 48
4.1 Introdução. . . 48
4.2 Principais Desafios. . . 48
4.3 Modelagem Arquitetural . . . 50
4.4 Acesso Transparente a Espaço de Tuplas Distribuídos . . . 53
4.7 Conclusão . . . 60
5 AVALIAÇÃO DE DESEMPENHO. . . 61
5.1 Experimento I - Avaliação do Acesso a Espaço de Tuplas Local, Infra-estruturado e Distribuído. . . 61
5.1.1 Análise dos Resultados . . . 63
5.2 Experimento II - Avaliação da Escalabilidade da Consulta em redes Ad Hoc . 64 5.2.1 Análise dos Resultados . . . 65
5.3 Experimento III - Avaliação do Acesso Transparente a Provedores de Contexto 66 5.3.1 Análise dos Resultados . . . 69
5.4 Experimento IV - Avaliação do Mecanismo de Escopo . . . 71
5.4.1 Análise dos Resultados . . . 72
5.5 Conclusão . . . 74
6 CONCLUSÃO E TRABALHOS FUTUROS. . . 75
6.1 Resultados Alcançados . . . 75
6.2 Limitações. . . 76
6.3 Publicações . . . 77
6.4 Trabalhos Futuros . . . 78
1 INTRODUÇÃO
Esta dissertação tem como objetivo apresentar o SysSU-DTS (System Support for Ubiquity - Distribute Tuple Space), um sistema de suporte que oferece funcionalidades para a coordenação de sistemas ubíquos em ambientes abertos e que executem tanto em redes infra-estruturadas quanto em redes Ad hoc, com independência de uma infra-estrutura fixa de co-municação. Este capítulo apresenta a contextualização do tema do trabalho desenvolvido, sua motivação e objetivos bem como a estrutura deste documento.
1.1 Contextualização
A computação ubíqua visa diluir as barreiras entre o usuário e suas necessidades e a tecnologia computacional, conforme afirma Mark Weiser em seu artigoThe Computer for the 21st Century(WEISER, 1991):
"As tecnologias mais profundas são aquelas que desaparecem. Elas se misturam com os objetos do dia a dia até se tornarem indistinguíveis no ambiente".
Na visão de Weiser, a interação entre o usuário e o sistema deve acontecer de forma natural e transparente, minimizando a intervenção direta do usuário e aumentando o grau de autonomia do sistema.
Fatores como a popularização dos dispositivos portáteis, evolução das redes móveis e da microeletrônica vêm modificando a forma como as pessoas acessam informações. Elas estão mais conectadas e demandam por sistemas rápidos, confiáveis e acessíveis em qualquer lugar e a qualquer momento (CORRADI et al., 2009). Com esse rápido avanço tecnológico, a computação ubíqua tem então se tornado uma realidade.
sistemas ubíquos. Surge a necessidade de criação de uma camada de abstração (i.e., um Mid-dleware) que permita aos programadores desenvolver aplicações ubíquas que possam fazer uso dos diferentes componentes de hardware e software disponíveis.
Este trabalho de pesquisa tem como foco sistemas ubíquos baseados em dispositivos móveis, como smartphones, tablets e ultrabooks, que podem se comunicar através de redes Ad hoc móveis (Mobile Ad hoc Networks - MANET). A Figura 1.1 apresenta uma visão de como ocorre a relação entre os principais elementos desse tipo de sistema: dispositivo, rede, middleware e aplicação. Os dispositivos móveis oferecem uma interface com o usuário que deve ser o mais transparente e menos intrusiva quanto possível. Para isso, esses dispositivos são dotados de sensores como acelerômetro, termômetro, GPS, bússola, microfone, sensor de luminosidade e nível de bateria, capazes de monitorar o contexto do usuário e do ambiente de execução do sistema. Além disso, esses dispositivos possuem tecnologias de comunicação sem fio como Bluetooth, WiFi (i.e., IEEE 802.11), 3G e NFC que permite que eles formem uma rede Ad hoc e interajam entre si favorecendo o compartilhamento de informações de contexto, bem como a possibilidade de acesso a redes infra-estruturadas e à internet. A complexidade que existe nessa comunicação ubíqua e no gerenciamento das informações de contexto distribuídas é encapsulada nos middlewares ubíquos que facilitam o desenvolvimento das aplicações ubíquas.
Os sistemas ubíquos possuem a capacidade de se adaptar ao contexto do usuário, essa característica é chamada de sensibilidade ao contexto. Um dos desafios principais desse tipo de sistema é garantir uma adaptação suave a mudanças de contexto e cooperação entre os dispositivos que interagem durante a execução do sistema. Para sistemas ubíquos, o contexto pode ser representado por dados que descrevem o cenário e o comportamento do usuário/sistema em um dado momento (e.g., localização, temperatura ambiente, atividade em andamento). A definição de contexto será discutida com mais detalhes na subseção 2.1.2.
Um middleware ubíquo deve lidar com as mudanças de contexto de forma autonô-mica e transparente para o usuário. A capacidade de se adaptar é importante, por exemplo, em situações em que um sistema oferece um serviço e este se apresenta de forma intermitente de-vido a constantes desconexões com a rede. Considerando a mobilidade, característica comum aos sistemas ubíquos, essas desconexões podem ocorrer por perda de sinal da rede ou esgota-mento da bateria de um dispositivo móvel. É necessário prover meios alternativos para manter o sistema executando de forma aceitável mesmo diante de desconexões inesperadas.
Um exemplo que ilustra a importância do comportamento adaptativo e autônomo em sistemas ubíquos é o aplicativo hipotético UMesseger, proposto em (ROCHA, 2009). O UMesseger é uma aplicação de troca de mensagens baseada em localização. O UMesseger suporta comunicação por voz, vídeo e por mensagens instantâneas entre um grupo de usuários cadastrados (i.e., seus amigos). A localização de cada amigo cadastrado é exibida em um mapa. Um usuário pode iniciar uma interação com seus amigos de acordo com a localização deles, por exemplo, pode solicitar que o sistema o informe quando um amigo específico chegar à sua casa. O sistema obtém a localização do usuário através de recursos embarcados em seu dispositivo móvel, como GPS, sensores ou ainda sistemas de localização aproximada baseados na intensidade do sinal de redes sem fio. O mapa é obtido em servidores de mapas como Google Maps1ou provedores de localizaçãoindoor.
O UMesseger pode adaptar seu funcionamento de acordo com as características da conexão de rede, recursos embarcados nos dispositivos e provedores de localização disponíveis. Por exemplo, caso a conexão de dados seja limitada, ou o dispositivo do usuário chamado não possua câmera, a aplicação converterá uma chamada de vídeo em chamada de voz. Caso o usuá-rio entre em um local fechado e sem sinal de GPS, como em um shopping center, e exista um
serviço de posicionamentoindoor, o sistema trocará para o provedor de localização disponível e carregará o mapa do local. Nesse momento, uma localização semântica pode ser obtida, como praça de alimentação, estacionamento, segundo piso ou loja de esportes. O usuário pode ainda estar em um ambiente que estabelece restrições ao modo de comunicação em determinadas da-tas e horários (teatro, cinema). Assim, a aplicação se adaptaria automaticamente para converter mensagens de voz para texto, e mudar o perfil do dispositivo para o modo silencioso.
Neste exemplo, pode-se perceber a existência de interação entre diversos disposi-tivos móveis e diferentes provedores de localização e mapas. Observa-se ainda que o usuário pode se mover por diferentes cenários, utilizando diferentes recursos (e.g., GPS, RFID, WiFi, 3G) para coletar informações de contexto. O comportamento ideal desse sistema ubíquo é alcançado quando os recursos necessários para atender as necessidades do usuário ficam dis-poníveis em qualquer lugar que ele se encontre e a todo momento. Dessa forma, percebe-se a necessidade de uma abordagem de gerenciamento de contexto distribuída, descentralizada, com baixo acoplamento e que permita a coordenação de componentes através da formação de redes Ad hoc.
1.2 Motivação
Em um cenário em que há interação entre diversos dispositivos móveis e diferentes provedores de serviços, e em que o usuário pode se mover por diversos contextos e utilizar diferentes dispositivos com diferentes recursos, uma abordagem de coordenação distribuída e desacoplada se torna necessária para garantir adaptação dinâmica (SOUZA, 2009). Um modelo de coordenação para sistemas ubíquos deve considerar a volatilidade e a dinamicidade de seus componentes. Tratando-se de dispositivos móveis, a coordenação, de forma descentralizada, das ações de cada dispositivo para que seja possível o compartilhamento de recursos e informações de contexto é o desafio a ser enfrentado.
2011; MAIA; ROCHA; ANDRADE, 2009).
Na última década, muitas pesquisas têm apresentado middlewares, infra-estruturas de software e frameworks para suportar os requisitos da computação ubíqua (BELLAVISTA et al., 2012). Uma solução que é proposta com frequência e tem sido bem aceita pela comu-nidade científica é uso conjunto dos paradigmas de Espaço de Tuplas e Sistemas Baseado em Eventos. Essa abordagem é empregada na construção de sistemas ubíquos como solução que promove desacoplamento, pro-atividade e sensibilidade ao contexto (LIMA, 2011; MAMEI; ZAMBONELLI, 2009; MURPHY; PICCO, 2006; SOUZA et al., 2012).
Em (LIMA, 2011) é apresentado um sistema de suporte à ubiquidade chamado SysSU2 (System Support for Ubiquity)(LIMA, 2011). O SysSU é uma infra-estrutura de su-porte à ubiquidade que tem o objetivo de atender aos principais requisitos do desenvolvimento de sistemas ubíquos. O SysSU suporta satisfatoriamente os requisitos de coordenação, descri-ção e descoberta de serviços, interoperabilidade e sensibilidade ao contexto. Este sistema de suporte à ubiquidade implementa um modelo de coordenação formado por uma composição dos modelos Linda (CARRIERO; GELERNTER, 1989) ePublish/Subscribe(EUGSTER et al., 2003) e ainda especifica uma sintaxe para troca de mensagens independente de linguagem de programação ou plataforma de desenvolvimento.
De acordo com (LIMA, 2011), o SysSU se destaca entre outras abordagens para coordenação como (MURPHY; PICCO, 2006) e (MAMEI; ZAMBONELLI, 2009), por ofere-cer uma infra-estrutura de serviço e coordenação que são desacopladas e interoperáveis. Por outro lado, uma desvantagem do SysSU em relação aos trabalhos citados anteriormente é o fato de possuir acesso centralizado a informações de contexto, não sendo aplicável em sistemas baseados em redes Ad hoc.
O SysSU é baseado em espaço de tuplas centralizado. Apesar dessa estratégia de coordenação simplificar o gerenciamento, essa abordagem faz com que todas as informações contextuais, representadas por tuplas, sejam armazenadas em um mesmo local. O acesso exclu-sivamente centralizado ao dados contextuais inviabiliza a comunicação diante de desconexões constantes e não permite que aplicações ubíquas executem sem estar conectadas a um servidor central. Portanto, para que o SysSU seja uma opção de middleware ubíquo com maior aplica-bilidade em sistemas ubíquos móveis, abertos e que se adapte dinamicamente à moaplica-bilidade do
usuário é necessário que ofereça suporte à comunicação em redes Ad hoc.
1.3 Objetivo, Metas e Contribuições
O objetivo deste trabalho é propor uma extensão do SysSU para fornecer suporte à computação ubíqua, permitindo a comunicação Ad hoc e adaptação dinâmica ao contexto de seus componentes. Esta extensão, denominada SysSU-DTS (System Support for Ubiquity -Distribute Tuple Space), implementa o conceito de espaço de tuplas distribuído e utiliza uma camada de comunicação adaptativa.
O SysSU-DTS possui como principal objetivo habilitar o SysSU a lidar com es-paço de tuplas distribuído entre os dispositivos participantes da comunicação. O SysSU-DTS é flexível o suficiente para permitir o funcionamento do sistema tanto através de uma rede infra-estruturada quanto em redes Ad hoc, além de possibilitar o funcionamento independente baseado apenas no espaço de tupla local (embarcado no dispositivo).
O espaço de tuplas distribuído permite a troca de mensagens de coordenação e tam-bém o gerenciamento do contexto global do sistema, no qual os dados armazenados podem estar distribuídos entre os dispositivos móveis e também em servidores centralizados. Cada dispositivo possui um espaço de tupla interno. Dessa forma, mesmo na ausência de um servi-dor, as aplicações podem se comunicar através da formação de uma rede Ad hoc. As tuplas contextuais podem ser acessadas e propagadas através dos espaços de tuplas de cada nodo da rede, de acordo com regras de propagação previamente definidas. A disseminação dos dados contextuais em redes Ad hoc é realizado usando-se redes ponto-a-ponto (P2P -peer-to-peer).
O acesso aos espaços de tuplas pode ocorrer de três formas: (i) acessolocal, acessa o espaço de tuplas que está interno ao dispositivo; (ii)infra-estruturado, acesso a um espaço de tuplas localizado em um servidor por meio de uma rede infra-estruturada; ou (iii) acesso Ad hoc, interagindo diretamente com espaços de tuplas localizados em dispositivos próximos através da formação de uma rede Ad hoc.
O SysSU-DTS fornece suporte para aplicações em geral que possuam requisitos comuns a sistemas distribuídos, moveis e descentralizados. Algumas aplicações que podem se beneficiar da infraestrutura oferecida pelo SysSU-DTS são aplicações com foco emCrowd Sensing, que podem acessar informações de contexto capturadas por diferentes dispositivos, tendo acesso a uma visão global do contexto do componentes do sistema. Outras aplicações como jogos pervasivos, aplicações para cuidar de idosos, assim como aplicações desenvolvidas para cenários de desastre, podem se valer da possibilidade de execução independente de uma infra-estrutura de comunicação fixa oferecida pelo SysSU-DTS.
Em resumo, O SysSU-DTS herda as características de suporte á ubiquidade do SysSU e oferece como principais contribuições:
1. Acesso transparente a espaços de tuplas distribuídos. A aplicação não precisa definir a forma de acesso nem tão pouco o tipo de espaço de tupla a ser acessado (local, infra-estruturado ou Ad hoc).
2. Suporte à criação de um contexto global. As informações de contexto capturadas em cada dispositivo podem ser acessadas e agrupadas para a formação de um dado contextual global.
3. Mecanismo de escopo que pode ser empregado para definir o acesso a espaço de tuplas lo-cais, infra-estruturado ou distribuído entre os dispositivos próximos e ainda para restringir o acesso a informações contextuais distribuídas.
1.4 Organização da Dissertação
Além da introdução aqui apresentada, este trabalho é dividido nos seguinte capítu-los:
• O capítulo 3 descreve o SysSU, o qual foi o ponto de partida desta pesquisa, além dos principais trabalhos relacionados a essa pesquisa: LIME, TOTA, EXEHDA-TS e Contory.
• No capítulo 4 é apresentado o SysSU-DTS, detalhando sua arquitetura, funcionalidades, forma de utilização e detalhes da estratégia de acesso transparente a provedores de con-texto, mecanismo de escopo e formação de contexto global.
• No capítulo 5 são descritos os aspectos envolvidos com a configuração do testbed dos experimento e a avaliação de desempenho do SysSU-DTS.
2 FUNDAMENTAÇÃO TEÓRICA DA PESQUISA
Diante da complexidade do desenvolvimento de aplicações ubíquas, a literatura (FERRY et al., 2009; LIMA et al., 2011; ROCHA; ENDLER; SIQUEIRA, 2008) propõe o uso de arquiteturas, middlewares e sistemas de suporte que facilitem a ubiquidade. Esses sis-temas possuem características específicas devido ao seu caráter móvel, distribuído e dinâmico, que são apresentadas neste capítulo.
2.1 Computação Ubíqua e Conceitos Relacionados
Sistemas ubíquos móveis encapsulam todas as complexidades associadas a sistemas distribuídos, móveis, autonômicos e adaptativos. Está seção apresenta as principais caracterís-ticas, requisitos e os desafios enfrentados no desenvolvimento de sistemas ubíquos.
2.1.1 Introdução à Computação Ubíqua
Historicamente, a computação tem evoluído a forma como os usuários interagem com os computadores. De acordo com os ambientes computacionais predominantes, como visto na Figura 2.1, essa evolução pode ser classificada em três períodos: (i) período inicial, com o uso de mainframes; (ii) o período atual, com o surgimento dos computadores pessoais e portáteis; e (iii) um período futuro, com o advento da computação ubíqua, no qual um único usuário possui diversos dispositivos (smartphones, tablets, ultrabooks), o sistema é voltado ao usuário, e o principal objetivo do sistema é fornecer acesso a informação a qualquer momento e onde quer que o usuário esteja (HANSMANN et al., 2003; BICK; KUMMER, 2008).
“A computação ubíqua tem como objetivo melhorar o uso do computador, fazendo muitos computadores disponíveis em todo o lugar, mas tornando-os efetivamente
invisíveis para o usuário.” (WEISER, 1991)
Figura 2.1: Do mainframe à ubiquidade (adaptado de (BICK; KUMMER, 2008)).
“O uso de um conjunto de computadores dos mais variados tamanhos, formatos e funções, que, de forma coordenada e autônoma, auxiliam as pessoas na realização
das diversas tarefas cotidianas. Esse auxílio é realizado de tal forma que a infra-estrutura computacional responsável fica escondida no ambiente.” (LIMA, 2011)
Nesta definição, fica evidente que a autonomia e a coordenação entre os dispositivos de hardware e os componentes de software são pontos fundamentais na construção de sistemas ubíquos. Por ser uma área de pesquisa em constante evolução, o conceito de computação ubíqua pode ser associado à computação pervasiva1, a computação pervasiva se preocupa mais estrita-mente com a inserção de recursos computacionais, como sensores e atuadores, no ambiente, de forma invisível para o usuário, tornando o ambiente ao seu redor inteligente e interativo.
Tais sistemas possuem características próprias que se relacionam à sensibilidade ao contexto, adaptabilidade e mobilidade, essas característica foram listadas e discutidas em diferentes pesquisas da área (SPÍNOLA; SILVA; TRAVASSOS, 2007; JAROUCHEH; LIU; SMITH, 2009). Nestas pesquisas existe um consenso científico sobre o comportamento espe-rado de um sistemas ubíquo, muito embora ainda não se encontre uma solução que contenha todos. Em (LIMA, 2011) é apresentada uma compilação dessas características, listadas a seguir:
1. Captura de experiências e intenções – o sistema deve perceber o comportamento do usuário e atender suas necessidades sem que sejam solicitadas de forma explícita;
2. Comportamento adaptável– o sistema deve se adaptar dinamicamente ao contexto;
3. Descentralização – os dispositivos que compõem o sistema devem possuir diferentes responsabilidades e cooperar entre si para prover inteligência ao ambiente;
4. Descoberta automática de serviços – os serviços desejados são descobertos de forma proativa, sem a intervenção do usuário;
5. Heterogeneidade de dispositivos e serviços – o sistema deve ser capaz de operar satis-fatoriamente em uma grande variedade de dispositivos e serviços;
6. Interoperabilidade espontânea– os diversos dispositivos e serviços interagem de forma automática e sem a intervenção do usuário;
7. Mínima intervenção do usuário – o sistema deve operar de forma discreta. O contato direto do usuário com os dispositivos eletrônicos que formam o ambiente ubíquo deve ser evitado ao máximo;
8. Onipresença dos serviços – o sistema deve permitir que os usuários se movam pelo ambiente ou troquem de dispositivos sem que o serviço acessado seja interrompido; e
9. Tolerância a falhas – o sistema deve se recompor autonomicamente quando ocorrerem falhas.
Diante dos desafios encontrados no desenvolvimento de sistemas ubíquos, esta pes-quisa está direcionada principalmente a coordenação distribuída dos componentes que integram esses sistemas. O sistema deve estar apto a se adaptar diante da perda de conexão com al-gum dispositivo móvel, assim como ao surgimento repentino de vários dispositivos ao mesmo tempo. É importante que sistemas distribuídos coordenem suas ações de modo a atingir um objetivo comum. Essa coordenação permite a autonomia necessária para a adaptação dinâmica tanto diante de mudanças no contexto quanto diante de falhas no sistema (SYKES et al., 2008).
que este deve estar ciente do contexto ao qual pertence. Essa característica fundamental para sistemas ubíquos é chamada de sensibilidade ao contexto, descrita da subseç ao 2.1.2.
2.1.2 Sensibilidade ao Contexto
Sistemas ubíquos ou pervasivos devem estar cientes do contexto ao qual estão inse-ridos, uma vez que precisam se adaptar automaticamente às suas mudanças. Contexto pode ser definido como:
“Contexto é qualquer informação que pode ser usada para caracterizar a situação de uma entidade. Uma entidade pode ser uma pessoa, um lugar ou um objeto
que é considerada relevante para a interação entre um usuário e uma aplicação, incluindo o próprio usuário e a própria aplicação”. (ABOWD et al., 1999)
Esta definição de contexto foi amplamente adotada em pesquisas nesta área. Ainda em (ABOWD et al., 1999) é definido que sistemas sensíveis ao contexto são aqueles que utili-zam as informações de contexto para prover serviços e informações adaptados/direcionados/es-pecíficos aos usuários e à atividade sendo realizada.
A definição de contexto de (ABOWD et al., 1999) foi estendida para que fosse removida a restrição de que o contexto deve estar relacionado diretamente à interação entre o usuário e o sistema. Viana (VIANA, 2010) define contexto como:
“Contexto é qualquer informação que pode descrever a situação das entidades, e suas relações, envolvidas em uma ação que é considerada importante pelo sistema.
Essas entidades são todos os conceitos abstratos e objetos físicos presentes na zona de observação do sistema em um determinado instante tn de observação”.(VIANA, 2010)
uso de um provedor de localizaçãoindoorde um shopping center, sua zona de observação está restrita à área do shopping. Já a zona de interesse abrange apenas as entidades e relações às quais o sistema considera serem importantes para seu funcionamento. No caso do UMesseger, o dispositivo móvel do usuário está interessado em informações de posicionamento, e apesar de poder observar as informações da temperatura do ambiente, essa informação não se mostra relevante para o sistema, ficando fora da sua zona de interesse. O contexto de um sistema é formado pela interseção entre a zona de observação (suas entidades e relações observadas) e a zona de interesse (suas entidades e relações que as caracterizam), como ilustrado na Figura 2.2.
A partir do sensoriamento do contexto, o sistema pode então se adaptar a eventuais mudanças, sejam mudanças causadas por alterações do ambiente externo à aplicação, como a aparição de uma nova entidade na zona de observação, ou internas à aplicação, como a perda de conexão com um provedor de contexto (GPS, termômetro). Essa adaptação pode ocorrer de duas formas: adaptação por parâmetro e adaptação por composição (MCKINLEY et al., 2004).
Figura 2.2: Relação entre contexto, zona de observação e zona de interesse (adaptado de (VI-ANA, 2010)).
durante o projeto original de construção do sistema. Os parâmetros podem ser ajustados para que a aplicação passe a adotar uma estratégia diferente da que já exista, mas as estratégias implementadas após a construção da aplicação não podem ser adotadas. Um exemplo de adap-tação por parâmetro é o ajuste do conteúdo de uma aplicativo móvel à diferentes resoluções de tela, no qual o tamanho da tela é passado como parâmetro para que ocorra a adaptação.
Adaptação de composição permite a troca de componentes do sistema por outros que melhorem seu desempenho no ambiente corrente. É possível adotar novos algoritmos para lidar com situações imprevistas durante o projeto original. Esta adaptação dinâmica é necessá-ria, por exemplo, quando é preciso adicionar um novo comportamento para que o sistema em execução seja capaz de incorporar novas condições ou requisitos não previstos.
Para abstrair a complexidade envolvida no sensoriamento, adaptação às mudanças de contexto e demais requisitos dos sistemas ubíquos, são necessárias infra-estruturas de soft-ware, como sistemas de suporte e middlewares. Dessa forma, o desenvolvimento de aplicações ubíquas é facilitado, uma vez que o desenvolvedor pode fazer uso de soluções prontas e reutili-záveis para os principais problemas encontrados. Na subseção 2.1.3 é apresentado o conceito de middleware ubíquo, que deve ser capaz de suportar, entre outros, os requisitos de adaptabilidade e sensibilidade ao contexto.
2.1.3 Middleware Ubíquo
Middleware é a camada de software que fica entre as aplicações e os sistemas ope-racionais, responsável por fornecer abstrações que facilitem o desenvolvimento de aplicações. Middlewares ubíquos devem atender aos requisitos da computação ubíqua. Na literatura, são en-contrados trabalhos (LIMA, 2011; MAIA; ROCHA; ANDRADE, 2009; ROCHA, 2009, 2009; ROCHA; ENDLER; SIQUEIRA, 2008) que elencam tais requisitos. Eles devem prover, a qual-quer momento, acesso a informações de contexto heterogêneas, distribuídas e imprevistas em uma escala global e para diferentes cenários, permitindo que clientes descubram novos tipos de contexto e informações restritas a um ambiente, garantindo a interoperabilidade semântica de contexto (ROCHA; ENDLER; SIQUEIRA, 2008).
e que devem ser gerenciados pelo middleware, sendo eles: Coordenação, Descoberta/Descrição de Serviços, Interoperabilidade, Sensibilidade ao Contexto e Adaptabilidade, Invisibilidade e Autonomia. O requisito de sensibilidade ao contexto está diretamente relacionado ao requisito de Adaptabilidade, uma vez que o sistema deve se adaptar a variações de contexto. A seguir são descritos estes conceitos:
Coordenação – Sistemas ubíquos possuem uma característica de descentralização, como visto na subseção 2.1.1. São compostos por diferentes dispositivos (sensores, celulares, tablets, computadores) e necessitam da participação de diferentes componentes de softwares que precisão interagir (trocar mensagens) de forma coordenada, onde cada componente inte-grante do sistema é responsável por uma função, para que o sistema atinja seu objetivo final.
Descoberta/Descrição de Serviços – O sistema deve ser capaz de fornecer descrições dos ser-viços que ele oferece para que os mesmos possam estar disponíveis a atender as neces-sidade de outros integrantes do sistema, que podem buscar os serviços necessários de acordo com seus interesses de execução.
Interoperabilidade – Devido a característica heterogênea dos sistemas ubíquos, seus com-ponentes podem ser construídos em diferentes plataformas, arquiteturas, linguagens de programação ou sistemas operacionais. A interoperabilidade deve garantir que, inde-pendentemente das diferenças de implementação, os diversos componentes possam se comunicar, compartilhando dados ou invocando processos.
Sensibilidade ao Contexto e Adaptabilidade – Como descrito na subseção 2.1.2, sensibili-dade ao contexto é a habilisensibili-dade de fornecer informações do ambiente que sejam relevantes para uma aplicação ou serviço. A partir das informações de contexto obtidas, o sistema deve ser capaz de modificar seu comportamento, o que caracteriza sua adaptabilidade.
Os middlewares ubíquos podem ser classificados quanto a forma como eles promo-vem ubiquidade (ROCHA; ENDLER; SIQUEIRA, 2008). Essa classificação se divide em duas categorias: (a) middlewares que promovem ubiquidade localizada, isto é, a ubiquidade está li-mitada a um domínio físico ou aplicação, e (b) middlewares que promovem ubiquidade global, ou seja, suportam acesso a contexto de grandes espaços físicos e domínios de aplicação. Nossa pesquisa pretende promover ubiquidade global, focando na coordenação e adaptação dinâmica de seus componentes.
Na próxima subseção é explorado o conceito de computação autonômica, suas ori-gens e como ela está diretamente incorporada à computação ubíqua. É Apresentado ainda um modelo arquitetônico de referência.
2.1.4 Computação Autonômica
A computação autonômica abrange sistemas capazes de se auto gerenciar, com-postos por elementos que interagem para atingir objetivos globais (ROCHA; ENDLER; SI-QUEIRA, 2008). O comportamento autônomo de um sistema está intrinsecamente relacionado à sua ubiquidade, uma vez que o sistema ubíquo deve tomar decisões em prol de satisfazer as necessidades do usuário com a mínima intervenção do mesmo.
Sistemas Autônomos também são chamados de sistemas auto gerenciáveis. O con-ceito de computação autonômica surgiu nos laboratórios da IBM (HORN, 2001), e foi de en-contro a necessidade da construção de sistemas auto gerenciáveis, adaptáveis a mudanças e que evitem a intervenção humana. Destacam-se quatro propriedades básicas para sistemas auto gerenciáveis, ou autônomos:
Autoconfiguração – Capacidade de configurar-se automaticamente a partir de metas de alto nível, objetivos globais, sem necessidade de instruções específicas de como atender esses objetivos;
Autocura – Capacidade de detectar, diagnosticar e se possível corrigir um mau funcionamento. Tolerância a falhas é um aspecto importante de auto-cura, isto é, um sistema autônomo deve ser reativo a falhas ou prever sinais de uma possível falha;
a um comportamento reativo) na tentativa de melhorar o desempenho ou a qualidade de serviço; e
Autoproteção – Capacidade de reagir contra ataques maliciosos. Um sistema autônomo deve proteger-se de ações maliciosas, intencionais ou não, e também dos usuários finais que, inadvertidamente, ao fazer alterações de software, por exemplo, podem excluir um ar-quivo importante. O sistema autonomamente se ajusta para alcançar segurança, privaci-dade e proteção de dados. A segurança é um aspecto importante de autoproteção.
É comum que sistemas autônomos adotem laços de controle, como o MAPE-K (Monitor, Analyse, Plan, Execute, Knowledge) (HUEBSCHER; MCCANN, 2008), apresentado na Figura 2.3, para gerenciar automaticamente a forma como interagem com o ambiente e entre seus componentes. improving system availability at a reasonable computational cost O MAPE-K é um laço autônomo que possui etapas de monitoramento, análise, planejamento, execução e geração de conhecimento, no qual um agente inteligente percebe o ambiente através de sensores e usa essas percepções para determinar as ações a serem executadas. No MAPE-K, o elemento gerenciado representa qualquer software ou recurso de hardware a quem é dado um comportamento autônomo através do acoplamento do gerenciador autônomo (HUEBSCHER; MCCANN, 2008).
Figura 2.3: Laço de controle – MAPE-K (adaptado de (HUEBSCHER; MCCANN, 2008)).
em (GAT et al., 1998), como um meio de identificar mais precisamente as preocupações e questões de pesquisas relevantes para o progresso dos sistemas auto gerenciáveis. A arquitetura proposta é composta por uma camada mais baixa, de controle de componente, uma camada intermediária de gerenciamento de mudanças e uma camada mais alta de gerenciamento de objetivos. A Figura 2.4 mostra graficamente a organização destas camadas.
Figura 2.4: Modelo de Arquitetura em Três Camadas para Auto Gerenciamento (adaptado de (KRAMER; MAGEE, 2007)).
Neste modelo, a camada mais alta, chamada de camada de gerenciamento de obje-tivos, compreende o processo de planejamento deliberativo. Os planos são gerados para atingir os objetivos especificados, levando em consideração as mudanças no estado atual do sistema. Novos planos são gerados sempre que novos objetivos são introduzidos ou em resposta a soli-citações de mudanças da camada inferior.
A camada intermediária, designada por camada de gerenciamento de mudanças, é responsável pela execução do plano. Dada uma nova situação, essa camada se encarrega de executar ações, ou sequencia de ações, para resolver o problema. Ela possui um conjunto de planos de ação pré-definidos para lidar com as mudanças reportadas pela camada inferior, e no caso de não encontrar um plano adequado para executar, é solicitado um novo plano à camada superior.
que realizam a função da aplicação. Esta camada deve suportar a criação, remoção e interli-gação de componentes. Uma característica importante é que quando uma situação requer uma configuração de componentes que não foi projetada, esta camada detecta essa falha e informa para as camadas superiores.
Existem dois ciclos de feedback entre cada camada. A camada de gerenciamento de objetivos fornece novos planos para a camada de gerenciamento de mudanças, enquanto esta camada pode solicitar um novo plano. A camada de gerenciamento de mudanças gera novas configurações de componentes na camada de componentes, enquanto a camada de componentes pode provocar uma nova configuração a ser gerada por relatar uma mudança de estado, tais como falha de componentes.
De acordo com (KRAMER; MAGEE, 2007), preservar o estado de execução sa-tisfatório da aplicação durante mudanças de contexto e garantir que informações não sejam perdidas durante a reconfiguração dos componentes são questões importantes, que fazem parte da camada de controle de componentes. Desafios como estes, encontrados na implementação de sistemas autônomos, são comuns à implementação de sistemas ubíquos, sobretudo no que diz respeito a adaptabilidade e autonomia, características essenciais para que o sistema execute com a mínima intervenção do usuário, um ponto marcante da ubiquidade. Neste sentido, pode-se fazer uso de modelos de coordenação para gerenciar a interação entre os componentes do sistema, o conceito de modelo de coordenação é descritos na próxima seção.
2.2 Modelos de Coordenação
Modelos de coordenação podem ser adotados para alcançar bons níveis de coope-ração entre os componentes de um sistema ubíquo, eles podem configurar uma solução para lidar com cenários dinâmicos e altamente distribuído. A adoção de tais modelos permite a se-paração entre as atividades de computação e de coordenação (TANENBAUM; STEEN, 2006). A coordenação de atividades pode ser entendida como um modelo de interação que descreve a forma como os componentes de software presentes no sistema devem se comportar para que a atividade esperada seja realizada (COULOURIS et al., 2005).
em Eventos; e Modelos de Coordenação Baseado em Espaço de Dados Compartilhado. Esses modelos são descritos a seguir.
Modelo de Coordenação Direta - Neste modelo os componentes distribuídos coordenam suas atividades por meio de comunicação direta e explícita. Assim, as entidades envolvidas devem se conhecer com antecedência. Essa abordagem resulta em um forte acoplamento das entidades envolvidas, uma vez que implica na coexistência no tempo e conhecimento explícito de suas localizações. O modelo de coordenação direta não é adequado para sistemas ubíquos, uma vez que requer uma interação direta e explícita.
Modelo de Coordenação Baseados em Eventos - Este modelo utiliza um mecanismo de pu-blicação e subscrição de eventos (Publish/Subscribe) para promover a interação entre os componentes distribuídos (MAMEI; ZAMBONELLI, 2009). Essa forma de interação resulta em um desacoplamento referencial. Em sistemas distribuídos, o acoplamento re-ferencial ocorre quando é necessário conhecer a referência (endereço de rede) da entidade que com a qual se pretende estabelecer um canal de comunicação. Por outro lado, esse modelo de coordenação possui acoplamento temporal, o que significa que as entidades envolvidas na comunicação devem estar ativas ao mesmo tempo. Para ser notificada, Uma entidade subscrita em um evento de outra entidade, deve estar ativa no sistema no mesmo momento em que este evento for publicado.
Modelo de Espaço de Dados Compartilhado - Modelo introduzido em (CARRIERO; GE-LERNTER, 1989) como Espaço de Tuplas. Consiste de uma memória associativa inde-pendente e compartilhada entre todos os nós do sistema (YAMIN, 2004). Esta memória pode ser considerada como um repositório de estruturas de dados chamadas tuplas. O Espaço de Tuplas permite que a comunicação entre os processos ocorra por meio da in-trodução (put) e leitura (read/take) de tuplas neste espaço compartilhado. Desse modo, a comunicação pode ocorrer mesmo entre entidades do sistema que não estão ativas ao mesmo tempo, promovendo a dissociação temporal. Esse modelo possibilita também o desacoplamento referencial, uma vez que as entidades envolvidas na leitura e escrita das tuplas não precisam ter nenhuma informação uma da outra.
atender às demandas de coordenação das aplicações alvo desta pesquisa, que são caracterizados pela distribuição, mobilidade e adaptação contexto, foi adotado o uso espaço de tuplas distri-buído, associada ao modelo baseado em evento Publish/Subscribe. Baseado nesses modelos, esta dissertação se propõe a estender uma infra-estrutura existente (LIMA, 2011) para geren-ciar as informações contextuais existentes nos espaços de tuplas de forma distribuída, com um comportamento pró-ativo e características de desacoplamento referencial e temporal.
2.3 Contexto Distribuído
Os dados contextuais podem ser capturados e armazenados de diferentes formas. Seja por dispositivos móveis, como smartphones e tablets, que acompanham o usuário nas diversas atividade do seu dia. Seja através de veículos inteligentes compondo uma VANET (Vehicular Ad-hoc Network)(HARTENSTEIN; LABERTEAUX, 2008) ou ainda em ambientes inteligentes, como as casas inteligentes, museus e ambientes com guia de visita móvel (MARI-NHO et al., 2010), nos quais há a presença de sensores embutidos no ambiente. Em sistemas ubíquos, o acesso às informações contextuais oriundas de diferentes fontes e a todo momento é essencial para se atender aos requisitos de sensibilidade ao contexto e invisibilidade citados na subseção 2.1.3.
Distribuição de dados de contexto é a capacidade de reunir e entregar informações contextuais relevantes para todas as entidades interessadas conectadas a um sistema ubíquo móvel (BALDAUF; DUSTDAR; ROSENBERG, 2007). A distribuição de dados contextuais é também chamada de provisionamento contextual. O gerenciamento das informações con-textuais é um processo que envolve duas entidades principais, o provedor e o consumidor de contexto. Considerando sistemas ubíquos abertos, que promovam ubiquidade global, é comum que ocorra situações em que não exista um acesso único e centralizado a essas informações. As informações de contexto estão distribuídas entre as diversas entidades do sistema, e uma mesma entidade pode exercer o papel de provedor e consumidor contexto. Segundo (BELLAVISTA et al., 2012), a distribuição eficaz e eficiente de informações de contexto é essencial para a im-plantação de serviços verdadeiramente sensíveis ao contexto. É preciso que estas informações cheguem a todas as entidades interessadas.
ser considerados na distribuição de dados de contexto, a saber:
Desacoplamento na produção/consumo de dados contextuais - A produção e o consumo de dados de contexto devem possuir desacoplamento temporal e referencial para promover um roteamento transparente dos dados de contexto. A comunicação deve ser assíncrona e anônima entre os produtores e consumidores de contexto, como proposto pelo modelo de coordenação baseado em eventosPublish/Subscribeque foi descrito na seção 2.2.
Adaptação à ambientes com conexões sem fio móveis e heterogêneas - O sistema deve estar preparado para executar com os recursos disponíveis no momento, seja Wi-Fi, Bluetooth, ou qualquer outra tecnologia sem fio, podendo migrar entre elas de acordo com as varia-ções no contexto e distribuir os dados de contexto apenas quando necessário. Nós móveis que necessitem de informações de contexto podem surgir e desaparecer, bem como passar por mudanças em seus requisitos de contexto, mudanças essas que podem ser representa-das como variações na zona de interesse e/ou zona de observação do sistema sensível ao contexto, conforme descrito da definição de contexto de (VIANA, 2010) que foi apresen-tada na subseção 2.1.2. Além disso, a distribuição de dados contextuais deve se preocu-par com a execução em sistemas heterogêneos, incluindo nós com diferentes capacidades computacionais, padrões e modalidades de comunicação sem fio.
Diferentes escopos de visibilidade para dados de contexto - A distribuição de dados contex-tuais deve definir, preservar e assegurar diferentes visibilidades contexto para evitar a saturação do sistema e o gerenciamento desnecessário de dados contextuais. Essa visi-bilidade é limitada por escopos que dependem de princípios lógicos e físicos. O escopo lógico é definido segundo o domínio da aplicação, por exemplo dados contextuais li-mitados a alunos que cursam uma mesma disciplina. Já o escopo físico é definido por característica relacionadas ao alcance de propagação dos dados contextuais, por exemplo o escopo pode ser limitado por nós que estejam em um mesmo local, conectados em uma mesma sub-rede, ou ainda limitado por um determinado número de saltos nos nós da rede.
expressar os requisitos de qualidade e as propriedades dos dados contextuais (por exem-plo, precisão, validade, integridade, confiabilidade, etc). Parâmetros de QoC podem ser úteis principalmente em cenários onde existam frequentes desconexões e garantia de en-trega limitada, nesses casos pode-se exigir que o dado contextual seja entregue com certa pontualidade e garantia de confiabilidade.
Gerenciamento do ciclo de vida dos dados contextuais - Os dados de contexto devem pos-suir um ciclo de vida que defina como ele será construído e destruído em um determinado momento, a fim de reduzir a sobrecarga na gestão. Cada dado contextual pode possuir uma propriedade que represente o seu tempo de vida, devem existir regras que determi-nem o momento em que esse dado deixa de ser útil para o sistema, seja por ter expirado sua validade ou atingido seu objetivo final, seja por ter sido consumido ou agregado a um outro dado de contexto. De fato, técnicas de agregação, bem como técnicas de filtra-gem de dados contextuais são importantes e podem ser empregadas para fazer inferências sobre o contexto global do sistema, e também para criar dados contextuais de mais alto nível.
2.4 Conclusão
3 TRABALHOS RELACIONADOS
Este capítulo apresenta alguns trabalhos que se destacam entre as infraestruturas de software propostas para auxiliar o desenvolvimento de sistemas móveis ubíquos. Os projetos foram selecionados por possuírem características intimamente relacionadas à proposta deste trabalho. Eles apresentam modelos de coordenação baseados em espaço de tuplas e imple-mentam mecanismos de evento, reagindo a mudanças no espaço de tuplas. Foram projetados para sistemas móveis e sensíveis ao contexto adequando-se, assim, aos principais requisitos da computação ubíqua.
Este capítulo está dividido em sete seções, as cinco primeira descrevem respecti-vamnte as seguintes infraestruturas: SysSU, LIME, TOTA, EXEHDA-TS e Contory. O SysSU é descrito com maior detalhes pois é a infraestrutura que deu origem a este trabalho. A duas últimas seções apresentam uma comparação entre os trabalhos listados e sua relacão com o trabalho proposto e a conclusão do capítulo.
3.1 Sistema de Suporte SysSU
O SysSU (System Support for Ubiquity)(LIMA, 2011) é uma infraestrutura de su-porte ao desenvolvimento de sistemas ubíquos baseada nos modelos Linda (CARRIERO; GE-LERNTER, 1989) e Publish/Subscribe (EUGSTER et al., 2003). Ele utiliza tuplas para re-presentar dados contextuais e permite que as entidades do sistema se comuniquem de forma desacoplada e interoperável. O SysSU realiza o gerenciamento das informações de contexto de forma centralizada e oferece mecanismos para troca de mensagens, coordenação de atividades e descoberta/invocação de serviços.
disso, o SysSU possui componentes especiais chamados Agregadores, que atendem ao requisito de gerenciamento do ciclo de vida dos dados contextuais, citado na seção 2.3. Os Agregado-res estão associados ao UbiCentre e permitem que sejam feitas composições de campos, tuplas e/ou eventos. Um Agregador tem a finalidade de gerar novas tuplas oriundas da composição de tuplas existentes, por exemplo, gerar uma tupla com o valor médio da temperatura coletada por todos os dispositivos em um ambiente.
Figura 3.1: Arquitetura original do SysSU (LIMA et al., 2011).
As funcionalidades oferecidas pelo UbiCentre são baseadas nas operações realiza-das sobre os espaços de tuplas por ele gerenciados. Essas operações seguem uma padronização de comportamento formada por um conjunto fixo de primitivas baseadas em lógica de primeira ordem e teoria dos conjuntos.
No SysSU uma tupla é formada por um conjunto de campos do tipo chave/valor (e.g. {(name, “roberto”), (location, “casa”)}). O UbiCentre oferece importantes funcionalida-des sobre o conjunto de tuplas que formam seus espaços de tuplas, dentre elas funcionalida-destacamos o mecanismo de associação (Matching) e mecanismo de eventos (Reactions).
subcon-junto de tuplas que satisfazem um padrão da tupla e a um filtro, o par ordenado composto por uma padrão de tupla e um filtro é chamado deQuery, esse mecanismo vai de encontro ao que foi definido no requisito de gerenciamento do ciclo de vida dos dados contextuais, citado na seção 2.3, o qual destaca a importância da adoção de técnica de filtragem de dados contextuais para a inferência sobre os mesmos.
Um padrão de tupla define o formato, valor e/ou o tipo de dado que a tupla possui, por exemplo, o padrão de tupla (null, string),(null, string), representa tuplas contendo dois campos do tipo string, já o padrão {(contextData, “umidade-relativa”), (value, null)}, representa tuplas com qualquer valor de umidade relativa. O filtro é definido através de uma função booleana, na qual apenas as tuplas que satisfizerem essa função poderão ser selecionadas pelo mecanismo de associação.
Os filtros são escritos usando a linguagem Javascript, o que gera maior expressividade e dinamicidade para expressar relações entre os campos das tuplas. Assim, com esse mecanismo de associação é possível, por exemplo, fazer uma consulta por todas as tu-plas com informações contextuais de temperatura coletadas pelo termômetro interno do dispositivo e que possuam valor superior a 25. Para isso basta utilizar uma Query com-posta pelo padrão de tupla {(contextData, “temperatura-ambiente”), (value, null)}, e pelo filtro “function filter(tuple) {return (tuple.value > 25 && tuple.source == ’termometroIn-terno’)}”.
Mecanismo de Eventos: O mecanismo de eventos possui um conjunto de ações, chamado de
Reaction, que devem ser realizadas dada a ocorrência de um evento. Todas as informações relacionadas ao evento devem estar contidas em uma tupla, que é utilizada como modelo de dados, enquanto que os padrões de tuplas são utilizados como modelo de filtros. A principal operação deste mecanismo é a subscrição ao um evento, na qual é informado o identificador da Reaction e uma Query. A Reaction será executada sempre que for inserida uma tupla associada a Queryinformada. Uma mesmaQuerypode estar relacio-nada a váriasReactions, quando o evento é disparado todas aReactionsassociadas serão notificadas.
aplicações em relação aos eventos. Esse modelo herda a expressividade das tuplas, pa-drões de tuplas e filtros, e com o uso de filtros pode-se implementar notificações sensíveis ao contexto.
O mecanismo de associação baseado em padrão de tupla e filtros também é utilizado no LIME e no TOTA, mas apenas o SysSU possibilita verificar relacionamentos entre os campos das tuplas. No SysSU os filtros são dinâmicos e são passados por parâmetro nas operações entre UbiBroker e UbiCentre. Uma outra vantagem é que o mecanismos de associação do SysSU promove independência do tamanho das tuplas e da posição dos campos, o que facilita a busca por tuplas. Assim, não é necessário conhecer todos os campos de uma tupla para conseguir consulta-la, e a adição de novos campos em uma tupla não afeta as consultas definidas antes da alteração. Essa característica vai de encontro ao comportamento dinâmico e evolutivo do contexto, citado na subseção 2.1.2 permitindo a representação de informações contextuais através de tuplas.
O SysSU é baseado em espaço de tuplas centralizado, como pode ser visto na Figura 3.1. Apesar dessa abordagem simplificar o gerenciamento, ela faz com que todas as informações contextuais, representadas pelas tuplas, sejam armazenadas em um mesmo local. Dessa forma o SysSU inviabiliza a comunicação diante de desconexões constantes e não permite que aplica-ções ubíquas executem sem estar conectadas a um servidor central. Portando, as contribuiaplica-ções apresentadas nesta dissertação seguem o caminho natural de evolução do SysSU, permitindo que exista mais de uma opção de acesso às tuplas contextuais, seja através de consultas a um servidor, seja através do acesso a tuplas armazenadas localmente, ou ainda através de uma rede Ad hoc.
3.2 LIME
Figura 3.2: Espaços tupla transitoriamente compartilhados (adaptado de (MURPHY; PICCO, 2006)).
O LIME introduz o conceito de compartilhamento transitório de espaço de tuplas, no qual os espaços de tuplas associados a agentes presentes em diferentes dispositivos formam um espaço de tuplas federado, como ilustra a Figura 3.2. Esse compartilhamento é feito por uma composição lógica de todas as tuplas presentes nos espaços de tuplas de cada agente en-volvido. O conjunto das tuplas compartilhadas muda ao longo do tempo, devido a restrições de compartilhamento de cada agente e também devido a mobilidade dos mesmos. Quando um novo dispositivo móvel entra na área de alcance da rede, o conjunto de tuplas compartilhadas se expande, e quando um dispositivo se desconecta, leva consigo suas tuplas e o conjunto de tuplas do espaço de tuplas federado diminui. O gerenciamento do contexto é transparente e é expressado pela mudança do conteúdo das tuplas disponíveis, que aparentam sempre ser locais. Embora tuplas sejam acessíveis a todos dispositivos conectados, cada tupla só existe em um único ponto no sistema, associada a um dos agentes móveis. Assim, a operação de leitura de uma tupla é distribuída, enquanto a escrita é local. No SysSU-DTS os espaços de tuplas estão associados a um dispositivo e o compartilhamento destes é realizado de forma transitória se-guindo a mesma lógica de espaço de tupla federado do LIME, porém esse compartilhamento acorre sob demanda, apenas quando uma aplicação realiza uma consulta distribuída.
LIME permite que tuplas sejam enviadas para um outro dispositivo, estendendo a operação de inserir uma tupla em um destino, cada tupla possui um campo com sua localização atual e um outro com o seu destino.
Reações permitem um pedido de registro de um fragmento de código (um ouvinte), a ser executado de forma assíncrona sempre que uma tupla correspondente a um determinado padrão é encontrado em qualquer lugar no espaço de tuplas federado. Este recurso é muito útil em ambientes móveis e altamente dinâmicos, visto que dispensa o monitoramento explicito do sistema.
A solução proposta pelo middleware LIME possui muitas semelhanças com o que foi proposto pelo SysSU e consequentemente com a proposta deste trabalho. Ambos são base-ados em tuplas e espaço de tuplas, implementam mecanismo de eventos basebase-ados em tuplas e o usam tuplas para representar dados contextuais. Segundo (LIMA, 2011), o SysSU apresenta formas mais flexíveis de consulta aos espaços de tuplas e na descoberta de serviços, além de ser interoperável, característica herdadas pelo SysSU-DTS. O SysSU possui a desvantagem de não ser aplicável a sistemas baseados em redes Ad hoc, essa desvantagem é eliminada a partir das contribuições propostas neste trabalho de mestrado.
3.3 TOTA
No TOTA, as tuplas são definidas pela composição de três elementos: Conteúdo, Regra dePropagação, e Regra deManutenção.
❚ ❂ ✭❈✱ P✱ ▼✮.
As informações da tupla propriamente dita, é representado pelo conteúdo❈, e diz repeito a um conjunto ordenado de campos tipados acessados através de mecanismo de asso-ciação com um padrão de tupla. A regra de propagação P determina como a tupla deve ser distribuída e propagada através de todo o sistema. Normalmente as tuplas são injetadas no sis-tema, armazenadas em um nodo local e em seguida são recursivamente clonadas e movidas para os nodos vizinhos. A regra de propagação delimitada o "escopo"da tupla, nesse caso, é consi-derado o escopo físico de propagação, isto é, a distância que a tupla pode percorre baseado no número de saltos na rede. A cada salto de propagação de uma tupla a regra de propagação P pode determinar como o conteúdo da tupla é alterado, portanto a propagação de uma tupla por múltiplos nodos não implica necessariamente em uma distribuição de réplicas, as tuplas podem assumir diferentes valores em diferentes nodos. A regra de propagação pode levar em conside-ração a presença ou ausência de tuplas no sistema. Por fim, a regra de manutenção▼determina como a tupla deve reagir a eventos que ocorrem no ambiente, por exemplo atualizando o valor das tupla ao passar do tempo ou diante de mudanças na topologia da rede.
Ao contrário do Lime, a operação de leitura no espaço de tupla é feita de forma local e a escrita é distribuída. O comportamento reativo também está presente no TOTA e as aplicações podem realizar subscrições caracterizando o evento que deve ser gerado. Os eventos podem estar associados a modificações nos dados armazenados no espaço de tuplas ou a mudanças da topologia da rede. Qualquer evento pode ser representado por uma tupla.
Assim como o TOTA, este trabalho apresenta uma estratégia para limitar o escopo das tuplas, essa estratégia leva em conta não apenas o número de saltos, mas também o escopo lógico definido em cada tupla, por exemplo uma tupla pode definir que só poderá ser lida por um determinado tipo de usuário.
3.4 EXEHDA-TS
di-nâmico, ele realiza o gerenciamento de tuplas distribuídas em espaços de tuplas presentem em cada nodo do sistema. Implementa mecanismos baseados em eventos que notificam as apli-cações sobre informações relevantes à medida que elas são inseridas no espaço de tuplas. A escalabilidade do sistema é garantida mediante parâmetros de visibilidade que restringem o acesso a leitura de tuplas distribuídas.
Cada instância do EXEHDA-TS é associada a uma entidade do sistema é chamada de Objeto EXEHDA (OX), a Figura 3.3 apresenta a forma como é organizado o espaço de tuplas do EXEHDA-TS. Trate-se de uma estrutura celular, que agrupa os espaços de tuplas de cada entidade do sistema (TSox) na forma de um espaço de tupla virtual (TSvirt), mantendo as tuplas sincronizadas em cada célula (EXEHDAcel).
Figura 3.3: Abstração da composição do Espaços tupla do EXEHDA-TS (retirado de (SOUZA et al., 2012)).
ocorre apenas quando requisitado pela aplicação e não é necessário manter uma sincronia entre os espaços de tuplas disponíveis, uma vez que esses podem sofrer desconexões.
3.5 Contory
Contory (RIVA, 2006) é um middleware que oferece suporte ao provisionamento de contexto através de diferentes estratégias de comunicação. Ele foi projetado para funcionar em dispositivos móveis (smartphones) de forma flexível e dinâmica. São oferecidas múltiplas alternativas para o provisionamento de dados contextuais as quais podem ser alternadas de forma dinâmica e transparente de acordo com os recursos disponíveis. Assim como o SysSU-DTS, o Contory permite que informações contextuais sejam obtidas através de sensores internos ao dispositivo, em um servidor de contexto centralizado externo ao dispositivo, ou ainda de forma distribuída, acessando dispositivos através de uma rede Ad hoc.
Enquanto o SysSU oferece a possibilidade de consultas que utilizam JavaScript para criar filtros, o Contory oferece uma interface baseada em SQL(Structured Query Language) para formulação das consultas de dados contextuais, através desta interface as aplicações podem definir o tipo e a qualidade dos dados contextuais desejados, bem como a fonte que originou o dado, o modo de interação, entre outras propriedades que qualifiquem o dado contextual. Apesar de utilizar uma sintaxe padronizada, essa interface baseada em SQL define um linguagem de busca limitada pelo modelo descrito na Figura 3.4.
Figura 3.4: Modelo de consulta de contexto do Contory.
tempo de vida da consulta, que pode ser determinado como o tempo (e.g., 1 hora) ou como o número de amostras que devem ser coletadas em cada rodada (e.g., 10 amostras). A clausula ❋❘❖▼permite identificar o tipo e as características da fonte que origina o dado contextual senso-reado, assim como o mecanismo a ser utilizado para acessar esse dado contextual. Uma vez que a clausula❋❘❖▼ não for especificada, o Contory define a fonte mais adequada de forma autô-noma e dinâmica. ❲❍❊❘❊aplica filtros aos dados contextuais (e.g., precisão = 0.9). ❋❘❊❙❍◆❊❙❙ especifica quão recente o dado contextual deve ser. O Contory possibilita que sejam realiza-das buscas sob demanda, baseada em eventos e ainda buscas periódicas, essa característica é definida através das cláusulas❊❱❊❘❨ e❊❱❊◆❚. Essas cláusulas são mutuamente exclusivas. A cláusula❊❱❊❘❨ permite especificar a taxa em que devem ser recolhidos os dados de contexto (i.e., consulta periódica). A cláusula❊❱❊◆❚determina o conjunto de condições que devem ser cumpridas no nodo do provedor de contexto para que um novo resultado seja retornado (i.e., consulta baseada em eventos).
3.6 Análise Comparativa
Os trabalhos citados se assemelham bastante a esta proposta, porém não oferecem simultaneamente a interoperabilidade, o desacoplamento e a expressividade semântica exis-tentes no SysSU. A Interoperabilidade oferecida pelo SysSU diz respeito a possibilidade de interação entre componentes do sistema desenvolvidos em diferentes plataformas, arquiteturas, linguagem de programação ou sistema operacional. A expressividade oferecida pelo SysSU diz respeito ao mecanismo de filtro utilizado nas consultas associativas a espaços de tuplas, os fil-tros são definidos usando a linguagem Javascript que permite realizar vários tipos de operações e comparações sobre os campos da tupla.
