Baseados em Espaço de Tupla

Nesta seção serão considerados sistemas de middleware baseados no modelo de comunicação em espaço de tuplas (tuple-space) definido por Leach [Leach et al. 1983].

LIME

O LIME (Linda in a Mobile Environment) [Murphy et al. 2001] é um

middleware de compartilhamento de informação que adota o mecanismo baseado em espaço de tupla (tuple space) que original do Linda [Gelertner 1985], o qual provê estrutura de dados para sistemas de distribuição de rede fixa. O LIME estende este modelo e o torna mais adequado para ambientes móveis de alta dinamicidade. Ele define um espaço de tupla para cada host e associa permanentemente um ao outro. Quando um host se conecta a outro, as regras para o compartilhamento transiente de espaço de tupla são acionadas, sendo uma maneira rápida e instantânea para troca de informação. Cada host mantém uma interface de tupla (ITS - Interface Tuple-Space) que é permanentemente e exclusivamente associada ao host e transferida quando um movimento ocorre. Todos os ITS contêm as tuplas que o host deseja compartilhar com os outros, representando o único contexto acessível, e seu conteúdo é dinamicamente atualizado resultante de uma combinação com as demais tuplas conectadas. Durante a chegada de um novo host móvel, o conteúdo de cada host é atualizado com o conteúdo da nova unidade através dos respectivos ITS, caracterizando a operação chamada de engagement. Existe um espaço de tupla transiente chamado Lime System, que contém detalhes sobre os

hosts presentes no ambiente e os relacionamentos entre os mesmos, fornecendo assim informações sobre a configuração do sistema. É possível também reagir a eventos para permitir que ações sejam tomadas em resposta à mudança na configuração do sistema, da mesma forma que, eventos podem ser usados para notificar as aplicações que novas tuplas estão disponíveis.

Levantando-se as características do LIME sobre os critérios de análise, tem-se:

CM1. Possui heterogeneidade suficiente para ser aplicado em um sistema

de gerenciamento de tráfego de veículos, mas não trata a interoperabilidade entre plataformas.

CM2. O modelo de conexão não trata a dinamicidade da rede e

compromete a mobilidade.

CM3. O modelo de conexão e a permanência da conexão reduzem a

escalabilidade.

CM4. A permanência da conexão durante o engagement consome recurso

de rede indevidamente.

CM5. A falta de suporte a adaptação impossibilita a abertura. Limone

O Limone (Lightly-coordinated Mobile Network) [Fok et al. 2004] é um esforço de melhoria do middleware LIME [Murphy et al. 2001], superando

130 Sobre Middleware para MANETs

limitações de conectividade. Uma limitação do Lime é assumir que a rede não é tão dinâmica e assim mantém uma conexão permanente durante toda a transação de grupo. Para lidar com esta característica, o Limone suporta um alto grau de incerteza quanto ao estado da rede provendo um modelo de interação mais robusto entre as aplicações. O modelo é baseado em hosts individuais contendo controle total sobre a transação distribuída na qual participa. Isto é feito através da manutenção de uma lista de aquisição em cada host, provendo uma visão global do contexto de operação, sendo customizável pelo uso de políticas de admissão dependendo da dinâmica da rede e dos requisitos da aplicação. Os principais recursos deste middleware são: gerenciamento de contexto, acesso direto aos dados, programação reativa e mobilidade de código (ou migração de agentes). Através do gerenciamento de contexto é possível prover um eficiente mecanismo de descoberta de hosts vizinhos, dando melhor suporte a escalabilidade e a limitação de recursos.

Levantando-se as características do Limone sobre os critérios de análise, tem-se:

CM1. Possui heterogeneidade suficiente para ser aplicado em um sistema

de gerenciamento de tráfego de veículos, mas não trata a interoperabilidade entre plataformas.

CM2. O aumento do grau de incerteza no modelo de conexão maximiza a

mobilidade.

CM3. O aumento da dinamicidade da rede dá suporte a escalabilidade. CM4. A visão global possibilitada através da lista de aquisição facilita a

