Fernando Alberto de Sousa nusp: 3286224



Baixar 153.81 Kb.
Página3/4
Encontro29.07.2016
Tamanho153.81 Kb.
1   2   3   4

3.1.8 Considerações Finais sobre o Gaia

Em suma, pode-se apontar alguns pontos importantes no projeto Gaia que acabam por caracterizá-lo como uma proposta audaciosa.

A infra-estrutura que o Gaia atualmente provê faz com que seja possível coordenar recursos existentes em um espaço físico e criar aplicações ubíquas através da conexão dinâmica de componentes disponíveis. GaiaOS converte espaços físicos e seus dispositivos de computação ubíqua em um sistema de computação programável.

O framework de aplicação do Gaia permite o particionamento de aplicações, a implantação dinâmica de componentes de aplicação, a adaptação a diferentes características de dispositivos, a reação às mudanças de contexto, e anexar/desanexar componentes de aplicação. A ferramenta de script da LuaOrb permite a automação das tarefas de gerenciamento e configuração, descrição e criação de cenários de computação ubíqua, permite também a realização de testes dos componentes e a concepção de protótipos de novas aplicações.

Para validar a infra-estrutura, foi desenvolvida uma aplicação de apresentação que opera em múltiplos displays e coordena todos os recursos disponíveis no espaço inerente para conduzir apresentações. Nesta aplicação, o Gaia é utilizado para integrar dispositivos infravermelho, dispositivos X10, dispositivos distintos de identificação de usuários e componentes de software de diferentes sistemas, como CORBA e COM.

Embora ainda existam muitas questões a serem investigadas sobre ambientes de computação ubíqua, os resultados preliminares mostram que oferecer uma infra-estrutura comum pode reduzir significativamente a complexidade desta tarefa.



3.2 Projeto One.World
Uma nova arquitetura, one.world, provê um framework integrado e detalhado para construção de aplicações pervasivas. É destinado às aplicações que devem se adaptar automaticamente a ambientes de computação altamente dinâmicos e inclui serviços que torna mais fácil para os desenvolvedores gerenciar a constantes mudanças.

Para superar as limitações dos sistemas distribuídos contemporâneos, três requisitos que os sistemas devem contemplar para aplicações pervasivas podem ser identificados. Primeiramente as pessoas movimentam-se pelo mundo físico, além disso podem estar portando seus próprios dispositivos portáteis ou ainda alternar os dispositivos que portam, um contexto de execução e localização de aplicação muda constantemente. Então, a estrutura do sistema deve admitir a mudança contextual e não escondê-la das aplicações. Em segundo lugar, os usuários esperam que seus dispositivos e aplicações apenas “pluguem” juntos, ou seja, desejam que as configurações sejam dinâmicas, assim o sistema também deve ter suporte à composição ad hoc e não assumir um ambiente de computação estático com apenas algumas poucas interações. Em terceiro lugar, como os usuários colaboram, eles devem compartilhar informação facilmente. Desta forma, o sistema deve suportar compartilhamento entre aplicações e dispositivos.

A arquitetura proposta no projeto é focada em torno da contemplação destes três requisitos, empregando um divisão clássica usuário/kernel: A base e os serviços de sistema rodam no kernel; bibliotecas, utilitários e aplicações rodam no espaço do usuário.

A base dos serviços do One.world busca atender àqueles requisitos. Eles também provém a base da arquitetura dos serviços de sistema, os quais servem, por sua vez, como tijolos comuns para a construção de aplicações pervasivas.



