Lime (Linda in a Mobile Environment) (MURPHY; PICCO, 2006) é um middleware que aprimora o modelo original de Espaço de Tuplas proposto por Linda (CARRIERO; GE- LERNTER, 1989) para ser utilizado em ambientes móveis através de MANETs. O LIME adota uma abordagem de espaço de tuplas descentralizado compartilhando as tuplas de acordo com a conectividade dos dispositivos móveis. Dessa forma, o espaço de tuplas não fica associado a um dispositivo específico (Figura 3.2).
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.
Além do compartilhamento transitório, o LIME adiciona ao modelo Linda os con- ceitos de localização de tuplas e de reações. Apesar da visão de um único espaço de tuplas local criado pelo espaço de tuplas federado facilitar o gerenciamento do contexto, em alguns casos os projetistas de software precisam controlar a localização e disponibilidade de uma tupla. O
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 baseados 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
TOTA (Tuples On The Air) (MAMEI; ZAMBONELLI, 2009) é um middleware projetado com foco na comunicação desacoplada entre componentes de aplicações distribuídas. Uma versão do TOTA é embarcada em cada dispositivo e as tuplas são propagadas, através de multi-saltos pela rede, de acordo com regras de propagação presentes na própria tupla, e podem ser acessadas localmente em outros nodos. O TOTA é composto por uma rede ponto-a-ponto de nodos possivelmente móveis, na qual cada nodo possui um conjunto limitado de referências para os nodos vizinhos com os quais pode se comunicar diretamente, como em um cenário MANET (Mobile Ad Hoc NETwork). Toda interação entre os componentes do sistema é feita através de troca de tuplas, as tuplas não estão associadas a um nodo específico da rede, e não é criada nenhuma noção de compartilhamento de um espaço de tuplas centralizado. O TOTA monitora e atualiza constantemente a composição da rede, disponibilizando a informação de quem entra e quem sai da rede.
No TOTA, as tuplas são definidas pela composição de três elementos: Conteúdo, Regra de Propagação, e Regra de Manutençã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
EXEHDA-TS (Execution Environment for Highly Distributed Application - Tuple Space)(SOUZA et al., 2012) é um modelo de coordenação escalável com comportamento 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)).
A sincronização realizada no TSvirt pode ocorrer de forma permanente ou sob de- manda. No modo de sincronização permanente cada TSox que compõe o TSvirt é acessado em todas as operações de leitura e escrita. Já no modo de sincronização sob demanda um TSox pode optar por não sincronizar seu status em determinados momento a fim de reduzir os custos de comunicação. No caso do SysSU-DTS o compartilhamento das tuplas presentes em cada nó da rede é realizado apenas sob demanda, dessa forma o acesso a espaço de tuplas distribuídos
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.
A Figura 3.4 apresenta o modelo de consulta de contexto criado pelo Contory, no qual as claululas❙❊▲❊❈❚ e ❉❯❘❆❚■❖◆ marcadas com ❬✯❪ s ao mandatórias. ❙❊▲❊❈❚ especifica o tipo co dado contextual (e.g., localização, temperatura, velocidade). ❉❯❘❆❚■❖◆ especifica o
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.
Por outro lado, o SysSU não oferece suporte à operações em redes Ad hoc, uma importante funcionalidade para sistemas ubíquos (MAMEI; ZAMBONELLI, 2009; MURPHY; PICCO, 2006; SOUZA, 2009). A Tabela 3.1 apresenta uma comparação entre os trabalhos relacionados, nessa tabela fica claro que os diferentes trabalhos relacionados possuem a ca- racterística de desacoplamento temporal e referencial presentes no suporte à coordenação de sistemas ubíquos. Porém, não encontramos uma proposta que ofereça interoperabilidade e su- porte à diferentes estratégias de acesso a tuplas distribuídas, ou seja, acesso a espaço de tuplas locais, centralizados e distribuídos de forma transparente. Assim, pode-se perceber a relevância
em habilitar o funcionamento do SysSU em redes Ad hoc, agregando-se estratégias para coor- denação em espaço de tuplas distribuído e transparência nas diferentes abordagens de acesso.
Tabela 3.1: Comparação entre os trabalhos relacionados.
O SysSU-DTS se propõe a atender todos os critérios comparativos da Tabela 3.1, neste trabalho é implementado o acesso transparente a espaços de tuplas embarcados em dis- positivos móveis, centralizados em servidores de contexto e ainda distribuídos em diversos dispositivos móveis conectados em redes Ad hoc. Vale ressaltar que a característica de de- sacoplamento referencial e temporal relativa a coordenação de sistemas ubíquos, bem como a interoperabilidade é herdada do SysSU. Contudo, uma vez que a implementação do SysSU-DTS é direcionada para o sistema operacional Android1, a interoperabilidade herdada do SysSU está presente apenas no acesso a espaço de tuplas centralizados em servidores de contexto. Isto quer dizer que aplicações dos SysSU implementadas em diferentes plataformas, como por exemplo IoS2 e Windows Phone3, podem interagir com aplicações do SysSU-DTS mediante a presença de um servidor que possua uma instância de um UbiCentre e esteja acessível através de uma rede infra-estruturada.
3.7 Conclusão
Neste capítulo foram apresentados os trabalhos relacionados a esta pesquisa. O SysSU, sitema de suporte à computação ubíqua que serviu de ponto de partida para este traba- lho, foi apresentado com maiores detalhes descando-se suas características de desacoplamento e interoperabilidade. Além do SysSU os demais trabalhos relacionados foram: Lime (Linda in a
1http://www.android.com 2http://www.apple.com/ios 3http://www.windowsphone.com
Mobile Environment) (MURPHY; PICCO, 2006), TOTA (Tuples On The Air) (MAMEI; ZAM- BONELLI, 2009), EXEHDA-TS (Execution Environment for Highly Distributed Application - Tuple Space)(SOUZA et al., 2012) e Contory (RIVA, 2006). Foi feita uma comparação entre os trabalhos destacado-se os pontos fortes e fracos de cada um. Por fim, foram identificadas oportunidades de melhoria no SysSU que motivaram as contribuições feitas por este trabalho de mestrado.
4 SYSSU-DTS
Este capítulo trata da proposta desta pesquisa, um sistema de suporte à computa- ção ubíqua baseado em espaços de tuplas distribuídos. Para isso, inicialmente é retomado o objetivo e a motivação deste trabalho. Em seguida são apresentados alguns desafios enfrenta- dos no processo de desenvolvimento do SysSU-DTS. Por fim, é apresentadas a arquitetura do SysSU-DTS, seu funcionamento, sua característica de acesso transparente a espaço de tuplas distribuídos, mecanismo de escopo e como o SysSU-DTS oferece suporte à formação de uma visão de contexto global.
4.1 Introdução
O foco deste trabalho é facilitar a criação de sistemas ubíquos compostos por dispo- sitivos móveis, onde nenhuma suposição sobre recursos existentes no ambiente deve ser feita. Assim, considerando a necessidade de comunicação e coordenação, e buscando eliminar a de- pendência de qualquer recurso centralizado, o SysSU-DTS estende o SysSU, alterando sua arquitetura baseada em um espaço de tuplas centralizado para uma baseada em espaço de tuplas distribuído. A partir dessa mudança arquitetural o SysSU-DTS oferece acesso transparente a tuplas remotas e um mecanismo de escopo que restringe o acesso à essas tuplas.
Com isso, as aplicações podem ser desenvolvidas sem considerar a infra-estrutura de comunicação, e utilizar os próprios dispositivos existentes no ambiente (nó da rede) como infra-estrutura de comunicação e coordenação. O SysSU-DTS permite que as tuplas possam ser propagadas e replicadas nos espaços de tupla de cada nó da rede.
4.2 Principais Desafios
Para se obter um gerenciamento distribuído e totalmente descentralizado das infor- mações contextuais presentes em sistemas ubíquos, é necessário enfrentar os desafios inerentes aos sistemas móveis e distribuídos somados à ausência de um ponto central de gerenciamento do sistema.
Os sistemas distribuídos se comunicam e coordenam suas ações através da troca de mensagens pela rede e o principal objetivo é o compartilhamento de recursos (COULOURIS et
al., 2005). Seguindo esta definição a versão original do SysSU já oferece suporte ao compar- tilhamento de recursos através de uma rede de computadores. Porém a arquitetura do SysSU exige que exista uma infra-estrutura de comunicação fixa (i.e., acesso a um servidor) para que os componentes distribuídos do sistema possam se comunicar, essa infra-estrutura oferece acesso centralizado a todas as informações contextuais.
O principal desafio do SysSU-DTS é possibilitar a comunicação entre os compo- nentes distribuídos sem a existência de uma infra-estrutura de comunicação fixa (e.g., ponto de acesso 802.11). O SysSU-DTS oferece suporte ao compartilhamento de informações contextu- ais através de redes Ad hoc. Esse tipo de rede é formada de maneira dinâmica e temporária, e os próprios dispositivos envolvidos são responsáveis pela troca de mensagens. Uma vez que os dispositivos são móveis é preciso lidar com conectividade intermitente.
Diante da distribuição dos dados contextuais por diferentes nós da rede e da ins- tabilidade da conexão com provedores móveis de contexto, manter a integridade desses dados torna-se uma tarefa muito custosa e muitas vezes inviável. Portanto, é aconselhável evitar uma forte consistência semântica, optando-se por abordagens que adotem restrições de dados con- textuais baseadas QoC (Quality of Context - ver seção 2.3) (BELLAVISTA et al., 2012).
O SysSU-DTS combina o modelo de coordenação desacoplado e interoperável do SysSU, que atende ao requisito de desacoplamento na produção/consumo de dados contextuais citado na seção 2.3, com uma API de comunicação Ad hoc flexível e extensível1, que permite a comunicação por diferentes tipos de tecnologia sem fio, como Bluetooth e Wi-Fi Direct, e a adoção de diferentes algoritmos de roteamento, como Inundação (do inglês, Flooding) e AODV (do inglês, Ad hoc On-Demand Distance Vector Routing), atendendo ao requisito de adaptação a ambientes com conexões sem fio móveis e heterogêneas citado na seção 2.3. Dessa forma, cada nó da rede possui uma instância do SysSU-DTS e pode gerenciar suas interações com o ambiente. A complexidade envolvida no roteamento das mensagens em redes Ad hoc é delegada a esta API de comunicação e não faz parte do escopo deste trabalho.
1A API de comunicação Ad hoc utilizada é um projeto, ainda não publicado, desenvolvido nos laboratórios do
4.3 Modelagem Arquitetural
Na arquitetura adotada pelo SysSU-DTS cada dispositivo possui um espaço de tu- plas embarcado. Os componentes originais da arquitetura do SysSU, UbiBroker e UbiCentre (descritos na seção 3.1), foram mantidos, sendo criada uma versão móvel para dispositivos com o sistema operacional Android2(Figura 4.1), o código completo da implementação do SysSU- DTS está disponível para download e aberto a contribuições em um repositório público hos- pedado no GitHub, no seguite endereço web❤tt♣s✿✴✴❣✐t❤✉❜✳❝♦♠✴❇✐❧❧②❞✐t♦✴s②ss✉✲❞ts✴ ✇✐❦✐✴❙②s❙❯✲❉❚❙.
As tuplas presentes em cada dispositivo móvel podem ser acessadas por troca de mensagem. Esta funcionalidade é executada através de uma API de comunicação responsável por configurar uma rede de comunicação descentralizada e Ad hoc, como pode ser visto na Figura 4.1. Esta interface de comunicação está implementada como um serviço e é responsável pela comunicação direta entre dispositivos usando Bluetooth e Wi-Fi Direct. Sua arquitetura foi desenhada para assegurar uma estratégia de comunicação multi-salto desacoplada e extensível, sendo esta estratégia similar à adotada em (CONTI et al., 2010) para compartilhar, de forma oportunista, o conteúdo de dispositivos móveis.
Figura 4.1: Comunicação descentralizada através de espaço de tuplas distribuído. A interface de comunicação adotada foi encapsulada em um componente responsá- vel pela comunicação Ad hoc do SysSU-DTS, Ad Hoc Comminication, como visto na Figura 4.2, dessa forma qualquer evolução ou mudança da estratégia de comunicação Ad hoc pode ser
feita editando-se esse componente.
Figura 4.2: Visão geral da arquitetura do SysSU-DTS.
A migração de uma arquitetura baseada em espaço de tuplas centralizado (descrita na seção 3.1 e ilustrada pela Figura 3.1) para uma arquitetura baseada em espaço de tuplas distribuído, é o primeiro passo para a concretização do SysSU-DTS. A Figura 4.2 apresenta a visão geral da arquitetura do SysSU-DTS onde podemos notar que além da comunicação Ad hoc entre os dispositivos móveis, existe ainda a possibilidade de acesso direto ao espaço de tuplas embarcado no dispositivo e ainda é mantida a opção de interação entre um dispositivo móvel e um servidor centralizado de contexto (UbiCentre) através de uma infra-estrutura de comunicação fixa proposta na implementação original do SysSU.
lizar operações de leitura (query) e escrita (put) de tuplas e ainda se subscrever para receber notificações baseada em eventos especificados (subscribe).
O SysSU-DTS oferece ainda acesso transparente a diferentes tipos de provedores de contexto, classificados em três grupos: Provedor Local; Provedor Infra-estruturado; e Prove-