gerência dos recursos.

CM5. O uso de políticas de admissão e a mobilidade de código tornam o middleware adaptável em tempo de execução, satisfazendo assim a abertura.

XMIDDLE

O XMIDDLE [Mascolo et al. 2002b] provê mecanismos para lidar com operações desconectadas no ambiente de redes móveis ad hoc, considerando a orientação ao compartilhamento de dados. O XMIDDLE oferece uma estrutura de dados (assim como o ITS do LIME) robusta para suportar cenários ad hoc e nenhuma premissa é feita sobre a existência de um provedor fixo ou hosts privilegiados como no caso das redes nômades. Usando uma estrutura de dados baseada em árvore definida em XML, os hosts podem estabelecer uma comunicação eficiente uns com os outros, possibilitando a colaboração on-line, manipulação de dados off-line, sincronização e reconciliação de dados dependente de aplicação. Desde que dois hosts estejam conectados, eles podem compartilhar e modificar a informação de cada árvore de dados. Quando a desconexão ocorre, os hosts retêm as réplicas das árvores que compartilhavam enquanto estavam conectados e continuam a poder acessá-las e modificá-las em modo desconectado. Quando ambos os hosts voltam a se conectar, o processo de reconciliação é acionado usando as réplicas previamente armazenadas, e a atualização é realizada. Porém, não é possível a atualização completa da árvore, principalmente se o host tem recursos muito limitados, e assim somente ocorre a recuperação de uma parte específica da árvore.

Levantando-se as características do XMIDDLE sobre os critérios de análise, tem-se:

CM1. Suporta heterogeneidade de dispositivo por ser implementado em

Java, porém não suporta interoperabilidade entre plataformas.

CM2. A mobilidade é parcialmente suportada pela estrutura de dados em

árvore.

CM3. Um mecanismo de descoberta de recursos ainda deve ser provido

para melhorar a escalabilidade.

CM4. Os mecanismos de operações desconectadas e reconciliação dão

suporte à limitação de recurso.

CM5. Possui abertura bastante limitada, pois somente possui um modelo

de comunicação básico para o ambiente de rede móvel ad hoc.

MESHMdl

O MESHMdl [Herrmann et al. 2007] é construído em cima do modelo de espaço de tupla e propõe um middleware para suportar comunicação anônima, assíncrona e baseada em conteúdo. As principais características dele são ciência de contexto e a auto-organização. A camada de comunicação, chamada de Event Space, é formada por um conjunto de tuplas que permite a interação de forma mediada e o acesso às informações atualizadas de contexto. As aplicações são expressas na forma de grupos de agentes móveis que colaboram entre si. A arquitetura do MESHMdl é composta pela camada de conexão genérica, camada de interação, camada Space, engine de execução de agentes e os agentes de aplicação. As duas primeiras camadas encapsulam diferentes tecnologias de rede e provê mecanismos de descoberta de hosts vizinhos e de interação entre eles. Desta forma, elas proporcionam que o middleware seja independente de uma rede específica. A camada Space define a maneira que as áreas de hosts são construídas e gerenciadas, formando um espaço de comunicação compartilhada. A engine funciona como um ambiente de execução dos agentes e estão presentes em todos os hosts. Já os agentes de aplicação são responsáveis por gerenciar a criação de determinado agente e a cooperação entre as aplicações através de um protocolo de engagement.

Levantando-se as características do MESHMdl sobre os critérios de análise, tem-se:

CM1. Suporta heterogeneidade de dispositivo por ser implementado em

Java, porém não suporta interoperabilidade entre plataformas.

CM2. Os dois modelos de comunicação (espaço de tupla e agentes

móveis) dão suporte à mobilidade.

CM3. O mecanismo de espaço de tupla não federado proporciona maior

escalabilidade.

CM4. O modelo de comunicação assíncrono é adequado para economia

de bateria e de tráfego de rede.

132 Sobre Middleware para MANETs