Os quatro serviços básicos são uma máquina virtual, tuplas, eventos assíncronos e ambientes. Primeiramente, todo código no one.world executa em uma máquina virtual, a Java virtual machine (JVM). Devido a heterogeneidade inerente aos ambientes de computação pervasiva, os desenvolvedores não conseguem garantir que todos os dispositivos executarão a aplicação, assim a JVM assegura que as aplicações e dispositivos podem ser integrados. Em segundo lugar, o one.world representa todos os dados como tuplas, que define um modelo de dados comum, incluindo um sistema de tipos para todas as aplicações e então simplifica o compartilhamento de dados. Tuplas são registros compostos por campos que possuem um nome e um tipo definido opcionalmente. Além disso, cada tupla é auto-descritiva, então uma aplicação pode dinamicamente inspecionar sua estrutura e conteúdo. Em terceiro lugar, one.world expressa toda a comunicação, seja local ou remota, através de eventos assíncronos. Tais eventos servem para explicitamente notificar as aplicações de mudanças em seus contextos de execução. Finalmente, os ambientes são o principal mecanismo de estruturação do one.world, como os processos dos sistemas operacionais tradicionais, os ambientes hospedam as aplicações em execução e efetuam o isolamento entre elas. Eles também servem como containers para dados persistentes, provendo armazenamento associativo de tuplas e tornando possível também agrupar aplicações executando com seus dados persistentes. Além disso, ambientes podem aninhar-se facilitando a extensão e a composição de aplicações. Um ambiente externo tem controle total sobre todos os ambientes internos a ele, incluindo a habilidade de interceptar facilmente e modificar os eventos enviados por estes ao kernel do one.world (que executa em um ambiente raiz do dispositivo) e para outros dispositivos. A facilidade de interposição permite aos desenvolvedores e usuários mudar dinamicamente a própria aplicação. Outro ponto importante é que a interposição é particularmente útil para comportamentos complexos e reutilizáveis, tais como a replicação dos dados da aplicação e a decisão de quando migrá-la. A figura a seguir mostra um exemplo de hierarquia de ambientes.


Figura: exemplo de hierarquia de ambientes.

O ambiente “User” hospeda Emcee, o utilitário para o gerenciamento de aplicação e usuários do one.world. “User”tem um ambiente filho “Robert”, que armazena diversas tuplas representando as preferências do usuário. O ambiente “Robert” tem dois filhos: “Clock” que contém apenas tratadores de eventos ativos; “Chat” que hospeda a aplicação de mensagens instantâneas e armazena tuplas representando sons que são enviados via broadcast pela aplicação.

(Correspondência entre as necessidades das aplicações pervasivas e os serviços oferecidos pelo one.world)

A tabela anterior exibe um mapeamento resumido entre as necessidades de aplicações pervasivas e os serviços correspondentes no one.world que visam atender a cada necessidade. Destes serviços, descoberta e migração são, provavelmente, os mais intereessantes. O serviço de descoberta localiza recursos – isto é, tratadores de eventos – através de suas descrições. Ele confere ao one.world um modelo de dados uniforme, no qual todos os dados, incluindo eventos e consultas, são tuplas. Usando este modelo de dados, tal serviço suporta um rico conjunto de opções, incluindo early binding e late binding, anycast e multicast, com apenas três operações simples. Além disso, devido ao serviço de descoberta ser essencial – sem ele as aplicações não podem adaptar-se a um novo ou a um alterado contexto de execução – ele é autogerenciado também. Um dispositivo age como o servidor de descoberta, provendo mapeamentos entre descrições e tratadores de eventos. Todos os dispositivos executando no one.world que são visíveis na rede local automaticamente elegem o servidor entre eles mesmos. Para garantir disponibilidade, o one.world convoca eleições ativamente e estas eleições terminam depois de um período de tempo fixo. Os dispositivos individuais toleram todas as inconsistências resultantes exportando recursos a serem descobertos para todos os servidores visíveis enquanto que efetua busca de recursos em apenas um servidor.

O serviço de migração move ou copia um ambiente e todo o seu conteúdo para um dispositivo diferente, simplificando, desta forma, a implementação de aplicações que seguem uma pessoa através do mundo físico. Diferentemente do processo tradicional de migração, a migração do one.world não é transparente e o estado da aplicação migrada é limitado aos ambientes sendo migrados. Durante a migração, one.world automaticamente libera as referências para recursos que estão fora da árvore de ambientes. Esta prática é aceitável porque as aplicações já esperam mudanças. A migração do one.world é impaciente, por mover o estado inteiro entre os dispositivos em uma única operação atômica. Isso evita dependências residuais e requer conectividade entre os dispositivos apenas durante a migração. O resultado disso é que a migração do one.world evita os excessos de complexidade do processo de migração tradicional e a migração através da Internet se torna prática.

O one.world foi especialmente desenhado para ajudar os desenvolvedores a construir aplicações que adaptam-se automaticamente a mudanças arbitrárias no ambiente computacional. O serviço de descoberta ajuda na localização e na conectividade aos serviços disponíveis em outros dispositivos e a migração ajuda na implementação de aplicações que seguem um usuário através do mundo físico. A vantagem da arquitetura dos serviços do one.world sobre os outros é que os mesmo foram construídos para aceitar mudanças, encorajar composições ad hoc e facilitar o compartilhamento.
3.2.1 Critério de Avaliação

Na avaliação do one.world, a equipe de desenvolvimento procurar dar foco aos três requisitos que conduzem a uma arquitetura prática para aplicações pervasivas (referidos anteriormente). Entretanto, devido ao fato de uma avaliação ser algo mais geral e difícil de se fazer, pode-se confiar em quatro critérios mais específicos e alguns pontos relacionados a eles:

• Completude. Pode-se construir programas úteis utilizando o one.world?

Este critério determina se a arquitetura do one.world é suficientemente poderosa e extensível para suportar programas interessantes de espaço de usuário, incluindo serviços adicionais e utilitários semelhantes ao shell do Unix.

• Complexidade: O quão difícil é escrever código no one.world?

Este critério determina o esforço envolvido em desenvolver programas para a arquitetura do one.world. O interesse principal no desenvolvimento do one.world é em como fazer as aplicações adaptáveis gerarem um bom impacto na produtividade dos programadores.

• Performance. A performance do sistema é aceitável?

Este critério determina se a arquitetura trabalha bem o bastante para suportar a carga de trabalho das aplicações atuais. Isso porque um dos objetivos é fazer as aplicações adaptáveis, então é interessante fazer com que as mesmas respondam prontamente a mudanças no seu contexto de execução.

• Utilidade. O one.world pode prover recursos para que aplicações reais sejam construídas?

Este critério determina se outros podem construir aplicações pervasivas reais sobre o one.world. Ele também representa o critério mais importante. Isso porque, em verdade, a utilidade da arquitetura de um sistema é determinada pela utilidade dos programas que podem ser executados sobre ela.


3.2.2 Serviços e aplicações sobre o one.world

Para responder às questões feitas anteriormente, a equipe de desenvolvimento criou diversos serviços, utilitários e aplicações a serem executadas sobre o one.world. Em particular, foi construído um serviço de replicação, que gerencia a aplicação e o usuário chamado Emceee um sistema de mensagens instantâneas de texto e áudio chamado Chat. A equipe de desenvolvimento do one.world também colaborou com o projeto Labscape da Universidade de Washignton que portou seu assistente digital do laboratório de biologia para o one.world. A equipe do Landscape desenvolveu seu assistente de laboratório como parte da iniciativa de Cell Systems.

Além destes programas, estudantes vêm construindo aplicações sobre tal arquitetura, sistemas de compartilhamento de músicas, sistemas de mensagens, aparelhos domésticos inteligentes, um debugger gráfico e um Web Server.
3.2.2.1 Serviço de replicação

Para prover acesso ubíquo à informação, aplicações pervasivas devem acessar os itens de dados correspondentes até se diversas pessoas compartilham os mesmos dados e os acessam de dispositivos distintos e, possivelmente, desconectados. O serviço de replicação ajuda a contemplar tal cenário. O modelo de replicação tem duas camadas, um mestre que guarda todos os dados e réplicas que armazenam cópias dos dados. O serviço de replicação executa no espaço do usuário e explora o aninhamento de ambientes do one.world para interferir no acesso da aplicação ao armazenamento de tuplas. No modo conectado, atualizações são definitivas e o sistema as encaminha diretamente ao mestre. No modo desconectado, as atualizações são tentativas e o sistema faz log delas na réplica em um ambiente separado de log. Quando uma réplica conecta novamente, ocorre a sincronização com o mestre repassando seu log para o mestre e recebendo quaisquer atualizações do mesmo. A sincronização é implementada através da migração de uma cópia do ambiente de log para o mestre, onde um componente específico da aplicação repassa as atualizações e, se necessário, executa alguma resolução de conflito.


3.2.2.2 Gerenciamento de apicação e usuários

Emcee inclui suporte para definição de usuários, execução de aplicações para um usuário e check-pointing para todas as aplicações de usuário. Emcee também permite que os usuários movem ou copiem aplicações e seus dados através de uma simples interface drag-and-drop, ou mover todas as aplicações entre os dispositivos. Os usuários podem jogar aplicações do dispositivo atual para outro dispositivo e vice-versa. Como a figura a seguir mostra, a implementação estrutura a hierarquia de ambientes de acordo com o padrão /User// e constrói diretamente neste ambiente aninhado para controlar as aplicações de usuários. A implementação confia no check-pointing e na migração para salvar, recuperar, mover e copiar aplicações e no serviço de descoberta para localizar uma aplicação de usuário quando joga-se a mesma para um novo dispositivo.
3.2.2.3 Resultados experimentais

Alguns dos programas citados anteriormente e outras aplicações construídas para executar sobre o one.world permitem chegar a algum tipo de resposta às questões levantadas na análise dos quatro critérios apresentados anteriormente.


3.2.2.3.1 Completude

Os programas construídos mostram que o one.world é poderoso o bastante para suportar uma considerável variedade de programas muito úteis. Além disso, o serviço de replicação e o Emcee demonstram que é possível implementar serviços e utilitários no espaço de usuário. A “feature” chave para prover serviços no espaço do usuário e utilitários é a hierarquia de ambientes do one.world, a qual torna fácil controlar outros programas e interferir nos seus canais de eventos.


3.2.2.3.2 Complexidade

Para avaliar o esforço envolvido em escrever aplicações adaptáveis, o processo de implementação do Emcee e do Chat foi cuidadosamente examinado. O desenvolvimento dos dois programas levou 256 horas e mostra resultados de produtividade que permitem afirmar que construir aplicações adaptáveis não é significativamente mais difícil que escrever aplicações mais convencionais.


3.2.2.3.3 Performance

Foram feitas medidas com o Emcee e o Chat utilizando Java HotSpot Virtual Machine 1.3.1 da Sun executando em máquinas Dell 800Mhz – Pentium III conectados através de Ethernet 100M-byte. As medidas mostraram que as interrupções de serviço devido a migração ou eleições do serviço de descoberta levaram menos de 4 segundos, resultado que permite uma comparação favorável, por exemplo, em relação ao time-out do TCP depois de diversos minutos. Além disso, embora a latência de migração geralmente dependo da quantidade e do tamanho de tuplas armazenadas, esta latência é de apenas 7 segundos para um ambiente que guarda 8 Mbytes de dados de áudio, que é rápido o bastante para uma pessoa movendo-se através do espaço físico.


3.2.2.3.4 Utilidade

A aplicação citada anteriormente, o assistente laboratorial ilustra a utilidade que pode-se conferir às aplicações de “mundo-real” que podem ser construídas. Além disso, a equipe do Labscape estabelece uma comparação entre as duas últimas versões do assistente. A penúltima versão foi implementada utilizando sockets de Java e a funcionalidade de migração foi implementada pela própria aplicação. A migração para o one.world levou menos da metade do tempo gasto para a implementação da 1ª. Versão. Isso sem contar algumas vantagens obtidas na quantidade de falhas devido à migração e à possibilidade dos desenvolvedores focarem no desenvolvimento da aplicação, isso por causa das características da arquitetura que provê um nível de indireção que evita que se manipule conexões TCP diretamente, por exemplo.





3.3 Projeto Aura
O projeto Aura foi desenvolvido com o foco em algumas situações, alguns cenários que são os alvos para o tipo de aplicação cujo desenvolvimento deseja-se possibilitar. Estes cenários não são muito diferentes dos cenários que motivam os demais projetos, mas situam bem as idéias do projeto, mostrando o foco das preocupações da equipe de desenvolvimento do mesmo, apresentando como a solução agiria para resolver as situações-problema.

O Aura vem do vislumbre do “mundo pervasivo” que pode ser ilustrado por dois cenários hipotéticos, mas que são considerados lugar comum durante a pesquisa:

1) No primeiro cenário, Jane está no portão 23 do aeroporto de Pittsburgh, esperando pela seu vôo de conexão. Ela editou vários documentos longos e gostaria de usar a sua conexão wireless para enviá-los por email. Infelizmente, a largura da banda é pequena porque muitos passageiros dos portões 22 e 23 estão navegando na Web.

Neste cenário o Aura observa que, com a largura de banda atual, Jane não vai conseguir enviar seus documentos antes de seu vôo partir. Consultando a largura da banda através do serviço da rede wireless do aeroporto e o serviço de agendamento de vôos, o Aura descobre que a largura da banda é excelente no portão 15 e que não na vôos partindo ou chegando nos portões vizinhos na próxima meia hora. Uma caixa de diálogo mostra para Jane uma tela sugerindo que ela vá ao portão 15 que está apenas a 3 minutos dali. Além de pedir a ela que priorize seu email que é a aplicação mais crítica e deve ser transmitido primeiro. Jane aceita o conselho do Aura e anda até o portão 15. Ela assiste aos informes da eleição na tv até que o Aura a avisa que ela já está perto o bastante de um local com boa largura de banda e já pode realizar suas tarefas, então depois de iniciado o processo ela pode começar a voltar. A última mensagem é transmitida durante sua caminhada e ela está de volta ao portão 23 a tempo da chamada para embarque.

2) No segundo cenário, Fred está no escritório, preparando-se freneticamente para uma reunião na qual ele fará uma apresentação e uma demonstração de software. A sala de reunião fica a 10 minutos dali, atravessando o campus. É hora de sair, mas Fred não está completamente pronto. Ele pega seu Palm XXII e sai pela porta. O aura transfere seu trabalho de seu desktop para o seu computador de mão e permite que ele faça sua edição final utilizando comandos de voz durante sua caminhada. O Aura infere para onde Fred está indo, através de sua agenda e do serviço de rastreamento de localização do campus e então faz um download da apresentação e do software de demonstração no computador que será utilizado para a projeção e inicia também a preparação do projetor. Fred termina sua edição imediatamente antes de entrar na sala de reunião. No momento que ele entra, o Aura transfere suas mudanças finais ao computador de projeção. A medida em que a apresentação se segue, Fred está prestes a mostrar um slide que contém informações sigilosas sobre orçamento, Aura “sente” que isso pode ser um erro: a detecção de faces da sala e a capacidade de reconhecimento indicam que existem alguns rostos incomuns presentes, então o Aura avisa Fred que, percebendo que o Aura está certo, pula o slide na apresentação, indo para outros tópicos e termina a apresentação muito bem conceituado, deixando a audiência impressionada com sua ilustre apresentação.

Estes cenários expressam as idéias chaves de computação pervasivas que são consideradas no escopo do projeto Aura.

No cenário 1) o Aura é pró-ativo na estimativa de quanto tempo Jane levará para enviar seus documentos além de combinar conhecimento de sistemas de diferentes camadas, determinando o congestionamento da rede wireless (baixo-nível) e a tabela de vôos (uma aplicação conceitualmente de nível de usuário) para permitir que Jane completasse o envio de seu email. Além disso, Aura tira vantagens de locais “espertos”, utilizando os serviços de seu ambiente para determinar as condições de banda wireless nos outros portões e as distâncias entre os mesmos.

O cenário 2) mostra como pode-se transferir facilmente o estado de execução através de plataformas diversas – de um desktop para um computador de mão, e do computador de mão para um computador de projeção, por exemplo – ele exemplifica auto-ajuste através da possibilidade de Fred editar no dispositivo de mão utilizando a fala. O Aura mostra sinais de proatividade quando infere que Fred está indo para a sala através do campus, prepara o projetor, transfere a apresentação e a demo, antecipa o iminente slide de orçamento e “sente” o perigo através da combinação disso com o conhecimento da presença inferida de estranhos. Aura usa os espaços “espertos” quando consulta o rastreamento de localização e os serviços de agenda online para inferir o destino de Fred, quando aciona o software de preparação do projetor e quando utiliza a câmera da sala com reconhecimento de faces para avisar Fred que ele está para expor possivelmente impropriamente algumas informações sigilosas.

As tecnologias de componentes apresentadas nestes cenários não são consideradas complexas. As tecnologias de hardware estão prontamente disponíveis, porém são muitas as tecnologias de componentes de software – rastreamento de localização, reconhecimento de faces, reconhecimento de voz e agendas online, infelizmente o todo é muito mais que a soma das partes. A pesquisa se faz necessária para não apenas construir os blocos da computação pervasiva, mas também para efetivar a integração de serviços e dispositivos.

No projeto Aura, está sendo desenvolvida a arquitetura de sistema, algoritmos, interfaces e técnicas de avaliação que concretizam a visão do Aura. A seguir temos uma mostra da arquitetura adotada:



O texto em itálico indica cada regra de componente. Coda e Odissey (que são projetos relativamente paralelos que estão inseridos no projeto Aura) foram criados a priori para o Aura, mas estão sendo modificados substancialmente para atender à demanda da computação pervasiva.

Odissey dá suporte ao monitoramento de recursos e adaptação ciente de contexto.

Coda provê um sistema de arquivos nômade, disconectável e adaptável à largura de banda.

Spectra é um mecanismo adaptativo de execução remota que utiliza o contexto para decidir de que maneira fará a chamada.

O Prisma, que será detalhado posteriormente, compõe uma nova camada de sistema que é responsável por capturar e gerenciar a intenção do usuário. A camada do prisma fica acima das aplicações e provê suporte de alto-nível para pró-atividade e auto-ajuste.

Notando a arquitetura e o conceito independente de alguns elementos podemos ver que o Aura é composto por alguns projetos paralelos que, por si só tentam contemplar alguns dos requisitos da computação pervasiva.

1   2   3   4


©principo.org 2016
enviar mensagem

    Página principal